January 7th, 2010

34. Удовлетворяйте свои амбиции на проектах open source.

(В оригинале - Fulfill Your Ambitions with Open Source)

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

К счастью, у этой проблемы есть решение: open source. Существуют тысячи проектов с открытым исходным кодом в самых разнообразных областях. Если вам нравится идея разрабатывать операционные системы, выбирайте любой из дюжины доступных проектов операционных систем. Если вы хотите работать над ПО обработки звука, анимации, криптографии, игр, как индивидуальных, так и онлайновых много пользовательских, или любым другим типом ПО, вы практически наверняка найдете как минимум один проект с открытым кодом, посвященный именно этой теме.

Разумеется, за все придется платить. В данном случае платить вы будете своим свободным временем. Вы ведь не можете разрабатывать open source проект в рабочее время – вы ведь должны выполнять свои прямые обязанности. А материальное вознаграждение за участие в open source проекте получают очень мало людей. У вас должно быть желание потратить часть своего личного времени. Чем больше вы будете работать над open source проектом, тем быстрее вы сможете реализовать ваши настоящие амбиции в программировании. При этом важно учитывать юридические детали вашего контракта с работодателем – там может быть пункт, запрещающий вам писать ПО определенной тематики даже в свободное время. А также вам нужно быть осторожным, чтобы нигде не нарушить закон в связи с авторскими правами, патентами, торговыми марками и промышленными секретами.

Open source предоставляет неограниченные возможности для мотивированного программиста. Во-первых, вы начнете общаться с теми, кто уже занимается тем, что вам интересно, и сможете многому научиться, изучая их код. Во-вторых, вы сами начнете помещать свои идеи и код в проект. Не каждая ваша идея будет принята, но какие-то из них будут. А вы получите новый опыт, работая над проблемами проекта. И в-третьих, вы встретите людей с теми же самыми интересами, что и у вас – такая open source дружба может длиться всю жизнь. И в-четвертых, когда вы станете компетентным участником проекта, вы сможете внести свой вклад в технологию, для вас интересную.


Начать работать с open source проектом достаточно несложно. Документация по необходимым инструментам (системы контроля версий, редакторы, языки программирования, компиляторы) обычно присутствует в изобилии. Найдите интересный для вас проект и изучите используемый в нем инструментарий. Документации непосредственно о самом проекте обычно крайне мало, но это не играет большой роли. Ведь лучший способ чему-то научиться – это изучить код самостоятельно. Если вы хотите присоединиться к проекту, вы можете предложить помощь в составлении документации. Или в написании тестовых сценариев. И хотя это может звучать не слишком захватывающе, правда в том, что написание тестовых сценариев для чьего-то чужого кода – один из самых быстрых способов обучиться чему-то новому. Просто пишите тестовые сценарии. Хорошие тестовые сценарии. Находите ошибки. Предлагайте исправления. Ищите друзей. Работайте над интересным для вас проектом. И удовлетворяйте свои амбиции.

Автор оригинала - Richard Monson-Haefel

Перевод мой, при использовании ссылка на мой живой журнал обязательна!

17. Комментируйте лишь то, что не ясно из кода

(В оригинале - Comment Only What the Code Cannot Say)

Различий между теорией и практикой гораздо больше на практике, чем в терории – это как нельзя более актуально применительно к комментариям. В теории идея комментариев заключается в том, чтобы «объяснить то, что происходит, дать больше деталей». Чем же желание объяснить может быть плохим? Однако на практике комментарии часто начинают приносить вред, а не пользу. Как и в любом другом деле, написание хороших комментариев – это умение. И значительная часть умения состоит в том, чтобы знать, когда их вообще писать не надо.

Если в коде есть ошибки, то компилятор, интерпретатор или другой подобный инструмент это сразу же обнаружат. Если ошибки есть на функциональном уровне, то ревью, статический анализ, тестирование и эксплуатация рано или поздно будут приводить к их обнаружению и устранению. А комментарии? В книге “The Elements of Programming Style” Kernighan и Plauger заметили, что «комментарий имеет нулевую или отрицательную ценность, если он неправильный». И такие комментарии часто сильно засоряют исходный код, оставаясь там долгое время, в отличие от ошибок в самом коде. При этом такие комментарии постоянно приводят к отвлечению внимания или даже к дезориентации того, кто этот код сопровождает.

А что, если комментарий не является технически неправильным, а лишь не приносит дополнительной ценности? Такие комментарии – это шум. Комментарий, повторяющий код, не дает читателю никакой дополнительной информации – повторение одного и того же сначала на языке программирования, а потом на человеческом не делает код более понятным. Закоментированный кусок кода не выполняется, поэтому не несет ничего интересного ни во время выполнения, ни для изучающего код. К тому же такой код очень быстро устаревает. Система контроля версий делает то, для чего предполагалось оставить закомментированный код, а именно отслеживание изменений, гораздо лучше.

Обилие «шумовых» и вообще неправильных комментариев в коде приводит лишь к игнорированию комментариев вообще. Программист легко может сделать что-нибудь, что может повлечь реальную проблему – игнорирование действительно важного комментария: спрятать все комментарии, настроить IDE так, чтоб комментарии отображались цветом фона, удалить все комментарии при помощи скрипта или еще что-нибудь подобное. И чтобы предотвратить такой сценарий, к комментариям надо относиться так, словно это не комментарий, а код. Любой комментарий должен иметь свою собственную ценность для читателя, в противном случае его не надо писать вообще, удалить написанный или же переписать заново.

Что же считать ценностью? Комментарий должен сообщать что-то, чего код не сообщает и не может сообщить. Желание написать комментарий, содержимое которого может быть видно из кода – это сигнал к изменению стиля кода так, чтобы код говорил сам за себя. Вместо объяснения непонятных имен функций, классов или полей, просто переименуйте их. Вместо комментирования секций длинной функции разбейте ее на несколько мелких и назовите их адекватными именами. Лишь то, что вы на самом деле не можете «сказать» в коде, является кандидатом на комментарий.

Комментируйте лишь то, что код не может сообщить в принципе, а не то, что он не сообщает сейчас.

Автор оригинала - Kevlin Henney

Перевод мой, при использовании ссылка на мой живой журнал обязательна!