Повышаем свою стоимость: пишем код сами

На первый взгляд, название статьи звучит странно. Как можно писать код не самим? Нейронные сети пока еще не умеют создавать программы, так что, хошь не хошь, а кодить ручками таки приходится

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

Подключатели библиотек

Чем прекрасна развитая экосистема любого языка программирования? Огромным выбором готовых библиотек, которые могут решить любую возникшую перед разработчиком задачу. Однако, у этой медали есть и обратная сторона. Если разработчик только и делает, что ищет решение проблем в написанных другими библиотеках, он перестает быть программистом. Он превращается в подключателя библиотек.

Чем это опасно? Как минимум тем, что это стагнация в развитии. Зачем пытаться писать код самому, если за тебя это уже кто-то сделал? Зачем тратить время на написание велосипедов, если нужно быстрее решить поставленную задачу? Берем кучу библиотек, дружим их между собой - и вуаля, проект готов, кидаем в прод и летим на Бали кушать кокосы.

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

Приведу пример со своей работы. Буквально месяц назад нам дали зеленый свет на использование TypeScript. Я, довольный, как слон, которому подогнали вкусняшку размером с него, написал конфиги для gulp и webpack и попер писать одну вспомогательную тулзу для нашего фронт кита. И для этого я установил в качестве зависимости библиотеку "merge-deep". Она совсем простенькая, но использует в зависимостях еще три библиотеки. Одна из них - "kind-of" - используется непосредственно в этой библиотеке плюс стоит в зависимостях других библиотек. По идее, npm должен был нормально установить зависимости, но это не так. В итоге, мой код падал из-за отсутствия "kind-of" в одной из зависимостей.

По идее, прямая установка "kind-of" в моем проекте должна была решить эту проблему. Нифига, код все равно падал. Я не знаю, каким образом автор мог намудрить с зависимостями, код написан давненько на es5, но я в нем не обнаружил каких-то косяков. Возможно, стоило изучить разные версии библиотек по тегам, но все же сам факт того, что внешняя либа падает по каким-то магическим причинам, меня напрягал. Поэтому я переписал все эти либы на TypeScript, используя в зависимостях только "kind-of". И все заработало.

Велосипединг

Написал ли я свой велосипед? Безусловно. Это плохо? В моем случае это решило проблему, значит нет. Но, как и в любой области, есть две крайности. И велосипединг - обратная "подключателю библиотек" проблема. Когда программист в принципе не признает ни одну готовую библиотеку и пилит свои аналоги, показывая всем, кто батя в здании. Почему это проблема? В поддержке этого велосипеда. Кадры в IT двигаются очень быстро, программист, написав для проекта свой велосипед, увольняется. Для велосипеда нет никаких доков, и новый прогер, которому достанется этот проект, охренеет от того, что в нем творится. Если прогер крутой, то он, изучив исходный код и разобравшись, как он работает, сможет пилить проект дальше. А если не разберется? Скорее всего, он перепишет код с использованием готовой библиотеки с развитым комьюнити и поддержкой.

И вот тут выпрыгивает из-за угла со страшной мордой еще один нюанс не в пользу подключателю библиотек. А что, если либа, которую он хочет подключить, заброшена автором проекта? Что, если последний коммит был сделан 2-3 года назад? Вдруг там сидит куча багов, которые вылезут в самый неподходящий момент? Что, если либа не покрыта тестами? Короче, говнеца можно хапнуть с лихвой. И подключатель библиотек не сможет решить эту проблему, ведь он не умеет писать код, или пишет его скверно.

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

Баланс

Так мы пишем код сами или че? Конечно пишем. Главное, не увлекаться. А нас хлебом не корми, дай увлечься написанием кода.

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

Не забывайте о том, что каждая новая зависимость - это потенциальная проблема в будущем. Дыра в безопасности, устаревший и заброшенный код, хакерская атака. В конце концов, отсутствие контроля. Если вы найдете проблему в коде библиотеки, вам придется или долбить автора в issues, либо форкать его либу, исправлять баг, делать pull request и снова долбить автора, чтобы ревьюил и мержил. Сплошной геморрой. А свой код всегда рядом и только ты его контролируешь.

Обезьяний труд

Хочу упомянуть еще один вид работы программистов - обезьяний труд. Он вреден, и для понимания этого приведу пример.

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

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

Итого

Надеюсь, я верно донес информацию. Возможно, какие-то вещи прозвучали обидно, но с этим ничего не поделать. Если вы хотите всю жизнь быть джуном и получать копейки, окей, тогда мои советы что мертвому припарка. Но если вы целеустремленный человек и хотите повысить свой доход, то пополняйте ваш багаж знаний и умений через написание собственного кода. Ведь программист, который остановился в развитии - мертвый программист. Хотя в контексте темы можно заменить "мертвый" на "дешевый".