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

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

Построение ментальной карты

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

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

Простота важнее удовлетворенности

Часто бывает так, что задача, которую нужно решить, является элементарной и несложной. Вы собираете требования от бизнес-команды, планируете и оцениваете несколько часов работы, и все готово. Вот тогда этот сумасшедший, эгоистичный ум, который у вас в голове, начинает играть в игры. Как я могу реализовать такую ​​простую вещь ?. Мой код не может выглядеть так скучно! В конце концов, мы инженеры; мы любим создавать сложные сложные решения.

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

Преждевременная оптимизация

Оптимизация без предварительного измерения почти всегда преждевременна. Но я думаю, что приведенное выше заявление Дональда Кнута в большинстве случаев неверно истолковывается. Это не должно служить оправданием написанию плохого кода. Я считаю, что этот комментарий должен быть более подходящим, поскольку преждевременная микрооптимизация - корень всех зол. Нам все еще нужно выполнить макрооптимизацию с хорошей архитектурой, дизайном базы данных, потоком данных и т. Д. Почти 90 процентов оптимизации должно происходить на уровне архитектуры. Даже при выборе алгоритма и структуры данных вы должны принимать обоснованные решения. Такие вещи, как выбор алгоритма O (log N) вместо O (N²), часто имеют смысл и должны быть рассмотрены заранее.

Оптимизация почти всегда требует затрат времени и технического обслуживания. Следовательно, разумно определить проблему и проанализировать ее, прежде чем работать над ней. Две недели на оптимизацию функции, которая запускается один раз в день по десять миллисекунд, - это не оптимизация, это излишество! При этом микрооптимизации не всегда плохи. Но выполнение этого в неподходящее время в цикле разработки может серьезно повлиять на вашу производительность.

Заставьте это работать, сделайте это правильно, сделайте это быстро - Кент Бек

Ссылки