Поглядите какая тут архитектура — вот тут мы выделили в отдельный сервер логирование, тут у нас развязка которая позволяет легко подменять БД, тут мы применили шаблоны — декоратор, мост и фасад. Плюс, у нас для всех классов выведены отдельно интерфейсы и только от них уже наследуются классы, плюс все у нас построено по MVC, все это само собой настроено поверх распоследего framework’а и заточенно под распределенное выполнение. Правда красота?
Э…. Позвольте, и вся эта хренотень вам нужна для того, чтобы показать пользователю Hello World? Может быть очень крутой и расширяемый, но именно Hello World?
Так вот, товарищи, КОД — ЭТО ЗЛО. Больше кода — больше возможных ошибок, сложнее читать код и понимать, что же он конкретно делает, больше зависимостей, больше документации, больше диаграм, больше принятых решений как делать и в конечном итоге больше денег потраченных на реализацию функциональности.
Пишите меньше и наступит вам счастье.
Я бы сказал быдлокод зло. А когда человек грамотно владеет паттернами проектирования и умеет работать с фрейворками, как правило код автоматически получается меньше и понятнее.
Конечно, для hello word, писать объектно-ориентированный код нет смысла, но в больших проектах без этого далеко не уплывешь.
Большие проекты типа Linux kernel?
Наверное в этом и состоит суть «быдла» и его кода. Оно всегда считает свой проект большим, пишет его на объектно-ориентированном языке, добавляет фреймворки (пару штук для верности) и делает его большим. Как результат Hello World на ООЯ с фреймворками.
Все остальное на говнокоде (рано или поздно).
В том то и проблема, что «умеет работать с фрейворками» не эквивалентно «применяет фрейморки, только когда это необходимо».
И дело тут как раз не в быдлокоде (который объективно плох), а в преувеличенной концентрации на _правильном_ написании кода.
Так шаблонами и фреймворками как раз и пользуются для того, чтобы в конечном итоге писать меньше кода 🙂
Отлично. Но нельзя путать инструмент с решаемой задачей.
Фрейморк и паттерны — это инструмент, иногда они подходят для уменьшения кода, иногда нет.
Проблема, что большое количество (даже неплохих программистов) считают этот инструмент единственный и всегда правильным.
Нема срібних куль. І які б інструменти не взяти, завжди доведеться щось дописувати, налаштовувати і пристосовувати до конкретної задачі. І не факт, що використавши готові частини система вийде простішою і надійнішою, ніж розроблена ad hoc. Я проти категоричності, але за золоту середину.
А кодування — це не зло, а кайф. Всі FPS, RPG, стратегії і рогалі разом узяті — це дитячі забавки у порівнянні з кодуванням.
По поводу первого абзаца — согласен на 100%.
По поводу второго. Да, никто же не говорил, что программирование — это зло 🙂 Для тех кто им увлекается — это действительно кайф.
Применение фасада намекает, что меньше кода уже написали 🙂
Действительно, применение шаблонов или другой «волшебной палочки» не означает уменьшение кода, тут главное вовремя остановиться и не написать больше или не так.
Но применение шаблонов все-таки гарантирует какое-никакое качество, хотя бы наличие структуры. О диаграммах я и не говорю.
Пусть уж лучше пишут больше, но со структурой, в которой можно разобраться, чем наоборот. Размер кода зависит не столько от технологий, сколько от опытности разработчиков. Написание минимального кода требует большого опыта, большего чем, например, требуется для применения шаблонов. Слишком много факторов.
Мне кажется, до написания хорошего, короткого кода разработчик проходит несколько стадий:
«Написание велосипедов», когда еще знание языка, среды и библиотек зачаточное, море кода, все тормозит. Попытки непрерывной оптимизации по скорости, что приводит к полному запутыванию.
«Немного опыта», когда уже есть умение применять написанное другими, появляется понимание, что лучше взять готовое, чем писать самому, пусть и более оптимально. Кода меньше, какая-то структура уже просматривается. Попытки писать как можно больше универсальный код, попытки рефакторинга.
«Опытный программист» — знакомство с паттернами на этом или даже предыдущем этапе, бездумное их применение. Длина методов уменьшается, но про общую длину кода это сказать трудно. Структура есть, но запутанная. Довлеет идеология «надо делать как можно универсальнее, чтобы потом не пришлось переписывать». Переписывание между тем требуется постоянно.
«Разработчик». Вот тут уже можно надеятся на короткий код. Оценка структуры кода, понимание, что шаблоны — это всего лишь руководство к действию, и могут выглядеть совсем не так как описаны. Оптимизация практически отсутствует за не особой надобностью. Пишется минимально то, что нужно, иногда расширяется по потребностям.
Можно писать и далее, но все дело в том что разработчики в большинстве своем это вторая и третья стадии, в лучшем случае. Так что не надейтесь.
Да, собственно говоря статья именно для «опытных программистов». Они чаще всего путают средство (паттерны, фрейворки) с целью (простым и понятным кодом).
Во всем согласен, единственное небольшое замечание. На уровне велосипеда, чаще всего разработчики еще не думают об оптимизации.
Ну почему не задумываются. Поневоле задумаешься, когда все тормозит. Мне кажется, именно здесь наступают первые попытки оптимизации, именно попытки.
Это скорее я упустил нулевой этап «оно работает!». Встречается редко, зато беспощаден. Сопровождаться код может только своим создателем и чрезвычайно трудозатратно.
Недавно познакомился с таким. Куча кода, и он даже работает. Но единственное, что с ним можно сделать — немедленно выкинуть.
Возможны, вы просто столкнулись с задачами, которые могли тормозить. Я и большинство знакомых, которые начинали — чаще всего работали над задачами, которые не слишком критичны по времени.
Ну условно говоря — хранилка паролей. Ее очень тяжело написать так, чтобы она тормозила, даже при всем желании.
Скорее, то что я видел — есть куча кода, который еле живет и при исправлении одной ошибки, вылезают три других. И действительно — можно (и нужно) немедленно выкинуть.
Я так понимаю претензия на количество потраченных денег.
В моем понимании заметка «пишите меньше — я вам буду платить меньше и вы будите счастливы» призывает наоборот писать код массивнее.
Выводы которые сделает разработчик:
+ если я буду писать больше документации я буду получать больше денег;
+ если я буду писать больше документации я буду писать проект дольше;
+ если я буду писать больше кода я стану нужнее для компании;
+ если я буду писать больше кода я буду получать больше денег;
+ если я буду писать больше кода я буду писать проект дольше;
+ если я буду писать больше кода я буду писать больше документации;
+ если я буду рисовать диаграммы я буду писать больше кода;
+ если я не буду рисовать диаграммы я буду писать больше кода и потом к нему диаграммы;
А все потому, что КОД – ЭТО ЗЛО. Надо было сначала подумать.
Если мы говорим о ЗП, то хоть более массивный, хотть менее массивный код писать — зарплата все равно таже.
Это о заметке (о призыве в ней если точнее), а не о ЗП.
И призыва никакого не было.
Это просто констатация факта, что чем больше кода (при прочих равных) — тем больше проблем. Соответственно, код — это зло.
Ладно… Намек не прокатил. Идем с другой стороны.
Что лучше для писателя на коболе: закончить писать проект завтра и уволится или закончить проект после смерти?
Э… Не совсем понимаю к чему это.
С трудом представляю, как можно закончить проект после сметри. Так, что я бы выбрал пожалуй вариант «закончить проект завтра и уволиться».
первый этап решения любой задачи — это упрощение самой задачи )
конечно! а ещё требования — зло редкостное! ну а от конечного пользователя, однозначно, только вред!! 😉
только вот иногда таким smart-кодерам, которым архитектура не нужна, руки хочется оторвать по самые колени, а некоторые из них и сами с собой такое готовы сделать, заглянув в свой недокументированный, недодуманный, нарасширяемый и вообще никому (даже себе) непонятный код… — так что есть и пара слов «за» значимость архитектуры — http://blogs.msdn.com/b/sorlik/archive/2010/04/30/10005090.aspx.
P.s. а начинать учиться грамотно проектировать как раз и надо с hello world, а не с заказчика….
Сначала проясню свою позицию, а потом отвечу критикой на критику.
Моя позиция следующая — написание без продумывания вообще — это плохо и это делают неумелые разработчкики. Написание с попыткой продумать вперед слишком много — это тоже плохо и этим страдают более опытные разработчики.
Если проект можно сделать вдвое меньшим количеством кода с теми же временными затратами, то вероятней всего — это предпочтительно, даже если расширяемость проекта ухудшится. Заранее редко известно в какую сторону начнет расти система и поэтому выгоднее в нужный момент проводить рефакторинг и добавлять возможность расширения в нужную сторону, чем заранее со всех сторон навешивать расширяемость.
>конечно! а ещё требования – зло редкостное! ну а от конечного пользователя, однозначно, >только вред!!
В конечном счете, с бизнес точки зрения — единственный НЕ ВРЕД — это деньги, если количество денег можно делать столько же имея меньше требований, меньше пользователей и меньше кода — это плюс.
Спасибо за разъяснение идеи.
Безусловно, абсолюта не существует, и бездумное применение паттернов в той или иной форме — зло, с этим сложно не согласиться ))) спектр проблем достаточно большой — с одной стороны слепое доверие и возведение в абсолют паттернов, с другой — полное отсутствие применения архитектурных практик. истина где-то посередине и, конечно, зависит от проекта. В первоначальном прочтении самого поста я увидел отрицание необходимости архитектурного анализа. Сейчас контекст прояснился ))) а нсчет того, что измеритель — он один и всегда необходимо оставаться прагматиком — это факт. Который, к сожалению, многие в силу своей увлечённости технологиями, не понимают и не принимают…
Думаю, на этом мы сойдемся 🙂
Размышления непрограммиста — аналогии этим вещам можно найти просто на этапе продумывания идей. Хочешь описать проект, и каждая мысль, каждый тезис неконтролируемо разрастается, т.к. хочется довести их до полной абстракции; доводишь и даже через длительное время умудряешься выстроить цельную структуру, а когда её выстроил, выясняется, что второстепенное оказывается основным, надо полностью всё переписывать и лучше б сразу сделал упор на описание цельной структуры, хотя бы минимальной, а потом уже расписывал и доводил части. С другой стороны, в процессе подробного расписывания частей непредсказуемо рождаются идеи, определяющие дальнейшее направление развития. И вот описываешь конечный результат вроде бы логично, но всё вместе оказывается слишком большим и нечитабельным и никому не понятным, нужен другой подход, теперь уже чтобы объяснить это другим, и т. д и т. п. В итоге моя статья Кодирование без кода http://vrus.habrahabr.ru/blog/94902/ — это не конечный результат, это одна из частей..
Насчет «кодирования без» кода. Я в него не верю. Идее уже добрых лет 20. В целом даже есть кое-какие продвижения. Но как только что-то становится чуть более сложным, чем «Телефонная книга содержит карточки, карточка содежит имя, телефон и адрес», то все это перестает работать.
Оглядываясь назад, фактически не одна программа (кроме пару институтских проектов), которую я разработывал вписывается в это.
То, что я вижу, что скорее будут разрабатываться высокоуровневые библиотеки для обычных языков программирования, которая будут облегчать написание кода а-ля «Объекты, связи и т.п.».
Практически полностью согласен — абстракция с одной стороны означает упрощение, но с другой стороны это же упрощение обернётся усложнением, если нужно описать что-то сложное.
Но есть нюанс — в «кодировании без кода» я не предлагал полноценную альтернативу традиционным языкам программирования, а ориентировался на массового среднего пользователя сети, который по-определению не занимается ничем более сложным, чем «телефонная книга содержит карточки… «. Модель объекты-связи скорее позволяет делать то, что люди приыкли делать в интернете — общаться, генерировать контент, распределять права доступа. Но она позволяет делать это вне ограничений форматов и функционала, которые задает каждый конкретный сервис, более гибко настраивать среду под себя. Программирование в данном случае — не более чем некоторое расширение возможностей, включающих в себя обычные вещи типа общения, чуть менее обычные типа структурирования контента, плюс какие-то примитивные формы, похожие на традиционное программирование.
Т.е. можно сказать, что я нашел правильную аудиторию для тех 20-летней давности идей программирования, которые не могут реализоваться собственно в профессиоанльном программировании.
Т.е. все wiki являются «кодированием без кода»?
Как по мне так это подход «мы напишем программы, вы введете данные».Он же старый (насколько?) совет о вынесении данных из кода.
Его сейчас очень полюбили авторы соц. сетей и блогов.
Программирование без «кода» давно исследуется в наших вузах с попыткой создать нечто само разрабатывающее программы из «вопросов и ответов» разработчиков.
А еще раньше оно породило функциональное программирование.
Наверное мы о разном. Если речь о веб-приложениях, то создать например соцсеть, блог или форум означает по-разному «запрограммировать» социальные взаимодействия пользователей. В этом плане традиционное программирование этих вещей выглядит аналогом низкоуровневого программирования в «машинном коде», когда «социальный программист» вынужден вдаваться в технические подробности или нанимать технических программистов. На сегодняшний день имеется два варианта — дать пользователям-нетехникам готовые форматы, возможность создания своего блога, форума или соцсети — по этому пути сейчас и идут, либо мой вариант — дать пользователям довольно простую абстракцию из объектов и связей, из чего они при желании смогут «программировать» различные формы социальных взаимодействий, не вдаваясь в технические подробности.
1 в 1 база друпала.
Зайду с другой стороны. Если взять некий рабочий код, убрать из него все данные (и заставить читать извне), получится некий код который управляется данными. Если эти данные будут обладать указаными в статье свойствать получится «программирование без программирования».
А теперь если взять любой wiki-проект получается тоже самое. Данные, коментарии и только защита ограничена.
Взять соц.сеть: данные, коментарии и защита. Зато взаимодействие ограничего.
А на самом то деле программирование не убрано, а лишь засунуто подальше.
PS: раз идея авторская предлагаю автору самому решать, что он будет считать подтверждением своей теории.
Как-то могу понять первый абзац, не очень понимаю второго (и как он связан с первым) и в принципе мог бы понять третий, если б понимал как он связан с первыми двумя. Может взять не любой вики-проект, а какой-то конкретный? Я обычно Википедию с разных сторон обсмаковываю. А какое взаимодействие ограничено в соцсети?
Пока понятно, чтобы пользователи что-то делали, нужно сделать сервис путем традиционного программирования. Естественно, оно никуда не девается.
С друпалом есть некоторые разницы. Например друпал — это не сервис, куда можно зайти и начать общаться путем создания объектов-постов, связанных определенной связью с объектами-откликами.
Первый обзац о друпале изнутри. В нем база реализована таким образом. Есть объекты и у них есть нужные характеристики. Если нужен какой-то особенный блок то его приходится писать.
Все остальное это взятие уже готовых блоков и работа с ними.
Да согласен что друпал это не сервис, но это не значит, что создать свое «уникальное произведение» там нельзя.
2 раскрывает историю и суть идеи. Если коротко: идея — это насоздавать много контролов (кода) и дать возможность их поразному тасовать.
Вики-проект. Возьмем библу и спроектируем ее на вики. Есть пользватели и книги (пространства). У каждого пользователя есть на странице читал, хочу прочитать и тд. В подстраницах каждого пользователя он создает рицензии (называние книги — название подстраницы). Спец. бот заносит эту информацию в статьи книг. На страницах обсуждения находятся коментарии. Зарабатывать можно продавая книги через реферальные ссылки (правда сомнительно).
Соц. сети на целены на общение людей, а не на создание полезного контента. По этому создать там сервис типа продажа-покупка недвижимости довольно сложно. Тем более сложно с оформлением заказов, покупкой и т.д.
Не ну наверно можно адаптировать друпал к разным штукам. Вопрос, во-первых, в том, насколько это способен сделать обычный пользователь, который допустим разбирается в недвижимости и знает что должно быть на сайте по недвижимости и совсем не разбирается в технике, даже в друпале. А во-вторых среда объектов-связей, она общая, что создает всякие дополнительные эффекты. Например, не нужно создавать какие-то объекты — допустим, их уже создали пользователи для других целей. Легче продвигать, т.к. релевантная аудитория уже тусит в теме недвижимости..
То, что я вижу, что людям нужно гораздо больше, чем “телефонная книга содержит карточки… “. Как только эта функциональность реализована, сразу становится необходима — интеграция с Skype, Outlook и Facebook. Поддержка вставления картинок только что снятых с камеры в виде аватаров и т.п. И оказывается, что все «вкусности» находятся далеко за границами «кодирования без кода».
Все вкусности — это преувеличение. Среда объектов-связей обладает потенциалом, трудно заранее предсказать все её вкусности. Часть из них я описывал в блоге. Тем более, повторюсь, я не предлагаю альтернативу существующему. Просто некий еще один сервис из многих, где реализован (пока гипотетически) вот такой малоопробованный подход.
Кроме того, ничто не мешает традиционными средствами делать для этого сервиса интеграцию с прочими сервисами.
Идею понял.
Я просто не слишком в нее верю. Уж очень мне это напоминает космическую архитектуру (http://victorronin.com/2009/06/22/kosmicheskie-arxitektory/)
Насчет космической архитектуры соглашусь, пожалуй. Возможно, на этапе обкатки самой идеи это может быть оправдано. Либо лично я к этому склонен 🙂
Кстати, отчасти подход возник из той посылки, что интернет-сервисы нужно развивать, чутко реагируя на реакцию пользователей. Временами она диктует наиболее жирное направление развития, которое даже «космические архитекторы» не могут предусмотреть. Отсюда возникла космическая-в-законе идея изначально сделать сервис с максимальными возможностями для пользовательских экспериментов, не превращая всё это во что-то межгалактическое и заведомо нереализуемое. Единственной подходящей для этой цели концепцией оказалась модель объекты-связи по причине её минимализма и простоты.
С тех пор я с разных сторон обыгрываю эту тематику, извлекая из неё всякие интересности. Одна из моих любимых интересностей — это аналогии со всякими концептами ООП, типа инкапсуляции. Мне поэтому очень интересно обсуждать эти вещи с программистами, но обычно им со мной не так же интересно, т.к. я не программист )) Так что спасибо вам за беседу )
Добавлю еще одну вещь. Как мне кажется обычно удачные (с финансовой стороны) проекты решают одну задачу очень хорошо, чем широкий спектр задач средне.
Мне кажется, что у вас скорее второй тип проблем («сервис с максимальными возможностями для пользовательских экспериментов»).
Собственно говоря. Опишите, зачем мне такой серсив. Какую конкретно проблему он призван решать. Какая конкретно моя головная боль, которую я не могу решить (или могу решить, но с сложностями) будет решаться проще.
То есть, все таки в определенный момент с космических высот нужно таки спуститься на землю и ткнуть пальцем, зачем это нужно.
Ну, для этого мой блог более подойдет )) И конкретные посты в нем. Но если хотите,
На «бытовом» уровне сервис решает проблему систематизации нарабатываемого пользователем контента. Сейчас для этого существуют в основном десктопные или полудесктопные приложения вроде TheBrain, совсем не имеющие вид классического веб-сервиса.
В другом аспекте сервис призван решать задачу вашей социальной самореализации. Каким образом? — доминанта заключена не в возможности общения с помощью модели объекты-связи (хотя контент легче генерировать и совершенствовать в процессе общения) и не в делании проектов путём «упрощенного программирования» (хотя иногда это надо, например, если не устраивают правила приватности в каком-нибудь Фейсбуке, или хочется обсудить пост в Википедии, а модераторы не дают или функционал не позволяет). Доминанта этого сервиса — в вики-структурировании контента.
Например, вы высказали тезис и позиционировали его как тезис (так определили тип объекта). Этот объект одновременно связан с вашим (блогом, персональным пространством, конкретной дискуссией, бог знает чем, пока не важно), потому что вы его так связали, и одновременно он связан с определенной темой (которая не ваша, она вики), потому что вы его свяжете с этой темой (вам это будет выгодно — см. далее). Если до вас никто ничего по этой теме никогда не высказывал, вы будете первым, будете в топе, остальные смогут только что-то добавить, доразвить, обсудить, аргументировать, но не повторить. Мой тезис в том, что среда, подавляющая повторения, обеспечивает максимальный объем релевантной аудитории. (На самом деле именно по этому принципу развивается наука и технологии). В любой дискуссии могут быть миллионы однотипных мнений, но очень небольшой набор различных аргументов. Типизация объектов на «мнения» и «аргументы», опять же, регулирует уровень внимания аудитории. Если чел способен добавлять что-то к сказанному до него, это работает на его самореализацию.
Что-то в этом роде.
Хорошо. Это не сервис, а метод структурирования данных. Так сказать замена вики.
Осталось услышать как этот сервис будет обеспечивать информирование всех обо всем (например, что Поповы не изобретали ни радио, ни линукс)? И как он будет выявлять определять подлинность аргументов (пример, снимки вируса ВИЧ, извините за тавтологию)?
Так что предлагаю закончить обсуждение о подготовить прототип.
Совместное структурирование, оно же вики. Если под вики понимать совместную работу над чем-то общим. Подлинность аргументов? Если чел под видом аргумента скажет глупость про линукс в сообществе линуксоидов, его социальный статус в этом сообществе упадет. В среде этого сервиса могут быть альтернативные сообщества линуксоидов, но не будет альтернативных тем про линукс. Т.е. абсолютно всё относящееся к линуксу будет попадать в «черную дыру» с меткой «линукс». И так по любой тематике. Внутри этой области в любом случае релевантность аудитории выше и говорить там глупости не выгодно.
Для прототипа я еще не вполне исписался в плане ясности понимания идеи. Хотел еще пару постов. Но вот как компромисный и менее масштабный вариант: http://startuppoint.ru/blog/startup-ideas/29081.html Не желаете попробовать?
Скажем коротко, суть сервиса — структурирование 2.0. А уже из структурирования следуют разные вещи. В частности, суть любого сетевого сервиса состоит в структурировании ресурсов (это мой тезис). В установлении каналов взаимосвязей между разными типами ресурсов.
Поэтому даже трудно сказать, в чем актуальность, поскольку она во всём ))
Горлов и Попов конечно круто, но боюсь не ваш уровень. О вас не напишут на лурке.
Зато в бюллетени комиссии по борьбе с лженаукой можете попасть (наверное придется проплатить публикацию в каком-нибудь научном журнале, а не писать на хабре).
Лучше пишите прототипы или рисуйте схемы. Написание псевдонаучных статей понимания не принесет, как и толковых сторонников.
PS: спасибо за очередное предложение бесплатной работы, но нет.
PPS: Наверное этот тред стоит почистить.
По правде самому уже охота приступить к прототипу. Программированием тоже видимо придется заняться самому. Фигли ж поделаешь? Другого выхода нет. Но пару псевдонаучных статей всё равно напишу 🙂
Ага. Теперь понял лучше.
Задумка забавная. Кстати, я ее несколько раз уже видел (не помню где).
Если когда-нить вспомните или увидите, кинете ссыль куда-нить в личку будь ласка?
Определенные проекты мне попадались, которые вышли и которые пока не вышли. Они родственны по использованию объектов-связей, но буквально тех же задумок всё же пока не встречал.
это все верно если ты пишешь что-то маленькое. для своего стартапа мы именно так и поступаем. а вот писать код винды таким способом это самоубийство. не стоит делать обобщений — это не выглядят умно 🙂 (сорри за нравоучение)
Напомню, что Window’ы тоже не сразу строился.
Код Windows 1.0 был откровенно небольшим.
Естественно если ЗАРАНЕЕ (это ключевое слово) известны требования системы. И именно из этих требований имеет смысл применять все вышеописанное — то тогда таки нужно применять.
Но вот применять наперед, в надежде на то, что система вырастет или потому, что в книжки так написано — глупо и невыгодно.
я и говорю — разные вещи смешаны и обобщены. я говорю про код современный, а не лохматый. сейчас в виндоуз азур пришлось полностью переделать те компоненты, где никто не страдал архитектурой, и понадобился только легкий рефакторинг для тех, что были хорошо задизайнены. при это требования системы естественно заранее были не известны — это не заказной проект. система меняется кардинально. еще пример — делали СДК потратили порядка 20 митингов и полутора месяцев что бы задизайнить два класса. зато теперь все идет как по маслу уде в Nной версии.
в общем нет правильных мыслей по этому поводу, каждый проект разный. и еще одно соображение — это как указатели в С++, кому-то дано, а кому-то нет. от природы. мы когда потора месяца сидели — было чувство что найдем решение. к тому же прогаммисты тоже люди и хотят творить, а не кодить (иначе они уйдут в другое место). у меня есть друг котороый в простых местах тааааакое городил на патернах и прочем. я вначале посмеивался, а он приобрел опыт офигенный и теперь пишет короткий лаконичный код используя все свою артилерию только по делу — очень солидно выгрядит. но потребовались эти мостропроекты что бы научиться
По пунктам.
а) Windows по своему размеру/требованиям исключительный проект. Большинство программистов работают на меньших проектах.
б) Согласен, что идеального решения нет. Но при прочих равных условиях, в абсолютно большинстве ситуаций — меньше кода — меньше проблем.
в) По поводу друга который городил. Есть такой анекдот насчет «Ты то гол забил, а Вася утонул» (http://ohda.ru/category/11/10). Может он и огреб опыта, а все окружающие вокруг него огребли проблем.
Привычка часто понемногу рефакторить избавляет от желания наваять излишеств «на всякий». А в проектах, где количество программистов фиксированно, есть смысл вообще торговаться за функционал. Типа «да, мы добавим эту фичу. но тогда уберём эту».
Согласен.