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



Пишите больше кода


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



Пишите проверки для кода


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

Давайте посмотрим на пример ниже:

function postData(data) {
 boolean valid = true;
 // проверим, если данные определены
 if (data === undefined) {
   valid = false;
 } // проверим, если email хорошо сформирован
 if (!regex(data['email']) {
   valid = false;
 } // проверим, если пароль имеет не меньше 8 символов.
 if (data['password'].length < 8) {
   valid = false;
 }if (valid) {
  http
   .post(`example.com/user/create`, data)
   .then((response) => {
    //добавляем в лист
    this.users.append(response.userid);
   })
   .catch((error) => {
    // показываем ошибки.
   });
 } else {
   showValidationError();
 }
}


Таким образом, метод postData делает несколько вещей, таких как проверка данных, добавление в список пользователей, когда это разрешено, и обработка ошибок. Написание юнит-теста для postData будет сложным и грязным. Вы можете разбить его на несколько методов и протестировать каждый метод отдельно, например:

function postData(data) {
 return http
   .post(`example.com/user/create`, data);
}function validate(data) {
 // проверим, если данные определены
 if (data === undefined) {
   return false;
 }// проверим, если email хорошо сформирован
 if (!regex(data['email']) {
   return false;
 }// проверим, если пароль имеет не меньше 8 символов.
 if (data['password'].length >= 8) {
   return false;
 }  return true;
}function appendUsers(userId) {
  this.users.append(response.userid);
}function main() {
 if (validate(data)) {
  postData(data)
   .then(data => appendToList(data.userId))
   .catch(error => handleError(error))
 } else {
  showValidationError();
 }
}


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

Будьте честным


Будьте честны в том, что вы знаете полностью, а что нет. Делая вид, что вы знаете все о API-интерфейсах, вы никогда не сможете развиваться, и в результате вы можете опозорится в дискуссии, если вы скажете что-то глупое из-за недостатка знаний о теме API.

Участвуйте в open-source проектах


Участвуя в open-source проектах вы можете обезопасить себя теми сценариями, которые никогда бы не могли произойти на работе и, таким образом, ограничить ваш кругозор. Вы сможете понять, что нужно для запуска проекта в распределенном сценарии, какие нужно внесение неразрывных изменений и другие новые инструменты с открытым исходным кодом. Преимущества бесконечны, и мы все знаем, как открытый исходный код прямо или косвенно изменил жизнь каждого.



Будьте готовы помочь


Помогая другим в чем-то, в чем вы разбираетесь, вы становитесь «готовым» человеком для этой концепции / функции / API и тем самым ограничиваете свою ценность и важность в команде. Будьте открыты для помощи в тех вещах, в которых вы не лучшие, в конечном итоге у вас появится ценный опыт.

Выберите персональный проект


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

Понизь свое эго


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



Поймите «почему»


Прежде чем принять и обуздать свою веру в новую платформу, шаблон или API, попробуйте сначала понять, вот это «почему» и из-за чего он существует. Попытайтесь добраться до интуиции в которой существует концепции.

var app = new Vue({
  el: '#app',
  data: {
    message: 'Hello Vue!'
  }
})


Выше приведен первый пример кода, который вы встретите в документации на сайте vue.js. Даже когда я смотрю на этот очень простой пример, я пытаюсь объяснить следующие вещи в моей голове:

Для чего новое ключевое слово для создания компонента? Почему у них нет фабричного шаблона для создания объектов?

Похоже, свойство el принимает идентификатор элемента и почему оно использует #? Означает ли это, что я могу добавить другие селекторы элементов, такие как атрибут и класс?

Данные выглядят как очень общее имя свойства объекта vue, что он пытается представить?

Я не говорю, что вы должны быть критически настроены вот так к отношении всему, но выработка этой привычки помогает лучше понять философию вещей и тем самым улучшить ваше понимание.

Не ленись


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



Решайте задачи по программированию


Решение задачи по программированию. Они заставят вас думать о вещах, которые мы считаем разумеющимся в нашей рутине. Я говорю о пространственно-временной сложности нашего кода. Некоторые люди утверждают, что решать задачи непрактично, поскольку большинство вещей абстрагировано, и вы просто будете использовать API.

Но я не согласен! Это не только поможет вам критически взглянуть на код, но также даст вам уверенность в том, что вы сможете найти лучший код по производительству, и еще одним преимуществом является то, что вы всегда будете готовы к этому собеседованию

Некоторые сайты для решения задач — это LeetCode, HackerRank и Project Euler.

Поощряйте хорошие вещи


Если вам понравился коммит вашего коллеги, не стесняйтесь оставлять сообщение и цените или одобряйте тот ответ, который помог вам в stackoverflow или похлопайте за статью на medium, которая дала вам бесплатную мудрость или звезду того интересного проекта, который вы проверили на github. Поощрение других помогает извлечь из них лучшее, а в конечном итоге и вас.

Не прячься за слоем


Вы обнаружили проблему с API, которую, на ваш взгляд, вы используете, но не можете ее исправить, потому что вы являетесь «фронтенд разработчиком». Это плохое отношение, по моему мнению. Основные принципы программирования, такие как DRY, использование абстракций, если вы видите несколько вариантов использования для ваших классов, перехват исключений для всех путей управления потоком и т. д., применимы практически к каждому слою стека. Если вы будите помнить об основных принципах, это может помочь вам решить проблемы, которые, по вашему мнению, не могут быть затронуты, потому что вы не работаете над этой частью кодовой базы.



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


Вууух, вроде перевел.

Если вам понравилась эта статьи (а я надеюсь, так как я много убил времени на перевод) лайкните ее, прокомментируйте, а также зайдите на мой сайт с другими новостями по программированию и оцените их. Например из последних — это "Как сделать калькулятор на javascript", "Советы о том, как стать лучшим программистом" и другие.

Я буду очень признателен вам за это и благодарен!)

Я в твиттере и вк

Комментарии (18)


  1. kruslan
    03.09.2019 21:00
    +1

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


    1. sshikov
      03.09.2019 21:12
      +4

      Ага. А тут с самого же начала:

      Пишите больше кода…
      Для того, чтобы стать лучшим, надо тратить много времени на это

      Между «стать лучше» и «писать больше кода» — пропасть… Иногда если подумать, можно вообще код не писать — и это будет лучшим решением.

      Не ленись

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


      1. vlreshet
        03.09.2019 21:56

        Ага, щаз. Хороший разработчик должен быть хотя бы немного ленив. Иначе он тупо сядет, и закодирует первое пришедшее в голову решение. А так делать не стоит.
        Более того — крутые инструменты зачастую вырастают из чего-то вроде «руками можно сделать за час, но лучше два дня буду писать код и автоматизирую это». Ибо руками — лениво.


      1. panteleymonov
        04.09.2019 03:37

        Иначе он тупо сядет, и закодирует первое пришедшее в голову решение. А так делать не стоит.

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


  1. vlreshet
    03.09.2019 21:06

    Для тех кому лень читать весь пост: пишите хорошо, не пишите плохо, думайте когда кодите.

    Очень важный и полезный пост открывающий глаза на мир разработки </sarcasm>


    1. JekaMas
      03.09.2019 21:10
      +2

      И не проверяйте регулярками email


  1. xakepmega
    03.09.2019 21:09
    +1

    имхо сразу надо набить шишки на плохом написании и вырабатывании понимания во что каждое так-себе решение выльется в будущем + понимание в какую сторону будет растит система и бизнес требований, а статья прям водная мокрая вода


  1. Mephi1984
    03.09.2019 21:09
    +10

    The basic principles of programming such as keeping the code DRY
    Основные принципы программирования, такие как хранение кода СУХИМ

    Вот тут орнул, спасибо


    1. sshikov
      03.09.2019 21:17
      +1

      Да еще ведь и погуглить лень (первая же ссылка в поиске ведет куда надо, стоит лишь уточнить dry + programming, например, или dry principle).


    1. Rapprogtrain Автор
      03.09.2019 21:20

      а как надо правильно перевести. Подскажи пожалуйста


      1. VolodjaT
        03.09.2019 21:33

        Это абривеатура


      1. aleksandy
        03.09.2019 21:33
        +2

        «Основные принципы программирования, такие как „не повторяйся“ (DRY)»?

        Вообще, переводить аббревиатуры, особенно в IT, лучше не следует, чтобы не возникло недопонимания, т.к. DRY знают многие, если не все, а вот о СУХОМ коде, я впервые прочёл.

        P.S. А если бы был упомянут YAGNI?


      1. vfreelancer
        03.09.2019 22:02

        DRY — don't repeat yourself — принцип программирования — избегать дублирования кода


    1. alexzzam
      04.09.2019 00:24
      +2

      Ага, а в строке var app = new Vue({ есть «новое ключевое слово».


  1. valemak
    03.09.2019 21:45
    +1

    Забавно, в подзаголовках обращение к читателю то на «Вы» (пишите, будьте, поощряйте), то на «ты» (понизь, не ленись, не прячься).


  1. sfi0zy
    03.09.2019 22:01
    +1

    Эту статью уже переводили в прошлом году.


    1. Rapprogtrain Автор
      03.09.2019 22:04

      не заметил. Когда начинал переводить текста, проверил его на уникальность была 100%


      1. justmara
        03.09.2019 22:40
        +6

        ну, если переводить dry, как "сухим", то несложно достигнуть уникальности 100%, да