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

в 20:05, , рубрики: здоровье, концепция, мотивация, правила, список, метки: , , , ,

Введение

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

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

Проблема

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

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

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

Правила

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

Заключение

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

Автор: VaiMR

Источник

Поделиться

* - обязательные к заполнению поля