Если класс достаточно автономен и не будет повторно использоваться в «нетипичных» сценариях, вы ДОЛЖНЫ использовать “GOD” классы.
❌ Это правило кажется противоречивым с принципом единой ответственности (Single Responsibility Principle), который говорит, что каждый класс должен иметь только одну причину для изменения. “GOD” классы - это классы, которые делают слишком много вещей и нарушают этот принцип. Они могут быть трудными для понимания, тестирования и поддержки.
Если “Рефакторинг” кода приводит к большому увеличению количества строк, этот рефакторинг НЕ НУЖЕН.
❌ Это правило кажется слишком упрощенным и не учитывает другие факторы, такие как читаемость, производительность и расширяемость кода. Рефакторинг кода может увеличить количество строк, но сделать код более понятным, быстрым или гибким. Количество строк не должно быть единственным критерием для рефакторинга.
Если “Интерфейс” используется только одним классом, то этот интерфейс не нужен, просто используйте КЛАСС КАК ЕСТЬ.
✔️ Это правило может быть верным в некоторых случаях, но не во всех. Интерфейс может быть полезен для определения контракта или спецификации поведения класса, даже если он используется только одним классом. Интерфейс также может облегчить тестирование и замену класса в будущем.
Если извлечение части кода метода в отдельный метод не влияет на остальную часть кода, НЕ СЛЕДУЕТ извлекать код в отдельные методы.
❌ Это правило также кажется слишком упрощенным и не учитывает преимущества извлечения кода в отдельные методы. Такие преимущества могут включать повышение читаемости, переиспользования и тестируемости кода. Извлечение кода в отдельные методы также может помочь избежать дублирования кода и нарушения принципа DRY (Don’t Repeat Yourself).
Использование «Инъекций зависимостей» разрешено только в случае крайней необходимости.
✔️ Это правило может быть обосновано тем, что инъекция зависимостей может усложнить код и добавить дополнительную сложность. Однако инъекция зависимостей также имеет много преимуществ, таких как обеспечение слабой связанности между компонентами, упрощение тестирования и поддержки кода и повышение гибкости и расширяемости системы. Инъекция зависимостей должна использоваться там, где она дает больше пользы, чем затрат.
Любые изменения “для красоты” не допускаются.
❌ Это правило может быть интерпретировано по-разному в зависимости от того, что считается “красотой”. Если это означает следование общепринятым стандартам кодирования и стиля, то это полезно для улучшения читаемости и согласованности кода. Если это означает добавление ненужных украшений или эффектов, то это может быть излишним или отвлекающим. В любом случае, изменения “для красоты” должны быть обоснованы и согласованы с командой.
Если использование шаблона увеличит количество классов в вашем коде по сравнению с кодом без шаблона, и вы не получите НАСТОЯЩИХ улучшений, то вам не нужно использовать этот шаблон.
✔️ Это правило звучит разумно, но определение “НАСТОЯЩИХ улучшений” может быть неоднозначным. Шаблоны проектирования предназначены для решения общих проблем в программировании с помощью проверенных решений. Они могут помочь сделать код более модульным, расширяемым и поддерживаемым. Однако они также могут добавить сложность и избыточность в коде. Шаблоны проектирования должны использоваться тогда, когда они подходят для задачи и контекста, а не ради использования шаблонов.
Изменения, затрудняющие чтение кода, даже если они улучшают архитектуру, ЗАПРЕЩЕНЫ.
❌ Это правило может быть спорным, так как оно подразумевает, что архитектура и читаемость кода противоположны друг другу. Хорошая архитектура должна способствовать читаемости кода, а не мешать ей. Изменения в архитектуре должны быть продуманными и обоснованными целями проекта. Если изменения делают код трудным для понимания, то возможно стоит пересмотреть эти изменения или добавить комментарии для пояснения2.
Прежде чем «отделить модель от вида», подумайте, будете ли вы когда-нибудь заменять вид.
✔️ Это правило может быть хорошим советом для избежания переусложнения кода. Отделение модели от представления - это распространенный подход к разработке пользовательского интерфейса (UI), который позволяет изменять UI без влияния на логику приложения. Однако этот подход может быть избыточным или неподходящим для некоторых типов приложений или проектов. Отделение модели от представления должно быть продиктовано требованиями и ожиданиями пользователей.
Если модель неотделима от представления в соответствии с «Бизнес-Логикой» (например редатор Paint) - не нужно создавать кучу классов с использованием MVC/MVVM/…, просто хардкодьте все в Представлении.
❌ Это правило кажется слишком радикальным и не учитывает преимущества использования шаблонов MVC или MVVM для разработки пользовательского интерфейса (UI). Эти шаблоны помогают отделить логику приложения от UI, что упрощает тестирование, поддержку и расширение кода. Эти шаблоны также позволяют создавать более модульные, гибкие и переиспользуемые компоненты UI. Хардкодинг всего в представлении может привести к нарушению принципа DRY (Don’t Repeat Yourself), затруднить изменение или замену UI и сделать код менее читаемым и поддерживаемым. Использование MVC или MVVM не обязательно означает создание кучи классов, если это не нужно для задачи или проекта. Использование MVC или MVVM должно быть обосновано требованиями и контекстом приложения.
Большие методы - это норма, просто перестань думать об этом, выпей успокоительного.
❌ Это правило кажется очень плохим советом. Большие методы могут быть очень трудными для понимания, тестирования и отладки. Они также могут нарушать принцип единой ответственности и принцип открытости/закрытости. Большие методы должны быть разбиты на более мелкие и атомарные методы, которые делают одну вещь и делают ее хорошо.
Нет смысла «превращать ваш код в абстрактный мусор» для модульного тестирования. Обычно ты не оставляешь дверь открытой для удобства ФБР.
❌ Это правило также кажется плохим советом. Модульное тестирование - это важный инструмент для проверки качества и функциональности кода. Оно помогает обнаруживать и исправлять ошибки, предотвращать регрессии и улучшать дизайн кода. Модульное тестирование не должно быть восприниматься как угроза или ненужная нагрузка. Оно должно быть частью процесса разработки и поддержки кода.
Прежде чем приступить к реализации «Нового Классного Метода Разработки», который «Решает Все Проблемы», вспомните предыдущие, которые теперь объявлены мусором. Новый подход неизбежно постигнет та же участь. Возможно, вам стоит исправить какой-либо баг или сходить к психологу.
✔️ [BASED] Это правило может быть полезным напоминанием о том, что не существует серебряной пули в программировании. Новые методы разработки могут быть привлекательными и обещающими, но они также могут иметь свои недостатки и ограничения. Прежде чем принимать новый подход, стоит изучить его достоинства и недостатки, сравнить его с альтернативами и оценить его пригодность для конкретной задачи или проекта. Также стоит учитывать обратную совместимость и переходные затраты при смене подхода.
Если у Сlass только один метод — это мусор, используйте обычную функцию.
✔️ Это правило может быть верным в некоторых языках программирования, но не во всех. В некоторых языках, таких как Java или C#, классы являются основной единицей организации кода и не могут быть заменены функциями. В других языках, таких как Python или Ruby, функции могут быть определены вне классов и использоваться как объекты первого класса. В этих языках использование функций может быть предпочтительнее использования классов с одним методом, если это не нарушает логику или структуру программы.
Используйте ручное тестирование там, где можно обойтись без автотестов.
✔️ [BASED] Это правило может быть обосновано тем, что ручное тестирование может быть более дешевым, быстрым или эффективным в некоторых случаях. Однако ручное тестирование также имеет свои недостатки, такие как человеческий фактор, неповторяемость и низкая масштабируемость. Автоматическое тестирование может быть более надежным, точным и полным в проверке кода. Автоматическое тестирование должно использоваться там, где оно дает больше выгоды, чем ручное.
ВСЕГДА вручную тестируйте представление. Настоящих проблем и регрессий автотесты здесь не найдут.
❌ Это правило кажется неверным. Автоматическое тестирование представления может быть сложным и затратным, но оно также может быть полезным для обнаружения ошибок в UI или UX. Автоматическое тестирование представления может проверять такие аспекты, как функциональность элементов управления, соответствие стандартам доступности или дизайна, адаптивность к различным размерам экранов или устройствам и т.д… Автоматическое тестирование представления должно дополнять ручное тестирование, а не заменять его.
Когда Крутой Наставник По Архитектуре прийдет в ваш старый проект, сообщите ему НАЧАЛЬНЫЕ бизнес-требования и попросите его набросать архитектуру. Купите попкорн. Затем покажите ТЕКУЩИЕ бизнес-требования и попросите посмотреть, как они соотносятся с его архитектурой.
❌ Это правило кажется шуткой или сарказмом. Оно не помогает улучшить архитектуру или код проекта, а только создает конфликт или недоверие между разработчиками. Архитектура должна быть адаптивной и отражать текущие и будущие бизнес-требования. Архитектура также должна быть согласована и обсуждена с командой и заинтересованными сторонами.