Общие ошибки начинающих разработчиков
Запись от Storm23 размещена 12.04.2017 в 08:00
Показов 6327
Комментарии 13
|
Здесь приводится обзор наиболее частых ошибок начинающих (и не очень) программистов. Эти ошибки не привязаны к какому либо конкретному языку программирования, а являются общими проблемами начинающих разработчиков ПО. 1. Отсутствие плана действий. Основной принцип, позволяющий эффективно выполнить работу за минимальное время - это разработка четкого плана действий. Большинство начинающих разработчиков приступает к выполнению задания без выполнения достаточной подготовительной работы. В результате - работа либо не выполняется, либо сроки ее выполнения срываются. В самом плохом варианте - разработчик просто не знает что он делает. В лучшем случае - начинающий программист мечется между разными вариантами решения задачи, и только в конце работы осознает, что время было потрачено впустую и что правильное решение можно было найти гораздо быстрее, если бы была проведена подготовительная работа. Когда нам назначается новая задача, мы должны сначала ее тщательно понять, а затем разработать и проверить алгоритм решения. Реализация должна начинаться только после разработанного алгоритма решения. 2. Они кодируют решение, и не задумываются о его эффективности. Каждое решение имеет два аспекта - верность решения в смысле получения правильного результата и оптимальность решения в смысле эффективного использования ресурсов и времени. Для примера возьмем задачу коммивояжера. Прямой метод решения этой задачи - полный перебор - дает правильный результат. Но поскольку число перебираемых вариантов растет экспоненциально с увеличением числа городов, то прямой перебор даже для нескольких городов будет вычисляться очееень долго. Можно ли считать прямой перебор решением задачи? Очевидно нет. Новички же, в большинстве случаев, как только получают правильный ответ, считают задачу выполненной, и не пытаются проверить/улучшить эффективность решения. Решение задачи должно быть не только правильным но и эффективным. 3. Нет четкой архитектуры, беспорядочное форматирование кода. Четкая архитектура и правильное форматирование кода всегда приводят к эффективному, легко управляемому и легко понимаемому решению. Если в начале проекта не была выбрана четкая архитектура и проект строится беспорядочно - это всегда приводит к сложному решению. Всякий раз, когда нам нужно внести изменения в проект, нам потребуется все больше времени на модификацию, если архитектура проекта не была однозначно определена. Аналогично, правильное форматирование делает код более читабельным и простым для понимания. Неправильное форматирование - создает ненужную путаницу и заставляет программиста тратить больше времени на понимание кода. Всегда задавайте архитектуру проекта перед его реализацией. 4. Дублирование кода. Если новичкам дается задание и они ранее уже выполняли подобное задание, то они просто копируют код и вставляют в новый проект. На первый взгляд они сэкономили время и ускорили разработку. Но на самом деле они создали проблему, называемую дублирование кода. Допустим начальный код содержал ошибку. Если код был неоднократно скопирован, то нам придется искать и исправлять эту ошибку во всех копиях этого кода, что по сути является ненужными усилиями. Также, если мы задумали усовершенствовать алгоритм или расширить функционал, то нам придется производить эти исправления во множестве копий кода. Вместо дублирования кода, нужно делать повторное использование кода. Если нам нужно разработать некий функционал и использовать его в нескольких местах программы, то функционал нужно выделить в отдельную функцию, и вызывать эту функцию из разных мест. А не дублировать один и тот же код в разные места. 5. Отсутствие четких принципов именования переменных, методов, классов. Соглашение об именовании - очень важный аспект всего программного проекта и играют важную роль для успешного его завершения и дальнейшего развития. Имена переменных типа a, b, c, d - это наилучшие примеры наихудших имен переменных. Они плохи, потому что они ничего не означают. Аналогично, бессмысленные или слишком общие имена классов/методов/функций делают программный код нечитабельным, если не сказать бессмысленным. Правильное именование делает код самодокументируемым, делает ненужными комментарии, снижает вероятность случайных ошибок и опечаток. Также правильное именование облегчает ведение логов и вывод сообщений об ошибках - они становятся гораздо более информативными. Названия должны быть осмысленными и указать максимально возможную информацию. Нет ничего плохого в длинных описательных именах, если эти имена дают нам понять семантику объекта, который они обозначают. Нужно избегать неправильного использования комбинаций верхнего и нижнего регистров, знаков подчеркивания, избегать коротких форм и случайных имен. 6. Неправильное исправление ошибок, приводящее к новым ошибкам. Исправление ошибок является одним из основных видов деятельности всех программистов. И тут есть один важный момент. Просто исправить ошибку - это еще не все. Более важным моментом является исправить эту ошибку правильно. Часто возникают ситуации, когда новички сосредотачиваются только на симптоматическом устранении ошибки. При этом, они игнорируют контекст и не решают проблему в целом. В результате, исправление ошибки провоцирует возникновение новых ошибок - сразу или в перспективе. Например, мы ведем базу клиентов, в которой есть поле City. Разумеется, это поле очень важно для нас. И вот пользователь сообщает программисту, что при попытке внести данные о клиенте, программа выдала сообщение об ошибке: "Невозможно вставить NULL в столбец City". Что бы решить эту проблему, предположим, программист просто открыл таблицу базы данных и присвоил полю City значение nullable, таким образом разрешив использовать NULL в качестве значения поля City. Казалось бы проблема решена, и ошибка исправлена. Но на самом деле, своими действиями программист создал целый каскад других ошибок - связанных с тем, что обрабатывающие алгоритмы не ожидают значения NULL в поле City, либо связанные с потерей полезной информации (поскольку у пользователя теперь будет возможность не вводить это поле). Целесообразно сосредоточится на системном исправлении ошибок, а не на устранении отдельных симптомов. 7. Плохое знание IDE, языка программирования и других средств разработки. Когда мы покупаем новый телефон, мы никогда не забываем попробовать каждую его функцию. Точно так же, когда мы начинаем изучать новые технологии, язык программирования или инструмент разработки, мы должны сначала изучить каждую его функцию, чтобы максимально эффективно его использовать. Таким образом, мы сможем сэкономить свое время, пользуясь готовыми инструментами. 8. Редкое использование средств отладки. Отладка означает обнаружение и устранение ошибок в программе. Средства отладки помогают нам найти и устранить ошибки в минимально возможное время. Большинство новичков почему-то редко используют отладчик. Программисты должны максимально использовать средства отладки для обнаружения и исправления ошибок, а также для того, что бы более глубоко понять как работает код. 9. Игнорирование бекапов и систем контроля версий. Резервное копирование - важная часть нашего повседневного труда. Не нужно объяснять, что случайная потеря кода означает то, что код нужно будет писать повторно. Сейчас доступно множество средств автоматического создания резервных копий и контроля версий кода. Мы можем эффективно использовать их и иметь резервную копию каждого кусочка нашей работы в любой момент времени. 10. Неправильное использование технологий, методов, алгоритмов и структур данных. Типичная ошибка новичка - использование алгоритмов, методов, технологий и классов для решения задач, для которых они не приспособлены. Обычно это вызвано незнанием или непониманием соответствующих технологий, незнанием фреймворка, непониманием алгоритмической эффективности, незнанием базовых структур данных и недостатка опыта работы с ними. Бывает и другой случай - эффект "золотого молотка" - когда опытный программист пытается использовать один и тот же хорошо знакомый ему инструмент для решения абсолютно всех задач, независимо от того, подходит ли данный инструмент для них или нет. Мы всегда должны использовать те инструменты, которые дадут нам наибольший эффект при наименьших затратах. 11. Изобретение колеса. Незнание технологий также может вести к другой проблеме - к "изобретению колеса". Часто новички не хотят тратить время на изучение технологий, фреймворка на котором они пишут, и даже на изучение уже готовых функций своей программы. Что приводит к трате времени на написание уже существующего кода, дублированию. При этом качество и функционал изобретенного "колеса" обычно хуже. Перед решением задачи, нужно изучить существующие решения. Пишите новый код только если аналогов нет или они не подходят по веским причинам. ________________________________________ ________________________________________ __ Этот пост является вольным переводом статьи Common-Mistakes-By-Beginners-In-Programming-World, с дополнениями из обсуждения на LinkedIn и компиляцией собственных мыслей по этому поводу. Также я вырезал и исправил некоторые спорные моменты. |
Размещено в Без категории
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Всего комментариев 13
Комментарии
-
Тут важно бы понимать о насколько "начинающих" речь, об уровне начинания.
И от этого плясать. Если совсем начинающих, то некоторые советы плохо применимы.
К примеру вместо того что бы гонять отладчик, полезнее было бы напрячь мозги и найти ошибку самому проглядывая код.
То же касается написания своих "велосипедов" с целью изучения.Запись от Avazart размещена 12.04.2017 в 13:22 
-
Для исчерпывающего понимания по каким правилам стоит программировать можно всегда посоветовать "Code Complete". Правда, лично по мне, уж чересчур исчерпывающего
.
Знание "велосипедов" можно даже отнести к культуре программиста, да и для мозгов полезно. Но в реальных условиях, конечно, стоит пользоваться готовыми и проверенными решениями.Запись от Garcian размещена 12.04.2017 в 15:32
-
Ну одно другому не мешает. Конечно думать нужно, но часто складывается такое впечатление, что люди просто не знают о существовании отладчика. Иначе откуда инфантильные вопросы типа "а у меня вот 20 строк кода и в конце ВНЕЗАПНО неправильный результат" или "У меня ошибка" (это полный текст вопроса
Сообщение от Avazart
)Запись от Storm23 размещена 12.04.2017 в 16:36
-
Я сам люблю писать велосипеды. Но одно дело писать просто так для себя, а другое дело профессиональная разработка.
Сообщение от Garcian
Запись от Storm23 размещена 12.04.2017 в 16:38
-
Жесть. Для меня самые трудновыполнимые пункты 7 и 9.Запись от mozgotron размещена 15.07.2019 в 10:07
-
Разве вам кто-то мешает это осваивать?Запись от Rius размещена 15.07.2019 в 11:47 
-
2. Они кодируют решение, и не задумываются о его эффективности. (?)
...
Лучше верное решение, чем эффективное, но не верное.
Медленную, но верную программу можно потом доработать до быстрой.Запись от wer1 размещена 16.07.2019 в 06:58
-
11. Изобретение колеса. (?)
...
Кто-то сказал... Что легче решить задачу самому, чем найти её на просторах интернета.
Действительно, поиск может быть долгим, если не вечным! А найденное решение, если оно есть, может вам не подходить. Зачем человеку мозги? Искать можно всю жизнь и не найти!Запись от wer1 размещена 16.07.2019 в 07:05
-
7. Плохое знание IDE, языка программирования и других средств разработки. (?)
...
Программирование тут ни при чём.Запись от wer1 размещена 16.07.2019 в 07:07
-
6. Неправильное исправление ошибок, приводящее к новым ошибкам. (?)
...
Нет логики. "Неправильное исправление ошибок" - Такой термин ещё придумать надо!
Ошибка либо исправляется, либо нет. Третьего не дано!!!Запись от wer1 размещена 16.07.2019 в 07:11
-
4. Дублирование кода. (?)
...
Почему нет? Хороший проверенный код можно дублировать многократно.
Это не ошибка! Это наше русское авось да небось!Запись от wer1 размещена 16.07.2019 в 07:16
-
Ох же этот номер 5 ) Сколько же мне пришлось прочитать решений задач, где эти "a, b, c, d" всё прут и прут. Ладно там "x, y, z", которые по контексту понятно за что отвечают или "i, j, k" в циклах, которые есть в примерах во многих учебниках и применяются как индекс массива/списка.
Пока не придётся переписывать все эти N дублей...Запись от wmysterio размещена 12.08.2019 в 18:02
-
Потом уже поздно, время на разработку невозвратимо потрачено, а программа не соответствует требованиям(если есть требования к скорости).
С таким же успехом можно сказать что "эффективное решение можно потом доработать до верного".Запись от Avazart размещена 13.08.2019 в 11:44
. 
Сообщение от Avazart
)
