Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Паша о г...коде

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

О веселый вброс на девбае от известного в узких кругах ограниченных людей Паши Веника о говнокоде.
Павел Вейник: «Все хотят писать красивый код. Откуда вокруг столько г...кода?» (dev.by/...​kuda-vokrug-stolko-g-koda)

А ты, программист, г...кодишь?
Или ты пишешь красивый код?

З.Ы. Да у меня очень часто возникало и возникает желание убить всех г...кодеров, впрочем и себя тоже, как представителя сего круга.

З.З.Ы. Надоел непрофильный треп, так может пусть лучше будет профильный.

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

Странно, что еще никто не запостил — goo.gl/NT2ZCR

пчёл тянет к цветам, мух — не особо.

В последнее время это стало так широко и модно я б даже прям сказал, рассказывать о том, что мол главное первым делом соблюсти потребности бизнеса, и что если всё как-то работает и коммерчески успешно и при этом реализовано быстро, значит всё хорошо.
Господа, а теперь сливаем чай из коньячных бокалов и тушим охотничьи колбаски. Наша непосредственная задача — это код, настолько же, насколько бизнес — задача клиента. Пример с сапожником из статьи не очень релевантен. Почему? Да потому что почти не бывает так, что один раз написали скрипт (программу, продукт и прочий софт), и всё, он больше не изменится. Ну положа руку на сердце, хоть у кого-то так было? Один случай из 100. Более того, завтра твой код отдадут другому человеку, и тут вдруг выяснится, что от тебя даже нельзя отнаследоваться (потому что все методы приватные), что у тебя всё захардкожено, что у тебя непонятные magic numbers, что ты параметры получаешь в массиве и даже не удосужился коммент какой-нибудь написать, что какой параметр означает. А твой код ему запретили менять, потому что он в продакшене и работает. И программисту, вместо того чтобы просто вызвать один метод (полчаса рабочего времени) придётся копировать кусок твоего кода в новый класс, разбираться как там всё работает и вносить правки в этой копии (4 часа времени). И что же, позвольте спросить, выгоднее для бизнеса? И сколько рабочих часов потратит третий программист, который сядет писать следующий кусок кода на основе этого?
Потом о нас рассказывают, что вот программисты такие-сякие, получают кучу денег и ничего не работает. Да потому что хороший код — это не ценность сама по себе, типа красиво внутри и коллега заценит. Это в первую очередь ещё и внутренняя отлаженность, наглядность процессов и поддерживаемость.
Помню, когда мне было лет 10, у нас была сенсорная лампа, которая сломалась, и мы отнесли её в ремонт. Какое-то время после ремонта она поработала, потом опять сдохла. Я разобрал её и нашёл там, что провода заизолированы... обёрткой от конфеты и ниткой.

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

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

Причём здесь вера? Я пишу что вижу, по опыту работы с хорошей командой и с плохой командой (или с их наследием).

Понимание «не говнокодить» должно быть у всех участников проекта. Если все понимают, что писать нужно не только, чтобы сейчас клиент был счастлив, а чтобы через пару лет проект не скатился в яму, то легче договориться о том как реализовывать данную идею. А именно, какой код считается плохо поддерживаемым, что можно делать, а чего нельзя. Из своего опыта могу привести пример соглашения о том, что весь код должен быть хорошо покрыт тестами. То есть, каждый кейс. Попробуй написать гавнокод и покрыть его хорошо тестами... Это будет тот еще динозавр. С такими мыслями проводилось расширение и модификация кода. В большинстве случаев, не было особых проблем в понимании кода коллег, так как все было на одинаковом хорошем уровне.

программисту пофиг — заплатят за 4 часа
я бы тебя уволил к черту

самий лучший код тей, який не написаний,
отже, чим менше коду тим більше перфекції

Говнокод — это «красивый код» написанный одни разработчиком, но не понятый другим....

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

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

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

а покажи мне код современности который будет соответствовать?

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

А точка зрения разработчика не монетезируется.

А я, как программист, стремлюсь писать красиво, но лишь тогда, когда красота не портит скорость. Если нужна фича и нужна завтра, то буду молиться Одину, чтобы дал потом время переписать по-человечески :)

А точка зрения разработчика не монетезируется.

Монетизируется на первом-втором нетривиальном баге.

Глупости они говнокодят с ходу безбажный говнокод прямо имея возможность пожертвовать красотой в пользу стабильности и надёжности говнокода.

Глупости они говнокодят с ходу безбажный говнокод

Я, конечно, завидую тому, кто работает напрямую с богами. Зачем только Вы спустились к нам на Землю?

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

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

Хм, такие я не рассматриваю всерьёз :) нужно же хотя бы внутреннему заказчику показать.

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

Внутренний заказчик вряд ли устроит тебе критичный баг, если до конечных клиентов продукт не добрался. ;-)

Да запросто. Ты ему показываеш — и в это время всё падает :)

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

Может. Но это, мне кажется, уже за пределами обсуждения.

У нас совершенно разная «обычность», я смотрю.

Да запросто. Ты ему показываешь — и в это время всё падает :)
Ну для такого чаще требуется не просто говнокод, а яркое рукожопство. Только в этом случае до нетривиальных багов дожить сложно :)
Но это, мне кажется, уже за пределами обсуждения.
Не совсем, если говорить про монетизацию.
система не успевает и до первого такого бага дожить
А делали её тогда зачем работу куда тратили где результат?

youtu.be/23fBoqQxSgQ

А делали её тогда зачем работу куда тратили где результат?
Делали по заказу клиента, результат в каком-нибудь гите болтается, готовый к деплойменту (или даже задеплоен на прод). А сам клиент прое^W решил за неделю до запуска выяснить требования законодательства и выяснил, что после запуска ему сразу в тюрьму идти :)

говнокод не имеет ничего общего к скорости написания! имеет отношение только к скиллу

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

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

У такого крутого чувака уже выработано понимание, как должно быть и стиль работы. Вряд ли ему будет легко перестроиться и писать плохо. Если не будет времени отрефакторить, чтобы сделать лучше, то он скорее будет страдать прокрастинацией из-за такой задачи.

нет, сделает максимально быстро чтобы отдать пекедж для деплоя, а потом сядет переписывать

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

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

ну программистом-то он может быть крутым
просто послушный
Так не бывает. Иначе бы из правок css никогда бы не вылез. Он же послушный, да?
сказали говнячь, он говнячит через слезы
Ну больше чем на месяц суперкрутых программистов не хватает обычно.
Так не бывает. Иначе бы из правок css никогда бы не вылез. Он же послушный, да?
Ну больше чем на месяц суперкрутых программистов не хватает обычно.
ты совсем не даешь мне шансов и сам себя опровергаешь

А что, всея бизнес уже заинтересован искать новых суперкрутых послушных программистов спустя месяц?

тем не менее практически всегда все происходит на условиях работодателя

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

лесом бомжевать
Let me fix this for you: стартапить.
В реальном стартапе требования бизнеса всего самые важные, а вот всё остальное на заднем плане.
Это среди взлетевших стартапов.

в Java 95% любого production-кода — говнокод (если оценивать по книгам Р.Мартина или С.Макконнелла). Ваша задача как разработчика — быстро вклиниться, добавить фичу \ починить баг и вынырнуть чтобы ничего не сломалось. Время на переписывание системы на лямды или рефакторинг на фабрики никто не даст. Поэтому для Java глупо жаловаться на говнокод.

Писать с нуля по-хипстерски еще хуже ИМХО.

Когда вы успеваете код писать? )) если пишете столько комментов.

За свою жизнь я пришел к выводу — работу надо работать. Пришел на работу — работаешь. Сделал таск, прошел тесты и ревью и норм. Ложное стремление к перфекционизму — убивает.

Работа работой, но нужно и что-то полезное в жизни делать

Работа работой, но нужно и что-то полезное в жизни делать

Например, детей.

Зачот ) я сейчас заплачу

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

пойду нахреначу логики в шаблон...

компьютер либо выполняет программу либо нет.
Самый цимес как раз в том что комьютер выполняет ровно то что ему написано а говнокод как раз и написан именно чисто технически конкретно так чтобы понять что именно выполнил выполняет и будет выполнять компьютер было максимально затруднительно весь «синтаксический сахарок говнокода» в чисто технически человеческом факторе.
точки и запятые
ненужный синтаксический сахар

Эх, молодой еще, глупый.

’Если вы будете следовать рекомендациям, то ваш код будет так сложен в поддержке, что у тех, кто придут после вас, даже простейшее изменение займет годы *оплачиваемого* труда! А сложные задачи оплачиваются хорошо, так что они, определённо, скажут вам «Спасибо».

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

...Впрочем, всему своя мера. При написании такого кода он не должен выглядеть сложным в поддержке, код должен быть таковым.

Явно кривой код может написать любой дурак. Это заметят, и вас уволят, а код будет переписан с нуля. Вы не можете такого допустить. Эти советы учитывают такую возможность. Да здравствует дзен.’

Полная версия, исповедь Буддиста.
learn.javascript.ru/write-unmain-code

С точки зрения профессии — Говнокод всегда в «глазах смотрящего». И он же показатель собственной эволюции. Смотришь на свой код годичной давности / джунов и видишь разный по качеству кал. А кал ли это ? Ой ли. Просто ты эволюционировал. Мне и сейчас мой код не нравится — хотя если посмотреть давние творения — это шедевр. Посмотрим что скажу о нем через год. Есть у меня подозрение ;) . А с точки зрения бизнеса — говнокода нет, иначе кто б платил за га..но. Если платят — значит норм.

А с точки зрения бизнеса — говнокода нет, иначе кто б платил за га..но. Если платят — значит норм.
а тебе за код платят или за проведенное над кодом время?

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

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

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

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

да, проблемы бывают разные. тема — о коде.
возможно ты достиг своего «потолка» — я нет.

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

Странный вопрос от профессионала ? Я вообще не знаю как можно жить в нашей профессии, если ничего нового не читать. Если реально интересно — одна конференция, пара книг с освоенными новыми техниками, видосов с практикой на курсере Х единиц. Короче — норм потрудился за год ) . Есть вещи, которые мне в моем коде не нравятся и сейчас — но как и писал выше — результат всех код ревью — супер. И я понимаю, что только сам смогу поправить это когда еще выросту.
Бывало у тебя такое, что в твоем окружении некому факать твой код или инженерные решения (если ты не пишешь код) ?
Мое мнение (выше) — в этом случае это не гов..код даже если через год я найду лучшее решение.

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

меня не волнует «большинство». меня волнует профессионализм, а он по-моему мнению не возможен без постоянного роста. На моей работе есть R&D инженер 75 лет, его мотив — человек живет пока узнает/делает что-то новое. И если уж он не достиг потолка до сих пор, то куда уж мне.
Достигну «потолка» если съем один язык ? При чем тут вообще язык. Кодируют мысли, процессы, алгоритмы, а язык тут может быть хоть жестов.
Не меняется. Ты цепляешься к словам, и не видишь за деревьями — леса. Мысль не изменилась.
В целом — или дай аргументы почему не согласен с тезисом, только будь-ласка без «общеизвестно» и «очевидно», или проходи мимо.

меня волнует профессионализм, а он по-моему мнению не возможен без постоянного роста
какое-то превратное понимание, профессионализм — это результат того роста
На моей работе есть R&D инженер 75 лет, его мотив — человек живет пока узнает/делает что-то новое. И если уж он не достиг потолка до сих пор, то куда уж мне.
такие за границей по 10 образований получают зачем-то
Достигну «потолка» если съем один язык ? При чем тут вообще язык. Кодируют мысли, процессы, алгоритмы, а язык тут может быть хоть жестов.
Не меняется. Ты цепляешься к словам, и не видишь за деревьями — леса. Мысль не изменилась.
в одном достигнешь, а если цель быть эникейщиком можно не запариваться, уметь много всего и ничего толком, много лет назад люди разделение труда придумали, и предполагалось что каждый будет крутым в чем-то одном, либо неквалифицированный труд, где намешано все подряд
В целом — или дай аргументы почему не согласен с тезисом, только будь-ласка без «общеизвестно» и «очевидно», или проходи мимо.
да как ты не понимаешь-то? ты говоришь что если тебя не макнут в твой код, а ты на данном этапе не знаешь как написать лучше, то он авотматически хороший и тут же добавляешь что через год обычно считаешь это говнокодом, это не из-за того что код хуже стал он не изменился, просто не было аудитора

похоже нащупали взаимопонимание )
«превратное» понимание профессионализма — оно у нас просто разное судя по всему. мое мнение — профессионал учиться всю жизнь. для меня профессионализм не результат — а процесс. у тебя вижу иначе. просто разные мнения — отсюда и непонимание в остальном. на конфе — той на которой был в этом году — видел архитекторов с 15-20 летним стажем в отрасли и все еще в процессе роста и поиска подходов, решений и .. это не дает моей позиции больше аргументов, чем твоей — просто мне такие люди больше подходят по стилю жизни — любопытные.
по 75 летнему инженеру — ты не угадал, хотя ты прав такие тоже бывают. этот в одной теме постоянно.и к его профессиональному мнению прислушиваются что в Европе, что в США. В твоих категориях это как раз тот самый, который копает в одном месте очень глубоко. правда он не пишет код давно ;)
«эникей» VS «узкий профиль» это холивар имхо. в чем-то я с тобой согласен, в чем-то нет. это также очень сильно зависит от личности и его жизненного пути. я понимаю твой психологический профиль ) как там у «нави» — I see you. ) I hope from our conversation you’ll see me.
No auditor. Не совсем так. Результат design review and code review from Switzerland — well done. Т.е. аудитор есть — просто он менее профессионален в предметной области чем я. Мое мнение — этого достаточно чтобы считать код нормальным — даже если через год он выглядит для меня шлаком.

В любом случае — спасибо за беседу. )

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

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

Щетаю ижнинир должен чувством ну и практическим опытом конечно же ж тоже различать «красоту» с технической целесообразностью и видеть в последней свою чисто техническую инжинирную красоту так выпьем же ж за кибернетиков! (к) (тм)

Занятная тема. Давай посмотрим о чём идёт речь. Если о pet проекте, который делаешь сам для себя, то там можно писать сколь угодно красивый код, руководствуясь только своими собственными представлениями о красоте.

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

Второй вопрос — сколько красивый код должен стоить. Другими словами, сколько времени уходит на то, чтобы рабочий код сделать ещё и красивым. У меня есть подозрение, что соотношение 20:80 будет и здесь — 80% времени тратится на оставшиеся 20% работы. То есть просто рабочий код стоит в пять раз дешевле, чем рабочий красивый код. Снова возвращаемся к оплате — готов ли заказчик отдать 80% денег за красоту кода, которую он не сможет ни увидеть, ни оценить.

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

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

То есть из четырёх названных пунктов три с половиной в поддержку г...кода, который, как ни странно, выгоден и заказчику, и разработчику и даже пользователям, которые смогут раньше получить работающий продукт. Но здесь, по-видимому, появляется ещё один пункт — интересы разработчика, которому, как и любому другому человеку, хочется делать хороший продукт, которым можно гордиться. Насколько сильно это желание и заставит ли оно пренебречь своими собственными интересами, я не знаю. Представьте, что на работу даётся достаточно времени. На то, чтобы написать рабочий код уходит n времени. На рабочий и красивый код 5n времени. Будете ли вы четыре часа из пяти заниматься улучшением кода, или займёте их чем-то более интересным и полезным для вас лично.
UPD Совсем забыла. Правило 20:80 не только времени, но и квалификации касается. Г...код напишет каждый, называющий себя программистом, а хороший, красивый, грамотный, структурированный, расширяемый, только квалифицированный специалист. То есть почасовая ставка за красивый код должна быть существенно выше — человеку нужно компенсировать время, которое он учился, вместо того, чтобы зарабатывать. Если заказчик платит ставку среднюю по рынку, то и код будет средним по рынку.

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

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

Оправдания типа — не мне потом поддерживать, работает и хорошо, мне не платят за рефакторинг — это нежелание развиваться. Это уже личное дело каждого )

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

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

Ну вот ты и сам ответил на вопрос говно/не говно код. Сначала говнокодим, а потом, если взлетело — переписываем по фен-шую. Просто такой подход.

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

значит, такие заказы.

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

ЗЫ: на худой конец попробуй оценить стоимость построения и поддержания инфраструктуры в которой «обновление на смартфон гарантия .9999» и оценить стоимость отдельного экземляра в серийной же ж производстве а может такое производство уже будет и как бы не совсем серийным?

я с тобой в принципе согласен, только реалии — это уже совсем другой разговор и к оценке кода не имеет никакого отношения :)

никогда прошивки не писал, поэтому не могу высказать своё авторитетное мнение ;)

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

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

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

Спасибо, а это идея, надо будет себя модулями поогораживать попробовать :)

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

А за деньги, все просто, пишешь максимально качество из учета времени данного на задачу. Чем лучше пишешь, тем дороже стоишь.. (возможно я слишком наивен)

Спасибо. Такой диалог приятно читать. )
Работал как-то в конторе, которая «перемалывала» джунов. Поначалу вообще не понял, как они выживали на рынке при таком «аде» в коде. А итог — модульность и тесты интерфейсов модулей. Лиды вообще в модуль не смотрели, пока багофиксы от тестов джун делал сам. Глядели лишь когда джун реально тонул в своем аду (не справлялся с фиксом своего же кода). Тогда говорили переписать. Но этот случай был намного реже — жопорукого кода, который однако же — выполнял задачу.
Так что да, для больших программ построенных джунами — Модульность конструкции + Тестирование интерфейса = Решение задачи.

Представьте, что на работу даётся достаточно времени. На то, чтобы написать рабочий код уходит n времени. На рабочий и красивый код 5n времени.
Если заказчик платит по времени и не подгоняет — почему не написать хороший код
Это какой?
Хорошо расширяемый и поддерживаемый, понятный. На момент написания конечно, через несколько месяцев может оказаться что получился не настолько уж и хорошо. И конечно в голове человека, писавшего.
Тут раньше я вбросил пример с кодом. Он какой?
Не знаю. Во-первых, я не понимаю синтаксиса «с ходу» (видимо это С++, я его никогда не изучал). Во-вторых, я бы не оценивал отдельные строчки кода в большинстве случаев. Ну есть у тебя например какая-то функция, что-то она делает. А удобно её использовать? Не много ли параметров или не мало ли, достаточно она универсальна или слишком универсальна, сложно или нет обработать ошибки. Это мне кажется важным. Отформатировано плохо, это да (но думаю это при публикации сюда сломалось).
Это какой?

который:
1. более-менее понятен другим
2. не ломается в других местах, когда изменяешь в одном
3. кусок которого можно легко выкусить и перенести в другой проект без извращений
4. в котором нет похожих кусков и, при внесении изменений, не нужно метаться по всему коду в поиске этих кусков, чтобы в каждый из них можно было внести.
5. модульность. При необходимости достаточно подсунуть новый модуль (идея которого возможно была даже абсурдной на момент написания основного кода), а не ковырять основной код.

думаю, ещё что-то забыл ;)

Ниже я специально пример положил. Без комментария он мало кому понятен сходу.

я к С++ последний раз прикасался 15 лет назад и напрочь его не помню, поэтому ничего про твой код сказать не могу

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

используй абстракции

Надо значит объединять абстракции. Хотя да, на практике часто именно это нормально и не получается :)

Потому что хороший код требует времени, а время — единственный невосполнимый и невосстановимый ресурс на планете. Является ли красота кода той целью, за которую нужно платить дополнительным временем?
Для простоты картины можно отбросить заказчика, команду, деньги. Остаётесь только вы и программа, которую пишете, но не для своего удовольствия, а чтобы она работала и приносила доход. Если за одно и то же время можно написать пять плохих с точки зрения используемого кода программ, или одну с идеальным кодом, что выберете? Помним, что пользователю до качества кода дела нет, и среди программ с отличным кодом масса аутсайдеров, точно так же как чуть ли не все известные и популярные проекты делались наспех и кое-как.
Или ещё вариант: написать одну программу с плохим кодом, а оставшееся время посвятить тому, чтобы что-то выучить, и в будущем иметь возможность писать код не только быстрее, но и качественнее.
P.S. На хабре видела топик. Названия не помню, имена главных героев (вымышленные персонажи) тоже не помню. Назовём их Виктором и Петром. Пётр пишет хороший код, проверяет, отлаживает, тестирует, доводит до совершенства. У Виктора код плохой кривой и страшный. Но продукт работает (да, с багами, глюками и проблемами) и, как ни странно, нравится пользователю. В итоге, пока Пётр собрался выпускать свою отлаженную программу, оказалось, что программа Виктора уже полтора года на рынке, известна, популярна, пережила несколько обновлений, а новый продукт с аналогичным функционалом пользователю малоинтересен. Заканчивается история тем, что Виктор берёт Петра в свою команду, а сам наслаждается заслуженным успехом. Зато у Петра был хороший код.

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

Является ли красота кода той целью, за которую нужно платить дополнительным временем?
а если время не твое, а заказчика?

Думаю, правильным будет такой ответ: качественный красивый код очень ценный и дорогой продукт и создавать его нужно только если есть прямой заказ или прямая выгода, вроде экономии своего собственного времени в будущем. Заказчику можно объяснить разницу в цене и времени, пусть выбирает что ему ближе. Вполне вероятно, что с учётом стоимости и скорости, такой вариант его вполне устроит: cs4.pikabu.ru/...1/1446405535_92965515.jpg

Дешевле правильное слово. 9 из 10 заказчиков будут искать дешёвый вариант. И ещё быстрый и качественный. А когда поймут, что это утопия, 99 из 100 выберут дёшево и быстро. Как-то так.
Так что о хорошем коде можно мечтать сколько угодно, но делать придётся то, за что платят, а не что хочется.
Возможно, есть проекты, где качество кода ставится на первое место. Ну так их ещё найти нужно. Да и требования у них скорей всего высокие не только к коду, но и к программистам тоже.

а как заказчики оценивают качество кода?

Дают на анализ.
А вообще большинство заказчиков не понимает, насколько это важно и потом расхлёбывают по полной

Заказчики? Думаю, что никак. Я выше об этом писала: «...готов ли заказчик отдать 80% денег за красоту кода, которую он не сможет ни увидеть, ни оценить». Когда говорила о проектах, которые за качеством кода следят, имела в виду компании, где тестирование качества кода является нормой, а разработчику не нужно решать дилемму: делать хорошо и получать меньше, или делать плохо, но при этом выигрывать в оплате.

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

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

делать хорошо и получать меньше
Делать хорошо и получать хорошо (предватительно заэстимейтив так чтобы было хорошо)
Делать хорошо и получать хорошо
Это был бы идеальный вариант. Не всем везёт. Украина с её ста тысячами программистов занимает первое место по аутсорсингу в Европе. Судя по комментариям и постам на форуме, не всегда на аутсорсинг передаются проекты, которые нужно делать хорошо или хотя бы писать с нуля. В фрилансе заказчик, который готов платить за качество, тоже вряд ли часто встречается. Получается, что немногие компании действительно заинтересованны в качестве кода. Но они и программистов приглашают минимум с высшим образованием, а большинство на форуме считает, что вузы не нужны, а меньшинство, что школы не нужны тоже.
заэстимейтив
Google в растерянности :)
Ага, догадалась кажется: estimate — рассчитывать, оценивать. В смысле, заложив в смету качественный код? А школьник Вася предложит код дешёвый. И ваш заказчик уйдёт от вас к Васе.
Украина с её ста тысячами программистов занимает первое место по аутсорсингу в Европе.

Откуда дровишки?

И ваш заказчик уйдёт от вас к Васе.
Ну потом они обычно в слезах возвращаются.

Справедливость торжествует ) Вот и славно.

Хороший пост о качестве кода. И даже с картинками. Если есть время, можно почитать: habrahabr.ru/post/163849 Кстати, обсуждение тоже занятное.

Не всем везёт.
Да, это так.
В фрилансе заказчик, который готов платить за качество, тоже вряд ли часто встречается.
Зато часто встречаются объявления, когда на разработку SPA ищут js-гуру, который знает quirks & workarounds (хз что под этим имеют в виду, если честно), к этому конечно же HTML5, CSS3 и особенности браузеров (опять-таки, хз кто может знать все особенности, там их просто море), знания node.js будут плюсом. В общем-то читая объявление можно поверить что им правда нужно качество. Но при этом в истории заказчика максимальный рейт 20$/час (это значит чистый рейт разработчика 16 — 18 в час) для разработчика приложения (непонятно кстати что с предыдущими стало и почему ищут нового), а для всей остальной черни вообще 10. И я не очень-то понимаю, как такие специалисты, которых они описывают, могут быть согласны работать за такие деньги.
В смысле, заложив в смету качественный код? А школьник Вася предложит код дешёвый. И ваш заказчик уйдёт от вас к Васе.
Ну это если на фрилансе. А если на фирме, то не уйдет. Хотя конечно может упереться рогом и сказать что это много.

NCover очень помогает, если предварительно было оговорено размер покрытия. Cyclomatic complexity хотя бы тот же легко проверить.

Тому, кто будет заниматься поддержкой кода. Разве это не очевидно?

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

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

Только что мой комментарий в этой теме удалили. Печаль. Стремление модераторов избавиться от всего, что они считают нарушением, понятно, но я бы, конечно, оставила Комментарии никого не обижали и не задевали ничьи чувства, зато позволяли увидеть, что анонимность в интернете вовсе не означает невидимость или неузнаваемость hkar.ru/Mk3V

Для форума, который анонимов считает людьми второго сорта, это было бы крайне полезно.
Кстати, как вы относитесь к дискриминации?

Твой поток сознания приятно читать. У тебя какой-то особенный, интересный стиль письма)

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

Всегда найдется тот, кто с отвращением, двумя пальцами попытается приподнять капот твоей жаркой программы, и тут же с ужасом захлопнет.
Всегда найдется что-то не то, и что-то не так. В конце-концов, можно и к египетским скобкам и «tab или три пробела» дое. еще при беглом осмотре.
Всегда будет «вот тут зачем вот так? Можно же было вот эдак, Я так всегда делаю и Это правильно».
Всегда будет в простом лаконичном коде «а чо тут так примитивненько? Где абстрактные фабрики абстрактных фабрик?», при шаблонизированом «Э, ты что, самый умный? Как этот клубок абстракций вообще распутать?»
Всегда кому-то не угодить, и Страупструппский код покажется кому-то термоядерным овер-инженерингом, ведь можно было те же вещи написать проще, и «красивее».
Всегда мы будем чем-то недовольны в чужой работе, ведь раньше-то:
— ’member when 640kb was enough for everybody?
— Oooh, I ’member!

Вот это в плюсах ненавижу. Так по крайней мере четко видно, чья это функция.

using std::vector
using std::pair
using std::transform

Криво, но каша из std:: перед каждым вторым словом убивает читаемость.
Плюсам не помешало бы питоновское from namespace import name, name, name.

Так нет ведь) Просто о чем топик?

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