20 ошибок начинающего программиста. | SHIFU.IO
Переводы
20 ошибок начинающего программиста.
Редакция 01.04.2018

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

Ошибка №7 Не использовать инкапсуляцию (изоляцию отдельных компонентов).

Использование концепции инкапсуляции всегда полезно. Неиспользование, напротив, часто приводит к более сложным системам. В приложении функция должна иметь только один обрабатываемый объект. Этот объект должен показывать только то, что необходимо для использования другими объектами приложения. Речь идет не о секретности, а о концепции сокращения зависимостей между различными частями приложения. Придерживаясь этого правила, вы сможете безопасно вносить изменения во внутренние части своих классов, объектов и функций, не беспокоясь о том, чтобы испортить что-то в большем масштабе. Концептуальные единицы должны получать свои собственные классы. Это может быть фактический объект класса или объект Function. Вы также можете идентифицировать его как модуль или пакет. В рамках класса самодостаточные части задач должны иметь свои собственные методы. Методы должны делать что-то одно и делать это хорошо. Аналогичные классы должны использовать аналогичные имена методов.

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

Ошибка №8 Планировать неизвестное.

  • Рост ради роста — это идеология раковой клетки. Эдуард Абби

Не пишите код, который вам не нужен сегодня. Не планируйте (и тем более не пишите) на неизвестное будущее то, что, как вам кажется сейчас, может пригодиться в будущем в проекте. Это неправильно. Всегда рассчитывайте минимальный объём кода, который вам нужен сегодня для решения, которое вы реализуете.

Ошибка №9 Использовать неверные структуры данных.

При подготовке к собеседованию начинающие программисты обычно уделяют слишком много внимания алгоритмам. Прекрасно, если вы распознаёте и используете хорошие алгоритмы, но их запоминание вряд ли будет отнесено к вашему таланту программиста. Скорее всего вы не в состоянии запомнить их все, тем не менее, запоминание сильных и слабых сторон различных структур данных, используемых в вашем языке программирования, безусловно, сделает вас лучшим разработчиком, чем вы сейчас есть. Использование неправильной структуры данных — это большой и ярко освещённый рекламный щит, который кричит «Посмотрите сюда! Здесь код новичка!»

Эта статья не предназначена для того, чтобы научить вас структурам данных, но позвольте мне привести пару небольших примеров:

- Использование списков (массивов) вместо хешей (объектов) для управления записями

Наиболее распространенная ошибка использования неверных структур данных, — это, вероятно, использование списков вместо хешей для управления списком записей. Да, для управления СПИСКОМ записей вы должны использовать ХЕШ. Обратите внимание, что я говорю о списке записей здесь, где каждый элемент имеет идентификатор, который используется для поиска этой записи. Использование списков для хранения скалярных значений вполне нормально и, как правило, это лучший выбор, если ключевое действие - добавление (пуш) значение в список. В JavaScript наиболее распространенная структура списка - массив, а у хэша - объект (также есть структура Map в современном JavaScript). Использовать списки вместо объектов для управления записями в большинстве случаев неправильно. Хоть это и действительно верно только для больших наборов данных, я бы предложил руководствоваться этим все время. Главная причина, почему это важно, — это потому, что при поиске записей при помощи идентификаторов, хеши гораздо быстрее списков.

- Не использовать стеки

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

Ошибка №10 Сделать существующий код хуже.

Представьте, что вам дали грязную комнату. Затем вас попросили добавить предмет в эту комнату. Поскольку это уже большой беспорядок, у вас может возникнуть соблазн поставить этот предмет в любом месте. Через несколько секунд вы сможете выполнить свою задачу. Не делайте так с грязным кодом, вы сделаете его ещё хуже! Всегда оставляйте код немного чище, чем, когда вы начали работать с ним. Если вам нужно разместить вещь в этой комнате – сразу кладите его в предназначенное месте. Если это, например, предмет одежды, расчистите путь к шкафу и положить его туда. Это часть выполнения вашей задачи правильно. Так же и с кодом.

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

Ошибка №11 Написание комментариев об очевидных вещах

У меня есть трудный способ избежать комментариев – заменять комментарии на очевидно названные элементы.

Например, вместо следующего кода:

Тот же код может быть написан без комментариев:

Одно только использование понятных имен для функций делает большинство комментариев ненужными.

Однако иногда бывают ситуации, когда единственная ясность, которую вы можете добавить в код, — это комментарии. В том случае, когда комментарии должны отвечать на вопрос «почему этот код здесь», а не «что он делает».

Если же вам очень-преочень хочется написать комментарий типа «что» для уточнения кода, пожалуйста, не указывайте на очевидное. Вот пример некоторых бесполезных комментариев, которые только добавляют шум к коду:

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

Ошибка №12 Не писать тесты

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

Ошибка №13 Не докапываться до существующего кода.

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

Ошибка №14 Одержимость лучшими методами.

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

Ошибка №15 Одержимость производительностью.

  • Преждевременная оптимизация — это корень всех зол (как минимум, большей их части) в программировании - Дональд Кнут (1974)

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

Конечно, есть некоторые очевидные оптимизации, которые вы должны всегда учитывать перед введением нового кода. Например, в Node.js крайне важно, чтобы вы не наводнили цикл событий или не блокировали стек вызовов. Это пример ранней оптимизации, которую вы всегда должны иметь в виду. Спросите себя: будет ли код блокировать стек вызовов? Любая неочевидная оптимизация, которая выполняется на любом существующем коде без измерений, считается вредной и ее следует избегать. То, что, по вашему мнению, может быть усилением производительности, если это возможно, может стать источником новых неожиданных ошибок. Не тратьте время.

Ошибка №16 Не ориентироваться на опыт конечного пользователя.

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

Ошибка №17 Выбирать неправильный инструмент.

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

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

Ошибка №18 Изобретать колесо.

Это сложно объяснить. В программировании некоторые колёса нужно изобретать. Здесь так много вещей быстро меняется, и новые требования вводятся быстрее, чем любая команда может справиться. Например, если вам нужно колесо, которое вращается с разной скоростью в зависимости от времени суток вместо того, чтобы настраивать колесо, возможно, нам нужно переосмыслить его. Однако, если вам действительно нужно обычное колесо, не изобретайте его повторно. Просто используйте это долбанное колесо!

Не тратьте свое драгоценное время на изобретение более лучшего колеса. Просто сделайте быстрое исследование и используйте то, что найдете. Только заменяйте колеса, когда станет очевидно, что они не справляются с задачей. Самое интересное в программировании - то, что большинство колес свободны и открыты для того, чтобы увидеть их внутреннее устройство. Постарайтесь пользоваться колёсами с открытым исходным кодом - их можно легко отлаживать, исправлять и заменять при необходимости. Если вам нужно колесо, не покупайте целый новый автомобиль. Не включайте целую библиотеку только для использования функции или двух из нее. Лучший пример - lodash library в JavaScript. Если вам просто нужно перетасовать массив, просто импортируйте метод тасования, но не импортируйте всю бесплатную библиотеку.

Ошибка №19 Не любить code review.

Ещё один из признаков новичка - они часто рассматривают проверку кода как критику. Она им не нравятся. Они её не ценят. Или даже боятся. Это неправильно. Если вы так себя чувствуете, постарайтесь изменить своё отношение. Посмотрите на каждый обзор кода как на возможность обучения. И самое главное, благодарите своих рецензентов, когда они вас чему-то учат. Вы - ученик навсегда и вам лучше это принять. Большинство code reviews научат вас тому, что вы не знали.

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

Ошибка №20 Забывать делать перерывы

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

Это был длинный пост. Вы точно заслуживаете перерыва.

Спасибо за прочтение.

Редакция 01.04.2018