Что такое хорошо и что такое плохо.

Что такое хорошо и что такое плохо.

Когда занимаешься программированием, есть жгучие желание побыстрее воплотить идею в коде и посмотреть, как она работает. Об этом пишет Демарко. Об этом же говорить Купер. Это могу подтвердить я сам. В былые школьные и студенческие годы, язык программирования был основным средством выражения идеи. К сожалению, и в областях программирования, далеких от школьной скамьи, процветает подобный подход.

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

Возьмем человеческого младенца, вот он лежит на спине, машет руками и ногами, его скорость перемещения равна нулю. Спустя какое-то время, он научиться переворачиваться и ползать на четвереньках, его скорость перемещения станет отличной от нуля. Затем, он подрастет, встанет на ноги и научиться ходить. Скорость перемещения значительно вырастит. Далее, с возрастом, он научиться бегать. Потом, если его хорошо тренировать и правильно кормить, он будет бегать очень быстро, может даже поставит мировой рекорд. Однако, как бы мы ни старались, как бы ни тренировали и ни кормили, этот человек не сможет преодолеть звуковой барьер и достичь космической скорости! Для решения этих задач нужны принципиально другие методы. Нужна работа многих инженеров и проектировщиков, создающих летательные и космические аппараты, нужна целая промышленная индустрия, со множеством заводов, чтобы эти аппараты создать, нужно целое государство, чтобы это все профинансировать, нужна слаженная работа огромного количества людей для того, чтобы этот человек смог таки преодолеть эти рубежи.

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

В чем-же разница?

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

Например — строители: Сначала дизайнер продумывает основную идею. Затем, архитектор создаст проект. После чего, инженеры рассчитают все необходимые нагрузки, допуски, коэффициенты, свойства материалов. Потом, управленцы заключат все необходимые договора о поставках и услугах и утвердят подробный график строительства. И на конец, произойдет собственно стройка. Все предварительные этапы могут длиться годами. Планы могут меняться, переписываться, переутверждаться... На это не надо много сил и денег, т.к. этим всем занимается небольшое количество людей, а результат их труда хранится на бумаге, а не закатан в бетон. Последний этап — результат проведенной колоссальной работы. За считанные месяцы, как грибы после дождя, вырастают небоскребы. Сценарий стройки разыгрывается как по нотам. Не без ошибок, конечно, но в пределах погрешностей. Посмотрим теперь, как строится шалаш. Собирается подручный материал и используется в строительстве по мере необходимости. Как по вашему, что лучше приспособлено для жилья?

Аналогичная ситуация в кинематографе. Собственно съемкам предшествует длительная предварительная работа со сценарием, графикам, договорами, резервированием... Съемки — это небольшой, но самый дорогой, эпизод в процессе создания фильма. В противовес можно привести сказку, которую рассказывают на ночь ребенку...

Художник, перед созданием картины, делает множество зарисовок, продумывает композицию, идею и цветовое решение. Нанесение красок — это финишная прямая. Школьник берет краски и садится рисовать чего-нибудь...

Можно продолжать очень долго.

В данной работе я постараюсь пройти от идеи до продукта используя по пути больших индустрий.

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

1. Описание идеи. Ответ на вопросы «Что мы делаем кому?»
   На этом этапе требуется 2 — 3 человека, способных генерировать идеи. Их задача найти потребность, которую нужно удовлетворить. Не менее 2х для того, чтобы они могли спорить друг с другом. Не более 5ти, чтобы они не начали друг-другу мешать и слишком много спорить.


2. Проектирование модели использования продукта. Ответ на вопрос «Почему мы это делаем именно так?»
   Тут требуется максимум человек 5. Основная задача — моделирование использования будущего продукта. Нахождение «тонкостей» и «моментов», на которых следует сконцентрировать внимание и силы.


3. Проектирование структуры продукта. Ответ на вопрос «Зачем нам нужны все эти компоненты и связи?»
   Тоже не более 5ти человек, лишние будут только мешать. Основная задача — структура будущего продукта, описывающая все его модули и интерфейсы между ними. Эта структура обязана быть следствием шага 2 и «ложиться» на модели использования.


4. Разработка спецификаций модулей продукта. Ответ на вопрос «Как мы создадим эти модули?»
   Детальная разработка модулей. Проектирование структуры исходного кода. Утверждение соглашений по различным конвенциям, стилям, используемым инструментам и решениям, сборкам и тестированию и проч. Создание расписания предстоящих работ по программированию. Количество человек может быть несколько больше, чем на предыдущих шагах.


5. Написание кода.
   Тут можно и нужно использовать столько человек, сколько вы можете себе позволить. Основное правило — все они обязаны неукоснительно следовать спецификациям предыдущего шага.


6. Выпуск и сопровождение

Количество человек зависит от размера продукта и количества потребителей.

Особенно хочу обратить внимание на то, что было-бы замечательно, если бы на шагах 1+2 и 3+4, а так-же и 5+6 были бы совершенно разные люди.

К сожалению, в данный момент, кроме меня этим продуктом никто не занимается, а потому возможны некоторые авторитарные решения и отвлечения от поставленных целей.