Кто же все-таки прав или как убить в себе перфекциониста?

я часть той силы, что вечно хочет блага, но пишет быдлокод

Вот что доставляет изрядные боли в районе пятой чакры: с одной стороны мы имеем лагерь оголтелых евангелистов, которые орут «ООП людям!», «MVC всем!», «да прибудет с вами SCRUM» или «скажем НЕТ! хардкоду, костылям и прочему»; с другой стороны имеем, пожалуй даже больший по численности, лагерь людей, которые просто делают свою работу и говорят «быдлокод? Хм, зато это работает и приносит деньги мне и моей компании».

Я, конечно, не смогу сейчас доказать свои утверждения, но всё таки давайте попробуем разобраться.

Так вот. если бы мы смогли получить исходники крупнейших проектов, я уверен — там быдлокод. даже не так — БЫДЛОКОДИЩЕ! Google, Яндекс, Twitter, Skype, Apple, Microsoft, Facebook и Вконтакте и т.д. Критические вещи вроде алгоритмов гугла и яндекса, по понятным причинам, вылизаны до блеска. но всё остальное — ужас и кошмар.
Куда не пойди на собеседование — тебя прогонят по паттернам, измучают вопросами об ООП, спросят про хай лоад, спросят об оптимизации, накроют задачами по MySQL и на всякий случай уточнят знаешь ли ты что такое Agile и Scrum. И ты, будучи не самым плохим специалистом, допустим справишься. И вот ты приходишь в эту компанию на работу и что ты видишь? Хардкод, костыли и прочее. К тебе приставляют человека, который должен помочь тебе со входом в проект. И вот он тебе показывает всё, объясняет. примерно так: «мы хотели изначально сделать всё качественно. что бы и ООП, и MVC, и масштабируемо. но потом к нам пришёл дедлайн и поэтому у нас вот тут, тут и ещё вот здесь костыли накручены. но ты не думай — это всё временно. а пока нужно что бы оно работало». И в итоге эти костыли кочуют из одной мажорной версии в другую, обрастают всё новыми костылями. и везде же так.

Может быть, конечно, в том же Киеве, можно найти штук пять компаний, которые действительно пишут всё грамотно. я надеюсь, что этих компаний есть хотя бы пять. Им повезло с заказчиками, дедлайнами и бюджетами.

И вот вопрос: Кто же всё таки прав?
Сперва кажется что евангелисты. Ну потому что они декларируют как «правильно» работать. Как грамотно. И как лучше, пожалуй. А потом посмотришь на гигантов отрасли и понимаешь — их быдлокод приносит миллионы. Windows? Быдлокод с первых строк. Unix системы — да туда же. Вы только вчитайтесь в исходники. Mac OS? Подозреваю что так же, но выборку делать сложно — яблочные фанаты как правило столкнувшись с багом считают что так и нужно и баг этот благословил сам Джобс. А посему молча терпят и ждут апдейтов. Да всюду.

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

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

С одним убитым абстракционистом рождается новый овнокодер

Еще подумалось.

ТС, очевидно, ставит равенство «плохо» = «отсутствие ООП».

Чтобы разрушить психологическую инерцию от рекламы ООП, нужно посмотреть, а что делает бизнес в реальности на самом деле? Возьмем мобилки. Каждый объект имеет свой интерфейс зарядки, свой разъем на аксессуары, свой формат обмена данными, и так далее. Каждая следующая модель одного и того же производителя имеет, как правило, зарядку, не совпадающую по интерфейсу с предыдущей. Бизнесу не выгодно договариваться с конкурентами о едином стандарте. Европарламенту пришлось вмешаться и обязать производителей не загрязнять окружающую среду своими зарядками...

Возьмем автомобили. Запчасти. Продолжать?
Возьмем принтеры. Картриджы, и защита от картриждей от сторонних производителей и всяческие козни против реюзабэл имеющегося.

Патентные войны. Война за Реюзабэл?

Ну а в чем-то договорились? Вовсе нет. Тот, кто захватит рынок «более чем ровно наполовину», тот фактически диктует свой стандарт.

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

Везде в бизнесе работает правило «так выгоднее нам сейчас». Это входит в противоречие с интересами каждого, потому что не совпадает с правилом для общего «так лучше для общества».

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

нет, вот как раз «плохо» != «отсутствие ООП»
речь идёт о качестве кода как такового
скажем есть же разница между
for($i = 0; $i < count($array), $i++)
и

for($i = 0; $i < $count_array; $i++)

И где тут ООП?

перфекционизм вне ООП такая же реальность как секс в СССР,

шоб Вы там себе не думали))

А я думал что «тру» — это всякая функциональшина.

>> ORG100h

Вау! Неужели кто-то еще помнит про com файлы? :)

Что бы убить в себе перфекциониста надо сделать ВСЕ самостоятельно.

:)

Я изучаю программирование один год и вижу ситуацию так:

Плохой код появляется не потому, что он работает к дедлайну, а потому что те кто его пишут писать хороший не умеют.

Плохой код не может поддерживаться долго. Если речь идёт о проекте на несколько лет то никакой плохой код не продержится до конца. Компания скорее всего разорится к середине. Этому есть масса примеров и в прошлом и будет в настоящем. Подозреваю, что мгновенная гибель тысяч стартапов ежегодно также является следствием плохого кода и невозможности вносить изменения быстро, масштабировать от 1 до 10 пользователей без переписывания всей системы и т д.

Писать хороший код очень сложно. Для этого надо десять лет писать плохой код и понимать почему он плохой. А если вы десять лет пишите плохой код и не понимаете почему он плохой то шансов научиться писать хороший просто нет и любые попытки будут приводить к обрушению пятиэтажных фабрик (Которые сами по себе, скорее всего, являются быдлокодом под вывеской шаблонов. Мне пока не удалось встретить даже трёхэтажные)

Хороший код это не обязательно шаблоны. Это внимание к мелочам и профессионализм. А шаблоны это МНОГОКРАТНО И УСПЕШНО РАБОТАЮЩИЕ СТРУКТУРЫ. Их придумали и поддерживают те люди которые написали все языки программирования, все IDE и все ОС. Другие программисты, те которые за «просто работающий код» просто наверное не пишут книг. И если по какой то причине у вас обвалились какие-то шаблоны то скорее всего надо пробовать ещё раз и ещё раз и ещё раз.

Нет никакого перфекционизма, есть нормальное желание постоянного улучшения кода.

В тех книгах что я успел прочитать нигде не утверждается что применение ООП и шаблонов сделает ваше приложение идеальным. Там как раз написано совсем другое — вначале вы пишите как умеете (потому что по другому не умеете) а потом ПОСТОЯННО улучшаете свой код.

Вообще в стане «евангелистов» ООП и шаблонов все могут писать плохой код если их попросить, а вот в стане «работающего и нормально» кода мало кто может поручится за то, что код будет работать через год или после внесения изменений в требования.

Разумный подход это не использование повсеместно ООП и шаблонов, а СТРЕМЛЕНИЕ к этому.

И по поводу быдлокода в Microsoft или в Google — ну просто шклотизм какой-то.

КРИЧАТЬ ТО ЗАЧЕМ ?

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

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

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

ну я вообще-то про архитектурные вещи. интерфейс можно и снести если что не так, а вот в рамках CAP и даже ее «однопроцессорные» вариации при выборе скорости либо consistency ... или аналогичные качели ... тут все веселее

Не могу поддержать дискуссию, но интуитивно подозреваю, что если бы вы попытались все эти страшные слова реализовать с помощью «быдлокода» то весёлости было бы в сто раз больше.

ну другой вариант — даже супер «шаблонная» штука может быть по сути быдлокодом , особенно часто я это встречал в java «сообществе» — впринципе простые по функционалу вещи выглядят как решение всех проблем человечества, с мега-конфигом (обязательно в xml) и сотней классов , каждый из которых состоит из одной-двух функций — все вроде как «по науке», а пользоваться невозможно

Ну нет же. Шаблон это Проблема — Поиск Шаблона — Применение. Если у кого то была проблема в моделировании Покупателей или Пиццы, а он начал решать проблему моделирования ДНК то при чём здесь шаблоны?

Я понимаю наверное откуда такое пошло — программеры измученные своим и чужим быдлокодом берут книгу по шаблонам и своими замыленными глазами читают «Волшебная пилюля» хотя там на каждой странице написано «Бритва Оккама» и вместо моделирования Покупателей они начинают моделировать ДНК — Пилюля же. Хотя то что я прочитал во многих случаях таки очень Пилюля. Но в очень конкретных случаях, определение которых ещё та наверное задача.

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

Ну так я про это и написал. Резюмирую — плохой, но работающий код — это всё равно плохо и опасно; Надо приводить его к хорошему; Для этого надо быть опытным профессионалом.

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

Повторюсь качественный код это не обязательно Шаблоны ООП. Иногда это просто имена и отступы.

(лень — основа быдлокода, кстати)

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

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

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

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

Разумный подход это не использование повсеместно ООП и шаблонов, а СТРЕМЛЕНИЕ к этому.

И только тогда можно стать ЧЛЕНОМ клуба НАСТОЯЩИХ ООП программистов.

Нет ООП программистов. Есть хорошие — они используют когда надо шаблоны ООП, а есть остальные — они просто остальные.

БЫДЛОКОДИЩЕ! Google, Яндекс, Twitter, Skype, Apple, Microsoft, Facebook и Вконтакте и т.д.

Особенно мородкнига!

Чтобы убить в себе перфекциониста нужно сначала им стать! А когда ты не только имеешь понятия о ООП, S.O.L.I.D., MVC, рефакторингах и иже с ними, а и грамотно умеешь применять данные методики на практике и видишь результат, то убивать в себе перфекциониста рука не подымется, если ты конечно не самоубийца.

но иногда очень хочется, особенно если проект большой команда распределенная и ... та ... удаленная часть (и это не только индусы!!!) команды не просто быдлокодит — а состоит из

пожилого, опытного быдлокодера.

пожилого, опытного быдлокодера.
херт хренсен?

Когда «вот та новенькая красненькая машинка» слепит полировкой в глаза блондинки, приводя ее в восторг, то уж мы-то знаем, что в данном вопросе блондинка — не перфекционист. В перфекционизм подмешана здравая критика, всегда заставляющая заглянуть под капот. Взрослый перфекционизм это не злорадная критика «а у вас всё через ж...у», и не восторженное «а-бал-деть!» блондинки. По-взрослому, это мотивация к исследованию в целом, без пропуска мелочей, что повлечет следующую мотивацию — сделать лучше. Без цепочки этих мотиваций критикующий перфекционизм более всего похож на самолюбование в снобизме.

Допустим, Вы позаботитесь о красоте кода на _своем_ уровне абстракций. Однако, проваливаясь то и дело сквозь эти ваши абстракции (J.Spolsky©), рано или поздно окажемся у ассемблерщиков. А них есть грубоватое, но точное замечание на кем-то написанный тупой код: «похоже на высер компилятора». (извините) И вот так, проваливаясь вниз по кроличьей норе на абстракциях, наконец, понимаете, что Интел производит унылое г..., заточенное под привычки выбранного стиля программирования в Майкрософт. Тогда в поле зрения появляются Sparc и ARM. Но и на этом провалы не заканчиваются. Догадайтесь с одного раза, куда мы проваливаемся, не найдя ускользающий perfect и здесь?

Правильно. Архитектура ф.Неймана и фундаментальная математика.

Подвиснув в своей оценке на самом первом уровне, полированной красоты кода, написанного на занятном экземпляре из нынешнего зоопарка т.н. языков программирования, рискуем выглядеть дилетантом. И ни разу не перфекционистом.

----

Кстати, про утверждение из стартового сообщения: «Windows? Быдлокод с первых строк.» Для такого вывода строки или экраны кода не могут быть основанием. Нет быдлокода на этом уровне в Windows.

Я вообще сомневаюсь, что ТС знает, с чего начинается Windows...

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
BootSeg segment at 07c0h
BootSeg ends

DirSeg segment at 1000h
DirSeg ends

NtLdrSeg segment at 2000h
NtLdrSeg ends

BootCode  segment ;would like to use BootSeg here, but LINK flips its lid
ASSUME CS:BootCode,DS:NOTHING,ES:NOTHING,SS:NOTHING

public FATBOOT
FATBOOT proc  far

jmp   Start

; ... ;ConfigDATA

Start:
xor   ax,ax         
mov   ss,ax
mov   sp,7c00h

.386
push  BootSeg
.8086
pop   ds
assume DS:BootCode
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Ну это просто так, к слову...

первая же строчка Windows — JMP то бишь go to. топикстартер прав :)

кстати, коменты про LINK вставляют не по-детски :)

=))) Да, у John Vert с юмором всё в порядке, про LINK...

Frank Rubin «„GOTO Considered Harmful“ Considered Harmful».
Communications of the ACM 30, (March 1987).(PDF)
www.ecn.purdue.edu/...rubin87goto.pdf

Когда я вижу IF, и вспоминаю религиозную секту Дейкстры, то одновременно вспоминаю и цитату из к/ф:
... Видишь суслика?
— Нет.
— И я не вижу. А он есть!

=)

Для такого вывода строки или экраны кода не могут быть основанием. Нет быдлокода на этом уровне в Windows.

На этом уровне нет ещё и Windows :)

Ну как дети, ей-богу :)
Практически любой проект который пережил больше одного релиза развивается по синусоиде — сначала пишется все «как правильно» — что там было модно и правильно на момент написания, потом, когда евангелисты <s>свалили с деньгами</s> получили свою порцию обожания , внезапно выясняется что все эти 5 уровней абстрактых фабрик не дают необходимой производительности — за дело берутся реалисты, которые прочищают циклы, выкидывают нафик красивости, прикручивают так что то там жвачкой сбоку и оно начинает работать на порядок быстрее. Позже, когда дело доходит до новой версии и добавления функционала — новая команда хватается за голову — «да тут всю систему менять надо!» — рефакторит и «впихивает невпихуемое» в новую, по последней моде, парадигму, и так же в конце концов сваливает с новыми строками в резюме и чувством глубокого удовлетворения от «неимоверной красотишши» получившегося решения. Затем опять внезапно выясняется, что все это еле ворочается и нифига не масштабируется и процесс повторяется.
Все это совершенно нормально и вовсе не стоит рефлексировать по этому поводу, достаточно понимать на каком этапе мы с кодом сейчас находимся и делать соотвественно.

Не, ну все конечно слышали краем уха о супергероях-программистах 45 уровня, который пишут одновременно и производительный и красивый код, но это urban legend — все о них слышали но никто не встречал. Да чего там далеко ходить, у любого уважающего себя разработчика есть любимый кусок кода или целый проект, который был написан им лично и он именно что самый-самый — и красивый, и умный, и оптимальный, и все паттерны к месту — конфетка, а не код. С ним только одна маленькая проблема — если на этот код взглянуть месяцев эдак через 6, то становится очень стыдно и хочется немедленно все переписать. Так и живем.

Да, проблема эта и меня очень часто волнует.
Поначалу я благоговейно молчала и слушала, когда другие разглагольствовали об идеалах.
Потом сама начала.
Потом меня стало раздражать это разглагольствование, т.к. слишком часто оно сопровождено тем же быдлокодом, который переделывает обычно кто-то другой.
А теперь я уже к этому спокойно отношусь, т.к. решила наконец для себя этот вопрос. А решение следующее: если ты уверен, или подозреваешь, что твой код будет использоваться повторно, и не раз, ну либо просто есть время и хорошее настроение — пиши в лучших традициях. Если у тебя сомнения насчет того, что сюда скоро еще кто-то зайдет, времени особо нет, или та же лень, можно чуть и побыдлокодить — главное, чтобы работало.

Тут как и в обычной жизни — все хорошо в меру. Если ты, например, в магазин за хлебом вышел в тапочках и шапке — не беда. Хуже, если все уже пообедали без хлеба, а ты только оделся. Но вот если ты на свадьбу так пришел, то тут уж извините, беда:)

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

Нужно просто поставить себе нижнюю допустимую планку качества и стараться держать её любой ценой, ведь есть репутация и всё такое.

Делать сразу плохо != заработать много денег.
Надо делать хорошо, а плохо — оно само потом получится (под чутким руководством маркетинга.)
Автор начал статью со слов об евангелистах а продолжил о случае когда вас бросают поддерживать старый проект написанный на коленке. Золотая середина тут заключается в том, чтобы терпимо (толерантно) относиться к поддержке старых проектов (которые кстати вас кормят), но знать как сделать правильно — Вы просто обязаны.

И если вам доверили новый проект с нуля, не зависимо от масштаба и сроков писать код обращения к базе данных в логике представления — прямая дорога на пенсию.

Есть идеал, к которому нужно, но в меру, стремится, а есть реальная работа. А насколько придерживаться идеологии — это от объема проекта зависит. В маленьком и краткосрочном проекте вовсе можно забить на все паттерны и т.п., главное скорость разработки, а в постоянно развивающемся, крупно проекте — нужда в наработках, грамотной документации растет, потому что иначе он со временем станет не рентабельным. Везде надо искать золотую середину, иначе дела не будет.

А знать ООП и хайлоад и навороченные алгоритмы полезно по одной простой причине:

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

Кстати, не совсем понятно, чем «провинился» хайлоад. Как правило, возможность справляться с большой нагрузкой — это самое, что ни на есть, требование бизнеса, а не «хотелки» разработчиков.

То я за компанию его туда впихнул. Сейчас хайлоад как никогда актуален.

Хочу еще отдельно прокомментировать про технический долг. Долг — это, по сути, кредит. Когда предприниматель берет кредит в банке на развитие бизнеса, никого же это не смущает? Другое дело, что кредит ему/ей не дадут, если под этот кредит не будет правдоподобного бизнес-плана.

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

Поэтому, писать правильный или не очень код — это, на самом деле, бизнес-решение. Задача же разработчиков — грамотно объяснить бизнесу, что быдлокод — это кредит, и объяснить механизм набегания «процентов».

Не очень понятно, о каких именно евангелистах идет речь, когда технический долг приравнивается к абсолютному злу.

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

По моему наблюдению, чтобы программа получилась, она должна быть как минимум два раза полностью переписана. Другое дело, что в коммерческих проектах главная задача — быстро срубить бабло, а не получить продукт максимально высокого качества. Так что получили минимальную работоспостобность и быстренько выбрасываем продукт на рынок. А что багов полно, так это проблемы пользователей. Даже возможен дополнительный профит, плата за техподдержку и устранение багов.

Я бы сказал, что все очень сильно зависит от специфики бизнеса, для которого, собственно, делается проект. Если это стартап, для которого жизненно важно получить дешевое решение быстро — увы, быдлокод может быть единственным приемлемым вариантом. Пример — тот же Твиттер, который, если я не ошибаюсь, сначала быстренько слабали на Руби, раскрутились, и только потом, когда уперлись в проблемы масштабируемости, переписали на чем-то другом.

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

В этой теме нет горизонта, по крайней мере сейчас.
Причина проста — в программировании нет идеала. Оптимизировать, перестраивать, строить можно вечно. Просто каждый (ну может почти) разработчик, относящийся с живым интересом к своей работе, пытается сделать её более удобной и лучшей, отсюда и возникает куча стандартов, паттернов и прочей полезной нечисти.
Отсюда вывод — все правы и не правы.

Это моё мнение исходя из наблюдений.

1. в целом- зачот, и читать приятно.

2. сорсы Джавы — вполне симпатичный код, Андроид — тоже ничего так.

Лично я убежден, что если бы Клавдий-Октавиан Домарощинер говорил не о людях, а о программах, он был бы кругом прав. «Код должен быть простым и ясным».

...Вот, например объект. Пока он лежит неподвижно, он прост, он не внушает сомнений. Но вот его берет чья-то недокументированная рука и куда-то передает. Чувствуете? ... Простота сразу исчезает, и ее больше нет. Чья рука? — спрашиваем мы. Куда передает? Или, может быть, кому? Или, может быть, в (void*)0? А зачем?..

Мучил меня недавно подобный вопрос. Решил для себя, что костыли иногда оправданы... Главное, запиливая костыль, делай так, чтобы потом можно было подменить его корректной реализацией. Конечно, сразу возникает вопрос — когда наступит это ’потом’, но это уже тема для другого разговора )

Но таким образом вы наращиваете «технический долг». И если по началу это действительно выглядит более правильным решением (действительно, зачем тратить 4 часа где можно обойтись часом, а когда понадобится то дописать), то потом это выливается в то, что для создания нового функционала появляются эти 3 часа, которые мы раньше будто бы сэкономили. А на самом деле еще нужно лишнее время что бы вникнуть в контекст старого кода, т.е. уже не экономим а теряем. А если доделать нужно не одну фичу а несколько, тут уже возникает другой эффект: вместо бизнеса необходимости и своевременности порядок фич определяет уже код.

«Сделать быстро это значит сделать хорошо.» ©

Совершенно верно... Если я начну писать проект с нуля, я буду делать все «идеально» =) Но как быть с проектами, которые передали тебе в наследство не совсем «качественные» проектировщики-разработчики ) Переписать все с нуля? Не вариант =) Вот и приходится — пользоваться старыми костылями, если рефакторинг остановит процесс выпуска новых фич, или создавать избыточность, пытаясь делать что-то новое правильно...

тут главный риск — не начать писать фреймворки вместо собственно кода.... разумнее , как по мне, написать «частичное решение» как можно проще, но с учетом того, что возможно оно будет рефакторится

Любой риск может быть оправдан. «Частичное решение» для каждого свое. Некоторые люди любят наоборот написать недоделок с дежурными поговорками «преждевременная оптимизация это зло» и «надо решать проблемы по мере их поступления». Получается убогий полупродукт который трудно развивать, темпы развития значительно падают оказывая влияние на боевой дух команды. Зато такие затейники с легкостью увольняются (сами и с помощью) и идут в другие команды делать очередной недопродукт.

Конечно это утрировано, но тем не менее такое происходит. Риск дело тонкое. Создание фреймворка обосновано? Пишите его. Нужно делать как можно проще? Создавайте «частичное решение». Больше всего минимизирует риски хорошая команда с объективным рассмотрением всех вариантов и выбором оптимального решения для текущей ситуации.

хорошая команда с объективным рассмотрением всех вариантов и выбором оптимального решения для текущей ситуации.

лучше всего научает опыт long-term проектов , если конечно задумываться об :) тогда можно и без команды

вы просто не до конца разобрались в идеологии

недословная цитата «евангелиста» гради буча — «идеальный процесс не достижим, но мы можем попытаться приблизится к нему»

вопрос не в «достижимости» или «недостижимости» идеала. вопрос в другом — стоит ли идеал свеч? здравый смысл подсказывает что «да», но опыт крупных компаний говорит «к чёрту идеал, делай деньги»

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

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

цель топика — разобраться и решить — убить в себе эти угрызения совести, или я всё делаю правильно

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

тут конечно возникает проблема баланса , но правильный баланс это искусство , которое на словах сложно объяснить , наверное что-то в духе сказанного разработчиком перла — «есть три доблести прогера — тщеславие, лень и трудолюбие. тщеславие — шоп не писать плохой код, лень — что бы не писать лишний код и трудолюбие ...»

ну если проще — надо знать и понимать где оператор goto допустим и эффективен :)

где оператор goto допустим и эффективен :)

в ООП он недопустим, ну если не считать таковыми свичи и метки.
Любая логическая структура собирается из комбинации 3-х элементов
— выбор if-else
— последовательный проход
— повторение (цикл)
так же как любой цвет собирается из RGB,
говорят, сортов кофе и табака тоже по три — а сколько комбинаций.

А дуля? Комбинация из 3-х пальцев вроде одна, а сколько в ней смыслов и значений!

кстати, о гoвнокоде- один мой корефан при обсуждении эстимейтов часто строил план так: «могу это сделать как следует за 3-4 дня, но если копипастом на гвоздях- за день успею» — в ответ раздавалось радостное повизгивание ПМ и аппрув 2-го варианта.

Интересно было бы увидеть комментарии ПМов по поводу такой ситуации )

Коммент ПМ-а: Зависит от того, кому и сколько времени использовать этот код.

Одно дело — 10-и людям в течении 2-3 месяцев, и совсем другое — 10 000 000 один раз в день пока не заменим фичу ;)

не стоит так нервничать из-за goto . вообще слепое следование догмам тоже есть зло ... меня ужос берет когда я думаю о том, какое сумасшедшее количество программерских человеко-часов было убито на ручное редактирование xml файлов :)

вот поэтому я второй вариант вслух и не называю )

цель топика — разобраться и решить — убить в себе эти угрызения совести, или я всё делаю правильно

это вопрос уважения к себе как к специалисту.

убить в себе можно всё что угодно.

Если под специалистом понимать человека, который выдает ожидаемый результат в рамках заданных стоимости, сроков и уровня качества — то дилеммы как бы больше и нет? ;)

Разумеется, речь не идет о всяких лентяях-разгильдяях, быдлокодящих не потому, что это осознанное бизнес-решение, а потому, что им, пардон, впадлу писать правильно.

Подписаться на комментарии