Здравствуйте, Undying, Вы писали:

U>А отсутствие боязни изменений достигается за счет другого. Если код написан хорошо и понятно, то есть уверенность, что при обнаружении ошибки в 99% случаев она будет локализована за 5 минут и исправлена за 15 минут.

Ага. Пользователем. И эти 15 минут выливаются в дни, так как нужно воспроизвести ошибку, сообщить о ней разработчикам и дождаться новой версии ПО.

Плюс нет никаких гарантий, что исправление не повлечет новых ошибок.

В общем, жить конечно так можно, но эта жизнь сравни с ездой по дороге с ямами. Хотя в общем дорога хорошая, но наличие ям в неизвестных местах заставляет ехать осторожно, а значит медленно. Плюс никаких гарантий, что не сломаешь колесо посеред дороги.

Здравствуйте, VladD2, Вы писали:


NGG>>Слишком много усилий нужно за раз приложить, чтобы от ручного само-тестирования перескочить к автомату.

VD>С этим я не спорю. Но ведь было время когда всю эту архитектуру придумывали и разрабатывали. В то время было вполне не трудно предусмотреть средства тестирования. И то что это не было сделано — это огромный архитектурный просчет, плоды которого ты лично и вынужден расхлебывать.

Было... Но, кто старое помянет, тому и глаз вон
Я, кстати, готов сказать проотцам спасибо и за ту архитектуру что есть (те базовые концепции на которых стоит весь зверинец).
Большинство претензий относится к качеству кода отдельных компонент.


NGG>>Обвязку юнит тестами сделать технически проще.

VD>Вполне возможно. Но сам понимаешь, юнит-тесты отлавливают только сугубо протокольные баги. Более сложную логику ими не охватить. Так что это будет частичное решение. Но лучше что-то чем ничего.

Да, конечно. Однако юнит-тесты позволяют хоть как-то отразить спецификацию в коде и "гарантировать", что "кирпичики" из которых строится приложение, не содержат ошибок. А это, в свою очередь, сильно упрощает рассуждения о корректности работы приложения в целом.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Undying, Вы писали:

U>>Если код сложный и запутанный, то и при наличии тестов его никто не будет менять без крайней на то необходимости.

VD>Это не так. Отличный пример — компилятор немрела. Код сложный, дико связанный (опыта у поляков было мало) и не всегда понятный. Но меняется он с завидной частотой. И именно тесты позволяют отлавливать плохие изменения.
это ты на примере компилятора, значится, судишь о сложности других проектов? молодец.

Здравствуйте, -_*, Вы писали:

-_*>Здравствуйте, Aikin, Вы писали:

CC>>>Код как код.
A>>Я вот тоже не поянл что там в коде-то не так? Но списал на незнание Cpp.

-_*>С кодом в принципе все в порядке, кроме
-_*>1. код — дерьмо
-_*>2. рефакторингом и не пахнет
-_*>3. нет принципа ООП, который не был бы нарушен

-_*>Но для плюсов это типичный случай — 90% кода на плюсах именно такое дерьмо и есть.

молодец, неплохо детишек завел. сколько сразу набежало, какашек нахватало
а то я все ждал, когда же они проявят свою натуру.....

Здравствуйте, March_rabbit, Вы писали:

U>>>Если код сложный и запутанный, то и при наличии тестов его никто не будет менять без крайней на то необходимости.

VD>>Это не так. Отличный пример — компилятор немрела. Код сложный, дико связанный (опыта у поляков было мало) и не всегда понятный. Но меняется он с завидной частотой. И именно тесты позволяют отлавливать плохие изменения.
M_>это ты на примере компилятора, значится, судишь о сложности других проектов? молодец.
M_>

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