37 lines
4.2 KiB
Markdown
37 lines
4.2 KiB
Markdown
---
|
||
name: feedback-reference-code-handling
|
||
description: Пользователь часто присылает код из своих других проектов (eoffice_v3 и т.п.) как референс — как с этим работать
|
||
metadata:
|
||
type: project
|
||
---
|
||
|
||
Пользователь регулярно кидает готовый код из своих старых/других проектов (`/home/isaevea/http/eoffice_v3`
|
||
и подобные) как образец того, что нужно сделать в Bicycle — целыми классами (Repository, Model,
|
||
render()-методы Controller, CSS/JS-подключение во View). Это не абстрактные пожелания, а буквальный
|
||
рабочий код, который он хочет видеть похожим здесь.
|
||
|
||
**Why:** Несколько раз за сессию 2026-08-07 я либо: (а) придумывал что-то стилистически похожее, но не
|
||
совпадающее с тем, что он реально писал в своём коде (например свойство `$_driver` вместо `$pdo` —
|
||
он дважды написал `$this->pdo` сам, прежде чем я понял, что нужно называть именно так), либо
|
||
(б) слепо копировал референс, не заметив реальные баги/нестыковки в нём (в `eoffice_v3`
|
||
`Repository::getList()` по умолчанию `FETCH_KEY_PAIR` — падает не на ровно 2 колонках; `FETCH_CLASS`
|
||
не получает `obj_class`; свой счётчик вложенности транзакций в каждом Repository — ломается, если два
|
||
репозитория делят одно PDO-подключение). На прямой вопрос «у нас свой проект, мне нужно не также а
|
||
правильно» — стало ясно: копировать вслепую не нужно, нужно оценивать критически.
|
||
|
||
**How to apply:**
|
||
1. Когда пользователь присылает референс-код — сначала спросить себя (не обязательно вслух), реально
|
||
ли это то, что нужно 1-в-1, или в нём могут быть баги/устаревшие паттерны конкретно под старый проект
|
||
(например поддержка нескольких "модулей", которых в Bicycle нет).
|
||
2. Портировать с адаптацией под реалии Bicycle (уже собранные классы вроде `PdoDriver` с его SAVEPOINT-
|
||
логикой могут делать что-то лучше/надёжнее, чем то, что в референсе — не дублировать хуже).
|
||
3. Если сомневаешься, действительно ли имя/сигнатура должны совпадать буквально — можно посмотреть
|
||
исходник самого референс-проекта на диске (он часто лежит рядом, в других папках `/home/isaevea/http/*`),
|
||
а не гадать по вставленным фрагментам — так нашлись оригиналы `Database.php`/`PdoDriver.php`/
|
||
`Statement.php`/`ProfilerPDO.php`/`Repository.php` в `eoffice_v3/System/Classes/`.
|
||
4. Если пользователь явно пишет что-то вроде `$this->pdo` (даже с ошибкой в другом месте кода) —
|
||
это сильный сигнал именно про нейминг, не опечатка; после второго повтора — не переспрашивать,
|
||
а сразу переименовывать под него (см. также [[feedback-less-confirmation]]).
|
||
5. После адаптации — явно резюмировать пользователю, ЧТО именно отличается от референса и почему
|
||
(иначе выглядит как будто я не выполнил задачу «сделай как там»), см. пример в `roadmap.md`.
|