И избегать в процессе.

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

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

  1. Плохое имя переменных и функций:за исключением, например, индекса цикла, настоятельно рекомендуется осмысленное имя.
  2. Не комментируйте свой код: обычно код пишется один раз, проверяется и исправляется десятки раз. Поэтому иногда невозможно понять, что мы кодировали некоторое время назад.
  3. Злоупотребление вводом с клавиатуры и выводом на экран. Как правило, компьютерная программа предназначена для диалога с другой программой, а не напрямую с пользователем-человеком.
  4. Знаменитый «выход»: в принципе, они уже искоренены. Я не знаю никого, кто серьезно преподает программирование с таким. Это не догма. Но их использование вызывает нарушение «линейности» чтения кода. Это делает доказательства завершения, доказательства правильности и анализ сложности очень сложными. Примечание: на первый взгляд может показаться, что разрыв в цикле имеет те же недостатки: на самом деле это не так. Разрыв обходит код, но чтение (и выполнение) остается «линейным».
  5. Использование глобальных переменных: по возможности следует избегать. Но я признаю, что время от времени я не знаю, что еще делать (копать)
  6. Плохое управление временем. Не настаивайте, если у вас нет решения, попросите о помощи, смените тему, чтобы вернуться позже. Неважно, если вы не знаете. Вы не можете знать все.
  7. Развлекайтесь (нечитаемый код, советы и приемы, понятные только самому себе, добавление функций не запрошенных, но классных) — см. agile-манифест — не слушая запрашивающего, который в любом случае считается « скучно» из-за отсутствия разработчика.
  8. Не тестируйте свой код. Вначале мы пренебрегаем тестами из-за нехватки времени. Я прекрасно понимаю, но есть ошибки, которые мы не понимаем, больше побочных эффектов везде в программе, и мы осознаем, что нужно писать тесты. С другой стороны, тест часто пишется быстро и может быть адаптирован в соответствии с модификациями кода.
  9. Использование нестабильных версий фреймворков. Многие программисты сохраняют версию своей фреймворка, хотя она устарела или никогда не была LTS. Это практика, от которой я настоятельно рекомендую отказаться. Фреймворк, который не поддерживается, может очень быстро стать проблемой.
  10. Всегда читайте передовой опыт и применяйте его.Знать, как программировать, — это одно, а уметь кодировать хорошо — совсем другое. Иногда я программирую вслепую, не обращая внимания на передовой опыт, но очень быстро замечаем, код становится нестабильным, а тесты не работают.
  11. Используйте существующий и стабильный фреймворк или библиотеку вместо того, чтобы изобретать велосипед.Многие программисты, в том числе и я, часто зациклены на том, что им приходится делать все без особой причины, но мы быстро понимаем, что изобретают вещи, которые уже существуют. Чтобы быть гибким, я думаю, что лучше использовать инструмент, который уже существует и работает или вносит свой вклад в проект, если он с открытым исходным кодом.
  12. Избегайте копирования и вставки, потому что мы также вставляем ошибки! А когда код нужно модифицировать, его нужно модифицировать везде, где было копирование-вставка,
  13. Не иметь представления о качестве кода и не проверять его. Сегодня это означает не включать SonarQube в его репозиторий или его кузницу -› Политика страуса, мой код гнилой, но я не хочу об этом знать.
  14. Отсутствие централизованного отслеживания (в идеале — вики) функциональных и бизнес-правил, реализованных в коде.
  15. Начните кодировать эволюцию, не очистив и не факторизовав существующий код — Технический долг.
  16. Не форматируйте весь код уникальным образом — это стиль для C/C++/Java, Perl. Их десятки, адаптированных ко всем языкам, но выбрать нужно один.
  17. Не используйте интерфейсные вызовы библиотек, специфичных для инструмента. Компоненты системы должны быть делимыми. Должна быть возможность изменять инструменты (BDD, MQ и т. д.), не оказывая влияния на код.
  18. Разместите описание кода в другом месте, кроме самого кода.
  19. Не вести журнал выполненных операций. В режиме отладки мне нужно знать все, что происходит в приложении, вызовах и обмене данными.
  20. Бросаться к его клавиатуре, прежде чем он обдумает элементы проблемы. Лучший программист, которого я когда-либо знал, мог начать с того, что целыми днями сидел за клавиатурой и писал объяснения, описывающие, как он представляет себе решение проблемы; код будет следующим, если можно так сказать, в качестве фона для объяснений, которые стали комментариями к программе.
  21. Не беспокойтесь о надежности кода с самого начала (анализ всех возможных случаев ошибок, анализ достоверности данных и т. д.), откладывая его, не терпя увидеть, как он работает. По моему опыту, плохо спроектированный код никогда не будет безопасным.

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

Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter и LinkedIn. Присоединяйтесь к нашему сообществу Discord.