• Каким инструментом вы пользовались, чтобы генерировать DTO объекты в проекте?
• Мозгом.
• Не слышал о таком. Пришли ссылку, пожалуйста.

 

При кажущейся абсурдности, это часть реального разговора между архитектором и ведущим разработчиком проекта. И абсурдного и удивительного в этом разговоре крайне мало. В 2001 году основатели Agile Software Development утверждали, что они ценят «индивидуумов и взаимодействия больше, чем процессы и инструменты».

Проблема с разработчиками-индивидуумами в промышленном масштабе в том, что они существуют в единственном числе. А для проектных нужд разработчиков неплохо бы заказывать небольшими партиями, человек так по 10-20 за раз.

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

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

Но единотехнологичные или же единоинструментальные проекты в ИТ возможны только до определенного момента. Чем больше проект и сложнее требования к нему – тем вероятнее использование нескольких технологий и нескольких инструментов разработки.

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

Как это можно сделать, когда перед тобой пачка технологий, жмут сроки, неидеальная команда, и ты сам как менеджер до конца не понимаешь, как это все вместе работает? В последнее несколько лет популярным стал «X Driven Development». Под этим подходом я понимаю настроение участников проекта, когда практически все внимание фокусируется на каком-то одном аспекте X, который должен обеспечить успех проекта. У проекта должен быть свой Х – будь то Test, Behavior, или Acceptance Testing. Недавно Ж.Д. Мейерс из Микрософта додумался до (User) Experience Driven Development. О чем это говорит? О том, что TDD, BDD, DDD, и прочие xDD по большому счету выстрел не понятно в какую сторону. Программистам нравится писать код. Поэтому они предпочтут писать код любой другой работе. Или же будут писать код под любым удобным предлогом.

Несомненно, качество программного кода имеет корреляцию с успехом проекта; вопрос только, насколько сильную? Это зависит от массы обстоятельств в бизнесе заказчика. В некоторых отраслях 80% годовой прибыли может формироваться за 2-3 месяца. Обычно эти месяцы ноябрь-декабрь, когда люди тратятся на Рождество и Новый Год. Или же необходимо сделать маркетинговую демонстрацию на определенной выставке, скажем, CeBIT. Ваш проект не сумел выпустить версию к нужной дате?

В некоторых случаях можете сворачивать проект. И сильно помогло вам качество вашего кода? Мы хотели бы услышать ваше мнение о том, что xDD реально дали Вам в Ваших проектах. Ждем комментариев!