Аргументация против глобальных автоимпортов (типа тех, что в Nuxt) от Artyom Tuchkov

1. Это явно - ты всегда видишь, откуда взялся компонент и в один клик можешь провалиться в него, а не в *.d.ts ;)

2. Это наглядно видно не только в редакторе, но и на всяких гитхабах, когда смотришь там код, с автоимпортами тебе придется гадать, откуда взялся компонент

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

4. Не нужно генерировать портянку *.d.ts для того, чтобы редакторы видели их, и, как следствие, без них ты получаешь более качественный тулинг и анализ твоего кода

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

6. Импорты может проставлять сама IDE, а еще их можно сворачивать в 1 строку, если визуально отвлекают

#architecture #bestpractices #tip #nuxt

Полезные советы при разработке с IDE AI агентами от @vuefaq.

1. Используйте по возможности системный промпт. Cursor позволяет иметь .cursorrules файл, в котором можно прописать основные установки по проекту. Пример файла.
Напишите свой и попросите AI улучшить его. Автокомплит его плохо видит, но чат и composer - вполне. По крайней мере, свою CSS дизайн систему и компоненты использует четко.

2. Научитесь азам promp-engineering. Это полезно и при разработке, и при диалогах с обычными чатботами. От простого few-shots prompt эффективность результата может вырасти в разы. Не надо винить AI в тупости, если вы не умеете формулировать вопрос на языке, который ему более понятен.

3. Используйте сильные стороны AI. Он может хорошо сгенерить новый компонент, новый микросервис, добавить функционал, сделать i18n перевод, дать совет по какой-то лучше практике в определённой области, рефакторинг, делать рутинные задачи, писать тесты, но не так хорошо работает на больших изменениях с существующим кодом. Также может с нуля нагенерировать плохой неоптимальный код на нестандартных задачах (в таких случаях, необходимо давать максимально подробную информацию о контексте задачи).

4. Используйте его как консультанта перед реализацией какой-то задачи. Задайте несколько вопросов в чате, как что-то можно сделать (с использованием вашего кода как контекста), проанализируйте варианты, выберите подходящий и дальше в composer начните постепенно его реализовывать, руководя процессом. Стратегически важные вопросы задавайте также разным внешним системам - Gemini, ChatGPT, DeepSeek. Иногда кто-то один даёт явно более лучший ответ.

4.1. Вместо «Напиши такой-то модуль» используйте цепочку:
- Проектирование API
- Реализация core-логики
- Добавление обработки ошибок
- Интеграция с существующим кодом
- Оптимизация производительности

5. AI - не старик Хоттабыч, он не творит чудеса. Более того, он очень тупой. Тупой инструмент. Но сильный. Управление им это как управление двухтонным ковшом экскаватора - можно быстро сделать много полезного, и можно быстро сделать кучу плохого (со своим кодом). Которую потом будешь долго разгребать.

6. AI хорошо генерит комментарии и документацию. Можете добавить сразу VitePress к проекту и поддерживать его техническую документацию.

7. При использовании AI сервисов в приложении используйте структурированные (JSON) ответы. Не все это умеют, но последняя 4o-mini, например, умеет (по JSON-scheme). С учетом цены на нее, она очень полезна для парсинга документов или картинок, скажем, из которых предварительно можно вытащить текст конвенциональными методами (pdf2text и OCR).

8. Пробуйте разные модели. Причем, разные модели для разных случаев. Дороже ≠ лучше.

9. Переиспользуемые промпты можно хранить в отдельных текстовых файлах. Научитесь использовать структурированные промпты при необходимости, например:

/analyze-tech-debt 
--focus=duplication,complexity 
--suggest-refactoring

Для современных LLM они, часто, предпочтительней для простых задач.

10. Почитайте документацию к вашей LLM и лучшие практики. Ваша продуктивность ( => стоимость как разработчика) может возрасти в несколько раз с этим инструментом. Потратьте время на то, чтобы научиться им эффективно пользоваться.

#ai #tip #ide #cursor