Где-то в степиsphinx_mv,
честно сказать не убедительно.
1 Зачем вы приплели сюда заказчика,тут обсуждается принцип кодинга.
Заказчик тут не причем, более того, общение программист и заказчика противопоказано, ибо заказчики в половине своей
долбоёбы чистой воды и это травмирует интеллектуальный психику пр-а, и плюс - хорошие пр-ы в себе циники и могут послать
нах заказчика ( и он уйдет к другому), по этому компании стараются всегда внедрять прослойку между п. и з.
- это ребята с стальными яйцами, которые могут терпеть бред заказчика и в тоже время заискивающе повизгивать ;'какое ох-е решение Вы придумали".
А вот Вы просто попытайтесь рассмотреть ситуацию, когда на крупном предприятии есть собственный отдел программных разработок... И в качестве "заказчика" выступает не какой-то посторонний "Вася Пупкин" из фирмы "Рога и Копыта", а непосредственно один из отделов предприятия, в котором для обеспечения очень конкретных производственных процессов крайне необходим определенный функционал. Расчитывать, что такой заказчик будет "повизгивать от удовольствия" в процессе развешивания лапши на ушах - не реально. Самое интересное во всем этом, что очень часто оказывается так, что этот "срочно нужный функционал" изначально планируется использовать очень ограниченное время...

Некоторое время в таких условиях, конечно, можно помурыжить "вот ту мы техзадание готовим", а "вот тут мы архитектуру модуля продумываем", "а сейчас мы пишем идеальный код" и все такое прочее... Проблема в том, что если весь этот процесс начнет по мнению "верхнего начальства" (которому, кстати, дополнительно "настучит" шеф отдела-заказчика) затягиваться (сроки определяются иногда с точностью до часов-минут), вопрос личного трудоустройства может стать крайне актуальным (и очень туманным в перспективе). Соответственно, "выкатывание" в работу временного, даже "абы как" написанного решения, которое просто обеспечивает требуемый функционал (с умеренным количеством ошибок и нареканий пользователей), с расчетом на то, что когда-нибудь этот код возможно будет улучшен, очень сильно демпфирует ситуацию.

Писать "правильно" - это, конечно, круто... Осталось только определить КАК это делать, когда сама задействованная инфраструктура представляет собой сложный комплекс программно-аппаратных средств, каждое из которых в отдельности заточено на выполнение определенной задачи (специфика, однако)... С учетом реально жесткой ограниченности ресурсов. И когда время - деньги в самом прямом и жестком смысле.

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

Вы очень повеселили вот этого вот дяденькуВы не поняли - этот дяденька смеется над Вами...
Синдром рефакторинга - известная программистская болезнь...

cooldevelopersphinx_mvА вот Вы просто попытайтесь рассмотреть ситуацию, когда на крупном предприятии есть собственный отдел программных разработок... И в качестве "заказчика" выступает не какой-то посторонний "Вася Пупкин" из фирмы "Рога и Копыта", а непосредственно один из отделов предприятия, в котором для обеспечения очень конкретных производственных процессов крайне необходим определенный функционал.
Уж тем более для своей компании писать "чтоб работало" не резонно. Как правило в таких компаниях более вменяемые сроки и лояльное руководство. Есть воля где можно архитектурно разгуляться.
1) Для своей компании нужно писать так, чтобы она в трубу не вылетела. Есть понимание, что делает и как работает конкретный участок кода? Если да - "ну, и фиг с ним" (с).
2) Лояльность руководства имеет границы.
3) Архитектурно разгуливаться можно только если нет других задач... И только когда есть четкое представление о том, что нужно изменить, на что это повлияет и как это вообще можно сделать при имеющихся ресурсах...
cooldevelopersphinx_mvНекоторое время в таких условиях, конечно, можно помурыжить "вот ту мы техзадание готовим", а "вот тут мы архитектуру модуля продумываем", "а сейчас мы пишем идеальный код" и все такое прочее...
А никто и не говорит, что нужно тянуть кота за яйца и что-то там мурыжить. Даже получив задачу с пинка можно её грамотно разложить по полочкам на колене без технических заданий и функциональных спецификаций. Главное, понимать предметную область и разбираться в производственных процессах.
Это все замечательные соображения. Только не имеющие никакого отношения к тому, получился в итоге лашекод или нет... Особенно - с учетом отсутствия "стандарного" представление о лапшекоде. Кому-то нравится, кто-то плюется...
Единственный объективный критерий - выполнение (или нет) некоторым кодом некоторой функции. Все остальное - лирика.
cooldevelopersphinx_mvПисать "правильно" - это, конечно, круто... Осталось только определить КАК это делать
Начнем с того, чтобы хотя бы не писать унылый лапшекод в обработчиках с логикой.Если "лапшекод в обработчиках с логикой" - достаточно эффективное решение, чтобы выполнить поставленную задачу, то имеено его и следует применить. Потом - если будет наобходимость, желание и ресурсы - код можно улучшить. Но можно и не улучшать.
"Кристальный код" не панацея. А рефакторинг - не самоцель.

Denis.sphinx_mv,

случаем, это не вы тот товарищ, который синглтон тут изобрел на досуге? Манера похожая.К "банде четырех" отношения не имею... Но если Вы про это - 14097324 , то не понимаю Вашего пренебрежения... Возможно, у Вас проявление страшного проффзаболевания - синдрома рефакторинга . В частности, симптом №1 (чужой код – г#$но)...

Вы действительно считаете, что подобного подход принципиально не применим?! А что так оптимистичненько?!
Ведь если его назвать "синглтоном", может, и нельзя (не обеспечивает строгого соответствия шаблону), то использовать в примерно такой ипостаси - почему бы и нет?! Случаи "в жЫзни" могут быть разные, и все варианты все равно не предусмотришь...

Где-то в степиsphinx_mv,
я не пойму, за что Вы ратуете, писать релизный код - а бы работало, потом подправим ежели что.
Если так, так это это принцип подмастерья он к производству качественного продукта не относится. Качество программного обеспечения
Качество программного обеспечения — характеристика программного обеспечения (ПО) как степени его соответствия требованиям. При этом требования могут трактоваться довольно широко, что порождает целый ряд независимых определений понятия. Чаще всего используется определение ISO 9001, согласно которому качество есть "степень соответствия присущих характеристик требованиям" .Есть требования к функционалу... И есть продукт, которыи полностью соотвествует этим требования... Ну, собственно, и все...
Любые не-функциональные критерии (наподобии "внутренней красоты кода") не нормируются и потому приниматься в качестве объективного критерия не могут...
Где-то в степиХотя чему удивляться, вся экономика России на этом построена.А только ли России?
Но обсуждение этого уже совсем за пределами топика...

ЕвгенийВПрограммирование - процесс творческий, а творчество не терпит жестких рамок, в которые ставят программиста. В большинстве случаев ему дается указание архитектором(тим лидом) нагромоздить таких то классов, применить такие то паттерны и сделать за такое то время. В результате получается нечто, работающее не совсем так как надо и не так быстро, как хотелось бы. Если еще приходиться интегрироваться с кем то, то они вполне в определенный момент могут перестать выдавать то, без чего тебе никак нельзя или наоборот запросто так, нечто, на получение чего ты до этого истратил кучу времени и сил.Навеяло...
Была история... В конторе готовились к запуску новой группы сервисов с использованием "хардварного" решения от одного из "сторонних" поставщиков... Уже была назначена дата, коммерсанты с клиентами уже начали вести "работу по окучиванию" (контракты, проплата, етц).
В процессе тестирования выяснилось, что текущая версия "железа" не обеспечивает всего необходимого функционала (хотя по документации - "все пучком") и нужно менять прошивку, которую поставщик должен был за несколько месяцев закончить, но еще не успел... В общем, повезло - за неделю до "взлета" прошивка пришла, начали на стенде прогонять... В результате "повылазило", что данные с этой хрени начали приходить а) в другой последовательности и б) в другом формате... Сроки никто отменять уже не мог - светили неслабые потери (и не только по репутации)... И тут на "архитектурность" решения уже никто не смотрел - оно просто должно было заработать строго во время "Ч"... Ну, в-общем, оно и заработало... Только "Семь самураев" нервно курили в сторонке...

Архитектура... Шаблоны... Хочется!!! Вот только бизнесу, по большому счету, на это плевать с самой высокой колокольни - "сколько новых денег мы на этом заработаем?"
Кричите "говнокод!.. говнокод!.." А вот выйдите "в чисто поле да с шашкой наголо", и попробуйте не наговнокодить в таких условиях - тогда и поговорим, кто тут программист, а кто - так, мимо проходил...

ЕвгенийВsphinx_mvК "банде четырех" отношения не имею...
Повезло! А то могли бы и расстрелять !
Не те, а эти ...

Где-то в степиsphinx_mv,
Интересно вы соскакиваете
Вам показалось.
Где-то в степия вам про Фому
авторСоответственно, "выкатывание" в работу временного, даже "абы как" написанного решения которое , просто обеспечивает требуемый функционал (с умеренным количеством ошибок и нареканий пользователей), с расчетом на то, что когда-нибудь этот код возможно будет улучшен, очень сильно демпфирует ситуацию.
Вы мне про Ерему
авторКачество программного обеспечения — характеристика программного обеспечения (ПО) как степени его соответствия требованиям. При этом требования могут трактоваться довольно широко, что порождает целый ряд независимых определений понятия. Чаще всего используется определение ISO 9001, согласно которому качество есть " степень соответствия присущих характеристик требованиям ".
и даже тынц, что Вы дали, ну ни как с моего имха не идет с вашим подходом, скорее вразрез ((Объективный критерий качества - наличие функциональной спецификации на продукт и наличие продукта, соответствующего этой спецификации. Ключевые моменты в обоих цитатах выделены. Что не так?

Может, Вас смущает "с умеренным количеством ошибок и нареканий пользователей"? Ну, так это тоже вполне нормально - любой "лапшекод" может быть (при желании) оттестирован. Несколько сложнее и долше...

И повторюсь еще раз: нефункциональных объективных критериев качества кода на основе его "чистоты" и прочих ненормируемых критериях не существует. Что есть "лапшекод"? Нет и не может быть однозначного ответа! У каждого отдельно взятого программиста, в каждой отдельно взятой комманде разработчиков это вообще разные понятия!