Чтобы стать отличным программистом, нужно много времени, но есть несколько вещей, которые вы можете улучшить прямо сейчас

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

Попробуйте взломать свой код

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

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

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

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

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

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

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

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

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

Делайте небольшие коммиты и запросы на извлечение

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

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

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

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

Создавайте быстро, а затем выполняйте рефакторинг

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

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

Мышление имеет решающее значение, но легко попасть в ловушку чрезмерного обдумывания. Поэтому, когда у вас есть некоторое представление о возможных решениях, выберите наиболее многообещающее и начинайте кодировать. Не пытайтесь сделать свой код безупречным или учитывать все крайние случаи. Просто завершите важные части вашего кода. Детали не важны. То же самое и с полезными правилами программирования, такими как Don’t Repeat Yourself (DRY). Можно повторять все, что вам нужно, пока вы работаете над первым черновиком кода. Теперь у нас должно быть что-то, что более или менее работает. Замечательно!

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

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

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