Спорные, но актуальные принципы разработки

В нашей компании в процессе разработки принято придерживаться нескольких простых принципов. Возможно, кому-то они покажутся спорными, кому-то наивными, но, так же как и календарь, про который писал в прошлом году наш IT-директор (aka paulig), эти принципы — результат собственного опыта и ошибок. Кроме того, мы верим, что следование им даёт возможность решать задачи быстрее и эффективнее.

Зачем это было написано, если есть множество книжек по методологиям разработки (в том числе extreme programming, scrum, tdd), по программированию в целом и в частности, о том, «как пасти котов» и про «идеальный код»? Книг много, но разработчики, к несчастью, их читать не любят. Ну, ладно, любят, но не все. У них, мол, своя специфика. Квинтэссенция нужна. И проще, ближе, понятнее. Вот поэтому. И в жизни чаще всего приходится вспоминать, вернее, не забывать, именно те, которые перечислены ниже.

Посмотрев на историю страницы в нашем корпоративном twiki, я обратил внимание, что небольшой список с пояснениями, на основе которого сделана эта публикация, начал своё существование в 2006 году и неспешно дополнялся до 2011 года. Потом почему-то заглохло. Может быть, у кого-нибудь из читателей появится желание что-то добавить?

Простота


Если решение задачи оказывается слишком сложным, то с вероятностью 99% способ решения неверен.

Unix-way


По возможности, программа должна выполнять одно действие, но зато делать это хорошо.

Бритва Оккама


Кроме того, что не нужно умножать сущности, всегда помним о тезисе «это нам никогда не понадобится». И, скорее всего, оно не понадобится на самом деле.

Велосипед уже существует


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

Повторы


Если действие повторяется больше шести раз, то пора это действие тем или иным способом автоматизировать. Варианты: написать скрипт, создать класс, записать макрос.

Почему именно шесть раз? Потому что до шести внимание на это обычно не обращают.

Тесты


Любую реализацию нужно начинать с реализации тестов.
То есть, прежде чем начать писать программу, надо продумать как эту программу тестировать. И начать тестировать. Даже если нет реализации того, что тестируется. Тесты помогут понять, что нужно делать и как, а что — нет.

Подкустовные выползни


«Подкустовные выползни появляются на свет сразу. как следует из названия, они выползают из-под куста.» © Квартет И, «День радио».

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

Время


Отработать больше часов не значит сделать больше. Продуктивность и отработка времени — совершенно противоположные понятия.

Очевидное


Вы думаете, что кто-то умеет читать ваши мысли? Это ошибочное суждение. Телепатов в нашем несовершенном мире можно встретить только в зеркале. Поэтому, прежде чем что-то сделать, основываясь на своём представлении об информированности окружающих, нужно убедиться, что окружающие «в курсе». Или «в теме».

То есть, всегда необходимо информировать коллег о своём видении проекта и своей роли в нём. А то сами они не догадаются.

Коротким списком


  1. Простота
  2. Unix-way
  3. Бритва Оккама
  4. Велосипед существует
  5. Повторы — автоматизировать
  6. Сначала тесты
  7. Подкустовных выползней нет
  8. Не нужно отрабатывать время
  9. Мысли читать никто не умеет

© Habrahabr.ru