Что-то у меня зачесались руки продолжить свой прошлый опус. Для начала хочется немного отойти в сторону. Я использую терминологию деления уровней программистов - Junior/Middle/Senior . Лично я не знаю ни одного четкого определения каждого из этих уровней и поэтому, говоря о переходе с одного уровня на другой – хочу в двух словах объяснить, что я под этим понимаю.
Предположим, перед группой стоит крупная фундаментальная задача. Например, сценарий авторизации. Программист уровня Junior, имея общее представление о том, что нужно делать – не понимает «что» и «как» надо написать, следовательно, старшие товарищи должны четко описать ему задачу. Программист уровня Middle знает «КАК» надо писать. Он знает, что должно быть бизнес-логикой, а что логикой уровня приложения. Senior знает «ЧТО» нужно писать. Т.е. например, может четко объяснить, почему для доступа к базе данных мы используем одни приемы, а не другие, и что это будет стоить.
И вот в прошлый раз мы остановились на уровне Middle. Если кому-то покажется что это уже достаточно высокий уровень и дальше можно не расти, так как зарплата уже и так хорошая – у меня снова плохие новости. Мы живем в капиталистическом мире и пока вам кажется, что вы достаточно ценный специалист чтобы не особо стараться выучить что-то новое – вырастет 2 таких же специалиста, которые согласятся делать вашу работу немного дешевле.
Четвертый год. Метод обучения – чтение документации. Начинается боль и страдание. Ни один программист не любит работать с плохо документированными библиотеками. Толпа программистов справедливо (подчеркиваю - справедливо) не комментирует свои разработки, так как старается, чтобы их интерфейс был максимально удобен для использующего. Но при этом все программисты, беря в руки плохо знакомую библиотеку (ну или просто рекомендованную в интернете) – моментально ищут документацию по ее использованию. У меня в голове витает один вопрос – «А кто эту документацию должен написать?». Любимый, на сей день, пример приложен на картинке.
Это кусочек документации платформы cake, которую я использую для сборки проектов под Teamcity. В итоге под конец этого периода обучения – я научился мастерски выдирать листинги кода, без понимания как они работают и «почему вот так». Может быть дело во мне? Может, но наличие в проекте блоков, которые буква в букву повторяют MSDN и порой даже комментарии заставляет думать, что я в этом не одинок.
Пятый год. Метод обучения – agile-методологии. Наконец-то попал в компанию, которая в серьез поддерживает подобные «современные» методологии. Или может не стоит радоваться раньше времени? Лично мне повезло и, не смотря на теплое отношение руководства к agile, мы не поддерживаем самые маразматические формы этой идеи вроде «покера планирования». Но и здесь не без недостатков. Один из самых очевидных путей обучения при такой методологии – ревью кода. То есть не просто за тобой как за новичком кто-то приглядывает и следит, что ты пишешь, а непосредственно частью рабочего процесса является оценка внесенных изменений. Это хорошо только на бумаге. На своей личной практике я скажу, что желание делать ревью изменений в 30 файлах и 10 коммитах болтается около нуля. Нужно иначе разбивать задачи? Возвращать на доработку? Ну дааа, только вот рабочее время ушло, руководство ждет результатов, и ты своей рукой результат работы хочешь помножить на 0. Возьмем более легкий вариант – небольшое изменение, покрыто тестами и всё компактно и прекрасно. А у ревьювера достаточно компетенций для оценки этих изменений? Кто должен делать ревью у Senior? Следовательно весь этот процесс будет стремиться к некоему среднему уровню программирования. А если вы хотите расти дальше – вы должны тащить за собой всех своих коллег, что не всем под силу.
И вот на такой позитивной ноте приходим в шестой год. Метод обучения – чтение исходного кода. К счастью за мою карьеру отношение компании Microsoft к концепции открытого кода изменилось и теперь если я возьму из документации какую-то конструкцию, которая сломается у меня в руках – я смогу выкачать исходники и хотя бы посмотреть, как это реализовано и что у меня может быть сделано не так. Заодно копание в таких местах может дать понять уровень собственного проекта или посмотреть, как используют инструменты языка другие специалисты в своих отраслях.
Дошел ли я сегодня до уровня Senior? Ну, судя по решаемым задачам и собственному определению – скорее всего да. Так ли это в объективном смысле – вопрос открытый. Я знаю только что нельзя никогда останавливаться в обучении. Всегда будет что-то, что полезно подучить. Даже если вы ниндзя в своей области программирования – полезно может быть поизучать политэкономию.