[Карьера в IT-индустрии] 7 советов разработчику из личного опыта
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Всем привет!
Думаю, что эта статья будет полезна новичкам в мире IT. Опытным разработчикам многие советы могут показаться очевидными. Но я надеюсь, что и они смогут почерпнуть для себя что-то новое и полезное.
1. Старайтесь погружаться в бизнес-процесс
В современных условиях гибких методологий разработки первостепенно важным является понимание того, как устроен бизнес-процесс. Глубокое понимание разрабатываемого продукта позволяет правильно спроектировать архитектуру приложения и выбрать релевантный технологический стек. Кроме того, появление термина «продуктовый разработчик» очень понравилось представителям бизнеса. И сейчас роль разработчика предполагает не только наличие развитых технических компетенций, но и определенного образа мышления: когда разработчик принимает участие в продуктовых обсуждениях, участвует в формировании плана развития продукта, отслеживает влияние релизов на бизнес-показатели. Одним словом, он «болеет» за продукт.
Сегодня продуктовый подход встречается повсеместно. И чтобы не отставать от современных реалий, важно понимать, как функционирует бизнес, в рамках которого вы разрабатываете программный продукт.
2. Используйте единый словарь терминов
Отсутствие единой терминологии в проекте может приводить к эффекту сломанного телефона, когда на выходе бизнес получает не совсем то, что он хотел от разработки. Или когда разработчики именуют в коде одну и ту же бизнес-сущность по-разному, что может приводить к потенциальным ошибкам и разрастанию кодовой базы. Поэтому следующим важным моментом я считаю составление и использование единой терминологии в проекте. Причем не только в общении, но и коде.
При запуске проекта желательно зафиксировать используемые бизнес-термины в едином для всех документе — словаре. В будущем этот документ будет не только инструментом для коммуникации между членами команды. Он станет своего рода API-контрактом между разработкой и бизнесом, между бизнес-требованиями и кодом. На этой идее строятся многие методологии разработки. Например, Domain Driven Design. Использование словаря создает эффект единого информационного пространства для всех участников команды, где каждый понимает друг друга с полуслова. А также это позволяет существенно снизить порог входа в проект для вновь прибывших участников команды.
3. Формируйте командные соглашения
Проблема дискуссий в комментариях к pull-request всегда стоит остро. В свое время в одной из команд мы даже выработали правило, что под одним комментарием рецензента не должно быть больше пяти сообщений. Иначе считалось, что обсуждение скатывается в демагогию, обострение отношений между членами команды и непродуктивное использование рабочего времени. А всему виной отсутствие командных соглашений.
Я настоятельно рекомендую перед началом разработки принять общие соглашения, на основе которых в дальнейшем будет строиться работа команды. Здесь я имею в виду архитектуру проекта, стиль написания кода, допустимый размер классов и методов, график код-ревью и прочие моменты, которые вы посчитаете важными для своей команды. Потому что не проведя эту процедуру заранее, вы вновь и вновь будете сталкиваться с однотипными темами для диспута в комментариях.
И здесь опять хотелось бы обратиться к своему опыту. Когда мы ввели командные соглашения, то при проведении код-ревью мы действительно смотрели только на реализацию фичи. И код в какой-то момент стал выглядеть так, словно его пишет один человек. А самое главное, отношения внутри команды наладились, так как практически отсутствовала почва для возникновения конфликтов.
Естественно, что все договоренности сложно держать в голове. И многое можно автоматизировать благодаря использованию линтеров, прехуков, автонапоминаний и прочих вспомогательных инструментов.
4. Регулярно давайте и получайте обратную связь
Не стоит недооценивать церемонию получения обратной связи. Старайтесь как можно чаще обмениваться ею с вашими коллегами. Ведь не всегда можно объективно взглянуть на проделанную работу и сделать правильные выводы. Каждый из нас обладает уникальным опытом, и через его призму может дать важные советы, которые, возможно, станут почвой для вашего дальнейшего развития.
Правильно поданная обратная связь — это всегда зона роста для разработчика. А вовремя поданная обратная связь — это «информационный клей», который позволяет сплотить команду и уберечь от разлада.
5. Придерживайтесь системности подхода
Старайтесь всегда придерживаться ваших договоренностей и выбранных методологий разработки. Если вы решили покрывать фичи тестами, то покрывайте всегда. Если вы решили проводить предрелизное демо, то проводите его всегда. Если прямой commit в релизную ветку запрещен, то он запрещен для всех. Это привнесет системность и порядок в действия вашей команды, а также застрахует от всеми нами любимого «авось».
6. Используйте методологии тайм-менеджмента
Для повышения личной эффективности и рационального использования рабочего времени в своей практике я стараюсь придерживаться методологии тайм-менеджмента. В моем случае это Pomodoro. Конечно, вы вправе не останавливаться на моем выборе. Но в целом контроль времени и декомпозиция задач в рамках рабочего дня позволяет быть более сосредоточенным и продуктивным, за счет устранения отвлекающих факторов и предельной концентрации на текущей задаче.
Кроме того, закрытие каждой такой задачи дает кратковременный выброс серотонина и чувство удовлетворенности. К концу рабочего дня можно посмотреть на список закрытых задач, проанализировать и подумать над тем, что в будущем можно улучшить, чтобы достичь большего результата. Такое персональное ретро в конце дня.
7. Следите за выгоранием
Бывают дни, когда мы так увлечены своей работой, что забываем про время на отдых. Иногда мы можем позволить себе «овертаймить» ночью для скорейшего достижения поставленных целей. Однако в такие моменты нужно помнить, что эту моментальную эффективность и продуктивность мы берём в долг у себя будущего.
Нахождение продолжительное время в таком режиме ведет к полной или частичной потере эффективности на рабочем месте вследствие нарастающего эмоционального и физического истощения. Иными словами, это приводит к выгоранию. Срабатывает психологическая защита мозга в ответ на продолжительный стресс с целью сберегания ресурсов организма.
Нужно уметь вовремя остановиться и скорректировать свой режим, чтобы не допустить этого. Нормализуйте свой режим сна и отдыха, придерживайтесь правильного питания, старайтесь переключаться на ваше любимое хобби, а также не забывайте о прогулках на свежем воздухе.
Спасибо за внимание. Всем удачи!
===========
Источник:
habr.com
===========
Похожие новости:
- [Программирование, Управление разработкой, Развитие стартапа, Карьера в IT-индустрии, Научно-популярное] Путь CTO в небольшом стартапе (Zapier) (перевод)
- [Тестирование IT-систем, Карьера в IT-индустрии] Из тестировщиков в агенты изменений департамента: путь в 10 лет и два выгорания
- [Программирование, Развитие стартапа, Карьера в IT-индустрии, Научно-популярное] Исповедь CTO: путь развития технического директора в стартапе (перевод)
- [Исследования и прогнозы в IT, Карьера в IT-индустрии, Удалённая работа] [Исследование] Как удалёнка поменялась за последний год
- [Управление разработкой, Управление персоналом] Быть тимлидом, ч.1: Люди
- [Информационная безопасность, Карьера в IT-индустрии] Сдать OSCE: вызов принят
- [Тестирование веб-сервисов, Тестирование мобильных приложений, Тестирование игр, Карьера в IT-индустрии] В тестировщики пойду: 10 вопросов про то, как переквалифицироваться в специалиста по тестированию
- [Карьера в IT-индустрии, Читальный зал] Уроки выживания. Что делать с токсичными руководителями
- [Управление персоналом, Карьера в IT-индустрии] Что делать с неэффективным сотрудником, который считает, что он отлично справляется (перевод)
- [Разработка веб-сайтов, Машинное обучение, Карьера в IT-индустрии, IT-компании] Как мы в ПИК-Брокер оцениваем квартиры через «цифру»
Теги для поиска: #_karera_v_itindustrii (Карьера в IT-индустрии), #_sovety_razrabotchiku (советы разработчику), #_produktovyj_razrabotchik (продуктовый разработчик), #_sovety_novichkam (советы новичкам), #_blog_kompanii_domklik (
Блог компании ДомКлик
), #_karera_v_itindustrii (
Карьера в IT-индустрии
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:52
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Всем привет! Думаю, что эта статья будет полезна новичкам в мире IT. Опытным разработчикам многие советы могут показаться очевидными. Но я надеюсь, что и они смогут почерпнуть для себя что-то новое и полезное. 1. Старайтесь погружаться в бизнес-процесс В современных условиях гибких методологий разработки первостепенно важным является понимание того, как устроен бизнес-процесс. Глубокое понимание разрабатываемого продукта позволяет правильно спроектировать архитектуру приложения и выбрать релевантный технологический стек. Кроме того, появление термина «продуктовый разработчик» очень понравилось представителям бизнеса. И сейчас роль разработчика предполагает не только наличие развитых технических компетенций, но и определенного образа мышления: когда разработчик принимает участие в продуктовых обсуждениях, участвует в формировании плана развития продукта, отслеживает влияние релизов на бизнес-показатели. Одним словом, он «болеет» за продукт. Сегодня продуктовый подход встречается повсеместно. И чтобы не отставать от современных реалий, важно понимать, как функционирует бизнес, в рамках которого вы разрабатываете программный продукт. 2. Используйте единый словарь терминов Отсутствие единой терминологии в проекте может приводить к эффекту сломанного телефона, когда на выходе бизнес получает не совсем то, что он хотел от разработки. Или когда разработчики именуют в коде одну и ту же бизнес-сущность по-разному, что может приводить к потенциальным ошибкам и разрастанию кодовой базы. Поэтому следующим важным моментом я считаю составление и использование единой терминологии в проекте. Причем не только в общении, но и коде. При запуске проекта желательно зафиксировать используемые бизнес-термины в едином для всех документе — словаре. В будущем этот документ будет не только инструментом для коммуникации между членами команды. Он станет своего рода API-контрактом между разработкой и бизнесом, между бизнес-требованиями и кодом. На этой идее строятся многие методологии разработки. Например, Domain Driven Design. Использование словаря создает эффект единого информационного пространства для всех участников команды, где каждый понимает друг друга с полуслова. А также это позволяет существенно снизить порог входа в проект для вновь прибывших участников команды. 3. Формируйте командные соглашения Проблема дискуссий в комментариях к pull-request всегда стоит остро. В свое время в одной из команд мы даже выработали правило, что под одним комментарием рецензента не должно быть больше пяти сообщений. Иначе считалось, что обсуждение скатывается в демагогию, обострение отношений между членами команды и непродуктивное использование рабочего времени. А всему виной отсутствие командных соглашений. Я настоятельно рекомендую перед началом разработки принять общие соглашения, на основе которых в дальнейшем будет строиться работа команды. Здесь я имею в виду архитектуру проекта, стиль написания кода, допустимый размер классов и методов, график код-ревью и прочие моменты, которые вы посчитаете важными для своей команды. Потому что не проведя эту процедуру заранее, вы вновь и вновь будете сталкиваться с однотипными темами для диспута в комментариях. И здесь опять хотелось бы обратиться к своему опыту. Когда мы ввели командные соглашения, то при проведении код-ревью мы действительно смотрели только на реализацию фичи. И код в какой-то момент стал выглядеть так, словно его пишет один человек. А самое главное, отношения внутри команды наладились, так как практически отсутствовала почва для возникновения конфликтов. Естественно, что все договоренности сложно держать в голове. И многое можно автоматизировать благодаря использованию линтеров, прехуков, автонапоминаний и прочих вспомогательных инструментов. 4. Регулярно давайте и получайте обратную связь Не стоит недооценивать церемонию получения обратной связи. Старайтесь как можно чаще обмениваться ею с вашими коллегами. Ведь не всегда можно объективно взглянуть на проделанную работу и сделать правильные выводы. Каждый из нас обладает уникальным опытом, и через его призму может дать важные советы, которые, возможно, станут почвой для вашего дальнейшего развития. Правильно поданная обратная связь — это всегда зона роста для разработчика. А вовремя поданная обратная связь — это «информационный клей», который позволяет сплотить команду и уберечь от разлада. 5. Придерживайтесь системности подхода Старайтесь всегда придерживаться ваших договоренностей и выбранных методологий разработки. Если вы решили покрывать фичи тестами, то покрывайте всегда. Если вы решили проводить предрелизное демо, то проводите его всегда. Если прямой commit в релизную ветку запрещен, то он запрещен для всех. Это привнесет системность и порядок в действия вашей команды, а также застрахует от всеми нами любимого «авось». 6. Используйте методологии тайм-менеджмента Для повышения личной эффективности и рационального использования рабочего времени в своей практике я стараюсь придерживаться методологии тайм-менеджмента. В моем случае это Pomodoro. Конечно, вы вправе не останавливаться на моем выборе. Но в целом контроль времени и декомпозиция задач в рамках рабочего дня позволяет быть более сосредоточенным и продуктивным, за счет устранения отвлекающих факторов и предельной концентрации на текущей задаче. Кроме того, закрытие каждой такой задачи дает кратковременный выброс серотонина и чувство удовлетворенности. К концу рабочего дня можно посмотреть на список закрытых задач, проанализировать и подумать над тем, что в будущем можно улучшить, чтобы достичь большего результата. Такое персональное ретро в конце дня. 7. Следите за выгоранием Бывают дни, когда мы так увлечены своей работой, что забываем про время на отдых. Иногда мы можем позволить себе «овертаймить» ночью для скорейшего достижения поставленных целей. Однако в такие моменты нужно помнить, что эту моментальную эффективность и продуктивность мы берём в долг у себя будущего. Нахождение продолжительное время в таком режиме ведет к полной или частичной потере эффективности на рабочем месте вследствие нарастающего эмоционального и физического истощения. Иными словами, это приводит к выгоранию. Срабатывает психологическая защита мозга в ответ на продолжительный стресс с целью сберегания ресурсов организма. Нужно уметь вовремя остановиться и скорректировать свой режим, чтобы не допустить этого. Нормализуйте свой режим сна и отдыха, придерживайтесь правильного питания, старайтесь переключаться на ваше любимое хобби, а также не забывайте о прогулках на свежем воздухе. Спасибо за внимание. Всем удачи! =========== Источник: habr.com =========== Похожие новости:
Блог компании ДомКлик ), #_karera_v_itindustrii ( Карьера в IT-индустрии ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:52
Часовой пояс: UTC + 5