Советы, которые выдержат испытание временем (какой бы ни была текущая горячая структура)
Вы иногда чувствуете себя истощенным и уставшим от изучения новых технических навыков? У вас есть ощущение, что в тот момент, когда вы что-то осваиваете, вам уже нужно переключиться на следующую новую вещь? Я делаю.
В этой статье я дам вам пять простых советов по совершенствованию как разработчика, которые выдержат испытание временем. Эти советы помогут вам на протяжении всей вашей карьеры разработчика.
1. Подумайте и спроектируйте, прежде чем внедрять
Сначала я придумываю черновой набросок решения, прежде чем приступить к его реализации. Это может означать создание дизайнерского документа или эскиза на доске.
Прежде чем приступить к реализации, я объясняю дизайн одному или нескольким коллегам. Это полезно двумя способами: рассказывая об этом, я заставляю меня обдумать это; Я также получаю полезные отзывы.
Поскольку многие команды используют Agile-методы, я вижу, что все больше и больше разработчиков пропускают дизайн - они берут историю и сразу же начинают ее реализовывать.
Конечно, они создают дизайн в своей голове. Но очень важно сделать этот замысел явным.
Помните, нет ничего постыдного в создании истории дизайна.
Если мне нужно выбрать один из двух вариантов при создании дизайна, я использую принцип «Легче изменить» (ETC) от The Pragmatic Programmer:
Вещь хорошо спроектирована, если она адаптируется к людям, которые ею пользуются. Для кода это означает, что он должен адаптироваться путем изменения. Поэтому мы верим в принцип ETC: легче менять. И Т.П. Вот и все.
2. Разделите свои истории на небольшие задачи.
Начиная новую историю, вы должны спросить себя: «Как я могу разбить эту историю на множество более мелких задач». Это заставляет вас найти лучшую стратегию для его реализации и снижает сложность.
Мне помогает предположение, что над этой историей будет работать больше разработчиков.
Часто я вижу, как разработчики создают реализацию одной задачи. Не знаю почему. Может быть, они боятся создаваемой прозрачности? С единственной задачей реализации никто не увидит, что вы что-то забыли.
Во время реализации я всегда обнаруживаю, что забываю одну или несколько задач. Но если вы заставляете себя делать это каждый раз, когда начинаете новую историю, вы станете лучше в этом.
Вы не забудете добавить задачу интеграционного тестирования, которую забыли в первый раз.
3. Попросите и проведите максимально честную проверку кодекса.
Буквально на этой неделе это случилось снова.
Я реализовал новую библиотеку классов. Я хорошо подумал об именах классов и методах. У меня было хорошее предчувствие. Для меня все это имело смысл. Код был ясен, и модульные тесты прошли успешно. Я отправил свой запрос на перенос (PR).
Когда мой коллега закончил pull request, мы начали обсуждать его замечания. К моему удивлению, он не понял названий классов и методов.
Вы должны помнить, что когда вы что-то реализуете, названия, которые вы придумываете, всегда вам понятны. Единственный способ подтвердить это - показать кому-нибудь.
Проверка кода - отличный способ улучшить. Когда ваш коллега просматривает ваш код, вы можете узнать об этом из полученных вами отзывов. Если вы просматриваете чужой код, вы можете извлечь уроки из кода и научиться оставлять отзывы.
Проверка кода должна быть предельно честной. Не бойтесь делать замечания, если что-то неочевидно. Просто относитесь к другим разработчикам с уважением.
4. Создайте спокойную рабочую среду.
В Нидерландах, где я живу, открытые офисы являются стандартной планировкой для девелоперских компаний.
Открытые офисы призваны улучшить сотрудничество, общение и продуктивность. Многие исследования показали, что это не так. Вместо расширения взаимодействия и сотрудничества происходит обратное.
Еще один эффект открытого офиса - это постоянный поток отвлекающих факторов. Когда вы развиваетесь, вам нужно сосредоточиться - любые дополнительные стимулы уменьшат его. Вы можете совершенствоваться как разработчик, убирая отвлекающие факторы.
Попросите своего работодателя установить звукоизоляционные стеновые панели или ковролин. В противном случае попросите своего работодателя предоставить наушники с шумоподавлением.
5. Не зацикливайтесь на скорости программирования
Легко сказать: «не сосредотачивайтесь на скорости программирования», поскольку все в современном процессе разработки организовано вокруг максимально быстрого перемещения задач из «сделать», «выполняется» в «выполнено».
Но вместо того, чтобы сосредотачиваться на скорости, вы должны сосредоточиться на качестве. Если вы сосредоточитесь на качестве, скорость последует.
Или, как Роберт С. Дядя Боб Мартинс описывает это в своей статье Яростная посредственность:
Новички считают, что качество и скорость противоположны. Они думают, что взлом - это быстро. Они еще не осознали того, что хорошо знают профессиональные разработчики: даже небольшое взломание происходит медленнее, чем его полное отсутствие.
Каждый раз, когда вы поддаетесь искушению поменять качество на скорость, вы замедляетесь. Каждый раз.
Заключение
Предыдущие пять советов более ценны, чем изучение другого нового фреймворка или языка программирования. Лучше всего то, что они выдержат испытание временем и останутся актуальными завтра.
Спасибо за прочтение!
