Документ обсуждает концепцию чистого кода, подчеркивая необходимость борьбы с его загрязнениями и описывая различные 'запахи' кода, которые сигнализируют о проблемах. Он также затрагивает важность компактности функций и классов, соблюдение принципа единственной ответственности, а также рекомендует использование тестов для рефакторинга. В заключение, представлены ключевые принципы, такие как закон Деметры, которые помогают улучшить качество программного обеспечения.

1. Запахи кода

2. Что есть чистый код?

3. Откуда берется плохой код?

4. Главный вопрос жизни, вселенной и тд тп Зачем?

5. Главный императив в программировании Борьба со сложностью

6. Поучительная история от гика Запись сессии программирования в текстовом редакторе Emacs Большую часть времени код читается

7. Чистый код по XP Все тесты проходят Нет дублирующегося кода Выражает намерения программиста Используется минимальное количество классов и методов

8. Пионеры в борьбе со злом

9. Собственно , о запахах Их много , очень много Низкоуровневые , высокоуровневые , на уровне методов , на уровне архитектуры Программирование больше состоит из эвристики , чем из детерминированных алгоритмов. Да поможет нам развивающееся с годами “ чувство кода ” .

10. Test Problem Рефакторинг без тестов – путь камикадзе Hard to Test code. TDD – думайте об этом как Test Driven Design Но и здесь есть запахи и свои подводные камни

11. Названия Удачные названия выстраивают в голове целостную картину о проекте Неудачные запутывают, вводят в заблуждение Придумать с первого раза хорошее имя методу или классу удается не всегда, но усилия на раздумия окупаются.

12. Длинные методы И дело вовсе не в размере Первое правило функций : они должны быть компактными Второе правило функций : они должны быть еще компактнее Третье правило : функция должна выполнять только одну операцию , она должна выполнять ее хорошо , и ничего другого она делать не должна.

13. Большой класс Большой объем ответственности , нарушение принципа SRP (Single Responsobility) Должна быть одна и только одна причина для изменения класса. Питательная среда для повторяющегося кода , хаоса и смерти

14. Симптомы Много атрибутов Не использует постоянно все переменные Большой коэффициент по выходу(много знает о других классах)

15. Длинный список параметров #Windows programmer NULL = None def CalculateAndPrintFactorialEx(dwNumber, hOutputDevice, lpLparam, lpWparam, lpsscSecurity, *dwReserved): if lpsscSecurity != NULL: return NULL #Not implemented dwResult = dwCounter = 1 while dwCounter <= dwNumber: dwResult *= dwCounter dwCounter += 1 hOutputDevice.write((dwResult)) hOutputDevice.write('\n') return 1 import sys CalculateAndPrintFactorialEx(6, sys.stdout, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL)

16. Туда же аргументы флаги render(true); render(boolean isSuite) renderForSuite()

17. Завистливые функции Методы класса больше интересуются не своим классов , а каким то чужим. Здесь же обитает анемичная модель.

18. Одержимость элементарными типами Стринговая типизация Передача id -шников по всему коду в методы

19. Операторы switch Полиморфизм от СИ разработчиков. Не всегда плохо , но повод задуматься есть Конечный автомат с небольшим числом состояний – хорошо.

20. Ленивый класс Класс перестал оправдывать свое существование в связи с чисткой в коде Дайте ему достойно умереть

21. Overdesign и теоретическая общность public class HelloWorld { public static void main(String[] args) { MessageBody mb = new MessageBody(); mb.configure(&quot;Hello World!&quot;); AbstractStrategyFactory asf = DefaultFactory.getInstance(); MessageStrategy strategy = asf.createStrategy(mb); mb.send(strategy); } }

22. Закон Деметры Или закон наименьшего знания. a.getB().method() – нехорошо , a.method() – лучше. Если хотите , чтобы собака побежала , глупо командовать ее ногами , лучше отдать команду собаке , она разберется со своими ногами сама.