Про одну из самых главных (если не самую главную) причин провалов, фейлов, да и просто, кривизны множества современных проектов. Я несколько раз в месяц общаюсь с небольшими командами разработчиков, маленькими стартапами, и вот типичные ошибочные ситуации, которые есть прямое следствие этой главной причины.
Во-первых, я первым делом смотрю и запускаю тесты, в первую очередь юнит-тесты. Если они конечно есть 😁
Если нету, то на этом консультация заканчивается с очевидной рекомендацией, по моей схеме 1-2-4-8- (сперва надо сделать одну самую важную вещь; потом две менее важные; и т. д.).
Но как правило, модульные тесты есть, и их достаточно много (обычно сотни-тысячи). Так вот, я беру например из местного гитлаба текущую версию проекта, которая пока пилится (не выложена в прод), запускаю все юнит-тесты – и, типичный системный баг – они все проходят! Это поразительно.
Зачем тогда меня вообще позвали?
Если проект в активной разработке, многие юнит-тесты не должны проходить.
Поймите меня правильно. Версия проекта, выкатываемая в продакшен, в промышленную эксплуатацию, должна конечно проходить все связанные с ней тесты.
Но пока ведётся разработка, пресловутый «спринт», существенная часть кода находится в отлаживаемом состоянии, и практически всегда находится (обязана находиться) куча неудачных тестов, если тестирование, да и сам процесс разработки, организованы правильно.
Я просматриваю случайные тесты, и снова часто оказывается, что они сами по себе весьма плохо сделаны, но самое главное, что в них часто почти ничего всерьёз не тестируется :)
Тысячи тестов, и фактически все они бывают бесполезны.
Программисты пишут их для галочки, для метрик, а тимлид следит лишь за общей статистикой.
=
Правильное понимание юнит-тестов – это понимание их не столько как тесты, а прежде всего как абсолютные проектные спецификации, которые никогда не врут.
=
Во-вторых, ребята, которым я рекомендую, чтобы все программисты обязательно ежедневно деплоили свою работу в общий бранч, мержились бы с мастером «as is», сталкиваются с другой типичной проблемой. Да, многие юнит-тесты наконец начинают ломаться (и это хорошо! это признак, что код активно меняется), однако у разных программистов теперь не срабатывают совсем разные множества тестов :)
Типичная причина — крайне разрозненные (особенно оптимизирующие) настройки компиляторов у каждого разработчика на его локальном рабочем месте. И разбирательства с ними обычно пожирают уйму ресурсов.
Как этот организационный баг глобально пофиксить, тоже вроде бы очевидно — и тоже эти элементарные вещи приходится объяснять буквально на пальцах.
Я для этого составил специальные организационные протоколы, которые в частности исключают такую типичную ситуацию, когда в течение недели каждый разраб пилит свои тикеты в отдельном бранче, а потом — чаще всего в пятницу :), десяток человек пытается смержиться с мастером, и после каждого n-го мержа оказывается, что у предыдущих 1..n-1 человек всё почему-то поломалось :) И возникает ситуация, требующая учёта n! случаев.
=
При том, что в каждой команде я встречаю ребят, которые значительно умнее меня, и гораздо лучше подкованы технически в своих стеках и фреймворках, и тимлиды очень адекватны, но у них у всех есть одна классическая проблема.
Сеньор не должен работать _в_ проекте.
Сеньор должен работать _над_ проектом.
Сеньор не должен втягиваться в текучку, в оперативку, во всю эту мышиную возню. Он должен мыслить о проекте стратегически – как повышать надёжность, масштабируемость, безопасность, гибкость всей системы в целом.
Он должен смотреть на проект максимально объективно и отстранённо, как это делаю я, когда смотрю на чужой проэкт равнодушно :) и поэтому вижу в нём множество слепых пятен. Но так почти никто в командах не умеет, потому что излишне эмоционально вовлечены в свои проекты. С одной стороны, это плюс, но с другой, и минус.
=
В-третьих, я начинаю смотреть историю комитов, прежде всего как развивались классы проектирования (классы реализации и классы анализа обычно более-менее аккуратно делаются), и вот тут наступает полный трэш.
В плане архитектурного дизайна практически всегда царит полный хаос. Проектировщики (в кавычках) понятия не имеют, чем они занимаются, и что вообще происходит :) Комитят иногда по десятку раз в день, подчас переписывая 50% кода, просто пытаясь хоть как-то склеить приляпками и удержать костылями постоянно разваливающееся здание проекта…
Ещё в советское время у программистов на ЕС ЭВМ была такая шутка: мы делаем свои системы, как братья Райт свои самолёты: собирают конструкцию, запускают в небо… ждут, когда развалится, и начинают по новой. С тех пор всё стало лишь печальнее.
Типа, закомитил – посмотрел, что поломалось – пошёл фиксить. Этакая «итеративная» модель разработки 😂 Словно понятия "дизайн проекта" просто не существует.
Но при этом, вроде бы, и паттерны проектирования активно применяются, и код аккуратный… Так в чём главная засада?
=
Я постоянно вижу много примеров классического проектного фейла – даже не в том смысле, что ничего не получилось, а в том, что сроки и бюджет перерасходуются в разы, а то и на порядок.
Главная причина этого всего – отсутствие научного подхода к созданию сложных систем.
Менеджеры принуждают разработчиков к созданию на коленке по сути чего-то хоть как-то работающего по обрывочным и противоречивым требованиям, пока в конце концов не становится понятно, а как же всё это должно работать правильно. Но при этом система уже сдана в промышленную эксплуатацию :) Абсолютно хрупкая система, которая представляет собой идеальный пример теории хаоса. Бабочка, похлопавшая крылышками бяк-бяк-бяк у нас в Ховрино, полностью рушит систему, запущенную в амазоновском облаке в Кейптауне.
Недаром говорят, что систему надо переписать три раза, и только на третий раз она получится так хорошо, как хотелось бы исходно.
Дело в том, что идеальная механическая, «в лоб», калибровка системы с множеством параметров приводит к тому, что даже микроскопические отклонения от найденного калибровочного диапазона дают жутко некорректные результаты. Чем точнее калибровка, тем сильнее будет отклонение при её нарушении.
А нужна не калибровка, наоборот, нужна гибкость.
=
И вот раз научные принципы (или хотя бы качественные инженерные подходы), лежащие в основе проектного дизайна ИТ-системы, плохо изучены, вы получите один из двух результатов (а может быть, и оба):
- огромные задержки в сроках работ, и/или
- систему, которая просто не работает хорошо.
