Уже в какой раз про такое читаю. Как это ВООБЩЕ возможно?
Во-первых, тебе нужно показывать результат почти каждый день, как правило.
Во-вторых, откуда известно, что ты пишешь что-то полезное? Может оно нафик не заработает в принципе?
В-третьих, эти тонны когда покрываются тестами потом, когда-нибудь? Или тесты тоже не запускаются?

И самое главное — зачем?

С 1 курса вбиваем в головы студентов: писать малыми порциями и после написания малой порции запускать на проверку.
С юнит-тестами.
Плохо поддаются дрессировке.
Как говорит одна преподавательница: только отвернешься, они опять на пальму полезли — менталитет однако...

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

В>И самое главное — зачем?

У меня такое было при полной смене базового алгоритма и, как следствие, полной переделки архитектуры одного модуля. Он не столько большой, но алгоритм принципиально базовый, меняет принцип работы всего, вплоть до типов данных и принципа работы с ними. Пока всё не переписал хотя бы с затычками, оно даже не собиралось.

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

В>Уже в какой раз про такое читаю. Как это ВООБЩЕ возможно?
В>Во-первых, тебе нужно показывать результат почти каждый день, как правило.
В>Во-вторых, откуда известно, что ты пишешь что-то полезное? Может оно нафик не заработает в принципе?
В>В-третьих, эти тонны когда покрываются тестами потом, когда-нибудь? Или тесты тоже не запускаются?

В>И самое главное — зачем?
При создании с нуля больших систем, например, следующей версии, когда логика работы тебе хорошо известна, но нужно сильно/полностью переделать алгоритмику, т.к. прежняя устарела.
Вот и пишешь базовые структуры, слои и логику, пока она не сольётся в нечто, способное к запуску.
Да, в РФ (и мире) теперь модны много, но мелких проектов.
Крупные проекты ушли в социалистическое прошлое. Наступило мелкое буржуазное контролируемое счастье)))
Почему-то раньше почти никого не надо было контролировать. Все работали из интереса и на совесть. Ну, почти все.
Были и исключения. Но исключение не опровергает правила, вовсе они его не подтверждают.
Сегодня все работают из под палки. Оттого и тяга к мелким порциям кода и частым проверкам.
Да и квалификация разработчика упала резко. Работают не специалисты в своей области с многолетним опытом, а пришлые варяги, часто нанятые на испытательные сроки и на небольшие экономные (для инвестора) зарплата.
Вот и торопится менеджер всех проверить, пока не уволил их. И требует проверок, чтоб потери были минимальными, а его личная прибыль — максимальна

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

В>Уже в какой раз про такое читаю. Как это ВООБЩЕ возможно?

ну вот есть же изречение про Haskell “Если оно компилируется, то оно скорее всего работает правильно”. Сейчас все языки идут к этому. Больше проверять на этапе компиляции. Вот есть люди, которые просто пишут код, не особо беспокоясь о работоспособности. Потому что знают, что на отладку уйдёт совсем немного времени.

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

В>И самое главное — зачем?

Да. Зачем такое. Инженер пишет клиента к апи от и до.
Неважно что в проекте половиина может никогда не понадобится.
Я вот склонен делать только нужное. Еще стараюсь чтобы удобно было. Хотя бы для меня.
Бывает что в ТЗ нет сортировки и программист ее делать не будет.
Но когда этим приходится периодически пользоваться думаешь как так то?

Здравствуйте, Ватакуси, Вы писали:
В>И самое главное — зачем?
Бывают огромное количество классов со ссылками на другие.
Невозможно протестировать код не создав все классы.
Да частично ты можешь посмотреть. Но проще сразу описать, а потом уже полностью тестировать. Были такие задачи

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

В>Уже в какой раз про такое читаю. Как это ВООБЩЕ возможно?
В>Во-первых, тебе нужно показывать результат почти каждый день, как правило.
В>Во-вторых, откуда известно, что ты пишешь что-то полезное? Может оно нафик не заработает в принципе?
В>В-третьих, эти тонны когда покрываются тестами потом, когда-нибудь? Или тесты тоже не запускаются?
В>И самое главное — зачем?

Чтоб результата достичь

Иногда это оправдано. Я помню, когда писал на ассемблере, мог неделю кодить даже не компилируя, потом софтина запускалась с первого раза и работала как надо.

Теоретически, если тебе нужно максимум отчетности, то надо постоянно показывать результат. Сделали крохотную вещь — докажи тестами.
Это значительно удлинняет работу, когда переделки значительные.

Фактически, можно сократить время, когда сначала экспериментируешь, возможно с откатами, а потом покрываешь тестами конечный результат.

В статически типизированом языке это вариант нормы. В динамически типизированом это сильный уклон в хаос.

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

В>Уже в какой раз про такое читаю. Как это ВООБЩЕ возможно?
А что в этом невозможного? Берёте бумагу, ручку и пишите код.

В>Во-первых, тебе нужно показывать результат почти каждый день, как правило.
Результат — это строчки кода.

В>Во-вторых, откуда известно, что ты пишешь что-то полезное? Может оно нафик не заработает в принципе?
т.е. код никто не читает? А если читают, то как оно может не заработать? Да ещё в принципе!?

В>В-третьих, эти тонны когда покрываются тестами потом, когда-нибудь? Или тесты тоже не запускаются?

Всё зависит от проекта, условий контракта, менеджмента и применяемого подхода к разработке.
Есть проекты, где 100% кода должно быть покрыто тестами, есть, где — 70%, а есть, где тестеры (менеджеры по качеству) проверяют не код, а работает продукт или нет.
Есть команды, где проводится код ревью, а есть — где такое не могут.
Есть проекты, где в принципе нечего показывать, кроме строчек кода.

В>И самое главное — зачем?
Причины могут быть разные: глубокая оптимизация может потребовать написания большого монолитного куска. Например, реализация B-Tree за день не пишется.
Причина может быть банальной: плата ещё не спаяна и запускать код не на чем.

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

В>Уже в какой раз про такое читаю. Как это ВООБЩЕ возможно?
В>Во-первых, тебе нужно показывать результат почти каждый день, как правило.
В>Во-вторых, откуда известно, что ты пишешь что-то полезное? Может оно нафик не заработает в принципе?
В>В-третьих, эти тонны когда покрываются тестами потом, когда-нибудь? Или тесты тоже не запускаются?

В>И самое главное — зачем?

Юго-Восточный проект (ЕВПОЧЯ). Один файл на 10..100К строчек. Копипаст на копипасте, но с вкраплениями разницы в логике. (Чисто чтоб не было скучно). Бизнес-логика в обработчиках UI — и это лучшее, что можно сказать о коде. Всё это надо отрефакторить, но отчётливо видно, что если достать из этого монолита из игровых костей любую, всё здание рухнет (как минимум, перестанет компилироваться). И начинаешь его переписывать, соблюдая предельную осторожность, ибо концов потом не найти. (Если кто-то скажет, что начал бы с написания тестов, я с таким даже разговаривать не буду, пусть сначала смузи на губах обсохнет). Запросто может неделя уйти, пока просто начнёт собираться, и ещё другая неделя, пока начнёт работать. На самом деле, и больше может.

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

В>Уже в какой раз про такое читаю. Как это ВООБЩЕ возможно?
В>И самое главное — зачем?

Было у меня такое в молодости. Когда кажется, что ты очень умный и никогда не ошибаешься, а инвестиции в стабильность кода — лишние траты времени.

Опыт показал обратное — косячу я много, а регулярное тестирование кода (или руками, или тесты) многократно окупается в будущем.

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

В>Во-первых, тебе нужно показывать результат почти каждый день, как правило.

Видимо не все работают в привычных тебе рамках.

В>Во-вторых, откуда известно, что ты пишешь что-то полезное? Может оно нафик не заработает в принципе?

Ну я, например, прекрасно знаю, как мой код работает, мне для этого не надо его запускать. Что значит "не заработает в принципе"? Это как так код надо писать, чтобы не быть уверенным, заработает ли оно в принципе?

В>В-третьих, эти тонны когда покрываются тестами потом, когда-нибудь? Или тесты тоже не запускаются?

Не все используют автотесты.

В>И самое главное — зачем?

Чтобы быстрей прийти к результату.

Здравствуйте, Географ, Вы писали:

Г>Почему-то раньше почти никого не надо было контролировать. Все работали из интереса и на совесть. Ну, почти все.
Нет.

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

LVV>С 1 курса вбиваем в головы студентов: писать малыми порциями и после написания малой порции запускать на проверку.

Забавно, а у нас на первом курсе наоборот вбивали в голову, что вначале нужно продумать логику от и до и только потом писать код. Даже были лабы, когда мы вначале писали код на листочке, а потом в конце обменивались листочками, вбивали код в компьютер и смотрели у кого заработает Про малые порции — это было уже позже.

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

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

В>Уже в какой раз про такое читаю. Как это ВООБЩЕ возможно?
В>Во-первых, тебе нужно показывать результат почти каждый день, как правило.
В>Во-вторых, откуда известно, что ты пишешь что-то полезное? Может оно нафик не заработает в принципе?
В>В-третьих, эти тонны когда покрываются тестами потом, когда-нибудь? Или тесты тоже не запускаются?

В>И самое главное — зачем?

- Продолжайте писать. Мы с вами свяжемся. ©

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

В>Уже в какой раз про такое читаю. Как это ВООБЩЕ возможно?

Как-то мы Nemerle переписали с SRE на DNLib. Так до полного переписывания его запустить было принципиально невозможно. Несомненно задача сложна, и если это возможно так лучше не делать. Но иногда нет другого выхода.

Другой раз как-то переписывали реализацию фич продукта (объектная модель определяющая доступность тех или иных фич продукта). В общей сложности поменялось несколько сотен файлов. А продукт — антивирус. Ты его локально хрен запустишь. Я только ПР заводил дней 5, так как все детали сборки и тесты можно отследить только на сборочном конвейере. В итоге сам ПР заезвез из отпуска, по RDP.

В>Во-первых, тебе нужно показывать результат почти каждый день, как правило.

Паранойя у начальства?

Вот я в том году писал фичу новую, а в этом ее переписывал под новый дизайн. Ну, раз в неделю показы.

В>Во-вторых, откуда известно, что ты пишешь что-то полезное? Может оно нафик не заработает в принципе?

Ну, ты же не идиот и понимаешь что делаешь? Когда можно написать мелкий кусок кода и его сразу же протестить — это хорошо. Но иногда это в принципе невозможно. И как-то надо жить.

В>В-третьих, эти тонны когда покрываются тестами потом, когда-нибудь? Или тесты тоже не запускаются?

Вообще есть еще "ручники". Основной процент багов выявляется при собственном тестировании и тестировании ручниками. Юинит-тесты и автотесты призваны скорее не выявлять баги, а выявлять регрессию и для интеграции разных компонентов (что вместе все работает). И за них приходится дорого платить, так как при масштабных изменениях они становятся гирями висящими на твоих ногах.

Тесты обычно уже есть. И при переписывании и рефакторинге они с одной стороны ловят ошибки (регрессию), а с другой мешают, так как часто просто запечатлевают неверную функциональность.

В>И самое главное — зачем?

Бывает — производственная необходимость (примеры таковой выше приведены). Есть идиоты, которые так живут исходно. В прочем, есть супер-аккуратные ребята, которые действительно могут писать простыни рабочего кода. Но скорее это исключение.