Современный темп разработки ПО просто поражает своей скоростью.
Функционал всегда «нужен вчера». Зачем? Конкуренция — обойдут, обгонят.
Времени тестировать нет, надо отгружать функционал, надо, надо, надо.
На помощь командам разработки приходят практики, методологии, подходы и
четкие регламенты. Попробую сформулировать в виде десяти правил
концепцию «спокойной» разработки. А она то вынудит использовать
современные методологии разработки ПО. И заказчик спокоен, и нервы свои
целы. Profit!
Проблема
В фильме «Пираты силиконовой долины»
хорошо показаны замученные длительным марафоном разработчики Apple. А
код уставшего разработчика часто не приятен даже ему самому на следующий
день. Вывод — не писать уставший код. Да и производительность оставляет
желать лучшего.
Но требования постоянно меняются, горизонты продукта размыты, заказчик
не может внятно объяснить, что хочет. Для таких случаев и придумали Agile.
Все родственные методологии позволяют гибко подстраиваться под
изменяющиеся требования заказчика и выдерживать должный темп разработки
без ущерба здоровью команды.
Перейдем к правилам «спокойной» разработки.
Правила
Срочных задач не бывает, бывают приоритеты
Если задача имеет фатальный приоритет, то о ней надо было думать еще
неделю назад. Явная ошибка планирования. Либо был проигнорирован пункт 9
и «хомяк» грозится откусить пол руки;
Приступай к задаче после полного ее понимания
Типичная ошибка в больших системах. Что-то сделал, как-то проверил, получил нечто;
Наладь диалог с заказчиком
В любом проекте приходится искать компромиссы, расставлять приоритеты. Найти общий язык с заказчиком дорогого стоит;
Руководствуйся ТЗ
ТЗ будет идеальным при использовании пункта 3, поэтому проблем быть не
должно. А если функционального элемента нет, то и делать его не надо;
Используй только проверенный код
Любой код должен проходить серьезный цикл проверки перед поставкой
заказчику. Любые сторонние модули должны быть покрыты тестовым кодом и
хорошо проверены. Свой код надо проверять в обязательном порядке, без
исключений;
Рабочий день 8 часов
Очень полезный пункт. Порой надо себе об этом напоминать. Семья тоже
требует внимания, да и здоровье свое надо беречь. Если не хватает
времени, то смотри пункт 1.
Пиши документацию
Без документации нет функционала. К тому же, она экономит уйму времени,
потому что достаточно дать ссылку интересующемуся. Если документация не
понятна, устарела или имеет двойственную трактовку, то ее надо
актуализировать;
Держи код в порядке
Ужасный код должен переписываться, а не врастать в систему. Нет времени? Поставь TODO и исправь в ближайшую свободную минуту;
Заказчик не лабораторный хомячок для экспериментов
Есть такой подход «стрельба трассирующими».
Его можно использовать только в молодых и еще мало-функциональных
продуктах. Как только продукт переходит в фазу зрелости, заказчик
перестает мириться даже с самыми маленькими ошибками. Продукт должен
быть идеален. Иначе будет снижаться лояльность, а значит и уровень
оплаты работ;
Тестируй
Очень важный пункт. Если функция не имеет теста, то вообще ничего нельзя
сказать о ее работоспособности. ПО нестабильно. Яркий пример SQLite. Вот почему эта БД успешно работает в самых разных системах.
Заключение
Берегите здоровье, пишите качественный код, получайте удовольствие от
работы. Будьте спокойны! Какие еще на Ваш взгляд правила стоит
упомянуть?