Что такое TPM?
В 1951 году в японской промышленности появилась методология повышения качества, называвшаяся TPM (Total Productive Maintenance). Она была ориентирована прежде всего на сопровождение, а не на производство. Доктрина TPM базировалась на так называемых «принципах 5S». В сущности, принципы 5S представляют собой набор житейских правил. Кстати говоря, они также заложены в основу методологии Lean — другого модного течения на западной сцене, набирающего обороты и в программных кругах. Как указывает Дядюшка Боб в своем введении, хорошая практика программирования требует таких качеств, как сосредоточенность, присутствие духа и мышление. Проблемы не всегда решаются простым действием, максимальной загрузкой оборудования для производства в оптимальном темпе. Философия 5S состоит из следующих концепций:
- Сэйри (организация) — абсолютно необходимо знать, где что находится — и в этом помогают такие методы, как грамотный выбор имен (думаете, выбор имен идентификаторов неважен?).
- Сэйтон (аккуратность) — старая американская поговорка гласит: всему свое место, и все оказывается на своих местах (фрагмент кода должен находиться там, где читатель кода ожидает его найти, а если он находится где-то в другом месте, переработайте свой код и разместите его там, где ему положено быть).
- Сэйсо (чистка) — рабочее место должно быть свободно от висящих проводов, грязи, мусора и хлама (избавляйтесь от загромождения кода комментариями и закомментированными строками кода).
- Сэйкэцу (стандартизация) — группа достигает согласия по поводу того, как поддерживать чистоту на рабочем месте (единый стиль кодирования и набора правил в группах).
- Сюцукэ (дисциплина) — программист должен быть достаточно дисциплинированным, чтобы следовать правилам, он должен часто размышлять о своей работе и быть готовым к изменениям.
Чистый код
Безжалостно перерабатывайте свой код. А еще можно сделать следующий шаг, который считался новаторским в движении TPM более 50 лет назад: строить машины, изначально ориентированные на удобство сопровождения. Ваш код должен не только работать, но и хорошо читаться. Как нас учит Фред Брукс, крупные блоки программного кода стоит переписывать «с нуля» каждые семь лет или около того, чтобы они не обрастали мхом. Но может быть, временную константу Брукса стоит вывести на уровень недель, дней и часов вместо годов. Именно на этом уровне живут мелочи.
