Ошибки начинающего программиста (часть 3)

Еще немного и еще чуть-чуть и мы определим все ошибки начинающего программиста. Хотя разве ошибки могут закончится? Вряд ли… Поэтому просто поговорим о самых распространенных. Продолжаем. Предыдущая часть ошибок программиста-новичка.

9) Использование неправильных структур данных

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

10) Порча существующего кода

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

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

11) Написание комментариев к очевидным вещам

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

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

12) Не написание тестов

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

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

Существует еще методика TDD (Testing-driven development), т.е. разработка от тестирования, когда тестовые кейсы пишутся раньше реализации. После пишется код удовлетворяющий тест. Во многих случаях использование этой методики позитивно сказывается на качестве кода и реализации проекта. Если вы можете использовать эту методику – используйте ее.

13) Ошибочно думать, что если что-то работает, то так будет во всех случаях

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

14) Признание существующего кода правильным

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

15) Следование лучшей практике

Сегодня часто можно услышать термин “лучшая практика” и выражения в стиле “Вот так вот делать лучше всего!”, “Это единственный верный вариант!”. Не ведитесь на такие вещи! Лучших практик на самом деле не существует. То, что вчера казалось идеальным решением проблемы сегодня может уже не быть таковым. Принимайте каждое существующее решение сомнению, анализируйте существующие решения и принимайте те из них, которые вы действительно считаете обоснованными.

16) Преждевременная забота о производительности

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

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

devOSA