Средства и методы разработки

Да сколько угодно. Небольшой кусочек самоиронии насчёт мастшаба («человечество»), я вижу, прокатил за чистую монету :-D Но поскольку я, в отличие от, не свожу холивар к фаллометрии, мне как-то сравнение «я-вы» не столь важно, как что-то типа… …типа вот такого вот. Ну, раз уж начали рассуждать о Высоком, продолжим. Разумеется, приглашаются все желающие, хотя думаю, это и так очевидно и можно было даже не говорить. Допустим, нам надо сделать окошко, в котором пяток полей ввода, «ОК» и «Отмена». 1) Есть вариант зарегистрировать класс окна и самому всё там руками сделать — оконный цикл, приём событий и передача их в оконную функцию, сама оконная функция. 2) Есть вариант создать диалог — для него класс окна и цикл предоставляются системой, потому что случай настолько частый, что его ввели в API как стандартный. Первый вариант явно начинает отдавать велосипедом. 3) Есть вариант вообще дикий — вкопаться ещё глубже, написать кучу своих обработчиков и подменить ими стандартные средства API, то есть реализовать вариант 1, переписав руками готовую часть системы. Ультра-велосипед. 4) Можно за отдельные деньги купить вариант 4, написанный кем-то ещё. Многие торгуют своими говнонавёртками, с большим успехом. В данном случае красивости не входят в ТЗ, а говнонавёртка требует неоднократно связываться с разработчиком и требовать её «подтюнить», потому что где-то в ней что-то ещё не так. Вопрос: является ли вариант 4 «велосипедом»? Pro: это архитектурно такой же бред, как вариант 3, требует долгой отладки, как вариант 3, требует отдельных вложений, чтобы получить то, что и так у нас уже на руках. Contra: мы не сами писали, мы купили. И доотладку тоже купили. По сути, это вопрос о том, относится ли покупной «велосипед» (технически полностью эквивалентный!) к «велосипедам». А если не относится — то чем покупка «велосипеда» отличается от найма себе лишнего прогера, который его напишет.