Главная

Clean Code.

Методология Lean

Поделиться:
 

11+

Я начал работать инженером по разработке ПО в том же году (2007), когда дядя Боб выпустил 1-е издание своей замечательной книги «Clean Code». В те дни я работал в промышленной компании и, поскольку это была производственная компания, в ней повсеместно использовали методологию Lean. Как-то я решил побольше узнать об этом и получить сертификат «Зеленый пояс шести сигм».

Когда я получал сертификат по Lean, я параллельно читал книгу “Clean Code”, правда в тот момент она не произвела на меня какого-то особого впечатления. Однако прошло время и когда я, готовясь к тренингу для разработчиков, в четвертый раз перечитывал эту книгу, все понемногу начало складываться. Я начал замечать, что принципы Lean и Clean Code взаимосвязаны.

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

Итак, чтобы что-либо организовать и быть дисциплинированным в отношении этого, сперва нужно четко определить все понятия и конечную цель. Что же такое Clean? Давайте вернемся во времена, когда мама говорила (или до сих пор говорит): “Не, дорогой, сперва уберись в своей комнате, а потом можешь идти на улицу играть с друзьями” (да, я жил еще в те времена, когда с друзьями играли на улице, а не в Интернете).

Когда вы начинали убираться в комнате, к вам приходило понимание, что для того, чтобы уборка была эффективной, нужно сначала все отсортировать(Set) — положить в одну сторону видеоигры, в другую — журналы, игрушки и т. д. А потом вы неосознанно определяли место для каждой группы отсортированных вещей и приступали к делу(Set in Order).

В итоге процесс уборки шел значительно быстрее, ибо вы не заморачивались над тем, что и куда положить(Shine). В какой-то момент вы осознали, что проще установить набор правил(Standardize), руководствуясь которыми вы сможете поддерживать чистоту в комнате и таким образом быстрее выходить на улицу, не прибегая к чистке(Sustain).
Этот подход включает в себя 5 принципов Lean, а также отлично согласуется с концепцией чистого кода.

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

Как это связанно с Чистым Кодом?

По правде говоря, каждый может стать программистом …
Сегодня, когда существует множество инструментов, хороших фреймворков и языков, каждый может пройти бесплатный туториал и написать код, понятный компьютеру. Написать код, понятный компьютеру, легко, написать код, понятный человеку — сложно.

Давайте будем честными: вы не можете называть себя инженером, если вы не пишете Чистый код. Ну… как минимум хорошим инженером точно… Трудно представить хорошего доктора, в кабинете которого грязно — книги разбросаны на полу, на столе мусор, а одежда доктора неопрятная. Хотели бы вы, чтобы вас лечил такой доктор?

Почему же так важно писать чистый код?
• Его легко поддерживать.
• Он устойчив к ошибкам.
• Код отражает ваши профессиональные качества.
• Легко читается и интуитивно понятен.
• Повышает продуктивность.
• Не надо ничего перепроектировать.
• Чистый код делает людей счастливыми.

«Бог в деталях»

Мис ван дер Роэ, Людвиг

Как я упоминал ранее, Lean — это методология, целью которой является обеспечение создания большей ценности при меньших затратах. Однако вы не можете применить эту методологию к тому, что вы не видите. Именно по этой причине код должен быть читабельным. Улучшить то, что нельзя прочитать и разобрать, — невозможно. Итак, давайте остановимся у первого правила Чистого Кода:

Читабельность.

Есть отличное определение выражению «читабельность кода»:

Если вы хотите быстро участвовать в проекте, если вы хотите, чтобы ваш код был поддерживаемым, сделайте так, чтобы его было легко читать.

Простота: знайте во всем меру.
Лаконичность: старайтесь использовать наименьшее количество ресурсов для получения наилучших результатов.

Советы по именованию:
• Имена переменных и функций, раскрывающие намерения (почему это существует, что оно делает и как оно используется)
• Используйте глаголы при именовании функций и существительные для классов и атрибутов.
• Переменная должна представлять то значение, для которого она была создана. (избегайте var x, вместо этого используйте var CustomersIndex)

Правила именования:
1) Выбирайте легко произносимые имена.
2) Читабельность важнее краткости.
3) Используйте семантически интересные имена. Не стоит использовать ключевые слова в именах. GetLength — лучшее имя, чем GetInt.
4) Не используйте двусмысленные сокращения. Используйте GetWindow, а не GetWin.
5) Избегайте использования имен, конфликтующих с ключевыми словами широко используемых языков программирования.
6) Используйте акронимы (малоизвестные слова) только при очень большой необходимости.

Методы:
• Метод должен выполнять только одну конкретную задачу.
• Приемлемый размер метода 10–15 строк. Если ваш метод больше, то, вероятно, он выполняет много лишних действий.
• Отдавайте предпочтение «Раннему возврату» (с англ. Early return).

Теперь давайте перейдем ко второму правилу Чистого кода.

Организация
Поскольку в этой статье мы больше говорим о коде, мы сосредоточимся именно на работе программистов, а они, в свою очередь, имеют дело с классами. Архитекторы работают на более высоком уровне, который не совсем связан с кодом — они больше работают с проектами или организациями (так называемыми доменами, микросервисами и т. д.).
Окей, классы…

И теперь переходим к третьему правилу Чистого кода.

Дисциплина
• Компетентность = Дисциплина + Навык.
• Ответственность превосходит любое количество лет опыта.
• Ответственность заразительна. Если вы ответственно подходите к делу, люди вокруг вас также стремятся к этому.
Ваше отношение к делу, а не ваши способности, будут определять высоту вашего полета.

Дисциплина — это набор стандартов, правил, принципов, практик и т. д. Мы определим те, которые, на мой взгляд, являются лучшими при написании чистого кода:
• Бойскаутское правило. Оставьте лагерь чище, чем вы его нашли. Каждый раз, когда вы садитесь за код, делайте его немного чище, чем он был до этого, и не имеет значения, кто автор изменяемого кода. Просто делайте свой небольшой вклад в общее дело — чистоту кода. Однако не увлекайтесь. Если вы будете вносить много изменений, вы можете что-то сломать.
• Не усложняйте. Не стоит убивать муху молотком.
• YAGNI (you ain`t gonna need it). Не пишите шаблон фабрики с расчетом на то, что он может вам когда-то понадобиться в будущем. Дождитесь того момента, когда это будет явной необходимостью.
• Принцип Наименьшего Сюрприза. Давайте найдем свое место для каждой вещи и поместим ее там, где другие разработчики ожидают этого больше всего. Помещайте новый функционал туда, где он вряд ли вызовет удивление.
«Если что-либо не протестировано, оно работает неправильно». Пишите много тестов, особенно юнит тестов. Вы не пожалеете об этом.
• Классы и функции должны быть небольшими и соответствовать принципу единственности ответственности (SRP — single responsibility principle). Функции должны быть не более 4 строк, а классы — не более 100 строк. Они также должны делать только то, что запланировано, и ни каплей больше.
• Функции не должны иметь побочных эффектов. Побочные эффекты (например, изменение входного аргумента) — это зло. Убедитесь в том, что ваши функции не подвержены этому злу. Указывайте все явно (например, передавайте нативные типы или объекты, которые не имеют сеттеров).
• DRY (do not repeat yourself). Избегайте дублирования кода путем абстрагирования общих вещей и размещения их в одном месте.

• Позже равно никогда. Вы пишете // TODO, но в глубине души знаете, что никогда этого не сделаете. Хорошей практикой является добавление рабочего элемента в очередь каждый раз, когда вы пишете TODO.
• Правило четырёх проверок кода. Чтобы быть полностью уверенным в том, что вы следуете всем стандартам, передовым методикам и т. д., вы всегда должны давать свой код на проверку четырем людям: любому разработчику, другу-разработчику, вашему техлиду. Свой код надо проверять точно также, как и чужой.
• Инструменты анализа кода. Такие инструменты, как ResharperIDE Enterprise EditionSonarQubeSpotBugs, могут помочь вам придерживаться наиболее распространенных дисциплин в коде.

Заключение.

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

11+