Как оптимизировать интерфейсный код на работе?

внешний интерфейс программист JavaScript модульный тест

Это вопросы и ответы Чжиху, я немного ответил здесь.

в общем

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

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

В основном «плохой код» вызван «оптимизацией, когда вы не заняты».

Не ищите оправдания написанию плохого кода

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

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

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

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

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

становится лучше

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

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

Далее идет умение.

Шаг 1: Не пишите плохой код

Фан Фан, ты что, дурак? Ты спросил "как оптимизировать код", а ответил "не пиши плохой код"? !

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

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

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

  1. неправильное имя переменной
  2. плохой комментарий
  3. плохой дизайн
  4. Не пишите тесты (весь код без юнит-тестов — плохой код, поспешите изучить юнит-тесты!)

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

И они даже не подозревают, насколько плох их код!

Итак, первый шаг — понять правду: 80% вашего кода — плохой код.

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

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

Шаг 2. Избегайте дублирования

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

Шаг 3: Табличное программирование

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

До оптимизации:

howManyDays(year, month){
    if(month === 1 ||
        month === 3 ||
        month === 5 ||
        month === 7 ||
        month === 8 ||
        month === 10 ||
        month === 12
    ){
        return 31
    }else if(month === 2){
        return isLeapYear(year) ? 29 : 28
    }else{
        return 30
    }
}

Оптимизировано:

howManyDays(year, month){
    const table = {
        1: 31, 3: 31, 5: 31, 7: 31, 8: 31, 10: 31, 12:31,
        4: 30, 6:30, 9: 30, 11: 30,
        2: isLeapYear(year) ? 29 : 28
    }
    return table[month]
}

До оптимизации:

function calculateGrade(score){
    if(score>=90){
        return 'A'
    }else if(score >= 80){
        return 'B'
    }else if(score >= 70){
        return 'C'
    }else if(score >= 60){
        return 'D'
    }else {
        return 'E'
    }
}

Оптимизировано:

function calculateGrade(score){
    const table = {
        100: 'A', 
        90: 'A',
        80: 'B',
        70: 'C',
        60: 'D',
        others: 'E'
    }
    return table[Math.floor(score/10)*10] || table['others']
}

Шаг 4: Используйте подпрограммы

Шаблоны проектирования — это некоторые процедуры программирования, а принципы программирования Unix — это также некоторые процедуры программирования.

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

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

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

Например, жизненный цикл обычно поддерживает крючки или аспекты;

Например, оптимизация производительности обычно заключается в добавлении кеша;

Например, дизайн API должен быть ортогональным;

Например, сложные системы данных обычно используют разделение ответственности команд и запросов;

Например, поменяйте пространство на время, поменяйте время на пространство;

...

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

Шаг 5: Настаивайте на оптимизации каждый день

Я сказал в классе, что «оптимизация каждый день» называется рефакторингом, а «оптимизация каждый год» называется переписыванием.

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

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

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

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

Вышеупомянутое содержание находится в моем "JS на простом языке》 рассматривается в курсе,Раздаточный материал по курсу здесь.

Категории