Принципы разработки

Материал из b4wiki
Перейти к: навигация, поиск

в своих разработках мы продвигаем вот такие принципы.

Содержание

простота

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

unix-way

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

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

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

и, скорее всего, оно не понадобится на самом деле.

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

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

повторы

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

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

тесты

любую реализацию нужно начинать с реализации тестов.

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

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

"подкустовные выползни появляются на свет сразу. как следует из названия, они выползают из-под куста." © квартет и. день радио. подкустовных выползней не бывает.

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

также см. Проблемы решения сложных задач.

время

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


--
(из внутреннего wiki НТЦ Метротек).

--fam 14:52, 4 февраля 2009 (UTC)

Личные инструменты
Пространства имён

Варианты
Действия
разработки
технологии
разное
Инструменты