Напишете задание за агент

Опишете промяна, която проверяващият може да оцени

„Добавете експорт на клиенти“ оставя няколко решения отворени. Кой може да експортира записи? Кои записи и полета се включват? Какво се случва при неуспешна заявка? Агент може да запълни тези празнини с правдоподобни решения. Те все пак могат да са погрешни за бизнеса.

Започнете с потребителя и проблема. След това опишете необходимото поведение. Включете доказателствата, които ще покажат дали резултатът е приемлив.

Заданието трябва да намали несигурността, без да определя всеки вътрешен проектен избор. Посочете необходимата граница на данните. Нека реализацията използва съществуващите подходи в хранилището, освен ако има причина за промяната им.

Използвайте конкретен пример

Следното задание е за измислено приложение за обслужване на клиенти. То е учебен пример, а не пълна спецификация за продукционна среда.

Резултат: Мениджър по обслужване може да изтегли списък с клиенти.
Роля: Мениджър в текущата организация.
Данни: Само активни клиенти в тази организация.
Полета: Идентификатор на клиента, име на фирмата и състояние на акаунта.
Формат: UTF-8 CSV със заглавен ред.
Отказана заявка: Върнете съществуващата грешка за права на достъп.
Празен резултат: Върнете валиден CSV само със заглавния ред.
Обхват: Използвайте съществуващия маршрут за експорт и подход за одит.
Изключено: Без нови роли, зависимости или внедряване.
Доказателства: Тестове за разрешени, отказани, празни и междуорганизационни заявки.

Това задание определя полезно поведение и ограничения. То разкрива и допълнителни въпроси. Трябва ли системата да ограничава размера на експорта? Може ли поле да съдържа формула за електронна таблица? Кой има достъп до одитния запис? Решете въпросите с важни последствия преди реализацията. Не приемайте примера като универсален контролен списък.

Разграничете изискванията от предположенията

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

Например „Използвайте съществуващия подход за одит“ предполага, че има подходящ такъв. Поискайте агентът да го намери. Ако в хранилището няма такъв подход, агентът трябва да докладва липсващата зависимост, преди да измисли нова одитна система.

Ограничение може и да противоречи на желания резултат. Съществуващият маршрут може по замисъл да връща всяка организация. Агентът трябва да покаже противоречието и да предложи ограничена поправка. Не трябва неявно да премахва границата на данните или да разширява задачата до пренаписване на архитектурата.

Включете доказателства в завършената работа

Поискайте обобщение на доставеното, което обяснява крайното поведение, променения обхват и изпълнените проверки. Изисквайте точни команди и резултати, когато са важни. Разграничавайте успешно преминала проверка от проверка, която не е могла да се изпълни.

Pull request-ът трябва да запази причината за промяната. Бъдещ разработчик по поддръжката може да види кода без първоначалния разговор. Включете достатъчно контекст, за да обясните защо експортът изключва определени полета и как се прилагат контролите за достъп.

Указанията на Google за описания на промени са полезен източник за този запис. Описанието трябва да обяснява промяната и целта ѝ. Поддържайте записа в съответствие с окончателната реализация след поправките от прегледа.

Съобразете обема на заданието със задачата

Малка текстова поправка може да използва кратко задание. Експортът на данни се нуждае от повече подробности, защото неуспехите му могат да разкрият информация. Нов работен процес за плащания изисква още повече анализ и преглед.

Не измервайте качеството на заданието по дължината му. Попитайте дали компетентен проверяващ би различил правилен от неправилен резултат. Ако две разумни реализации биха се различавали по поведение с важни последствия, първо изяснете това поведение.