Обмен технологиями

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

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

Несколько возможностей, которыми должен обладать интерфейс:

(1) Возможность подготовки поддельных данных (моделированных данных), поскольку иногда внутренний интерфейс не готов, а на внешнем интерфейсе нет данных, но график плотный и не может дождаться внутреннего интерфейса. end должен иметь возможность создавать моделируемые данные.

(2) Возможность пропустить определенную бизнес-логику. Если для завершения бизнеса с замкнутым циклом требуется 5 шагов, а если 2 застревает, то 345 не может продолжать продвигаться вперед. Конечно, это действительно хороший способ побеспокоить серверную часть. изменить базу данных. Это просто. Если это последнее средство и оно находится в среде разработки, я думаю, все в порядке.

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

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

(5) Когда одновременно разрабатывается несколько проектов, работа внутренней среды разработки влияет на итеративную разработку различных версий клиентской части. Что нам делать?

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

(7) Возможность инкапсулировать компоненты. Здесь я хотел бы поделиться некоторыми своими мыслями. Основываясь на личном опыте, я думаю, что интерфейсные компоненты можно просто разделить на общедоступные общие функциональные компоненты и бизнес-компоненты, реализующие общий функционал. Компоненты повсеместно используются при реализации систем. Общие функции могут облегчить последующую разработку аналогичных функциональных предприятий. Бизнес-компоненты тесно связаны с нашим бизнесом. Данные и логика в них тесно связаны с нашим бизнесом и, как правило, не могут использоваться на других страницах. Одна вещь, которая действительно нужна нашему интерфейсу и которую он должен учитывать при инкапсуляции компонентов, — это стараться не помещать бизнес-данные и логику в такие общие функциональные компоненты. Это приведет к некоторой связанности кода. Когда наш проект постепенно станет сильнее, им станет трудно работать. снова. Поэтому при работе с компонентами мы должны максимально подготовить данные и логику в бизнес-компонентах. Если нам придется это делать, лучше всего писать заметки и стараться не затрагивать предыдущую логику кода. Я столкнулся с этой проблемой, когда впервые начал работать над проектом. В результате к первоначально инкапсулированному табличному компоненту было добавлено слишком много if и else, я думаю, это произошло из-за слишком сильной связи с бизнесом. это с одной стороны, а с другой стороны. С одной стороны, количество итераций частое, а цикл относительно длинный, и им занимается много людей, поэтому вносить изменения становится сложнее. Поэтому, что касается упаковки компонентов, я постепенно обнаружил некоторые моменты, которые можно оптимизировать в текущей разработке проекта. Затем, если компоненты должны быть упакованы в последующих итерациях проекта, следует максимально избегать некоторых проблем. также то, что необходимо дополнительно оптимизировать, если в расписании достаточно времени. В конце концов, это позволяет нам более плавно использовать компоненты.

продолжение следует...