Заметки о процессе ведения проектов в Delphi. Мой опыт.

Это старый пост из архива, который почему-то не был опубликован. Он немного устарел, и описывает то как я видел процесс разработки 1,5 года назад. Если интересно, то позже я напишу о том, как я вижу этот процесс сейчас.

Как-то так получилось, что в основном, мне приходилось заниматься сопровождать и развивать чужие проекты. А характерным признаком всех моих мест работ было одно – бардак. На всех работах, одним проектом занимался только один программист. У проекта обычно есть руководитель, который формулирует задания. Руководитель кода не знает, и программировать не умеет. В проекте могут участвовать люди, занимающиеся поддержкой и развитием базы данных, тестированием продукта, общением с клиентами и установкой новых версий. Практически все проекты, с которыми я работал, относились к бухгалтерским программам, и напрямую работали с базой данных(Firebird). Обычно в фирме таких проектов было несколько, но общего кода, не считая сторонних компонентов, у них почти не было. Так что у меня нет опыта работы в команде. И практически нет опыта следования процессу разработки. Только на одной из моих работ, для программистов была написана инструкция о том, как правильно работать. Там были как разумные вещи, так и не очень(in my humble opinion). Но, полностью инструкции не следовал ни один из программистов. Поэтому большинство моих рассуждений – это отчаянная попытка придумать велосипед навести порядок и превратить бардак в процесс так, чтобы это не сильно напрягало ни меня, ни других программистов и позволило навести и сохранить порядок в проекте.

Процесс выглядит так:

Программист получает задание, анализирует адекватность требований, и предлагает одно или несколько решений, лучше всего вписывающихся в архитектуру. Вместе с руководителем обсуждает достоинства и недостатки решений, выбирают оптимальное, и программист приступает к программированию. Иногда задания приходится уточнять, дополнять и даже переформулировать. В идеале, каждое задание, программист разбивает на несколько мелких задач, и после выполнения каждой задачи, программист фиксирует (делает commit) изменения в хранилище кода[1]. Мы используем Subversion.

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

[1] Перед фиксацией(commit), очень полезно ещё раз подробно просмотреть изменения в исходниках (svn Diff) и избавиться от такого мусора, как закомментированный код, позабытый отладочный код. Это позволяет избежать неожиданных глюков в готовой программе, и засорения хранилища ненужной информаций. Это может показаться занудным и неинтересным, но это действительно упрощает жизнь!

---

Спонсоры поста:

• Умение договариваться очень важная черта. Но иногда договор лучше оформить письменно. Например, давая деньги взаймы стоит оформить договор займа. Деньги же любят порядок.
• Если у вас есть домашний питомец, и ему нездоровится, то вас может заинтересовать следующая услуга: вызов ветеринара на дом. Я знаю, что некоторые программисты очень любят котов. ;)