Комментарии 245
Для полноты истории не хватает постскриптума, что через год-два клиенту пришлось обращаться к другой фирме и таки писать свой инструмент с нуля и по всем правилам. Потому что количество человекочасов на каждое новое расширение поделия Серёжи увеличивалось в геометрической прогрессии, и то, что раньше стоило 4 часа, теперь стоит все 40, а то и 80.
И очередная фирма заверила, что уж ее-то продукт будет внедрен по всем правилам, направления масштабирования заранее просчитаны и все будет по фикс прайсу. А потом окажется что сову на глобус натянуть не удалось)
только до тех пор пока тонны их дурно пахнущего кода не спрессуются в нечтоЕсть нюанс. система на 1с долго не живет. Вендор заставит, вынудит, нагнет перейти с ТиС 8 на ТиС9, оттуда на УТ10, оттуда на УТ11, а там даже переход с УТ11.4 на УТ11.5 вынудит переписать значительную часть написанного плохо или хорошо просто потому, что на селезневке «концепция поменялась». Т.е. «г-коду Сережи» нужно продержаться года 3-4.
Ну не может же это быть правдой, нет? Похоже на какой-то флешмоб-набег с двача.
Кстати, в отзывах от разных людей попадается странное сокращение "мален детей", что намекает, что они написаны одним человеком. Да и вообще язык очень похож во всех и стиль повествования.
Но угарно всё таки
Да, конечно же, приношу свои извинения, как то умудрился совсем даже не близкий пост прокомментировать. Конечно, я комментировал тот пост, спасибо.
А в условиях российских реалий иногда и меньше. Или фирма закроется или направление бизнеса загнется. Кроме того, кроме программистов никто не сможет оценить степень говнокодистости, человеку от бизнеса главное, чтобы кнопка работала как надо, ну а что там под капотом - дело десятое. И это очень большая проблема программистов 1С: мотивация к собственному развитию только внутренняя, уйти с этого языка дальше можно, но очень сложно.
ну не скажи, как раз из-за стоимости и иногда оооочень глубоких отличий от типовой ТиС, некоторые до сих пор на 7.7
Все так. Но история походу не про код, а про бизнес. Есть требования у бизнеса здесь и сейчас и ресурс который он может себе позволить. Помню году в 2012 смотрел Бизнес Секреты с Тиньковым, у него в гостях был паренек, который в провинции открывал службу доставки пиццы, вроде название "До-до" (как птичка). Так у него спросили, а почему у тебя сайт это просто картинка? Он сказал, да картинка (тупо выкатил макет))), но мне надо было быстро запуститься и оттачивать бизнес-процессы, а вдруг не взлетит вовсе? Ну а если поедет, то все вопросы будет решать по мере поступления.
Есть и другие примеры. Когда также была "картинка", а клиенты "поперли", но система просела из-за нагрузок и многие остались недовольны и ушли к конкурентам, т.к. там намного надежнее и стабильней.
и это нормально, вопросы роста должны решаться по мере поступления. Представьте ситуацию, когда вы потратили основную часть денег на старте на мега-портал, заказы прут, а повар косячит. Надо бы найти более компетентного или даже двух, а денег уже нет, а потом еще вопросы с логистикой...
На мой взгляд, нужно везде искать компромисс. Между "сайтом-картинкой" и "навороченным мега порталом" есть очень много мест приемлемых для старта бизнеса. А вот то, что жадность мало когда "выстреливала", увы жизненных примеров куча.
На мой взгляд, нужно везде искать компромисс. Между "сайтом-картинкой" и "навороченным мега порталом" есть очень много мест приемлемых для старта бизнеса.
А почему "сайт-картинка" не может быть компромиссом? Между "навороченный сайт" и "нет сайта" например?
Сайт в мало мальски малом бизнесе услуг сейчас почти всегда есть. Это или авито/vk/insta или свой.
Речь в истории шла про 2012. А сайт, возможно, делали еще раньше.
Есть машина, но я не пользуюсь сервисом уровня - "дядя Вася в гараже". Я принципиально обращаюсь в ремонт к тем, кто имеет уголок потребителя, сайт и т.д. А все остальное - уровень "бабок с семками" под мостом. Что-то случится с машиной после ремонта, а с исполнителя и взять нечего, поэтому и другим не советую такой "сервис". Но согласен есть исключение - в деревнях/селах, там все на виду, но и очень и очень редко даже ИП оформлено (по крайней мере я таких не встречал, все в "черную").
Сайт и т.д. не гарантия качества ремонта, но он показывает как владелец относится к своему бизнесу.
Для меня хороший автосервис это корректно оформленные документы, юридическая гарантия, чистота в приемке. Все остальное - на свой страх и риск. То что вы говорите про "рынок продавца" это симптом жесткой экономии среди населения. Запись к официальному дилеру есть и условно "на завтрашний день", но цены в несколько раз выше, поэтому народ и голосует за "гараж дяди Васи".
Официальный дилер это тем более «рынок продавца», где за большие деньги, тем кто привязан по гарантии или просто наивен делают сервис хуже качеством. Есть опыт.
Дяди Васи бывают разные, есть и ещё хуже, конечно, но там хоть можно выбирать.
Дяди Васи бывают разные, есть и ещё хуже, конечно, но там хоть можно выбирать.
Да, но есть нюанс: а сможет ли сделать правильный выбор массовый потребитель, обладает ли он для этого достаточной информацией?
А то для очень близкого рынка — автомобилей, где официальные дилеры новых с «заряженными» (на мгновенное падение процентов на 20 сразу после продажи) ценами и продавцы б/у автомобилей с ценами сильно пониже, но с совершенно непроверяемым качеством — информации для правильного выбора у покупателя откровенно не хватает: если чо, ученый, обнаруживший этот факт и сделавший из него надлежащие выводы, получил Нобелевку по экономике.
PS Этот комментарий я предназначаю не для того, чтобы мне отвечать, а чисто для информации к размышлению, о том, как оно бывает.
В моем опыте дорогущий монобрендовый сервис с сайтом, чистой приемкой и ценой нормочаса почти в два раза больше, чем в обычных отличается только наличием специнструмента, чтобы правильно ГРМ выставить или ГБЦ снять-поставить.
В остальном, что там, что там крутят гайки обычные Василичи, которым только бы колодки да масло менять, а диагностика сложных и непонятных неисправностей сводится к "ну давайте %детальнейм% поменять попробуем" (без гарантии, за мои деньги).
Но в серваке попроще я могу вместе со слесарем гайки покрутить, подкинуть ему каких-нибудь специфичной инфы конкретно по моему автомобилю, вместе мозгоштурм неисправности провести. А в дорогом монобрендовом в ремзону не пускают: "Вот вам диванчик, ожидайте. Можем такси вызвать". Безальтернативное "клиент - дурак, нам лучше видно".
Ну, или проводя аналогии с пиццей — решающим в выборе места, где заказать пиццу, всё равно будет скорее «а вот тут она вкуснее», а не «тут мобильное приложение удобнее»
Ну, или проводя аналогии с пиццей — решающим в выборе места, где заказать пиццу, всё равно будет скорее «а вот тут она вкуснее», а не «тут мобильное приложение удобнее»Решающим очень часто будет «вот эту я [в интернете] нашёл, а про другие даже не слышал». И да — в 100м от моего дома делают неплохую пиццу, но у них нет ни сайта, ни приложения, ни присутствия в агрегаторах доставки типа Я.Еды и Деливери-Клаба. Только телефон. В итоге, пиццу я у них брал ровно 2 раза за 5 лет, а с доставкой — вообще ни разу.
Дайте, пожалуйста, более развернутое описание Вашего "приема". А то коллега, которому Вы оппонируете привел развернутое описание, причем я ему верю. Потому что он описывает очень реалистичный кейс. А Вам не могу поверить. Увы, потому что нет конкретики.
Можно уточнить примеры?
забавно что Додо стала номер 1 в России, как по объемам так и по пиццириям, видать паренек знал что делает
Бизнес-секреты: Федор Овчинников (08.05.2011)
Есть интересная особенность у "бизнеса" - постоянное стремление получить товар/услугу еще дешевле и еще быстрее. Еще и еще. Стремление понятное и логичное, но здесь, как и везде, надо знать меру, иначе рискуешь стать тем самым скупым, который заплатит дважды. Для людей, которые теряют меру в подобном стремлении, это становится чем-то вроде спорта, превращаясь в самоцель. И там уже не важен результат - их реально заклинивает на самом процессе. Этим многие "от бизнеса" болеют. Это что-то психологическое.
В своей практике, я несколько раз встречал людей, которые могли ввести себя прям в состояние настоящей истерики, пытаясь что-то получить еще хоть немного быстрее или дешевле. Серьезные люди, занимающие серьезные должности, натурально впадали в истерику, пытаясь доказать что работу просто необходимо сдать быстрее, чем мы с ними прописали в договоре. А потом вдруг оказывалось, что это все были лишь сказки и спешки никакой, на самом деле, не было. Просто перестраховка такая. А ведь из-за сдвига сроков "влево" заказчик за те же деньги получил в итоге гораздо менее качественный результат. Первый раз, когда подобное случилось - я был несколько обескуражен (такой актерский талант пропадает!). Но со временем - привык.
Есть, кстати, забавный рассказ, хорошо, на мой взгляд, иллюстрирующий подобную пагубную страсть некоторых людей: "Четвертый комод Чиппендейла", автор Даль Роальд.
На счет до-до, так и после 2012 они остались видимо приверженцами *овнокода, например в 2017 откатили платежи на 8 миллионов. https://habr.com/ru/company/yoomoney/blog/325762/
Так что не стоит их в пример ставить.
Вообще, если серьезно, говнокодные решения могут жить вечно и без существенного удорожания. Я гипотетически могу предположить, что какие-то изменения могут потребовать сильных изменений в архитектуре, но обычно в тяп-ляп системах так не бывает. Нашлёпывать костыли можно практически бесконечно, а там, где простой костыль сделать не получается, всегда можно прилепить внешнюю утилиту, эксель, или на худой конец, внести изменения в сам бизнес-процесс, чтобы какой-то шаг учитывал кривизну системы.
Вообще, чтобы проект не скатывался в конечном итоге в овнокод, нужно чтобы, как минимум, руководитель разработки был в курсе всех или большинства бизнес-процессов и имел представление дальнейшего развития компании на длительный период и мог спрогнозировать будущие фичи и оставить концы для подзвязки в существующем функционале. А для этого должен быть штатный отдел разработки.
Поэтому выполнение задач поностью аутсорсом в 99.9% скатится к овнокоду.
Кстати говоря в некоторых проектах именно так и надо. Сначала программирует Серёжа. Когда поддержка слишком сложна производиться глубокий рефакторинг.
А когда делают "сразу хорошо" часто оказывается не то, не туда масштабируется , рефакторинг сделать ещё сложнее, чем для кода Серёжи.
А когда делают «сразу хорошо» часто оказывается не то, не туда масштабируется, рефакторинг сделать ещё сложнее, чем для кода Серёжи.
Абсолютно верно. При прочих равных, «запустить сегодня с нуля на коленке, а потом при необходимости провести анализ, перепроектировать правильно, и переписать всё нафиг» — это значительно дешевле, чем «провести анализ, спроектировать правильно, разработать и внедрить через полгода-год». Потому что в первом случае, во-первых, пока вы будете анализировать, проектировать и переписывать, система уже будет работать и приносить вам деньги. Во-вторых, когда вы будете анализировать и проектировать, у вас уже будет реальный пользовательский опыт, а не только предположения про него, как во втором случае.
По модному, это любят называть mvp
И это абсолютно нормально. Нереалистично в рассказе то, что по запросу клиента они не смогли привести примеры, когда говнокод замедлял разработку и не давал выпустить фичу вовремя.
В таком случае Серёжа абсолютно прав. Тут как в присказке: есть те кто не делает бэкапы и кто уже делает. Бизнес может (вполне справедливо) с сомнениям относиться к страшилкам о сложности поддержки, если ни разу не возникали реальные проблемы. Когда (и если) говногод работать перестанет, то можно пересоздать систему с нуля, обычно так и делается.
И вот тут прямо чешутся руки написать про тот самый модный ныне Agile, который в большинстве своём оказывается только красивым прикрытием того говнокода Сережи. Рабочим прикрытием, кстати.
Всё проще: через два года (по той или иной причине) внутри "клиентской компании" был внедрён новый функционал,- а весь старый был свёрнут нахрен. Но!, как только чего-то стало не хватать,- звонили "Серёже" и просили его нашаманить какую-нибудь говноподелку, которая а) делала-именно-то-что-надо , б) заработала-быстро, в) стоила недорого ....
Аминь!...
Не. Клиент через два года закрылся из-за причин не связанных с кодом. А пока контора работала - у нее всегда был инструмент и он отвечал требованиям заказчика за небольшие деньги.
Я - за сережу. Времена такие что бизнес сегодня есть, завтра нет. Или занимается совсем другим.
Терять время и деньги сейчас, чтобы через 4 года было хорошо - такое себе.
Вы явно из той лиги хороших программистов, где все планируется и масштабируется). Только вот задачи бывают разные, и там где не требуется масштабирование - подход Сережи более эффективен.
А вот и эти программисты подтянулись. Бизнес для программистов или программисты для бизнеса?
Или нет - причем в большинстве случаев.
'расти' инструменту надо, если растет фирма, и если с ее ростом нужен рост инструмента (не всегда связанно). Большинство бизнесов не растут, а проваливаются, это факт. Но даже те что растут - не всегда растут в конкретной области. В итоге имеем, что абс. большинству сережиного тула хватит навсегда
Я иногда такой Серёжа. Я считаю что важна правильная архитектура крупными мазками, а в изолированных деталях может существовать какой угодно говнокод. И мне крайне непонятны люди которые приходят, видят читаемый код, читают, понимают и говорят что он не соответствует их идеалам программирования которые они видели в толстых книжках. При этом эти люди частно никогда не смотрели ни в какой в крупный и успешный опенсурс. А правда в том что в любом старом крупном опенсурсе всё что надо работает на достаточном уровне, но там невероятные глубины говнокода с точки зрения смузи программиста. Задачи делать надо, и смотреть чтобы продукт жил. Далеко не каждый кусок кода надо полировать, далеко не каждый кусок кода надо покрывать тестами, могут существовать куски кода которые 2/3 отдела понять не в состоянии в принципе. Ничего страшного. Нет никакого смысла прямо сейчас пытаться всё это отполировать чтобы джун мог там как рыба в воде плавать. Более того, я даже пост писал на эту тему https://habr.com/ru/post/440414/
Согласен. Мощность и качество архитектуры - это как раз границы, прозрачность на высоком уровне и куча понятных точек расширения, где можно говнокодить (если нужно), не разбрызгивая. И где для большинства новых разработчиков понятно, если нужен экран приложения - делай так. Нужна новая сущность - добавляй тут, нужно расширение апи - здесь, а сервисы с длинным ЖЦ - тут и т.д.
Не раз видел обратную ситуацию - отточенные функции, качественные специализированные классы, качественный гайдстайл, модули уже рыхлые и со странными связями, а на уровне проекта управление - набор костылей, говнокода и спрятанных глобальных переменных, неявно рулящих состоянием.
И это гораздо хуже.
Именно так. Система, всё-таки, должна в первую очередь решать бизнес-задачи, а не демонстрировать образцовость концепций. Часто выгоднее реализовать прототипный код "как быстрее", запланировав рефакторинг на будущее (которое, в общем случае, может и не наступить). Тем более, что через полгода-год бизнес-требования могут смениться так, что заранее продуманная идеальная модель перестанет быть идеальной ;)
«Публикуйте раньше. Публикуйте часто. И слушайте своих клиентов»...
Без 1000 проверяющих глаз, но в целом Серёжа двигается в этом направлении.
Потом будет SCRUM и пр.
Серёжа ярый агилист. Всё верно, большинство программистов пытаются решать проблему, которая возможно никогда не возникнет, что тратит время клиентов. И в этой истории программисты полезли в работающий код без анализа, с очевидным результатом. А в таком коде нужно сначала разобраться, а потом уже постепенно срезать лишнее.
Ну или всё-таки надо было найти какого-нибудь Петю, который может мастерски работать с клиентами и донести до них мысль, что Серёжа им не нужен. Вот зачем программистов на это подряжать? Они не по части общения с клиентом, они - по части программирования. А хотелки клиента - это тоже вещь эфемерная, им нужна машина, а они это формулируют как "более быстрая лошадь". Да и хотелки эти меняются хаотическим образом, порой возвращаясь на место, как в знаменитом "Порожняке" из Фитиля. Так может такие Серёжи являются симптомом того, что компания не научилась нормально выстраивать диалог с клиентом? Или что у компании неадекватные клиенты? В любом случае, ничего хорошего такую компанию не ждёт, в краткосрочной перспективе поработать здесь и сейчас можно, но в целом я бы валил из такой, ибо в плане долгосрочной карьеры и самореализации там ловить, видимо, нечего.
Проблема как раз в том, что не гарантирует. А ещё аргумент - покопаться в бизнес-процессах клиента, подсказать, что ему НА САМОМ деле нужно. Универсального рецепта нет, тем более, что я и сам-то не переговорщик. Из моего опыта мне как-то (правда, внутренний) заказчик всё больше и больше пытался продавить в приложении функций экселя. В итоге я не выдержал и просто в какой-то момент сделал импорт-экспорт, весь эксель уже есть, он хорош, и нам его точно не переплюнуть. Аргумент ровно такой: мы можем тратить кучу времени добавляя фичи в приложение, делая из него БЛЕДНОЕ подобие экселя, или вы можете использовать уже существующий у вас замечательный эксель, экономя и своё, и наше время. Другой вариант - обговорить MVP, попытаться понять, что здесь и сейчас можно обрезать, пообещать сделать в следующей итерации (а на практике как до неё дойдёт, то часто, либо ишак, либо падишах). Если договориться не удалось, можно попробовать походить по тонкому льду и заняться саботажем, т.е. ой, я не успел сделать. В случае прокачанного чутья можно как раз "не успеть" сделать то, что окажется к сроку сдачи уже и не сильно нужным, или окажется, что в процессе эксплуатации все довольны реализованным функционалом. Если эту итерацию повторить несколько раз, то до заказчика начинает доходить, что ты фишку сечёшь и они начинают больше прислушиваться к тебе в процессе постановки задачи. Правда, опять же, это прокатывает с внутренним заказчиком, если есть договор и ТЗ, то так уже становится сложно себя вести. Вариант: то, что "не успеть", сделать максимально костыльно и говнокодисто, с расчётом на то, что всё равно придётся выпилить.
Проблема как раз в том, что не гарантируетСережа еще не разу не подвел клиентов, и никто его «говнокод» за ним не разгребал (он не уходил в другую фирму, сбросив все на оставшихся коллег). Практика разве не важнее теории?
Проблема как раз в том, что не гарантирует.
Проблема больше в том, что на стороне «Сережи» лежит быстрое работающее и недорогое решение проблемы при отсутствии гарантий его успешного развития. На стороне «Пети» лежит более дорогое решение, требующее более долгого внедрения. А знаете, что самое неприятное? Оно тоже не предлагает никаких гарантий его успешного развития. Ну просто потому, что предложенная программистами продуманная архитектура совершенно не обязательно окажется соответствующей будущим (а иногда — даже текущим) потребностям бизнеса. Это их собственное видение, не более того.
Оно тоже не предлагает никаких гарантий его успешного развития. Ну
просто потому, что предложенная программистами продуманная архитектура
совершенно не обязательно окажется соответствующей будущим (а иногда —
даже текущим) потребностям бизнеса.
Моя практика показывает, что если тут нет чьей-либо предвзятости, то есть вполне объективные показатели, как лучше-хуже, и какая-никакая минимальная продуманность всегда в долгосрочной перспективе выигрывает по сравнению с полной непродуманностью и костылями. Суть хорошей архитектуры не в том, чтобы соответствовать текущим или будущим требованиям бизнеса, а в том, чтобы уметь под любые такие требования подстраиваться. И для этого, поверьте, кроме хороших практик в конкретной предметной области, есть вполне себе универсальные общеинженерные методики, плюс-минус работающие хоть в системе учёта персонала, хоть в компиляторе, хоть в 3D-движке. То, что некоторые программисты продумывают "архитектуру", а потом получается ужас, свидетельствует либо о том, что они по сути такие же "Серёжи", которые обозвав исходного Серёжу говнокодером, перетянули на себя проект, либо о просчётах менеджмента, который руководил разработкой/внедрением системы.
Если бы это решение лежало у Сережи этой истории бы не было, Сережа бы греб деньги лопатой и слал нам воздушные поцелуи с пляжей теплых морей. Но Сережа вместо этого обсуждаем сейчас здесь не в лучшем свете, а следовательно Сережино решение включает в себя некоторые издержки в своем жизненном пути, даже для него самого. И мы можем софистически искать равенство этих двух решений, но обсуждаем то мы не второе, а Сережино. В этом проблема. Оно _было_ когда то дешевым, быстрым, срочным, но сейчас оно неработающее, немасштабируемое и дорогоподдерживаемое, оттого оно в обсуждении.
А если допустить что Серёжа на работе уи пинает, а вместо него код пишет "ИИ, нейронная сеть Маша" ))) То что обычный человек не понимает как это творчество устроенно и как работает не имеет никакого значения если задача решается так как нужно заказчику )))
Слишком много внимания уделяется архитектуре - как говориться дорога ложка к обеду ))
Угу-угу.
Есть контора, работает 10 лет, например.
И пришли ммм допустим даже интеграторы, и говорят - вы все делаете неправильно.
Вчера мы молокозаводу объяснили как правильно работать,позавчера алмазному разрезу. И вам объясним.
А обычно учить пытаются просто фирмочки, которые сайты делают
Предположу, что Серёжа его не гарантирует, а обещает, т.е. не несёт ответственности за невыполнение обещания.
Надо программировать доступно и всерьез. Я тоже Сережа (по имени) и франчи 1С проигрывают мне, потому что делают дорого и красиво, а я дорого и сердито.
Но тем не менее у меня красивые решения, ибо я Гений 1С.
Ну конечно, твой код это шедевр. Передавать параметры в метод через базу данных, что может быть лучше:
https://geniy1s.ru/nekanonicheskij-sposob-spuskaniya-parametra-nizhestoyashhim-proczeduram/
Ситуации бывают очень разные и в каких-то случаях могут быть оправданными весьма неочевидные решения.
Гении могут быть со странностями, если отзывы правдивы. https://otzovy-moskvy.ru/firm/ip-osipov-sergey-aleksandrovich-154062
я все хочу услышать, какое альтернативное решение для передачи контекста вглубь ты придумаешь (если не придираться к хранению в БД, которое я потом безболезненно заменил параметрами сеанса)?
К сожалению, прошедшие такую школу очень сложно переучиваются «работать правильно», делать решения с учетом возможного расширения, и долгого сопровождения.
Сегодня всем мы- "Серёжа"!!! :)
Регулярно таким заниматься приходится. Причем не столько от отсутствия квалификации или "принципов", а от лютейших дедлайнов "ой нам вчера надо было полностью переделать проект!"
P.S. Только что переносил "проклЯтый" проект с одной CMS на другую. Пол-сотни классов сущностей. За три дня. %)
А коллеги из Яндекса только что занимались еще более масштабной задачей(ну вы понимаете) за два дня.
Оно и понятно – быстрый говнокод дёшев, нормальный – существенно дороже.
Как тонко написано =)
Получается Серёжа демпингует, да ещё завязывает клиента на себя. Клиенту понятно такой демпинг выгоден, ибо платить меньше, но страдает вся компания.
Статья именно потому, что сценарий "либо потом, либо вообще не будет" не реализовался. Реализовался незапланированный никем "работаем дальше", но как с этим теперь работать? Если бы Сережа или подобные вытягивали, то и статьи бы не было.
Есть среди стоматологов такие Серёжи, делают клиенту реставрации коронок из пломбировочного материала, анкеров накрутят в канал, хоп, хоп, коронку вылепили. Дёшево. Быстро. Красота! Клиент счастливый, довольный.
Через пару лет во время еды эти коронки начинают откалываться, оставляя гнилые пеньки.
Эмм, любые коронки через несколько лет начинают откалываться, оставляя гнилые пеньки. Во-первых, Ваш зуб изначально превращают в пенек, чтобы на него надеть коронку. То, что этот пенек под коронкой со временем сгниет - это несомненно, никаких других вариантов не предусмотрено. И случится это скорее рано, чем поздно. Даже если будете делать в США за очень много долларов. Поэтому никогда не делаю коронки - у меня не так много здоровых зубных тканей, чтобы их еще обтачивать и подгонять под коронки/виниры/прочую ерунду.
Интересно было бы посмотреть какой год "проф" проггеры считают "говнокодом", по каким параметрам он его определяют? Что его так отличает от "идеального", по их мнению?
Классика типа
if var1 == "true"По моему пониманию "говнокод" это безграмотность, либо алгоритмически, либо в средствах языка.
Но впрочем я не программист.
Линтеры разве такое не ловят?
Это не говнокод, но логическая ошибка.
Говнокод - это использовать функциональное программирование там, где лучше было бы все собрать в классы с несколькими уровнями астракции, интерфейсами, модульностью, без непонятных констант и т.п.
Осталось выяснить для кого лучше и кто решает что лучше.
Итогом такой точки зрения получится что любой код говнокод.
Я все же останусь при мнении что говнокод это прежде всего неумение пользоваться инструментом - алгоритмом или языком.
И наоборот тоже. Когда из-за добавления одного-единственного аргумента в метод при лишнем уровне абстракции оказалось нужно переписать 14 методов объектов, я то же самое понятие использовал...
Если до рефакторинга в куске кода находили 4 бага в неделю, а после стало в среднем 1.5, то до рефакторинга код был явно не очень.
Если одна сферическая задача в вакууме раньше занимала 36.2 часа разработки, а после переписывания стала закрываться за 7.1 часов - аналогично.
[совсем реальный кейс с настоящими цифрами] Если раньше один критичный алгоритм занимал 10.000 строк кода и покрывал 17 возможных комбинаций входных значений из 640.000, а потом стал занимать 100 строк (просто сотня, а не сто тысяч) и покрывать все 640.000...
Нужно продолжать?
Если до рефакторинга в куске кода находили 4 бага в неделю, а после стало в среднем 1.5, то до рефакторинга код был явно не очень.
но код с багами это же не обязательно говнокод, это просто код с багами, или после рефакторинга у вас код стал просто чуть менее говнокодистым?)
Если одна сферическая задача в вакууме раньше занимала 36.2 часа разработки, а после переписывания стала закрываться за 7.1 часов - аналогично.
Тоже, возможно, не лучший пример, сферическая задача в вакууме, особенно на зарождении проекта, скорее всего будет гораздо быстрее решаться говнокодом
Если раньше один критичный алгоритм занимал 10.000 строк кода и покрывал 17 возможных комбинаций входных значений из 640.000, а потом стал занимать 100 строк (просто сотня, а не сто тысяч) и покрывать все 640.000...
А это говнокод или баг?) Или изначально были разные требования? Безусловно сравнение 10к или 100к строк с сотней выглядит потрясающе, но немного настораживает :)
Возможно говнокодом можно назвать просто сложночитаемый код, который не использует всех явных синтаксических и «логических?» возможностей, из этого и будут вытикать другие признаки говнокода
Вот именно для того, чтобы не спорить, что есть баг, а что есть говнокод (или кто из двух кодообезьян говнокодистее, или какой стиль именования/отступов/расстановки скобок самый правильный, или какой из /анти/паттернов является на самом деле таковым), я и предлагаю сводить всё к числам.
Боль есть? - Значит говно!
Работает и ни у кого не подгорает? - Молодцы, продолжайте!
А вы, однако, оптимист.
У меня вот регулярно подгорает от своего же кода.
"Подгорает" здесь не в смысле "подо мной уже стул тлеет после чтения твоего кода", а в смысле "у нас сроки/проект горят". Т.е. вопрос всё равно о неких цифрах и фактах, а не о субъективном восприятии. Извиняюсь, если неточно выразился.
благодаря быдлокодерству появились гигагерцы и многоядерники.
а то па по прежнему сидели бы на еэсках
Мне кажется, что это хоть и связанные как-то процессы, но у них очень слабая связанность. Если почитать всякие там статьи от яндекса про их кликхаус, где они меряются пиписьками с гуглом и на их яндекс-метрике их хеш-куча отрабатывает быстрее на 30%, укладываясь где-то в какой-то кеш процессора, то создается впечатление, что в реальном хайлоад все очень сильно оптимизируется, просто до невозможности. А если смотреть, как народ те же недействительные паспорта в базу 1С пытается десятками часов грузить, при том если просто хеш-таблицу в той же 1С сделать и засунуть в нее просто записи файлов с номерами и все грузится за 40 минут, то еще неизвестно, что назвать говнокодом. А ведь грузить в базу - это вроде как "праильно", при том хранить в базе меняющиеся каждый день значения - это явно "не правильно". С третьей стороны, любая битовая маска покрывает эту задачу и решает вопрос загрузки за единицы минут даже на 1С, а на Си вообще за десятые долит секунды, при этом проверка падает в эффективность О(1), как и вставка/обновление значения при минимально используемой памяти, т.к.маску можно грузить частями.
В общем, одна и та же задача может быть как ресурсоемкой, так и элементарной. Все упирается в алгоритм и инструмент. Есть быстрые алгоритмы, которые будут на медленном инструменте ресурсоемки, есть медленные алгоритмы, которые на быстром инструменте будут нересурсоемки. Так что производительность ПК - это благодаря геймерам, научным расчетам и медленным платформам (типа 1С, где расчет себестоимости по объему вычислений не превышает расчета одного кадра 4к в приличной игрушке, при том занимает до суток времени, при том домашний комп за сто рублей в этой игрушке выдает приличное FPS, в то время как на порядок более дорогой сервер дохнет в "кровавом энтерпрайзе").
Смотря какое. Многие образцы старого кода считают быдлокодерством т.к. не в когда нет классов, много глобальных переменных, даже функции и то вызываются редко и большие.
Но зато по скорости это работает намного быстрее сегодняшнего условно хорошего кода.
Это два процесса которые подтягивают друг друга. Например есть производители железа и программисты, которые делают что-то. Программисты умеют в оптимизацию, но бизнесу это не нужно, а значит что-то жрет все больше и больше ресурсов. Если ситуация по оптимизации патовая, то делают оптимизацию. Если нет, ждут пока производители железа начинают соревноваться, чей продукт справляется с чем-то лучше потому что им тоже надо решать запросы пользователей чего-то, и цикл повторяется.
Гораздо интереснее в этом отношении таже картина в плоскости embedded, где в конечном итоге умудряются натянуть Arduino на Cortex-A Series, хотя с задачей справился бы гораздо, горазбо более простой чип, но это же надо знать pure c и asm. В итоге люди с компетенцией Сережи делают продажи производителям чипов, систем-на-кристалле и демо-плат, отчасти от того что взять микроконтроллер придуманный для во-много во-много раз сложных задач дешевле, чем оплатить работу программистов. От этого и рождаются решения типа NET nanoFramework, microPython и тд, потому что "давайте использовать существующую кодовую базу".
Ну и следует учитывать, что сегодня железо обрабатывает 100 транзакций в день, а завтра 100 транзакций в секунду. Ну и в итоге проблема или заливается деньгами на железо, что в общем-то быстрее, или заливается куда большими деньгами на оптимизацию, что дорого, ибо вываливается в триалектический баланс вместе с быстро и качественно. С железом тут быстрее и дешевле.
У меня странное ощущение, что мифологемы не бьются. Говнокод - это не когда "никто не может прочитать". Говнокод - это когда оно работает не как должно, а никто не может понять по коду как должно.
Говнокод, это что-то рабочее, но поддерживаемое с трудом. Или просто вызывающее кровь из глаз, но тоже рабочее. Во многом эти проблемы с написанием качественного кода возникают из-за недостатка времени у сотрудников, и отвратительного менеджмента. У людей сначала нет времени читать документацию, нет времени подумать над архитекторой.. а потом нет и желания. Потоянное переключение между задачами из-за их деприоритизации потому что бросай все! срочно нужно сделать %subject% не позволяет сосредоточиться на поиске правильного решения. Классическое хуяк-хуяк и в продакшн. При этом задачи ставятся на уровне "сделай заебись", а результат обсуждается под крики "я тут начальник, я лучше понимаю что нужно" и классическое "я никого не держу" и "дверь там".. при том, что в коллективе фактор автобуса стоит достаточно остро. Во всяком случае у нас именно так.
у всех программистов говнокод. Ещё не видел ни одного программиста код которого мне нравится. Так и должно быть.
И типовой код от фирмы 1С тоже говнокод, но там кода очень много и работает обычно правильно, поэтому надо уважительно относиться как они умеют так делать чтобы много говнокода вместе работало правильно.
Много говнокода - надо привыкать
Мало говнокода - надо удалять
Само понятие "говнокод" возникает в процессе оценки этого кода, следовательно система "Сережа + Клиенты" перестала быть закрытой, самодостаточной и требует взаимодействия с другими программистами, которые и оценили код.
Апелляция к тому, что клиенты то раньше были довольны прекрасна, но ключевое слово "раньше были". И последующее движение вперед невозможно без оценки того, что есть и выплаты по накопившемуся техдолгу, раз уж мы пришли к необходимости в Сережин код вникать. Никто в здравом уме в такие болота не лезет по собственной воле в целях сохранения этого здравого ума.
Аналогия - на изношенной машине Вы доехали до клиента, когда колеса лысые в заплатках, двигатель троит, от тормозов только ручник, рама сгнила и подварена, а клиент просит еще пару тройку тонн перевезти, и ну вот же, машина то до этого ездила, мы не жаловались, сюда то доехала и техобслуживание недорогое было то...
Апелляция к тому, что клиенты то раньше были довольны прекрасна, но ключевое слово «раньше были»Почему Сережа перешел в другой отдел в статье не говорится. Поэтому отталкиваемся от того, что «просто так перешел».
но по сути то это не меняет ничего. Сережино решение работает только с ним, следовательно не масштабируется, плохо поддерживается (зависимо от него в поддержке) и т.д. Вот момент Х и наступил, по какой причине совершенно не важно.
Предположу этот момент оголил такие бездны техдолга для клиента, что их лояльность к Сереже резко возросла из за фактической невозможности осилить расходы на его переработку. Но это так, смелое предположение.
К чему этот поток желчи?
У меня в команде был такой Серёжа, через год работы сделали его тимлидом, после этого жить стало попроще. Но после того, как я оттуда ушёл, местами проникся подходом, потому что в конечном итоге наша продуктивность оценивается как количество проблем, решённых в единицу времени, что бы мы о себе не думали.
Ну вообще Сережи - ценный ресурс. Бизнесу важно, чтобы работало здесь и сейчас. И даже не бизнесу, а конкретному человеку. Бизнес, как "группа товарищей, стремящаяся к общему благу", часто тянет воз в разные стороны (да, как все эти лебеди, раки, щуки и "не только лишь все"): кто-то собирает комплект увольнения, кто-то движется по головам, кто-то делает что-то еще из тех кейсов, которые автор уже описал и из тех, о которых даже автор не догадывается. И им нужен результат как можно быстрее, желательно прям вот "щаз". И Сережа им помогает в этом, делая ровно так, как они сказали. Да, может быть потом на это "дерево решений" придется повязать кучу "бантиков" ("свистоперделок") в виде "граблей и костылей", но они будут решать отдельные задачи.
Вот, например, есть у нас решение. Его просто прикола заради прогнали через анализатор кода. И анализатор на типовом коде выдал существенную часть проблем (порядка 85%). Т.е. это продуманный и все такое код, который был написан уважаемыми людьми, многие из которых в алгоритмах принимают не хуже Кнута, но им пришлось работать с весьма "волатильной" в представлениях "метазаказчика" предметной областью, для которой "годных архитектур" не напасешься. И все это произведение тех, кто о программировании знает столько, сколько не знает никто (да, туда берет только после того, как ты решишь кучу задач, самая простая из которых - это слияние упорядоченных массивов в "обратную сторону" "правильным" методом, т.е. в один проход без дополнительных массивов - да, это тривиальная задача, но она там самая простая).
Да, всегда разработка балансирует на том самом "триалектическом балансе": "быстро, качественно, недорого (выберите любые два)". И 170 часов на полную переработку решения, написанного за 50 часов - это не быстро, не факт, что качественно, но точно дорого.
И да, Аджайл тут рулит, т.к. Сережа выкатывает прототип, которые вкорячивается в бизнес-приложение, т.к. конкретного стейкхолдера от бизнеса этот прототип устраивает на все 100%. Он делает ровно то, что нужно. А проблемы масштабируемости - это проблемы роста, и если рост пойдет, то всегда есть возможность вынести из монолита этот легаси-кусок в отдельный микросервис, который запилит уважаемый разраб за овер дофига бабла, т.к. бизнес вырос и способен это осилить.
Серёга пришёл туда где уже наговнокодено до нас, за десять лет, десятком разных людей, с разными стилями, уровнем знаний и т.п.
В статье рассказывается не просто о неком условном софте, а конкретно об 1С.
Если вы не в курсе, что это такое, то вот:
«Товары на складах»
«Товары организаций»
«Товары переданные»
«Товары полученные»
«Товары к получению на склады»
«Товары к передаче со складов»
«Товары к передаче организаций»
«Товары в резерве на складах»
«Партии товаров на складах»
«Партии товаров переданные»
Это список регистров, в которых хранится движение товаров в одной из стандартных конфигураций. И да, это дублирование. И да, на практике в данных появляются расхождения...
С 1С не надо 10 лет ждать, пока наговнокодят. )))
Мне вот даже интересно - если у разработчиков из 1С спросить, слышали ли они о нормализации базы данных - им хоть немного стыдно будет? :)))
Если их рекламщики рассказывают, что "это не баг, а фича" - проблемы никуда не исчезают.
Типовые конфигурации часто "провоцируют" писать не очень хорошо. Когда у тебя выбор - или за час-два написать, но говнокод, или правильный код, но за 15-20 часов - тяжело убедить заказчиков, что надо писать правильно.
Впрочем, может за последние 7 лет что то поменялось, я давно с 1С не работаю. Но - сомневаюсь.
Во-первых, в 70-е года такой подход был стандартом.
Во-вторых, главная настоящая проблема такого подхода в том, что такой код слишком сложно поддерживать другим. Вот это и надо было объяснить начальству: что вы будете делать, если Сережа уйдет? Или заболеет? И Серёже надо было это объяснить, а не то, что он дурак.
Мне известны случаи, когда есть критически важный код, который работает, а новые требования к нему отклоняются уже 20 лет под разными предлогами: потому что автор не только на пенсии, но и скончался. Компании теряют миллионы и ничего не могут сделать.
Давайте называть вещи своими именами. То, что вы называете "говнокодом", на самом деле просто сложный код, который понимает только Сережа, который его писал. А почему он такой сложный легко понять из оговорки автора про "точное выполнение заданий" -- Сережа пишет код так, чтобы клиент получил в точности то, что заказал -- все кнопки и цвета на своих местах. Для этого ему приходится наворачивать сложности. Другие программисты в конторе пишут простой и понятный код, красивый, по гайдлайнам. Но этот простой код не удовлетворяет клиентов (они не видят код, они видят результат) на 100% и они хотят Сережу. Странные они.
Вообще, вы не задумывались почему программисты старшего возраста (то есть, с многолетним опытом работы), поголовно вот такие "Сережи"? Они просто умеют писать сложный код, читать сложный код и править сложный код так, чтобы он работал. И пользуются этим умением, чтобы получать нужные результаты, посмеиваясь про себя над "студентами".
На самом деле, существуют способы писать сложный код просто, но для этого надо использовать правильные инструменты. Например, функциональное программирование. Такие языки, как Lisp и пр. Но до них надо дорасти. Я вполне допускаю мысль, что если Сережа случайно прочтет SICP (о, бойтесь этого!) и, потом, не к ночи будь помянут, "Common Lisp Recipes", то он начнет писать код красиво и еще в несколько раз быстрее. Но вы этот код понять не сможете от слова совсем. Впрочем, это будет иметь мало значения, потому что ваш отдел сократят в полном составе, так как Сережа будет справляться один со всей работой.
Самый распространенный вариант говнокода на моем жизненном пути это описание в "модулях отвечающих за общую концепцию" каких то конкретных сиюминутных случаев. Именно для того, что бы "быстро и четко".
Если встает вопрос что операторы должны поделиться на функции ввода и контроля ввода говнокодер напишет следующее:
" if operator.Name == "Ivanov" then ...
дальше это превратиться в if operator.Name == "Ivano" or operator.Name == "Petrov" and time() < "13.40" and today() == "sunday" then
Потом добавится периодическая замена Петрова Васичкиным, который впрочем уже уволился год назад, но под его именем работает Галочкина со вторника по среду, если не замещает Милочкину, которая работает под учеткой Попова, т.к. сидит за его компьютером.
Никто кроме Сережи не в курсе этих перипетий и на их разбор требуются эти самые овер 200 часов кто есть кто и какие функции выполняет.
Сережа не пишет подсистему ролей, т.к. это не то, что требует клиент "здесь и сейчас". Сережа пишет все это прямо в ядро, копируя и размазывая это на весь проект тонким и не очень слоем. А потом приходит момент когда с этим необходимо взаимодействовать.
Это вот самый частый пример говнокода в моей жизни.
я могу сказать, почему Сережа не пишет сразу подсистему ролей -- потому что эта подсистема клиенту не нужна и у клиента возникнет закономерный вопрос, почему он должен платить за разработку ненужного ему кода. Если ему впоследствии потребуется система ролей, то Сережа напишет и ее. Но, из вашего же примера видно, что система ролей не нужна и в последствии. Если у клиента 2 (два) оператора и одному надо запретить определенные действия в воскресенье утром, то городить отдельную таблицу, придумывать интерфейс к ней, прописывать права доступа уже к этому всему (еще одна система ролей?!), обучать клиента работе с ней, писать документацию, чтобы клиент в красивой форме вписал это правило и забыл про нее на следующие 10 лет -- оверкил. Сережа прав.
Сережа мог сделать вид, что такая подсистема у него есть и вместо всего этого ifthen-а (понятного только ему и заказчику (вернее тому представителю заказчика, актуального на момент задачи и который тоже уже уволился)) и вставленного в самых неожиданных местах, написать объект/подсистему Rules пусть и с одним длинным текстом одной экспортной функцией boolean isAccess(context) . И в этой функции любым приятным ему образом генерить false или true в зависимости от контекста работы и чего он пожелает. Это не слишком отличается от предыдущего по смыслу и трудозатратам, но это локализует говнокод в одном месте, а локализованный говнокод уже не является говнокодом. Это подготовленный к обработке техдолг.
Но нет. Пока жив и творит Сережа этому не бывать.
Старый добрый java enterprise edition hello world
Система ролей в данном случае может выглядеть и простым пятистрочным конфигом + одним единственным сервисом, который умеет читать его и говорить "да"/"нет" на запрос доступа от конкретного юзера. 2 минуты подумать, 15 строк кода и Серёжа неправ.
Хорошая архитектура это не про "давайте юзать r/w базу везде и к каждой сущности добавлять инструмент управления", а про поддержку, расширяемость и адаптирование к новым требованиям.
вы правы. Но в частностях могут быть нюансы - например, система ролей прописана, но в другой части системы, и надо ее только подтянуть к текущей операции. Если условный Сережа не знает архитектуры системы в целом и не подозревает, что можно добавить тип роли и подключить готовый модуль,, то будет наворачивать систему условных операторов, и на каком-то этапе замена Петрова Васечкиным пойдет тяжело.
Встречал такие штуки в системах - есть четкие настройки, все настроили, и - бац... не работает (последний случай, который вспомнил - не было открыто поле для редактирования). Начинаем выяснять, оказалось, что для конкретно одного локации прописано свойство закрытого для редактирования.
Я, помнится, как-то заморочился над системой замещающих, но ею попользовались пару раз и забили бот. Но и у меня на этот бизнес-процесс со схемой и всем таким прочим, включая полную привязку ко всем другим процессам с исполнителями, ушло совсем немного времени.
В той же конторе мы сделали таблицу с периодическими константами и кеширующую функцию, которая эти константы поставляла в код. В итоге вместо if(User == "Ivanov") было что-то типа if(User == getGlobalConstData("MegaUserForXXX")). Ну это совсем упрощенно если. Это как раз использовалось в последствии очень активно.
ХЗ, я хоть и Сережа, но я как-то не могу писать код не по стандарту. Если только в статьях, но там нет говнокода - там есть переменные из одной буквы, которых в продуктиве у меня нет.
беда в том, что задача: "В воскресенье с моего компьютера мой зам будет подготавливать для меня урезанный/расширенный отчет" будет выполнена буквально.
Прямо в запросе к данным появятся имя компьютера и день недели. "Быстро и точно" все в точности как заказчик заказал. Впрочем я не прав. Во всех запросах к данным.
Но сережин вариант работал и в первый день и через год, когда дела пошли в гору и добавилось еще 2 сотрудника.
А система ролей - запускалась бы неделю.
Один if добавить сильно быстрее и ничего не ломается.
Потом - in_array, затем список человеков из файла, затем... Да к черту, для 100 человек можно остаться со списком в файле и делать что-то более важное, чем админку для сотрудников, которые меняютя раз в 2 года
все положительное из подхода Сережи Вами перечислено в прошедшем времени. Клиент взял кредит в техдолг прекрасно жил, но постучались и собираются стучаться дальше, а жить в долг было так хорошо...
Вот прямо сейчас в реальном времени зависла продажа сетевому клиенту. Все на ушах, штрафы, время и т.д. Штрафы к слову больше прибыли. Проверяем что случилось. Оказывается
if patrner.name == "blablabla" then doc.adress = "" через строку в коде, спасибо дорогому субподрядчику. Что тут криминального казалось бы? А в том, что есть уже универсальное решение проблем заказчика, но его внедрение прямо сейчас аннулирует все эти инъекции и никак не поможет избежать штрафов за поставку. А ревью что же делает таки этот код и почему он адреса так виртуозно меняет не обращая внимания на адреса из БД - это тоже сутки работы - и никак не поможет опять же избежать штрафов за непоставку. Ну и плюс подключение программиста каждый раз, когда надо изменить адрес.
А где же Сережа ловкий мастер сверхэффективного кода? А его нет, это уж как водится. А где же заказчики и приемщики этого сверхэффективного кода? А они тише воды ниже травы ловко играют в бюрократические игры, перебрасывая ответственность вот типа: этот код уже работал год и еще бы десять проработал.
С клиента денег возьмется за полное универсальное решение и больше, т.к. это и есть внедрение полного решения с доработками заказчика. Его говнокод у него и останется т.к. на избавление от него у клиента нет ни денег ни времени. Поэтому в круг он заплатит больше, чем другие, получив в итоге меньше. Ну и операторы научатся вручную доки генерить, т.к. Сережено решение имеет некоторые особенности.
Понимаете, все кто против сережи упирают на то что придется заплатить еще раз. Но видят это так, будто сережа деньги взял а в замен ничего не дал.
А рассматриаать нужно как с автопромом
Купил бу форд транзит - ездил работал. Понял через 2 года, что надо не форд, а маз - купил маз.
А в вашей ситуации надо просто поставить актуальный адрес в этот if, а потом нормальное решение сделать, без авралов
ничего просто не получится, потому что проблема у клиента не в адресе. В адресе (адресах) проблема у нас, т.к. мы не можем без анализа просто заменить его неработающее решение на работающее наше, не потеряв его функциональности по адресам. Если мы быстро ставим наше, то клиент теряет адреса. В данном случае клиент оплатил свой техдолг невозможностью оперативного обновления.
Свой потолок развития клиент уже определил, когда принял такой код. И влез с ним в проекты, где его за неоперативность штрафуют соизмеримо прибыли. Считай что вкрутил во время сборки машины неликвидные копеечные болты, а теперь когда на машине надо гонку ехать, оказалось что двигатель перебирать надо.
Можно ли было этого избежать? Можно, выполнив решение хотя бы самозадокументированным. Вынести его в отдельный блок и написать краткий комментарий отчего происходит подмена адреса и почему адрес не хранится в БД, а захардкожен. Но нет, адреса подменяются не в секции задания переменных объекта, где его все ожидают, а в ядре генерации документа. Потому что вмазывать *овнокод нужно как можно глубже в систему, иначе потомки не оценят.
О точно, у меня был период когда я испражнялся от ужаса, встречаясь со сложным кодом. Потом преодолел этот барьер и сейчас сам пишу такой код, от которого мегабайты замерзают в воздухе от страха
То, что вы называете "говнокодом", на самом деле просто сложный код, который понимает только Сережа, который его писал. А почему он такой сложный легко понять из оговорки автора про "точное выполнение заданий" -- Сережа пишет код так, чтобы клиент получил в точности то, что заказал -- все кнопки и цвета на своих местах.
"Сережа" херачит бизнес-логику прямо в обработчике кнопки на форме вместо выделения данного кода и размещения в классе/таблице. Или меняет базовый класс там где в этом просто нет никой необходимости. Или добавляет поля в системную таблицу там где должен создавать свою. И прочее, прочее.
Поймите, в таких системах, это не про код на экране сложный к пониманию, а в следовании принятого в конкретной системе. Не важно что в твоих машинах под капотом, вопрос в том чтобы ты не бросал их посреди дороги других.
Вообще, вы не задумывались почему программисты старшего возраста (то есть, с многолетним опытом работы), поголовно вот такие "Сережи"? Они просто умеют писать сложный код, читать сложный код и править сложный код так, чтобы он работал.
Да ни при чем тут возраст. Выворачивает не от сложности, а от чужеродности стиля/подхода/структурирования кода для данного места. Все должно быть на своих местах не просто так.
И когда, в системе подразумевается определенное место для данного кода, а его пишут одной процедурой да еще и не на том слое, в силу незнания продукта/системы, это не признак умения писать сложный код. Это полный провал в понимании паттернов и гордится тут нечем.
Э... вообще-то "метод Серёжи" - это удешевление разработки взамен увеличения технического долга.
И применять или нет такой метод - зависит от жизненного цикла приложения.
Если я пишу скрипт автоматизации, который мне надо 2 раза запиустить и лог которого я буду проверять глазами - то я и напишу ровно такой скприт автоматизации + юнит тесты.
А "интеграционное тестирование" проведу методом "grep -r ........"
Ничего в этом зазарного нет.
В бизнесе существует ровно два вида результата: работающий в срок и любой другой. Сережа делает первый вид, и клиенту это обходится дешевле других вариантов - по факту.
Если в 77й версии обнаружатся непреодолимые костыли, или Сережа подвергнется фактору автобуса - то это полностью ответственность заказчика, задача руководителя конторы обозначить риски. Как правило, заказчики не настолько тупые в плане денег (как их представляют себе пишущие правильный код программисты ^w), чтобы не понимать, что чем дешевле сразу, тем дороже потом переделывать.
Если совсем конкретно, то лучшее из виденного мной - привязка сереж за конкретными заказчиками, и введение таких независимых стабильных связок типа-фриланса. Сережа не лезет в другие проекты, другие не лезут в сережины, перед клиентом отвечает начальник.
Забавно. Синдром Д'Артаньяна, а в случае автора со слов автора целой команды Д'Артаньянов-программистов вместе с автором. Они конечно очень хорошие ребята, никогда не говнокодят, и клиенты вообще не понимают что им в жизни надо без программистов. Ну а кто им ещё об этом скажет, как "неговнокодеры", в чём они всегда не правы.
Есть другая сторона вопроса. Если программисты предлагают громоздкое общепринятое решение, универсально работающее у конкурентов, но оно медленнее, неудобнее для конечного пользователя, и не позволяет вносить серьезных изменений.
да, кризис IT в решениях для бизнеса явно имеет место быть.
Само количество языков программирования, на мой взгляд, говорит о том, что они не вполне соответствуют объекту. В математической или музыкальной нотациях нет же такого разнообразия диалектов. А в программировании их множество и то, что мы решили задачу в одной нотации не особенно облегчает ее решение в другой. Даже логику решения извлечь и то нелегко.
Настоящие программисты узнали, что ПО должно решать проблемы бизнеса.
Все это очень, конечно, хорошо, но вот был я на проекте, представлявшем смесь красивого кода и быдло-кода. Причем смесь жуткую. А причина очень простая - когда-то написали, через некоторое время разрабы сменились, а еще спустя некоторое время выяснилось, что нужно дописать фичу, подправить тут и там, добавить новые API... И все. И никто это рефакторить не будет - заказчик не готов платить за переделывание того, что и так работает, а как там оно, под капотом - заказчику глубоко до одного места.
Знаю контору с очень сложным и очень кривым API, обслуживающим очень крупных клиентов(связь). Дока на API датирована 2009 годом, содержит сотни(sic!) методов, возвращающих XML по 15000-20000 нод. Текущая команда разработчиков вообще неотдупляет что половина API делает, тупо проконсультировать никто не может, разрабы, которые этот API писали давно уволились и неизвестно где. Каждый фикс занимает неделю и не всегда работает. Зачастую вместо фикса предлагается использовать костыль, который позволяет обойти проблему....
Я не призываю писать говно-код, я просто хочу сказать, что, если чо, я просто говорю, что в реальности очень часто желания разработчиков писать по правилам и желания клиента не совпадают. И тогда на сцену выходят Сергеи.
Говнокод был и будет всегда. Но суть-то в том, что заказчики есть такие, которые готовы платить за то, чтобы обязательно "правильно от профессионалов", и те - которым надо "вот такую колонку в таблице" - и никак иначе ("и ваши профи-советы не нужны, я же башляю").
И, вероятно, дело даже не столько в деньгах и сроках - а вот в именно психологии человека-заказчика, в хотелках.
В принципе во многом согласен. Какая архитектура "правильная" нет смысла обсуждать, пока в полном объеме не ясны автоматизируемые бизнес (и пр.) процессы, пока не ясно, в какую сторону и как будет развиваться бизнес. Вопросов много, а ответов для нового бизнеса мало. Неправильно выбранная "правильная" архитектура зачастую будет хуже кода "на коленке".
Что касается стиля программирования, принципов именования, разделения на функции/классы и пр. - это сильно дискуссионный вопрос, скорее вопрос личных предпочтений. Например, я всегда жалел, что вводил лишние абстракции и промежуточные слои (типа на будущее). На практике почти всегда в итоге было лучше делать проще, прямолинейнее и понятнее.
Также почему то не люблю разбиение на множество мелких функций/методов. Проглядывая чужой код, не раз ловил себя на мысли, что меня раздражает перемещаться по сотням микро функций (в несколько строк), да еще разбросанных по множеству библиотек. С другой стороны, спокойно читаю код например Wagtail, где файл может содержать несколько тысяч строк.
Ну, и самое главное - скорость запуска проекта и... вообще вероятность запуска. С "правильным" подходом дело до запуска может вообще не дойти. Это конечно новых проектов в основном касается. Ну, а когда бизнеспроцессы устаканятся, вступает в силу старый программисткий принцип: работает - не трогай.
За гомнокод всегда беру дороже..
Ситуация — прихожу в стартап ещё до релиза, а там до меня на фронте работал такой Сережа. А именно — клиент доволен, все сверстано очень точно, а внутри — копипаста на копипасте, непонятные конфиги ради конфигов и компонентов с кучей if.
Например, у стандартных "панелей с тенью" из материал дизайна убрана тень, а потом вручную добавлена через style.
Или зачем делать нормальную верстку чтобы один из "под-хедеров" знал свою ширину и менялся в зависимости от неё, если можно после каждого обновления данных вручную вызывать функцию пересчета на сотню строк, которая его идеально выставляет как надо.
Только одна маааленькая проблемка — сережа ушел, а теперь надо все это великолепие синхронизировать с беком. Упс.
Конечно повезло с СЕО который давал время рефачить (хотя не факт, возможно он думал что интеграция занимает столько времени), а я в это время брал компонент под интеграцию и выжигал там всё напалмом.
В итоге первые полгода, наверное, мои коммиты добавляли фичи, уменьшая общее количество строк. И, видимо, перформанс был на уровне с Сережиным, вопросов не было.
А вот через год выяснилось, что если они верстали примерно год 4 раздела, то 5ый раздел добавляется за 2 недели.
Или что ушли странные баги типа "на пути А-Б-С летит верстка. да только там".
Вопрос с точностью я решил договором с дизайнером, которая пошла навстречу и сделала полноценный стайлгайд и (вот за это ей прям большой респект) придерживалась его. То есть у нас реально было 8 стилей текста, прописанных в теме и она честно рисовала дизайны с этими стилями.
Конечно до сих пор есть с͏̨͝т̴а̵͟р̸̨ы̨е ͞҉ра҉з͘д̛͘̕е͘л̀͠ы̷̡, с хелпом например, где поверх текста из темы наверстано куча стилей которые делают его таким же, но туда никто обычно не ходит.
Разгадку этой истории вижу во фразе
Но сработал закон Вселенной – чем больше задач клиента ты решаешь, тем больше их становится. Серёжа перестал справляться с возрастающим потоком.
Ну надо же! Кажется что из-за хотелок клиента, но, сдается мне, это из-за возрастания сложности.
А программисты провафлили, надо было не переписывать всё с нуля, а просто заменять компоненты, а если их в этой каше нет — резать и заменять на отдельные, тестируемые, изолируемые и бла бла. На этой ещё больший скилл нужен, чем сразу красиво сделать.
Для пущего эффекта можно было подождать некоторое время, потому что чем больше функционала, тем медленнее работает Сережа.
С другой стороны да, это стоит бОльших денег, а если надо дешево — тут Сереже нет равных, согласен.
узнаю в себе Серёжу... к счастью в далёком прошлом
Пока существуют плохо поставленные задачи, странные
ошибки и нереалистичиские расписания машинного времени, будут
находится настоящие программисты, желающие взять на себя и
решить проблему, оставив документацию на потом.
Читаю и узнаю себя. Я тот самый условный Сережа, который админил линуксы и кодил деплойменты на fabric еще до появления этих ваших ansible, потом, насобачившись писать скрипты и все еще будучи админом, начал решать более сложные задачи, потому что понял, что могу. Залез и в анализ данных, и в микросервисы, уяснил пару популярных паттернов проектирования и ООП, потому что остро встала проблема переиспользования своего же кода. Потом появилось магическое слово "DevOps", и я, сменив три конторы, продолжал говнокодить свой рокет-сайенс и какие-то задачи по автоматизации, при виде которых прочие девопсы обычно разводили руками.
И в течение ВСЕГО этого времени у меня не было толкового ментора, который ткнул бы меня носом в мой говнокод и объяснил бы, что я делаю не так.
Излагаю свой крик души и воззвание ко всем программистам. Если к вам приходит админ в поисках ментора в обмен на knowledge transfer по k8s/helm, или просто за пиво/банку смузей - не отказывайте ему. Возможно, этот админ потом переведется в ваш департамент и вам придется работать с ним вместе, как пришлось это делать программистам из коллектива Сережи.
Вот поддержу! Я всю жизнь занимаюсь только тем, что мне нравится. Это мое дело. Ментора, советчика, критика, гилдмастера, ревьюера у меня никогда не было, я всю жизнь читаю чужой код и разбираюсь в нем со временем. Образование не профильное. Не было тогда профильного в доступности. Я Серёжа, так сложилось, что я люблю разбираться в непонятном, мне хочется решить чью либо проблему, но оценить верно я могу только опираясь на свой опыт. Вся деятельность не приносит миллионов, но удовольствие от решенной задачи(своей, клиента) бесценно.
Поделюсь примером. Недавно был опыт(первый работы по найму в студии, где ребята моложе меня на 10 лет в среднем). Была задача спарсить кучу инфы из разных источников. Ведущий программист требовал месяц и приступил к работе по написанию парсера и обработке данных. Я не обладая компетенциями этого человека решил с помощью стороннего софта и if else итд, за неделю... Задача должна быть решена максимально эффективно, а не красиво.
.
Клиентам - совершенно неважна лирика про архитектуру, Сережа - просто демпингует на рынке, ну и понятно, что история не реальная - лирика ... вообще, я вначале посмотрел бы код Сережи, может так статься, что и не так все плохо, т.к. "мозги" испорченные паттернами восстановить иногда еще сложнее ... но и обратный случай был только был это Каспарс - уволился под моим нажимом ... но начальство хорошо вспоминало, потому что я просил адекватную зарплату, а он работал сколько давали, а клиенты хотели скидку с демпинговой цены гос. закупок ... в итоге не бизнес, а утопия. Может и правда, пусть Сережа программирует, и по ночам исправляет свои баги, потому что клиенты уже не хотели платить за поддержку ... А зажравшимся мордам как я лучше найти коммерческую разработку, а не по гос. дешевизне, чтобы есть пельмени и пахать как индус 12 часов
Ах, да ... походите на Агил сброды, послушайте менеджеров о их пользе, и тогда Сережа будет идеальным для вас программистом ... Только не забываете, что это не больше чем психологическая атака, чтобы сбить цену разработки за счет программистов.
Удалите менеджерский сброд, и Сереж в компании, автоматом не будет
Только за то что Сереже важна точность интерфейса дал бы ему плюс +10 пунктов перед другими программистами.
Зачастую программисты пренебрежительно относятся к верстке, высокомерно считают что это ниже их достоинства делать точную вёрстку в соответствии с дизайном. Зато код который никогда никогда не увидит кроме них самих должен быть идеальным.
Сиюминутная точность под конкретные данные. Очень точно сверстанный летом сайт, но который при -10 на улице минус сожрет, потому что Сережа сделал лютую дичь под непродуманный дизайн. Сережа быстро поправит, клиент будет доволен.
Лучше так чем программисты уверенные в собственной гениальности делают что-то вообще отдаленно напоминающее исходный дизайн, а потом нужно еще столько же времени на исправление багов интерфейса.
Почему сразу точно не сделать? Перед тем как вообще написать хоть строчку кода нужно вместе с дизайнером и заказчиком пройтись во дизайну и проверить учтены ли все случаи..
Не лучше. И что значит «точное соответствие дизайну»? Под Loren ipsum на 1 макете вместо десятка? Под 1 десктопное разрешение? Про «отдаленно напоминающее» и тут же про красивый код - как минимум странно. «Вместе с дизайнером и заказчиком» - это в какой вселенной?
Сразу видно токсично- истеричное поведение...
Делать как в дизайне означает если шрифт размером в 18 пикселей, значит он должен быть и верстке 18, а не 20 или 16. Тоже самое с расстояниями, цветами и т.д. это делается не так сложно. К сожалению, разные личности вроде вас пренебрегают точностью, делают невнимательно и в итоге приходится либо переделывать по сто раз, либо махнуть рукой и оставить как получилось. За это Сереже респект, он делает точно.
Я не знаю в какой вселенной вы живете, в моей вселенной перед разработкой каждый дизайн проходит детальное обсуждение, после чего если нужно дизайнер дорабатывает некоторые моменты. Всего заранее предусмотреть физически невозможно конечно, потом уже бывает всплывают некоторые упущения, хороший разработчик сразу же обратится по этому поводу к дизайнеру или менеджеру и они вместе найдут решение.
Делать как в дизайне означает
В контексте данной статьи «делать как в дизайне» означает «разместить поле прямо по центру, где просил клиент, и выделить его жирненьким, как он просил, а не следовать общим гайдлайнам UI приложения».
Не знаю откуда вы взяли этот контекст, в статье написано следующее:
"Особенно важна точность интерфейса, включая цвета, шрифты, названия и порядок колонок и т.д."
И это действительно важно. Почему-то многие пренебрегают этим. Если есть дизайн система и дизайн ей не соответствует, то это проблема с дизайнером, а не с разработчиком.
И это действительно важно.
Важно это или нет, целиком зависит от того, о каком продукте идёт речь. Если мы говорим о корпоративном софте (а default-soft у автора nmivan, к слову, 1С), в процессе его разработки часто вообще не существует никакого дизайнера, или в лучшем случае он пропишет общий стиль приложения, но не будет прорисовывать все формы и таблички.
Ну и насколько это важно, тоже вопрос. Дизайн важен с точки зрения брендирования и просто профессионального вида приложения. Разработать же качественный дизайн с точки зрения юзабилити и «юзер экспириенс», ну так в корпоративном софте такого не бывает. Это сказка, которую вам расскажут разве что внедренцы, пытающиеся продать услуги своего дизайнера. Реальный «юзер эксириенс» вам может дать только сам юзер по обратной связи.
Если нету дизайнера - то не о чем говорить, пусть делают как хотят :)
В данном конкретном случае речь идет не об юзер экспириенсе хороший он или плохой, тяжело его создать или легко, а про то что расхождения между дизайном и версткой должны быть минимальными.
Если компания работает с заказчиками (случай из статьи), то почему вы вдруг решили что неважно чтобы в дизайне и верстке цвета, размера шрифта и порядок колонок(!!!) могут различаться и что это вообше не важно? Заказчик предоставил дизайн, заплатил деньги - почему вдруг вы решаете забить на верстку?
Я не собираюсь вступать в спор о том насколько важен дизайн, но один из параметров качества разработки это соответствие дизайну.
И если макет и верстка выглядят примерно следующим образом как картинка снизу, то значит фроентенд разработчик делает свою работу плохо и ничего больше.
И это происходит зачастую засчет того, что почему-то многие разработчики работают по типу: "Да ну дизайн не важен, ииитак сойдет". В конечном итоге получаются кривые недоступные сайты с плохим юзер экспириэнсом.
Поэтому повторю еще раз, Сереже +10 очков за точную верстку.
https://i.kym-cdn.com/entries/icons/facebook/000/031/680/unfinished_horse.jpg
Если компания работает с заказчиками (случай из статьи), то почему вы вдруг решили что неважно чтобы в дизайне и верстке цвета, размера шрифта и порядок колонок(!!!) могут различаться и что это вообше не важно? Заказчик предоставил дизайн, заплатил деньги — почему вдруг вы решаете забить на верстку?
Вы немного не понимаете, о чём речь :)
Нет там скорее всего никакой вёрстки даже как вида работ. Автор имеет в виду типичную ситуацию при разработке форм для бизнес-пользователя.
Есть какой-то общий принцип построения интерфейса, общий гайдлайн — поля имеют такой-то шрифт, цвет, расположены в такие-то колонки и т.д.
Что делает конечный пользователь, если у него есть прямая коммуникация с разработчиком, минуя аналитиков, менеджеров проекта и т.д.? Он заказывает: вот тут на форме отгрузки сделайте мне поле «Сумма ТТН» 18 кеглем, и красным, если по клиенту есть просроченная дебиторка. Это нарушает все гайдлайны, смотрится дико колхозно, и вообще правильнее было бы сделать проверку дебиторки ещё до того, как она логисту падает на оформление отгрузки… но в этой конторе так сложилось, её проверят логист. И заказывает доработку он, ему так удобнее, да, колхоз, но он будет меньше совершать ошибок.
Опытный программист начнёт рассказывать, что это смотрится ужасно, нарушает гайдлайны, и вообще надо переделывать бизнес-процесс. А Сережа просто сделает страшно, но зато как заказывали, клиент доволен.
Вот так оно в реальной жизни и выглядит.
Хамить не стоит. Вы же написали, что главное точное соответствие, а не идеальный код, верно? Я вам ответил, что говнокод при точном соответсвии дизайну ещё хуже. Речь не идёт о несоответствии в цветах, размерах шрифтов. Это вообще недопустимо. речь идёт про подгонку результата под макет пофиг какой ценой.
Про детальное обсуждение и доработки и все такое - лукавите. Либо у вас процесс без сроков и результата.
Я говорил исключительно в контексте того что описано в статье, а там речь шла именно о цветах и размерах шрифтов.
Есть у нас и сроки и результаты. Обсуждение дизайна с разработчиками обязательный шаг, в конечном итоге экономит огромное количество времени. В ходе обсуждения очень часто всплывают недоработки в макетах
Сережа делает быстро и дешево, а остальные ему завидуют. В ТЗ был пункт про масштабирование? Про понятный код? Ну и все, Сережа вас всех уделал. Зачем бизнесу платить в несколько раз больше и ждать дольше? Надеюсь Сережа откроет свою компанию, где будут брать только кодеров из ПТУ.
Когда настанет время возвращать техдолг
Из моего уже опыта поддержки корпоративного софта, с 90-х и уже до седых волос, могу сказать, что это время скорее всего не придёт никогда. Ну точнее, оно значительно превышает среднее время жизни одной учётной системы на одном предприятии. Поэтому бизнес от «тяп-ляп» скорее всего таки останется в профите. Исключения бывают, но это именно исключения, а не общее правило.
Специально зарегался на Хабре, чтобы прокомментировать. Я сам был и в роли говнокодера и в роли специалиста, который воспринимает BestPractice, как Библию. Многие разработчики прикладного ПО, в отличие от Серёжи, пребывают в иллюзии, считая себя творцами чего то вечного и незыблемого. В реальности же код ваш проживёт лет 5-7 если повезет. За это время однозначно что то произойдёт: сменится парадигма разработки, появятся новые фреймворки, новые технологии и под них новые протоколы и языки, прилетят инопланетяне, рак на горе свистнет и т.д. Обычно бизнесу нужно решение здесь и ещё вчера и подешевле. Ему нет дела до абстрактных красот ООП и всей этой ереси инкапсуляции и полиморфизма.
Без подробностей сложно понять, кто из них прав, можно увидеть разные варианты: можно додумать ситуацию так, что прав Серёжа (и может у него вообще не говнокод, может он разбирается в предмете лучше коллег, которые не могут понять его код (а ему, в свою очередь, сложно ограничивать себя и делать так, чтобы они поняли), а можно её додумать так, что Серёжа копит техдолг и просто не успел обжечься на каких-то плохо продуманных решениях.
Можно придумать ситуацию, когда это не так. Представь, что один из программистов вместо пузырьковой сортировки использовал более оптимальный алгоритм, а другие его не знают. И для них это может выглядеть это может так, что код переусложнён и вообще непонятно как работает. В таком случае наверное правильнее повышать квалификацию остальных программистов, а не ограничиваться примитивными и неэффективными алгоритмами?
Ну не обязательно речь про те примеры. Вспомнилась одна дискуссия, кажется на opennet.ru, где сравнивались две свободные операционные системы, сторонник одной, для иллюстрации её преимущества, привёл код какой-то функции из обеих систем: в предпочитаемой им системе код был гораздо проще и понятнее. Но оппоненты объяснили, что во второй код оптимизирован, вроде с учётом особенностей той или иной архитектуры, и он сделает то же самое, но быстрее.
Далее, сортировка — это просто условный пример для иллюстрации (конечно, часто можно не задумываться и использовать стандартный вариант сортировки из той или иной библиотеки). Но и во многих случаях самое простое решение не является оптимальным, при этом более эффективный алгоритм не всем будет очевиден.
И я же не говорю, что это именно случай Серёжи. Исходя из того, что написано в статье, Серёжа для нас находится в состоянии квантовой суперпозиции хорошего и плохого программиста, и только в результате наблюдения (если мы посмотрим его код) он окажется тем или иным случаем.
Чтобы не быть голословным — вот пример реального кода на C# из библиотеки ASP.NET Core, регистрирующего самописный делегат-middleware
public static IApplicationBuilder Use(this IApplicationBuilder app, Func<HttpContext, RequestDelegate, Task> middleware)
{
return app.Use(next => context => middleware(context, next));
}
IApplicationBuilder Use(Func<RequestDelegate, RequestDelegate> middleware);
public delegate Task RequestDelegate(HttpContext context);
Живописно. У нас такой Сережа был, даже много. Поэтому и код соответствующий. Однако история не такая красивая. Все работало через такую то мать, как бог на душу положит. Соответственно и бэклог на тысячи задач и десятки тысяч человеко/часов. Вместо развития приходилось заниматься практически постоянно поддержкой.
Все здорово, пока Сережино поделие не торчит наружу. Как только говнокод, заключающийся обработке подразумевающихся данных в подразумевающийся результат, начинает работать с любыми данными - возникает инфобез.
Все мы в какой то момент по требованию "гениальных" бизнесменов немного Сережи ...
А потом наступает момент, когда ты погребен под тоннами "говнокода", и проще с нуля, чем исправить.
Не совсем. Бизнесмены не понимают риски или не хотят принимать, хотя скорее Сережа им не объяснил, что в долгосроке быстрый результат точного соответствия ограниченным требованиям череват. У бизнесмена горизонт планирования чуть дольше, чем Сережин результат.
Тут бы между Сережей и бизнесменом переводчика в виде проджекта. Но зачем - проджектов как минимум считают лишними, а то и ненавидят.
Вы серьёзно думаете, что бизнесмены чего то там не понимают? Всё зависит от стороны баррикады на какой вы находитесь. Если вы работаете в IT, то вы не должны допускать Серёжу до работы пока не научится, потому что это вы несёте эти риски. А если на противоположной стороне , то вы будете выбирать Серёжу, потому как быстро, дёшево и страховка бесплатная(ущерб то в случае чего оплатит поставщик услуг IT).
Серёжа — личность и человек дела. А автор — просто завистливый ноунейм.
Интересен уровень обсуждения. Написано стоПитсот коментариев о говнистости кода, которого никто не видел
Не что не ново под солнцем. Не знаю, как сейчас, а раньше индусы промышляли тем, что демпинговали, переманивали клиента, забирали проект и пару лет показывали дичайшие показатели по сроку/цене. А потом, когда проект превращался уже в конкретное месиво, начинали задирать цену. Даже термин такой был "индусский код". Клиент, конечно, пытался вернуться или еще куда-то дернуться, но с таким кодом его или не бради вообще, или тоже выкатывали кусачие ценники. Скупой платит дважды.
Так и здесь, думается, что Сирожа просто свалит в какой-то момент на большие деньги, написав себе в резуму кучу лет работы ведущим программером (и это даже будет чистой правдой), а мудрое начальство останется с неподъемным куском г. и без программистов.
Также всё хорошо, пока Серёжа один и работает. А если задач стало больше, и он не справляется? Коллегу ему не нанять, он ничего не поймёт в таком коде и будет только отвлекать Сережу вопросами. А если Сережа ушел в отпуск, заболел или уволился?
Иногда бизнесу важнее минимальное кол-во багов, чтобы не терять деньги и клиентов. А стоимость и скорость разработки на втором месте. К таким проектам Сереж нельзя подпускать.
Знаю одну историю, когда существующая очень давно, сложная, имеющая большое количество пользователей программа стала понемногу отставать от программ-конкурентов по отдельным функциям. Новые версии выпускались, добавлялись фичи, некоторые даже опережали конкурентов, но в целом отставание росло. Одной из существенных причин отставаний был возраст программы. Технологии существенно поменялись за годы и без существенной переделки ядра, общей архитектуры, движка пользовательского интерфейса было тяжело оперативно менять и наращивать функционал, удовлетворять растущим запросам пользователей.
Руководство решило совершить смелый шаг - переписать ядро. После нескольких лет параллельной разработки новой и поддержки старой версии, случился провал. Долгожданная новая версия сильно отличалась интерфейсом от старой, а главное по функционалу была настолько урезанной в первых выпусках, что, несмотря на очевидные новые фичи и потенциал развития, она провалилась в тестовых релизах.
Последовали кадровые перестановки, уходы и увольнения как среди руководства, так и в команде разработчиков. За это время отставание от конкурентов увеличилось еще больше. И было принято решение «эволюционно» внедрить часть решений из почившей новой версии в старую, добрую, любимую всеми.
Но чуда не случилось, таланта новых привлеченных и оставшихся программистов и внедренных ими новинок не хватило, чтобы полноценно конкурировать на рынке, также можно упомянуть плохой маркетинг, и такую же обратную связь с пользователями. Несмотря на многолетнюю любовь, очень много пользователей осваивали другой софт, во время ожидания нового релиза, и слиняли окончательно после провала. Программа перестала развиваться совсем и, считай, умерла, вместе с сообществом пользователей и группой разработчиков сторонних плагинов.
Этот поток сознания написан в попытке обратить внимание, что говнокод (которого не было в принципе в этой истории) видимо не является определяющим в реальном мире, и что поддерживать и развивать написанный по промышленным стандартам продукт после смены команды тоже не сильно легко, а уход пары талантов из команды вполне может похоронить проект, как бы они красиво не кодили. Определяющим походу являются деньги вложенные в маркетинг и цена для потребителя (т.е. тоже деньги), а что там за кадром происходит – «проблемы индейцев». ))
Прочитал на одном дыхании расценил как художественное произведение, но подозреваю, что это может быть действительно реальная история в небольших компаниях...
По существу истории проблема очень простая, а именно отсутствие опытного тимлида в компании, которые смог бы обьяснить корень возникшей проблемы. О самой проблеме поговорим позже... а пока разберемся как стоит действвоать в подобных ситуациях:
Первое и самое важное: любые размышления о говнокоде стоит внимательно анализировать и разбирать, а не замалчивать (докапываясь до источника претензии - исключая любые эмоции, а об этом позже), так как они могут превратиться в разновидность преследования (травли) несчастного Сереги и приводить к отавлению отношений внутри коллектива, а это самый главный залог успешной работы (при первых признаках отравления - приглашать веселую молодую HR психолога и в коллаборации с тимлидом начать разбираться с враждебынм отношением - всем ходить на шашлыки, собираться за любимым хобби - играть в игры и т.д.).
Второе это вопрос почему заказчик знает как устроена команда разработки по именам, но это уже вопрос наверное организационного плана и вроде как тех процессы во многих компаниях секрет успеха фирмы, а тут видимо или внутренний заказчик или что-то еще в любом слчуае к делу отношения не имеет, но факт любопытный.
Третье, относительно сути травли командой Сереги, который столкнулся с враждебным отношением в существующем коллективе. Проблема связана с отсутствием нормального проектного управления (думаю, что просели в области BA, но точнее нужно разбираться на месте ;). В обьяснении руководителя пропущена статья расходов - владение кодовой базой (уровнем понимания всеми участниками принципа вн. работы приложения) при "плохой" архитекктуре (говнокоде), введение нового программиста начинаеться с обучения и выглядит дороже, если нужно разгадывать загадки (проводить обратную инженерию кода) и дешевле если применять хорошо известные подходы (шаблоны проектирования) или даже использовать готовый FrameWork (который заранее знают и понимают новые участники).
Четвертое, предыдущая пробелма возникает, но только в случае отсутствия на разработку дизайн документации (да, именно тех самых занудных UML диаграммок, которые своременные команды зачастую вовсе не составляют, а получив SRS сразу переходят к разарботке) и вопрос начального обучения становиться совсем незначительным (1 час посмотреть видео с дев дизайном и ты покрыл кодовую новую базу).
Пятое, в рассказе сталкивают две качественно разные системы один разработчик и команда разработки и нужно понять, что в первом случае это действительно может функционировать быстрее, но система имеет проблемы с масштабированием, а вот вторая система имеет накладные расходы (зачастую игнорируемые и превращающиеся в технический долг) при координации работы, но при должной организации позволяет бесконечно наращивать команду и сложность решения. Ответственный за масштабирование команды наверное стоит возложить на руководителя или тимлида.
Я не разработчик, так — рядом постоял и маску на стройке нашел. Но разве не на Хабре постоянно приводят в пример байку: «Пока Петя разрабатывал план — у Васи уже было костыльное приложение, которое скачивали и платили. Когда Петя выкатил идеально написанную прогу — ее никто не смотрел даже, потому что Вася уже всех подсадил на свою и потихоньку рефакторил костыли.»
Вроде обычный цикл, когда нужная фича быстро и костыльно запиливается, а потом рефакторится, когда довольный клиент уже за все заплатил. А в кост закладывается как срочный говнокод, так и последующее приведение его в порядок, все при деле и все довольны, а приложение потом не рассыпется, когда придется масштабировать.
А мне до сих пор непонятно "особое" отношение заказчиков к программёрским конторам. Заказчик заказал продукт, исполнитель сделал его плохо и сдал заказчику, а потом объявляет заказчику - его-де надо переделать и просит за это денег и заказчик платит. Для меня это сродни тому, как подрядчик построил дом на херовом фундаменте, а потом объявляет мне, что, чувак, мы херово построили - надо переделывать, плати ещё за один дом; вы бы стали платить? Какая разница, что кодил Серёжа, он же ваш Серёжа.
Может Сережа и не по канонам пишет код, но читает он его судя по всему заметно лучше, чем вся ваша команда вместе взятая ))
Знавал таких Серёжей.
Как-то на время подключили на один маленький проект, который единолично вел такой вот Сережа.
Первое что насторожило - подход Серёжи: по любой мелочи часовой созвон, на котором всячески изображается готовность помочь, но в итоге просто по нескольку раз повторяется то что ты скажешь, и по сути ничего обсудить не удается. Человек изображает бурную деятельность, и клиентам это нравится, но по факту впустую тратит время. От практики созвонов с Серёжей естественно пришлось отказаться, ввиду их абсолютной неэффективности.
Второе что привлекло внимание - отсутствие автозагрузки классов на проекте: обычно это означает что идёт жёсткая борьба за быстродействие. Но код проекта как-то не показывал, что стремится быть быстрым - кеширование почти не используется, море говнокода и лишней работы в коде, все тормозит. В коде настолько много лишнего, что после рефакторинга в своей небольшой зоне ответственности код сокращался в разы, почти полностью заменяясь библиотечным функционалом, и наконец то становился более-менее понятен с первого взгляда. Стал разбираться как же так вышло, что за несколько лет жизни проект не обзавелся автозагрузкой - это же 15 минут работы, элементарный функционал. В итоге нашел: задача на оптимизацию проекта была, пару лет назад, там в том числе затрагивался вопрос автозагрузки, но Сережа просто не понял что от него хотят, и в итоге все эти годы тщательно складывал каждый новый класс в огромную таблицу статической загрузки классов. Терпение конечно впечатляющее у человека, но это сизифов труд.
И вот примерно в таком стиле был построен весь проект. Но опыт был интересным, конечно: как в кунсткамеру сходил - столько необычных решений и абсурда редко где встретишь.
А что вы хотите, когда так называемый "программист 1С" во франчайзи должен и часики подписывать у клиента и что-то там программировать? Франч при таком раскладе простой посредник который просто берет свой процент с объема продаж за бренд. Хотите нормальных разрабов - берите специалистов на оклад. Когда разработчик будет разрабатывать, а бизнес- нести бизнес-риски тогда можно будет что-то предьявлять Сереже. А так - Сережа молодец, остальные - удобные ишаки для владельцев франча.
Не всем нужен «программист на оклад» (и не у всех есть этот самый «оклад») — иногда вменяемый франч выгоднее (у него есть сотрудник практически всегда, а штатный — он в отпуск ходит, и все такое).
Автор забыл добавить, что часто в дополнение к такому Сережиному коду бонусом идет существенное удорожание установки обновлений 1С. А после обновления что-то из Сережиного кода перестает работать. Неудивительно что:
Серёжа перестал справляться с возрастающим потоком
Представьте, вот разработал какой-то Сережа десктопное приложение на C++, а оно почему-то ломает установку обновлений безопасности Windows.
Всё нормально - Серёжа пишет прототипы (PoC), а остальные должны превращать это в нормальный код. Причём сначала писать автотесты, а потом код так, чтобы он 100% проходил все тесты.
А код Серёжи не должен попадать в основной код хотя бы из-за басфактора.
А ещё, бизнес бизнесом, конечно. Дешевизна разработки и всё такое. Но потом работать после таких вот Серёжь - одна сплошная боль. И эту боль не всегда можно измерить в суммах зарплаты. Поэтому с говнокодом надо бороться. И с заказчиками, которые его заказывают - тоже. Надо голосовать ногами против этого. Да, говнокод выгоден заказчику в краткосрочной перспективе, но обычно те заказчики, которые экономят на качестве кода, потом экономят на его рефакторинге. И потом экономят на зарплатах для страдальцев, которые будут этот код поддерживать. Потому что экономия она такая штука - увлекательная.
Понятно, что есть одноразовые проекты, и их не нужно красиво писать. Но обычно то проблема возникает как раз тогда, когда МВП переходит на следующий этап жизненного цикла и никто не хочет тратить деньги на его переписывание, потому что "ну и так же всё работает".
И тут уже разработчик для себя решает, какие косвенные плюшки ему нужны кроме зарплаты: кофе с печеньками, ДМС или качественная кодовая база. И я вот считаю, что качественный код - это прям мощная плюшка. Это как любоваться закатом или жить в помойке. Есть разница.
То есть экономный подход - он вообще не в интересах нашей касты. Это на нас экономят в итоге. И ладно бы только на зарплатах. Так ведь ещё работа с говнокодом немыслимо нервная.
Возможно, Серёжа писал говнокод, а может и нет. Возможно, что остальные программисты писали правильный код, а может оказаться, что они тоже писали говнокод, просто по другому. Сомневаться приходится потому, что люди часто путают говнокод и то, что можно было бы назвать быстрокодом, и упускают из виду, что отборнейший говнокод как раз может быть очень тщательно спроектирован. Хорошим примером, в шутку доведённым до абсурда, является fizbuzz enterprise edition. Такие примеры, пусть и менее абсурдные встречаются в жизни довольно часто, и печально, что у многих складывается впечатление, что так и надо, и поэтому здесь "всё надо переписать", опять, потому что вот теперь всё точно будет масштабируемо без костылей.
Круто, fizbuzz enterprise edition это нечто, я знаю java и писал на ней год, но почти ничего не понял что там сделано, хотя задачу такую на собеседовании решал.
Клиент всегда прав. Почему миллионы леммингов могут выбирать слушать говномузыку или есть говноеду, а говнокод выбрать не могут? = )
Клиент всегда прав.
Открою тайну: не всегда. За подробностями - в гугл.
а говнокод выбрать не могут?
Да ради бога, пусть выбирают. Только пусть не хныкают "а почему постоянно вылазят ошибки, а куда пропал Сережа, а почему другие не могут/не хотят его заменить, слишком долго разбираются и предлагают всё переписать".
Этот пост на самом деле, о том что жизнь бывает сложной. И требует решения а не привлечения шаблонизированых практик,в каждом случае когда показалось что они нужны.
Волею судьбы я сам работаю в чем то похоже на Серёжу. У меня под крылом древний проект-проститутка в несколько десятков тысяч строк, к которому приложило руку много, очень много людей.
У меня тоже есть план, как все правильно сделать, и я даже делаю. Но есть нюанс. Я пробовал объединять свою работу с формализацией бизнесслогики в целостную форму и столкнулся с тем что некоторые процессы в компании МОГУТ меняться так быстро, что привлекать аналитика чтобы оформлять это - гораздо дольше чем новым изменениям требуется чтобы слегка устареть. И в таких случаях зовут меня и говорят: "надо чтобы....".
И это не какая то крайность, когда все забыли об обобщениях и тд. Это просто часть работы, ее небольшой кусочек. Другой ее кусочек оформляется иначе. Не по каким то там канонам, просто так нужно организму в котором я работаю.
И это и есть правильный путь. Имхо.
А вот и Сережа https://habr.com/ru/post/673350/
Пусть программирует Серёжа