Спор с «суперпрограммистом»
Произошёл спор с разработчиком, утверждавшим о превосходстве над автором и готовностью обучать за значительно меньшую цену. Для демонстрации разницы в квалификации, ему было предложено предоставить пример кода на Java. Анализ полученного кода представлен ниже.
Анализ кода: ошибки и антипаттерны
Представленный код содержит многочисленные ошибки. Разметка выполнена вручную, поскольку код предоставлен в виде скриншотов.
Метод getStationAction: проблемы с дизайном и стилем
Рассмотрим метод getStationAction из мега-класса GameServer (более 3600 строк кода). Его местоположение свидетельствует о перегруженности кода и реактивном подходе к разработке без должного проектирования. Наблюдается ситуативная разработка: решение проблем по мере их возникновения без учёта общей архитектуры.
- Отсутствие модификатора доступа: Метод объявлен без модификатора доступа (public, private и т.д.), что является ошибкой в C#. Модификаторы доступа должны указываться явно.
- Неинформативное имя метода: Имя getStationAction неинтуитивно. Рекомендуется использовать глагол + существительное, отражающее действие метода.
- Список параметров: Список параметров (ссылка на объект business, player, byte action, массив pit) не разделен пробелами. Использование ссылки на business указывает на неэффективное использование репозиториев или других механизмов постоянного хранения данных. Смешение слоёв предметной области (business) и низкоуровневых сетевых операций (player) нарушает принципы проектирования.
- Использование switch вместо полиморфизма: Использование switch по значению byte action для реализации полиморфизма неэффективно и снижает читаемость. Рекомендуется использовать типы и интерфейсы. Пример переписывания с использованием полиморфизма можно запросить в комментариях. Проблема усугубляется отсутствием абстракции: byte не несёт семантической информации, что требует дополнительных комментариев для пояснения значений.
- Отсутствие пробелов: Отсутствие пробелов между параметрами снижает читаемость кода.
Вложенная функция: проблемы с именованием и логикой
Вложенная функция (с маленькой буквы) обрабатывает данные (возможно, XML или JSON), но имеет неинформативное имя. Рекомендуется использовать прямое сравнение (==) вместо унарного оператора (!=). Метод смешивает проверку (is hacker content) и действие (disconnect). Проверку и действие необходимо разделить.
Переменная bannerRaider: проблемы с именованием и использованием
Переменная bannerRaider типа byte имеет неинформативное имя. Имя переменной должно отражать её назначение, а не тип данных. Использование switch вместо полиморфизма повторяется.
Парсинг данных: проблемы с индексами и обработкой ошибок
Парсинг использует «магические числа» (индексы без описания), что снижает читаемость и затрудняет поддержку. Отсутствие проверок на null может приводить к исключениям. Динамический контейнер свойств (business) затрудняет переименование атрибутов и поиск мест использования. Обработка ошибок недостаточно надёжна.
Запись в поток: проблемы с оптимизацией и оформлением
Запись в поток происходит с неявной стратегией открытия/закрытия соединения. Код перегружен промежуточными действиями (парсинг, проверки), что затрудняет понимание основной логики. Отсутствие таких инструментов, как Visual Studio или ReSharper, указывает на недостаток в среде разработки.
Разработчик, предлагающий услуги за 200 рублей в час, предоставляет код низкого качества. Цена его услуг не соответствует квалификации. Анализ кода выявил множество ошибок, свидетельствующих о недостатке опыта и понимания принципов разработки ПО.