Стоит задача упорядочить процесс разработки программного обеспечения.
Проблема в том, каждый месяц заказчики предлагают новые идеи которые надо реализовать (эта ситуация будет продолжаться и в будущем, такова специфика работы). В результате на данный момент разработка программного обеспечения сводится к тому что 3 программиста пишут код и один руководитель распределяет обязанности. Код не документируется, не применяются системы тестирования, нет единого стиля кодирования, программисты имеют чрезвычайно поверхностное представление о ООП и дизайне. В добавок предстоит набор на работу студентов, которые не имеют серьезного опыта работы.
Все это необходимо разрулить.
На данный момент предполагаю предпринять следующие меры:
0) выработать общий стиль кодирования
1) обязательное документирование нового кода, и постепенное документирование старого
2) ознакомить людей с design pattern-ами, и потребовать чтобы постепенно сотрудники осваивали их
3) периодически проверять как сотрудники применяют pattern-ы
4) важные модули разрабатывать самому

По вашему мнению какие меры надо предпринять для улучшения ситуации, как поставлен процесс у вас?

P.S. Пожалуйста не предлагайте вариант всех разогнать и набрать супер спецов и и ввести RUP.

Здравствуйте, Аноним, Вы писали:

А>На данный момент предполагаю предпринять следующие меры:
А>0) выработать общий стиль кодирования

Это очень просто — стиль кодирования всегда берется из Framework который юзаешь — используешь Java — Camel Notation, используешь MFC — венгерская.
Связано с тем что ты все равно в коде используешь Framework и если у тебя будет другая нотация то это значит что у тебя их будет две. Т.е. никакой.

А>1) обязательное документирование нового кода, и постепенное документирование старого

Документировать код достаточно бесполезно. Документировать нужно дизайн. Код в случае непонятки в конкретном месте проще переписать чем по доке с ним разбираться. Ну т.е. нужно документировать не как код рботает а что он делает, поэтому описание 2 пол экрана на класс как правило полезней чем описание по 2 строчки на каждую процедуру в нем.

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

А>2) ознакомить людей с design pattern-ами, и потребовать чтобы постепенно сотрудники осваивали их

Учти что архитектура это не просто паттерны.

А>3) периодически проверять как сотрудники применяют pattern-ы

Это Code Review называется.

А>4) важные модули разрабатывать самому

Не модули, а общую архитектуру, интерфейсы etc. Модули это слишком малохзначительная часть.

А>По вашему мнению какие меры надо предпринять для улучшения ситуации, как поставлен процесс у вас?

Здравствуйте, Аноним, Вы писали:

А>0) выработать общий стиль кодирования
Это обязательно, если хотите обеспечить более легкую поддержку проекта. Каждый день проводить проверки и совместно разбирать отклонения от стандарта.

А>1) обязательное документирование нового кода, и постепенное документирование старого
Создание документации по проекту зависит от выбранной методологии разработки проекта.

А>2) ознакомить людей с design pattern-ами, и потребовать чтобы постепенно сотрудники осваивали их
А>3) периодически проверять как сотрудники применяют pattern-ы
Учить, конечно, надо, но архитектуру приложения должен создавать профессиональный архитектор. Если каждый "начинающий" программист будет вносить в общую систему свое видение архитектуры, то проект скорее всего скоро превратится в помойку.

А>4) важные модули разрабатывать самому
Утопия. Невозможно все делать самому. Необходимо чаще контролировать результат работы сотрудников.

Я бы посоветовал следущее (переработанный и дополненный вариант):
1. выбрать методологию разработки: Agile (типа XP) или nonAgile (типа RUP или MSF). Я больше склоняюсь к RUP, если система пишется под заказ, или в некоторых случаях к MSF, если делается коробочный продукт.
2. создать документ, регламентирующий процесс написания кода.
3. при использовании nonAgile методологии создать необходимую предварительную документацию, постоянно ее развивать и дополнять.
4. создать скелет архитектуры системы, постоянно развивать и дополнять архитектуру.
5. при написании кода использовать автоматизированное тестирование, контроль версионности, автоматизированная сборка версий.
6. хотя бы на начальных этапах производить каждый вечер Code Review (просмотр написанного кода всеми сотрудниками для поиска логических ошибок).
7. стараться совместно обсуждать все аспекты построения системы.
8. постоянно проводить обучение сотрудников.

Очень порадовало сообщение про «готов оказать консалтинговые услуги» — у нас тут скоро rsdn.management, не успев родиться, превратится в rsdn.marketplace

OK, давай по порядку.

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

Чтобы упорядочить, к проблеме надо подходить с двух сторон. Смотри, вот что ты пишешь:

> Все это необходимо разрулить.
> На данный момент предполагаю предпринять следующие меры:
> 0) выработать общий стиль кодирования
> 1) обязательное документирование нового кода, и постепенное документирование старого
> 2) ознакомить людей с design pattern-ами, и потребовать чтобы постепенно сотрудники осваивали их
> 3) периодически проверять как сотрудники применяют pattern-ы
> 4) важные модули разрабатывать самому

Это всё, наверное, хорошо и правильно, но это односторонний, я бы даже сказал, однобокий подход. Общий стиль кодирования — чего его вырабатывать? Есть масса рекомендацийи соглашений, да хоть бы и эти.

Обязательное документирование нового кода? Согласен, некоторому оздоровлению ситуации этот шаг способствовать будет (а если применить xDoc, так и документацию можно будет формировать вполне удобочитаемую). Но следует понимать, что документировать старый код никто и никогда не будет, потому что у того, кто его знает, постоянно нет времени, а тот кто его не знает, документировать ничего не может.

Design patterns? Боюсь, что в условиях, когда «программисты имеют чрезвычайно поверхностное представление о ООП и дизайне» и «предстоит набор на работу студентов, которые не имеют серьезного опыта работы», это только отпугнёт большинство сотрудников. С другой стороны, стоит сформировать «отдел системной архитектуры», некий центр компетенции, который будет ответственным за принятие архитектурных решений. Всё, что касается изменения дизайна системы, должно решаться им. Все разработка должна курироваться им. Здесь важно организовать не только (и не столько) контроль, но и обучение, тьюторинг. Если совсем «зелёного» специалиста, с минимумом опыта и практических навыков зажать в рамки строгого учёта и контроля, производительность его, скорее всего, будет невысока. Если же поощрять человека к диалогу, если приветствовать его вопросы, с которыми он обращается к «старшим товарищам», если такие вопросы не будут оставлены без внимания, человек покажет хороший прогресс, и довольно быстро. Опять же, всякий формализм в этом деле может только повредить; очень важна здоровая атмосфера в коллективе.

«Важные модули разрабатывать самому» верно настолько же, насколько верно «хочешь сделать что-нибудь хорошо, сделай это сам». В конце концов это приведёт к тому, что всю работу делаешь ты, потому что вся разработка состоит сплошь из важных модулей. Я бы сконцентрировался на организации процесса таким образом, чтобы перевести операционные и технологические риски в поле управляемости.

> По вашему мнению какие меры надо предпринять для улучшения ситуации, как поставлен процесс у вас?

Теперь о том, что, по моему мнению, ты упускаешь: взаимоотношения с заказчиком. Как мне кажется, совершенно необходимо внедрить процедуру управления изменениями. Заставить заказчиков высылать запросы на изменение в установленном формате. Сформировать change control board (CCB), которая будет рассматривать высылаемые заказчиками запросы на изменение, анализировать новые требования, их связь с реализованными требованиями, их влияние на дизайн системы. Сформировать регламенты взаимодействия между заказчиком, CCB и командой проекта.

Если интересно, могу поделиться кое-каким опытом.

Здравствуйте, speedballer, Вы писали:

S>Design patterns? Боюсь, что в условиях, когда «программисты имеют чрезвычайно поверхностное представление о ООП и дизайне» и «предстоит набор на работу студентов, которые не имеют серьезного опыта работы», это только отпугнёт большинство сотрудников. С другой стороны, стоит сформировать «отдел системной архитектуры», некий центр компетенции, который будет ответственным за принятие архитектурных решений. Всё, что касается изменения дизайна системы, должно решаться им. Все разработка должна курироваться им. Здесь важно организовать не только (и не столько) контроль, но и обучение, тьюторинг. Если совсем «зелёного» специалиста, с минимумом опыта и практических навыков зажать в рамки строгого учёта и контроля, производительность его, скорее всего, будет невысока. Если же поощрять человека к диалогу, если приветствовать его вопросы, с которыми он обращается к «старшим товарищам», если такие вопросы не будут оставлены без внимания, человек покажет хороший прогресс, и довольно быстро. Опять же, всякий формализм в этом деле может только повредить; очень важна здоровая атмосфера в коллективе.

Я на сколько понимаю до целого отдела архитекторов здсеь далеко — найти бы одного человека.

S>«Важные модули разрабатывать самому» верно настолько же, насколько верно «хочешь сделать что-нибудь хорошо, сделай это сам». В конце концов это приведёт к тому, что всю работу делаешь ты, потому что вся разработка состоит сплошь из важных модулей. Я бы сконцентрировался на организации процесса таким образом, чтобы перевести операционные и технологические риски в поле управляемости.

>> По вашему мнению какие меры надо предпринять для улучшения ситуации, как поставлен процесс у вас?

S>Теперь о том, что, по моему мнению, ты упускаешь: взаимоотношения с заказчиком. Как мне кажется, совершенно необходимо внедрить процедуру управления изменениями. Заставить заказчиков высылать запросы на изменение в установленном формате. Сформировать change control board (CCB), которая будет рассматривать высылаемые заказчиками запросы на изменение, анализировать новые требования, их связь с реализованными требованиями, их влияние на дизайн системы. Сформировать регламенты взаимодействия между заказчиком, CCB и командой проекта.

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

S>Если интересно, могу поделиться кое-каким опытом.

Я бы с удовольбствием почитал, интересно сравнить со своим опытом.

Да, мне тоже было бы очень интересно узнать механизм работы change control board, организованной у вас.

Заставить заказчиков высылать запросы на изменение в установленном формате. Сформировать change control board (CCB), которая будет рассматривать высылаемые заказчиками запросы на изменение, анализировать новые требования, их связь с реализованными требованиями, их влияние на дизайн системы. Сформировать регламенты взаимодействия между заказчиком, CCB и командой проекта.

S>Если интересно, могу поделиться кое-каким опытом.

Очень интересно, если можно — отдельным тредом, например под названием "Управление требованиями".
Спасибо.

A> Я на сколько понимаю до целого отдела архитекторов здсеь далеко — найти бы одного человека.

Anyway, пусть решения, касающиеся архитектуры, принимаются коллегиально. Пусть гипотезы представляются на «суд общественности», пусть их обсудят, рассмотрят и покритикуют, прежде чем этот один человек на две недели уйдёт в разработку, чтобы понять в конце концов, что его исходные предпосылки были неверны.

S>>Теперь о том, что, по моему мнению, ты упускаешь: взаимоотношения с заказчиком. Как мне кажется, совершенно необходимо внедрить процедуру управления изменениями.
A> На мой взгляд это возможно и нужно только если заказчиков много. Мелкие фирмы как правило вынуждены подпрыгивать под заказчика, и только когда заказчиков уже много нужно говорить — в очередь! и перестать делать все прямо сейчас а планировать фичи на определенные версии и иметь план релизов.

Ты, конечно, прав — всё нужно примеривать на конкретную ситуацию. Но в части твоих высказываний про «много заказчиков» и «мелкие фирмы» позволю себе с тобой не согласиться. Иметь выстроенные процедуры управления изменениями всегда полезно. Объяснить заказчикам, — неважно, много их или мало, — что это не самодурство и не каприз, что это направлено исключительно на пользу дела, тоже возможно — в 90% случаев. И тем более это важно для мелкой фирмы, потому что один неуспешный и даже недостаточно успешный проект способен такую фирму просто похоронить.

S>>Если интересно, могу поделиться кое-каким опытом.
A> Я бы с удовольбствием почитал, интересно сравнить со своим опытом.

Постараюсь более или менее внятно сформулировать в отдельной ветке.

Здравствуйте, <Аноним>, Вы писали:

А>Стоит задача упорядочить процесс разработки программного обеспечения.
А>Проблема в том, каждый месяц заказчики предлагают новые идеи которые надо реализовать (эта ситуация будет продолжаться и в будущем, такова специфика работы). В результате на данный момент разработка программного обеспечения сводится к тому что 3 программиста пишут код и один руководитель распределяет обязанности. Код не документируется, не применяются системы тестирования, нет единого стиля кодирования, программисты имеют чрезвычайно поверхностное представление о ООП и дизайне. В добавок предстоит набор на работу студентов, которые не имеют серьезного опыта работы.
А>Все это необходимо разрулить.
А>На данный момент предполагаю предпринять следующие меры:
А>0) выработать общий стиль кодирования
А>1) обязательное документирование нового кода, и постепенное документирование старого
А>2) ознакомить людей с design pattern-ами, и потребовать чтобы постепенно сотрудники осваивали их
А>3) периодически проверять как сотрудники применяют pattern-ы
А>4) важные модули разрабатывать самому

А>По вашему мнению какие меры надо предпринять для улучшения ситуации, как поставлен процесс у вас?

А>P.S. Пожалуйста не предлагайте вариант всех разогнать и набрать супер спецов и и ввести RUP.

ИМХО.

Лирическое отступление.

Есть два подхода к облагораживанию парка. Первый — это поставить заборы, расставить указатели, перекопать протоптанные тропинки и сделать красивые аллеи. Второй — это заасфальтировать уже существующие тропинки и поставить вдоль них урны и лавочки. В первом случае вам может не хватить времени и денег, а тропинки всё равно появятся. Вполне вероятно, вам будет достаточно второго, причём сделать из него первый будет уже гораздо проще...

Вступление.

Исходя из вышеуказанных начальных условий предполагаю, что жёсткое внедрение любой методологии потерпит крах по следующим причинам:
— отсутствие культуры использования "упорядоченного процесса разработки" у разработчиков;
— отсутствие дополнительных ресурсов на внедрение и поддержание строгого процесса разработки;
— резкое понижение продуктивности в период внедрения каких-либо методик;
— отсутствие опыта использования методик у вас лично;
— отсутствие у разработчиков внутренней тяги к упорядочиванию собственной деятельности.

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

Поэтому, моё предложение в текущей ситуации будет звучать как формирование условий для возможности дальнейшего внедрения одной из методологий путём постепенного упорядочивания процесса разработки и операционной среды проекта.

План действий.

1. Создание артефакактов

Под артефактами понимается набор документов, в той или иной степени описывающих проект. Создание формальных артефактов по шаблонам, данным в различных методиках в текущий момент не самая хорошая мысль, поскольку всё документы там связаны друг с другом и их полная реализация займёт слишком много времени и может не удасться вовсе. Я думаю, что на данном этапе вам нужно создать следующие артефакты:

— Требования. В данном наборе документов нужно перечислить задачи, которые вам ставит заказчик, и для каждой задачи кратко описать основные требования заказчика (функциональные). В данном разделе можно создать небольшой документ, в котором описать основные нефункциональные требования.
— Архитектура проекта. Здесь нужно описать общее видение проекта, сделать грубую функциональную модель, описать основные технологические принципы построения программного обеспечения и технологии, которые предполагается применять.
— Технический проект. Здесь рекомендуется описать основные сервисные составляющие системы (написанные вами библиотеки, постоянно используемые технологические приёмы, сервисные классы и т.п.). Данный документ можно проработать достаточно глубоко, поскольку использоваться он будет как справочник. Также можно даже попробовать средства автодокументирования кода для создания чего-то вроде help-а, потому что этот документ будет использоваться дальше как справочник.
— Модель процесса разработки. Этот документ достаточно простой — здесь нужно кратко описать, какие процессы у вас в разработки задействованы и какие данные поступают на вход этих процессов, а какие на выход. Например, вы указываете процесс "формирование требований". На входе этого процесса у вас есть устные пожелания заказчика, а на выходе документ "Требования". Также, например, можно описать что разрабатывается в модуле и в какой последовательности (например, сначала модель предметной области, потом структура БД, хранимые процедуры, параллельно модель классов, далее кодирование классов, интерфейсы, тестирование отдельных классов, общая сборка и тестирование, деплоймент...). Причём желательно описать это достаточно кратко (можно хоть в Visio нарисовать прямоугольничками), но должно быть чётко указано, что поступает на вход каждого процесса, а что из него выходит (документы, устные сведения, код и т.п.). Это даст вам возможность отслеживать, какой модуль на какой стадии находится, а также возможность осуществлять минимальное планирование. Кстати, не обязательно все этапы должны быть пройдены всегда — в некоторых случаях часть процесса может быть пропущена. Главное здесь, чтобы разработчик знал, что он получит в качестве условий задачи и что должен породить (передать дальше).

2. Формирование операционной среды

Под операционной средой я понимаю ту инфраструктуру, которая обеспечит разработчику всё необходимое для того, чтобы он работал и не отвлекался. Сюда входит:
— среда(ы) разработки (если есть возможность, то лучше свести всё к одной среде);
— средства поддержки версионности и совместного использования кода (как пример — SourceSafe). Здесь, кстати, надо хранить и все документы;
— средства обеспечения отказоустойчивости разработки (систему резервного копирования и восстановления операционной среды)

Кстати, резервное копирование очень простая и важная штука... Она позволяет ощутить устойчивость. На первых порах можно остановиться хотя бы на 3-х вещах: backup дисков на машинах разработчиков (например, Norton Ghost), автоматизированный backup БД и автоматизированный Backup исходников кода системы и документов (например, бэкапить базы SourceSafe при помощи утилиты Backup32 — в ZIP, а потом на другой винт, CD или DVD)

3. Структурирование команды

Здесь сложно чего-то говорить не зная вашей специфики, но всё же... Если есть возможность, то я бы советовал разделить разработчиков "горизонтально" по специализации. Т.е. кто-то в основном занимается БД, кто-то в основном пишет интерфейсы, кто-то классы предметной области, кто-то системную и коммуникационную часть и т.д. Жёсткой специализации делать не нужно — теряете взаимозаменяемость, но вот мягкая даёт следующие преимущества:
— появление в команде явных технологических лидеров-экспертов по направлениям;
— появление "контрактных" отношений (СУБД-шник придумывает документы типа описания заказа на структуры данных и процедуры, писатель классов предметной области договаривается "документально" с интерфейсником и т.п.). Таким образом появляется потребность создавать артефакты более низкого уровня, нежели "архитектура" и "техпроект", что само по себе хорошо. Почему? Потому что при дальнейшем приближении к артефактам той или иной методологии люди уже не будут задумываться — что им писать, а будут только изучать "в каком формате" им это делать, а это уже несоизмеримо легче.
— более простое управление вновь прибывшими в команду разработчиками. Каждый специалист может брать шефтсво над вновь прибывшим, если тот также принимается на специализированную должность или над той частью обучения и контроля новичка, которая находится в ведении специалиста.
— повышение ответственности каждого конкретного специалиста за содеянное своими руками, поскольку теперь из-за него могут замедлится коллеги и пострадать целый проект. Это даст более ответственное отношение к срокам и качеству кода, а также халтура будет видна лучше.

4. Фиксация окружения

Основная идея здесь — это упорядочить внешние связи Посмотрите, с кем общается ваша команда и какие формы общения существуют. Как минимум — общение с заказчиком на стадии получения заказа, итерационного уточнения требований, деплоймента и дальнейшей поддержки системы. Все эти составляющие можно и нужно буферизировать, чтобы:
— упорядочить общение;
— свести его из онлайна в офлайн по возможности (избежать дергатни);
— сделать вашу деятельность "прозрачной для заказчика".

Как практические меры могу предложить:
— использование артефакта "требования" для уточнения и фиксации постановки задачи;
— создание чёткого процесса деплоймента (желательно одной кнопкой, если возможно). Это будет являться предпосылкой для появления в дальнейшем поддержки версионности вашей системы и снимет головную боль при частых апдейтах;
— создание простейшего трекера ошибок, где заказчик (да и вы сами) могли бы фиксировать ошибки и мелкие пожелания и отмечать их исправление;
— создание простого календарного плана (пусть даже в элементарном исполнении, но максимально честного). Не беда, что пока он будет у вас постоянно корректироваться. Главное, чтобы он на этой стадии появился.

Если есть другие внешние к вашей команде игроки — сделайте и для них буферную зону. Работать станет удобнее и легче, поскольку, с одной стороны, объём ощения теперь будет регламентирован, а с другой — ответственность будет разделена с заказчиком (ему тоже придётся участвовать, а не пальцы гнуть).

5. Формирование процедур управления

Здесь основная идея — начать приучать людей к нововведениям и себя — к ужесточению процесса управления. Еженедельные совещания с уточнением по существующим артефактам, анализом сделанного и коррекцией планов на следующую неделю — самое "то" для начала. Это даст вам следующее:
— вы сможете наконец контролировать сроки в той или иной степени;
— вы сможете контролировать ведение артефактов и соответствие реального процесса разработки задуманному;
— планировать вместе с командой ближайшие задачи;
— помогать команде осваиваться с артефактами и контролировать правильность (с вашей точки зрения) ведения артефактов;
— следить за тем, насколько члены команды привыкли к существующему процессу и постепенно вводить новые "меры упорядочивания".

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

Также можно ввести устную беседу с каждым разработчиком по вечерам, выясняя, что он сделал и что собирается делать автра. Только не надо вводить всякой отчётности типа документов "что я сделал за день". Почему не надо — я уже писал где-то в форуме "о работе". Если нужно — найду ссылку.

--
Вот, вкратце такой набор мер. Думаю, что у вас на это может уйти несколько месяцев (от 2-х до 4-х). В результате вы не только сможете получить некоторое упорядочивание в своём проекте, но и подготовите почву для дальнейшего применения более тяжёлых методик (если это будет необходимо). Также за это время вы поймёте, что вам действительно нужно (какая методика), сможете приучить своих людей к структурированному, а не хаотичному, ведению проекта и увидите многие слабые места.


Если я не прав, то старшие товарищи меня поправят.

Здравствуйте, Spidola,

большое спасибо за столь информативный постинг.

Здравствуйте, Аноним, Вы писали:

А>Стоит задача упорядочить процесс разработки программного обеспечения.
А>Проблема в том, каждый месяц заказчики предлагают новые идеи которые надо реализовать (эта ситуация будет продолжаться и в будущем, такова специфика работы). В результате на данный момент разработка программного обеспечения сводится к тому что 3 программиста пишут код и один руководитель распределяет обязанности. Код не документируется, не применяются системы тестирования, нет единого стиля кодирования, программисты имеют чрезвычайно поверхностное представление о ООП и дизайне. В добавок предстоит набор на работу студентов, которые не имеют серьезного опыта работы.
А>Все это необходимо разрулить.

Мне кажется надо начать с проблем, которые у вас возникают. Если все так как есть и работает — значит так и надо
Студенты — сложно. Надо будет контролировать много и старательно. Поэтому думаю, что прежде всего — план работ и постоянный контроль этого плана, еженедельные митинги, например, где все отчитываются на сколько доделаны текущие таски и какие возникли проблемы. Тогда и проблемы начнут всплывать с которыми бороться надо и PM будет в курсе работы над каждым куском системы.

А>На данный момент предполагаю предпринять следующие меры:
А>0) выработать общий стиль кодирования
А>1) обязательное документирование нового кода, и постепенное документирование старого
А>2) ознакомить людей с design pattern-ами, и потребовать чтобы постепенно сотрудники осваивали их
А>3) периодически проверять как сотрудники применяют pattern-ы
А>4) важные модули разрабатывать самому
Ну это де-факто. Т.е. просто вещи, которые необходимы, но без контроля они не помогут. Вполне может оказаться, что студень пишет кусок системы, грит, что все пучком, а к релизу окажется, что он падает через раз.
Еще тестирование модульное бы накрутить, интерграцию. Но это не просто. Часто без таких вещей обходятся и успешно, но стремиться к этому надо.

A>Это очень просто — стиль кодирования всегда берется из Framework который юзаешь — используешь Java — Camel Notation, используешь A>MFC — венгерская.
A>Связано с тем что ты все равно в коде используешь Framework и если у тебя будет другая нотация то это значит что у тебя их будет A>две. Т.е. никакой.

Ага. Используешь ATL + boost + STL и идешь вешаться, потому что в ATL верблюд, в бусте и стле — foo_bar.

А>>1) обязательное документирование нового кода, и постепенное документирование старого

A>Документировать код достаточно бесполезно. Документировать нужно дизайн. Код в случае непонятки в конкретном месте проще переписать чем по доке с ним разбираться. Ну т.е. нужно документировать не как код рботает а что он делает,
О да. А лучше иметь юнит/ацкептанс/регрешн тесты на этот код.

A>поэтому описание 2 пол экрана на класс как правило полезней чем описание по 2 строчки на каждую процедуру в нем.
Yep.


A>Правда от документирования кода есть вот какая польза. Нужно ввести правило, что если что делает процедура не ясно из ее названия то нужно это писать в комментарии. Что приводит очень быстро к вменяемым названиями во всем проекте потом учто случаев когда нельзя по человечески процедуру назвать почти не бывает.

А>>2) ознакомить людей с design pattern-ами, и потребовать чтобы постепенно сотрудники осваивали их

A>Учти что архитектура это не просто паттерны.

А>>3) периодически проверять как сотрудники применяют pattern-ы
Да-да. За регулярное применение паттернов премировать, за недовыполнение
плана по паттернам — штрафовать.

A>Это Code Review называется.

Здравствуйте, speedballer, Вы писали:

S>Очень порадовало сообщение про «готов оказать консалтинговые услуги» — у нас тут скоро rsdn.management, не успев родиться, превратится в rsdn.marketplace
Постараюсь этого не допустить, все-таки у нас форум и есть этот самый консалтинг...