Семь смертных грехов разработки ПО

Решил перепечатать интересную и актуальную на мой взгляд статью. Любой профессиональный программист смог бы сформулировать похожий список, и он, как нельзя лучше описывает ошибки современной разработки. Такое ощущение, что каждая компания и индивид проходят через все эти пункты. В большей степени «грешим» из-за непонимания. Пункты 4-7, для молодой компании могут казаться бесполезным и дорогим занятием. Пункты 2-3 говорят о несовершенстве менеджмента, это типичная ситуация в командах где решения принимают люди, далекие от ИТ.

Первый пункт — проблема больше индивидуальная. На своем опыте могу сказать, что недостаточно замечать за собой такую проблему, важно не отходить от поставленного курса непосредственно во время написания кода. Я часто впадаю в подобную паранойю совершенства, а через пару недель ужасаюсь от количества велосипедов.

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

1. Страсть (избыток проектирования)

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

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

Но то, что хорошо выглядит на бумаге, не всегда работает на практике. И то, что вы можете что-то делать, вовсе не означает, что вы обязаны это делать. Гуру программирования Джоэл Спольски говорит об этом так: «Выпуск продукта – это фича. Очень важная фича. И ваш продукт обязан ею обладать». Программисты, которые занимаются фетишизмом своих инструментов разработки, неминуемо упускают из виду этот момент, и даже простейший из проектов может погрязнуть в аду разработки. Сопротивляйтесь этим низменным импульсам и придерживайтесь тех решений, которые действительно работают.

2. Чревоугодие (неспособность к рефакторингу)

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

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

Вместо того чтобы поглощать новые фичи тарелку за тарелкой, удерживайте себя. Оценивайте существующий код на предмет качества и «поддерживаемости». Сделайте рефакторинг кода отдельной строкой в бюджете каждой новой итерации проекта. Возможно, клиенты будут видеть только новые возможности в каждом релизе, но со временем они будут вам благодарны за то, что ваш продукт не оброс жиром.

3. Жадность (соревнование между командами разработки)

Излишнее желание власти и силы – как еще можно объяснить мотивы тех программистов, которые соревнуются со своими коллегами? Начинается все с того, что некоторые команды просто исключают из списков email рассылки, потом митинги проходят за закрытыми дверями. Ну а дальше одна из команд пишет библиотеку, которая повторно реализует большую часть той функциональности, которая до этого уже была реализована другой командой.

Команды программистов редко изобретают велосипед по злому умыслу, но недостаток четко определенных целей может легко привести к намного более широкой сфере ответственности, чем в действительности нужно. Результатом этого является избыточный, неподдерживаемый код, не говоря уже о потерях с точки зрения бюджета проекта вследствие дублирования разработки. Одной из важнейших задач управления проектом по разработке ПО должно стать осознание каждой из команд того, чем занимаются другие команды, и понимание общей цели. Вашим слоганом должны стать слова: «Делитесь всем поровну».

4. Лень (отсутствие проверки входных данных)

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

Современные языки программирования предоставляют большое количество инструментов, которые позволяют избежать этой ошибки, но ими нужно еще правильно пользоваться. Помните, что веб-форма, использующая JavaScript для проверки входных данных, может быть легко обойдена выключением JavaScript’а в браузере, либо при доступе вообще без использования браузера. Проверка входных данных должна быть прошита в код вашего приложения, а не разбросана в UI. Все меньшее – просто лень.

5. Гнев (отсутствие практики комментировать код)

Какой поступок с вашей стороны может быть более враждебным по отношению к вашим коллегам, чем отсутствие комментариев в коде? Да, я знаю, знаю: хорошо написанный код лучше всякой документации. А знаете что? Те 2 метода, которые вы написали в 2 часа ночи в прошлый вторник, представляют собой не слишком хорошо написанный код. (А если вы являетесь хакером, который пишет на Perl, вы должны мне 9 раз спеть «Аве Мария»).

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

Но помните что, бессмысленные комментарии, равно как и излишнее словоизлияние, могут быть даже хуже полного отсутствия комментариев. Комментарии вроде «это не работает» или «ни в коем случае это не трогать!» не слишком полезны для других. Также бесполезны и излишние комментарии, объясняющие простые операции вроде инициализации переменных. Код лучше всего документирует то, что он делает; комментарии нужны для того, чтобы понять, зачем это нужно.

6. Зависть (не использование систем управления версиями)

Трудно поверить в то, что в 2011 году все еще существуют проекты, которые хранятся в виде группы папок на файловом сервере, ревностно охраняемой одним «хранителем». На компьютерах разработчиков по всему офису разбросаны копии этих папок, каждая немного отличающаяся от других, хотя никто точно не знает, чем именно.

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

7. Гордость (отсутствие юнит-тестирования)

Часто хочется похлопать себя по спине и поблагодарить за хорошо сделанную работу. Но откуда вы знаете, что она действительно хорошо сделана? Какие метрики вы используете?

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

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

Источник

Метки:разработка, деньги