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