RT
Разработчик, плохо понимающий домен, пишет технически красивый, но бесмыссленный код, который очень быстро скатывается в вермишель, просто потому что в него заложены неверные абстракции и поведение.
Size: a a a
2020 February 26
RT
Как решатете проблему “многобукав, лень читать” в части разработчиков?
А
Разработчик, плохо понимающий домен, пишет технически красивый, но бесмыссленный код, который очень быстро скатывается в вермишель, просто потому что в него заложены неверные абстракции и поведение.
Домен, разработчик, Всемирная революция
WTF???
WTF???
A
Коллеги, поделитесь советом что вы предринимаете для того чтобы стимулировать разработчиков изучать прикладной домен?
Если разраб скачет между доменами каждые 2 дня, обычно никак не получается.
Думать начинают когда приходится доводить задачу на горизонте месяц-полгода, после пары таких циклов с переработками и исправлением своих костылей в третий раз начинают вникать глубже.
Думать начинают когда приходится доводить задачу на горизонте месяц-полгода, после пары таких циклов с переработками и исправлением своих костылей в третий раз начинают вникать глубже.
RT
То есть, воспитывать поеданием собственного кактуса, только так?
A
То есть, воспитывать поеданием собственного кактуса, только так?
Я не помню другого способа заставить человека делать хорошо, если есть установка "потом все равно кто нибудь другой будет переделывать"
RT
Ситуация номер два: проект команда получила от других людей. Метод кактуса еще не работает. Как стимулировать разбираться в задаче, а не делать быстрые заплатки как-нибудь кое-как?
A
Какая разница от кого получила? Главное дать понять что после вас проект никто не подберет, и доводить придется до конца.
ОИ
Ситуация номер два: проект команда получила от других людей. Метод кактуса еще не работает. Как стимулировать разбираться в задаче, а не делать быстрые заплатки как-нибудь кое-как?
Брифинг с аналитиком можно провести.
ОИ
Либо с представителем бизнеса и продуктом
ОИ
Описать проблемматику, окружение, варианты. После чего привести к решению показав плюсы и минусы решения
ОИ
Писать бизнес-требования и метрики успеха, понятные разработке
ОИ
Добавить фин поощрение за изменения в прикладной области. Но это уже сложнее.
AL
Я видел только один вариант рабочий: Команду разработки заставить саппортить багофикс бесплатно или за свой счёт.
AL
Ну в смысле возмещать гарантийные потери например.
AL
Тогда сразу начинают работать с требованиями. Проектировать архитектуру... Писать качественные тесты...
AL
Документацию делать. Сами.
RT
Да, наверное метод “кудаж ты денешься с подводной лодки” он будет самый эффективный. Классика.
DK
Как решатете проблему “многобукав, лень читать” в части разработчиков?
Букв должно быть мало и информация должна быть адекватно пропилена на слои, каждый из которых для понимания довольно прост и имеет чёткие связи с другими уровнями
СС
Я видел только один вариант рабочий: Команду разработки заставить саппортить багофикс бесплатно или за свой счёт.
вспомнилось в тему:
https://youtu.be/-72YklIyIxY
https://youtu.be/-72YklIyIxY
