Начало
Валера по-прежнему работает тимлидом в одной большой IT-компании одной большой среднеазиатской страны. В работе находится несколько крупных проектов и, судя по сияющим лицам специалистов по маркетингу и продажам, в скором времени их станет значительно больше. На эту же мысль Валеру наводит приглашение на совещание, которое он получил от технического директора. Тема совещания — расширение направления образовательных систем.
На следующее утро в зале для совещаний собрались ключевые сотрудники направления. Технический директор (для тех, кто с ним еще не знаком, — его зовут Иван) сразу перешел к сути вопроса: «Приветствую всех! Как вы знаете, некоторое время назад мы поставили перед собой цель расширить присутствие на рынке и для этого открыли новый офис продаж. Так вот, эта стратегия сработала. Через месяц мы подписываем договор на разработку и внедрение платформы дистанционного образования. Проект очень интересный, но пока не об этом. Чтобы его потянуть, нам нужно срочно формировать новую команду в направлении образовательных систем.»
«Опачки!» — пронеслось в голове у Валеры. Он ясно понимал, что сейчас на рынке очень мало свободных разработчиков, и за месяц найти нужное их количество будет практически невозможно. Он поделился этими мыслями с коллегами. Подискутировав некоторое время, участники совещания пришли к следующему решению. Из других команд направления в новую будет выделено три сильных специалиста. И во все команды будут приняты стажеры — вчерашние студенты или старшекурсники, которых нужно будет обучить. Обучить быстро, чтобы обязательства по всем проектам не пострадали. Валера становится тимлидом новой команды. Решено.
Через две недели в новый кабинет новой команды неуверенно зашел молодой парень. Он подошел к столу Валеры и представился: «Ержан — ваш стажер». Валера впервые увидел человека, с которым до этого только переписывался в почте, давал задачи и проверял их решение. И с которым ему долгое время предстоит трудиться на одном из самых важных проектов компании.
«Присаживайся» — махнул в сторону стула наш герой — «Я тот самый Валера, который заочно мучил тебя последние полторы недели. У нас в компании действует правило, что к каждому стажеру прикрепляется наставник. Он помогает стажеру в выполнении заданий, дает рекомендации, что и в каком порядке изучать. В общем, моя задача — рассказать тебе все то, что я знаю сам. Со всеми вопросами также обращайся ко мне». Ержан улыбнулся: «Супер! Я думаю, это поможет мне в разы быстрее войти в курс дела и начать решать реальные задачи». Валера отметил про себя, что у парня правильная мотивация.
Мотивация мотивацией, но Валере еще нужно было понять, как за несколько недель из человека, потрепанного отечественной системой образования, сделать специалиста, способного самостоятельно решать задачи. И решать их качественно и в срок. Для этого нужно будет систематизировать весь тот опыт, который Валера получил за долгие годы своей карьеры, и постараться быстро передать его стажеру. Задача не простая, но оно того стоит. Глядишь, кто-нибудь потом книгу про это напишет.
А вообще, на чем сконцентрироваться? Что отличает плохого программиста от хорошего? Почему одному ты боишься дать задачу, зная, что придется постоянно подключаться, отслеживать статус и переписывать половину кода, а другому дал постановку, объяснил детали и спокойно пошел заниматься своими делами? Может один из них хорошо знает язык программирования, а другой не очень? Нет, не то. Валера насмотрелся на людей, проштудировавших не одну книгу по языку программирования, но не умевших спроектировать простейшего приложения. Так, подождите… спроектировать… Вот оно! Хороший разработчик обязан уметь проектировать. И на развитии этого навыка нужно сконцентрироваться в первую очередь.
Теперь нужно донести это Ержану. Валера начал неожиданно: «Требования меняются всегда». Увидев удивленный взгляд своего собеседника, он продолжил: «Твоя основная задача как разработчика — реализация требований пользователей создаваемой системы. Так вот, пользователи — очень ветреные создания и никогда сразу не знают, что им нужно. Только после того, как они увидят первую версию системы, их требования начинают проясняться и зачастую сильно меняться. И ты должен писать код так, чтобы каждый раз, когда ты будешь узнавать, что функционал должен работать по-другому, ты радовался. Потому что созданный тобой дизайн позволит легко реализовать эти требования, и система станет чуточку лучше.»
Валера потратил еще некоторое время, объясняя Ержану почему правильное проектирование так важно. Он рассказал о том, как на ранних этапах своей карьеры работал с плохо спроектированными системами. Необходимость даже малейшего изменения в них вызывала панический страх у всей команды. Ведь никто не знал, в каком месте после этого изменения система поломается. И хорошо, если о поломке сообщат тестировщики. Ситуации, когда об этом сообщали бизнес-пользователи, не относились к самым приятным воспоминаниям Валеры.
Валера резюмировал: «Система, которую мы начнем разрабатывать через несколько недель, большая и сложная. И ты не будешь сидеть там на исправлении багов. Ты будешь полноценным участником разработки. Так что будь готов к погружению в мир гибкого объектно-ориентированного проектирования». «Всегда готов!» — выскочила из подсознания Ержана услышанная в каком-то фильме фраза. А еще он подумал, что ему начинает тут нравиться.
Первый день. Первые истины
Когда на следующий день Ержан пришел на свое рабочее место, первое, что он увидел, было две книги, лежащие возле монитора. «Совершенный код» Стивена Макконнелла и «Идеальный программист» Роберта Мартина. Попросив Валеру объяснить, почему на столе лежат именно эти книги, в ответ он услышал: «Первая книга рассказывает о качествах хорошего кода. Вторая книга рассказывает о качествах хорошего программиста. Мне кажется, они отлично дополняют друг друга. Одного без другого не бывает. Прочитав эти книги, ты сможешь значительно ускорить свое развитие. К тому же, хорошие книги вдохновляют. Это важно для успеха.»
Закончив с книгами, Валера вкратце объяснил, какую систему они будут разрабатывать. Не так давно Министерство образования создало Институт дистанционного образования, перед которым поставило задачу разработать новую модель предоставления образовательных услуг. В результате родилась концепция площадки, на которой преподаватели из разных вузов публикуют свои курсы, а студенты на основании учебного плана выбирают нужный для себя набор. Каждый преподаватель указывает цену прохождения своего курса. И студенты на основании отношения цены и качества выбирают оптимальный для себя вариант. Институт предполагает, что этот механизм приведет к стимулированию конкуренции между преподавателями и в целом повысит качество дистанционного образования.
«А наша компания должна разработать платформу для запуска этой модели» — продолжил объяснять Валера — «Это будет веб-решение и писать его мы будем на платформе .NET и языке C# в частности. Предлагаю сейчас обсудить модули системы и выбрать тот, в разработке и проектировании которого будешь участвовать ты.» После непродолжительного обсуждения коллеги решили, что это будет модуль проверки выполненных заданий.
Ноутбук Ержана до сих пор был у специалистов технической службы, которые устанавливали на него все необходимые инструменты. Так как отдадут его только завтра, Валера решил использовать это время, чтобы пока не обсуждать детали конкретной задачи, а вместо этого донести до Ержана те вещи, понимать которые должен каждый программист. И чем раньше он их поймет, тем лучше.
Валера начал со своего любимого вопроса: «Что такое объектно-ориентированное программирование и для чего его придумали?» Ержан удивился простоте вопроса и тут же ответил: «Это знает любой студент. Объектно-ориентированное программирование позволяет описать в коде объекты реального мира. Предположим, есть автомобиль, у него есть колеса и другие механизмы. Мы можем создать соответствующий класс и с помощью него управлять автомобилем и использовать его в программе.»
Настало время Валеры: «То, о чем ты рассказал, верно. Но это не главное. На самом деле, главная цель ООП — борьба со сложностью. Объясню, о чем я. До появления ООП доминирующей моделью разработки было процедурное программирование. Но по мере того, как системы становились сложнее, процедурный подход начал пробуксовывать. Сопровождение и развитие кода стало занимать очень много времени. А все из-за того, что процедуры не позволяли в должной мере отделить компоненты системы друг от друга; изменение одних процедур влияло на поведение других. ООП придумали для того, чтобы решить эту проблему. Объектный подход позволяет разделить программу на независимые и изолированные компоненты. И изменение одних никак не влияет на поведение других. К тому же, мозг человека весьма слаб и не может в один момент времени охватить всю систему целиком. А класс позволяет концентрироваться на отдельной части системы, понимать и работать с ней, уменьшая общую сложность задачи.»
Подумав пару мгновений и вспомнив свой первый проект, Валера добавил: «Еще важно осознавать, что использование ООП-языка автоматически не дает все эти преимущества. Мне доводилось видеть, как на том же C# писали полностью процедурный код со всеми сопутствующими проблемами. Нужно понимать объектно-ориентированное программирование и объектно-ориентированное проектирование и уметь их правильно использовать. Тогда тебя ждет счастливая и плодотворная карьера. И еще ты не подумай, что сейчас применяют только лишь ООП. Существуют и другие подходы, каждый из которых используется в своей области. Но для нас, как для разработчиков корпоративных систем, ООП очень важно.»
Начав с ООП, следующим логичным шагом было рассказать Ержану о слабой связанности (или loose coupling, если пользоваться англоязычной терминологией). Классы позволяют разделить код системы на отдельные части — это хорошо. Но еще более важно, чтобы эти части как можно меньше знали друг о друге и были максимально независимы. Тогда изменения в одном классе не будут влиять на другой класс. К тому же, систему будет удобно разрабатывать командой программистов, распределив независимые компоненты между ними. Слабая связанность — качество, к которому нужно стремиться всеми силами. Но сделать это сложнее, чем кажется. Связи между компонентами системы могут проявляться разными способами, как явно, так и неявно.
Спустя некоторое время, потраченное на объяснения, Валера посмотрел на задумчивое лицо Ержана и поспешил его успокоить: «Не переживай, если ты не до конца понимаешь, о чем я говорю. Мы в компании фанаты гибких методик разработки и в проектировании придерживаемся такого же подхода. Начиная с завтрашнего дня ты приступишь к реальной задаче и постепенно будешь оттачивать свои навыки. А на сегодня теории хватит. Предлагаю тебе пройтись по офису, посмотреть, как тут все устроено, и познакомиться с людьми.»
Ержан поспешил воспользоваться советом Валеры. Оставшееся время он потратил на общение со своими новыми коллегами. И каждый из них выдавал Ержану порцию новой информации. Так, он узнал, что существует магическая аббревиатура SOLID, описывающая основные принципы объектно-ориентированного проектирования. А еще оказывается умные люди придумали готовые рецепты для решения разных задач программирования. Они называются паттерны проектирования. Конечно, Ержан сразу мало что понял, у него лишь появилось стойкое желание во всем этом разобраться и научиться писать крутой софт.
Так прошел первый день Ержана в его новой компании. После того, как часы показали 18-00, он попрощался с коллегами и направился домой. Но через несколько минут вернулся, взял со стола «Совершенный код», еще раз махнул всем рукой и вышел из кабинета.
Продолжение следует…
P.S. Эта начальная статья из серии статей про тимлида Валеру, стажера Ержана и гибкое проектирование. В следующих статьях будет описан тернистый путь, на котором Ержан будет реализовывать требования, писать много кода и параллельно изучать принципы гибкого объектно-ориентированного проектирования.
P.P.S. Самую первую статью про Валеру можно найти здесь.
P.P.P.S. Все совпадения с реальными людьми и событиями вымышлены.
Комментарии (38)
masterL
25.05.2015 19:00Вместо Совершенного кода, я бы джуниору дал «Принципы паттерны и методики гибкой разработки», того же Мартина. Не потому что они равноценны, а потому что «Совершенный код» очень тяжелый к прочтению, и на нем можно надолго застрять.
Lailore
25.05.2015 19:58+1Можете описать тяжесть прочтения «Совершенный код»?
AllexIn
25.05.2015 20:24+5Как вы себе это описание представляете?
Книгу просто тяжело читать. Почти также тяжело как спецификацию С++ от Страуструпа. Язык хороший, но читать все равно тяжело.
Я раза четыре брался… До сих пор целиком не осилил. :(
masterL
25.05.2015 20:49+9В обучении чему-либо я использую итеративное усложняющееся чтение.
Когда по одному и тому же материалу сначала берется самый простой вариант изложения, чтобы построить каркас для знаний, потом более сложный, потом еще более сложный и т.д. Потому что информация лучше запоминается, тогда когда она связывается с уже какой-то другой запомненной информацией, иначе уже через несколько дней она забудется (кривая забывания эббингауза).
«Совершенный код» — это огромный объем информации написанный сухим языком. Тяжесть чтения в том, что у джуниора нет необходимого бэкграунда к которому эту информацию можно привязывать, он просто все забудет после прочтения или надолго застрянет на этой книге, пытаясь качественно усвоить материал.
Myosotis
26.05.2015 13:25Сухой язык, много воды, отступлений, отсылок и размышлений автора. Приходит понимание, что поверхностное чтение не принесет пользы, что надо основательно проникнуться каждой страницой. Но потом смотришь на количество страниц, и возникает вопрос: а что, если это пустая трата времени? Краткость — сестра таланта. Например, «55 верных способов улучшить программу на C++» гораздо приятнее для прочтения книга.
mitro Автор
26.05.2015 04:31+1Тут я полностью опираюсь на свой опыт. Как раз джуниором читал «Совершенный код» и он помог мне значительно улучшить качество кода. И в своей нынешней работе советую эту книгу приходящим к нам молодым разработчикам. Они высоко оценивают эту книгу.
vabue
30.05.2015 14:53На хабре её как-то ругали.
masterL
30.05.2015 15:09Да, я читал эту статью Сергея Теплякова, но все равно считаю эту книгу, замечательной для начинающих.
stebunovd
26.05.2015 00:38+4Еще одна хорошая книжка для начинающих и не только — «Программист-прагматик» Эндрю Ханта и Дэвида Томаса. Классика, читается легко, дает ценные советы как по подходу к работе программиста в целом, так и по проектированию.
mitro Автор
26.05.2015 04:33Да, согласен с вами. Думал про нее, когда выбирал, какие книги упомянуть.
Artem_zin
27.05.2015 20:49+1«Программист-прагматик» — отличная книга, как для начинающих, так и для более опытных разработчиков.
По чистоте и качестве кода лучше читать статьи и блоги от разных авторов, в какой то момент можно увидеть и осознать, что в статьях разных авторов, написанных о разных языках и парадигмах (ООП, ФП) есть некие общие мысли — это и есть общие критерии чистоты и качества кода, ну и, конечно, потребуется пара лет программирования.
«Совершенный код» для начинающих как-то полезен и понятен первые страниц 50-100, а для опытных разработчиков читать сухой текст о довольно очевидных вещах неинтересно и плохо цепляет.
Вот это всё, конечно же, имхо.
Кстати, лайфхак для студентов — в универе есть библиотека! Экономьте деньги на книгах по разработке, методологиям и, особенно, по языкам программирования (самые одноразовые книги, потом просто пылятся на полке и устаревают с бесконечной скоростью).
ad1Dima
26.05.2015 07:47Так, он узнал, что существует магическая аббревиатура SOLID, описывающая основные принципы объектно-ориентированного проектирования. А еще оказывается умные люди придумали готовые рецепты для решения разных задач программирования. Они называются паттерны проектирования. Конечно, Ержан сразу мало что понял, у него лишь появилось стойкое желание во всем этом разобраться и научиться писать крутой софт.
Вот серьёзно? где-то в ВУЗах это не дают? (Ержан вроде как мотивированный и изучил бы если б давали)mitro Автор
26.05.2015 08:00Тут акцент на казахстанских реалиях. К сожалению, они таковы, что в большей части случаев люди узнают про эти вещи только когда приходят на производство.
i_user
26.05.2015 08:08+3Нам тоже такого не давали, а ведь, на минуточку, МГУ и все-такое. В России тоже с computer science все довольно таки плохо. И я, наоборот, очень рад, что есть факультеты, где такое рассказывают, чем печалюсь обратному.
А еще. А еще у меня есть стойкое подозрение того, что есть некоторые концепты, которые можно реально понять только лишь собственной болью. SOLID — один из них. Вообще, это довольно таки поздний концепт, по моему мнению. По крайней мере я не знал людей, которые начинали писать действительно SOLID код до тех пор, пока они не начинали писать грамотные тесты, пока они не осваивали методологий разработки(в боевой обстановке, ессно), как например Code-Review и так далее. Так что в университете о них, конечно, рассказывать, прикольно, но рано. (Если вы, конечно, не про MIT)ad1Dima
26.05.2015 08:13Я про НГУ и колледж информатики при нем. Тот же SOLID нам рассказывали на занятиях по проектированию, понятное дело полностью его осознать там трудно.
По паттернам был отдельный курс с семинарами и прочими радостями. Правда читал его молодой парень по бумажке, но реальный прогер из Алавара. Да и на других предметах преподы старались про них говорить.
Вероятно дело в том, что наш универ старается привлекать практикующих специалистов на все дисциплины.i_user
26.05.2015 08:21+1О, НГУ это здорово :-) Да и то, что людей из индустрии привлекают — тоже здорово. Поздравляю с хорошим и правильным образованием :-)
Но общего тезиса это не отменяет. Знание правильных концепций без правильного опыта приводит к очень разнообразным и интересным ошибкам. Видел довольно много кода, который порочит концепции паттернов, ООП, ФП и другие.
Вообще, все больше прихожу к необходимости групповых дипломов на IT специальностях)
ad1Dima
26.05.2015 08:46+1Но общего тезиса это не отменяет. Знание правильных концепций без правильного опыта приводит к очень разнообразным и интересным ошибкам. Видел довольно много кода, который порочит концепции паттернов, ООП, ФП и другие.
Безусловно
Вообще, все больше прихожу к необходимости групповых дипломов на IT специальностях
если вы про то, что несколько человек над одним проектом работают, то оно у нас у большинства, наверное, так и было. У нас ещё часто дипломы пишутся при лаборатории Parallels(иногда даже связанные с внутренними продуктами компании) или Intel(вот тут обычно с интелом никак не связанные), и просто при местных фирмах. Возможности научиться есть. Было бы у студентов желание.
mdaemon
26.05.2015 10:41+1Каждый раз что то подобное объясняю новым сотрудникам, будем надеется наконец то вы изложите это литературно :)
mitro Автор
26.05.2015 10:51Кстати, одна из идей статьи заключалась в том, что этот текст можно давать новым сотрудникам. И за 3 минуты, потраченные на прочтение, они смогут понять, как начать, и на чем лучше концентрироваться.
ilyaplot
26.05.2015 11:28+1С удовольствием почитал бы книгу в таком стиле изложения. Возможно, такие есть?
mitro Автор
26.05.2015 11:45+1Тот же самый «Идеальный программист» Роберта Мартина написан в похожем формате. Автор рассказывает истории, правда про себя. Еще «Принципы, паттерны и методики гибкой разработки на языке C#» того же автора. Там истории вперемешку с обычным стилем. А кроме этого подобных книг не встречал.
Я написал две статьи в этом стиле и планирую писать дальше. Кто знает, может постепенно появится и книга про Валеру :)masterL
26.05.2015 14:08Жалко, что того же Идеального программиста и Программиста-прагматика давно не переиздавали и в продаже их не найти.
mitro Автор
26.05.2015 14:13+1Кстати, с «Идеальным программистом» произошла интересная ситуация. Ребята из издательства «Питер» прочитали мою первую статью про Валеру, ссылка на которую есть в этом посте. И после этого оперативно выпустили электронную версию русского издания книги. Вот пост, где они про это говорят habrahabr.ru/company/piter/blog/245345 Так что теперь можно без проблем купить электронную книгу.
Alexeyslav
26.05.2015 15:58О, если б всё в этом мире было идеально…
Нам досталась на поддержку система которую наверно специально проектировали так чтобы в ней никто не разобрался. Без документации. Состоит на вскидку на 90% из костылей.mitro Автор
26.05.2015 19:07Это еще раз доказывает, что еще есть люди, не сильно понимающие, как нужно проектировать системы. И значит тема развития в этой области весьма актуальна. Я тоже насмотрелся на такой софт. Но после того, как мы плотно взялись за практики разработки и проектирования, много проблем ушло.
У нас есть команда, которую мы практически полностью сформировали из стажеров. Несколько месяцев интенсивного обучения и они разработали систему, которая сейчас весьма успешно внедрена в одном из городов Казахстана. Поддержка ее не доставляет особых проблем, так же как и развитие.
KHH
26.05.2015 19:41+1Вопросы могут показаться троллингом, но на самом деле нет.
1. Вот есть у нас код программы, системы. Как понять это хороший код или нет?
2. Чем отличается «Хоршее» ООП от «Плохого» ООП.
Интересуют субъективные! Критерии, управляющие метафоры. Т.е. не надо меня отсылать к книгам, статьям и стандартным определениям. Нужен ответ которые пропущен через субъективный опыт. И желательно не слишком обобщённый.
Дело в том, что, например, книга «Совершенный код» В процессе прочтения трансформируется в мозгу в набор неких утверждений(поверхностные структуры), а потом трансформируется(«проваливается») в некую систему в виде визуальных образов внутри сознания. И через неё пропускается в процессе написания программного кода.
Или например, чем отличается хороший и опытный программист от плохого и не опытного?
В процессе изучения платформы, системы, языка программирования программист строит некое представление — модель о том как работает платформа, язык программирования. У хорошего и опытного программиста эта модель более «точная» и «полная», более связная и разветвлённая. Нежели у неопытного и плохого.
Цель вопросов, достать вот эту модель из сознания\бесознательного. Что сложно. Т.к. Обычно начинают сыпать стандартными определениями, понимая под ним совсем другое.
mitro Автор
27.05.2015 08:00+3Я приведу аналогию с текстом. Если вы посмотрите на структуру моих статей, то увидите, что она состоит из небольших абзацев примерно равного размера, каждый из которых несет некую законченную мысль. И эти абзацы постепенно раскрывают ту картину и историю, которую я задумал. Может быть не всегда получается, но я иду по этому пути. И многие отмечают, что статьи читаются легко.
Та же самая история и с кодом. Если я открыл код и вижу небольшие блоки (классы, методы), которые написаны просто и имеют четкую и понятную цель, то я понимаю, что код хороший. Дальше я начинаю по ним идти и если они постепенно раскрывают передо мной замысел автора, то я еще больше утверждаюсь в своем мнении. То есть для меня хороший код — это такой код, который легко читать и понимать.
Что касается ООП, то в дополнение к вышеописанному я ожидаю увидеть там минимальное использование статических конструкций, активное использование интерфейсов, отсутствие злоупотребления наследованием. Ну и некие четкие уровни абстракции. Чтобы на каждом уровне я понимал, что делает система. И в детали углублялся только тогда, когда сам этого захотел.
Это мое метафорическое и субъективное восприятие. Было бы очень хорошо услышать такое видение от других людей, чтобы более полно раскрыть тему.
dordzhiev
Классный рассказ, жду продолжения!
Где же вас, Валер, в Москве найти можно? :)
Lailore
Кхм, все мысли из этого поста, почти под копирку из названных книг. + к ним, я бы посоветовал Кент Бек «Экстремальное программирование: разработка через тестирование», там очень хорошо описана борьба со сложностью, и + Марк Сииман «Dependency Injection in .NET»
dordzhiev
Я имею в виду, чтобы оказаться на месте Ержана. До Валеры еще далеко :)
mitro Автор
В статье не ставилось цели придумать новые идеи. Она больше ориентирована на то, чтобы в интересной форме дать основную информацию и замотивировать молодых специалистов на развитие. Плюс я описываю свое видение, как нужно работать со стажерами. Очень часто их садят на баги и успокаиваются на этом. Я применяю другой подход, который, на мой взгляд, хорошо работает.
mitro Автор
Спасибо за отзыв! Если в Москве нет, приезжайте в Астану ;)