S
Без комментариев можно сказать, что делает код бизнес-логики. Но нельзя ответить на вопросы "зачем оно тут вообще" и "правильно ли оно тут реализовано",
вот для этого и нужно управление требованиями, чтоб они где-то были зафиксированы
Size: a a a
2020 June 10
S
если нигде не фиксировалось. то код по дефолту делает то, что нужно :)
G
Рассинхрон неизбежен
G
Между кодом и документацией по требованиям
S
да, но если требований вообще нет, то никак не синхронизировать
S
так по крайней мере можно прочесть, осознать и полезть в код
G
если нигде не фиксировалось. то код по дефолту делает то, что нужно :)
Именно так, пока не начинают жаловаться пользователи)
S
программисты ленивы и изобретать оригинальные именования и паттерны редко будут. Даже велосипеды обычно стандартны
G
Побольше бы ленивых программистов. Слишком часто бывают слишком инициативные, сам таким страдаю...
S
сложно если в команде была "звезда" и что-то сделала в духе - напишу мини-виртуальную машину на Форте и на ней уже логику
DK
Рассинхрон неизбежен
Да, но это не тумблер - есть или нет. Это риски, выражающиеся в повышении трудозатрат. Сложность изменения слабо задокументированного кода с хитрой бизнес-логикой растет экспоненциально во времени - чем больше изменений внести, тем сложнее внести новые.
G
Да, но это не тумблер - есть или нет. Это риски, выражающиеся в повышении трудозатрат. Сложность изменения слабо задокументированного кода с хитрой бизнес-логикой растет экспоненциально во времени - чем больше изменений внести, тем сложнее внести новые.
Полностью согласен, видел реальный пример такого.
DK
сложно если в команде была "звезда" и что-то сделала в духе - напишу мини-виртуальную машину на Форте и на ней уже логику
О, на прошлом проекте выкидывали модули одной такой обидчивой звязды, и ставили новые, потому что его модули были не модифицируемы в принципе (и он отказывался их модифицировать, так как они, по его мнению, все делают хорошо, а мы идиоты и не лечимся)
S
еще геммор, если hardcode всего идет... чем больше параметров захардкодят тем сложней потом в принципе что-то поменять
S
допустим воткнут где не надо часовой пояс фиксированный. Или число дней в месяце , одно.. на все месяцы...
DK
Я столкнулась с закардкоженными справочниками. Есть апишка, к ней схемы - xsd, там же справочники. И некоторые из них дублированы в коде перечислением. И в других подсистемах еще есть копии. И в итоге есть три справочника (минимум): один в xsd, второй в коде, третий в монге. Все разные.
S
да, и это тоже, вообще жесть. Захардкоженные роли (ролевая модель как бы есть, но в реальности нет) и т.д
S
с выделением и абстрагированием туго
AZ
главное при анализе кода goto definition / find refrences
для Java Eclipse-а хватает. Там можно и плагин самому набрость для вытаскивания деталей
с С++ сложней, надо продукты Klocwork-а
для Go и т.п и так уже много, в том числе тот же sourcegraph
для Java Eclipse-а хватает. Там можно и плагин самому набрость для вытаскивания деталей
с С++ сложней, надо продукты Klocwork-а
для Go и т.п и так уже много, в том числе тот же sourcegraph
Есть системы на таких стеках и так написаны, что "карта кода" не даёт и 50% понимания функционала. А вопрос "зачем система это делает" чаще гораздо важнее вопроса "как система это делает"
S
"как" - нужно, если хотим поменять
помимо карты кода добавляем еще трассировку запросов, смотрим что UI дергает и т.д
помимо карты кода добавляем еще трассировку запросов, смотрим что UI дергает и т.д