Saturday, December 13, 2008

Дао программиста

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

Технологии определяют “чем” мы работаем, т.е. это набор инструментов: языки программирования, базы данных, среды, тулзы, библиотеки классов, фреймворки, компоненты и т.д. То есть, если взять аналогию с токарем, это те инструменты и материальные приспособления, которые он использует для изготовления деталей.

Подходы же определяют “как” мы используем все эти инструменты и пишем код, т.е. в случае программирования это понимание и правильное использование ООП, SOLID, паттернов проектирования (GoF, Fowler), каких-то других Patterns & Best Practices, архитектурных принципов, рефакторинга, алгоритмов, структур данных и т.д. Сюда же можно отнести и знание и использование таких практик, как TDD, DDD и пр. В том числе это и тот опыт, который мы приобретаем в процессе работы. В случае с токарем это его умение вытачивать те или иные детали, которое он тоже совершенствует.

У каждого программиста эти 2 компонента развиты в разных соотношениях. Есть ребята гармонично развитые, которые, например, не только знают о том, что есть такая штука как ООП, но и правильно его используют. Есть отклонения в ту или иную сторону.

Как правило, у начинающих программистов идет четкий перекос в сторону технологий. Они изучают язык(и) программирования, технологии разработки веб-приложений и доступа к данным в университете или по книжкам (статьям в инете/msdn/блогам, нужное подчеркнуть), и верят в то, что этого знания достаточно не только для того, чтобы написать приложение любой сложности, но и чтобы быть классным программистом в целом. Они также часто верят в то, что на любой их вопрос всегда найдется ответ в гугле, что какие-то там непонятные паттерны проектирования им не нужны и что они знают ООП в совершенстве (дружный смех в зале). Что, узнаете себя в молодости? :)

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

Неужели это конец развития? Нет, конечно, это только начало. Во-первых, нет предела совершенству, и знание и понимание тех же технологий можно и нужно увеличивать. А во-вторых, когда программист переходит на уровень архитекта, у него начинаются уже свои головные боли и дальнейшее развитие, но уже не как программиста. Есть application architect, solution architect, enterprise architect, etc. и у каждого свои навыки и знания. Про дао архитекта я пока написать не могу, извините, не дорос еще :) Но оно есть, я в этом уверен.

К чему я все это веду? К тому, чтобы все понимали, что в работе программиста важны и технологии, и подходы, что даже отличное знание технологий еще не делает программиста инженером. На одном крыле далеко не улетишь. Ну и чтобы каждый мог понять хотя бы приблизительно, на каком уровне он сейчас находится и увидел, что именно нужно развивать. Благо, книги есть не только по технологиям, но и по подходам. Изучайте ООП, паттерны, рефакторинг, всякие TDD/DDD/Agile/прочее, это чужой опыт, который может помочь вам стать настоящим профессионалом. Успехов!

10 comments:

  1. IMHO, в статье перекос в сторону важности архитектуры и процессов, хотя на самом деле, это задача скорее прожект менеджеров и архитекторов, чем программистов.

    Конечно, программист должен понимать то же ООП, но на то и разделение труда, что бы одни занимались процессами разработки, другие архитектурой, третьи - кодом.

    Когда программиста обвиняют в плохой структуре классов, значит в проекте нет архитектора, когда программист пишет курсорами там, где, например, можно обойтись INSERT INTO ... SELECT ..., значит либо он, либо руководитель имеют иллюзию, что "технологии не так и важны и любую можно изучить довольно быстро".

    Кроме того, есть склонности человека. Кого-то тянет к технической стороне вопроса, кого-то к дизайну архитектуры, кого-то к процессам, QA, тестированию и т.п. Нельзя быть мастером во всем, но и нельзя стать мастером в чем-то одном, не понимая остального. Вот что главное!

    Так что я за разделение труда :)

    ReplyDelete
  2. Roman: Позволю себе не согласится :) О процессах я вообще не упоминаю, а архитектуру упоминаю вскользь, и то, скорее упоминаю ее основы в дополнение к другим, уже чисто программистским навыкам и знаниям.

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

    Теперь насчет разделения труда. Конечно, я согласен, что без грамотного разделения труда никуда. Но я не согласен, что программист не должен знать о вреде курсоров или паттернах. В конце-концов, использование курсоров - это знание технологии, это его прямая обязанность, как и написание нормального, продуманного, расширяемого кода. Неужели этим должен заниматься девлид или архитект?

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

    А кроме этого (заведу несколько в сторону) неплохо бы иногда задумывать еще и над тем, зачем программист делает то, что он делает.

    ReplyDelete
  4. В жизни программиста еще, помимо технологий/процессов, важна туча вещей: в чем он одет, как относится к коллегам, что думает о бизнес-стороне задачи, что кушает на завтрак, как понимает/собирает требования, насколько "чисто" педалит, какое у него чувство юмора, сколько у него поинтов на rsdn'e и какая карма на хабрахабре.

    :). Я до сих пор верю в силу гугла. Кстати, а что такое дао?

    ЗЫЖ а по сути: *thumbs up*.

    ReplyDelete
  5. AlexS Согласен :) Я вот тоже пока не хочу. Хотя бизнес-анализ, планирование, архитектура - тоже интересные вещи.

    anvaka А еще есть семья, велосипед, горы, байдарки, музыка, путешествия, футбол, горные лыжи и т.д. :)

    Да, я тоже в него верю. Когда-нибудь он поработит мир ;) А еще я верю в википедию :) И вот что она говорит по поводу дао:

    "Дао (кит. 道, буквально — путь) — одна из важнейших категорий китайской философии. Конфуций и ранние конфуцианцы придали ему этическое значение, истолковав как «путь человека», то есть нравственное поведение и основанный на морали социальный порядок."

    PS. Спасибо :) Жаль, не смогу на твоей лекции по архитектуре побывать

    ReplyDelete
  6. :)) Извини, Санек, ты опоздал лет на десять ;). Твой уровень гораздо выше уровня "тренинга" для жуниоров. Да и потом, что в один час можно рассказать по архитектуре? Как можно впихнуть с самого начала то, чему учатся десятилетиями в один час :)?

    Не, уж лучше потратить этот час с пользой. Я вот отговариваю-отговариваю Майка Чалого не ходить, а он не верит :).

    ReplyDelete
  7. Майка туда идет подсрекать....

    А вообще по теме есть небольшое исключение.

    Я думаю есть технологии который больше важны на высоком уровне. Пример SharePoint, Dynamic CRM, Аксапта, всякие там SAP. Вобщемто основной поинт что есть дженерал пурпоз технлогии с ними я согласен. А есть заточенные на конкретный домен. Вобщемто на каком то уровне они становяться важнее даже чем подходы. Ведь какаря разница знаеш ты или нет ДДД, если в Дайнамиксе анемичная модель, да и это не существенно. Главное что архитект должен понимать что реализовать на Дайнамиксе приложуху на подобие нашего клиникал траил менджера, в десятки раз быстрее. При этом полученых бенефитов хватило бы для того чтобы покрыть отрицательные фишки этого продукта.

    ReplyDelete
  8. Да, Миш, я с тобой согласен. Есть ситуации, когда технологии диктуют подходы. Хотя даже в этих ситуациях у программиста есть куча способов написать каличный код или, наоборот, произведение искусства. Собственно, основной посыл заметки в другом, я уже писал :)

    ReplyDelete
  9. К спору о том, нужно ли программисту заниматься архитектурой.

    Для начала нужно уточнить, что архитектуру можно условно разделить на 2 подвида - макро- и микроархитектура. Макро - это зона отвественности системного архитектора, а Микро - программиста.

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

    Архитектор же не будет стоять над головой у программистов и следить, чтобы тот пользовался инсертами вместо курсоров или подсказывать, что синглетон - это очень опасно.

    ReplyDelete
  10. Заметка очень понравилась. А тем, кто настаивает на "разделении мух от котлет" в смысле роли архитекта от роли девелопера, скажу:
    1) в реальных проектах участникам часто приходится выполнять по нескольеко ролей, и роль архитекта зачастую выполняет senior developer, team lead, project manager или вся команда вместе
    2) есть такое понятие как "project's big picture", IMHO без видения которой девелопер врядли сможет на 100% качественно выполнить даже очень "автономный" кусок кода

    ReplyDelete