Comments 7
Оценка сложности изменений кода с помощью оценки сложности алгоритмов O, вполне возможна.
Основная проблема этого подхода в том, что вы можете произвести оценку только тогда, когда к вам уже принесли изменение.
O(0) — мы установили CMS и все настраиваем из админки. Код уже написан.
… а почему вы не считаете сложность внесения изменений через админку? Или "не я вношу — стоимость 0"?
O(0) — типа программировать не нужно. Трудозатраты контент-менеджера не считаю.
Я и говорю: "не я вношу — стоимость 0". Это удобный подход для программиста, но неудобный для того, кому систему надо поддерживать.
Потому что на самом деле не важно, кто и когда вносит изменения, важно сколько изменений надо внести (и насколько это сложно) для того, чтобы система перешла из одного функционального набора в другой.
Напомню, что анализ через O(n) используется для больших n. А тут как раз тот случай, когда из-за маленьких n есть заметные шансы, что O(1) окажется больше, чем O(n).
Ну и наиболее интересная метрика – не во сколько мест надо внести изменения, а в скольки местах изменения внести забудут :-). Так что интерфейсы с жёстко прописанными типами данных рулят: изменил одну сторону "разъёма" – вынужден сразу менять все "ответные части".
Думаю нет, поскольку предложенная оценка не даёт понимания, сколько лишних абстракций у вас создано, а только лишь — сколько абстракций не хватает для запрошенных изменений.
При работе с кодом несколько уровней абстракции, созданных «на будущее», чтобы потом попасть в О(1), совсем не добавляют прозрачности и понимания. Особенно «не скучно» становится, когда вы не угадали со структурой абстракций (редко разработчик знает предметную область лучше заказчика).
Статья жиденькая, конечно, но попытка формализации такой важной темы достойна уважения! Развивайте идею!
Оценка трудности изменений в коде с помощью O большое