Ошибки при написании программы бывают

• 30 июн 2020

Научитесь выявлять их. Выработайте привычки избегать их.

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

Работающий код может иметь изъяны — например, быть недостаточно простым, лаконичным и понятным. Это может быть признаком более глубоких проблем в коде, а избавиться от них можно с помощью рефакторинга. В этой статье разберем наиболее популярные недостатки кода. Материал адаптирован на русский язык вместе с Глебом Михеевым, директором по технологиям Skillbox и спикером профессии «Frontend-разработчик PRO» и преподавателем курса Frontend-разработки в Skillbox Борзуновым Игорем.

Непонятный выбор имени

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

Общие принципы выбора имени:

• Стратегия выбора последовательна.

• Из имени понятно назначение переменной.

• Имена легко различимы между собой.

• Имя переменной можно произнести вслух.

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

const a = 'Frontend course';

const b = 1;

const c = '100$'

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

const courseName = 'Frontend course';

const courseId = 1;

const coursePrice = '100$'

3 + 5 * 6

(3 + 5) * 6

input = 25
x = 0.8/(Math.sqrt(input) - 5)

items = [0,1,2,3,4,5]
print items[8]
//комментарий: элементы здесь представляют собой массив с шестью элементами. Например, чтобы получить 4-й элемент, вы будете использовать [3]. Мы начинаем отсчет с 0.

input = Hippo'
if input == 'Hippo':
  print 'Hello, Hippo'

1) Программирование без планирования

Качественный контент не создаётся “на коленке”, а требует основательной работы. Программный код – не исключение.

Хороший код должен проходить через следующие стадии:

Замысел. Исследование. Планирование. Написание. Проверка. Изменение.

Каждому из этих пунктов надо уделить достаточно усилий.

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

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

“Если ты зол, сосчитай до 10, прежде чем говорить. Если очень зол — то до 100”. (Томас Джефферсон)

Для нашего случая это можно перефразировать так:

“Когда проверяешь код, сосчитай до 10 прежде чем переписать 1 строчку. Если для этого кода нет тестов — то до 100”.

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

Программирование – это не просто написание строк кода, а творчество, основанное на логике, которое надо развивать в себе.

6) Не гуглить

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

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

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

Не будьте креативным в понятиях Брета Виктора, который сказал:

“Думать, что ты знаешь, что делаешь – самая опасная мысль креативного человека”.

10) Ухудшать код

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

Вот несколько распространенных ошибок, приводящих к беспорядку в коде:

Дублирование

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

Не использование файла конфигурации

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

Лишние условные операторы и временные переменные

Любой if разветвляет логику вашей программы, поэтому их наличие должно быть сведено к минимуму, насколько это возможно без вреда для читабельности. Самое сложное – определить правильный уровень для изменений: будете вы расширять текущий код или вынесете его во внешнюю функцию и вызовете её?

Вот яркий пример ненужного if:

function isOdd(number) {
 if (number % 2 === 1) {
   return true;
 } else {
   return false;
 }
}

Его можно переписать без единого if:

function isOdd(number) {
 return (number % 2 === 1);
};

23) Злоупотребление общим состоянием (shared state)

И снова это не про сравнение парадигмы функционального программирования с остальными.

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

Большая проблема общего состояния начинается тогда, когда несколько ресурсов меняют его в рамках одной итерации цикла событий (в событийно ориентированных средах). Возникает состояние гонки (Race conditions). И новички склонны решать эту проблему посредством таймера, особенно при блокировке данных. Это большой красный флаг. Избегайте этого. Ни в коем случае нельзя писать такой код или принимать его.

Слишком много параметров

Большое число аргументов функции затрудняет чтение и тестирование кода. Разработчик Роберт Мартин в книге «Чистый код. Создание анализ и рефакторинг» назвал ноль идеальным числом параметров:

Глеб Михеев: «В идеальном случае количество аргументов функции равно нулю. Далее следуют функции с одним аргументом и с двумя аргументами. Функций с тремя аргументами следует по возможности избегать. Необходимость функций с большим количеством аргументов должна быть подкреплена очень вескими доводами».

Мутации переменной

Это специфическая проблема JavaScript, которая указывает на изменения переменной. Но мутация отличается от изменения тем, что происходит непредсказуемо. Из-за изменения одной переменной в другом месте меняется и другая, связанная с ней.

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

Хорошая практика в JavaScript — использование так называемого иммутабельного подхода: запрета мутирования переменных. Он позволяет избавиться от этой проблемы. Пример реализации –– библиотека

ImmutableJs

Если воспользоваться ключевым словом let, то значение переменной действительно можно переопределить 

let age = 25;

age = "Двадцать пять";

В случае с const, будет выведена ошибка, так как ключевое слово const неизменно в данном примере 

const age = 25;

age = 'Ягодка опять';

> Uncaught TypeError: Assignment to constant variable.

5) Не отступать

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

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

15) Одержимость лучшими практиками

Термин “лучшие практики” вредный, он ограничивает вас в исследовании, «ведь уже есть лучшая практика».

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

Довольно часто то, что вчера считалось “лучшей практикой” сегодня считается плохой практикой. Вы всегда можете найти более лучшую практику, если потратите достаточно времени для этого. Поэтому не парьтесь о “лучших практиках”, а сосредоточьтесь на том, что вы можете сделать хорошо.

Не делайте что-то, потому что где-то прочитали цитату об этом, или увидели как кто-то делает это, или кто-то сказал про это “лучшая практика”. Ставьте всё под сомнение, бросайте вызов всем теориям, знайте все возможные варианты, и принимайте только обоснованные решения.

17) Не ориентироваться на конечного пользователя

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

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

18) Не подбирать правильные инструменты

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

Ориентироваться на популярность инструмента, а не пригодность для конкретной задачи – признак новичка.

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

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

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

12) Не писать тесты

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

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

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

Если можете, создавайте проверки даже прежде самого кода. Разработка через тестирование (test-driven development, TDD) создана не для прикола и хайпа. Она благотворно влияет на то, как вы продумываете, проектируете и реализуете программные элементы.

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

2) Чрезмерное планирование

Планировать прежде чем нырять в написание кода – хорошая вещь. Но даже хорошие вещи могут навредить вам, если переборщить с ними. Даже водой можно отравиться, если слишком много её выпить.

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

Линейное планирование всей программы “от А до Я” (водопадным методом) – не годится для большинства программных продуктов. Разработка подразумевает обратную связь и вы постоянно будете удалять и добавлять функционал, что никак нельзя учесть в «водопадном планировании». Планировать следует несколько следующих элементов. И каждый новый надо включать в план лишь после гибкой адаптации к реальности (Agile).

К планированию надо подойти очень ответственно, потому что и его недостаток и избыток могут навредить качеству кода. А качеством кода ни в коем случае нельзя рисковать.

20) Изобретение колеса

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

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

Иногда бывает сложно выбрать нужное колесо из-за многообразия. Проводите исследование. Пробуйте перед покупкой. Большинство “программных колёс” бесплатны и с открытым кодом. По возможности используйте заготовки с открытым исходным кодом (open source), их легко отлаживать, улучшать, заменять и поддерживать.

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

11) Комментирование очевидных вещей

Например, такой код:

// This function sums only odd numbers in an array
const sum = (val) => {
  return val.reduce((a, b) => {
    if (b % 2 === 1) { // If the current number is odd
      a+=b;            // Add current number to accumulator
    }
    return a;          // The accumulator
  }, 0);
};

Можно заменить таким:

const sumOddValues = (array) => {
  return array.reduce((accumulator, currentNumber) => {
    if (isOdd(currentNumber)) { 
      return accumulator + currentNumber;
    }
    return accumulator;
  }, 0);
};

// create a variable and initialize it to 0
let sum = 0;
// Loop over array
array.forEach(
  // For each number in the array
  (number) => {
    // Add the current number to the sum variable
    sum += number;
  }
);

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

22) Не использование систем контроля версий (Git)

Новички склонны недооценивать пользу хорошей системы контроля версий/кода, вроде Git.

Обычно её используют, чтобы опубликовать свои изменения кода для других. Но её главное предназначение — это ясность истории. Код будут изучать и история его развития ответит на многие вопросы. Маленькие коммиты с осмысленными заголовками помогут сопровождающим код людям понять, как шаг за шагом образовывалась программа, пока не достигла текущего состояния.

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

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

Ещё одно предназначение системы контроля версий – понятность предназначения той или иной вещи. Допустим, вы столкнулись с функцией и вам надо понять её назначение и устройство. Вы можете найти коммит, в котором она появилась, и перед вами возникнет контекст её создания, что прольёт свет на всё остальное, связанное с ней.

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

Систему контроля можно использовать в разных целях, даже до того, как изменения кода превратились в официальные коммиты:

• отслеживание изменений (staging changes)
• выборочный патч (patching selectively)
• сброс (resetting)
• прятание (stashing)
• перезапись истории (amending)
• применение (applying)
• просмотр изменений (diffing)
• отмена коммитов (reversing)

Изучите все эти возможности, поймите, используйте и цените их. Чем меньше возможностей Git вы знаете, тем больше вы новичок.

Надуманная сложность

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

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

7) Не использовать инкапсуляцию

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

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

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

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

Если вам нужно создать новый метод, или расширить старый, хорошенько подумайте и прислушайтесь к интуиции. Не делайте это на авось, с мыслью “потом переделаю”. Делайте это прямо сейчас.

Стремитесь к тому, чтобы ваш код имел высокое зацепление и низкую связанность (High Cohesion and Low Coupling). Этот загадочный термин означает, что внутри класса должно быть максимально связей, а между классами – минимально зависимостей.

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

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

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

Неуместно использованная структура данных это кричащее предупреждение: “код новичка!”. Вот несколько примеров.

Обычный массив или ассоциативный?

Самая распространённая ошибка – это использование обычных массивов вместо ассоциативных для хранения списка записей.

[{id: 1, title: "entry1"}, {id: 2, title:"entry2"}, .... ]

{ 1: {id: 1, title: "entry1"}, 2: {id: 2, title:"entry2"}, ....}

Да, вы не ослышались, для хранения списка записей нужно использовать ассоциативные массивы. Под списком записей я подразумеваю такие записи, где присутствует идентификатор. Массивы оправданы для хранения скалярных величин и если планируется активное использование методов, вроде push, pop, shift, unshift, которые обращаются к записям не через ключ, а через порядок в списке.

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

Стек или рекурсия?

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

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

Стрельба дробью

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

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

25) Не отдыхать

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

13) Думать, если что-то работает, то это правильно сделано

Взгляните на эту функцию, которая суммирует нечетные числа. Всё ли там правильно?

const sumOddValues = (array) => {
  return array.reduce((accumulator, currentNumber) => {
    if (currentNumber % 2 === 1) { 
      return accumulator + currentNumber;
    }
    return accumulator;
  });
};
 
 
console.assert(
  sumOddValues([1, 2, 3, 4, 5]) === 9
);

Тест проходит. Жизнь прекрасна. Правда?
Проблема этого кода в том, что он не полный. Он корректно работает только для нескольких случаев и наш удачный тест проверяет как раз один из них.

Проблема 1

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

TypeError: Cannot read property 'reduce' of undefined.

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

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

TypeError: Cannot execute function for empty list.

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

Проблема 2

Нет валидации. Что если в функцию передадут вместо массива строку, число или объект? Вот что произойдет:

sumOddValues(42);
TypeError: array.reduce is not a function

Подвох в этой ситуации в том, что array.reduce — это как раз функция. Но так как вы назвали аргумент функции array (массив), то что бы вы не передали ей (в данном примере это 42), будет названо массивом внутри функции. На самом деле ошибка говорит о том, что 42.reduce — это не функция. Не лучше ли сделать вывод ошибки в виде:

ОшибкаТипа: 42 - это не массив, чувак. 

Проблемы 1 и 2 описывают стандартные исключения, которые легко предусмотреть. Но бывают и менее очевидные исключения, с которыми надо быть внимательнее. Например, что произойдёт, если в массиве будут отрицательные числа?

sumOddValues([1, 2, 3, 4, 5, -13]) // => still 9

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

“Это не баг. Это задуманный функционал” — удобная отмазка тех, кто не пишет тестов.

Проблема 3

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

sumOddValues([2, 1, 3, 4, 5]) // => 11

В данном примере 2 попадёт в сумму, хотя не должна. Это произойдёт потому, что в функцию reduce не передано initialValue, и поэтому в качестве исходного значения будет взят первый элемент массива. Поэтому важно написать тест и для такого случая. Если такого нет, то это ещё один признак кода новичка.

16) Одержимость производительностью

“Преждевременная оптимизация – это корень всех зол в программировании (или почти всех)”. Дональд Кнут, 1974

Хотя программирование существенно изменилось со времен Дональда Кнута, его совет актуален и в наши дни.

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

Разумеется, есть очевидные правила оптимизации, которые всегда надо держать в уме при написании кода. Например, в Node.js нельзя заполнять цикл событий и блокировать стек вызовов.

В погоне за вымышленной производительностью вы можете наделать реальные баги в самых неожиданных местах.

19) Непонимание, что проблемы с кодом вызывают проблемы с данными

Один из важнейших аспектов программирования — это управление данными. Программа – это интерфейс для добавления, редактирования и удаления записей.

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

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

Как защитить себя от такого? Можно использовать несколько уровней валидации: на фронтенде, бекенде, при передаче и в базе данных (БД). Как минимум, используйте встроенные ограничения в БД.

Хорошо знайте все типы ограничений в БД и используйте их все при создании новых столбцов и таблиц.

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

CHECK проверяет произвольное выражение, например, для процентов нужно проверять вхождение в интервал от 0 до 100.

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

FOREIGN KEY говорит о том, что величины этого столбца содержатся в другой таблице.

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

От переводчика

Иногда бывает трудно объяснить простыми словами казалось бы банальные вещи: зачем использовать гит, в чем фишка инкапсуляции, зачем писать тесты, как планировать свой код, рефакторить чужой и т.д. Мне показалось, что в этой статье компактно собраны важные «гуманитарные» аспекты программирования. Что-то вроде морального кодекса, ориентира и мотиватора в принятии решений, связанных с написанием кода.

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

3) Недооценивание важности качества кода

Если при написании кода вы можете сосредоточиться только на одной вещи, то это должна быть читабельность. Непонятный нечитабельный код это не просто мусор, а мусор, не подлежащий переработке.

Смотрите на программу как на составные части, общающиеся посредством кода. Плохой код — это плохая коммуникация.

“Пишите свой код так, будто его будет сопровождать агрессивный психопат, знающий, где вы живете”. (Джон Вудс)

Важны даже “мелочи”. Если вы бессистемно используете заглавные буквы и отступы, то у вас нужно отобрать лицензию программиста.

tHIS is
  WAY MORE important
than
         you think

Не используйте длинные строки. Строку длиннее 80 символов очень трудно читать. Используйте специальные инструменты для приведения кода в порядок (ESLint, Prettier для js).

Следите за количеством строк в функциях и файлах. Разделяйте код на мелкие части, понятные и тестируемые. Функция больше 10 строк – слишком длинная.

Не используйте двойное отрицание. Не не не делайте так. Это очень не не плохо.

Давайте переменным осмысленные, информативные, однозначные названия. Не используйте короткие, общие, или опирающиеся на тип, названия.

“В компьютерных науках есть только две по настоящему сложные вещи: инвалидация кэша и именование переменных”. (Фил Карлтон)

Используйте константы с содержательным названием для хранения примитивов. Если вам где-то нужно использовать число 12, сделайте сначала так:

const monthsInYear = 12; 

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

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

“Измерять программирование строками кода, это то же самое, что измерять авиастроительство тоннажем произведенных самолетов”. (Билл Гейтс)

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

Программист и ошибки — актуально во все времена

Чтобы максимально раскрыть смысл фразы «актуально во все времена«, в качестве иллюстрирующих примеров будут приведены сведения времён старой доброй DOS 🙂, поэтому материал рекомендуется к прочтению любителям ностальгии

Какие же бывают типы ошибок?

Тип №1. Ошибки в программном комплексе, допущенные при разработке и не обнаруженные при его тестировании

• В «Справочнике Microsoft Works» и интерактивной помощи пакета интегрированной обработки информации Works 2.0 функция ЕСЛИ описана как
ЕСЛИ (Условие, ЗначениеЛожь, ЗначениеИстина)
Однако в действительности работа данной функции должна иметь следующий вид:
ЕСЛИ (Условие, ЗначениеИстина, ЗначениеЛожь)

В «Руководстве пользователя Microsoft Works для Windows» пакета Works 3.0 эта ошибка исправлена 🙂

• Потеря связи с космической станцией «Фобос-1» (СССР) произошла из-за ошибочной команды, переданной с Земли на бортовой компьютер.

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

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

• Одна из первых компьютерных систем противовоздушной обороны США (60-е годы) в первое же дежурство подняла тревогу, приняв восходящую из-за горизонта Луну за вражескую ракету, поскольку этот «объект» приближался к территории США и не подавал сигналов, что он «свой» 🙂

Тип №2. Ошибки, возникающие при вводе в компьютер неверных данных

Весьма популярные ошибки, предотвращение которых известно под названием «защита от дурака»

• В 1983 году произошло наводнение в юго-западной части США. Причина заключалась в том, что в компьютер были введены неверные данные о погоде, в результате чего он дал ошибочный сигнал шлюзам, перекрывающим реку Колорадо.

• Ещё один печальный пример: в восьмидесятые годы прошлого века в Антарктиде разбился самолёт с туристами на борту, поскольку в управляющую полётом систему были заложены неверные координаты аэропорта взлёта и система ошибочно рассчитала высоту полёта над горами

Тип 3. Компьютерные вирусы, «вмешивающиеся» в работу компьютера и выполняемую им программу.

• Летом 1988 года в Мичиганском госпитале компьютерный вирус инфицировал три компьютера, которые обрабатывали информацию о пациентах. Вирус перемешал фамилии пациентов в базе данных. В результате данного «вмешательства» диагностические сведения одних пациентов оказались приписанными другим пациентам.

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

Тут, в принципе, всё обстоит точно так же, как и 20 лет назад: в процессе эксплуатации компьютерной системы возможно физическое повреждение накопителя, выход из строя блока питания, отключение электроэнергии, колебание напряжения в электрической сети и др. Результатом такого рода неисправностей может быть полная потеря информации, хранящейся на жёстком диске, частичная или полная потеря информации в файлах баз данных, нарушение работы систем, управляемых компьютером и многое другое. Для предотвращения ошибок данного типа используют системы, в которых одновременно работают несколько компьютеров, дублирующих друг друга, в компьютеры устанавливают два и более параллельно работающих накопителя (вспоминаем RAID-массивы), аппаратуру подключают к источникам бесперебойного питания, которые обеспечивают его работу при отключении электроэнергии или колебаниях напряжения электрической сети и т.д. и т.п.

Тип №5. Выход из строя или сбои в работе измерительных приборов и датчиков, используемых при управлении какими-либо техническими системами и технологическими процессами

• В июле 1985 года произошло преждевременное отключение компьютера одного из основных двигателей американского космического корабля «Челленджер» (Шаттл), едва не закончившееся катастрофой. Положение спас командир корабля, сумевший на двух работающих основных двигателях и двух менее мощных двигателях для маневрирования вывести «Челленджер» на орбиту. Причина же заключалась в том, что один из трёх бортовых компьютеров, управляющих двигателями (на каждый двигатель по компьютеру), был «обманут» вышедшим из строя датчиком, измеряющим температуру газа в двигателе. Для устранения подобных неполадок в будущем на следующих космических кораблях серии Шаттл были установлены датчики изменённой конструкции.

• При запуске французской ракеты нового поколения «Ариан-5» примерно на 37-й секунде полёта компьютер, находившийся на борту ракеты, получил от датчиков системы управления неверную информацию о пространственной ориентации ракеты. Исходя из этой информации, компьютер начал корректировать траекторию полёта для того, чтобы компенсировать не существующую на самом деле погрешность. Ракета стала отклоняться от курса, что привело к возрастанию нагрузок на её корпус. В результате чрезмерных нагрузок верхняя часть ракеты отвалилась, и по команде с земли ракета была взорвана.

Тип 6. «Злая воля человека», носителем которой чаще всего выступает либо программист, либо оператор

Программист, создавая программу, может специально внести в неё ошибку 🙂. Другим вариантом проявления «злой воли программиста» является включение в программу «логической бомбы», срабатывающей, например, после определённого числа запусков программы, определённых значениях входных данных и др. Оператор, обслуживающий компьютер, может сознательно ввести в компьютер неверные данные, которые и будут обработаны компьютером, выдавая неверные выходные данные в соответствии с принципом «мусор на входе – мусор на выходе».

• Сборочный конвейер волжского автомобильного завода в городе Тольятти работает под управлением АСУ, которая обеспечивает своевременное поступление деталей на конвейер со складов и из цехов вспомогательных производств. Для выполнения этой задачи информационно-управляющая система хранит информацию о тысячах узлов и деталей, из которых собирается автомобиль, о запасах деталей на складах, об их движении по транспортным линиям и т. д. На основе этой информации АСУ самостоятельно управляет автоматизированными складами, транспортными конвейерами, а также рядом других устройств.
Программист, разрабатывавший программное обеспечение для управления главным конвейером Волжского автозавода, сознательно внёс в программу «логическую бомбу» в знак протеста против низкой зарплаты. Через некоторое время эта «логическая бомба» сработала, и главный конвейер остановился на несколько дней. Ущерб от остановки составил 1 миллион рублей (в ценах 80-х годов), этот ущерб был несопоставим с зарплатой всех программистов ВАЗа, вместе взятых, а программист был дисквалифицирован и переведён в рабочие.

Подводим итоги

Анализ приведённых типов ошибок показывает, что основными задачами, стоящими перед разработчиками программного обеспечения в плане повышения его надёжности, является:

• устранение ошибок, допущенных при разработке программного обеспечения (1-й тип ошибок);
• проектирование программного обеспечения с учётом человеческого фактора, то есть таким образом, чтобы оно было защищено от «дурака» (2-й тип ошибок). При этом «свалять дурака» могут не только пользователи, работающие за компьютером, но и приборы и датчики, от которых компьютер принимает информацию при управлении техническими или иными системами (5-й тип ошибок);
• использование известных мер безопасности для снижения вероятности переноса компьютерных вирусов (3-й тип ошибок) с программами, передаваемыми в эксплуатацию (в практике распространения программ известны случаи, когда разработчики этих программ записывают дистрибутивы на заражённых вирусами компьютерах).

Таким образом, программный продукт в обязательном порядке должен проходить тщательное тестирование и отладку (выявление ошибок 1-го и 2-го типов). Выявление возможных ошибок 5-го типа производится с помощью имитации отказа приборов и датчиков на прошедших тестирование программных комплексах.

Надеюсь, данный материал окажется полезным. Желаю всем делать поменьше ошибок, ведь это особенно актуально в нынешние кризисные времена :^)

PS: сведения предоставляются по данным из этих источников, множество важных дополнений и опровержений представлены ниже в комментариях, особенно от хабраюзера scoon. Однако оригинальный текст не изменяю

14) Не подвергать сомнению существующий код

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

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

Новичкам можно посоветовать такое правило: любой недокументированный код, который вы не понимаете — возможно, плохой. Изучайте его. Спрашивайте о нём. Пользуйтесь командой git blame, выдающей автора каждой строки кода.

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

21) Неправильное отношение к инспекции кода (code review)

Один из признаков новичков, это восприятие инспекций кода как критицизма. Они не любят их, не ценят и даже боятся.

Это в корне неправильное отношение надо как можно быстрее изменить. Смотрите на каждую инспекцию кода как на ценную возможность обучения. Любите и цените их. Учитесь посредством них. И благодарите делающих замечания.

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

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

24) Неправильное отношение к ошибкам

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

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

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

Длинный метод

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

async function makeAnOrder() {

  const form = document.querySelector('form#basket');

  const basket = new FormData(form);

  if (!basket.get('name')) {

      throw new Error('Вы не указали имя');

  }

  if (!basket.get('address')) {

      throw new Error('Вы не указали адрес доставки');

  }

  const user = await fetch('/api/user').then(results => results.json())

  basket.set('user_id', user.id);

  basket.set('discount', user.discount);

  fetch('/api/order', { method: 'POST', body: basket })

      .then(results => results.json())

      .then(() => {

          alert('Заказ удачно отправлен')

      })

}

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

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

async function makeAnOrder() {

  const basket = getBasket();

  vaildateBasket(basket);

  await applyDiscount(basket);

  createOrder(basket).then(() => {

    alert('Заказ удачно отправлен')

  })

}

function getBasket() {

  const form = document.querySelector('form#basket');

  return new FormData(form);

}

function vaildateBasket(basket) {

  if (!basket.get('name')) {

    throw new Error('Вы не указали имя');

  }

  if (!basket.get('address')) {

    throw new Error('Вы не указали адрес доставки');

  }

}

function createOrder(basket) {

  fetch('/api/order', { method: 'POST', body: basket })

    .then(results => results.json())

}

async function applyDiscount() {

  const user = await fetch('/api/user').then(results => results.json())

  basket.set('user_id', user.id);

  basket.set('discount', user.discount);

}

Объект бога

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

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

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

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

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

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

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

let button = document.getElementById("button");

let anotherButton = document.getElementById("anotherButton");

button.onclick = function() {

    modal.style.display = "block";

    modal.style.height = "100%";

    modal.style.width = "50%";

    modal.style.position = "fixed";

}

anotherButton.onclick = function() {

    modal.style.display = "block";

    modal.style.height = "100%";

    modal.style.width = "50%";

    modal.style.position = "fixed";

}

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

function showModal() {

  modal.style.display = "block";

  modal.style.display = "block";

  modal.style.height = "100%";

  modal.style.width = "50%";

  modal.style.position = "fixed";

}

button.onclick = showModal

anotherButton.onclick = showModal

8) Планирование неизвестного

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

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

“Рост ради роста — это идеология раковой клетки”. (Эдвард Эбби)

4) Хвататься за первое решение

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

Ваша задача как профессионального программиста, найти не первое попавшееся решение, а самое простое. То есть то, которое наиболее просто реализуется, эффективно работает и легко поддерживается.

“Есть два пути написания программы: 1) сделать её настолько простой, что в ней, очевидно, не будет недостатков; 2) сделать её настолько сложной, что в ней никакие недостатки не будут очевидными”. (Тони Хоар)