Фон

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

Это было так грубо — ее намек, я думаю, что она не освоила 1 единственный самый полезный навык, когда дело доходит до общения с продакт-менеджером, существами, которые постоянно злятся на Услышав (да, Событие) «нет, не могу» .

Для программ там:

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

Я испугалась ☹️

Что так сложно

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

🙀Git
Это Гималаи перед каждым программистом, не занимающимся повседневным использованием. Git шпаргалка необходима на каждом этапе пути. На цыпочках по льду, изо всех сил стараясь не задеть ветки. Мне уже понадобилось 0,5 дня, чтобы сделать только основы: ветвление, настройку, вытягивание и коммит.

3️⃣ Вью
Не побежден. Я продолжаю.

Мои устаревшие знания о Vue подвергаются сомнению. Я знаю Vue 2, но это уже эпоха Vue 3. Я признаю, что учусь восхищаться красотой vue 3 с помощью API композиции. Я восхищаюсь тем, как он может сочетать в себе простоту и запутанность одновременно.

вам больше не нужны жесткие `data{}`, `methods{}`, `onCreate{}` blablabla — не знаю, черпал ли Эван Ю, создатель, вдохновение в 八股文 (парадигмальный фиксированный стиль, который древнекитайский должны соблюдаться при написании официальной диссертации, особенно в национальном тесте). Но тогда у вас есть `ref()`, `reactive()` — оба могут быть реактивными, но с различиями. и `const rect = reactive()` rect нельзя изменить, но свойство reactive({property:value}) можно изменить. и т.д.

📋 Форма
Позвольте мне перемотать вперед (забудьте о процессе изучения фреймворка ant-design-vue — их документы и codeandbox очень помогли.)

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

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

2. Какие правила проверки должны применяться к имени, паролю и другим обязательным полям?

3. Что подсказывать пользователю при сбое проверки?

4. Какова рекомендация при заполнении формы?

🎊Демонстрация
Вот соображения ( Я рад поставить себя на место менеджера по продукту и разработчика, даже если это будет стоить полуночного сжигания масла.)

1. Я считаю, что наилучшей практикой является проверка в реальном времени. Это не должно быть предметом переговоров. Ant-design обеспечивает довольно обширную проверку, поддерживающую как встроенную, так и пользовательскую. Есть еще один плагин, который мне очень нравится — «vee-validate». Я использовал дизайн муравья.

2. Правила, применяемые ко всем обязательным полям, по умолчанию «не пусты».
3. Правила, применяемые к электронной почте, являются встроенными, и нам не нужно об этом беспокоиться.
4. Правила, применяемые к паролю, часто настраиваемые, и именно здесь мы применяем правила безопасности нашей организации в бизнес-операциях.
5. Два пароля должны совпадать, и в случае изменения одного из них после проверки необходимо выполнить повторную проверку.
6. После отправки происходит окончательная проверка.

После всего,

Дизайн — смешное слово. Некоторые люди думают, что дизайн означает, как это выглядит. Но, конечно, если копнуть глубже, то это действительно так. — Стивен Леви, WIRED: Стив Джобс, революционер

Вот демо:

https://codesandbox.io/embed/form-with-custom-validator-ant-design-vue-3-2-10-forked-from-basic-ant-design-vue-3-2-10-pi8p8l ?fontsize=14&hidenavigation=1&theme=темный

если вы не видите превью, вот скриншот демонстрационного проекта codeandbox

Конечный продукт

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

Заключение

Сегодняшний вывод — это совет для менеджеров по продукту: не пытайтесь писать код самостоятельно. Недостаток этого:

  1. Это пощечина, говорящая о том, как неправильно было думать, что это займет 0,5 дня.
  2. Это не вызывает уважения у программистов, потому что они говорят: «Что же такого сложного?» «Я тоже могу это сделать, может быть, немного уродливее, но кого это волнует».
  3. В конце концов, по-прежнему одна зарплата за выполнение двух работ. Что еще хуже: это кодирование все еще не дает вам навыка выживания, если вы однажды потеряете работу pm. это опыт, требующий сосредоточенности и преданности делу.

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