Индустрия софтостроения. Индустрия?

Чем больше читаю книг о производстве - речь, конечно, не о беллетристике, а о популярных рассказах менеджеров и конструкторов -  тем больше недоумения, почему отличные практики, которые применяются в производстве материальных вещей, то ли не работают, то ли просто  игнорируются в software development.

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

Документация

У вас в отделе есть стандарт на описание программных интерфейсов? То есть, документ, или хотя бы четкое недокументированное соглашение о том, как писать такие документы? А не странно ли то, что такого стандарта нет в отрасли? Тут должно прозвучать слово "UML", но скажите честно, даже если вы им пользуетесь, насколько однозначно он позволяет описать именно вашу задачу?

Если зачастую не все интерфейсы и API строго задокументированы, то про алгоритмы и внутреннюю структуру говорить совсем грустно. Не один раз приходилось слышать: "возьми исходник, разберись".

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

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

Стандарты разработки

Почему стандартизация процесса, от КД до ОТК, от изготовления отдельных деталей до сборки в случае жележного производства считается благом, а во втором применяется лениво и редко? Индустрия производства ПО молодая, но почему не заимствуется опыт из других сфер производства?

Обилие вариантов синтаксиса среди языков программирования и само по себе вызывает изумление, но на гибкость синтаксиса языка   накладываются еще и изобретательно сочиненные во множестве Style Guide. Или, что еще хуже,  не накладываются совсем.

Так вот, запишите меня в сталинисты, но я не понимаю, почему давно не выработано 2-3 стандарта оформления текста программ для распространенных языков программирования, которые были бы обязательны к применению? Зачем эта игра в свободу?

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

"Железному" конструктору, наделавшем в детали ненужную кучу резьбовых отверстий тут же даст по мозгам технолог. После одного-двух раз выработается представление, что можно, а что нельзя проектировать и дальше все будет хорошо. А в софтостроении сделать god object, класс с описанием на пару сотен строк - так лишь пожурят, что неудобно, не полагается так.

Отсюда следующий пункт

Управление качеством

• Обсуждения функциональных спецификаций - случаются регулярно.
• Code review - случаются, но обычно ревю делает peer, того же уровня подготовки и мудрости, что и автор кода.
• Design review видел один единственный раз. Постмортем. Хотя при maintenance готового пакета основные проблемы упираются как раз в перепроектирование.
• Root cause analysis - бывает, но спонтанно.
• Usability тестирование - не видел. Слышал, что бывает у крупных софтостроителей, но в известных небольших командах на поток оно не поставлено.

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

Но это уже вопрос пункта под названием

Управление процессом

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

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

В результате неэффективность, неэффективность и неэффективность. Там, где могла бы быть нормальная потогонка. И там, где надо 10 быдлокодеров, пара продвинутых инженеров и один супергуру, нижняя позиция уже требует высшего образования.

И отсюда гордое: лучше наймем 3-х мегаумных программистов, чем 10 средних. Потом один мега уходит, второй попадает под staff reduction, оставшийся не вытягивает сроки релиза (так как надо обучить трех нанятых китайцев) и проект если и не загибается, то круто теряет позиции.

А еще одно следствие - специалиста, владеющего базовым набором навыков softdev найти очень тяжело, так что никто особо и не пытается. Еще раз: я про базовый набор, не о продвинутом уровне.

А набор, к примеру, такой (тут накладывается еще специфика моей отрасли, в БД-девелопменте ситуация чуть лучше):

• базовая методология OOD
• базовые принципы индустриального OOP
• TDD
• комментирование и документирование кода
• дизайн спецификации (UML)

Конструкторы, не знающие, что такое ЕСКД бывают? А программисты уровня проектировщика бывают.

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

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