Как писать код, который будет нравится вам в будущем

Дядя Бен однажды сказал Питеру Паркеру: “С большой силой приходит большая ответственность”. Эта цитата относится также и к программистам, отвечающим за разработку проектов. После 5 лет работы в этой сфере я решил оглянуться назад и поделиться своими наблюдениями с общественностью.

Начало

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

Команда разработчиков там состояла всего из пяти человек. Работа в этом стартапе поменяла мой взгляд на программирование. Мне повезло с отличным наставником и крутыми коллегами, которые помогли мне развиваться. Но мы были быстрорастущей компанией. Чтобы сдавать работу в срок, мы часто поступались качеством нашего кода. “Потом исправим”, — думали мы. То есть, создавая проект, мы могли оставить там некоторые недочеты. Это приводило к техническому долгу, что само по себе было не так плохо.

Никогда не жертвуйте качеством кода

Через какое-то время мы начали понимать, что больше не можем расти. Поэтому мы решили переписать всю кодовую базу, что, в свою очередь, заняло больше времени. Но в итоге мы получили хорошую кодовую базу. Она была вариативна и удобна в работе. До сих вспоминаю нашу “папку позора” для разработчиков, которые решили написать код, который в дальнейшем придется дорабатывать.

Так мы заставили сами себя отвечать за поддержание качества кода на уровне. Но я усвоил такой урок:

Даже если вам понадобится чуть больше времени, вам стоит потратить его, чтобы написать качественный код и не исправлять его в будущем. Эти дополнительные усилия сэкономят много времени и денег.

Мы решили проблемы со структурой, но затем перешли к самому интересному: проблеме производительности. Создавая наши проекты, мы использовали множество библиотек, чтобы ускорить процесс разработки. Мы понимали, что наши проекты слегка тяжеловаты. Над ними нужно было поработать. Чтобы сбросить лишнее, мы провели анализ и поняли, что использовали много ненужных библиотек. Мы бы и сами могли их создать. Так что мы собрали данные этих библиотек и создали свою собственную. Отлично! Наши страницы стали работать быстрее из-за меньшего количества используемых инструментов.

Всегда записывайте, что вы делаете, и пишите комментарии к коду

Затем в нашей истории произошел поворот: стартап был, наконец, выкуплен. Я перешел в новую команду. Новым членам команды были лучше знакомы библиотеки, существовавшие на рынке. И внезапно наша кодовая база оказалась им совершенно непонятна. Написать свои библиотеки мы смогли, а вот на документирование нам времени не хватило. Так я узнал о важности документирования и комментариев.

Я понял, что мы пишем код не только для себя. Как автор, вы обязаны всё разъяснить другим программистам.

Мораль: создавать свои библиотеки — не плохо. Но если вы это делаете, то обязаны записывать и комментировать свои действия. Любой программист должен понимать, как работает ваша библиотека, прочитав вашу документацию. Ещё раз подчеркиваю, пишите код не только для себя! Это ваша обязанность, если вы редактируете и поддерживаете код.

Не изобретайте велосипед, если не уверены, что сможете его поддерживать

Со временем я понял, что нам не нужно было делать всю эту работу. У нас не было времени на создание документации, которая помогла бы и другим понять работу нашей библиотеки. Если уже существует библиотека, решающая вашу проблему, вам стоит поспособствовать её развитию! Но есть один подвох. Я хочу привести цитату из блога Фила Уолтона:

Изобретать велосипед вредно для бизнеса, но полезно для обучения. Может быть, вас привлекает возможность просто взять виджет или библиотеку делегирования из npm, но только представьте, сколько нового вы могли бы узнать, попытавшись создать эти инструменты самостоятельно.

Так что хорошенько подумайте.

Всегда тестируйте свою кодовую базу

Даже описать не могу, насколько это важно. Благодаря Jest, React testing library и многим другим библиотекам, тестировать код очень просто. В больших кодовых базах одна-единственная измененная строчка может сломать всё приложение. Но если тестирование проходит автоматически, мы можем быть уверены во всех изменениях, которые вносим.

Продолжайте учиться

Я хотел быстрее и продуктивнее работать во front-end разработке. В итоге я решил изучать React, в основном из-за своего предыдущего опыта. Эта библиотека была мне интересна, а работа с ней была очень похожа на работу с обычным JavaScript. Это решение изменило мою жизнь к лучшему.

React, Vue, Angular и многие другие библиотеки (особенно Redux) не просто помогают создать быстрый пользовательский интерфейс. Они также помогают изучить другие понятия, такие как функциональное программирование, неизменность и множество других, которые развивают ваши навыки программирования. Изучение React и Redux помогло мне углубить мои знания.

Вывод

Набравшись опыта, я перешел в ещё один стартап, где моей задачей было создание продуктов с нуля и создание основы. Но в этот раз у меня уже был собственный опыт. И я рад отметить, что горд тем, что мне уже удалось создать. И я уверен, мне есть куда расти. Нам никогда не достичь совершенства, но всегда нужно к нему стремиться.

Совсем не факт, что ваш путь будет похож на мой. Я описал только свою историю работы в этой сфере. Но я надеюсь, что эта статья поможет вам стать лучше, как программист. И также я благодарен сообществу, которое помогало мне развиваться.

Перевод статьи Lusan Das: How to write code you will love in the future