У каждого клиента – свои предпочтения. Не только в выборе автомобиля, блюда на обед или корпоративной информационной системы. Клиенты любят выбирать программистов.
Ну, что программисты разные – ежу понятно. Считается, что клиенты предпочитают профессионалов. Мы тоже так думали, и искренне стремились сделать каждого своего программиста этим самым профессионалом.
Однако, несколько клиентов, ставя нам задачи, упорно твердили: пусть программирует Серёжа. Хотя Серёжа – лютейший говнокодер, объект всеобщей жалости и главный поставщик материалов для конференций на тему «Как не надо программировать».
Кто такой Серёжа?
Я буду называть Серёжу Серёжей, потому что он просит называть себя именно так. Не знаю, почему.
Ничего особенного. Отучился в ПТУ (колледже) на программиста, пришёл работать. Попал в отдел сопровождения – где надо «а-а-а-а-быстрее-быстрее-клиент-ждёт». Такой старт во многом и определил стиль программирования Серёжи.
Стратегия Серёжи: «быстро и точно». Кратчайшим путём дойти до решения, максимально точно попадающего в исходную постановку задачи. Особенно важна точность интерфейса, включая цвета, шрифты, названия и порядок колонок и т.д.
Сами понимаете, такая стратегия – чрезвычайно сложна. Реализовать её можно либо будучи бешеным профи, либо – оставляя за собой лютейший говнокод. Серёже, конечно, был доступен только второй сценарий.
Клиенты Серёжу полюбили. Руководитель отдела сопровождения – тоже. Но, тем не менее, через три года Серёжа ушёл – в отдел разработки. Туда, где сидят «настоящие программисты».
Переход
Вообще, переходы были нормальной практикой. Человек осваивает какие-то навыки в сопровождении, и идёт к сурьёзным ребятам, задачам и клиентам. Некоторые так и оставались, правда, в сопровождении.
Но Серёжа, будучи почти звездой в сопровождении, нужен был в программировании. Это было не его решение – начальство так постановило.
И началась дичь. И для Серёжи, и для программистов. Закатывали глаза, заламывали руки, брызгали слюной, бились головой о стену. Но ничего не помогало – говнокод стал частью ДНК Серёжи.
Несчастный очень быстро скатился вниз по показателям. Какую бы задачу ему не дали – ни фига не получалось. Точнее, программирование шло с противнейшим скрипом и затратами колоссального времени остальных сотрудников – приходилось объяснять, ещё раз объяснять, тыкать носом, заставлять переделывать и, в конце концов, забирать задачу и, матерясь, переделывать самим.
Начали проседать показатели всего отдела – не сильно, но всё-таки. Ну и атмосфера, конечно, стала гнетущей. Надо было что-то решать.
Позвали начальство.
Решение
Начальство было мудрое. С одной стороны, виден полный провал Серёжи во всём «сурьёзном». С другой – бывшие клиенты Серёжи изнывали без него. Ну а чё, подумало начальство.
Пусть Серёжа сидит с программистами, но решает задачи своих бывших клиентов. Случился лёгкий спор с начальником отдела сопровождения – ведь «забрали клиента». Но, как выяснилось, забирать-то особо нечего, с уходом Серёжи его клиенты почти перестали приносить деньги.
Ну а остальные программисты будут Серёже помогать в развитии навыков, только уже на его задачах и клиентах. На том и порешили.
Пошло хорошо. Первый месяц Серёжа, к великой радости клиентов и начальства, просто херачил весь накопленный пул задач. Быстро и точно, как умел и любил. Но сработал закон Вселенной – чем больше задач клиента ты решаешь, тем больше их становится.
Серёжа перестал справляться с возрастающим потоком. Выход был очевиден – пусть задачи решают и остальные программисты. Те оказались не против. Парней, если честно, немного завидки брали – пусть и говнокодом, но Серёжа зарабатывал больше. А тут – возможность победить засранца на его же поле.
Но начался жесточайший кризис.
Кризис
Программисты полезли в сокровищницу Серёжи и ахнули… Не, говнокод-то они уже видали, но чтобы столько, да в одном месте, и как-то это всё взаимосвязано! И, самое поганое – работает!
Ситуация получалась весьма странная. Раньше Серёжа решал хорошую задачу и огребал за гокновод, который пытался встроить в нормальный, чёткий, лаконичный и выверенный контекст. Теперь – ровно наоборот. Нужно было понять записки сумасшедшего, и хоть как-то вклинить в них что-нибудь изящное и не позорное.
Для программистов это было в новинку. И бесило жутко. Начались скандалы. Брал программист задачу, смотрел, матерился, звал Серёжу и пытался тыкать его носом. Серёжа к тому моменту уже стал чуть смелее, и отвечал просто: «не хочешь – не делай, сам подшаманю». Раз сказал, два сказал – перестали пытаться воззвать к чувству вины.
Ну ладно, сказали программисты. Щас мы покажем – и Серёже, и его клиентам, как надо программировать. И стали молча делать решения так, как положено. Но тут, совершенно неожиданно, взвыли клиенты.
Во-первых, им не нравились решения программистов – они были не точны. Программист ведь почти Бог, и лучше знает, что надо клиенту. Поэтому делает близко к требованиям, но с обязательным внесением своей лепты в постановку задачи.
Во-вторых, не понравились суммы, которые программисты выставляли за свою работу. Они были в разы больше серёжиных. Оно и понятно – быстрый говнокод дёшев, нормальный – существенно дороже.
Фраза «Пусть программирует Серёжа» звучала всё чаще и настойчивее.
Но программисты не сдавались – решили объяснить клиентам, как надо на самом деле. Организовали несколько встреч, собрались, поговорили. Рассказали про архитектуру, стоимость поддержки кода, правильное проектирование, сценарии использования, масштабируемость и т.д. Короче, изложили, что есть «правильно».
Клиенты послушали, головой покивали, но честно признались – всё понятно, но ничего не понятно. Давайте на примерах. Программисты взялись объяснить на текущих задачах.
Под руку попался инструмент планирования загрузки оборудования имени Серёжи – клиент попросил добавить в него новую функциональность. Программисты сказали, что на анализ всего инструмента придётся потратить 10 чел/часов. Но раз такое дело, сделают это бесплатно. Клиент, правда, цифру услышал и запомнил.
После анализа программисты сказали, что весь инструмент надо переделать. От макушки и до пят. И анализ сделать ещё раз – только не кода, а требований, процессов и сценариев. С людьми поговорить, короче. А тут уже не обойтись без привлечения бизнес-аналитика.
Насчитали, в итоге, предварительную стоимость в 120-160 чел/часов. Клиент был в шоке – нахера отдавать столько денег за создание с нуля инструмента, который уже давно работает? Программисты пытались объяснить, что это будет правильно. Говнокод обязательно сломается когда-нибудь, не будет масштабироваться, не натянется на него очередное функциональное требование.
Но всё было тщетно. Клиент перестал слушать программистов. Твердил, как заведённый: «Пусть программирует Серёжа». Особенно с учётом того, что Серёжа оценил текущую доработку в 4 чел/часа.
Но программисты не сдавались. Они пошли к начальству.
Финал
Программисты знали, что начальство, конечно, уважает всякие там «технические подробности», но любит деньги. Поэтому решили надавить именно на доход – сравнить суммы от «хорошего» и «плохого» программирования.
За основу взяли тот самый инструмент планирования, который оценивали для клиента. На вторую чашу весов положили свою фантазию на тему «за сколько Серёжа это говнокодище сделал», и добавили известную им стоимость доработок инструмента за последние месяцы.
Итак, хороший код принёс бы компании 160 чел/часов. Плохой, по оценкам программистов – 50 чел/часов. Отправили цифры начальству, попросили о встрече.
Начальство, напомню, было мудрое. Решило выслушать и вторую сторону – попросило Серёжу посчитать, сколько компания заработала на создании и доработках этого конкретного инструмента. Ну и назначило встречу на всех.
Серёжа насчитал 300 чел/часов. И не просто насчитал – принёс документы, которые подтверждали цифры. Чаша весов резко качнулась. Но Серёжа, кроме денег, докинул на неё свои говнокодерские аргументы.
Во-первых, инструмент работал уже через месяц после начала создания. Да, через задницу, но задачи клиента решал. Во-вторых, инструмент продолжал развиваться и выполнять своё предназначение в течение двух лет. Ну да, не развиваться, а «развиваться». В-третьих, ни разу, ни единого разочка, с клиентом не было проблем – ни с инструментом планирования, ни с другими задачами.
Четвёртое добавило начальство – неистовая, слепая лояльность клиента. К Серёже, конечно, но через него – ко всей компании.
Программисты с выводами не согласились, но уже исчерпали все аргументы. Раз такое дело – пусть и правда программирует Серёжа.
P.S.
Развитие истории получилось неожиданным. Чутка поостыв, программисты подумали, поговорили, поспорили и… Признали право Серёжи и его говнокода на существование. Решили к нему даже присмотреться. И, по возможности, поучаствовать – очень, почему-то, захотелось и к себе неистовой лояльности.
Правда, отношения с клиентами Серёжи уже успели испортить. Поэтому решили так: пусть клиент думает, что программирует Серёжа. А задачи будут решать программисты. Не все подряд, разумеется, и не только их – свои клиенты никуда не делись. Никто не собирался менять веру и уходить в говнокод с головой.
Стали просто разбавлять. Один день красиво программируешь, другой – пускаешься во все тяжкие. Сравнивали дни говнокодерства с мероприятиями вроде Ла Томатины. И, как ни странно, остались довольны.
Во-первых, чутка больше зарабатывали – доработки говнокода требовались часто. Во-вторых, нашли в говнокодерстве профессиональную ценность – лучше понимали, как надо писать код. В-третьих, обнаружили, что и своим клиентам иногда полезно сделать «быстро и точно» - лояльность повышается, а следом – и поток объём задач. В-четвертых, клиенты Серёжи, наконец, сдались и разрешили другим программистам официально решать их задачи.
Теперь можно услышать не только про Серёжу. Пусть программирует Коля, Петя, Вася. Жить стало интереснее и проще.
Комментарии (195)
Aquahawk
10.06.2022 09:04+58Я иногда такой Серёжа. Я считаю что важна правильная архитектура крупными мазками, а в изолированных деталях может существовать какой угодно говнокод. И мне крайне непонятны люди которые приходят, видят читаемый код, читают, понимают и говорят что он не соответствует их идеалам программирования которые они видели в толстых книжках. При этом эти люди частно никогда не смотрели ни в какой в крупный и успешный опенсурс. А правда в том что в любом старом крупном опенсурсе всё что надо работает на достаточном уровне, но там невероятные глубины говнокода с точки зрения смузи программиста. Задачи делать надо, и смотреть чтобы продукт жил. Далеко не каждый кусок кода надо полировать, далеко не каждый кусок кода надо покрывать тестами, могут существовать куски кода которые 2/3 отдела понять не в состоянии в принципе. Ничего страшного. Нет никакого смысла прямо сейчас пытаться всё это отполировать чтобы джун мог там как рыба в воде плавать. Более того, я даже пост писал на эту тему https://habr.com/ru/post/440414/
SadOcean
10.06.2022 11:22+5Согласен. Мощность и качество архитектуры - это как раз границы, прозрачность на высоком уровне и куча понятных точек расширения, где можно говнокодить (если нужно), не разбрызгивая. И где для большинства новых разработчиков понятно, если нужен экран приложения - делай так. Нужна новая сущность - добавляй тут, нужно расширение апи - здесь, а сервисы с длинным ЖЦ - тут и т.д.
Не раз видел обратную ситуацию - отточенные функции, качественные специализированные классы, качественный гайдстайл, модули уже рыхлые и со странными связями, а на уровне проекта управление - набор костылей, говнокода и спрятанных глобальных переменных, неявно рулящих состоянием.
И это гораздо хуже.
MAXH0
10.06.2022 09:07+12«Публикуйте раньше. Публикуйте часто. И слушайте своих клиентов»...
Без 1000 проверяющих глаз, но в целом Серёжа двигается в этом направлении.Потом будет SCRUM и пр.
Kealon
10.06.2022 09:25+8Серёжа ярый агилист. Всё верно, большинство программистов пытаются решать проблему, которая возможно никогда не возникнет, что тратит время клиентов. И в этой истории программисты полезли в работающий код без анализа, с очевидным результатом. А в таком коде нужно сначала разобраться, а потом уже постепенно срезать лишнее.
konsoletyper
10.06.2022 09:31+8Ну или всё-таки надо было найти какого-нибудь Петю, который может мастерски работать с клиентами и донести до них мысль, что Серёжа им не нужен. Вот зачем программистов на это подряжать? Они не по части общения с клиентом, они - по части программирования. А хотелки клиента - это тоже вещь эфемерная, им нужна машина, а они это формулируют как "более быстрая лошадь". Да и хотелки эти меняются хаотическим образом, порой возвращаясь на место, как в знаменитом "Порожняке" из Фитиля. Так может такие Серёжи являются симптомом того, что компания не научилась нормально выстраивать диалог с клиентом? Или что у компании неадекватные клиенты? В любом случае, ничего хорошего такую компанию не ждёт, в краткосрочной перспективе поработать здесь и сейчас можно, но в целом я бы валил из такой, ибо в плане долгосрочной карьеры и самореализации там ловить, видимо, нечего.
nikolas78
10.06.2022 10:21+6А какие доводы надо привести клиентам, если Сережа все делал на отлично и гарантирует такой же результат в будущем?
konsoletyper
10.06.2022 10:37+4Проблема как раз в том, что не гарантирует. А ещё аргумент - покопаться в бизнес-процессах клиента, подсказать, что ему НА САМОМ деле нужно. Универсального рецепта нет, тем более, что я и сам-то не переговорщик. Из моего опыта мне как-то (правда, внутренний) заказчик всё больше и больше пытался продавить в приложении функций экселя. В итоге я не выдержал и просто в какой-то момент сделал импорт-экспорт, весь эксель уже есть, он хорош, и нам его точно не переплюнуть. Аргумент ровно такой: мы можем тратить кучу времени добавляя фичи в приложение, делая из него БЛЕДНОЕ подобие экселя, или вы можете использовать уже существующий у вас замечательный эксель, экономя и своё, и наше время. Другой вариант - обговорить MVP, попытаться понять, что здесь и сейчас можно обрезать, пообещать сделать в следующей итерации (а на практике как до неё дойдёт, то часто, либо ишак, либо падишах). Если договориться не удалось, можно попробовать походить по тонкому льду и заняться саботажем, т.е. ой, я не успел сделать. В случае прокачанного чутья можно как раз "не успеть" сделать то, что окажется к сроку сдачи уже и не сильно нужным, или окажется, что в процессе эксплуатации все довольны реализованным функционалом. Если эту итерацию повторить несколько раз, то до заказчика начинает доходить, что ты фишку сечёшь и они начинают больше прислушиваться к тебе в процессе постановки задачи. Правда, опять же, это прокатывает с внутренним заказчиком, если есть договор и ТЗ, то так уже становится сложно себя вести. Вариант: то, что "не успеть", сделать максимально костыльно и говнокодисто, с расчётом на то, что всё равно придётся выпилить.
nikolas78
10.06.2022 10:43Проблема как раз в том, что не гарантирует
Сережа еще не разу не подвел клиентов, и никто его «говнокод» за ним не разгребал (он не уходил в другую фирму, сбросив все на оставшихся коллег). Практика разве не важнее теории?konsoletyper
10.06.2022 10:45+11Цитата из статьи: "Серёжа перестал справляться с возрастающим потоком." А точно возрастал именно поток задач?
nikolas78
10.06.2022 16:35+2Серёжа перестал справляться с возрастающим потоком
Справедливости ради, это случилось уже после некоторых орг-изменений. Возможно именно эти изменнения были тому виной, или нет, из статьи не понятно.
DrPass
10.06.2022 15:48+3Проблема как раз в том, что не гарантирует.
Проблема больше в том, что на стороне «Сережи» лежит быстрое работающее и недорогое решение проблемы при отсутствии гарантий его успешного развития. На стороне «Пети» лежит более дорогое решение, требующее более долгого внедрения. А знаете, что самое неприятное? Оно тоже не предлагает никаких гарантий его успешного развития. Ну просто потому, что предложенная программистами продуманная архитектура совершенно не обязательно окажется соответствующей будущим (а иногда — даже текущим) потребностям бизнеса. Это их собственное видение, не более того.konsoletyper
10.06.2022 16:04+3Оно тоже не предлагает никаких гарантий его успешного развития. Ну
просто потому, что предложенная программистами продуманная архитектура
совершенно не обязательно окажется соответствующей будущим (а иногда —
даже текущим) потребностям бизнеса.Моя практика показывает, что если тут нет чьей-либо предвзятости, то есть вполне объективные показатели, как лучше-хуже, и какая-никакая минимальная продуманность всегда в долгосрочной перспективе выигрывает по сравнению с полной непродуманностью и костылями. Суть хорошей архитектуры не в том, чтобы соответствовать текущим или будущим требованиям бизнеса, а в том, чтобы уметь под любые такие требования подстраиваться. И для этого, поверьте, кроме хороших практик в конкретной предметной области, есть вполне себе универсальные общеинженерные методики, плюс-минус работающие хоть в системе учёта персонала, хоть в компиляторе, хоть в 3D-движке. То, что некоторые программисты продумывают "архитектуру", а потом получается ужас, свидетельствует либо о том, что они по сути такие же "Серёжи", которые обозвав исходного Серёжу говнокодером, перетянули на себя проект, либо о просчётах менеджмента, который руководил разработкой/внедрением системы.
SwingoPingo
10.06.2022 16:07+4Если бы это решение лежало у Сережи этой истории бы не было, Сережа бы греб деньги лопатой и слал нам воздушные поцелуи с пляжей теплых морей. Но Сережа вместо этого обсуждаем сейчас здесь не в лучшем свете, а следовательно Сережино решение включает в себя некоторые издержки в своем жизненном пути, даже для него самого. И мы можем софистически искать равенство этих двух решений, но обсуждаем то мы не второе, а Сережино. В этом проблема. Оно _было_ когда то дешевым, быстрым, срочным, но сейчас оно неработающее, немасштабируемое и дорогоподдерживаемое, оттого оно в обсуждении.
wAgo
11.06.2022 00:22А если допустить что Серёжа на работе уи пинает, а вместо него код пишет "ИИ, нейронная сеть Маша" ))) То что обычный человек не понимает как это творчество устроенно и как работает не имеет никакого значения если задача решается так как нужно заказчику )))
Слишком много внимания уделяется архитектуре - как говориться дорога ложка к обеду ))
shornikov
10.06.2022 20:01+2Угу-угу.
Есть контора, работает 10 лет, например.
И пришли ммм допустим даже интеграторы, и говорят - вы все делаете неправильно.
Вчера мы молокозаводу объяснили как правильно работать,позавчера алмазному разрезу. И вам объясним.
А обычно учить пытаются просто фирмочки, которые сайты делают
konsoletyper
10.06.2022 20:24Ахаха, кто же приходит и в лоб заявляет "вы всё неправильно делаете"? Если кто-то такое произносит, то явно в компании проблемы с взаимодействием с клиентами, из-за чего и перекладывают всё на несчастного Сергея, со всеми вытекающими.
fixin
10.06.2022 09:54Надо программировать доступно и всерьез. Я тоже Сережа (по имени) и франчи 1С проигрывают мне, потому что делают дорого и красиво, а я дорого и сердито.
Но тем не менее у меня красивые решения, ибо я Гений 1С.
Naf2000
10.06.2022 10:14+9Ну конечно, твой код это шедевр. Передавать параметры в метод через базу данных, что может быть лучше:
https://geniy1s.ru/nekanonicheskij-sposob-spuskaniya-parametra-nizhestoyashhim-proczeduram/
vis_inet
10.06.2022 11:42+3Ситуации бывают очень разные и в каких-то случаях могут быть оправданными весьма неочевидные решения.
Nickel3000
10.06.2022 13:03+6Гении могут быть со странностями, если отзывы правдивы. https://otzovy-moskvy.ru/firm/ip-osipov-sergey-aleksandrovich-154062
IvanSTV
10.06.2022 17:27+1блин, какие глубины психиатрии открылись, даже если это хотя б на 10% правда
pehat
10.06.2022 21:04+3@BarsMonster , человек, которого Вы пригласили на Хабр, имеет весьма специфическую репутацию в узких кругах. Не могли бы Вы сказать пару хороших слов в адрес своего знакомого? Отзывы, конечно, смешные, но если хотя бы часть из них правда - я не знаю, куда звонить в первую очередь - докторам или полицейским.
Abbadosha
11.06.2022 23:25Читая эти отзывы я сначала подумал что это чисто ироничное описание себя от опытного прогера, но сейчас я даже не знаю что сказать)
fixin
10.06.2022 16:57я все хочу услышать, какое альтернативное решение для передачи контекста вглубь ты придумаешь (если не придираться к хранению в БД, которое я потом безболезненно заменил параметрами сеанса)?
DvoiNic
10.06.2022 10:09+14Ну, обычный подход франчей, где «лучше 100 раз доработать и срубить 200 тыр, чем один раз сделать правильно, и взять 100 тыр».
К сожалению, прошедшие такую школу очень сложно переучиваются «работать правильно», делать решения с учетом возможного расширения, и долгого сопровождения.
FanatPHP
10.06.2022 12:57+1Единственный комментарий по теме so far. Остальные с увлечением дискутируют с голосами в своей голове. «Агилист», «Common Lisp Recipes» my ass…
SwingoPingo
10.06.2022 13:11+1лет 20 я уже не во франче, но никуда от говнокода вокруг не делся. Вопрос шире чем франчи vs фиксы.
fixin
10.06.2022 16:58Какова метрополия, таковы и филиалы. Сама 1С не радует нас качестенным кодом. Особенно нынешняя ее ERP - это ужас. У них уже была Ужасно Плохая Программа.
esisl
10.06.2022 10:23+5Сегодня всем мы- "Серёжа"!!! :)
Регулярно таким заниматься приходится. Причем не столько от отсутствия квалификации или "принципов", а от лютейших дедлайнов "ой нам вчера надо было полностью переделать проект!"
P.S. Только что переносил "проклЯтый" проект с одной CMS на другую. Пол-сотни классов сущностей. За три дня. %)
А коллеги из Яндекса только что занимались еще более масштабной задачей(ну вы понимаете) за два дня.
roboter
10.06.2022 10:54+2Получается Серёжа демпингует, да ещё завязывает клиента на себя. Клиенту понятно такой демпинг выгоден, ибо платить меньше, но страдает вся компания.
Arimefu
10.06.2022 12:22+6Мне кажется, это не совсем демпинг. Если бы он указывал цену заметно ниже адекватной, то это был бы демпинг. А в его случае цена (за единицу работы) вполне обычная, просто достигается она тем, что задача выполняется другими способами. Если заказчику нужно здесь и сейчас, потому что завтра может бизнеса уже и не стать, и его устраивает, что потом, возможно, придется заплатить больше (но это будет либо потом, либо вообще не будет), то такой подход вполне имеет право на жизнь. Об этом и статья. Но не везде такой целесообразен.
SwingoPingo
10.06.2022 12:26Статья именно потому, что сценарий "либо потом, либо вообще не будет" не реализовался. Реализовался незапланированный никем "работаем дальше", но как с этим теперь работать? Если бы Сережа или подобные вытягивали, то и статьи бы не было.
Arimefu
10.06.2022 12:35Меня немного неправильно поняли. Под фразой «заплатить больше потом» я имел в виду то, что поддержка такого решения в итоге требует суммарно больше денег (даже в случае без рефакторинга), но при этом все эти расходы бизнес несет не здесь и сейчас, а по мере необходимости. Либо не несет, если необходимости нет, условия поменялись, бизнес прогорел и т.д.
SwingoPingo
10.06.2022 12:40Вы правы. Бывает и так что код/архитектура тянет за собой и содержание оператора этого кода, явное или неявное.
engine9
10.06.2022 11:02+6Есть среди стоматологов такие Серёжи, делают клиенту реставрации коронок из пломбировочного материала, анкеров накрутят в канал, хоп, хоп, коронку вылепили. Дёшево. Быстро. Красота! Клиент счастливый, довольный.
Через пару лет во время еды эти коронки начинают откалываться, оставляя гнилые пеньки.
Admz
10.06.2022 11:03+1Интересно было бы посмотреть какой год "проф" проггеры считают "говнокодом", по каким параметрам он его определяют? Что его так отличает от "идеального", по их мнению?
JPEGEC
10.06.2022 12:19+1Классика типа
if var1 == "true"По моему пониманию "говнокод" это безграмотность, либо алгоритмически, либо в средствах языка.
Но впрочем я не программист.
kotandvla
11.06.2022 07:45-1Это не говнокод, но логическая ошибка.
Говнокод - это использовать функциональное программирование там, где лучше было бы все собрать в классы с несколькими уровнями астракции, интерфейсами, модульностью, без непонятных констант и т.п.
JPEGEC
11.06.2022 13:14+2Осталось выяснить для кого лучше и кто решает что лучше.
Итогом такой точки зрения получится что любой код говнокод.
Я все же останусь при мнении что говнокод это прежде всего неумение пользоваться инструментом - алгоритмом или языком.
lubezniy
12.06.2022 23:38И наоборот тоже. Когда из-за добавления одного-единственного аргумента в метод при лишнем уровне абстракции оказалось нужно переписать 14 методов объектов, я то же самое понятие использовал...
staticmain
10.06.2022 13:29+6union bitdata {
struct {
unsigned int bit1 : 1;
unsigned int bit2 : 1;
unsigned int bit3 : 1;
unsigned int bit4 : 1;
unsigned int bit5 : 1;
unsigned int bit6 : 1;
unsigned int bit7 : 1;
unsigned int bit8 : 1;
};
unsigned char byte;
} first_byte, second_byte;
first_byte.bit1 = first_byte.bit1 == 0 && second_byte.bit1 == 0 ? 0 : 1; first_byte.bit2 = first_byte.bit2 == 0 && second_byte.bit2 == 0 ? 0 : 1; first_byte.bit3 = first_byte.bit3 == 0 && second_byte.bit3 == 0 ? 0 : 1; first_byte.bit4 = first_byte.bit4 == 0 && second_byte.bit4 == 0 ? 0 : 1; first_byte.bit5 = first_byte.bit5 == 0 && second_byte.bit5 == 0 ? 0 : 1; first_byte.bit6 = first_byte.bit6 == 0 && second_byte.bit6 == 0 ? 0 : 1; first_byte.bit7 = first_byte.bit7 == 0 && second_byte.bit7 == 0 ? 0 : 1; first_byte.bit8 = first_byte.bit8 == 0 && second_byte.bit8 == 0 ? 0 : 1; ready_bytes[j] = first_byte.byte;
courage_andrey
10.06.2022 13:32+2Если до рефакторинга в куске кода находили 4 бага в неделю, а после стало в среднем 1.5, то до рефакторинга код был явно не очень.
Если одна сферическая задача в вакууме раньше занимала 36.2 часа разработки, а после переписывания стала закрываться за 7.1 часов - аналогично.
[совсем реальный кейс с настоящими цифрами] Если раньше один критичный алгоритм занимал 10.000 строк кода и покрывал 17 возможных комбинаций входных значений из 640.000, а потом стал занимать 100 строк (просто сотня, а не сто тысяч) и покрывать все 640.000...
Нужно продолжать?
Ionenice
10.06.2022 14:18+2Если до рефакторинга в куске кода находили 4 бага в неделю, а после стало в среднем 1.5, то до рефакторинга код был явно не очень.
но код с багами это же не обязательно говнокод, это просто код с багами, или после рефакторинга у вас код стал просто чуть менее говнокодистым?)
Если одна сферическая задача в вакууме раньше занимала 36.2 часа разработки, а после переписывания стала закрываться за 7.1 часов - аналогично.
Тоже, возможно, не лучший пример, сферическая задача в вакууме, особенно на зарождении проекта, скорее всего будет гораздо быстрее решаться говнокодом
Если раньше один критичный алгоритм занимал 10.000 строк кода и покрывал 17 возможных комбинаций входных значений из 640.000, а потом стал занимать 100 строк (просто сотня, а не сто тысяч) и покрывать все 640.000...
А это говнокод или баг?) Или изначально были разные требования? Безусловно сравнение 10к или 100к строк с сотней выглядит потрясающе, но немного настораживает :)
Возможно говнокодом можно назвать просто сложночитаемый код, который не использует всех явных синтаксических и «логических?» возможностей, из этого и будут вытикать другие признаки говнокода
courage_andrey
10.06.2022 14:55+2Вот именно для того, чтобы не спорить, что есть баг, а что есть говнокод (или кто из двух кодообезьян говнокодистее, или какой стиль именования/отступов/расстановки скобок самый правильный, или какой из /анти/паттернов является на самом деле таковым), я и предлагаю сводить всё к числам.
Боль есть? - Значит говно!
Работает и ни у кого не подгорает? - Молодцы, продолжайте!
srg27y
10.06.2022 11:19+2благодаря быдлокодерству появились гигагерцы и многоядерники.
а то па по прежнему сидели бы на еэсках
DvoiNic
10.06.2022 11:30+9отнюдь. Это быдлокодерство появилось благодаря «мегагерцам, многоядерникам и гигабайтам».
starik-2005
10.06.2022 15:18+3Мне кажется, что это хоть и связанные как-то процессы, но у них очень слабая связанность. Если почитать всякие там статьи от яндекса про их кликхаус, где они меряются пиписьками с гуглом и на их яндекс-метрике их хеш-куча отрабатывает быстрее на 30%, укладываясь где-то в какой-то кеш процессора, то создается впечатление, что в реальном хайлоад все очень сильно оптимизируется, просто до невозможности. А если смотреть, как народ те же недействительные паспорта в базу 1С пытается десятками часов грузить, при том если просто хеш-таблицу в той же 1С сделать и засунуть в нее просто записи файлов с номерами и все грузится за 40 минут, то еще неизвестно, что назвать говнокодом. А ведь грузить в базу - это вроде как "праильно", при том хранить в базе меняющиеся каждый день значения - это явно "не правильно". С третьей стороны, любая битовая маска покрывает эту задачу и решает вопрос загрузки за единицы минут даже на 1С, а на Си вообще за десятые долит секунды, при этом проверка падает в эффективность О(1), как и вставка/обновление значения при минимально используемой памяти, т.к.маску можно грузить частями.
В общем, одна и та же задача может быть как ресурсоемкой, так и элементарной. Все упирается в алгоритм и инструмент. Есть быстрые алгоритмы, которые будут на медленном инструменте ресурсоемки, есть медленные алгоритмы, которые на быстром инструменте будут нересурсоемки. Так что производительность ПК - это благодаря геймерам, научным расчетам и медленным платформам (типа 1С, где расчет себестоимости по объему вычислений не превышает расчета одного кадра 4к в приличной игрушке, при том занимает до суток времени, при том домашний комп за сто рублей в этой игрушке выдает приличное FPS, в то время как на порядок более дорогой сервер дохнет в "кровавом энтерпрайзе").
nmrulin
10.06.2022 16:14+2Смотря какое. Многие образцы старого кода считают быдлокодерством т.к. не в когда нет классов, много глобальных переменных, даже функции и то вызываются редко и большие.
Но зато по скорости это работает намного быстрее сегодняшнего условно хорошего кода.
iamkisly
11.06.2022 10:20Это два процесса которые подтягивают друг друга. Например есть производители железа и программисты, которые делают что-то. Программисты умеют в оптимизацию, но бизнесу это не нужно, а значит что-то жрет все больше и больше ресурсов. Если ситуация по оптимизации патовая, то делают оптимизацию. Если нет, ждут пока производители железа начинают соревноваться, чей продукт справляется с чем-то лучше потому что им тоже надо решать запросы пользователей чего-то, и цикл повторяется.
Гораздо интереснее в этом отношении таже картина в плоскости embedded, где в конечном итоге умудряются натянуть Arduino на Cortex-A Series, хотя с задачей справился бы гораздо, горазбо более простой чип, но это же надо знать pure c и asm. В итоге люди с компетенцией Сережи делают продажи производителям чипов, систем-на-кристалле и демо-плат, отчасти от того что взять микроконтроллер придуманный для во-много во-много раз сложных задач дешевле, чем оплатить работу программистов. От этого и рождаются решения типа NET nanoFramework, microPython и тд, потому что "давайте использовать существующую кодовую базу".
amarao
10.06.2022 11:32+4У меня странное ощущение, что мифологемы не бьются. Говнокод - это не когда "никто не может прочитать". Говнокод - это когда оно работает не как должно, а никто не может понять по коду как должно.
Arimefu
10.06.2022 12:17+10В таком случае это уже не просто говнокод, это вообще нерабочее что-то. Говнокодом обычно все же работающее что-то называют, только вот его трогать, как правило, страшно: чуть что поменяешь, и все пойдет не так, потому что нет структуры или в ней разобраться просто нереально.
iamkisly
11.06.2022 11:16Говнокод, это что-то рабочее, но поддерживаемое с трудом. Или просто вызывающее кровь из глаз, но тоже рабочее. Во многом эти проблемы с написанием качественного кода возникают из-за недостатка времени у сотрудников, и отвратительного менеджмента. У людей сначала нет времени читать документацию, нет времени подумать над архитекторой.. а потом нет и желания. Потоянное переключение между задачами из-за их деприоритизации потому что бросай все! срочно нужно сделать %subject% не позволяет сосредоточиться на поиске правильного решения. Классическое хуяк-хуяк и в продакшн. При этом задачи ставятся на уровне "сделай заебись", а результат обсуждается под крики "я тут начальник, я лучше понимаю что нужно" и классическое "я никого не держу" и "дверь там".. при том, что в коллективе фактор автобуса стоит достаточно остро. Во всяком случае у нас именно так.
manyakRus
10.06.2022 11:38у всех программистов говнокод. Ещё не видел ни одного программиста код которого мне нравится. Так и должно быть.
И типовой код от фирмы 1С тоже говнокод, но там кода очень много и работает обычно правильно, поэтому надо уважительно относиться как они умеют так делать чтобы много говнокода вместе работало правильно.Много говнокода - надо привыкать
Мало говнокода - надо удалять
SwingoPingo
10.06.2022 11:53+9Само понятие "говнокод" возникает в процессе оценки этого кода, следовательно система "Сережа + Клиенты" перестала быть закрытой, самодостаточной и требует взаимодействия с другими программистами, которые и оценили код.
Апелляция к тому, что клиенты то раньше были довольны прекрасна, но ключевое слово "раньше были". И последующее движение вперед невозможно без оценки того, что есть и выплаты по накопившемуся техдолгу, раз уж мы пришли к необходимости в Сережин код вникать. Никто в здравом уме в такие болота не лезет по собственной воле в целях сохранения этого здравого ума.
Аналогия - на изношенной машине Вы доехали до клиента, когда колеса лысые в заплатках, двигатель троит, от тормозов только ручник, рама сгнила и подварена, а клиент просит еще пару тройку тонн перевезти, и ну вот же, машина то до этого ездила, мы не жаловались, сюда то доехала и техобслуживание недорогое было то...
F0iL
10.06.2022 12:22+6Вот кстати да, техдолг очень в тему упомянут. Ни для кого не секрет, что зачастую чем больше "берешь в долг", тем быстрее можно достигать требуемого (особенно по сравнению с конкурентами). Самое главное - успеть соскочить до того момента, когда придется этот долг отдавать, иначе может быть очень больно.
SwingoPingo
10.06.2022 12:31+6Да, это общая беда для политиков и программистов. Популисты быстро спускают накопленный другими капитал, конвертируя его в лояльность к себе.
nikolas78
10.06.2022 16:31Апелляция к тому, что клиенты то раньше были довольны прекрасна, но ключевое слово «раньше были»
Почему Сережа перешел в другой отдел в статье не говорится. Поэтому отталкиваемся от того, что «просто так перешел».SwingoPingo
10.06.2022 16:45+1но по сути то это не меняет ничего. Сережино решение работает только с ним, следовательно не масштабируется, плохо поддерживается (зависимо от него в поддержке) и т.д. Вот момент Х и наступил, по какой причине совершенно не важно.
Предположу этот момент оголил такие бездны техдолга для клиента, что их лояльность к Сереже резко возросла из за фактической невозможности осилить расходы на его переработку. Но это так, смелое предположение.
nikolas78
10.06.2022 16:58Единственный минус вижу в «вендор-локе». Это да. Но вопрос «прав ли Сережа» остается открытым.
Stormwalker
10.06.2022 12:00+4У меня в команде был такой Серёжа, через год работы сделали его тимлидом, после этого жить стало попроще. Но после того, как я оттуда ушёл, местами проникся подходом, потому что в конечном итоге наша продуктивность оценивается как количество проблем, решённых в единицу времени, что бы мы о себе не думали.
starik-2005
10.06.2022 12:28+2Ну вообще Сережи - ценный ресурс. Бизнесу важно, чтобы работало здесь и сейчас. И даже не бизнесу, а конкретному человеку. Бизнес, как "группа товарищей, стремящаяся к общему благу", часто тянет воз в разные стороны (да, как все эти лебеди, раки, щуки и "не только лишь все"): кто-то собирает комплект увольнения, кто-то движется по головам, кто-то делает что-то еще из тех кейсов, которые автор уже описал и из тех, о которых даже автор не догадывается. И им нужен результат как можно быстрее, желательно прям вот "щаз". И Сережа им помогает в этом, делая ровно так, как они сказали. Да, может быть потом на это "дерево решений" придется повязать кучу "бантиков" ("свистоперделок") в виде "граблей и костылей", но они будут решать отдельные задачи.
Вот, например, есть у нас решение. Его просто прикола заради прогнали через анализатор кода. И анализатор на типовом коде выдал существенную часть проблем (порядка 85%). Т.е. это продуманный и все такое код, который был написан уважаемыми людьми, многие из которых в алгоритмах принимают не хуже Кнута, но им пришлось работать с весьма "волатильной" в представлениях "метазаказчика" предметной областью, для которой "годных архитектур" не напасешься. И все это произведение тех, кто о программировании знает столько, сколько не знает никто (да, туда берет только после того, как ты решишь кучу задач, самая простая из которых - это слияние упорядоченных массивов в "обратную сторону" "правильным" методом, т.е. в один проход без дополнительных массивов - да, это тривиальная задача, но она там самая простая).
Да, всегда разработка балансирует на том самом "триалектическом балансе": "быстро, качественно, недорого (выберите любые два)". И 170 часов на полную переработку решения, написанного за 50 часов - это не быстро, не факт, что качественно, но точно дорого.
И да, Аджайл тут рулит, т.к. Сережа выкатывает прототип, которые вкорячивается в бизнес-приложение, т.к. конкретного стейкхолдера от бизнеса этот прототип устраивает на все 100%. Он делает ровно то, что нужно. А проблемы масштабируемости - это проблемы роста, и если рост пойдет, то всегда есть возможность вынести из монолита этот легаси-кусок в отдельный микросервис, который запилит уважаемый разраб за овер дофига бабла, т.к. бизнес вырос и способен это осилить.
Nbx
10.06.2022 17:51-2Ну вообще Сережи — ценный ресурс.
Есть два сценария — Серёга начинал новый проект и наговнокодил там с самого порога. Тут конечно оправданий не много.
Второй (и самый частый), что Серёга пришёл туда где уже наговнокодено до нас, за десять лет, десятком разных людей, с разными стилями, уровнем знаний и т.п., но Серёга смог понять, простить и может с этом всем разобраться и сделать то что просят. Тогда Серёга герой и заслуживает печеньки с полочки.
А если он ещё и правилом бойскаута пользуется, то вообще молодец.
SergeyUstinov
10.06.2022 22:49+1Серёга пришёл туда где уже наговнокодено до нас, за десять лет, десятком разных людей, с разными стилями, уровнем знаний и т.п.
В статье рассказывается не просто о неком условном софте, а конкретно об 1С.
Если вы не в курсе, что это такое, то вот:
«Товары на складах»
«Товары организаций»
«Товары переданные»
«Товары полученные»
«Товары к получению на склады»
«Товары к передаче со складов»
«Товары к передаче организаций»
«Товары в резерве на складах»
«Партии товаров на складах»
«Партии товаров переданные»
Это список регистров, в которых хранится движение товаров в одной из стандартных конфигураций. И да, это дублирование. И да, на практике в данных появляются расхождения...
С 1С не надо 10 лет ждать, пока наговнокодят. )))Мне вот даже интересно - если у разработчиков из 1С спросить, слышали ли они о нормализации базы данных - им хоть немного стыдно будет? :)))
Nbx
10.06.2022 22:53С 1С не надо 10 лет ждать, пока наговнокодят. )))
Я думаю что «говнокод» в 1С не подразумевает что изначально, стандартные конфигурации это «говнокод».
Так что их «говнокод» должен быть вполне специфичный.SergeyUstinov
10.06.2022 23:21Если их рекламщики рассказывают, что "это не баг, а фича" - проблемы никуда не исчезают.
Типовые конфигурации часто "провоцируют" писать не очень хорошо. Когда у тебя выбор - или за час-два написать, но говнокод, или правильный код, но за 15-20 часов - тяжело убедить заказчиков, что надо писать правильно.
Впрочем, может за последние 7 лет что то поменялось, я давно с 1С не работаю. Но - сомневаюсь.
Nbx
11.06.2022 15:54Типовые конфигурации часто «провоцируют» писать не очень хорошо.
Я имел ввиду что «говнокодом» будет считаться нечто по сравнению с этим подходом. Т.е. есть некий подход и подовляющее большинство так делают, то не зависимо ни от чего, это не является говнокодом. Но Серега пишет код, который даже по сравнению с этим кодом является «говнокодом»
GBR-613
10.06.2022 12:35+2Во-первых, в 70-е года такой подход был стандартом.
Во-вторых, главная настоящая проблема такого подхода в том, что такой код слишком сложно поддерживать другим. Вот это и надо было объяснить начальству: что вы будете делать, если Сережа уйдет? Или заболеет? И Серёже надо было это объяснить, а не то, что он дурак.
Мне известны случаи, когда есть критически важный код, который работает, а новые требования к нему отклоняются уже 20 лет под разными предлогами: потому что автор не только на пенсии, но и скончался. Компании теряют миллионы и ничего не могут сделать.
Hemml
10.06.2022 12:43+10Давайте называть вещи своими именами. То, что вы называете "говнокодом", на самом деле просто сложный код, который понимает только Сережа, который его писал. А почему он такой сложный легко понять из оговорки автора про "точное выполнение заданий" -- Сережа пишет код так, чтобы клиент получил в точности то, что заказал -- все кнопки и цвета на своих местах. Для этого ему приходится наворачивать сложности. Другие программисты в конторе пишут простой и понятный код, красивый, по гайдлайнам. Но этот простой код не удовлетворяет клиентов (они не видят код, они видят результат) на 100% и они хотят Сережу. Странные они.
Вообще, вы не задумывались почему программисты старшего возраста (то есть, с многолетним опытом работы), поголовно вот такие "Сережи"? Они просто умеют писать сложный код, читать сложный код и править сложный код так, чтобы он работал. И пользуются этим умением, чтобы получать нужные результаты, посмеиваясь про себя над "студентами".
На самом деле, существуют способы писать сложный код просто, но для этого надо использовать правильные инструменты. Например, функциональное программирование. Такие языки, как Lisp и пр. Но до них надо дорасти. Я вполне допускаю мысль, что если Сережа случайно прочтет SICP (о, бойтесь этого!) и, потом, не к ночи будь помянут, "Common Lisp Recipes", то он начнет писать код красиво и еще в несколько раз быстрее. Но вы этот код понять не сможете от слова совсем. Впрочем, это будет иметь мало значения, потому что ваш отдел сократят в полном составе, так как Сережа будет справляться один со всей работой.
FanatPHP
10.06.2022 12:48+3Давайте называть вещи своими именами, в этой выдуманной от начала до конца истории каждый понимает под говнокодом своё. Причем степень приближенности к тому, что закладывал автор (а это совсем нехитрая мысль о том, что чем хуже на системном уровне сделана задача, тем меньше денег клиент принесёт своими запросами впоследствии) зависит от умения читать и воспринимать художественные тексты вообще, и степени туннельности зрения в частности.
SwingoPingo
10.06.2022 13:03+12Самый распространенный вариант говнокода на моем жизненном пути это описание в "модулях отвечающих за общую концепцию" каких то конкретных сиюминутных случаев. Именно для того, что бы "быстро и четко".
Если встает вопрос что операторы должны поделиться на функции ввода и контроля ввода говнокодер напишет следующее:
" if operator.Name == "Ivanov" then ...
дальше это превратиться в if operator.Name == "Ivano" or operator.Name == "Petrov" and time() < "13.40" and today() == "sunday" then
Потом добавится периодическая замена Петрова Васичкиным, который впрочем уже уволился год назад, но под его именем работает Галочкина со вторника по среду, если не замещает Милочкину, которая работает под учеткой Попова, т.к. сидит за его компьютером.
Никто кроме Сережи не в курсе этих перипетий и на их разбор требуются эти самые овер 200 часов кто есть кто и какие функции выполняет.
Сережа не пишет подсистему ролей, т.к. это не то, что требует клиент "здесь и сейчас". Сережа пишет все это прямо в ядро, копируя и размазывая это на весь проект тонким и не очень слоем. А потом приходит момент когда с этим необходимо взаимодействовать.
Это вот самый частый пример говнокода в моей жизни.
Hemml
10.06.2022 14:04+5я могу сказать, почему Сережа не пишет сразу подсистему ролей -- потому что эта подсистема клиенту не нужна и у клиента возникнет закономерный вопрос, почему он должен платить за разработку ненужного ему кода. Если ему впоследствии потребуется система ролей, то Сережа напишет и ее. Но, из вашего же примера видно, что система ролей не нужна и в последствии. Если у клиента 2 (два) оператора и одному надо запретить определенные действия в воскресенье утром, то городить отдельную таблицу, придумывать интерфейс к ней, прописывать права доступа уже к этому всему (еще одна система ролей?!), обучать клиента работе с ней, писать документацию, чтобы клиент в красивой форме вписал это правило и забыл про нее на следующие 10 лет -- оверкил. Сережа прав.
SwingoPingo
10.06.2022 14:23+8Сережа мог сделать вид, что такая подсистема у него есть и вместо всего этого ifthen-а (понятного только ему и заказчику (вернее тому представителю заказчика, актуального на момент задачи и который тоже уже уволился)) и вставленного в самых неожиданных местах, написать объект/подсистему Rules пусть и с одним длинным текстом одной экспортной функцией boolean isAccess(context) . И в этой функции любым приятным ему образом генерить false или true в зависимости от контекста работы и чего он пожелает. Это не слишком отличается от предыдущего по смыслу и трудозатратам, но это локализует говнокод в одном месте, а локализованный говнокод уже не является говнокодом. Это подготовленный к обработке техдолг.
Но нет. Пока жив и творит Сережа этому не бывать.
fixin
10.06.2022 17:05+1Ксати да, такие затычки надо выносить в одно место. Но к этому надо тоже прийти.
Когда сам приходишь сопровождать код за другими, начинаешь писать так, чтобы было понятно тем, кто придет за тобой.
bohdan-shulha
10.06.2022 14:25+2Система ролей в данном случае может выглядеть и простым пятистрочным конфигом + одним единственным сервисом, который умеет читать его и говорить "да"/"нет" на запрос доступа от конкретного юзера. 2 минуты подумать, 15 строк кода и Серёжа неправ.
Хорошая архитектура это не про "давайте юзать r/w базу везде и к каждой сущности добавлять инструмент управления", а про поддержку, расширяемость и адаптирование к новым требованиям.
IvanSTV
10.06.2022 14:42-1вы правы. Но в частностях могут быть нюансы - например, система ролей прописана, но в другой части системы, и надо ее только подтянуть к текущей операции. Если условный Сережа не знает архитектуры системы в целом и не подозревает, что можно добавить тип роли и подключить готовый модуль,, то будет наворачивать систему условных операторов, и на каком-то этапе замена Петрова Васечкиным пойдет тяжело.
Встречал такие штуки в системах - есть четкие настройки, все настроили, и - бац... не работает (последний случай, который вспомнил - не было открыто поле для редактирования). Начинаем выяснять, оказалось, что для конкретно одного локации прописано свойство закрытого для редактирования.
fixin
10.06.2022 17:05вот например, в той же 1С типовая система прав доступа, это ад.
поэтому вполне логично не влазить в нее, а писать сбоку припёки.
starik-2005
10.06.2022 14:37+1Я, помнится, как-то заморочился над системой замещающих, но ею попользовались пару раз и забили бот. Но и у меня на этот бизнес-процесс со схемой и всем таким прочим, включая полную привязку ко всем другим процессам с исполнителями, ушло совсем немного времени.
В той же конторе мы сделали таблицу с периодическими константами и кеширующую функцию, которая эти константы поставляла в код. В итоге вместо if(User == "Ivanov") было что-то типа if(User == getGlobalConstData("MegaUserForXXX")). Ну это совсем упрощенно если. Это как раз использовалось в последствии очень активно.
ХЗ, я хоть и Сережа, но я как-то не могу писать код не по стандарту. Если только в статьях, но там нет говнокода - там есть переменные из одной буквы, которых в продуктиве у меня нет.
SwingoPingo
10.06.2022 14:47беда в том, что задача: "В воскресенье с моего компьютера мой зам будет подготавливать для меня урезанный/расширенный отчет" будет выполнена буквально.
Прямо в запросе к данным появятся имя компьютера и день недели. "Быстро и точно" все в точности как заказчик заказал. Впрочем я не прав. Во всех запросах к данным.
shornikov
10.06.2022 20:22Но сережин вариант работал и в первый день и через год, когда дела пошли в гору и добавилось еще 2 сотрудника.
А система ролей - запускалась бы неделю.
Один if добавить сильно быстрее и ничего не ломается.
Потом - in_array, затем список человеков из файла, затем... Да к черту, для 100 человек можно остаться со списком в файле и делать что-то более важное, чем админку для сотрудников, которые меняютя раз в 2 года
F0iL
10.06.2022 14:09+2То, что вы называете "говнокодом", на самом деле просто сложный код, который понимает только Сережа, который его писал.
Да, если этот код не может понять и поддерживать никто кроме Серёжи, то это весьма вероятно говнокод. Потому что чем сложнее код, тем качественнее и понятнее он должен быть написан: с четкой структурой и разделением на модули/функции/блоки, говорящим сами за себя названиями сущностей, отсутствием неявной и неочевидной магии (а там, где без нее не обойтись - с подробными комментариями, как она работает и зачем она там нужна), заложенным запасом прочности и гибкости (чтобы при необходимости добавить одно условие не было необходимости перепахивать все в десятках неочевидных мест, которые помнит только Сережа, и т.д.).
Вообще, вы не задумывались почему программисты старшего возраста (то есть, с многолетним опытом работы), поголовно вот такие "Сережи"?
Нередко потому что период их молодости, проф. роста и солидной части карьеры пришелся на времена, когда а) по-другому не умели б) продукты/задачи не были настолько сложными и долгоиграющими, и по-другому и не требовалось. В итоге они тупо делают так, как привыкли, гибкость ума в связи с возрастом чтобы менять привычки и осваивать новое уже не та, что раньше, и поэтому все даже максимально справедливые замечания воспринимаются в штыки без каких-либо контраргументов по принципу "молчи щенок,
я воевалпоработай с мое, а потом рот открывай". Правда, когда к ним с замечаниями и предложениями приходит другой такой "старшевозрастной программист", но не страдающий олдскульностью и закостенелостью, и которого задавить возрастом и авторитетом просто так не получится, можно наблюдать очень интересное шоу с интересными результатами :)Hemml
10.06.2022 14:59когда к ним с замечаниями и предложениями приходит другой такой "старшевозрастной программист"
...вы можете через некоторое время наблюдать двух сильно нетрезвых программистов, стоящих в коридоре в обнимку (чтобы не упасть) и обсуждающих какие-то высокие материи))
fixin
10.06.2022 17:03О точно, у меня был период когда я испражнялся от ужаса, встречаясь со сложным кодом. Потом преодолел этот барьер и сейчас сам пишу такой код, от которого мегабайты замерзают в воздухе от страха
axmct
10.06.2022 19:49+3То, что вы называете "говнокодом", на самом деле просто сложный код, который понимает только Сережа, который его писал. А почему он такой сложный легко понять из оговорки автора про "точное выполнение заданий" -- Сережа пишет код так, чтобы клиент получил в точности то, что заказал -- все кнопки и цвета на своих местах.
"Сережа" херачит бизнес-логику прямо в обработчике кнопки на форме вместо выделения данного кода и размещения в классе/таблице. Или меняет базовый класс там где в этом просто нет никой необходимости. Или добавляет поля в системную таблицу там где должен создавать свою. И прочее, прочее.
Поймите, в таких системах, это не про код на экране сложный к пониманию, а в следовании принятого в конкретной системе. Не важно что в твоих машинах под капотом, вопрос в том чтобы ты не бросал их посреди дороги других.
Вообще, вы не задумывались почему программисты старшего возраста (то есть, с многолетним опытом работы), поголовно вот такие "Сережи"? Они просто умеют писать сложный код, читать сложный код и править сложный код так, чтобы он работал.
Да ни при чем тут возраст. Выворачивает не от сложности, а от чужеродности стиля/подхода/структурирования кода для данного места. Все должно быть на своих местах не просто так.
И когда, в системе подразумевается определенное место для данного кода, а его пишут одной процедурой да еще и не на том слое, в силу незнания продукта/системы, это не признак умения писать сложный код. Это полный провал в понимании паттернов и гордится тут нечем.
WASD1
10.06.2022 14:51+3Э... вообще-то "метод Серёжи" - это удешевление разработки взамен увеличения технического долга.
И применять или нет такой метод - зависит от жизненного цикла приложения.
Если я пишу скрипт автоматизации, который мне надо 2 раза запиустить и лог которого я буду проверять глазами - то я и напишу ровно такой скприт автоматизации + юнит тесты.
А "интеграционное тестирование" проведу методом "grep -r ........"
Ничего в этом зазарного нет.
NikRag
10.06.2022 15:02+3В бизнесе существует ровно два вида результата: работающий в срок и любой другой. Сережа делает первый вид, и клиенту это обходится дешевле других вариантов - по факту.
Если в 77й версии обнаружатся непреодолимые костыли, или Сережа подвергнется фактору автобуса - то это полностью ответственность заказчика, задача руководителя конторы обозначить риски. Как правило, заказчики не настолько тупые в плане денег (как их представляют себе пишущие правильный код программисты ^w), чтобы не понимать, что чем дешевле сразу, тем дороже потом переделывать.
Если совсем конкретно, то лучшее из виденного мной - привязка сереж за конкретными заказчиками, и введение таких независимых стабильных связок типа-фриланса. Сережа не лезет в другие проекты, другие не лезут в сережины, перед клиентом отвечает начальник.
RemiZOffAlex
10.06.2022 15:21+1Забавно. Синдром Д'Артаньяна, а в случае автора со слов автора целой команды Д'Артаньянов-программистов вместе с автором. Они конечно очень хорошие ребята, никогда не говнокодят, и клиенты вообще не понимают что им в жизни надо без программистов. Ну а кто им ещё об этом скажет, как "неговнокодеры", в чём они всегда не правы.
maxlilt
10.06.2022 15:57Есть другая сторона вопроса. Если программисты предлагают громоздкое общепринятое решение, универсально работающее у конкурентов, но оно медленнее, неудобнее для конечного пользователя, и не позволяет вносить серьезных изменений.
nikolas78
10.06.2022 16:40+2По-моему, тут основная проблема в том, что современная техническая база (яп, библиотеки, фреймворки, иде, и т.д) не в полной мере отвечают потребностям бизнеса. Отсюда и «говнокодистые», но сверхпопулярные Python, 1С, Cobol (когда-то), и т.д. Возможно эту часть задач на себя возьмет low-cod/now-cod (что бы это не значило), DSL или что-то другое.
BiW
10.06.2022 17:49+2Настоящие программисты узнали, что ПО должно решать проблемы бизнеса.
Все это очень, конечно, хорошо, но вот был я на проекте, представлявшем смесь красивого кода и быдло-кода. Причем смесь жуткую. А причина очень простая - когда-то написали, через некоторое время разрабы сменились, а еще спустя некоторое время выяснилось, что нужно дописать фичу, подправить тут и там, добавить новые API... И все. И никто это рефакторить не будет - заказчик не готов платить за переделывание того, что и так работает, а как там оно, под капотом - заказчику глубоко до одного места.
Знаю контору с очень сложным и очень кривым API, обслуживающим очень крупных клиентов(связь). Дока на API датирована 2009 годом, содержит сотни(sic!) методов, возвращающих XML по 15000-20000 нод. Текущая команда разработчиков вообще неотдупляет что половина API делает, тупо проконсультировать никто не может, разрабы, которые этот API писали давно уволились и неизвестно где. Каждый фикс занимает неделю и не всегда работает. Зачастую вместо фикса предлагается использовать костыль, который позволяет обойти проблему....
Я не призываю писать говно-код, я просто хочу сказать, что, если чо, я просто говорю, что в реальности очень часто желания разработчиков писать по правилам и желания клиента не совпадают. И тогда на сцену выходят Сергеи.
peacemakerv
10.06.2022 19:18Говнокод был и будет всегда. Но суть-то в том, что заказчики есть такие, которые готовы платить за то, чтобы обязательно "правильно от профессионалов", и те - которым надо "вот такую колонку в таблице" - и никак иначе ("и ваши профи-советы не нужны, я же башляю").
И, вероятно, дело даже не столько в деньгах и сроках - а вот в именно психологии человека-заказчика, в хотелках.
nivorbud
10.06.2022 19:56+1В принципе во многом согласен. Какая архитектура "правильная" нет смысла обсуждать, пока в полном объеме не ясны автоматизируемые бизнес (и пр.) процессы, пока не ясно, в какую сторону и как будет развиваться бизнес. Вопросов много, а ответов для нового бизнеса мало. Неправильно выбранная "правильная" архитектура зачастую будет хуже кода "на коленке".
Что касается стиля программирования, принципов именования, разделения на функции/классы и пр. - это сильно дискуссионный вопрос, скорее вопрос личных предпочтений. Например, я всегда жалел, что вводил лишние абстракции и промежуточные слои (типа на будущее). На практике почти всегда в итоге было лучше делать проще, прямолинейнее и понятнее.
Также почему то не люблю разбиение на множество мелких функций/методов. Проглядывая чужой код, не раз ловил себя на мысли, что меня раздражает перемещаться по сотням микро функций (в несколько строк), да еще разбросанных по множеству библиотек. С другой стороны, спокойно читаю код например Wagtail, где файл может содержать несколько тысяч строк.
Ну, и самое главное - скорость запуска проекта и... вообще вероятность запуска. С "правильным" подходом дело до запуска может вообще не дойти. Это конечно новых проектов в основном касается. Ну, а когда бизнеспроцессы устаканятся, вступает в силу старый программисткий принцип: работает - не трогай.
Fen1kz
10.06.2022 21:30+4Ситуация — прихожу в стартап ещё до релиза, а там до меня на фронте работал такой Сережа. А именно — клиент доволен, все сверстано очень точно, а внутри — копипаста на копипасте, непонятные конфиги ради конфигов и компонентов с кучей if.
Например, у стандартных "панелей с тенью" из материал дизайна убрана тень, а потом вручную добавлена через style.
Или зачем делать нормальную верстку чтобы один из "под-хедеров" знал свою ширину и менялся в зависимости от неё, если можно после каждого обновления данных вручную вызывать функцию пересчета на сотню строк, которая его идеально выставляет как надо.
Только одна маааленькая проблемка — сережа ушел, а теперь надо все это великолепие синхронизировать с беком. Упс.
Конечно повезло с СЕО который давал время рефачить (хотя не факт, возможно он думал что интеграция занимает столько времени), а я в это время брал компонент под интеграцию и выжигал там всё напалмом.
В итоге первые полгода, наверное, мои коммиты добавляли фичи, уменьшая общее количество строк. И, видимо, перформанс был на уровне с Сережиным, вопросов не было.
А вот через год выяснилось, что если они верстали примерно год 4 раздела, то 5ый раздел добавляется за 2 недели.
Или что ушли странные баги типа "на пути А-Б-С летит верстка. да только там".
Вопрос с точностью я решил договором с дизайнером, которая пошла навстречу и сделала полноценный стайлгайд и (вот за это ей прям большой респект) придерживалась его. То есть у нас реально было 8 стилей текста, прописанных в теме и она честно рисовала дизайны с этими стилями.
Конечно до сих пор есть с͏̨͝т̴а̵͟р̸̨ы̨е ͞҉ра҉з͘д̛͘̕е͘л̀͠ы̷̡, с хелпом например, где поверх текста из темы наверстано куча стилей которые делают его таким же, но туда никто обычно не ходит.
Разгадку этой истории вижу во фразе
Но сработал закон Вселенной – чем больше задач клиента ты решаешь, тем больше их становится. Серёжа перестал справляться с возрастающим потоком.
Ну надо же! Кажется что из-за хотелок клиента, но, сдается мне, это из-за возрастания сложности.
А программисты провафлили, надо было не переписывать всё с нуля, а просто заменять компоненты, а если их в этой каше нет — резать и заменять на отдельные, тестируемые, изолируемые и бла бла. На этой ещё больший скилл нужен, чем сразу красиво сделать.
Для пущего эффекта можно было подождать некоторое время, потому что чем больше функционала, тем медленнее работает Сережа.
С другой стороны да, это стоит бОльших денег, а если надо дешево — тут Сереже нет равных, согласен.
mvv-rus
10.06.2022 23:39Долго думал, где я видел сходную проблематику. Потом таки вспомнил юность и осознал, что Серёжа — настоящий программист, хотя, возможно, он даже не знает Фортран.
Пока существуют плохо поставленные задачи, странные
ошибки и нереалистичиские расписания машинного времени, будут
находится настоящие программисты, желающие взять на себя и
решить проблему, оставив документацию на потом.nmrulin
11.06.2022 01:48Автор кстати провидец - предсказал, что "настоящие программисты" в будущем пересядут на Си :-)
Ну и также Pascal он явно недооценил, т.к. многие программы на нём вылетают с Access violation , а многопоточные программы вообще требуют особой квалификации настоящего программиста.
vkflare
11.06.2022 00:29+3Читаю и узнаю себя. Я тот самый условный Сережа, который админил линуксы и кодил деплойменты на fabric еще до появления этих ваших ansible, потом, насобачившись писать скрипты и все еще будучи админом, начал решать более сложные задачи, потому что понял, что могу. Залез и в анализ данных, и в микросервисы, уяснил пару популярных паттернов проектирования и ООП, потому что остро встала проблема переиспользования своего же кода. Потом появилось магическое слово "DevOps", и я, сменив три конторы, продолжал говнокодить свой рокет-сайенс и какие-то задачи по автоматизации, при виде которых прочие девопсы обычно разводили руками.
И в течение ВСЕГО этого времени у меня не было толкового ментора, который ткнул бы меня носом в мой говнокод и объяснил бы, что я делаю не так.
Излагаю свой крик души и воззвание ко всем программистам. Если к вам приходит админ в поисках ментора в обмен на knowledge transfer по k8s/helm, или просто за пиво/банку смузей - не отказывайте ему. Возможно, этот админ потом переведется в ваш департамент и вам придется работать с ним вместе, как пришлось это делать программистам из коллектива Сережи.
gBACTAKAHA
11.06.2022 01:38+1Вот поддержу! Я всю жизнь занимаюсь только тем, что мне нравится. Это мое дело. Ментора, советчика, критика, гилдмастера, ревьюера у меня никогда не было, я всю жизнь читаю чужой код и разбираюсь в нем со временем. Образование не профильное. Не было тогда профильного в доступности. Я Серёжа, так сложилось, что я люблю разбираться в непонятном, мне хочется решить чью либо проблему, но оценить верно я могу только опираясь на свой опыт. Вся деятельность не приносит миллионов, но удовольствие от решенной задачи(своей, клиента) бесценно.
Поделюсь примером. Недавно был опыт(первый работы по найму в студии, где ребята моложе меня на 10 лет в среднем). Была задача спарсить кучу инфы из разных источников. Ведущий программист требовал месяц и приступил к работе по написанию парсера и обработке данных. Я не обладая компетенциями этого человека решил с помощью стороннего софта и if else итд, за неделю... Задача должна быть решена максимально эффективно, а не красиво.
.
tac
11.06.2022 07:21Клиентам - совершенно неважна лирика про архитектуру, Сережа - просто демпингует на рынке, ну и понятно, что история не реальная - лирика ... вообще, я вначале посмотрел бы код Сережи, может так статься, что и не так все плохо, т.к. "мозги" испорченные паттернами восстановить иногда еще сложнее ... но и обратный случай был только был это Каспарс - уволился под моим нажимом ... но начальство хорошо вспоминало, потому что я просил адекватную зарплату, а он работал сколько давали, а клиенты хотели скидку с демпинговой цены гос. закупок ... в итоге не бизнес, а утопия. Может и правда, пусть Сережа программирует, и по ночам исправляет свои баги, потому что клиенты уже не хотели платить за поддержку ... А зажравшимся мордам как я лучше найти коммерческую разработку, а не по гос. дешевизне, чтобы есть пельмени и пахать как индус 12 часов
Ах, да ... походите на Агил сброды, послушайте менеджеров о их пользе, и тогда Сережа будет идеальным для вас программистом ... Только не забываете, что это не больше чем психологическая атака, чтобы сбить цену разработки за счет программистов.
Удалите менеджерский сброд, и Сереж в компании, автоматом не будет
ninJo
11.06.2022 08:31+1Только за то что Сереже важна точность интерфейса дал бы ему плюс +10 пунктов перед другими программистами.
Зачастую программисты пренебрежительно относятся к верстке, высокомерно считают что это ниже их достоинства делать точную вёрстку в соответствии с дизайном. Зато код который никогда никогда не увидит кроме них самих должен быть идеальным.
entze
11.06.2022 11:24Сиюминутная точность под конкретные данные. Очень точно сверстанный летом сайт, но который при -10 на улице минус сожрет, потому что Сережа сделал лютую дичь под непродуманный дизайн. Сережа быстро поправит, клиент будет доволен.
ninJo
11.06.2022 11:31-4Лучше так чем программисты уверенные в собственной гениальности делают что-то вообще отдаленно напоминающее исходный дизайн, а потом нужно еще столько же времени на исправление багов интерфейса.
Почему сразу точно не сделать? Перед тем как вообще написать хоть строчку кода нужно вместе с дизайнером и заказчиком пройтись во дизайну и проверить учтены ли все случаи..
entze
11.06.2022 11:58+1Не лучше. И что значит «точное соответствие дизайну»? Под Loren ipsum на 1 макете вместо десятка? Под 1 десктопное разрешение? Про «отдаленно напоминающее» и тут же про красивый код - как минимум странно. «Вместе с дизайнером и заказчиком» - это в какой вселенной?
ninJo
11.06.2022 12:16-4Сразу видно токсично- истеричное поведение...
Делать как в дизайне означает если шрифт размером в 18 пикселей, значит он должен быть и верстке 18, а не 20 или 16. Тоже самое с расстояниями, цветами и т.д. это делается не так сложно. К сожалению, разные личности вроде вас пренебрегают точностью, делают невнимательно и в итоге приходится либо переделывать по сто раз, либо махнуть рукой и оставить как получилось. За это Сереже респект, он делает точно.
Я не знаю в какой вселенной вы живете, в моей вселенной перед разработкой каждый дизайн проходит детальное обсуждение, после чего если нужно дизайнер дорабатывает некоторые моменты. Всего заранее предусмотреть физически невозможно конечно, потом уже бывает всплывают некоторые упущения, хороший разработчик сразу же обратится по этому поводу к дизайнеру или менеджеру и они вместе найдут решение.
DrPass
11.06.2022 12:49Делать как в дизайне означает
В контексте данной статьи «делать как в дизайне» означает «разместить поле прямо по центру, где просил клиент, и выделить его жирненьким, как он просил, а не следовать общим гайдлайнам UI приложения».ninJo
11.06.2022 13:04Не знаю откуда вы взяли этот контекст, в статье написано следующее:
"Особенно важна точность интерфейса, включая цвета, шрифты, названия и порядок колонок и т.д."
И это действительно важно. Почему-то многие пренебрегают этим. Если есть дизайн система и дизайн ей не соответствует, то это проблема с дизайнером, а не с разработчиком.
DrPass
11.06.2022 16:00И это действительно важно.
Важно это или нет, целиком зависит от того, о каком продукте идёт речь. Если мы говорим о корпоративном софте (а default-soft у автора nmivan, к слову, 1С), в процессе его разработки часто вообще не существует никакого дизайнера, или в лучшем случае он пропишет общий стиль приложения, но не будет прорисовывать все формы и таблички.
Ну и насколько это важно, тоже вопрос. Дизайн важен с точки зрения брендирования и просто профессионального вида приложения. Разработать же качественный дизайн с точки зрения юзабилити и «юзер экспириенс», ну так в корпоративном софте такого не бывает. Это сказка, которую вам расскажут разве что внедренцы, пытающиеся продать услуги своего дизайнера. Реальный «юзер эксириенс» вам может дать только сам юзер по обратной связи.ninJo
11.06.2022 16:28-1Если нету дизайнера - то не о чем говорить, пусть делают как хотят :)
-
В данном конкретном случае речь идет не об юзер экспириенсе хороший он или плохой, тяжело его создать или легко, а про то что расхождения между дизайном и версткой должны быть минимальными.
Если компания работает с заказчиками (случай из статьи), то почему вы вдруг решили что неважно чтобы в дизайне и верстке цвета, размера шрифта и порядок колонок(!!!) могут различаться и что это вообше не важно? Заказчик предоставил дизайн, заплатил деньги - почему вдруг вы решаете забить на верстку?
Я не собираюсь вступать в спор о том насколько важен дизайн, но один из параметров качества разработки это соответствие дизайну.
И если макет и верстка выглядят примерно следующим образом как картинка снизу, то значит фроентенд разработчик делает свою работу плохо и ничего больше.
И это происходит зачастую засчет того, что почему-то многие разработчики работают по типу: "Да ну дизайн не важен, ииитак сойдет". В конечном итоге получаются кривые недоступные сайты с плохим юзер экспириэнсом.
Поэтому повторю еще раз, Сереже +10 очков за точную верстку.
https://i.kym-cdn.com/entries/icons/facebook/000/031/680/unfinished_horse.jpgDrPass
11.06.2022 16:42+2Если компания работает с заказчиками (случай из статьи), то почему вы вдруг решили что неважно чтобы в дизайне и верстке цвета, размера шрифта и порядок колонок(!!!) могут различаться и что это вообше не важно? Заказчик предоставил дизайн, заплатил деньги — почему вдруг вы решаете забить на верстку?
Вы немного не понимаете, о чём речь :)
Нет там скорее всего никакой вёрстки даже как вида работ. Автор имеет в виду типичную ситуацию при разработке форм для бизнес-пользователя.
Есть какой-то общий принцип построения интерфейса, общий гайдлайн — поля имеют такой-то шрифт, цвет, расположены в такие-то колонки и т.д.
Что делает конечный пользователь, если у него есть прямая коммуникация с разработчиком, минуя аналитиков, менеджеров проекта и т.д.? Он заказывает: вот тут на форме отгрузки сделайте мне поле «Сумма ТТН» 18 кеглем, и красным, если по клиенту есть просроченная дебиторка. Это нарушает все гайдлайны, смотрится дико колхозно, и вообще правильнее было бы сделать проверку дебиторки ещё до того, как она логисту падает на оформление отгрузки… но в этой конторе так сложилось, её проверят логист. И заказывает доработку он, ему так удобнее, да, колхоз, но он будет меньше совершать ошибок.
Опытный программист начнёт рассказывать, что это смотрится ужасно, нарушает гайдлайны, и вообще надо переделывать бизнес-процесс. А Сережа просто сделает страшно, но зато как заказывали, клиент доволен.
Вот так оно в реальной жизни и выглядит.ninJo
11.06.2022 17:29Понятно, спасибо за объяснение. У меня из статьи (и личного опыта) сложилось впечатления будто в процессе участвует дизайнер :)
Если дизайна как такого нету, но есть гайдлайны (дизайн система) - которые клиент хочет "нарушить", то это конечно не очень практика.
entze
11.06.2022 19:15Хамить не стоит. Вы же написали, что главное точное соответствие, а не идеальный код, верно? Я вам ответил, что говнокод при точном соответсвии дизайну ещё хуже. Речь не идёт о несоответствии в цветах, размерах шрифтов. Это вообще недопустимо. речь идёт про подгонку результата под макет пофиг какой ценой.
Про детальное обсуждение и доработки и все такое - лукавите. Либо у вас процесс без сроков и результата.
ninJo
11.06.2022 19:40Я говорил исключительно в контексте того что описано в статье, а там речь шла именно о цветах и размерах шрифтов.
Есть у нас и сроки и результаты. Обсуждение дизайна с разработчиками обязательный шаг, в конечном итоге экономит огромное количество времени. В ходе обсуждения очень часто всплывают недоработки в макетах
wrk9
11.06.2022 08:52-1Сережа делает быстро и дешево, а остальные ему завидуют. В ТЗ был пункт про масштабирование? Про понятный код? Ну и все, Сережа вас всех уделал. Зачем бизнесу платить в несколько раз больше и ждать дольше? Надеюсь Сережа откроет свою компанию, где будут брать только кодеров из ПТУ.
F0iL
11.06.2022 12:19+2Сережа всех уделал потому что взял в долг и не вернул (пока). Когда настанет время возвращать техдолг, "все остальные" продолжат делать как делали, а Сережа будет тратить все больше и больше времени и сил на разгребание своего говна вместо того чтобы пилить новые фичи, в итоге придется бизнесу "...платить в несколько раз больше и ждать дольше". А если Сережа возьмет и свалит, то весьма вероятно следующий исполнитель, взглянув на его творения, согласится их поддерживать только за двойную оплату.
DrPass
11.06.2022 12:53+4Когда настанет время возвращать техдолг
Из моего уже опыта поддержки корпоративного софта, с 90-х и уже до седых волос, могу сказать, что это время скорее всего не придёт никогда. Ну точнее, оно значительно превышает среднее время жизни одной учётной системы на одном предприятии. Поэтому бизнес от «тяп-ляп» скорее всего таки останется в профите. Исключения бывают, но это именно исключения, а не общее правило.
blessHammer
11.06.2022 08:52+3Специально зарегался на Хабре, чтобы прокомментировать. Я сам был и в роли говнокодера и в роли специалиста, который воспринимает BestPractice, как Библию. Многие разработчики прикладного ПО, в отличие от Серёжи, пребывают в иллюзии, считая себя творцами чего то вечного и незыблемого. В реальности же код ваш проживёт лет 5-7 если повезет. За это время однозначно что то произойдёт: сменится парадигма разработки, появятся новые фреймворки, новые технологии и под них новые протоколы и языки, прилетят инопланетяне, рак на горе свистнет и т.д. Обычно бизнесу нужно решение здесь и ещё вчера и подешевле. Ему нет дела до абстрактных красот ООП и всей этой ереси инкапсуляции и полиморфизма.
askharitonov
11.06.2022 09:03+1Без подробностей сложно понять, кто из них прав, можно увидеть разные варианты: можно додумать ситуацию так, что прав Серёжа (и может у него вообще не говнокод, может он разбирается в предмете лучше коллег, которые не могут понять его код (а ему, в свою очередь, сложно ограничивать себя и делать так, чтобы они поняли), а можно её додумать так, что Серёжа копит техдолг и просто не успел обжечься на каких-то плохо продуманных решениях.
F0iL
11.06.2022 12:17+1(и может у него вообще не говнокод, может он разбирается в предмете лучше коллег, которые не могут понять его код)
Как бы он хорошо не разбирался и каким бы сложным не был код, если этот код не может понять и поддерживать никто кроме Серёжи, то это весьма вероятно говнокод.
askharitonov
11.06.2022 13:03-2Можно придумать ситуацию, когда это не так. Представь, что один из программистов вместо пузырьковой сортировки использовал более оптимальный алгоритм, а другие его не знают. И для них это может выглядеть это может так, что код переусложнён и вообще непонятно как работает. В таком случае наверное правильнее повышать квалификацию остальных программистов, а не ограничиваться примитивными и неэффективными алгоритмами?
F0iL
11.06.2022 19:56+2Если Сережа сильный и опытный программист, то в таком случае для него правильным и естественным будет указать в комментариях в коде название алгоритма (чтобы все его не знающие могли легко нагуглить и понять, что это и как оно работает) и причины, почему он использовал именно его, а не что-то из стандартной библиотеки или более простое. И все, никакой проблемы для других разработчиков, все становится понятно и логично.
Но вообще ваш пример высосан из пальца, обычно "говнокод сережа-like" сводится не к квиксорту вместо пузырька, а к чему-то типа такого.
askharitonov
11.06.2022 20:41+1Ну не обязательно речь про те примеры. Вспомнилась одна дискуссия, кажется на opennet.ru, где сравнивались две свободные операционные системы, сторонник одной, для иллюстрации её преимущества, привёл код какой-то функции из обеих систем: в предпочитаемой им системе код был гораздо проще и понятнее. Но оппоненты объяснили, что во второй код оптимизирован, вроде с учётом особенностей той или иной архитектуры, и он сделает то же самое, но быстрее.
Далее, сортировка — это просто условный пример для иллюстрации (конечно, часто можно не задумываться и использовать стандартный вариант сортировки из той или иной библиотеки). Но и во многих случаях самое простое решение не является оптимальным, при этом более эффективный алгоритм не всем будет очевиден.
И я же не говорю, что это именно случай Серёжи. Исходя из того, что написано в статье, Серёжа для нас находится в состоянии квантовой суперпозиции хорошего и плохого программиста, и только в результате наблюдения (если мы посмотрим его код) он окажется тем или иным случаем.
mvv-rus
11.06.2022 19:27+1Понятность и поддерживаемость кода не являются объективными показателями. Они сильно зависят от того, кто будет понимать и поддерживать код.
Чтобы не быть голословным — вот пример реального кода на C# из библиотеки ASP.NET Core, регистрирующего самописный делегат-middlewarepublic static IApplicationBuilder Use(this IApplicationBuilder app, Func<HttpContext, RequestDelegate, Task> middleware) { return app.Use(next => context => middleware(context, next)); }ДополнительноИспользуемый здесь метод IApplicationBuilder.Use имеет сигнатуру
где RequestDelegate определен какIApplicationBuilder Use(Func<RequestDelegate, RequestDelegate> middleware);public delegate Task RequestDelegate(HttpContext context);Немного пояснений:С одной стороны, если вы знаете ФП и имели много дела с Haskel, то этот код тела метода для вас прост и понятен. С другой стороны, если вы не умеете в ФП (а C# — это не функциональный язык, он все больше про ООП, а потому для программиста на нем не знать ФП нормально), то вам придется поднапрячься, чтобы понять, что делает этот кусок кода — а ведь в той же в ASP.NET Core подобных кусков много. С третьей стороны, привычка к ФП может оказать вам медвежью услугу: компилятор C# не имеет никаких средств, чтобы гарантировать отсутствие в делегате побочных эффектов, а потому внутри такого кода может быть запрятана любая дичь, способная повлиять на самые неожиданные места, и вы об этом сразу не догадаетесь.этот метод расширения добавляет в некий список делегат-построительна всякий случай - про делегат, который принимает на вход RequestDelegate(ссылку на функцию, принимающую контекст обработки запроса HTTP и возвращающий задачу, в которой асинхронно выполняется обработка этого запроса), реализующий последующие стадии конвейера Middleware, и возвращает такой же делегат, реализующий эту и, если надо, последующие стадии конвейера.— делегат в C# — это ссылка на метод класса вместе с экземпляром класса, для которого его надо вызвать, если метод — не статическийИ такое иногда встречается:Вот и получается, что понятность и поддерживаемость одного и того же кода разными людям, даже с примерно одинаковым уровнем квалификации (и грейдом, соответственно), но в несколько разных областях, может оказаться сильно разной.например, в реальном коде ASP.NET Core я наткнулся некогда на глубоко запрятанный побочный эффект, когда разбирал как именно вызывается метод Configure Startup-класса; подробности, если кому нужны — здесь.
MyraJKee
11.06.2022 10:49+1Живописно. У нас такой Сережа был, даже много. Поэтому и код соответствующий. Однако история не такая красивая. Все работало через такую то мать, как бог на душу положит. Соответственно и бэклог на тысячи задач и десятки тысяч человеко/часов. Вместо развития приходилось заниматься практически постоянно поддержкой.
entze
11.06.2022 11:18+1Все здорово, пока Сережино поделие не торчит наружу. Как только говнокод, заключающийся обработке подразумевающихся данных в подразумевающийся результат, начинает работать с любыми данными - возникает инфобез.
MarksMan09
11.06.2022 11:35+1Все мы в какой то момент по требованию "гениальных" бизнесменов немного Сережи ...
А потом наступает момент, когда ты погребен под тоннами "говнокода", и проще с нуля, чем исправить.
entze
11.06.2022 12:04Не совсем. Бизнесмены не понимают риски или не хотят принимать, хотя скорее Сережа им не объяснил, что в долгосроке быстрый результат точного соответствия ограниченным требованиям череват. У бизнесмена горизонт планирования чуть дольше, чем Сережин результат.
Тут бы между Сережей и бизнесменом переводчика в виде проджекта. Но зачем - проджектов как минимум считают лишними, а то и ненавидят.
blessHammer
11.06.2022 20:00Вы серьёзно думаете, что бизнесмены чего то там не понимают? Всё зависит от стороны баррикады на какой вы находитесь. Если вы работаете в IT, то вы не должны допускать Серёжу до работы пока не научится, потому что это вы несёте эти риски. А если на противоположной стороне , то вы будете выбирать Серёжу, потому как быстро, дёшево и страховка бесплатная(ущерб то в случае чего оплатит поставщик услуг IT).
helluvasatan
11.06.2022 19:42-2Серёжа — личность и человек дела. А автор — просто завистливый ноунейм.
HiTawr
11.06.2022 19:42+1Интересен уровень обсуждения. Написано стоПитсот коментариев о говнистости кода, которого никто не видел
DrPass
11.06.2022 20:00+2Написано стоПитсот коментариев о говнистости кода, которого никто не видел
Комментарии не про конкретно код, а про описываемый достаточно типовой кейс. Кода Сережи скорее всего вообще не существует, как и самого Сережи. Это собирательный образ.
acordell
11.06.2022 19:42+3Не что не ново под солнцем. Не знаю, как сейчас, а раньше индусы промышляли тем, что демпинговали, переманивали клиента, забирали проект и пару лет показывали дичайшие показатели по сроку/цене. А потом, когда проект превращался уже в конкретное месиво, начинали задирать цену. Даже термин такой был "индусский код". Клиент, конечно, пытался вернуться или еще куда-то дернуться, но с таким кодом его или не бради вообще, или тоже выкатывали кусачие ценники. Скупой платит дважды.
Так и здесь, думается, что Сирожа просто свалит в какой-то момент на большие деньги, написав себе в резуму кучу лет работы ведущим программером (и это даже будет чистой правдой), а мудрое начальство останется с неподъемным куском г. и без программистов.
elegorod
11.06.2022 20:26+3В реальности клиенты бы любили Серёжу с его говнокодом только поначалу. А потом очень часто появляются странные баги в неожиданных местах. Поменял Сережа что-то в обработке заказов — часть заказов начала исчезать. И никто не узнает, что они исчезли, пока недовольный потребитель не начнёт жаловаться (а он скорее закажет то же самое на другом сайте). Поменял Сережа расчет комиссий — программа начала обсчитывать некоторых клиентов и недосчитывать зарплату части сотрудников. В малом бизнесе это, может, и прокатит, сто баксов туда-сюда роли не играют. А если бизнес побольше, так можно неожиданно потерять миллион, и это превысит стоимость разработки системы с нормальным кодом.
Также всё хорошо, пока Серёжа один и работает. А если задач стало больше, и он не справляется? Коллегу ему не нанять, он ничего не поймёт в таком коде и будет только отвлекать Сережу вопросами. А если Сережа ушел в отпуск, заболел или уволился?
Иногда бизнесу важнее минимальное кол-во багов, чтобы не терять деньги и клиентов. А стоимость и скорость разработки на втором месте. К таким проектам Сереж нельзя подпускать.
Emulyator
11.06.2022 23:08+1Знаю одну историю, когда существующая очень давно, сложная, имеющая большое количество пользователей программа стала понемногу отставать от программ-конкурентов по отдельным функциям. Новые версии выпускались, добавлялись фичи, некоторые даже опережали конкурентов, но в целом отставание росло. Одной из существенных причин отставаний был возраст программы. Технологии существенно поменялись за годы и без существенной переделки ядра, общей архитектуры, движка пользовательского интерфейса было тяжело оперативно менять и наращивать функционал, удовлетворять растущим запросам пользователей.
Руководство решило совершить смелый шаг - переписать ядро. После нескольких лет параллельной разработки новой и поддержки старой версии, случился провал. Долгожданная новая версия сильно отличалась интерфейсом от старой, а главное по функционалу была настолько урезанной в первых выпусках, что, несмотря на очевидные новые фичи и потенциал развития, она провалилась в тестовых релизах.
Последовали кадровые перестановки, уходы и увольнения как среди руководства, так и в команде разработчиков. За это время отставание от конкурентов увеличилось еще больше. И было принято решение «эволюционно» внедрить часть решений из почившей новой версии в старую, добрую, любимую всеми.
Но чуда не случилось, таланта новых привлеченных и оставшихся программистов и внедренных ими новинок не хватило, чтобы полноценно конкурировать на рынке, также можно упомянуть плохой маркетинг, и такую же обратную связь с пользователями. Несмотря на многолетнюю любовь, очень много пользователей осваивали другой софт, во время ожидания нового релиза, и слиняли окончательно после провала. Программа перестала развиваться совсем и, считай, умерла, вместе с сообществом пользователей и группой разработчиков сторонних плагинов.
Этот поток сознания написан в попытке обратить внимание, что говнокод (которого не было в принципе в этой истории) видимо не является определяющим в реальном мире, и что поддерживать и развивать написанный по промышленным стандартам продукт после смены команды тоже не сильно легко, а уход пары талантов из команды вполне может похоронить проект, как бы они красиво не кодили. Определяющим походу являются деньги вложенные в маркетинг и цена для потребителя (т.е. тоже деньги), а что там за кадром происходит – «проблемы индейцев». ))
vit1251
12.06.2022 00:21Прочитал на одном дыхании расценил как художественное произведение, но подозреваю, что это может быть действительно реальная история в небольших компаниях...
По существу истории проблема очень простая, а именно отсутствие опытного тимлида в компании, которые смог бы обьяснить корень возникшей проблемы. О самой проблеме поговорим позже... а пока разберемся как стоит действвоать в подобных ситуациях:
Первое и самое важное: любые размышления о говнокоде стоит внимательно анализировать и разбирать, а не замалчивать (докапываясь до источника претензии - исключая любые эмоции, а об этом позже), так как они могут превратиться в разновидность преследования (травли) несчастного Сереги и приводить к отавлению отношений внутри коллектива, а это самый главный залог успешной работы (при первых признаках отравления - приглашать веселую молодую HR психолога и в коллаборации с тимлидом начать разбираться с враждебынм отношением - всем ходить на шашлыки, собираться за любимым хобби - играть в игры и т.д.).
Второе это вопрос почему заказчик знает как устроена команда разработки по именам, но это уже вопрос наверное организационного плана и вроде как тех процессы во многих компаниях секрет успеха фирмы, а тут видимо или внутренний заказчик или что-то еще в любом слчуае к делу отношения не имеет, но факт любопытный.
Третье, относительно сути травли командой Сереги, который столкнулся с враждебным отношением в существующем коллективе. Проблема связана с отсутствием нормального проектного управления (думаю, что просели в области BA, но точнее нужно разбираться на месте ;). В обьяснении руководителя пропущена статья расходов - владение кодовой базой (уровнем понимания всеми участниками принципа вн. работы приложения) при "плохой" архитекктуре (говнокоде), введение нового программиста начинаеться с обучения и выглядит дороже, если нужно разгадывать загадки (проводить обратную инженерию кода) и дешевле если применять хорошо известные подходы (шаблоны проектирования) или даже использовать готовый FrameWork (который заранее знают и понимают новые участники).
Четвертое, предыдущая пробелма возникает, но только в случае отсутствия на разработку дизайн документации (да, именно тех самых занудных UML диаграммок, которые своременные команды зачастую вовсе не составляют, а получив SRS сразу переходят к разарботке) и вопрос начального обучения становиться совсем незначительным (1 час посмотреть видео с дев дизайном и ты покрыл кодовую новую базу).
Пятое, в рассказе сталкивают две качественно разные системы один разработчик и команда разработки и нужно понять, что в первом случае это действительно может функционировать быстрее, но система имеет проблемы с масштабированием, а вот вторая система имеет накладные расходы (зачастую игнорируемые и превращающиеся в технический долг) при координации работы, но при должной организации позволяет бесконечно наращивать команду и сложность решения. Ответственный за масштабирование команды наверное стоит возложить на руководителя или тимлида.
vconst
12.06.2022 06:40+1Эммм…
Я не разработчик, так — рядом постоял и маску на стройке нашел. Но разве не на Хабре постоянно приводят в пример байку: «Пока Петя разрабатывал план — у Васи уже было костыльное приложение, которое скачивали и платили. Когда Петя выкатил идеально написанную прогу — ее никто не смотрел даже, потому что Вася уже всех подсадил на свою и потихоньку рефакторил костыли.»
Вроде обычный цикл, когда нужная фича быстро и костыльно запиливается, а потом рефакторится, когда довольный клиент уже за все заплатил. А в кост закладывается как срочный говнокод, так и последующее приведение его в порядок, все при деле и все довольны, а приложение потом не рассыпется, когда придется масштабировать.
Sa6aH
12.06.2022 10:43+2А мне до сих пор непонятно "особое" отношение заказчиков к программёрским конторам. Заказчик заказал продукт, исполнитель сделал его плохо и сдал заказчику, а потом объявляет заказчику - его-де надо переделать и просит за это денег и заказчик платит. Для меня это сродни тому, как подрядчик построил дом на херовом фундаменте, а потом объявляет мне, что, чувак, мы херово построили - надо переделывать, плати ещё за один дом; вы бы стали платить? Какая разница, что кодил Серёжа, он же ваш Серёжа.
nikolas78
12.06.2022 15:32Странно, что у большой и «правильной» команды нет типовых решений, из которых они бы быстро наваяли «правильное» приложение. Получается, что они всё и всегда делают с нуля — конечно в такой ситуации Сережа будет выигрывать.
pavelsc
13.06.2022 02:03Может Сережа и не по канонам пишет код, но читает он его судя по всему заметно лучше, чем вся ваша команда вместе взятая ))
Lodin
Для полноты истории не хватает постскриптума, что через год-два клиенту пришлось обращаться к другой фирме и таки писать свой инструмент с нуля и по всем правилам. Потому что количество человекочасов на каждое новое расширение поделия Серёжи увеличивалось в геометрической прогрессии, и то, что раньше стоило 4 часа, теперь стоит все 40, а то и 80.
Grigorenkovic
И очередная фирма заверила, что уж ее-то продукт будет внедрен по всем правилам, направления масштабирования заранее просчитаны и все будет по фикс прайсу. А потом окажется что сову на глобус натянуть не удалось)
F0iL
Вот то же самое хотел сказать. Такие Серёжи обычно могут давать результат весьма неплохо, но только до тех пор пока тонны их дурно пахнущего кода не спрессуются в нечто, что уже не сможет успешно и с разумными трудовремязатратами поддерживать даже сам Сережа.
После этого такие Серёжи обычно увольняются и убегают творить в другое место, оставляя бывших коллег и клиентов
разгребатьсяразбираться со своим наследием.А ещё Сережа может просто внезапно пропасть (см. Bus factor). И тогда для клиентов начинается новый этап веселья с поиском того, кто сможет и захочет продолжать работать с этим, но это уже совсем другая история...
DvoiNic
F0iL
А, понятно. Тогда не удивительно, что там такое цветет и пахнет
DvoiNic
Не без того. Ну и плюс habr.com/ru/post/670700/#comment_24426910
PanDubls
Ну не может же это быть правдой, нет? Похоже на какой-то флешмоб-набег с двача.
Кстати, в отзывах от разных людей попадается странное сокращение "мален детей", что намекает, что они написаны одним человеком. Да и вообще язык очень похож во всех и стиль повествования.
Но угарно всё таки
DvoiNic
?? каких «мален детей»?
FanatPHP
Я думаю, товарищ выше перепутал ссылки, и комментировал эту
PanDubls
Да, конечно же, приношу свои извинения, как то умудрился совсем даже не близкий пост прокомментировать. Конечно, я комментировал тот пост, спасибо.
sogarkov
А в условиях российских реалий иногда и меньше. Или фирма закроется или направление бизнеса загнется. Кроме того, кроме программистов никто не сможет оценить степень говнокодистости, человеку от бизнеса главное, чтобы кнопка работала как надо, ну а что там под капотом - дело десятое. И это очень большая проблема программистов 1С: мотивация к собственному развитию только внутренняя, уйти с этого языка дальше можно, но очень сложно.
Faxfox
Все так. Но история походу не про код, а про бизнес. Есть требования у бизнеса здесь и сейчас и ресурс который он может себе позволить. Помню году в 2012 смотрел Бизнес Секреты с Тиньковым, у него в гостях был паренек, который в провинции открывал службу доставки пиццы, вроде название "До-до" (как птичка). Так у него спросили, а почему у тебя сайт это просто картинка? Он сказал, да картинка (тупо выкатил макет))), но мне надо было быстро запуститься и оттачивать бизнес-процессы, а вдруг не взлетит вовсе? Ну а если поедет, то все вопросы будет решать по мере поступления.
alexs0ff
Есть и другие примеры. Когда также была "картинка", а клиенты "поперли", но система просела из-за нагрузок и многие остались недовольны и ушли к конкурентам, т.к. там намного надежнее и стабильней.
Faxfox
и это нормально, вопросы роста должны решаться по мере поступления. Представьте ситуацию, когда вы потратили основную часть денег на старте на мега-портал, заказы прут, а повар косячит. Надо бы найти более компетентного или даже двух, а денег уже нет, а потом еще вопросы с логистикой...
alexs0ff
На мой взгляд, нужно везде искать компромисс. Между "сайтом-картинкой" и "навороченным мега порталом" есть очень много мест приемлемых для старта бизнеса. А вот то, что жадность мало когда "выстреливала", увы жизненных примеров куча.
Daemonis
А почему "сайт-картинка" не может быть компромиссом? Между "навороченный сайт" и "нет сайта" например?
alexs0ff
Сайт в мало мальски малом бизнесе услуг сейчас почти всегда есть. Это или авито/vk/insta или свой.
Daemonis
Речь в истории шла про 2012. А сайт, возможно, делали еще раньше.
sshmakov
Бизнес-секреты: Федор Овчинников (08.05.2011)
FrolVII
Есть интересная особенность у "бизнеса" - постоянное стремление получить товар/услугу еще дешевле и еще быстрее. Еще и еще. Стремление понятное и логичное, но здесь, как и везде, надо знать меру, иначе рискуешь стать тем самым скупым, который заплатит дважды. Для людей, которые теряют меру в подобном стремлении, это становится чем-то вроде спорта, превращаясь в самоцель. И там уже не важен результат - их реально заклинивает на самом процессе. Этим многие "от бизнеса" болеют. Это что-то психологическое.
В своей практике, я несколько раз встречал людей, которые могли ввести себя прям в состояние настоящей истерики, пытаясь что-то получить еще хоть немного быстрее или дешевле. Серьезные люди, занимающие серьезные должности, натурально впадали в истерику, пытаясь доказать что работу просто необходимо сдать быстрее, чем мы с ними прописали в договоре. А потом вдруг оказывалось, что это все были лишь сказки и спешки никакой, на самом деле, не было. Просто перестраховка такая. А ведь из-за сдвига сроков "влево" заказчик за те же деньги получил в итоге гораздо менее качественный результат. Первый раз, когда подобное случилось - я был несколько обескуражен (такой актерский талант пропадает!). Но со временем - привык.
Есть, кстати, забавный рассказ, хорошо, на мой взгляд, иллюстрирующий подобную пагубную страсть некоторых людей: "Четвертый комод Чиппендейла", автор Даль Роальд.
sogarkov
Вы все правильно подметили, это психология эффективных менеджеров, которым ставят KPI. Потом, даже когда нет метрик, это становится профдеформацией. И встречается это и у российских и у западных заказчиков.
DrPass
А знаете, что с высокой долей вероятности будет дальше? Другая фирма провела системный анализ, разработала архитектуру, план реализации, внедрения и приёмки, содрала кучу денег, а потом… потом выяснилось, что вот тут одного костыля не хватает, там ещё трех, а в том модуле доброго десятка. И новое приложение превратилось в такой же говнокод, сроки реализации фич также дорасли до 40 часов, но уже не времени Сережи, а времени ERPшника. И это не шутка, кейс, когда новая система, разработанная с нуля, успешно заменила старую, в которой была написана масса автоматизаций под частные бизнес-процессы компании, это редкость редкая. Чтобы всё это учесть, нужен огромный и дорогой пласт анализа, и так… практически никто не делает :)
Вообще, если серьезно, говнокодные решения могут жить вечно и без существенного удорожания. Я гипотетически могу предположить, что какие-то изменения могут потребовать сильных изменений в архитектуре, но обычно в тяп-ляп системах так не бывает. Нашлёпывать костыли можно практически бесконечно, а там, где простой костыль сделать не получается, всегда можно прилепить внешнюю утилиту, эксель, или на худой конец, внести изменения в сам бизнес-процесс, чтобы какой-то шаг учитывал кривизну системы.
v1t3man
Вообще, чтобы проект не скатывался в конечном итоге в овнокод, нужно чтобы, как минимум, руководитель разработки был в курсе всех или большинства бизнес-процессов и имел представление дальнейшего развития компании на длительный период и мог спрогнозировать будущие фичи и оставить концы для подзвязки в существующем функционале. А для этого должен быть штатный отдел разработки.
Поэтому выполнение задач поностью аутсорсом в 99.9% скатится к овнокоду.
DrPass
В компаниях, в которых есть такой руководитель, Серёжа дырки не затыкает :)
medstrax
Не многовато для «руководителя разработки»?
nmrulin
Кстати говоря в некоторых проектах именно так и надо. Сначала программирует Серёжа. Когда поддержка слишком сложна производиться глубокий рефакторинг.
А когда делают "сразу хорошо" часто оказывается не то, не туда масштабируется , рефакторинг сделать ещё сложнее, чем для кода Серёжи.
DrPass
Абсолютно верно. При прочих равных, «запустить сегодня с нуля на коленке, а потом при необходимости провести анализ, перепроектировать правильно, и переписать всё нафиг» — это значительно дешевле, чем «провести анализ, спроектировать правильно, разработать и внедрить через полгода-год». Потому что в первом случае, во-первых, пока вы будете анализировать, проектировать и переписывать, система уже будет работать и приносить вам деньги. Во-вторых, когда вы будете анализировать и проектировать, у вас уже будет реальный пользовательский опыт, а не только предположения про него, как во втором случае.
Yozi
Шикарно будет, когда на код/публичный интерфейс Серёжи ещё пару отделов завяжутся и потом обратно-совместимо это поддерживать.
v1t3man
По модному, это любят называть mvp
TedBronson
И это абсолютно нормально. Нереалистично в рассказе то, что по запросу клиента они не смогли привести примеры, когда говнокод замедлял разработку и не давал выпустить фичу вовремя.
mvv-rus
Не потому ли они не смогли привести примеры, что таковых не было? Например, когда намечался провал выпуске фичи — просто звали Серёжу, и он всё делал?
TedBronson
В таком случае Серёжа абсолютно прав. Тут как в присказке: есть те кто не делает бэкапы и кто уже делает. Бизнес может (вполне справедливо) с сомнениям относиться к страшилкам о сложности поддержки, если ни разу не возникали реальные проблемы. Когда (и если) говногод работать перестанет, то можно пересоздать систему с нуля, обычно так и делается.
sogarkov
И вот тут прямо чешутся руки написать про тот самый модный ныне Agile, который в большинстве своём оказывается только красивым прикрытием того говнокода Сережи. Рабочим прикрытием, кстати.
SIMPLicity
Всё проще: через два года (по той или иной причине) внутри "клиентской компании" был внедрён новый функционал,- а весь старый был свёрнут нахрен. Но!, как только чего-то стало не хватать,- звонили "Серёже" и просили его нашаманить какую-нибудь говноподелку, которая а) делала-именно-то-что-надо , б) заработала-быстро, в) стоила недорого ....
Аминь!...
shornikov
Не. Клиент через два года закрылся из-за причин не связанных с кодом. А пока контора работала - у нее всегда был инструмент и он отвечал требованиям заказчика за небольшие деньги.
Я - за сережу. Времена такие что бизнес сегодня есть, завтра нет. Или занимается совсем другим.
Терять время и деньги сейчас, чтобы через 4 года было хорошо - такое себе.
BZL
Вы явно из той лиги хороших программистов, где все планируется и масштабируется). Только вот задачи бывают разные, и там где не требуется масштабирование - подход Сережи более эффективен.
IvanIvanc
А вот и эти программисты подтянулись. Бизнес для программистов или программисты для бизнеса?
nikolas78
А разве здесь есть какие-то варианты ответа, кроме единственно верного?
sobserg
Или нет - причем в большинстве случаев.
'расти' инструменту надо, если растет фирма, и если с ее ростом нужен рост инструмента (не всегда связанно). Большинство бизнесов не растут, а проваливаются, это факт. Но даже те что растут - не всегда растут в конкретной области. В итоге имеем, что абс. большинству сережиного тула хватит навсегда