Как улучшить вкус кода

Архитектура спецификация кода

Как улучшить вкус кода

Слова семьи можно обсудить в комментариях

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

что такое писать код

Я думаю, что написание кода делится на две части:

  • Структурный дизайн, включая модульное разделение, взаимодействие модулей, дизайн интерфейса
  • Реализация функций, включающая специфические особенности языка и стиль кода

структурный дизайн

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

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

  • Всегда размышляйте над структурой кода в процессе разработки.
  • имя серьезно

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

  • В начале он был разделен на два модуля, и было написано, что один из модулей оказался очень большим, так что посмотрим, сможем ли мы продолжить его делить.
  • В начале он был разделен на четыре или пять модулей. Позже я написал и обнаружил, что два модуля очень часто взаимодействовали. Они должны работать вместе для достижения полной функции. Затем соединили их (высокая связность)
  • В процессе итерации выяснилось, что хоть два модуля и независимы друг от друга, но логика взаимодействия очень дохлая, а зависимости очень прямые, если модифицируется один, то и другой тоже надо модифицировать, то модифицировать их зависимости и взаимодействия, и старайтесь избегать друг друга.
  • В итеративном процессе обнаруживается, что определенную часть двух модулей можно разделить, а затем извлечь ее (СУХОЙ)
  • В ходе итеративного процесса обнаруживается, что часть кода в модуле часто изменяется, затем извлеките эту часть отдельно (инкапсулируйте изменения)
  • . . .

Конечно, список таких ситуаций бесконечен, на самом деле команда может установить какие-то жесткие показатели, чтобы облегчить деление на модули, например, в файле максимум 300 строк, в функции максимум 70 строк и т.д. , и поместите их в правила Lint. У нас есть много условных "скрытых правил", которые на самом деле имеют за собой логику. Например, упомянутые в прошлом режимы MVC и MVVM являются основными отличиями. Основное отличие заключается не в разделении модулей, а во взаимодействии между модулями. С точки зрения разделения, все они работают на разделение пользовательского интерфейса и логики, почему? Поскольку пользовательский интерфейс дешев, пользовательский интерфейс будет пересматриваться дизайнерами каждые три-пять, но логика и данные будут относительно стабильными, поэтому их разделение потребует относительно небольших изменений в итерации пользовательского интерфейса. Тогда почему перед Реагировать/Вью
Эти популярные в последние годы фреймворки также выступают за так называемые компоненты (Component),по-видимомуВы хотите совместить пользовательский интерфейс и логику? На самом деле это не так. Компонент представляет собой мелкозернистый модуль. Он относительно независим и имеет высокую связность. «Логика» в компоненте должна быть больше логикой взаимодействия, связанной с пользовательским интерфейсом, а не относительно низкоуровневой логикой. Нам лучше извлечь относительно стабильную логику и поместить ее на более низкий уровень.

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

Реализация функции

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

  • Знать свой язык программирования
  • Улучшите свои логические способности
  • Обратите внимание на стиль кода

Существует известное мнение, что идеи в программировании важнее всего, а языки — это всего лишь инструменты. На первый взгляд языки программирования могут показаться незначительными. Если это разовая сделка, написать кусок кода для реализации функции и оставить его после написания, это не имеет значения, то, конечно, язык не важен. Я считаю, что большинство программистов могут быстро начать работу с новым языком, потому что для реализации функции могут потребоваться только некоторые общие основные функции, для языков на основе C знать функцию/оператор ветвления/оператор цикла/строку/массив/разброс Использование этих вещей достаточно для развития повседневных нужд, и эти фичи честно говоря на C
Языки совсем разные. Но если вы хотите писать хороший код, вы должны работать над освоением языка. Некоторые функции вы пишете кучу дерьмового кода, могут быть реализованы так себе, но с определенной фичей, несколько строчек короткого и лаконичного кода можно решить. Я отвергаю точку зрения, что для того, чтобы всем в команде было понятно, рекомендуется использовать только базовые возможности языка, а некоторые расширенные или менее часто используемые возможности не допускаются. В качестве крайнего примера некоторые люди считают, что Если else более удобочитаемо, чем тернарные выражения, рекомендуется использовать только if else. На мой взгляд, такая «читабельность» подходит только посредственным кодерам. У некоторых языковых функций есть плюсы и минусы, а у некоторых только минусы (JS
Это очень распространено в ), постарайтесь не использовать его или сделайте компромисс в соответствии с реальной сценой. Критериями, которые мы выбираем, являются «сценарии», а не люди. Что такое подходящая сцена, или возьмем в качестве примера тернарное выражение:

const data1 = a > b ? 100 : 200;
const data2 = a > b ? 300 : 400;

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

let data1 = 200;
let data2 = 400;
if (a > b) {
    data1 = 100;
    data2 = 300;
}

Или вычислите условие a > b заранее, чтобы избежать двойного вычисления (эта оптимизация не для производительности, потому что компиляторы некоторых языков будут выполнять аналогичные оптимизации во время компиляции, в основном для удобства чтения):

const condition = a > b;
const data1 = condition ? 100 : 200;
const data2 = condition ? 300 : 400;

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

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

// if (key === 'x') return 'xxx';
// if (key === 'y') return 'yyy';
// if (key === 'z') return func;

const xxxMap = {
    x: 'xxx',
    y: 'yyy',
    z: func
};
return xxxMap(key);

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

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

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

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

Категории