В настоящее время несколько проектов, принятых на работу, являются проектами для ПК на стороне B. Бизнес-логика относительно сложна, а код имеет долгую историю.При ежедневном обслуживании мы часто сталкиваемся с техническими проблемами, с которыми хотим разобраться, найти проблемы, решать проблемы и избегать их повторения Возникает одна и та же проблема, которая является не только одним из факторов устойчивого поддержания проекта, но и процессом накопления личного опыта работы
Эту статью можно сделатьБерете новый front-end проект? Вот некоторые моменты, на которые вы можете обратить внимание,Написание поддерживаемых современных интерфейсных проектовдобавка
Конкретные, согласованные имена переменных
Модернизация разделения между передней и задней частямиwebВ процессе разработки передняя часть берет на себя больше бизнес-логики, чем в прошлом, хотя естьTypeScriptи другие инструменты ограничения, но по сравнению с внутренними языками,jsОн по-прежнему имеет значительную гибкость, что делает предельный код исследования кода более неприятным после сложного кода
Очень часто одна переменная передается слой за слоем и используется везде, и именование переменных оказывает значительное влияние на отслеживание переменных.
Таким образом, имена переменных должны быть конкретными и осмысленными. Не рекомендуется делать имена переменных избыточными, чтобы добиться точности имен переменных, но нечеткие и широкие имена переменных также не желательны.Имена переменных точные и короткие, в какой-то момент это может быть трудно сделать,Моя личная тенденция такова, что я предпочел бы выбрать длинное имя переменной, чем расплывчатое и широкое имя переменной, когда действительно невозможно найти хороший компромисс.
Например,dataМожет использоваться как имя переменной, которое используется длявременная локальная переменнаяЭто не проблема, в конце концов, вы можете сразу увидеть всю сферу использования этой переменной, но если данные, содержащиеся в переменной, имеют большую область применения (например, кросс-компонентную) и имеют реальное бизнес-значение, то это не очень хорошо.dataМожет использоваться как имя переменной для любых данных, когда требуется отслеживаниеdata, ищите в редактореdata, встречается вездеdata, нехорошо
Как только имя переменной определено, лучше не переименовывать его, например, если вы хотитеAв компонентеuserDataперейти кBкомпонент,BДля компонента лучше получить это имя переменной как есть, а не называть его как-то иначе.
Иногда может потребоваться переименование при передаче переменных, например сторонние компоненты получаютdata, то вы не можете пройтиuserData, в этом случае, конечно, вы должны переименовать
Основная цель отказа от переименования переменных состоит в том, чтобы предотвратить перестройку мышления, вызванную изменением имен переменных при отслеживании переменных.После того, как переменная была переименована несколько раз, вы можете забыть об этом, когда будете отслеживать ее до конца.Я отслеживал что-то, и я не очень дружу с функцией поиска.Консистентное имя переменной с конца позволяет искать с начальной позиции отслеживания, чтобы пропустить много логики в середине и перейти сразу к концу.
нужный селектор
Современные интерфейсные проекты в основном используютReact,Vueи другие фреймворки, управляемые данными,UIКомпоненты, как правило, упакованные компонентной библиотеки, чтобы использовать кого-то еще, если только не будет писать стиль, в противном случаеhtmlСелекторы элементов в основном необязательны, но это не значит, что они не нужны, по крайней мере, одно преимущество в том, что когда вы хотите найти элемент на странице в коде, вы можете напрямую использовать имя селектора.
На странице есть всплывающее окно, которое отображается неправильно. Вы видите этот элемент всплывающего окна на странице браузера под названиемant-modal-wrap, является сторонним компонентом, поэтому вы вообще не можете найти это имя селектора в своем коде, есть проблема с копией на странице, вы видите на странице браузера, что элемент, где находится копия, является элемент без селектораdivэтикетки, которые сейчас распространены全站divПод волной
Итак, здесь селектор используется какпоказательПоскольку он является индексом, следует также следовать приведенные выше правила, связанные с именами переменного, то есть имя селектора должно быть точным и коротким
Оптимизация должна начинаться с самого начала
Не оптимизируйте заранее
Я думаю, что многие люди слышали эту фразу. Раньше я считал эту фразу мудрой поговоркой, но после большого опыта я начал сомневаться в ней.
Не оптимизируйте заранее, так когда же вы должны оптимизировать? скороholdОптимизировать, когда он не живет? Повторно оптимизировать, когда будут повторены семьдесят или восемьдесят выпусков? Когда члены команды переходят от партии к партии, то оптимизировать?
Конечно можем, но кто в то время оптимизация, кто собирается заниматься таким бизнесом даже на кажущемся безнадежным выходе можно оптимизироватьbugНеблагодарное дело?
Десятки слоев запихиваются в функциюif...else, код тела функции превышает тысячу строк, и его надо бы оптимизировать, но эти коды лежат здесь уже несколько лет, и дорабатывались партиями разных программистов. кто может гарантировать, что оптимизация где-то не нанесет ущерба бизнес-логике?
Заранее нет оптимизации, и нет оптимизации в процессе, то нет оптимизации вообще, вот и родился Шишан
я думаю不要提前优化Это предложение создано в контексте, когда нет необходимости работать сверхурочно с 9 до 5 и мало времени для технической оптимизации.В этом контексте с этим предложением нет проблем, но в большинстве случаев реальная ситуация не вообще не соответствует контексту, так что с этим предложением что-то не так
Компоненты сноса, общий метод извлечения, структура каталогов плана, спецификация кода ...... введены с самого начала для формирования,Не ждите, пока вам понадобится оптимизация, уже слишком поздно
Повторное использование (компоненты, методы)
Повторное использование кода предназначено для повышения эффективности работы, но если вы повторно используете код только для повторного использования, это поставит телегу впереди лошади.
Общие методы, общие компоненты поощряют повторное использование, ноБизнес-логика, бизнес-компоненты, повторное использование с осторожностью
Типичным примером является то, что страница сведений для мобильных устройств и страница редактирования могут иметь большую часть перекрывающейся логики, но для компонента с сильными бизнес-атрибутами, если вы не уверены, что компонент не претерпит серьезных изменений в будущем, не жадный до ближайшего будущего, удобство принятия его как должное
Первоначально, чтобы отличить состояние отображения и состояние редактирования, некоторые условные операторы были написаны. Если в будущем есть логика, которая была повторно использована в будущем, она должна быть разделена в соответствии с требованиями бизнеса, или даже логика полностью отличается , Начальный этап в порядке, может быть, его можно спасти сразу, но, вероятно, слишком поздно выяснить, что эта проблема находится на середине и поздних этапах. С таким большим количеством бизнес-логики, которые вы все еще смеете разделить это? Тогда количество кода этого повторного использования компонента должно быть заменено большим количествомif...elseЗанятие, модификация любой функциональной точки и устранение любой проблемы должны учитывать два набора логики.Для сопровождающего это вызовет значительную умственную нагрузку.Для самого проекта код обслуживания станет больше.
Бизнес-код постоянно меняется. Первоначально схожая логика в нескольких сценариях может стать неактуальной при итерации бизнеса. В этом сценарии повторное использование не только не повысит эффективность работы, но и задержит ее.
Для универсальных методов и универсальных компонентов, чтобы более тщательно отделить их, следуетфункциональный, не должен неявно изменять внешнее состояние
Общий метод предпочтительно представляет собой чистую функцию, одни и те же входные данные имеют одинаковые выходные данные, а входные и выходные параметры должны быть четкими, чтобы люди могли сразу увидеть, какие входные параметры необходимы и какие выходные параметры необходимы, вместо напрямую передавая Большой объект, а затем переходим к телу метода, чтобы найти требуемые свойства объекта одно за другим
Общие компоненты не должны предоставлять свободную руку, чтобы изменить внешние данные, и полученное изменение должно принять инициативу, чтобы пролить, чтобы слой компонентов явным решим, как использовать это изменение
Привязка файлов путем настройки псевдонимов
Обычно ссылаются на компоненты/переменные в нескольких файлах, многие люди могут предпочесть использовать текущий файл в качестве основы для простоты или привычки, а затем передать../или./указать путь к целевому файлу, тем самым добившись ссылки на целевой файл
Представьте себе сценарий, в котором несколько файлов в проекте импортируют один и тот же файл.btn-group.tsx, поскольку он может быть разным относительно разных путей к файлам, импортируемые пути отличаются, и даже бывают случаи, когда на непубличные компоненты ссылаются другие компоненты (предполагалось, что на этот компонент могут не ссылаться другие компоненты, поэтому не был помещен в общую папку компонента, но это произошло позже); он также может существовать по разным путям, с файлами с одинаковыми именами, напримерapp/constant/btn-group.tsx,app/page/home/btn-group.tsx, а поскольку предметы крупнее, дело не только в этомbtn-group.tsxНа теле несколько файлов сталкивающихся с этой проблемой
Пока вроде проблем нет, но когда захочется модифицироватьbtn-group.tsx, возникает вопрос, как вы гарантируете, что ваши изменения не затронут все файлы, которые ссылаются на этот файл? В обычных обстоятельствах нужно проверить все компоненты, которые ссылаются на этот файл, чтобы увидеть, есть ли неожиданные эффекты, так как же найти все компоненты, которые ссылаются на этот файл?
Справочный путь глобального поиска? Но все используют относительные ссылки, а пути ссылок у всех разные.Невозможно искать по одному пути ссылок, по имени файла? Однако существует множествоbtn-group.tsx, вы не можете гарантировать, что найдетеbtn-group.tsxТот, который вы изменилиbtn-group.tsx
Конечно, вы можете убедиться, что все найденные файлы верны, перепроверив их, но это дополнительная умственная нагрузка, и в больших проектах ее можно пропустить, если вы не будете внимательны.
Мое предложение состоит в том, чтобы настроитьalias, то все ссылки начинаются сaliasСсылайтесь на базовый путь (лучше всего следовать этому правилу в той же папке), чтобы для любого файла в проекте его ссылочный путь мог иметь только один случай
Преимущество этого заключается не только в более четком поиске файлов, но и в упрощении ссылок.Файлам ссылок больше не нужно немного сращивать пути.Его путь уникален, и вам нужно только обратиться к файлу из другого просто сделайте копию, не беспокоясь об относительном пути ссылки
Генеральные редакторы, такие как
vscode, можно напрямую скопировать относительный путь файла относительно корневого пути проекта (Copy Relative Path)
Основано на сообществе, а не на сердце
При выборе базовых функций, таких как шаблоны проектирования, библиотеки компонентов пользовательского интерфейса и библиотеки управления состоянием для проекта, следует выбирать те, которые более популярны в сообществе, а не личные предпочтения.
Шаблоны проектирования, сторонние библиотеки и т. д., которые вы считаете очень хорошими, могут быть чем-то, о чем другие люди никогда не слышали или с чем другие люди просто не согласны, что только усложнит сотрудничество между командами.
Код командного проекта для наследования, а не для показухи
отказаться от привычного мышления
Это человеческий инстинкт оставаться в зоне комфорта. Из-за знакомства, технологический стек, используемый в предыдущем проекте, должен продолжать использоваться в следующем проекте.
Но действительно ли он подходит?
последний использованный проектmobx, нужно ли использовать его в этом проекте? В предыдущем проекте все данные о состоянии помещались в библиотеку управления состоянием, будет ли и в этом проекте то же самое? Предыдущий пункт бесполезенTypeScript, тебе не нужен этот?
Может и не надо,может надо заменить,конечно,это не значит,что надо отставать от предыдущего проекта в обратную сторону.Как минимум должен быть мыслительный процесс,не то что предыдущий проект такой, так что и этот сделайте то же самое
Подумав об этом, напишите TODO
Сознательная оптимизация — это хорошая привычка, но вы должны осознавать это.
По моему опыту, в совместных бизнес-гибких итеративных проектах с участием нескольких человек большинствоtodoне может быть сделано
наиболееtodoВсе основано на рассмотрении ситуации в то время, в то время этот метод может иметь только несколько строк.todoЭто было очень просто сделать, но я не сделал этого в то время.Когда я подумал об этом через некоторое время, я обнаружил, что метод стал сотнями строк.Ты все еще осмеливаешься это сделать?
Или, другими словами, вам все еще нужно закончить этоtodoразум? Люди ленивы, вы готовы потратить время, которое можно было бы потратить на игры и просмотр видео, чтобы завершить этоtodoвверх? Видел, что кто-то написалtodo, а также понимаете, но вы готовы помочь другим завершить этоtodo?
Что нужно делать, нужно делать немедленно,Возможно она не может быть выполнена сразу по какой-то причине,поэтому вы хотите сделать это позже,но в общем случае стоимость последующего завершения должна быть больше текущей,и ее нельзя выполнить сейчас.Почему вы считаете,что это можно сделать завершено позже?
Вещи, которые действительно необходимо сделать, даже если прогресс задерживается, пока у вас есть веская причина, у других нет причин останавливать вас
резюме
Часто некоторые предложения, которые позволяют вам писать лучший код, на самом деле бесполезны для бизнеса. и производительность не связаны напрямую с тем, насколько хорошо написан код. Даже эти так называемые предложения иногда влияют на ваш быстрый вывод. Пока я могу произвести хороший вывод и получить хорошую производительность, код Какая разница, если он плохо написано? Я расскажу об этом позже, может быть, это не я буду поддерживать его в будущем
Такая психология может быть нормой, ведь она больше соответствует действительным интересам
Но если вы человек, занимающийся технологиями, действительно ли вы готовы этим заниматься? Я думаю, помимо практических соображений, вы также должны нести ответственность за код, который вы пишете