Помоги проекту - поделись книгой:
На новом проекте любое задание требует чуть более подробного обсуждения со старшими разработчиками. Не стесняйтесь задавать максимальное количество вопросов о том, как сделать лучше, какой код можно использовать в качестве примера, какие компоненты проекта стоит использовать. При написании кода обращайтесь за советом или консультацией: чем больше актуальной информации о проекте вы получите сейчас, тем легче будет ориентироваться в работе в дальнейшем.
В любом случае единственный способ начать писать код, подходящий вашему проекту, – это начать его писать. Не бойтесь ошибиться или сделать что-то не так: любой опыт несравненно полезнее, чем его отсутствие.
Тезисы
■ Читайте и анализируйте код нового проекта.
■ Используйте время ознакомления с новым проектом по максимуму.
■ Спрашивайте, спрашивайте и спрашивайте.
■ Не бойтесь допускать ошибки; разработчиков, которые приходят на новый проект и моментально пишут идеально подходящий код, не существует.
Задание
Просмотрите коммиты вашего проекта и найдите те, которые реализуют что-то новое. Попытайтесь понять, чем руководствовался автор кода, и оценить, насколько его код соответствует принципам проекта, общему стилю, подходам к решению задачи.
История из жизни
На одном из проектов с очень амбициозным и своенравным главным разработчиком мне пришлось 20 раз переписывать одну из своих первых задач. Сложность была в том, что мой код должен был выглядеть как его код, а писали мы очень по-разному. Задачу я все же завершил, но сделал для себя выводы о том, что нельзя заставить людей писать так, как хочется тебе, а не им. В дальнейшем этот пример очень помогал мне находить общий язык с новыми разработчиками на проекте. Каждый раз, когда мне хотелось, чтобы их код был похож на мой, я вспоминал эту историю и просто находил компромисс.
Код как документация
Многие из вас знают, что документирование кода – отличная и даже обязательная практика. Кто-то из вас слышал, что лучшая документация – это сам код, написанный так, чтобы он не нуждался в дополнительном описании. Оба утверждения верны, однако в реальной жизни вы чаще будете работать с кодом, документация и качество которого оставляют желать лучшего (не пугайтесь, вы же разработчик, а значит, сможете это исправить).
Документация – это очень широкий термин, охватывающий многие стороны проекта. Можно говорить о комментариях в самом коде, а также об обязательной документации в коде библиотек, если вы их создаете и предполагаете, что их будут использовать другие разработчики.
Подходы к созданию документации тоже бывают разными: это могут быть комментарии самих разработчиков или труд нескольких специалистов вашей команды, основная работа которых – составление документации проекта. Документация может писаться вручную, собираться автоматически из кода проекта или генерироваться из схем API. Сейчас мы будем говорить только о документировании кода как о наиболее частом случае.
В вашем проекте должно быть соглашение о том, что и насколько подробно надо документировать при работе над кодом. Если такого соглашения нет, следует руководствоваться здравой логикой (и любовью к коллегам). Золотое правило, на которое лучше всего опираться при принятии решения, – спросить себя, насколько код, который вы только что написали, будет понятен тому, кто находится вне контекста задачи и просто открыл файл в этом месте.
Хорошо ли названы переменные, методы и классы, которые вы создали? Позволяют ли они понять, что делают и для чего? Не будьте избыточны (Java, спасибо, что зашел): если вы написали метод add, состоящий из одной строчки кода и суммирующий два числа, не стоит писать к нему документацию. С другой стороны, если вы написали метод, который вычисляет плотность населения на квадратный метр, используя для этого анализ сигналов с мобильных телефонов, – пожалуйста, документируйте это так, чтобы за это выдали премию (а еще вы основательно наплевали на наши права и свободы).
Старайтесь комментировать код по возможности компактно. Краткие и емкие комментарии не будут отвлекать разработчиков при беглом осмотре кода, тогда как избыточная информация станет помехой и усложнит рефакторинг.
Хороший проект – это вкусный коктейль из качественно написанного кода, который не требует документации, и емких комментариев в местах, где трудно разобраться с ходу. Не каждый код можно сделать простым, иногда вам ничего не остается, кроме как описать происходящее словами (и это абсолютно нормально).
Несколько смешных примеров комментариев (надеюсь, вы не встретите подобного в вашем проекте):
// Dear maintainer:
//
// Once you are done trying to 'optimize' this routine,
// and have realized what a terrible mistake that was,
// please increment the following counter as a warning
// to the next guy:
//
// total_hours_wasted_here = 42
// I am not sure if we need this, but too scared to delete.
// When I wrote this, only God and I understood what I was doing
// Now, God only knows
return 1; # returns 1
// somedev1–6/7/02 Adding temporary tracking of Login screen
// somedev2–5/22/07 Temporary my ass
// I am not responsible of this code.
// They made me write it, against my will.
Тезисы
■ Пишите код как документацию.
■ Документируйте емким текстом.
■ Иногда код не может быть простым – документируйте!
Задание
Если у вас уже имеется некоторый опыт работы с проектом, проанализируйте места кода, которые вы хорошо знаете, и попытайтесь поставить себя на место человека, который видит этот код впервые. Смогли бы вы понять, что этот код делает? Не показалось бы вам, что было бы проще, окажись в том или ином месте текстовое описание правил выполнения или логики приложения?
История из жизни
На одном из проектов, где я работал, было принято решение комментировать весь написанный код, независимо от того, насколько он прост и понятен. Разработчики любят предсказуемость и простоту, однако оказавшись в ситуации, где формализм существует ради формализма, вы в итоге получаете что-то такое:
// check if operation was a success
if (isSuccess) {
// return success marker
return MARKER_SUCCESS;
}
Коллаборация
Вам часто придется работать над кодом, написанным не вами. Работа с чужим кодом – дело непростое: вы должны понять, как он работает, привыкнуть к стилю автора. Код может быть написан неидеально, запутанно или неряшливо. В любом случае вы должны уважать чужой труд.
Самое важное в коде – его безошибочная работа, поэтому, если вы видите неряшливый, недокументированный код, который при этом идеально выполняет свою функцию, не торопитесь дополнять его обильными комментариями и заниматься рефакторингом. В случае если ваша задача – избавить код от ошибок, у вас развязаны руки: сделайте все возможное, чтобы он стал лучше.
Если вы столкнулись с необходимостью расширить код или улучшить существующий, постарайтесь связаться с человеком, который его написал, это сэкономит вам массу времени. Даже если автор кода не вспомнит всех деталей реализации, он хотя бы сможет объяснить общее направление своей работы и указать на основные подводные камни, с которыми вы можете столкнуться.
Полагайтесь на тесты кода, который вы исправляете, либо напишите их, если позволяют задача и время: вы должны быть уверены, что не допустите новых ошибок. В данном случае будет лучше написать тесты на существующий код, после чего приступить к его исправлению. Таким образом, закончив, вы сможете проверить код уже написанными тестами и убедиться в том, что логика работы не нарушена.
При исправлении чужого кода старайтесь не втягиваться в конфликты. Иногда люди воспринимают работу над их кодом как сомнение в их профессионализме. Возможно, вы и сами испытываете то же чувство, если видите, что ваш код исправили. Будьте честны с собой и помните: ваша цель состоит в том, чтобы код работал корректно, быстро и без ошибок. Не позволяйте эмоциям или амбициям мешать вашему профессионализму. Поступайте так же и при общении с коллегами: напомните им, что ваша задача – не критика и сомнения, а работа с кодом, ни больше и ни меньше.
При исправлении кода старайтесь подстроиться под стиль автора, даже если он вам не близок, – этим вы сохраните читаемость, не добавляя фрагментации.
Тезисы
■ Уважайте чужой код.
■ Корректная работа кода всегда важнее его внешнего вида.
■ Если есть возможность, пообщайтесь с автором исправляемого кода.
■ Напишите тесты до начала исправлений и проверьте уже исправленный код.
■ Избегайте конфликтов с коллегами.
Задание
Если на вашем проекте есть практика код-ревью, постарайтесь принять в ней участие в роли как проверяемого, так и проверяющего. Если такой практики нет, уделите время просмотру свежих коммитов от коллег, попытайтесь проанализировать написанный ими код и подумайте, как вы смогли бы его улучшить. Будет здорово, если, выполняя это задание, вы найдете ошибку, – обсудите это с автором коммита, предложите помочь в исправлении.
История из жизни
Однажды ко мне обратился друг с просьбой посмотреть, правильно ли проходит его код-ревью. В то время он как раз устроился в новую компанию и его работу часто проверяли коллеги. Он пожаловался, что сам тон комментариев и претензии, которые они предъявляют, звучат агрессивно и неприятно. Сначала я не воспринял ситуацию всерьез, подумал, что проблема преувеличена, но желание помочь взяло верх и я ознакомился с комментариями к его коду. «Побивание камнями», пожалуй, самое мягкое сравнение, которое приходит мне на ум. Я не знаю, с чем был связан этот разгул немотивированной агрессии по отношению к новому человеку в команде, но в тот момент ситуация расстроила меня настолько, что я, на тот момент уже будучи lead-разработчиком, попросил друга предоставить мне слово на код-ревью. Я высказал все, что думаю о таком отношении внутри команды и о самой политике компании, которая это поощряет, после чего искренне посоветовал другу сменить место работы. Порой есть смысл тратить время и силы, чтобы попробовать изменить положение к лучшему, но эта ситуация была из разряда «собирай вещи и беги».
Отладка
Отладка по многим причинам должна занимать особое место в вашем сердце. Под отладкой мы подразумеваем любые действия, которые помогают проанализировать работу кода: от вывода сообщений от работающей программы в консоль или браузер до создания debug-сборки вашего приложения с последующим профилированием. Отладка кода – одно из самых лучших средств для анализа работы приложения и поиска проблем.
В зависимости от языка программирования проекта вам будут доступны разные способы отладки. Некоторые языки программирования предоставляют очень богатые возможности для отладки, другие, наоборот, не имеют их совсем. Но не стоит отчаиваться: даже работая с языками, чьи средства отладки минимальны, вы всегда сможете воспользоваться встроенными средствами диагностики, пусть даже это будет простой вывод на экран.
Самый простой (и старый) способ отладки – это непосредственный вывод на экран. Это может быть вывод информации о текущем состоянии кода в консоль, в браузер, в интерфейс приложения. Это быстрый и действенный способ: вы просто выводите на экран состояние переменных, результат выполнения функций и все, что сочтете необходимым. Однако я очень (ОЧЕНЬ) рекомендую настроить инструменты для отладки (отладчик), если они доступны для вашего языка программирования. Иногда настройка отладочных инструментов занимает какое-то время, но, поверьте мне, это сэкономит вам невероятное количество времени и нервов в дальнейшей работе.
Одно из самых главных табу – недосмотреть и оставить в проекте отладочный код (к примеру, вывод отладочной информации или искусственную паузу в выполнении кода). Это может не только нарушить работу приложения (вы удивитесь, насколько часто забытый в коде sleep становится в дальнейшем невероятной «оптимизацией», когда его наконец находят и удаляют), но еще и скомпрометировать данные клиентов, которые будут отображены в логах или записаны в файл и прочитаны людьми, для которых они не предназначены. Настройка отладочного инструментария избавит вас от таких опасных ситуаций.
Тренируйтесь работать с отладчиком, не идите коротким путем, решая проблему разбрасыванием выводов на экран по всему коду. Во-первых, это решение только кажется самым быстрым: в какой-то момент вы все равно столкнетесь с ситуацией, когда одного лишь вывода на экран будет недостаточно. Во-вторых, вы упускаете невероятно ценную возможность увидеть код так, как его видит интерпретатор вашего языка или операционная система при выполнении. Регулярная работа в отладчике при поиске ошибок или анализе кода позволит вам почувствовать себя машиной – видеть то, что видит она при выполнении кода, следовать тем же путем. Это поможет выработать интуицию и способность замечать потенциальные ошибки при написании кода.
Профилирование – отдельный подход к анализу кода: оно позволяет определить, насколько ваш код эффективен, обнаружить в нем медленные места, избыточные вызовы, утечки памяти или нецелесообразное использование ресурсов операционной системы. Этот инструмент используется не так часто, как отладчик, но вы должны уметь применять его, когда это необходимо (ваше приложение заняло всю оперативную память или накалило процессор так, что на нем можно зажарить стейк, – тогда закатывайте рукава и открывайте профилировщик).
Тезисы
■ Старайтесь обходиться без выводов на экран.
■ Найдите время на настройку отладчика, оно окупится с лихвой.
■ Пользуйтесь отладкой регулярно, не позволяйте себе утратить навыки.
■ Профилируйте, чтобы понять, насколько эффективно ваше приложение.
Задание
Найдите отладчик и профилировщик для языка программирования вашего проекта, если они доступны. Настройте их, разберитесь с документацией и принципами работы, командами и возможностями. Запустите код проекта и начните отладочную сессию, проходя по коду, который вы недавно написали. Попробуйте разные возможности отладчика, изменяйте состояние вашего приложения в реальном времени, нарабатывайте опыт, чтобы при необходимости быстро найти ошибку. Запустите профилировщик и определите, действительно ли приложение эффективно. Спросите старших разработчиков, существует ли практика профилирования вашего проекта, и если нет, то стоит ли ее ввести.
История из жизни
Из всех историй отладки мне запомнилась одна, когда мне казалось, что я вот-вот лишусь рассудка. Я отлаживал свое Windows-приложение, которое, в силу условий, поставленных клиентом, должно было использовать одну из стремительно устаревающих технологий OLE (если вы пишете с использованием OLE – простите, эта претензия не лично к вам). Моя головная боль началась в тот момент, когда я понял, что у приложения «течет память». Как и любой порядочный разработчик, я, разумеется, начал подозревать в этом свой код. Спустя неделю, лишившись огромной части нервных клеток и изрядно поседев, я смог найти утечку в одной из системных DLL Windows, датированную 1995 годом выпуска. Скажу честно, я искренне попытался найти авторов и сообщить им о найденной проблеме, но безрезультатно. Меня не покидает мысль, что все, кто хоть что-то помнил об этой библиотеке, либо сняли руки с клавиатуры, либо уже покоятся с миром. Покойтесь мирно, но нервов мне, конечно, жаль.
Инструменты и автоматизация
Работая над проектом, крайне важно создать среду, в которой вы наиболее эффективны, начиная от выбранных вами инструментов разработки и заканчивая операционной системой и «железом». Все должно работать так, чтобы вам было максимально удобно.
Единственное мнение, к которому следует прислушиваться в этом вопросе, – свое собственное. Вы чувствуете, что эргономическая клавиатура вам не подходит? В мусор ее. Вы чувствуете, что монитор, повернутый, как у всех коллег, на 90 градусов, вас раздражает? Поверните его так, как вам удобно. Вы чувствуете, что максимально эффективны в Emacs, а не в полноценной среде разработки, оплаченной вашей компанией? Что ж, вы сэкономили компании немного денег – работайте в Emacs.
Выбор инструментов – долгий процесс, и вам потребуется немало времени, чтобы определить, как и чем удобнее всего работать. Если вы постоянно пробуете новые инструменты и подходы, это тоже правильно. Как можно понять, что вам что-то подходит больше, если не испробовать все варианты? Как шеф-повар, как плотник, вы должны знать свои инструменты досконально.
Не бойтесь пробовать новые подходы. Вы разработчик, в нашей индустрии вещи успевают устареть, едва появившись. Если процесс выбора доставляет вам удовольствие, уделите ему побольше времени (можно даже рабочего, но я об этом не говорил). Найдите то, что подходит вам больше всего.
Старайтесь автоматизировать рутинные задачи. Вы знаете, что за день открываете более 100 файлов? Найдите и запомните shortcut на окно открытия файлов. Вам необходимо скачать множество файлов с внутреннего сервера? Найдите для этого утилиту или напишите короткий скрипт. Это кажется мелочью, но она сэкономит куда больше времени, чем вы думаете. Кроме того, вы сможете работать с разными областями IT, впитывать больше знаний и тренироваться в технологиях, с которыми раньше не сталкивались (возможно, вы даже решите написать свой первый скрипт на Perl).
Если вы работаете со сложным проектом, требующим комплексной процедуры загрузки или настройки, – автоматизируйте. Вы будете тратить куда меньше времени на подготовку к работе и вдобавок сможете поделиться своим решением с коллегами, чем облегчите жизнь всей команде.
Помимо прочего, автоматизация нередко приводит к созданию нового проекта, иногда весьма успешного. Часто необходимость автоматизировать какой-то процесс выливается в скучные рутинные действия, которые все выполняют одинаково. И в таком контексте новый проект, позволяющий упростить этот процесс, становится долгожданным и очень желанным инструментом.
Тезисы
■ Выбирайте инструменты самостоятельно.
■ Учитесь работать со своими инструментами, становитесь эффективнее.
■ Пробуйте новые инструменты и подходы.
■ Автоматизируйте рутинные задачи.
Задание
Постарайтесь запомнить все моменты в течение рабочего дня, которые требовали от вас рутинных действий. Определите, какие из них раздражали вас больше всего и что было самым скучным. Подумайте, как бы вы могли автоматизировать эту часть работы. Кажется ли она такой же скучной другим разработчикам проекта?
История из жизни
Мне всегда нравилось выбирать инструменты, пробовать редакторы кода, среды разработки, утилиты, инструменты автоматизации. Часто это давало преимущество в принятии решения о выборе инструмента – у меня уже был опыт и представление о том, что я хочу видеть и чем хочу пользоваться на проекте. У этого подхода есть и обратная сторона: чтобы сделать HTTP-запрос, я скорее напишу Python-скрипт, чем просто воспользуюсь cURL. Но это определенно не то, из-за чего я стану огорчаться.
Тесты
Тесты – это большая (и не всегда однозначная) часть любого крупного проекта. Тестирование предполагает проверку функций, корректности их работы, проверку ожидаемых результатов, и не всегда оно заключается только в тестировании кодом. Тестирование выполняется вручную или автоматически, этим могут заниматься коллеги-тестировщики, и (в самом худшем случае) у вас всегда будут тестировщики со стороны – пользователи вашего продукта.
Давайте сразу проясним один важный вопрос о тестировании: оно необходимо. Если у вас уже есть опыт работы, то, возможно, вы сталкивались с проектами без тестов, с разработчиками, которые относятся к тестированию и написанию тестов скептически, с руководителями и клиентами, которые не хотят тратить время и деньги на написание тестов. Но все это не имеет значения, потому что, каков бы ни был ваш проект, одно я могу сказать наверняка: ему нужны тесты.
Тема тестирования кода так же стара, как и само его написание. Никто из разработчиков не завершит работу над задачей, не проверив предварительно, работает ли она так, как требуется. В этом смысле каждый разработчик является тестировщиком.
В этом же кроется один из основных подводных камней, вынуждающих нас писать тесты или нанимать отдельных специалистов для тестирования кода. Разработчик не всегда способен корректно и полноценно протестировать собственный код. Отчасти это связано с тем, что, работая над конкретной задачей, мы упускаем из вида общую картину проекта; отчасти с тем, что, разрабатывая код, мы интуитивно осознаём его потенциальные недостатки и при тестировании пытаемся обойти их, проверяя лишь формально.
Тестирование проекта условно можно разделить на две большие категории: проверка человеком и проверка кодом. В идеальном мире нам не приходится выбирать из этих двух вариантов, так как они дополняют друг друга. В реальности же вы можете оказаться в ситуации, когда у вас нет ни тестировщиков, ни написанных тестов.
Тестирование человеком направлено на те проблемы, которые обнаружат пользователи вашего продукта (а они обнаружат, поверьте). Тестирование кодом направлено на формальный поиск ошибок, когда проверяются заранее подготовленные сценарии и данные.
Тестирование человеком всегда дает вашему проекту преимущество, потому что человек – это невероятная аналитическая машина, способная совершать фантастические глупости. Как разработчику вам никогда даже в голову не придут вещи, которые пользователь может сотворить с продуктом. Буквально. Просто поверьте мне на слово. Тестировщики, конечно, будут относиться к вашему проекту более бережно, однако, как опытные специалисты, они (как и вы в коде) интуитивно чувствуют слабые места и выявляют проблемы продукта куда быстрее и качественнее самих разработчиков. «Володя, я кликнул на это поле ввода три раза, отсоединил и подсоединил обратно клавиатуру, подпрыгнул на стуле, и наше приложение зависло» – да, готовьтесь именно к такому.
Тестирование кодом служит другим, не менее важным целям. Технические способы проверки кода весьма обширны, они включают много терминов и понятий. Не рассчитывайте испробовать все подходы к тестированию в рамках одного проекта. Задача формального тестирования состоит в том, чтобы проверить, насколько предсказуемо ведет себя код, основываясь на ваших требованиях и исходных данных.
Как правило, приступая к очередной задаче, вы, как разработчик, располагаете всеми данными, необходимыми для ее реализации (если нет – вы явно пропустили фазу анализа и сбора требований, ай-яй-яй). Следовательно, вы можете заранее описать сценарии работы еще не написанного кода. На этом принципе базируется методология разработки и тестирования TDD. Формализм и аккуратность будут вашими лучшими помощниками при написании таких тестов, однако знайте, что есть грань, пересекать которую считается дурным тоном. Однажды формализм заставит вас написать проверку того, что true является true. Встаньте, передохните и постарайтесь больше не превращаться в робота.
Не менее полезно в написании тестов то, что они помогают отслеживать регрессии кода. Покрывая тестами какую-то функцию проекта, вы с определенной долей уверенности можете на них положиться и использовать их, когда начнете эту функцию изменять. Провалившиеся тесты будут первым звоночком, что вы сделали что-то не то.
Как вы уже поняли, тестирование – это пункт, который нельзя просто пропустить. Писать тесты может быть очень-очень скучно. Тестировать функцию может быть невероятно утомительно. Но этим вы помогаете себе и проекту куда больше, чем думаете. Просто представьте: один провалившийся тест в вашей локальной консоли или один упавший продакшн-сервер с миллионом клиентов.
Используйте рабочее время, дополняя тестами код, который пишете. Включайте время на тесты в ETA задач, над которыми будете работать. Вы не сможете найти все ошибки, которые есть в коде, это правда, но, эй, мы же оба знаем, что вы хотите сделать его максимально стабильным. Это ваш профессионализм, это ваш код. Инвестиция своего времени в тестирование вернется вам вдвойне.
Тезисы
■ Тесты нужны, даже если вас убеждают в обратном.
■ Идеальный вариант, если ваш код будут проверять тестировщики или хотя бы ваши коллеги.
■ Терпите скуку формальных тестов, это окупается.
■ Один упавший тест – минус сотня недовольных клиентов.
Задание
Узнайте, используются ли на вашем проекте тесты. Проверьте их актуальность, настройте окружение для тестирования. Проведите тестирование проекта. Если тесты не выполняются или все красные от ошибок, поговорите с кем-нибудь из старших разработчиков или коллег, чтобы понять, в чем может быть проблема. Если у вас нет тестов или они не обновляются, обсудите ситуацию с коллегами, узнайте, почему работа над тестами не ведется. Выберите какой-нибудь код, написанный вами недавно, и попробуйте написать для него тесты (хотя бы для себя).
История из жизни
Вам никогда не встречался тест, который использует текущее системное время для проверки работоспособности проекта? Мне встречался. А знаете, чем будет знаменит такой тест, чем он запомнится вам, когда вы с ним встретитесь? А вы обязательно с таким встретитесь или даже напишете свой. Ваши тесты будут либо выполняться безукоризненно гладко, либо останавливаться с ошибками, и вы потратите уйму времени на то, чтобы понять: все, что меняется между их запусками, – это секунды, которые сменяют друг друга. Тик, тик, тик… Успешный тест, неуспешный тест, успешный тест…
Идиоматичность
У каждого языка программирования есть свое неповторимое «лицо», свой шарм и обаяние. Помимо синтаксиса и особенностей реализации, идиоматичность языка состоит в том, КАК на нем пишут. Сюда входят лучшие практики по написанию типовых решений, устоявшиеся в сообществе языка подходы к использованию языковых конструкций, стилистические особенности оформления кода и многое другое. Иными словами, идиоматичность языка напрямую определяется его применением. Нередко сами авторы языка описывают наиболее подходящие способы решения типовых задач, тем самым давая разработчикам подсказку, каким образом следует использовать их язык программирования.
Идиоматичность кода трудно воспринять с первого взгляда. Вам потребуются опыт и много практики для того, чтобы «почувствовать», как стоит писать на том или ином языке программирования. Скорее всего, рано или поздно вы сами придете к идиоматическому написанию кода. Однако я очень рекомендую вам ускорить этот процесс: читать определения авторов языка программирования, код стандартных библиотек и код значимых проектов, написанных на этом языке.
Нет ничего ужасного в том, чтобы писать на одном языке программирования так же, как вы писали бы на другом. Просто это непрофессионально. Не понимая, как писать код идиоматически, вы зачастую будете приходить к решениям, которые окажутся не такими эффективными, стабильными и элегантными, какими могли бы быть.
Воспринимайте написание идиоматического кода как разговор на иностранном языке. Без изучения правил и постоянной практики вы будете говорить с акцентом, и чем больше вы будете стараться говорить на иностранном языке как на родном, тем сильнее будет акцент и тем хуже вас будут понимать носители языка.
Все, что вам необходимо, чтобы начать писать идиоматический код, – опыт, знание правил и много-много практики. Наблюдайте, как пишут код люди, давно работающие с этим языком (для этого очень полезно читать исходный код стандартных библиотек, написанный авторами языка программирования). Читайте инструкции и документацию от создателей языка – они провели с его кодом куда больше времени и точно знают, как писать на нем с максимальной эффективностью. И конечно же, постоянно практикуйтесь в написании кода.
Если в течение карьеры вам пришлось многие годы писать на одном и том же языке программирования, не расстраивайтесь, что теперь пишете профессионально только на нем. При переходе к новому языку программирования вас будет тянуть писать на нем так, как вы привыкли писать на предыдущем. Это нормально, но следует четко понимать, что у разных языков разная идиоматичность и ее нужно уважать. Нередко для того, чтобы вы полностью восприняли новый язык, должен совершиться качественный переход (щелчок в голове): вы внезапно увидите язык как целое, его правила станут прозрачнее, а сама работа с ним – проще и естественнее. Не старайтесь ускорить приближение этого момента, практика и опыт, как всегда, сделают свое дело.
Тезисы
■ Каждый язык программирования обладает своей идиоматичностью.
■ Не пишите код на каждом новом языке программирования так же, как на предыдущем.
■ Читайте код, читайте советы авторов языка, практикуйтесь.
■ Если «заржавели» на одном языке, не бойтесь переключиться на другой и потратить время на его изучение.
Задание
Если у вас уже накоплен определенный опыт в работе с одним языком программирования, найдите несколько написанных на нем малоизвестных open source проектов. Проанализируйте их код: выглядит ли он идиоматически верным? Что бы вы смогли улучшить, опираясь на свой опыт работы с данным языком? Познакомьтесь с каким-нибудь новым языком программирования, совсем не похожим на привычный вам (я даже дам подсказку – берите Lisp).
Создайте свой небольшой проект и попытайтесь перенести маленький кусочек кода проекта на новый язык. Интуитивно ощутите разницу при написании кода на двух разных языках программирования, попробуйте переделать перенесенный код так, чтобы он соответствовал идиоматике выбранного языка.
История из жизни
Вместо десятка слов я покажу вам код. Здорово, если вы уже немного знаете PHP и JavaScript, вам будет легче оценить эту шутку:
$sum = 0;
$arr = new Array(1, 2, 3);
for ($i = 0; $i < $arr.length; $i++) {
$sum += $arr[$i];
}
Это JavaScript-код, но написанный так, будто это PHP. Нет, делать так не надо никогда.
Open source
«With great power comes great responsibility»[1] – это, пожалуй, самое точное описание, которое можно дать open source проектам. В своей карьере вы совершенно точно столкнетесь (и уже сталкивались) с open source решениями, которые будете использовать на благо ваших проектов. Приложения, библиотеки, сервисы, компоненты, утилиты – все, что вы можете представить, и еще немного сверх того.
С точки зрения кода open source – это самый большой помощник, который у вас есть. Современная коммерческая разработка не терпит задержек и никого не ждет. Рынок диктует условия и сроки. Продукт, который не был запущен «прямо сейчас», через месяц окажется задавлен конкурентами или потеряет актуальность. Вы не можете позволить себе потратить жизнь только на то, чтобы написать свой веб-сервер, когда захотите завести себе небольшой сайт-визитку. Поэтому все разработчики приходят к open source, используют его, стараются делать лучше, участвуя в разработке открытых проектов, берут и отдают одновременно.
Open source решения могут быть качественными или собранными на коленке, огромными или совсем крохотными, но вы будете их использовать, а значит, нужно усвоить несколько правил, которые спасут вас от хаоса открытых проектов и позволят наслаждаться их дарами.
Поделиться книгой: