Это 3-й день моего участия в ноябрьском испытании обновлений.Подробности о событии:Вызов последнего обновления 2021 г..

Всем привет, я Чжан Сансуй🤣, фронтенд правовой системы⚖️. Люблю делиться🖋️, люблю Bingbing🧊🧊.
Добро пожаловать в мои маленькие друзья плюс микро письмо: Maomaoibingbing, потяните вас в группу, чтобы обсудить, и мы с нетерпением ждем расти вместе 🥂.

предисловие

Я считаю, что спецификации разработки проекта знакомы всем вам, и хорошие спецификации разработки могут улучшить работу разработчика.комфорти кодПоддерживаемая степень.本文将会以一个ReactС точки зрения проекта передних разработчиков, организуйте информацию оспецификация разработкито, что ты хочешь.

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

Во-первых, происхождение и предназначение

1.1 Происхождение спецификации разработки

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

Миссия и будущее Развитие 1.2 Спецификация

Миссия разработки норм заключается в следующем:

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

В сегодняшней все более совершенной экосистеме кода код, которым занимаются разработчики,

• Открытый исходный код
• эффективный
• Простота обслуживания
• Масштабируемость
• нормализовать

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

Во-вторых, спецификации разработки начального проекта.

1. Нормативные принципы

Практика - единственный стандарт проверки правды - "Guangming Daily"

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

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

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

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

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

2. Разделение, инкапсуляция и повторное использование

2.1 Отношения между тремя

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

2.2 Развязка

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

/* 在 CSS 中解耦的应用 */

/* 某容器 */
.box {
    /* ... */
    background-color: greenyellow;
}

/* 控制背景色为粉色 */
.background-hotpink {
    background-color: hotpink;
}

/* 控制背景色为蓝色 */
.background-sklyblue {
    background-color: skyblue;
}

<div class="box"></div>
<div class="box background-hotpink"></div>
<div class="box background-sklyblue"></div>

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

// JavaScript 中的解耦

// 解耦前
const myFun = () => {
    // 完成 A 任务代码 ...
    // 完成 B 任务代码 ...
};

// 解耦后 拆分成完成两个不同任务的方法,单独维护,代码变多了,可维护性增强了
const funA = () => {
    // 完成 A 任务代码 ...
};
const funB = () => {
    // 完成 B 任务代码 ...
};
const myFunNew = () => {
    funA();
    funB();
};

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

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

2.3 Упаковка

Целью инкапсуляции является облегчение повторного использования и обслуживания. Давайте посмотрим на простой фрагмент кода:

// 给一个按钮绑定点击事件

// 获取元素方法
document.getElementById('myButton').onclick = () => {
    console.log('点击了~');
};

// 封装成方法后,在元素上增加 onclick 即可
const handleClickMyButton = () => {
    console.log('点击了~');
};

2.4 Мультиплексирование

Как следует из названия, это многократное использование упакованного кода, что позволяет сократить затраты на разработку. Проще говоря, в проекте может быть несколько инкапсулированных методов, модулей и компонентов, а в целом может быть несколько методов для решения класса задач.插件库, который состоит из нескольких компонентовUIБиблиотеки, набор решений, рожденных для решения проблем — фреймворки — это воплощение повторного использования. (и конечно же дух open source)

3. Публичный модуль

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

├── ...
└── src
    ├── assets
    ├── components
    ├── hooks
    ├── services
    ├── styles
    └── utils

• assets Глобальные статические ресурсы, обычно хранящие файлы, такие как изображения и шрифты.
• компоненты — это глобальный общедоступный компонент, в котором хранятся компоненты пользовательского интерфейса, которые будут использоваться несколько раз на нескольких страницах/компонентах.
• hooks Глобальный хук, в котором хранятся многоразовые хуки.
• услуги глобального общественного запроса.
• СТИЛИ глобальный публичный стиль.
• использует глобальный общедоступный метод.

4. Компонентизация пользовательского интерфейса

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

// src/pages/Home/index.tsx
// 父组件
import { CSSProperties } from 'react';
import Child from './components/Child'; // 子组件

const Home: React.FC = () => {
  const parentStyle: CSSProperties = {
    margin: '50px',
    padding: '50px',
    fontSize: '24px',
    backgroundColor: 'cornflowerblue',
  };
  return (
    <div style={parentStyle}>
      我是父组件
      <Child />
    </div>
  );
};

export default Home;

// src/pages/Home/components/Child/index.tsx
// 子组件
import { CSSProperties } from 'react';

const Child: React.FC = () => {
  const childtStyle: CSSProperties = {
    marginTop: '30px',
    padding: '50px',
    backgroundColor: 'skyblue',
  };
  return <div style={childtStyle}>我是子组件</div>;
};

export default Child;

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

• Научу строить компонентную систему фронтенд команды от 0 до 1 (обязательно для продвинутых и продвинутых)
• Каждый передний конец стоит иметь собственную компонентную библиотеку, как и арбуз каждое лето.

5. Нормализация имен

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

• Значительное
• Сначала используйте английскую комбинацию слов
• умеренная длина
• регулярность

/* ============ 这些命名不太好 ============ */

// 无意义
// 缺点:容易混淆,维护困难
const a1, b1, c1;

// 拼音
// 目前不流行用拼音,大多数人觉得会觉得不习惯
const biaoti, tupian, julao;

// 过于简单的单词
// 缺点:容易重复,可能一个文件中会用的很多相似用途的名称(例如名称总不能都叫name吧)
const title, img, name;

// 没有使用驼峰命名
const pagetitle, routeparam, allstatus;

// 过于大众化的名称
const myFunction = () => {};

/* ============ 这些命名真不戳 ============ */

// 常见命名规则:前缀 + 名词
// 优点:有意义、长度适中、驼峰形式的单词组合
const isTitleShow;
const handleSendMsg = () => {};

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

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

• элегантное именование переменных

6. Разумное разделение каталогов и именование

6.1 Разделить каталог

6.1.1 Каталог модулей

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

└── ModuleA 某模块
    ├──components 存放当前模块子组件
        ├── Module1 子组件
        └── Module2
    ├── index.tsx 目录主文件通常命名为 index
    └── ...

6.1.2 Каталог статических ресурсов

Управление статическими ресурсами также очень важно. Статические ресурсы проекта обычно размещаются вsrc/assets, если не классифицировать, может выглядеть так:

└── assets
    └── images
        ├── xxx.png
        └── ... x100

Круто положить документы на время, найти крематорий документов. Для этого мы должны следоватьмодульРазделить на группы:

└── assets
    ├── fonts 存放字体文件
    └── images
        ├── common 存放公共文件
        ├── moduleA
            └── A模块所用到的文件目录命名和模块命名相同或有关联,如果该模块文件较多则可以继续拆分
        ├── moduleB
        └── ...

6.2 Именование каталогов и файлов

При именовании каталогов следует обратить внимание на следующие аспекты:

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

При именовании файлов следует обратить внимание на следующие аспекты:

• Главный файл для каждого модуля должен называться index.xxx , чтобы на него можно было ссылаться с помощью сокращения (например,/Moduleэквивалентно/Module/index.tsx)

7. HTML-связанный

Не только здесь обсуждают.htmlфайл, также включаетVueсерединаtemplateа такжеReactизjsx. На что нам нужно обратить внимание:

• Разумное использование новых строк
• Вложенные узлы должны иметь отступ
• добросовестное использованиеmetaЭтикетка
• дляhtmlнаписание этикеткиlangАтрибуты
• Используйте двойные кавычки для атрибутов в тегах
• Порядок написания атрибутов метки, важные располагаются первыми
• Старайтесь не использовать необычные теги и атрибуты тегов с плохой совместимостью.

// 省略非重点代码

// 某组件
// 此处传入参数过多,换行方便阅读
const ArticleItem = (
    {
        item = {},
        type = 'ARTICLE',
        isCurrentUser = false,
        isDel = false,
        titleStatus = false,
        division = false
    }
) => {
    // ...
};

export default () => {
    // 同样的,使用该组件的时候加换行让其显示更清晰
    return (
        <>
            <ArticleItem
                key={value?.id}
                item={value}
                type={value?.type}
                isCurrentUser={isCurrentUser}
                titleStatus
                division
            />
        </>
    );
};

оmetaЭтикетка, здесь предлагаютMDNПортал документов, пожалуйста, прочитайте сами:HTMLElement.lang

8. Связанный с JavaScript

8.1 Функциональная модульность

Чем сложнее построена страница, тем сложнееJavaScriptЧем сложнее, тем модульность обеспечивает практичное и эффективное решение этой проблемы снижения сложности программы. Он поддерживает импорт и экспорт упакованного кода по запросу, тем самым улучшая возможность повторного использования некоторого кода. Общие модульные характеристики:CommonJS,AMD,RequireJSЖдать.

Рекомендуемое чтение:

• Модули JavaScript
• Загрузка реализации модуля

8.2 Легко понять

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

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

• Тип 1: избыточный код
• Тип 2: плохой отступ
• Тип 3: переменные, падающие с неба
• Четвертый тип: лишняя операция
• Пятый стиль: головная боль
• Шестая форма: более трех уровней вложенности суждений
• Тип 7: Совершенно отличный от аннотационного описания способ (самая удушающая операция)

8.3 Использование синтаксического сахара и новых функций

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

/* ============ 箭头函数 ============ */
// before
var oldFunction = function () {
    var _this = this;
    // do something
};
var oldFunction2 = function () {
    return "hello world";
};

// after
const newFunction = () => {
    // do something
};
const newFunction2 = () => "hello world";

/* ============ 解构赋值 ============ */
// before
var person = {
    name: "王冰冰",
    sex: "female",
    job: {
        jobName: "compere",
    },
};
var name = person.name;
var sex = person.sex;
var jobName = person.job.jobName;

// after
const {
    name,
    sex,
    job: {
        jobName
    },
} = person;

/* ============ 模板字符串 ============ */
// before
var myStr = "world";
var helloWorld = "hello " + myStr + " !";

// after
const str = `hello ${myStr} !`;

/* ============ 对象属性简写 ============ */
// before
var a1, b1, c1;
var obj = {
    a1: a1,
    b1: b1,
    c: c1
};

// after
cosnt obj = {
    a1,
    b1,
    c1
};

Рекомендуемое чтение:

• 15 000 слов, описывающих все возможности ES6
• Вы можете использовать ES6, вот и все!

8.4 Выполнение обработки ошибок

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

• Разумно генерировать исключения для сообщений об ошибках
• Для кода, который может пойти не так, используйтеtry/catch
• имеют默认数据или占位UIЧтобы гарантировать, что страница не сбивается, когда возникает ошибка

Рекомендуемое чтение:

• Самое полное руководство по обработке ошибок JavaScript

8.5 Модульный тест

Чтобы обеспечить общую надежность кода, вы можете выполнить интерфейсное модульное тестирование перед отправкой кода в репозиторий. Конкретный рабочий процесс модульного тестирования здесь обсуждаться не будет, но он прилагается.JavaScriptтестовая средаJestПортал официальных документов:www.jestjs.cn/

Рекомендуемое чтение:

• Модульное тестирование React с помощью Jest
• Фреймворк для фронтенд-тестирования Jest

9. Связанный со стилем

9.1 Краткое изложение правил

В проекте мы обычно используемПрепроцессор CSSНапример:Sass,Less,Stylus, здесь сLessИллюстрируйте на примере. Обычно нам нужно обратить внимание на:

• единыйсоглашение об именовании
• добросовестное использованиевложенный синтаксис
• Разумное определениеобщедоступная переменная
• Не последний элемент, используйте меньше или не используйте селектор тегов
• стиль компонентакорреспонденция один на одинПринцип, один компонент соответствует одному файлу стиля
• В общедоступных компонентах или компонентах уровня страницы используйте как можно меньше простых для повторения коротких имен классов, таких как: box, title, info
• Вы можете определить имя класса, которое нелегко повторить в самом внешнем элементе компонента, освобождая имя класса в компоненте.Пространства имен

9.2 Правила именования

一个项目我们需要制定一个统一且合理的命名规则，例如采用短横线分割式命名或者下划线分割式命名。 Чтобыпеременные JavaScriptЧтобы различать, обычно не используют верблюжий регистр.

// 短横线 "-" 分割式命名
.hd-title {}

// 下划线 "_" 分割式命名
.banner_box {}

9.3 Разумное вложение

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

// 嵌套越深，维护起来越麻烦，尽可能减少嵌套。当然这还需要合理的 DOM 元素嵌套
.classname-a {
    .classname-b {
        .classname-c {
            .classname-d {
                // ...
            }
        }
    }
}

Используйте символы в вложенном&Вместо родительского элемента оптимизируйте код.

.btn {

    // ...
    &.active {
        color: #0094ff;
    }
}

9.4 Публичные переменные

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

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

// 以下仅为示例代码

/* ============ 布局 ============ */
// 间距-大
@space-large: 36px;

// 间距-中
@space-middle: 24px;

// 间距-小
@space-small: 12px;

/* ============ 配色 ============ */
// 主题色
@theme-color: #0094ff;

// 底色
@background-lightgray-color: #f9f9f9;

9.5 Глобальные файлы общественного стиля

// src/styles/index.less
// 全局公共样式

// ! 使用多行注释分割不同类型的样式代码，变量优先

// ! 这是一级分类
/* ======================== 公共变量 ======================== */

// ! 这是二级分类
/* ------------ 布局 ------------ */
// 版心宽度
@container-width: 1200px;

// 间距-大
@space-large: 36px;

// 间距-中
@space-middle: 24px;

// 间距-小
@space-small: 12px;

/* ------------ 配色 ------------ */
// 主题色
@theme-color: #0094ff;

// 底色
@background-lightgray-color: #f9f9f9;

// 标题
@title-color: #000c;

/* ======================== 公共类名 ======================== */
/* ------------ 布局 ------------ */
// 版心
.container {
    margin: 0 auto;
    width: @container-width;
    min-width: @container-width;
}

// ! 这是三级分类，同一分类下可能有不同公共类名/工具类名
// 外边距 margin
.mg-0-auto {
    margin: 0 auto !important;
}

.mg-b-16 {
    margin-bottom: 16px !important;
}

.mg-l-auto {
    margin-left: auto !important;
}

/* ------------ 文本 ------------ */
// 文字大小
.font-16 {
    font-size: 16px !important;
}

.font-24 {
    font-size: 24px !important;
}

// 文本对齐
.text-align-center {
    text-align: center !important;
}

// 单行文字超出隐藏
.text-ellipsis {
    white-space: nowrap;
    text-overflow: ellipsis;
    overflow: hidden;
}

// ! 自定义类名就是在很多页面组件中需要使用的公共类名，如无必要，尽量少用
/* ------------ 自定义 ------------ */
// 公共盒子
.common-box {
    background-color: #fff;
    // ...

    // 灰色背景色
    &.gray-bg {
        background-color: @background-lightgray-color;
    }

    // 盒子内一级标题
    .box-title {
        color: @title-color;
        font-weight: bold;
    }
}

10. Использование комментариев

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

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

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

Рекомендуемое чтение:

• Используйте аннотации элегантно

11. Спецификации отправки кода

Это относится к описанию отправки кода в репозиторий, т.е.git commit -m [message]серединаmessage--Описание. Неорганизованная информация описания усложнит отслеживание источника последующих проблем и распределение обязанностей. Из-за нехватки места здесь он не будет расширяться, друзьям рекомендуется прочитать соответствующие статьи о спецификациях представления кода:

• Изящно зафиксируйте сообщение Git Commit Message
• Введение в использование набора инструментов Cz — стандартные инструкции по коммитам Git

12. Плагины, связанные со спецификацией (VSCode)

12.1 Плагин форматирования кода

Beautify

Плагин документации:Beautify

Скриншот плагина:

Prettier - Code formatter

Документация по плагину:Prettier - Code formatter

Скриншот плагина:

12.2 Проверка стиля кода

ESLint

Документация по плагину:ESLint

Скриншот плагина:

13. README.md

13.1 Why README ?

У хорошего проекта часто есть хороший документ.Как правило, при просмотре или обслуживании проекта первое, на что следует обратить внимание, — это документ с описанием проекта.READMEТо есть "читает меня" значит.

13.2 Синтаксис

Markdown — это облегченный язык разметки, который можно использовать для добавления элементов форматирования в текстовые документы. Markdown был создан Джоном Грубером в 2004 году и на сегодняшний день является одним из самых популярных языков разметки в мире. —— Китайский веб-сайт MarkDown

Если вы хотите узнать больше о Markdown, перейдите сюдаКитайский веб-сайт MarkDown.

13.3 Основные компоненты

Хороший проектный документ обычно включает в себя следующее:

1. Представление проекта (включая основную информацию, такую ​​как название проекта, логотип, введение, официальный сайт и т. д.)
2. Используйте стек технологий
3. Установите и запустите
4. Особенности проекта, список функций проекта
5. FAQ
6. Список изменений

Рекомендуемое чтение:

• Почему документы проектов с открытым исходным кодом других людей так круты? Вот что было раньше!
• VuePress научит вас создавать технический документ/блог в стиле Vue.

14. Документация по спецификации кода

Чтобы изучить спецификацию кода более систематически, настоятельно рекомендуется перейти наCode GuideСмотри сюда, там полно галантерейных товаров! Ниже приведен скриншот веб-сайта:

В-третьих, стыковка дизайнера пользовательского интерфейса

1. Спецификация внешнего интерфейса и дизайн пользовательского интерфейса

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

2. Мой контроль качества с UI-дизайнером Джун Гэ

Фон вопросов и ответов

Красота страницы во многом зависит от пользовательского интерфейса.Вдохновение для дизайна, но стиль страницы неодинаков в зависимости от пользовательского интерфейсаСпецификация проекта. Разработчики внешнего интерфейса могут определять общедоступные переменные и инкапсулировать общедоступные компоненты в соответствии с общедоступной частью стиля в процессе разработки проекта.С точки зрения процесса разработки, если дизайнер пользовательского интерфейса может предоставить полный набор спецификаций дизайна стиля, он будет значительно снизить стоимость.Постобслуживание требования разработчиков переднего плана. Важным процессом развития является общение. С таким настроением я начал Q&A с UI-дизайнером команды проекта, братом Джуном.

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

важные. Полная спецификация проекта основана наТеория атомного дизайнаКонструкция атомов молекул интерфейсных тканей, воплощенных в виде модуля, является фундаментальной частью всех атомных материалов, отмечается, что если только один атом, не может составлять целую молекулу. - Ui Designer Jun Brother

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

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

Четыре, хорошая рекомендация книги

"Код аккуратной"

В книге предлагается идея: качество кода прямо пропорционально его чистоте. Чистый код, как более надежный с точки зрения качества, так и заложил хорошую основу для пост-обслуживания, обновления. Как лидер в области программирования, автор дает серию эффективных и чистых методов работы с исходным кодом. Эти практики, как правило, отражены в книге (или «откровении»), дополненные положительными и отрицательными сторонами примеров из реальных проектов. Следуя этим правилам, вы сможете писать чистый код, чтобы эффективно улучшить качество кода. - Знаменитая книга

Рефакторинг (2-е издание)

Эта книга является обновленным изданием спустя 20 лет после публикации классической книги «Рефакторинг». Книга наглядно раскрывает процесс рефакторинга, объясняет принципы и практики рефакторинга и показывает, когда и с чего начинать анализ кода для улучшения. В книге представлено более 60 возможных рефакторингов, каждый из которых знакомит с мотивацией и методами проверенного подхода к преобразованию кода. Рекомендации по рефакторингу, представленные в этой книге, помогут разработчикам изменять код шаг за шагом, тем самым снижая риск во время разработки. —— Дубан Чтение

резюме

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

использованная литература

• Code Guide
• MDN Web Docs
• Китайский веб-сайт MarkDown