Как стать лучшим разработчиком
Главное конкурентное преимущество любого специалиста — знать правила и понимать когда, где и зачем они нужны.
Нормальный разработчик решает проблемы по мере поступления, учится тому, что пригодится в работе, бессистемно читает статьи по разным темам.
Хороший разработчик углубляет текущие знания, смотрит лекции по другим технологиям, читает фундаментальные книги.
Лучший разработчик делает то же, что и хороший. Но не просто поглощает факты, а разбирается, почему всё работает именно так. Какие границы применимости у новых знаний. Чем один подход лучше другого.
Недостаточно заучить типовые ситуации и типовые решения. В лекциях даются упрощённые однобокие примеры. На каждом проекте свои проблемы, подходы и технологии. У каждой задачи несколько решений.
Анализируйте то, что делаете. Даже если вы ещё джуниор или мидл, и задачи выглядят как «напиши это по подобию того». Посмотрите на задачу шире и постарайтесь понять, почему сделано так, а не иначе. Когда читаете статьи и смотрите лекции задавайте себе вопрос - как ещё решить исходную проблему? Когда мой вариант лучше варианта из статьи? Сначала будет казаться, что других достойных опций нет, но со временем вы будете видеть их всё чаще.
Мгновенного профита от такого процесса не будет, но если привычка закрепится — вы будете на голову выше своих коллег. Чем выше должность - тем больше принимаемых решений и тем важнее навык критического мышления.
В разработке ПО полно инертности. Однажды выбранные способы решения выбираются снова и снова. Thinking out of the box — самый редкий и ценный навык и над ним тоже нужно работать.
#soft_skills
Главное конкурентное преимущество любого специалиста — знать правила и понимать когда, где и зачем они нужны.
Нормальный разработчик решает проблемы по мере поступления, учится тому, что пригодится в работе, бессистемно читает статьи по разным темам.
Хороший разработчик углубляет текущие знания, смотрит лекции по другим технологиям, читает фундаментальные книги.
Лучший разработчик делает то же, что и хороший. Но не просто поглощает факты, а разбирается, почему всё работает именно так. Какие границы применимости у новых знаний. Чем один подход лучше другого.
Недостаточно заучить типовые ситуации и типовые решения. В лекциях даются упрощённые однобокие примеры. На каждом проекте свои проблемы, подходы и технологии. У каждой задачи несколько решений.
Анализируйте то, что делаете. Даже если вы ещё джуниор или мидл, и задачи выглядят как «напиши это по подобию того». Посмотрите на задачу шире и постарайтесь понять, почему сделано так, а не иначе. Когда читаете статьи и смотрите лекции задавайте себе вопрос - как ещё решить исходную проблему? Когда мой вариант лучше варианта из статьи? Сначала будет казаться, что других достойных опций нет, но со временем вы будете видеть их всё чаще.
Мгновенного профита от такого процесса не будет, но если привычка закрепится — вы будете на голову выше своих коллег. Чем выше должность - тем больше принимаемых решений и тем важнее навык критического мышления.
В разработке ПО полно инертности. Однажды выбранные способы решения выбираются снова и снова. Thinking out of the box — самый редкий и ценный навык и над ним тоже нужно работать.
#soft_skills
👍21❤2👎1🔥1
Эффективное код ревью
и как сделать его лучше.
Практика код ревью используется на многих проектах, потому что это:
1. Обмен знаниями о проекте и технологиях внутри команды.
2. Повышение качество кода.
3. Способ найти оптимальное решение задачи.
В слаженных командах с утверждённым кодстайлом и схожим бэкграундом код ревью действительно даёт эти преимущества. А вот для новичка или в молодых командах код ревью часто приводит к конфликтам и непониманию.
Каждый проект уникален, но общие правила выглядят так:
1. Время автора кода и ревьюеров — ценный ресурс.
2. Код — это инструмент решение задачи, а не отражение личности разработчика.
3. Замечания должны быть конструктивны и понятны.
На верхнем уровне это все понимают, но чтобы на практике увеличить прозрачность и эффективность этого процесса, нужно обсудить и чётко обозначить:
1. Время, в течение которого ревьюеры обязаны посмотреть код.
2. Код-стайл команды — обычно в виде файла для настройки форматирования IDE
3. Приоритеты при решении задачи:
- производительность (высоконагруженные системы),
- чистота кода (open-source проекты),
- лёгкость понимания (проекты с большим количеством разработчиков),
- простота модификации (стартапы)
и тд.
4. Действия при разногласиях - чаще всего это предоставить решение третьей стороне конфликта
2 часа обсуждать имя переменной - это трата времени. Не надо так.
#soft_skills
и как сделать его лучше.
Практика код ревью используется на многих проектах, потому что это:
1. Обмен знаниями о проекте и технологиях внутри команды.
2. Повышение качество кода.
3. Способ найти оптимальное решение задачи.
В слаженных командах с утверждённым кодстайлом и схожим бэкграундом код ревью действительно даёт эти преимущества. А вот для новичка или в молодых командах код ревью часто приводит к конфликтам и непониманию.
Каждый проект уникален, но общие правила выглядят так:
1. Время автора кода и ревьюеров — ценный ресурс.
2. Код — это инструмент решение задачи, а не отражение личности разработчика.
3. Замечания должны быть конструктивны и понятны.
На верхнем уровне это все понимают, но чтобы на практике увеличить прозрачность и эффективность этого процесса, нужно обсудить и чётко обозначить:
1. Время, в течение которого ревьюеры обязаны посмотреть код.
2. Код-стайл команды — обычно в виде файла для настройки форматирования IDE
3. Приоритеты при решении задачи:
- производительность (высоконагруженные системы),
- чистота кода (open-source проекты),
- лёгкость понимания (проекты с большим количеством разработчиков),
- простота модификации (стартапы)
и тд.
4. Действия при разногласиях - чаще всего это предоставить решение третьей стороне конфликта
2 часа обсуждать имя переменной - это трата времени. Не надо так.
#soft_skills
👍8❤1🔥1