Перейти к содержанию

Требования к разработке

1. Название приложения

Используйте корректные и осмысленные названия для приложений и файлов.

  • Наименование настольного приложения должно обязательно включать название компании-заказчика.
  • Названия должны отражать назначение: избегайте шаблонов и “заглушек” вроде App1, Test, NewProject.

Пример: - KorokNET.AuthClient (если компания-заказчик — KorokNET) - KorokNET.AdminPanel - KorokNET.ServiceDesk

2. Файловая структура

Файловая структура проекта должна отражать логику приложения и обеспечивать удобную навигацию по коду.

Рекомендуемая организация: - формы — в одной директории; - пользовательские визуальные компоненты — в другой; - классы сущностей / модели — в третьей; - работа с БД (репозитории, контекст, SQL) — отдельно; - сервисы (бизнес-логика) — отдельно.

Пример структуры: 

/Data
/Models
/Repositories
/Services
/UI
/Forms
/Controls
/Assets

3. Структура проекта

  • Каждая сущность должна быть представлена в программе как минимум одним отдельным классом.
  • Классы должны быть:
  • небольшими;
  • понятными;
  • выполнять одну функцию (принцип SRP — Single Responsibility Principle).

Пример: - User — модель данных - UserRepository — работа с таблицей пользователей - AuthService — логика входа, блокировок, проверки капчи

4. Макет и технические характеристики интерфейса

Все компоненты системы должны иметь единый согласованный внешний вид и соответствовать требованиям:

  • Разметка и дизайн: предпочтение отдается масштабируемой компоновке (Dock/Anchor, TableLayoutPanel).
  • Должно быть ограничение на минимальный размер окна.
  • Должна быть возможность изменения размеров окна, где это необходимо.
  • При увеличении окна должна увеличиваться контентная часть (например, таблица данных из БД).
  • Должна быть группировка элементов в логические категории (GroupBox, панели, вкладки).
  • Используйте соответствующие элементы управления, например:
  • выпадающие списки (ComboBox) для подстановочных значений из БД;
  • маски ввода (MaskedTextBox) для телефонных номеров и т.п.
  • Корректное расположение и выравнивание элементов (метки, поля ввода, кнопки).
  • Последовательный переход фокуса по элементам интерфейса по клавише TAB.
  • Общая компоновка должна быть логичной, понятной и простой.
  • На каждом окне должен быть соответствующий заголовок:
  • не допускаются значения по умолчанию типа MainWindow, Form1, Документ1 и т.п.

5. Обратная связь с пользователем

Пользователь должен получать корректную обратную связь:

  • уведомления об ошибках ввода;
  • уведомления о запрещённых действиях в рамках задания;
  • сообщения об отсутствии результатов поиска;
  • подтверждения успешных действий (при необходимости).

Сообщения должны отображаться в окнах соответствующего типа: - Ошибка (Error) - Предупреждение (Warning) - Информация (Information)

Требования к сообщениям: - корректный заголовок окна; - соответствующая пиктограмма; - текст полезный и информативный: - что произошло; - почему это ошибка; - что нужно сделать, чтобы исправить.

Допускается использование визуальных подсказок: - подсветка полей; - подсказки возле элемента; - сообщения под полями ввода.

6. Обработка ошибок

  • Не позволяйте вводить некорректные значения в текстовые поля сущностей:
  • несоответствие типу данных;
  • превышение допустимого размера;
  • запрещённые символы (если предусмотрено проверкой).
  • При ошибке ввода пользователь должен получить понятное уведомление.

При возникновении непредвиденной ошибки приложение не должно аварийно завершать работу: - используйте try/catch в критически важных местах; - выводите сообщение пользователю и сохраняйте работоспособность приложения (насколько возможно).

7. Оформление кода

  • Идентификаторы переменных, методов, классов должны отражать суть и цель использования.
  • Это относится и к элементам управления:
  • запрещены названия по умолчанию (Form1, button3, textBox1).
  • Идентификаторы должны соответствовать соглашениям об именовании среды разработки (для C# обычно PascalCase/camelCase).
  • Допустимо использование не более одной команды в строке.

8. Комментарии

  • Используйте комментарии только для пояснения неочевидных фрагментов кода.
  • Запрещено комментирование “очевидного”: хороший код читается как обычный текст.
  • Не используйте комментарии, которые дублируют то, что и так понятно по названию метода или переменной.
  • Комментарии должны присутствовать только там, где действительно требуется дополнительное пояснение.