Saturday, May 17, 2008

Наш ответ Scott'у Hanselman'у

Чуть больше 3 лет назад Scott Hanselman - бывший архитектор Corillian, а теперь Senior Program Manager в Microsoft, автор интереснейших подкастов по программированию на платформе .NET и не только, соавтор нескольких книг и вообще очень уважаемый человек - опубликовал свой набор вещей, которые должен знать хороший .NET разработчик. Конечно, много времени утекло с тех пор, но вопросы остались. Немного порыскав в гугле я смог найти не так уж и много хороших ответов. В основном либо люди отвечают неполно, либо пытаются начать отвечать хорошо, но, как правило, через какое-то время бросают это занятие. Я бы хотел начать небольшой эксперимент и хочу предложить поучаствовать в нем всем желающим. Предлагаю попробовать всем дружно ответить на эти вопросы. Никто никого ни к чему не обязывает: есть время и желание - отвечаем или комментируем и улучшаем чужие ответы, нет этих двух составляющих - просто читаем, что пишут другие. Плюсы участия лежат на поверхности. Во-первых, не все вопросы легкие, для того, чтобы ответить, нужно разобраться с чем-то новым. Отсюда польза для человека, который взялся отвечать. Во-вторых, своим ответом вы сможете помочь другим людям, которые столкнуться с этой проблемой в будущем, что тоже не может не радовать. В-третьих, это действительно эксперимент. Эксперимент по созданию небольшого комьюнити, которое бы смогло успешно обмениваться знаниями и опытом. Думаю, это также будет полезно всем. В дальнейшем этот небольшой FAQ можно будет расширить за счет других вопросов. Возможно, из этого получится что-то интересное и полезное.

Итак, вопросов там около 100. Достаточно много для одного человека (думаю, частично в этом кроется проблема того, что остальные бросали на полпути), но в то же время вопросы разные и достаточно интересные, чтобы каждый нашел себе что-то более близкое. Меня сейчас интересует лишь, кто хотел бы участвовать в этом действии и в какой мере. Язык ответов, думаю, русский, по крайней мере для начала, т.к. хочется, чтобы все ответы были на одном и том же языке + чтобы их смогли прочитать люди, не знающие английский. Впрочем, над этим можно еще подумать. Еще один момент, требующий решения - место. В идеале это мог был бы быть вики, но я не знаю ни одного бесплатного. Если есть идеи - пишите, решим. Как вариант, можно попробовать поднять свой хостинг с вики, в принципе, выходы есть.

А пока выкладываю ссылки, которые нашел к текущему времени: http://www.ekampf.com/blog/2005/02/23/NETInterviewQuestionsFromScottHanselmanAnswersPart1.aspx http://sketch-in-dot-net.spaces.live.com/Blog/cns!A4F5926067C892F0!149.entry http://sketch-in-dot-net.spaces.live.com/blog/cns!A4F5926067C892F0!167.entry http://blogs.ittoolbox.com/visualbasic/operating/archives/some-interesting-net-questions-4216 http://blogs.ittoolbox.com/visualbasic/operating/archives/more-net-questionstyping-ii-4271 http://blogs.ittoolbox.com/visualbasic/operating/archives/more-net-questions-iii-4433 http://www.avneesh.com/Blogs/PermaLink,guid,22.aspx http://www.dotnetdoc.com/PermaLink,guid,d7c8a3e4-b151-4838-a1e9-114128ef1646.aspx http://www.dotnetdoc.com/PermaLink,guid,76b6a74e-011a-49c6-bbd1-745e6ca9dc68.aspx http://graysmatter.codivation.com/MyGrandmotherAndTheDifferenceBetweenProcessesAndThreads.aspx http://sendhil.spaces.live.com/blog/cns!30862CF919BD131A!575.entry http://sendhil.spaces.live.com/blog/cns!30862CF919BD131A!579.entry http://sendhil.spaces.live.com/blog/cns!30862CF919BD131A!583.entry http://sendhil.spaces.live.com/blog/cns!30862CF919BD131A!585.entry

Последний парень подошел к делу наиболее ответственно и ответил на 4 из 6 секций. Или поместил ссылки на ответы. Но в идеале я хотел бы, чтобы ответы были более развернутыми, хотя, опять же, использовать чужие наработки никто не запрещает. Лишь бы copyleft соблюдать :)

Sunday, May 11, 2008

Оценка уровня программиста

В недавнем разговоре с моим другом мы подняли интересный вопрос, с которым наверняка сталкивался каждый senior и lead при приеме нового человека на работу, в команду или даже просто в своей команде: как оценить реальный уровень программиста. Мой друг высказал интересную, но все же шуточную идею: junior хочет все переписать заново, middle и выше уже начинают понимать, что переписыванием заново проблема не решается, а за само переписывание клиент/руководство деньги просто так платить не будет. Однако в каждой шутке, как известно, лишь доля шутки: я сам работал с ребятами, которые хотели переписать весь проект или какую-то его часть за несколько недель или дней, аргументируя это тем, что их вариант будет работать лучше. Я на собственном опыте не раз убеждался, что навыков у подобных junior/middle людей просто не хватит на реализацию задумки, а предложение переписать возникает лишь за отсутствием других навыков, кроме написания кода с нуля. Люди посильнее никогда не стремятся переписать все. Они более трезво оценивают сложность задачи, свой уровень и уровень команды в целом, и, что самое важное, обладают навыками рефакторинга, которыми еще не обладают junior'ы и многие midlle'ы. То есть они могут, при необходимости, просто изменить нужную часть приложения, причем, как правило, в процессе имплементации новой функциональности, чтобы а) не напрягать никого оплатой/продажей отдельных тасков на рефакторинг, б) протестировать измененный функционал в комплексе вместе с тестированием нового. Второе, конечно, не всегда возможно, так как изменения могут быть глубоко в ядре, но тогда на помощь приходят unit-тесты, о которых эти люди, опять же, знают и умеют применять.

Итак, к чему это длинное вступление? К тому, что оценка уровня программиста очень сложная штука и очень сложно загнать кого-то в существующие рамки junior, middle, senior, lead, architect, etc. У меня есть свое видение данного вопроса, которое я сейчас изложу, но наверняка у читающих этот пост людей будет свое, дополняющее или опровергающее мое, и мне будет интересно его услышать.

Я не хотел бы сейчас останавливаться на моменте принятия незнакомого человека на работу или проект и попытке определить его уровень. Во-первых, для начала нужно выработать какие-то критерии оценки уровня в своей голове, чтобы потом умело их применять, а, во-вторых, пост тогда превратиться в сборник советов для собеседования, а их и так вагон и маленькая тележка. Также я специально не буду затрагивать личные качества программиста, такие как ответственность, исполнительность, коммуникабельность, быстрая обучаемость и др. Эти качества также можно и нужно развивать, но это тема отдельного разговора. Поэтому коснусь лишь непосредственно понимания уровня специалиста, которое потом можно использовать в различных ситуациях.

В данный момент в различных фирмах существуют разные подходы к оценке. Где смотрят лишь на технические знания, заставляя сотрудников сдавать тесты, где опираются на мнение руководителя, где проводят комплексную оценку, опрашивая сотрудников, руководителя и подчиненных по различным пунктам. Но практически везде забывают одну важную вещь, которая вроде бы лежит на поверхности, но ведет себя как потерянные очки, которые потом оказываются на носу: в программировании, как и во многих других сферах деятельности, нельзя давать единственную оценку уровню человека, можно давать лишь среднюю, выведенную определенным образом из менее общих оценок. Это как в английском языке: человек с reading и listening на уровне upper-intermediate может иметь pre-intermedite в общении и vocabular’е. Такого человека и обучать нужно соответствующим образом: с большим упором на менее развитые области. То есть, алгоритм оценки должен выглядеть приблизительно следующим образом: разбиваем необходимый набор знаний/умений на группы (критерии), оцениваем независимо каждый критерий и затем собираем все воедино в соответствии с необходимой формулой, используя те или иные коэффициенты усиления для критериев различной степени важности.

Второй ошибкой является сам набор критериев оценки. Почти всегда в таких случаях рассматривают лишь знание человеком различных технологий, паттернов, подходов, методологий, на оценку чего направлены различные тесты. В то время как оценивать нужно не знание, а понимание этих вещей. Хороший программист может не знать технологии JSP или JSF, т.к. он никогда в глаза не видел Java, но при этом, хорошо понимая принципы web-программирования и имея опыт ASP.NET или PHP, он с легкостью сможет разобраться со сложной проблемой и изучит новую технологию или язык очень быстро. Это как в школе: щелкать однотипные задачки может научиться практически любой, а вот понимать предмет на уровне, достаточном для решения нестандартных олимпиадных задач, могут единицы. То есть если человек знает, что есть определенный набор событий в жизненном цикле ASP.NET-страницы, это хорошо, но это junior уровень. Middle уже должен не просто использовать эти события, но и понимать, что происходит до них, и что их вызывает и с какой целью (что такое http-запрос и http-ответ, как они выглядят, что такое конвейер и что такое класс страницы вообще). Задача senior'а же уметь видеть полный поток выполнения запроса, знать особенности, понимать на более глубоком и абстрактном уровне все процессы, происходящие здесь, чтобы суметь в случае надобности разобраться со сложной проблемой. Именно на уровне понимания, на мой взгляд, и проходит одна из важнейших границ оценки специалиста.

Еще одним важным умением, которое приходит лишь с повышением уровня и может рассматриваться как некоторый критерий этого уровня, является умение перемещаться между уровнями абстракции. Junior-программисты часто не видят дальше своей маленькой задачи и куска кода, который они сейчас пишут. Из-за этого их код и отличается некоторой непродуманностью и их часто приходится поправлять, просить перенести тот или иной код в другой класс или даже на другой уровень приложения. С опытом, программист учится выходить на более высокие уровни абстракции: сначала на уровень понимания класса, потом на уровень взаимодействия между классами и объектами, как правило, при этом на ходу изучая паттерны проектирования. Затем приходит видение слоев и частей приложения, взаимодействия между ними и, наконец, умение видеть архитектуру и дизайн приложения в целом, с высоты птичьего полета. Если оценивать очень грубо, я бы сказал, что на этом этапе программист выходит уже на уровень middle+ или даже senior. Самое важное здесь: умение быстро перемещаться с уровня высокоуровневой архитектуры до уровня какого-нибудь куска кода и обратно, комплексная видимость кода приложения. Конечно, в крупных и даже средних приложениях очень сложно знать весь код, но это и не нужно – достаточно просто понимать, что делает тот или иной модуль или слой, а лезть ниже стоит лишь тогда, когда это действительно нужно. С этим сильный программист справляется без особого труда. Кроме того, умение видеть приложение в целом, пусть даже без особой степени детализации – это одно из самых важных умений lead'а и architect'а, без него далеко не уедешь.

С предыдущим умением также тесно связан т.н. системный анализ: умение анализировать задачу/требования, разбивать их на подзадачи, оценивать последние и создавать архитектуру приложения (то есть еще и выполнять некоторый синтез). Здесь также нужно уметь видеть взаимосвязи между задачами, требующими выполнения, и существующим либо будущим кодом. На этом уровне мыслят в основном программисты с уровнем senior и выше, которым часто приходится заниматься подобными вещами.

Еще один важный навык – умение писать качественный и продуманный код. Этот навык включает в себя целый комплекс других умений: знание и применение объектно-ориентированного дизайна и архитектуры, паттернов проектирования (естественно, в меру), рефакторинга, best patterns and practices в той или иной технологии, умение читать код глазами и смотреть наперед, предупреждая возможные ошибки и предусматривая дальнейшее расширение приложения. Все это приходит с опытом и желанием учится и в разной степени развито у программистов всех уровней, начиная от junior'а и заканчивая lead'ами и architect'ами.

Также нельзя оставлять в стороне и понимание процесса разработки. Процесс разработки серьезного ПО – это в 99% случаев командная работа, которой нужно управлять. Неуправляемые проекты очень часто превращаются в проекты разной степени безнадежности (привет всем «камикадзе»). Выбор правильной методологии, планирование работ в соответствие с ней – задача программистов не всех уровней, это работа людей уровня senior+, но понимание этой методологии, своей роли и задач в разработке очень полезно. Если мы сейчас пишем код, значит, мы пишем код, если фиксим баги, значит, фиксим баги, а не кто в лес, кто по дрова. В слаженно работающей по определенному плану команде, как правило, здоровая рабочая атмосфера и авралы случаются очень редко. По уровню данного понимания также можно оценить уровень специалиста.

И напоследок скажу еще об очень важном навыке: это навык постоянного саморазвития и расширения собственного кругозора. Развит этот навык у всех в различный степени. У кого-то есть желание изучать новые технологии и языки, читать книги, статьи, новости, технические блоги, слушать подкасты, смотреть вебкасты, ездить на конференции, постоянно быть в курсе событий и пробовать что-то новое, у кого-то – нет. Или да, но в меньшей степени. Однако тем, кто пренебрегает этим навыком, стоит сказать лишь одно: в индустрии, где действует закон Мура, нужно стараться двигаться с той же скоростью, иначе рискуешь остаться на обочине. Не в ущерб семье, личной жизни и хобби, ни в коем случае. Это вещи более важные и никакая работа не должна заменять человеку его настоящего развития, становления как личности или даже просто отдыха. Мы все же должны соблюдать разумный баланс в известном противоречии: жить, чтобы работать, или работать, чтобы жить. Но если уж мы все как минимум 8 часов проводим на работе, то пусть хотя бы малая толика этого времени уйдет на ваше развитие, как специалиста – это будет выгодно и вам, и вашему работодателю. Если не текущему, значит, следующему, который будет понимать подобные простые вещи.

Thursday, May 8, 2008

Крымские горы

Чатыр-Даг
Горный массив (яйла), расположенный в центральной части Крымских гор, между Алуштой и Симферополем, пятый по высоте в Крыму. Основные вершины – Ангар-Бурун (1453 м) и Эклизи-Бурун (1525 м, по другим источникам 1527 м). Переводится на русский как «Церковный мыс», так как на ней находятся практически уничтоженные развалины греческой церкви, называвшейся Панагия (Παναγıα – «Пресвятая»), куда греки раз в году восходили многолюдным ходом для молитв. Чатыр-Даг известен тем, что в его районе находится огромная куча пещер, в том числе всем известная Мраморная пещера. Это любимое место спелеологов, туристов и просто любителей Крымской экзотики.


Демерджи
Горный массив (яйла), расположенный возле Алушты. Название Демерджи (Demirci) в переводе с крымскотатарского означает «кузнец». В Средние века греки называли гору Фуна — «дымящаяся». Вершины — Северная Демерджи (1356 м.) и Южная Демерджи (1239 м.). На ее склоне находится известная Долина Привидений, а возле вершины располагается так называемая Голова Екатерины.


Ай-Петри
Гора, являющаяся одним из общепринятых и всеми любимых символов Крыма (переводится с греческого как Святой Петр). Является частью Ай-Петринской яйлы. Высота 1234 м, далеко не самая большая, но от этого не менее значимая. Зуб¬цы Ай-Петри состоят из четырех крупных (высотой 12-15 м) и ряда мелких отвесных пиков, образовавшихся при выветрива¬нии неоднородных рифовых известняков. На Ай-Петри можно подняться 3-мя способами: по дороге (машина, велосипед), по горным тропинкам (пешком) и по воздуху (на фуникулере).


Эти фотографии я сделал в походе, в который мы ходили на майские. К сожалению, к началу маршрута мы не попали, так как меня задержала работа, поэтому любоваться Чатыр-Дагом нам пришлось лишь снизу, куда остальные ребята уже спустились к моменту нашего приезда. Моей половинке это не так страшно – она уже была и на Чатыр-Даге, и на Демерджи, а вот мне было здорово обидно. Пришлось утешаться оставшейся частью похода и поездкой на Ай-Петри на фуникулере (не было времени подняться пешком, хотя очень хотелось). Это мой первый поход, поэтому еще успею везде побывать. Главное, что я понял, что горы – это одно из лучших мест на нашей планете и туда я буду возвращаться еще не раз.

Для затравки еще несколько фотографий. Все остальные – в моей галерее (1 и 2).