Когда я только начинал свою карьеру, я думал, что мне не повезло, потому что каждый проект, в котором я участвовал, был полным дерьмом. Пользовательский интерфейс может выглядеть мило, но весь бэкэнд всегда был смесью чьего-то преждевременного восторга от совершенно нового фреймворка, различных доказательств концепций и устаревших громоздких «лучших практик». Я работал в частном и государственном секторах, организациях с небольшим количеством людей и корпорациях, я заключал короткие контракты и работал на постоянной основе в течение нескольких лет — без разницы, как только проект вырастает до определенного размера, он начинается медленно, постепенно трансформируясь. к монстру.
Это вообще проблема?
Проблема огромная, она затрагивает всех заинтересованных сторон. С точки зрения бизнеса разработка каждой новой функции обходится дорого и опасно, поскольку никто толком не понимает, как все работает. Каждая неудача влияет на репутацию и увеличивает потери в бизнесе. Для пользователя неприятно застрять с зависшим экраном в ситуации ограниченного времени или получить неописательную ошибку.
Быть начинающим разработчиком в подобном проекте непросто, поскольку для того, чтобы начать работать продуктивно, требуются недели. Никто не захочет работать в грязной комнате, полной пауков, жуков и той отвратительной гниющей массы в углу, о которой все знают, но навсегда игнорируют. Вот как это чувствуется!
Это почему?
Мы все еще спорим об этом, разработка программного обеспечения — относительно новая отрасль, которая в последнее время получила огромный импульс. Нам нужно больше программистов, а также очень легко начать программировать, честно говоря, каждый день появляется 5 новых руководств по любому возможному языку программирования, которые производят как минимум 5 новых разработчиков «я думаю, я могу кодировать» в день. Давайте рассмотрим самые популярные сбои в производстве программного обеспечения и способы их устранения.
Технические люди
Я не собираюсь говорить вам, что большинство разработчиков не так уж хороши (я действительно думаю, что большинство из них в порядке, они просто находятся на разных этапах своей карьеры), однако рекрутинг — это огромная проблема. Обычно я беру интервью у разработчиков на поздних стадиях их процесса найма и редко имею дело с кем-то совершенно потусторонним. Хотя время от времени я встречаю людей с правильным резюме, в которых много шума и сексуальных слов, но которые не могут решить проблему FizzBuzz. Даже низкоуровневые технические навыки не являются большой проблемой, но неспособность четко излагать идеи и нежелание изучать новые навыки и концепции делают разработчика непригодным для какой-либо работы, кроме как быть программистом.
кодовая обезьяна
Программист, который на самом деле не участвует ни в каких аспектах концептуальной или дизайнерской работы, а просто пишет код в соответствии с заданными спецификациями. "Словарь городского сленга"
К сожалению, эти кодеры пишут некачественный код, игнорируют модульное тестирование и часто занимаются программированием вуду.
программирование вуду
Использование кода или техники программирования (чаще всего сложной) без понимания того, что она на самом деле делает и почему решает ту или иную проблему. "Словарь городского сленга"
Как смягчить?
Я знаю, что нанять разработчика сложно, это редкие и неуловимые животные. Но сначала посмотрите на личность, спросите, как она поддерживает свои навыки в актуальном состоянии, работает ли она над открытым исходным кодом или личным проектом. Любой признак программирования в нерабочее время является очень положительным признаком достойного программиста, а также посещения митапов или профессиональных конференций. Кроме того, дайте ей простое кодовое ката, я обычно использую задачу Супермаркет, сажусь рядом с ней и прошу устно объяснить, что происходит у нее в голове. Обратите внимание, как она использует свои инструменты, пишет тесты, свои базовые математические навыки. Ничего страшного, если вам нужно дать ей пару намеков, чтобы вы могли видеть, способна ли она следовать вашим идеям. Надеюсь, вы сможете найти разработчиков, которые могут писать простой, поддерживаемый и хорошо протестированный код.
Не технические люди
Бизнес есть бизнес, однако я видел довольно много бизнес-аналитиков, которые не могут объяснить фичу, владельцев продуктов с минимальными знаниями о продукте или отрасли и менеджеров проектов, не имеющих понятия, чем производство программного обеспечения отличается от производства дверей. Поскольку я не совсем деловой человек, я не собираюсь давать здесь какие-либо рекомендации. Когда я встречаю некомпетентных людей, я пытаюсь их просветить, если это не работает, я избавляюсь от них.
Природа разработки программного обеспечения
Да, разработка программного обеспечения — достаточно новая человеческая деятельность. Стандарты и парадигмы возникают, умирают и снова меняются. Зависимость компонентов неуловима, документация никогда не обновляется. Никто на самом деле не знает, нужно ли жестко кодировать или не стоит. Должны ли мы создавать кучу управляемых событиями микросервисов без какой-либо структуры, или монолит все же приемлем? Следовательно, вы никогда не знаете, что делать, но все же можете использовать «обоснованное предположение».
Как смягчить?
- Набор коротких модульных тестов позволит вам провести безопасный рефакторинг, отловить ошибки на ранних стадиях разработки и предоставить исчерпывающую низкоуровневую документацию о том, как должен работать код.
- Несколько интеграционных тестов дают вам уверенность в доставке
- Частая поставка небольшими партиями помогает избежать больших сбоев
- Автоматизация развертывания убережет вас от человеческих ошибок и ускорит доставку
- Предоставление людям достаточно времени для творчества, написания тестов и больше размышлений, а не кодирования.
Технический долг
Технический долг — штука интересная, он растет с каждым днем (даже по воскресеньям, так как некоторые разработчики любят тайком слить-другой перед сном) и им нужно активно управлять, иначе он накапливается. Я видел как минимум несколько проектов, рухнувших под невыносимой тяжестью технического долга.
Почему это так опасно? Это увеличивает энтропию программного обеспечения (он же сложность), затрудняет внесение изменений и раздражает разработчиков и деловых людей. Представьте, что вам внезапно сказали, что разработчикам нужна пара недель на рефакторинг, поэтому никаких новых функций не будет.
Как смягчить
- Обзор кода — позвольте другому разработчику взглянуть на ваш код.
- Срезая углы в условиях цейтнота, создайте тикет и впишите его в следующий спринт, пока память свежа. Выделите до 20 % времени спринта на очистку кода и выполнение технических задач.
Вывод
Поскольку существует множество причин, по которым мастерство разработки программного обеспечения может пойти не так, решение должно заключаться в наборе практик и процедур. Кроме того, я хотел бы отметить, что, поскольку кодовая база — это живое существо, которое растет с каждым днем, можно только смягчить мутацию монстра и никогда не предотвратить ее.
