Вот 5 практик, которые я использую, чтобы кодировать быстрее

Вы работаете сразу над несколькими задачами? Не можете выбрать технический стек? Вы теряете время на рефакторинг?

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

Вот что вам нужно применить, чтобы сократить время, которое тратится впустую.

· Stick with one tech
· Consult first, change second, review after
· Don’t overengineer
· Focus on solving business problems
· Avoid multitasking

Придерживайтесь одной технологии

Работайте с одним стеком технологий. Это справедливо для опытных разработчиков. Новым разработчикам следует попробовать разные технологии и посмотреть, что им нравится. В любом случае, не гонитесь за ажиотажем. Быть конкретным - это хорошо. Постройте фундамент, а затем расширьте его.

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

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

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

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

Изучите Git подробно. Git может расточить время. Вы также можете потерять свою ценную работу и заставить возненавидеть Git. Изучите команды, которые вы используете каждый день. Изучив Git, вы можете использовать графический интерфейс. Изучите Git, чтобы не тратить время впустую.

Я много лет использую графический интерфейс для Git. Sourcetree имеет возможность настраивать действия. Допустим, вам нужно переустановить ветку функций при разработке. Вам нужно запустить несколько команд в CLI. Это можно заменить на настраиваемые действия. Чего достигают пользовательские действия?

  • Ускорьте разработку
  • Удалите повторяющиеся задачи Git
  • Выполнять команды за вас.

Хотя я не являюсь DevOps, я немного знаю Дженкинса. Я запускаю сборки, смотрю на ошибки сборки и развертываю самостоятельно. Изучите системы DevOps, чтобы улучшить опыт разработки.

Сначала проконсультируйтесь, затем измените, затем просмотрите

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

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

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

Не беспокойте экспертов и не поручайте им свою работу. Избегайте этого: «Я мог бы это сделать, но X сделает это лучше!» Обратитесь за помощью, если вы столкнетесь с проблемами. Обращайтесь за помощью, не теряя времени на оба конца.

Не переусердствуйте

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

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

Вы стремитесь выполнить задачу. Время влияет на качество кода. Вы должны знать код, который пишете. Для PoC не нужно писать первоклассный код. Им нужно показать концепцию. Позже вы можете исправить недостающие биты. Качество истекает, когда важно время. Это известный факт, и он называется «технический долг».

Старший, архитектор решений и бизнес должны уточнить задачи. Средний и младший должны сосредоточиться на кодировании. Хотя посредник может предложить передовой опыт, решение принимает старший. Быстрые релизы приводят к незавершенной работе. Мы должны помнить о незавершенных задачах, но больше внимания следует уделять итерации.

Сосредоточьтесь на решении бизнес-задач

Проблема XY - это вопрос о вашей попытке решения Y. Вам следует спросить о реальной проблеме X.

- xyproblem.info

Работайте над своим общением с бизнесом. Спрашивайте, что им нужно, а не то, что они хотят. Это может решить проблему XY.

Компании не знают, чего хотят, но знают, чего не хотят.

- Адам Ральф

«Хорошее командное взаимодействие ведет к эффективной и результативной работе». - Боян Лекович

Боян столкнулся с серьезной проблемой. Причина? Плохое общение.

Сократите общение до кратких сообщений. Он установил новые стандарты общения с двумя типами сообщений:

  • статусные сообщения

Над чем вы работаете? Когда ты закончишь? Почему вы опоздали?

  • содержательные сообщения

Они содержат проблему и контекст. Используйте их для описания блокировщика, проблемы или критической проблемы.

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

Избегайте многозадачности

Вы знаете это. Вы запускаете мало задач, страдает качество. Назначьте одну задачу и выполните ее вовремя.

Оказывается, если вы дадите кому-то поработать над двумя вещами, вы должны быть благодарны, если они« заморят одну задачу и будут работать только над одной, потому что они успеют сделать больше и закончить в среднем. задача раньше. Фактически, реальный урок из всего этого заключается в том, что вы не должны позволять людям работать сразу над более чем одним делом. Убедитесь, что они знают, что это такое. Хорошие менеджеры видят свою ответственность в устранении препятствий, чтобы люди могли сосредоточиться на чем-то одном и действительно сделать это. Когда возникают чрезвычайные ситуации, подумайте, сможете ли вы справиться с ними самостоятельно, прежде чем делегировать их программисту, который глубоко погружен в проект ». - источник

Многозадачность сопровождается множеством перерывов. Вы выполнили задание №1? Каков статус Задачи №2? Когда вы собираетесь выполнить задание №3? Прерывание замедляет разработчиков. Работайте только над одним делом.