9 тяжелых уроков, которые я усвоил за 18 лет разработки

Я начал писать код в моей комнате родительского дома, когда мне было 14. Помню, как читал всё, что мог достать с помощью своего медленного соединения с Интернетом. Затем, когда мне было 20, я подписал первый контракт, став веб-разработчиком и изучая PHP и JavaScript. Мне потребовалось 18 лет, чтобы осознать, что кодинг — только часть профессии. Заметьте, я по-прежнему наслаждаюсь кодингом. Не думаю, что когда-нибудь перестану программировать, даже если это станет просто моим хобби, но есть нечто гораздо большее, чем код. Вот почему я хочу поделиться своим опытом. Я думаю, что иногда разработчики усваивают эти уроки слишком поздно.

У разработчиков раздутое эго. Это факт. Но почему? Я сказал бы, что любой, кто серьёзно относится к своей профессии, считает себя кем-то вроде человека искусства. Да, мы не поём перед миллионами и не рисуем «Мону Лизу», но иногда пишем код, решающий сложные задачи столь эффективно и элегантно, что не можем не гордиться своей работой. Я думаю, что разработчик благодаря подходу к проблемам является человеком искусства настолько же, насколько им является математик. А раз так, мы склонны ползать вокруг кода так же, как мамаша-медведица вокруг своего потомства. Мы пишем его, любим его и терпеть не можем, когда люди вокруг спорят, насколько код ошибочен или нет.

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

Перестаньте называть себя разработчиком на Java или разработчиком на JavaScript. Да, есть языки, которые нравятся вам из-за синтаксиса или возможностей. Это совершенно нормально. Однако вы выиграете, если какое-то время посвятите изучению чего-то ещё. Изучение новых языков, особенно если они следуют парадигме, отличной от привычной для вас, поможет открыть разум для различных подходов к решению проблем.

У меня даже нет слов, насколько это важно: изучение новых языков и их применение пойдут на пользу вашим навыкам. Я прочитал книгу Seven Languages in Seven Weeks несколько лет назад, и она открыла мне множество вариантов только потому, что показала способы решения задач, доступные в других языках.

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

Некоторые разработчики-новички думают, что должны знать алгоритмы наизусть, так что чувствуют себя плохо в ту минуту, когда осознают, что начали забывать, как пишется цикл for. Это не только нормально. Я бы сказал, что это даже полезно. Просто у нас слишком много всего, что нужно запомнить. Но это тоже не нужно. Нужно принять тот факт, что Интернет — всего лишь ещё один инструмент, столь же необходимый, как наша IDE, для поиска ответов.

Мы все делаем это. И если вы от этого чувствуете себя плохо, не тратьте время на это чувство. Просто поищите ответ в Google и поймите вашу проблему. Подумайте вот о чём. Каждый язык имеет схожие, но немного различающиеся способы реализации паттерна Наблюдатель. Что полезнее? Понимание того, для чего хорош паттерн и какие проблемы он решает, или запоминание того, как реализовать его на каждом языке, с которым вы работаете?

Если вы знаете, что паттерн решит вашу проблему, то вы уже решили её. Всё остальное — просто поиск наилучшего способа его реализации в Google. Такой поиск не отнимает уважения ни к вам, ни к вашей работе, ни к вашему опыту. То же самое относится к любому другому поиску. Сосредоточьтесь на важном, на решении проблемы и позвольте Google подтолкнуть вашу память. Для этого он и существует.

4. Вы будете учиться всю свою карьеру

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

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

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

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

• Новые языки.
• Новые (и старые) парадигмы программирования.
• Новые подходы к работе.
• Новые пути решения проблем.
• Новые способы взаимодействия с товарищами по команде.
• Новые подходы к ревью и тестированию вашего кода.

Если вы не готовы быть вечным студентом, подумайте, для вас ли такая карьера. Заметьте, я не сказал: «Уходите сразу», но подумайте, готовы ли открыть своё сознание постоянному обучению.

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

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

В конце концов, вы решаете проблему. Чем быстрее вы решите проблему, тем лучше для ваших пользователей.

В соответствии с некоторыми предыдущими пунктами, не попадайте в чёрную дыру ранней оптимизации. Даже если вы думаете, что сделаете код быстро, как только он выйдет в свет (если когда-нибудь это случится), вы поймёте, что эффект замедления во времени реален.

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

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

Ранняя оптимизация означает оптимизацию вашего кода в процессе его написания. Это опасная практика, потому что при оптимизации мы делаем предположения о времени выполнения, требованиях к данным, требованиях к памяти и о других факторах, которые мы еще не видели в действии. Любое такое предположение может быть неверным, и в конце концов вы внесёте ошибки в свою логику.

Подумайте о рабочем процессе TDD:

1. Напишите тест, чтобы понять всё, что нужно сделать для вашей функции (тест не пройдет).
2. Напишите свой код так, чтобы тест прошел.
3. Теперь побеспокойтесь об оптимизации кода.

Второй шаг обязателен. Сначала нужно позаботиться о тесте, который означает, что функция работает. Тесту не важно, что в алгоритмы вы используете три вложенных инструкции if. Это станет важно, возможно, на этапе ревью кода.

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

И это совершенно нормально. Мы склонны сосредотачиваться прежде всего на крупных функциях, оставляя мелкие детали или даже известные баги на самый конец. Но с ними, тем не менее, нужно бороться — и вот здесь появляются дополнительные 90 %. Вы должны протестировать, исправить код, протестировать ещё раз, научить пользователей обращаться с решением, представить финальную версию решения и так далее. Конечно, всё зависит от контекста, от того, кто ваш клиент, и от многих других факторов, но что-нибудь найдется всегда. Так что запомните: когда вы думаете, что почти закончили с кодом, вероятно, вы что-то забыли.

Кодинг — это про поведение абстракций. Абстрагируя общую логику, мы можем повторно использовать её в других местах, но вначале мы забываем о важности абстракций. Вот моё личное правило: если код повторяется в двух местах, он отправляется в функцию (метод, модуль); вы поняли идею. Если два повторения выглядят в ваших глазах небольшим числом, учтите, что в будущем могут найтись другие места для применения только что абстрагированного кода. И, абстрагировав код сразу, вы сразу будете иметь к нему доступ.

Абстракция — это масштабирование. Кусочек абстрагированной логики может использоваться много раз с минимальными усилиями, тогда как копипаста (хотя сделать её легко) — чем больше вы её используете, тем больше усилий она требует. Подумайте, что произойдёт, если из-за бага вам нужно будет изменить часть логики, которая повторяется 5 раз. Чтобы исправить баг, вы буквально 5 раз измените одну и ту же часть кода.

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

Некоторые говорят, что, если вы хотите быть успешным разработчиком, вам нужны сторонние проекты. Не думаю, что это правда. Я лично знаю многих великолепных разработчиков, которые пишут код только на работе, «с 9 до 17». Честно говоря, я восхищаюсь ими. Они мастера своего дела, а в свободное время они, делая что-то другое, наслаждаются жизнью. В этом нет абсолютно ничего плохого. Однако иногда вам нужна дополнительная практика. Иногда вам кажется, что вы отстаёте от своих коллег; здесь и помогут сторонние проекты.

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

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

Вот мои 9 тяжелых уроков, которые я как разработчик получил за последние 18 лет. Надеюсь, поделившись своим опытом, я пролил немного света на вашу будущую или нынешнюю карьеру. Вы научились чему-то другому, чем хотели бы поделиться? Я буду рад услышать вас в комментариях, я хотел бы научиться чему-то у вас.

• Обучение профессии Data Science
• Обучение профессии Data Analyst

Автор: honyaki

Источник