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

BFE>>Это ошибочный подход из-за "многопоточности". Файл в любой момент может быть удалён кем-то ещё, поэтому проверка что-либо до вызова функции не гарантирует, что в момент вызова функции файл всё ещё будет существовать.
L_G>"Ошибочность" вряд ли есть в предварительной проверке того, существовал ли файл вообще (или его "забыли" создать, или записали в другую папку и т.п. — т.е. в проверке на ошибки пользователя/интеграции/конфигурации/забывчивого программиста).

Я имел ввиду TOC/TOU

BFE>>Ага, я такую "экономию" не один год уже наблюдаю: коллектив переписывает одну и ту же функциональность в который раз. И каждый раз с ошибками отличными от предыдущей реализации. На каждом конкретном месяце экономия есть, а в целом — упущенная выгода. Впрочем это проблемы работодателя, а не работников.

L_G>Всегда остаётся вероятность, что YAGNI придумали идиоты и применение этого принципа в массовом индустриальном/энтерпрайзном программировании неоправдано. Но я в этот принцип почему-то поверил и даже широко применяю (видимо, потому, что я очень ленивый программист).

Вряд ли. Скорее методология должна соответствовать задаче. YAGNI не годится для V-Model, но подходит для agile. При этом сам agile не подходит для тех задач, где чёткие требования прописанные и подписанные в договоре, где V-Model — самое то.

L_G>BTW, рационально мыслящие программисты обычно практикуют не переписывание с нуля, а дописывание нового с одновременным рефакторингом старого (рефакторинга в рамках необходимого для того, чтобы новое вписалось органично, а не в виде костылей). Думается, тем коллективом двигало как раз то самое хорошо знакомое тебе стремление сделать программирование интересным.
Не, большинство выбирает ехать, а не шашечки и как следствие частые аварии ведущие к костылям.