Распространенные инженерные ошибки, которые допускают начинающие разработчики программного обеспечения: Часть-1

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

Многие инженеры-программисты, особенно те, кто только начал заниматься разработкой, часто сосредотачиваются исключительно на проблеме разработки, и поэтому их программное обеспечение редко бывает масштабируемым или обслуживаемым в долгосрочной перспективе. Многие разработчики с трудом понимают свой собственный код, который они написали месяц назад и который плохо масштабируется, когда они начинают работать в команде. В команде часто другие натыкаются на ваш код, когда им приходится его использовать или рефакторить. Будет очень неприятно, если вам придется объяснять написанное новому человеку каждый раз, когда возникнет такая ситуация. Поэтому, работая в команде со старшими инженерами, которые проверяют ваш код, новые разработчики часто сталкиваются с многочисленными комментариями и просьбами о внесении изменений. Поверьте мне, я был там, мой PR однажды имел около 40+ комментариев на GitHub, когда я проходил свою первую стажировку.

До сих пор я работал в нескольких стартапах на ранних стадиях и выполнял несколько фрилансерских заказов и видел, как многие новые разработчики сталкиваются с несколькими проблемами, которыми я поделюсь с вами. Я рекомендую разработчикам прочитать книгу «Чистый код»: Robert C Martin, так как она более доступна, особенно для начинающих разработчиков.

Ошибка 1 — самая распространенная ошибка

Плохое именование переменных, функций или любых подобных идентификаторов.

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

Я не могу подчеркнуть этого достаточно, но называйте свои переменные в соответствии с тем, для чего они используются. Я видел, как некоторые люди используют такие имена переменных, как —

var a , final c, const b

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

function double(num){//code to double multiple of 3}

function doubleMultipleOfThree(num){//code to double multiple of 3}

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

if(number > 0) double(number);

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

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

Ошибка 2 — Непонимание GIT

Два основных преимущества использования Git при разработке программного обеспечения:

1. Отслеживание изменений и обновлений. Мы можем видеть, кто и какие изменения внес. Git также предоставляет информацию о том, когда и почему было сделано то или иное изменение.

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

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

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

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

1. Rebase
2. Stash
3. Merge
4. Статус
5. Log
6. Diff
7. Revert

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