Спорные, но актуальные принципы разработки
В нашей компании в процессе разработки принято придерживаться нескольких простых принципов. Возможно, кому-то они покажутся спорными, кому-то наивными, но, так же как и календарь, про который писал в прошлом году наш IT-директор (aka paulig), эти принципы — результат собственного опыта и ошибок. Кроме того, мы верим, что следование им даёт возможность решать задачи быстрее и эффективнее.
Зачем это было написано, если есть множество книжек по методологиям разработки (в том числе extreme programming, scrum, tdd), по программированию в целом и в частности, о том, «как пасти котов» и про «идеальный код»? Книг много, но разработчики, к несчастью, их читать не любят. Ну, ладно, любят, но не все. У них, мол, своя специфика. Квинтэссенция нужна. И проще, ближе, понятнее. Вот поэтому. И в жизни чаще всего приходится вспоминать, вернее, не забывать, именно те, которые перечислены ниже.
Посмотрев на историю страницы в нашем корпоративном twiki, я обратил внимание, что небольшой список с пояснениями, на основе которого сделана эта публикация, начал своё существование в 2006 году и неспешно дополнялся до 2011 года. Потом почему-то заглохло. Может быть, у кого-нибудь из читателей появится желание что-то добавить?
Простота
Если решение задачи оказывается слишком сложным, то с вероятностью 99% способ решения неверен.
Unix-way
По возможности, программа должна выполнять одно действие, но зато делать это хорошо.
Бритва Оккама
Кроме того, что не нужно умножать сущности, всегда помним о тезисе «это нам никогда не понадобится». И, скорее всего, оно не понадобится на самом деле.
Велосипед уже существует
Прежде чем изобретать свой способ решения, неплохо было бы оглядеться: может быть, кто-то уже решил проблему и сделал это лучше, чем мы хотим. Не забываем про мир свободных программ.
Повторы
Если действие повторяется больше шести раз, то пора это действие тем или иным способом автоматизировать. Варианты: написать скрипт, создать класс, записать макрос.
Почему именно шесть раз? Потому что до шести внимание на это обычно не обращают.
Тесты
Любую реализацию нужно начинать с реализации тестов.
То есть, прежде чем начать писать программу, надо продумать как эту программу тестировать. И начать тестировать. Даже если нет реализации того, что тестируется. Тесты помогут понять, что нужно делать и как, а что — нет.
Подкустовные выползни
«Подкустовные выползни появляются на свет сразу. как следует из названия, они выползают из-под куста.» © Квартет И, «День радио».
Подкустовных выползней не бывает. И не нужно даже пытаться решить _всю_ задачу _сразу_. Просто поверьте, что это невозможно., но если разбить ее на части, то решение подзадач становится вполне реальным.
Время
Отработать больше часов не значит сделать больше. Продуктивность и отработка времени — совершенно противоположные понятия.
Очевидное
Вы думаете, что кто-то умеет читать ваши мысли? Это ошибочное суждение. Телепатов в нашем несовершенном мире можно встретить только в зеркале. Поэтому, прежде чем что-то сделать, основываясь на своём представлении об информированности окружающих, нужно убедиться, что окружающие «в курсе». Или «в теме».
То есть, всегда необходимо информировать коллег о своём видении проекта и своей роли в нём. А то сами они не догадаются.
Коротким списком
- Простота
- Unix-way
- Бритва Оккама
- Велосипед существует
- Повторы — автоматизировать
- Сначала тесты
- Подкустовных выползней нет
- Не нужно отрабатывать время
- Мысли читать никто не умеет
