Что такое TPM?

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

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

Чистый код

Безжалостно перерабатывайте свой код . А еще можно сделать следующий шаг, который считался новаторским в движении TPM более 50 лет назад: строить машины, изначально ориентированные на удобство сопровождения . Ваш код должен не только работать, но и хорошо читаться . Как нас учит Фред Брукс, крупные блоки программного кода стоит переписывать «с нуля» каждые семь лет или около того, чтобы они не обрастали мхом . Но может быть, временную константу Брукса стоит вывести на уровень недель, дней и часов вместо годов . Именно на этом уровне живут мелочи.