[Перевод] Распространенные ошибки, которые я совершал, когда только начинал программировать

• Оригинальный адрес:The Mistakes I Made As a Beginner Programmer
• Оригинальный автор:Samer Buna
• Перевод с:Программа перевода самородков
• Постоянная ссылка на эту статью:GitHub.com/rare earth/gold-no…
• Переводчик:kezhenxu94
• Корректор:DAA233 dandyxu

Научитесь распознавать ошибки и заведите привычку избегать их

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

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

Ошибки ниже не имеют определенного порядка.

1) Пишите код без плана

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

Существует рабочий процесс для написания качественного кода:считать.исследовательская работа.план.кодирование.проверять.Исправлять. 很遗憾，这个工作流没有一个很好的（英文）首字母缩写来帮助记忆。你需要养成好的习惯来履行工作流中的各个阶段，ничего меньше.

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

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

Когда вы злитесь, если хотите поговорить, начните со счета от 1 до 10. Если сильно злишься, считай до 100.

-Томас Джеферсон

Примените это предложение:

При просмотре кода, если вы хотите провести рефакторинг кода, начните со счета от 1 до 10. Если тестового кода нет, сосчитайте до 100.

— Самер Буна

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

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

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

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

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

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

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

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

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

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

Никогда не недооценивайте важность качества кода. Думайте о написании кода как о способе сообщить о реализации. Ваша основная задача как программиста — четко сообщить о реализации вашего текущего решения.

Одна из моих любимых цитат о программировании:

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

- Джон Вудс

Джон, какое мудрое предложение!

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

tHIS is
  WAY MORE important

than
         you think

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

Многие из этих простых вопросов можно решитьlintingиformattingИнструменты Ремонт. В JavaScript есть два отличных инструмента для работы без проблем:ESLintиPrettier. Сделайте себе одолжение и используйте их.

Вот еще несколько мифов, связанных с качеством кода:

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

• Используйте двойное отрицание. Пожалуйста, пожалуйста, не делайте этого.

Также нет ничего плохого в использовании двойного отрицания.

• Используйте короткий и универсальный или на основе типа имени переменной. Дайте вашу переменную описательную и без неоднозначного имени.

В компьютерных науках есть только две сложные вещи: очистка кешей и присвоение имен вещам.

— Фил Карлтон

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

const answerToLifeTheUniverseAndEverything = 42;

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

• Я думаю, что чем длиннее код, тем лучше. Однако в большинстве случаев чем короче код, тем лучше. Метод написания длинного кода используется только в том случае, если код более удобочитаем. Например, не встраивайте много тернарных операторов (?:), чтобы сделать код короче. Конечно, не делайте код намеренно излишне подробным. Удаление ненужного кода — лучшее, что вы можете сделать в любом проекте.

Использование строк кода для измерения прогресса программирования похоже на использование веса для измерения прогресса строительства самолета.

- Билл Гейтс

• Чрезмерное использование условной логики. Большинство ситуаций, которые, по вашему мнению, требуют условной логики, могут быть реализованы без условной логики. Рассмотрите все альтернативы и выберите только одну на основе удобочитаемости. Не оптимизируйте производительность, если вы уже не можете измерить производительность. Связанный: ИзбегайтеYoda conditionsи условные задания.

4) Используйте первоначальный план

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

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

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

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

- КАР Хоар

5) Не сдавайся

Еще одна ошибка, которую я часто принимаю в том, что я придерживаюсь моего первоначального решения, хотя я подтвердил, что это, вероятно, не самое простое решение. Это, наверное, что говорит психология »Не сдаваться«Мышление. Это хорошее состояние ума в большинстве видов деятельности, но не в программировании. На самом деле, когда дело доходит до программирования, правильное состояние ума должно бытьПотерпеть неудачу как можно скорее и потерпеть неудачу много.

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

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

6) Не гуглите

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

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

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

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

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

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

— Брет Виктор

7) Нет пакета

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

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

логические единицы и состояния понятий должны иметь своисвоего рода.我说的类是指一个蓝图模版，这可能确实是一个своего родапредмет, возможно,функцияобъект, который вы также можете представить какмодульилиСумка.

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

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

Добавляя метод в класс или добавляя дополнительные обязанности к методу, подумайте об этом и спросите свою интуицию. Вам нужно не торопиться, не пропускайте и не думайте: «ЯРефакторинг позже«Сделайте это прямо с самого начала.

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

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

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

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

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

Пишите как можно меньше кода для сценария, который вы сейчас реализуете. Конечно, обрабатывайте крайние случаи, но не добавляйтеГраничная функция.

Рост ради роста — это разум раковой клетки.

— Эдвард Эбби

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

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

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

Использование неправильной структуры данных — это огромный и очевидный рекламный щит, говорящий «это код для новичков».

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

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

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

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

В JavaScript наиболее часто используемой структурой списка является массив, а наиболее часто используемой структурой карты является объект (в современном JavaScript также есть структуры карты).

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

- стек не используется

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

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

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

10) Сделать существующий код хуже

Предположим, вам дан такой беспорядок в доме:

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

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

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

Вот несколько неправильных приемов, часто делающих код хуже (неполный список), чем раньше:

• скопировать код. Если вы копируете/вставляете фрагмент кода и меняете только одну строку, вы просто создаете дублирующийся код и делаете его еще хуже. В приведенном выше примере с грязной комнатой вы получили стул с более низким основанием вместо стула с регулируемой высотой. Всегда помните об абстрактных концепциях и используйте их всякий раз, когда можете.
• файл конфигурации не используется. Если вы хотите использовать значение, которое может отличаться в других средах или в другое время, это значение следует поместить в файл конфигурации. Если вам нужно использовать значение в разных местах вашего кода, это значение также должно быть помещено в файл конфигурации. Когда вы хотите ввести новое значение в свой код, просто спросите себя: следует ли помещать это значение в файл конфигурации? Ответ, скорее всего, «должен».
• Используйте ненужные условные операторы и временные переменные. КаждыйifОператор — это логическая ветвь, которую необходимо проверить дважды. Если вы можете избежать условных выражений, не жертвуя читабельностью, вы должны это сделать. Главный вопрос здесь заключается в том, расширять ли одну функцию логикой ветвления или вводить другую функцию. каждый раз, когда вы чувствуете необходимостьifоператора или новую функциональную переменную, вы должны спросить себя: меняю ли я код на правильном уровне, или я должен думать об этом на более высоком уровне.

о ненужномifзаявление, посмотрите на следующий код:

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

ВышеisOddЕсть несколько проблем с функцией, но можете ли вы найти самую очевидную?

Он использовал ненужнуюifзаявление, следующий эквивалентный способ написания:

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

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 even
      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);
};

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

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

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

// 创建一个变量并初始化为 0
let sum = 0;

// 遍历数组
array.forEach(
  // 对于数组中的每一个数字
  (number) => {
    // 把当前数字加到变量 sum 中
    sum += number;
  }
);

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

12) Тесты не пишутся

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

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

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

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

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

13) Я чувствую, что код может работать правильно, когда он работает

Взгляните на эту функцию, которая реализует функциональность «добавить все нечетные числа».sumOddValues,Любые вопросы?

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
);

Тестовое утверждение пройдено, жизнь прекрасна, правда, правда?

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

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

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.reduceОпределенно функция!

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

Вы видели воочию, насколько загадочными бывают ошибки, не так ли? Возможно, более полезная ошибка заключается в следующем:

TypeError: 42 is not an array, dude. // （译注：42 可不是数组啊，我的大胸弟。）

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

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

Эм-м-м,-13Тоже нечетное число. Это ваше ожидаемое поведение? Разве не должно быть выброшено исключение? Не следует ли суммировать и отрицательные числа? Или он просто игнорирует отрицательные числа, как сейчас? Теперь вы можете понять, что имя этой функции должно было называтьсяsumPositiveOddNumbers(Суммирует положительные нечетные числа).

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

Это не баг, это фича.

— Тот, кто забыл написать тестовый код

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

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

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

Ответ прост,reduceПринимает другой параметр в качестве начального значения сумматора. Если этот параметр не передан (как в коде выше),reduceФункция будет использовать коллекциюПервыйзначение как начальное значение сумматора. Поэтому суммируется и первое четное число в приведенном выше примере.

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

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

14) Никаких сомнений в существующем коде

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

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

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

Как новичок, вы всегда должны предполагать, что код, который вы не понимаете и который не документирован, вероятно, является плохим кодом. вопрос, вопрос, использованиеgit blameУзнайте виновник!

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

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

Я думаю, что «лучшая практика» на самом деле вредна, она подразумевает, что вам не нужно копаться в этом, вот что всегдаоптимальныйПрактикуйтесь, не спрашивайте!

Нет такой вещи, как лучшая практика, может быть, естьВ настоящее время,для этого языка,В ПОРЯДКЕупражняться.

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

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

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

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

Преждевременная оптимизация — корень всех зол

- Дональд Кнут (1974)

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

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

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

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

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

Не тратьте время на оптимизацию неизмеримых проблем с производительностью.

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

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

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

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

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

Молоток — отличный инструмент для забивания гвоздей в стены, но это худший инструмент для забивания шурупов. Не используйте этот молоток только потому, что вам нравится закручивать шурупы. Не используйте его для завинчивания только потому, что это популярный молоток с пользовательским рейтингом 5,0 на Amazon.

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

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

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

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

19) Непонимание проблем с кодом может привести к проблемам с данными.

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

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

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

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

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

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

• NOT NULLОграничение not-null означает, что нулевое значение NULL не может быть сохранено в столбце. Если ваше приложение предполагает, что значение этого столбца существует, оно должно определить этот столбец как ненулевой в базе данных.
• UNIQUEУникальное ограничение означает, что все значения в этом столбце не могут дублироваться во всей таблице данных. Например, это отличный пример использования полей имени пользователя и электронной почты в таблице пользователей.
• CHECKОграничение — это пользовательское выражение, которое должно быть истинным, чтобы данные были приняты базой данных. Например, если у вас есть обычный процентный столбец со значениями от 0 до 100, вы можете использоватьCHECKограничения, обеспечивающие это.
• PRIMARY KEYОграничение первичного ключа означает, что значение этого столбца должно быть ненулевым и уникальным. Возможно, вы уже используете его. Каждая таблица в базе данных должна иметь первичный ключ для уникальной идентификации записи.
• FOREIGN KEYОграничение внешнего ключа означает, что значение этого столбца должно совпадать со значением столбца (обычно первичного ключа) другой таблицы.

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

20) повторить колесо

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

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

Иногда бывает сложно выбрать желаемое колесо среди множества доступных брендов. Исследуйте и используйте перед покупкой! Самое классное в программных «колесах» то, что большинство колес свободны и открыты, и вы можете видеть их внутреннюю конструкцию. О качестве программных колес легко судить по качеству их внутренней конструкции. Используйте колеса с открытым исходным кодом, если это возможно. Пакеты с открытым исходным кодом можно легко отлаживать и исправлять. Его также можно легко заменить. Кроме того, вы можете поддержать их, не выходя из дома.

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

21) Ошибка отношения к обзору кода

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

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

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

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

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

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

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

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

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

Контроль версий также связан с возможностью обнаружения. Если вы видите функцию и начинаете сомневаться в ее необходимости и дизайне, вы можете найти запись фиксации, которая представила функцию, и увидеть контекст функции. Коммиты могут даже помочь вам определить, какой код вызывает ошибки. Git даже предоставляет инструменты для бинарного поиска среди коммитов, чтобы помочь найти коммиты, вызывающие ошибки (bisectЗаказ).

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

В моем словаре, тем меньше вы знаете о функциональности Git, тем больше вы чувствуете себя новичком.

23) Чрезмерное использование общего состояния

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

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

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

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

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

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

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

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

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

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

25) Без перерывов

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

Это действительно длинная статья. Вы должны сделать перерыв.

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

---

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