(C) Кодекс бережливого производства

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

Это было примерно в те же годы, когда я получил сертификат, а также когда я читал книгу, но в то время она не вызывала никаких сомнений. Это было до четвертого раза, когда я прочитал книгу, когда я готовил тренинг по Чистому Коду для некоторых разработчиков, которых я тренировал, когда на самом деле части головоломки бережливого и чистого кода начали складываться.

Начнем с определения Lean. В самом чистом смысле это методология, направленная на организацию деятельности человека с целью повышения ценности при одновременном устранении потерь.

Люди использовали много разных подходов к определению методологии бережливого производства, хотя они могут называться разными именами. Каждая из этих дисциплин уделяет определенное внимание принципам бережливого производства.

Чтобы организовать и быть дисциплинированным, вам сначала нужно увидеть то, что вы хотите организовать, и следовать дисциплине. А поскольку мы говорим о Коде, когда вы его видите, вы на самом деле читаете его. Мы продолжим это через минуту.

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

Когда вы начинаете убирать свою комнату, вы понимаете, что первый шаг к эффективной уборке - это сначала рассортировать весь беспорядок, положить на одну сторону видеоигры, на другую - журналы, на другую - игрушки и т. Д. назначьте место для каждой отсортированной группы. Теперь вы можете легче чистить каждую вещь (сияние). Наконец, вы понимаете, что легче создать набор правил (стандартизировать) о том, как следует обращаться с вещами в вашей комнате, чтобы поддерживать ее (поддерживать) в чистоте, чтобы вы могли быстро выйти и поиграть, не прибираясь. вверх первым.

Это хорошо известно как методология 5, и она идеально согласуется с нашей моделью кода c (l) ean.

5’s is:

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

Вот как это вписывается в Чистый код:

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

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

Теперь давайте упомянем, почему чистый код действительно важен:

  • Более удобный в сопровождении код.
  • Стройте устойчивый бизнес
  • Это заставляет вас выглядеть и быть более профессиональным.
  • Легко читать и понимать.
  • Повысить продуктивность.
  • Избегайте циклов редизайна.
  • Делайте людей счастливыми.

«Бог в деталях», архитектор: Людвиг Мис ван дер Роэ

Как мы упоминали ранее, бережливое производство - это методология, набор дисциплин, цель которых - организовать работу, чтобы приносить больше пользы при одновременном устранении потерь. Но вы не можете организовывать и дисциплинировать то, чего не видите, а чтобы действительно увидеть Код, это должно быть читаемым. Вы не можете улучшить то, что не видите (читаете). Итак, давайте начнем с 1-го столпа C (L) Ean Code.

ЧТЕНИЕ

Это идеальное определение удобочитаемости:

Ясность.- «, если вы хотите работать быстро, если вы хотите сделать быстро, если вы хотите, чтобы ваш код было легко писать, сделайте его легко читаемым »- Роберт К. Мартин

Простота. Не переусердствуйте.

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

Значимые имена:

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

Соглашения об именах:

✓ ОБЯЗАТЕЛЬНО выбирайте легко читаемые имена идентификаторов.

✓ ДЕЙСТВИТЕЛЬНО отдавайте предпочтение удобочитаемости, а не краткости.

✓ ОБЯЗАТЕЛЬНО используйте семантически интересные имена, а не специфичные для языка ключевые слова для имен типов. Например, GetLength - лучшее имя, чем GetInt.

X НЕ используйте сокращения или сокращения как часть имен идентификаторов. Например, используйте GetWindow, а не GetWin.

X ИЗБЕГАЙТЕ использования идентификаторов, которые конфликтуют с ключевыми словами широко используемых языков программирования.

X НЕ используйте какие-либо сокращения, которые не являются общепринятыми, и даже если они есть, только при необходимости.

Малые методы:

  • Метод должен быть единым тестируемым модулем, выполняющим только одну задачу.
  • Храните от 10 до 15 строк кода.
  • Если ваш метод более крупный, то, вероятно, он делает много вещей, за которые они не отвечают.
  • Предпочитаю «досрочное возвращение».

Теперь перейдем ко второму столпу C (L) Ean Code.

ОРГАНИЗАЦИЯ

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

3 С:

Наконец, у нас есть 3-й столп C (L) ean Code.

ДИСЦИПЛИНА

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

«Ваша позиция, а не ваши способности, будет определять вашу высоту». - Зиг Зиглар

Дисциплина - это набор стандартов, правил, эвристик, принципов, практик и т. Д. Мы определим те из них, которые я считаю лучшими для соблюдения вашего кода C (L):

  • Правило бойскаутов. Оставьте палаточный лагерь чище, чем вы его нашли. Каждый раз, когда вы пишете код, давайте немного очистим старый код, неважно, если это код, который пишет кто-то другой. Сделайте небольшой вклад, немного очистив все вокруг. Просто не сходите с ума, много убирая, иначе вы можете что-нибудь сломать.
  • Сделайте это максимально простым. Помните, не переусердствуйте; не убивайте муху молотком.
  • ЯГНИ (Оно тебе не понадобится). Не создавайте заводской шаблон проектирования, думая, что в будущем вам, возможно, потребуется добавить дополнительные функции. Дождитесь этого момента и создайте фабрику, но не раньше.
  • Принцип наименьшего удивления. Давайте найдем для каждой вещи место и поместим его там, где другие разработчики ожидают большего. Положите его туда, где он меньше всего может удивить, когда кто-нибудь его найдет.
  • «Если не тестировали, значит, он сломан»
    Напишите много тестов, особенно модульных, иначе вы пожалеете об этом.
  • Классы и функции должны быть небольшими и подчиняться принципу единой ответственности (SRP)
    . Функции не должны содержать более 4 строк, а классы - не более 100 строк. Да, вы правильно прочитали. Они также должны делать одно и только одно.
  • Функции не должны иметь побочных эффектов
    Побочные эффекты (например, изменение входного аргумента) - зло. Убедитесь, что в вашем коде их нет. Укажите это явно в контрактах функций, где это возможно (например, передайте собственные типы или объекты, у которых нет установщиков).
  • СУХОЙ. Избегайте дублирования кода, абстрагируя общие вещи и помещая их в одном месте.

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

Заключение

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

Спасибо, что дочитали до конца, я очень признателен.

Если вам это нравится, пожалуйста, следуйте за мной.