Тимлид Разработки

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

Часто приходится слышать споры по поводу того, на что нужно обращать внимание в первую очередь при проверке кода. Одни смотрят на синтаксические конструкции, другие — на производительность алгоритмов, третьи — на архитектуру. Давайте попробуем разобраться с этим по-подробнее. Очевидно, что самым главным является соответствие кода цели поставленной задачи. Если код никак не обеспечивает результат, то и смысла его проверять совершенно отсутствует. Экспресс-тестирование является необходимым условием перед началом инспекции, которое упорно продолжают игнорировать...

Объём кома грязи в программном коде напрямую влияет на снижение скорости разработки, увеличение количества внеплановых дефектов, увеличивающееся отставание от графика работ и снижение мотивации у разработчиков. Но признавать это как вескую причину никто не торопится. Продолжают говорить о чём угодно — о плохих коммуникациях в проекте, о недостаточном планировании (задачи не двигаются, план смещается ежедневно и это нужно фиксировать). Казалось бы — почему? Начало истории в "Почему Code Review никому...

Многие проекты в АйТи часто бывают охвачены пожаром. Большой объём работ, короткие сроки вынуждают на чём-то экономить. И эту самую экономию в первую очередь обеспечивают за счёт снижения качества и его контроля. Поскольку пожар проектный и не думает угасать, разработчики быстро привыкают к такому положению вещей и забывают про то, как вообще можно работать качественно. Даже когда их никто не торопит. Что интересно - такое положение вещей достаточно выгодно. Сплочённые «пожарники» продолжают получать за свою отвагу «плюшки» и премии...

Типичный диалог, повторяющийся из совещания в совещание: - Нас подвели подрядчики! Они обещали, но не снова не сделали. Придётся делать ещё одно предупреждение и выставлять им штраф. - Мы запросили у подрядчиков срок выполнения. К пятнице они нам всё сделают… - Из-за подрядчиков у вас встала вся остальная работа! Сроки выполнения работ в области разработки программного обеспечения уменьшаются из года в год. Чтобы уложиться в эти сроки, приходится нанимать подрядчиков (аутсорсеров) на определённые части работ...