Десять правил спокойной разработки

Введение

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

На помощь командам разработки приходят практики, методологии, подходы и четкие регламенты. Попробую сформулировать в виде десяти правил концепцию «спокойной» разработки. А она то вынудит использовать современные методологии разработки ПО. И заказчик спокоен, и нервы свои целы. Profit!

Проблема


В фильме «Пираты силиконовой долины» хорошо показаны замученные длительным марафоном разработчики Apple. А код уставшего разработчика часто неприятен даже ему самому на следующий день. Вывод — не писать уставший код. Да и производительность оставляет желать лучшего.

Но требования постоянно меняются, горизонты продукта размыты, заказчик не может внятно объяснить, что хочет. Для таких случаев и придумали Agile. Все родственные методологии позволяют гибко подстраиваться под изменяющиеся требования заказчика и выдерживать должный темп разработки без ущерба здоровью команды.

Перейдем к правилам «спокойной» разработки.

Правила

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

Заключение


Берегите здоровье, пишите качественный код, получайте удовольствие от работы. Будьте спокойны! Какие еще на Ваш взгляд правила стоит упомянуть?

0 комментариев

Оставить комментарий

Комментировать при помощи:
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.