Дилемма: XP или Архитектура

Как оказалось новые технологии сильно конфликтуют друг с другом. Так ХР (Экстремальное программирование) требует постепенного улучшения и совершенствования моделей, подтвержденных тестами. Академические же методики требуют изначального формального рассмотрения системы в целом. Если избежать паралича анализа - то можно определить систему подробно и увидеть все подводные камни.
Эти методики как разный взгляд на путешествие. ХР - это драйв на яхте к тем местам, которые хочешь увидеть. Архитектурный подход - скрупулезное планирование пути по карте и выставление вех. После этого работа - чисто на автоматизме, с применением генераторов кода и дешевых "кодеров".



Эти два подхода имеют как своих сторонников, так и противников. Так мой преподаватель Ху Вен Цен очень не любит "кустарей". Он говорит: "Программу надо разрабатывать сначала по формализированной методике". Он очень умный человек, единственный минус - он не пишет программ :)

Попробовал разные методики и лишь ХР мне понравилась тем, что можно как в старые добрые времена кодировать"от души". То есть имеешь лишь общий план - а все остальное приложиться: и качество, и красота кода, и надежность.

Как часто мы сталкиваемся с одной проблемой: кажется, что вещь не нужна совсем, а потом, распробовав жалеем, что раньше не взяли ее. Так и у меня с ХР - книга меня не восхитила, когда я первый раз ее увидел. Изучив академическое программирование и почти загасив пламя творчества в душе своего программиста я нашел эту книгу опять. И, о - радость, вернулась та самая искорка ради которой стоило программировать.

Многие книги по программированию слишком детализируют процесс разработки, а само кодирование стоит на 5-10 месте. Это от того, что книги пишут преподаватели, а не программисты. Сколько раз сталкивался с проблемой: хочется совета, прочитаешь несколько книг и думаешь - все узнал. Начинаешь делать, а оно неудобно. Писатель, то - ученый или преподаватель.

Так я изучал ООП по Бучу "ООА и ООП с примерами на С++". Эта книга содержит много интересных идей. Но, сам автор в начале пишет: "Мы не будем рассматривать программы, которые пишет один программист. Они не столько сложные, сколько рутинные". И действительно, применяя его методику, чувствуешь, что впадаешь в "паралич анализа" - проект готов, а желания воплощать его исчезло.

И так происходит практически со всеми методиками, кроме ХР. Кет Бек - пишущий программист, и написал книгу с нашей точки зрения - по эту сторону клавиатуры.

После нескольких лет экспериментов пришел к выводу - если ты программируешь один или в паре - то лучший выбор - это ХР. Если большая команда (7 и больше человек), то лучше формализованных методик: RUP, MDA/OMF/UML не найти.

Но все же пришел к выводу, что одному программисту незачем лезть в горы "архитектуры". Интуитивное чутье и постоянное улучшение модели - вот козырь одиночки программиста. Из-за того, что не нужно совещаться мы очень мобильны. Это доказывает рынок шароварных продуктов - сплошь и рядом один-два человека. И это доказательство того, что не надо "мудрствовать лукаво".

Для молодых программистов
Часто вы думаете, что вы умнее многих и знаете программирование детально, и владеете им мастерски (и это я понимаю - сам такой был). Но посмотрите вокруг, чего вы достигнете с текущим набором знаний и что еще не известно и готово к использованию. Этот мир слишком сложен, чтобы за несколько лет познать даже такую малую сущность как программирование. И даже на то, чтобы достичь совершенства в нем нужно 10-15 лет упорного труда.