Перевод статьи «What Developers Should Actually Learn In College».
Забудьте о количестве строк кода
Разработчику приходится слышать множество сумасшедших, невероятных теорий относительно того, о чем может свидетельствовать количество строк кода. Не верьте ни одной из них. Просто смешно принимать какие-то решения, основываясь на таком показателе, как количество строк. В очень редких случаях эти числа могут вам что-то поведать, но во всех остальных они не значат ровным счетом ничего. Судить о качестве кода по количеству строк все равно что судить о качестве книги по числу страниц.
Кто-то может возразить, что чем меньше в приложении строк кода, тем легче этот код читать. Это верно, но лишь отчасти. Для меня более весомыми показателями хорошей читаемости являются следующие:
- Код должен быть последовательным.
- Код должен описывать сам себя.
- Код должен быть хорошо документированным.
- В коде должны использоваться надежные современные фичи.
- Код не должен быть излишне сложным.
- Код не должен быть непроизводительным (т. е., не следует намеренно писать медленный код).
Когда уменьшение количества строк кода отрицательно сказывается на любом из этих показателей, это ведет к проблемам. А на практике это уменьшение практически всегда задевает что-то из списка и, таким образом, это практически всегда ведет к проблемам. Но самое интересное в этом другое. Если вы стараетесь, чтобы ваш код соответствовал указанным критериям, в нем в любом случае будет идеальное количество строк, можно даже не считать.
Нет никаких «хороших» или «плохих» языков
Ну, разве что за исключением PHP. Шучу.
Люди все время говорят что-то вроде:
- C лучше, чем X, из-за производительности.
- Python лучше, чем X, благодаря своей лаконичности.
- Haskell лучше, чем X, потому что гладиолус.
Сводить сравнение языков к подобному простому предложению это практически оскорбительно. Это же языки, а не покемоны.
Не поймите меня неправильно: между языками действительно существуют различия. Просто на самом деле реально«плохих» языков практически нет (хотя есть много устаревших / мертвых языков). Каждый язык связан с собственным уникальным набором компромиссов. В этом отношении языки похожи на разные инструменты в наборе. Отвертка может делать то, на что не способен молоток, но можно ли сказать, что на этом основании отвертка лучше молотка?
Прежде чем я расскажу, как следует оценивать языки, я хочу кое-что прояснить. Случаев, когда выбор языка действительно имеет значение, очень мало. Есть вещи, которые очевидно нельзя сделать на каких-то языках. Если вы пишете код фронтенда, вам выбирать не приходится. Но в целом выбор языка это обычно одна из самых незначительных проблем проекта.
Есть несколько ключевых аспектов, на основе которых следует делать выбор:
- Количество доступных онлайн-ресурсов.
- Скорость разработки.
- Предрасположенность к багам.
- Качество и обширность экосистемы пакетов.
- Характеристики производительности.
- Спрос на рынке труда (прости, COBOL).
Некоторые языки сильно связаны с определенными сферами деятельности и повлиять на это вы не можете. Например, если вы занимаетесь наукой о данных, вам нужно будет использовать Python, R или Scala (возможно, Java). А если речь идет о вашем хобби-проекте, вы можете пользоваться всем, что вам нравится. У меня есть только одно строгое правило касательно выбора языка. Я не использую языки, если связанные с ними проблемы, с которыми я могу столкнуться, не имеют готовых решений на StackOverflow. Не то чтобы я не смог разобраться самостоятельно, просто это не стоит потраченного времени.
Читать код других людей тяжело
Чтение чужого кода это сложное дело. Роберт С. Мартин так говорит об этом в своей книге «Чистый код»:
«Несомненно, по времени чтение и написание кода относятся как 10 к 1. Чтобы написать новый код, мы постоянно читаем старый. Таким образом, облегчение чтения кода облегчает и его написание».
Я долгое время думал, что это только у меня проблемы с чтением чужого кода. Но постепенно я понял, что подобные трудности ежедневно возникают практически у каждого программиста. Чтение чужого кода можно сравнить с чтением на иностранном языке. Даже если вы хорошо знаете язык программирования, на котором написан код, вам все равно нужно приспосабливаться к стилю и выбору архитектуры. И это еще в случае, если автор написал последовательный и надежный код, а ведь мог написать и методом проб и ошибок. В общем, чтение чужого кода это действительно сложная задача. Есть несколько вещей, которые могут помочь вам в этом.
1. Ревью кода других людей очень сильно улучшит ваши навыки чтения. За последние пару лет я проверил изрядное количество пул-реквестов на Github. И с каждым новым пул-реквестом я чувствую себя все более уверенно, читая чужой код. По нескольким причинам пул-реквесты на Github особенно хорошо подходят для улучшения навыков чтения кода:
- Можно практиковаться в любое время. Нужно лишь найти open source проект, в котором вам хотелось бы принять участие.
- Вы практикуетесь в чтении в ограниченном контексте (PR связаны с отдельными фичами или багами).
- В этом деле требуется внимание к деталям, а это заставит вас оценивать каждую строку.
2. Второй «хак» немного более уникален. Эту технику я придумал сам. Благодаря ей мне удалось очень сильно сократить количество времени, необходимое, чтобы освоиться в незнакомой кодовой базе.
Определив стиль кода, который я хочу прочесть, я открываю vi и начинаю писать код в этом стиле. Когда вы пишете код в новом для себя стиле, это тоже улучшает ваши навыки чтения. Стиль будет казаться вам не таким чужим, поскольку вы его уже прочувствовали. Я стараюсь проделывать этот фокус, даже если просто просматриваю случайный проект на Github. Попробуйте.
Вам никогда не удастся написать «идеальный» код
Четыре года назад, прежде чем начать работать в команде, я был «волком-одиночкой». Большую часть этого времени я предполагал, что все программисты, занятые в разработке, пишут идеальный код. Я считал, что я тоже когда-нибудь смогу писать «идеальный» код, что это лишь вопрос времени и практики. Вообще вопрос «неидеальности» моего кода очень меня беспокоил.
Но как только я присоединился к команде, мне быстро стало ясно, что никто не пишет «идеальный» код. Тем не менее, код, идущий в продакшен, практически всегда был «идеален». В чем же дело? А дело в ревью кода.
Я работаю в команде действительно потрясающих инженеров. Это одни из самых компетентных программистов, которых можно нанять за деньги. При этом у каждого члена команды (включая меня) началась бы паническая атака, если бы кто-то предложил закоммитить непроверенный код. Даже если вы думаете, что вы новый Билл Гейтс, у вас все равно будут ошибки. Я даже не говорю о логических ошибках – речь идет, например, об опечатках, о пропущенных символах. На подобные вещи ваш мозг не обращает внимания; читая свой код самостоятельно, вы никогда не найдете эти ошибки. Для этого вам нужна вторая пара глаз.
Старайтесь работать с людьми, внимательными к деталям и готовыми критиковать вашу работу. Поначалу выслушивать критику тяжело, но это единственный надежный путь к совершенствованию. Старайтесь не впадать в глухую оборону, когда ваш код проходит ревью, и никогда не воспринимайте никакие комментарии как личное оскорбление. Ваш код это не вы.
Делая ревью, я ищу в Google информацию о каждом выборе, сделанном автором кода, если этот выбор отличается от популярной точки зрения. Часто, взглянув на задачу «глазами начинающего», можно обнаружить вещи, к которым в противном случае никогда бы не вернулся.
Работать программистом не значит писать код по 8 часов в день
Это распространенный вопрос, на который редко дают четкий ответ.
Очень мало людей пишут код больше 4 часов в день.
Люди, которые с этим не согласятся, или являются исключением из правила, или работают в компании, которой стоит лучше относиться к своим сотрудникам.
Программирование это изнурительный умственный труд, требующий большой концентрации. Неразумно ожидать от человека, что он сможет писать код по 8 часов в день 5 дней в неделю. Конечно, в вашей работе будут случаи, когда нужно успеть к дедлайну и т. п., но это редкие случаи. Под «редкие» я имею в виду «практически никогда не встречающиеся». Если из-за плохого планирования или недостатка рабочей силы вас постоянно заставляют перерабатывать, не следует с этим мириться.
Кстати, заставлять вас работать по 8 часов в день даже не в интересах вашей компании. Ваш босс может с этим не согласиться, но это близорукая политика, в долгосрочной перспективе негативно влияющая на продуктивность и душевное здоровье.
Я настоятельно рекомендую делать регулярные перерывы в ходе рабочего дня, а также физические упражнения (хотя бы «пятиминутки»). Польза физической активности для борьбы с умственной усталостью подтверждается многими исследованиями. Лично я нахожу, что упражнения очень помогают, когда я не могу сосредоточиться.
Заключение
Это лишь несколько вещей, которые, по моему мнению, должны рассказывать в университетах вместо чистой теории.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
