Программирование: Практики которые я возьму с собой

Я имею довольно небольшой опыт работы в сфере разработки программного обеспечения (всего 6 лет), но я уже накопил ряд полезных и правильных практик (по моему скромному мнению), которые можно использовать при создании программного обеспечения.

В основном описаны моменты которые касаются поддержки процесса разработки программного обеспечения, не затрагиваются темы планирования хода выполнения работ. Также не затронут процесс программирования и полезные плюшки для него (например расслоение системы на уровни, использование шаблонов проектирования). Но все ниже приведенное было и остается полезным для меня лично, и я буду рад если и вам на что нибудь сгодится :)

• В конце рабочего дня подведение краткого итога, и письменный ответ на три вопроса: что было сделано, какие проблемы возникли, что планируется сделать. Также неплохо предоставить данную информацию всей команде (электронная почта, внутренний блог), и если у них будет интерес, то они могут прочитать данный отчет. Полезность данной практики неоценима, каждый кто составляет отчет задумывается в конце дня над вопросом: а что он сегодня полезного сделал. И ради ответа на данный вопрос уже стоит использовать данную практику. Кстати, некоторые заметят что данная практика присутствует в Scrum методологии. Но я первый раз увидел ее на Иркутском Авиационном заводе, мне о ней рассказал один очень интересный человек.
• Все материалы по проекту должны быть сосредоточенны в одном месте. Например, ссылки на логи общения с заказчиком или URL, для репозиториев исходного кода. Порядок никогда не бывает лишним, а порой очень сильно способствует повышению производительности.
• Надо управлять требованиями заказчика. Что понимается под таким общим утверждением? Все просто, все запросы на изменения вносимые в проект от заказчика должны быть зафиксированны в электронном виде. В тяжелых случаях заказчик должен ставить подпись под каждым своим требованием. Да это бюрократия, да интереснее писать код, но без этого ваш проект имеет очень высокую вероятность провала. Хотя тут многое зависит от.
• После получения задания от заказчика надо ему объяснить своими словами что он хочет. Данная вещь очень важна, без нее очень часто реализовываются вещи которые хочет разработчик, а не заказчик. Хоть это и звучит дико, но тут надо очень аккуратно согласовывать требования, ведь разработчик тоже не дурак и понимает к чему приведет реализация странных требований.
• Повесить на общее обозрение диаграмму описывающую архитектурные особеннности проекта. В идеале рядом с ней повесить диаграмму с ходом движения работ по проекту. Это позволит поднять уровень коммуникации между членами команды на принципиально иной уровень. Главное не забывать тыкать пальцем в элементы диаграмм при обсуждении проекта. И не забывайте рисовать на доске ваши мысли для общего обсуждения :)
• Исходный код проекта должен хранится в системе контроля версий. Порядок никогда не бывает лишним. Особенно это важно когда код пишет более одного человека, хотя я уже не представляю себе как можно писать код без системы контроля версий. Наверное у меня комплекс :)
• Должна быть инструкция для настройки рабочего окружения по работе над проектом. Если данного документа нет, то получается истинный хаос при подключении нового человека в проект. Да и передача дел значительно затрудняется. Вики по проекту это идеальный вариант.
• Использование системы управления задачами. Наличие данной системы позволит более продуктивно исправлять различные проблеммы и не забывать про них. Не забывать это хорошо.
• Наличие описания сборки проекта. Если каждый раз сборка проекта это череда магических пасов, и собрать проект может только единственный гуру в команде, то это бардак. Если будет описание процеса сборки приложения хотя бы в текстовом виде, то это значительно упростит работу работу всех членов команды, и избавит от ряда глупых вопросов. Идеальный вариант когда процесс сборки приложения автоматизирован (например при помощи Ant или Maven), тогда счастье разработчиков поистине безгранично.
• Использование системы непрерывной интеграции. Возможно вам это и не надо, но меня очень уж радует факт того, что каждый день происходит сборка системы, и возможно проходят все тесты. Это значительно повышает уверенность в разрабатываемой вами системе.
• С опаской относится к независящим от вас системам. Интернет ненадежная штука.
• Быть готовым к изменениям. Не все изменения одинаково полезны, но надо быть готовым принять разумные вещи и использовать их в своих целях. В том числе, надо критически воспринимать данный текст :)

Надеюсь вы не зря потратили свое время на чтение данного текста, и что то будет вам полезным :) Кстати, черновик этого текста можно найти у меня в блоге :)