Основа проекта выполняетя на говнокоде творческими ребятами — иначе будет слишком долго и никому не нужно. Тут работа на результат.
Далее, когда проект прошел все этапы становления — уже нанимают ремесленников, работа которых разгребать говно за первыми ребятами, у которых получилось.
Ремесленики, конечно, считают что они умнее, ведь первая категория ребят не способны так высококлассно писать. Однако эта умная категория годится только разгребать говно — что-то с нуля они сделать не смогут — это будет несовместимо с жизнью, несовместимо с бизнесом.
На мой взгляд описание слишком примитивное и подходит к небольшому числу проектов.
Про "с нуля не могут" это, конечно, глупость. В крупных компаниях постоянно делают проекты с нуля и у них есть ресурсы делать всё по феншую. Это описан только некий карикатуризированный стартап. Безусловно такое случается.
Вон касперские пишут свою операционку и скорей всего никто там никуда не торопится, нет цели за месяц её в продакшн выплюнуть. Думаю, там всё более-менее приемлемо.
По моему опыту говнокод возникает тогда, когда не хотят тратить время на удаление старого кода. Делают код по одним требованиям. Потом выясняется, что нужно другое или нужна фича, которая плохо ложится на текущую архитектуру. Здесь можно либо остановиться, заново продумать архитектуру, переписать что надо, и реализовать как положено, без говнокода. Либо можно попытаться натянуть на текущую архитектуру новые фичи как попало. Во втором случае получается говнокод. Частично это может нивелировать грамотный архитектор, который заранее предсказал эти изменения и внёс их в архитектуру, но если он не угадает, то опять же будет говноархитектура, что может быть даже хуже говнокода. Всё это может предотвратить грамотная аналитика, которая в принципе не допустит изменения требований, ну это в идеале.
Понятно, что не всегда говнокод это плохо. Разумные временные рамки никто не отменял. Иногда надо поступаться принципами. Это жизнь.
Ну и, конечно, главный источник говнокода это просто низкоквалифицированные программисты. Этим уже ничего не поможет кроме наработки опыта.
Есть два подхода:
1. Делать сразу, основательно и чтобы всё хорошо работало.
2. Делать быстро, что бы хоть как-то работало, потом допиливать, чтобы работало хорошо.
Re[3]: Хорошее объяснение природы возникновения говнокода
vsb>> главный источник говнокода это просто низкоквалифицированные программисты. Этим уже ничего не поможет кроме наработки опыта. ЭФ>Это менеджмент гавно. Иначе бы занимался развитием квалификации своих программистов.
Это ещё зачем, чтобы программисты рыночную зарплату могли требовать? ЭФ>Опыт должен собираться, систематизироваться, распространяться. ЭФ>Почему программисты этим занимаются в индивидуальном порядке, если они работают в организации?
Наберутся опыта и уйдут где платят. Нет уж.
Re: Хорошее объяснение природы возникновения говнокода
Я чаще видел другую картину. Сначала хитрые ребята делают из говна и палок кривой и косой прототип, быстренько отчитываются перед начальством что самое главное уже сделано, и ищут кому спихнуть все это счастье на "небольшую доработку".
Ад пуст, все бесы здесь.
Re: Хорошее объяснение природы возникновения говнокода
и да и нет
комрад в принципе все правильно описал и аргументировал. можно поспорить с отдельными тезисами. на вскидку: копи-паст легко заменяется вынесением логики в какой-нить ютилс класс с шаблонами. ну или юнит-тесты — я считаю обязательными
а во всем остальном — обычный итерационный подход отягчённый бизнес необходимостью
Re[2]: Хорошее объяснение природы возникновения говнокода
Здравствуйте, vsb, Вы писали:
vsb>На мой взгляд описание слишком примитивное и подходит к небольшому числу проектов.
естессна — жизнь она ооочень многообразна
vsb>Про "с нуля не могут" это, конечно, глупость. В крупных компаниях постоянно делают проекты с нуля и у них есть ресурсы делать всё по феншую. Это описан только некий карикатуризированный стартап. Безусловно такое случается.
да что только в жизни не случается
vsb>Вон касперские пишут свою операционку и скорей всего никто там никуда не торопится, нет цели за месяц её в продакшн выплюнуть. Думаю, там всё более-менее приемлемо.
вот именно — "нет цели". ребятам не надо бабло отбивать, их менеджерам не надо перед топами отчитываться. может даже попилинг
vsb>По моему опыту говнокод возникает тогда, когда не хотят тратить время на удаление старого кода. Делают код по одним требованиям. Потом выясняется, что нужно другое или нужна фича, которая плохо ложится на текущую архитектуру. Здесь можно либо остановиться, заново продумать архитектуру, переписать что надо, и реализовать как положено, без говнокода. Либо можно попытаться натянуть на текущую архитектуру новые фичи как попало. Во втором случае получается говнокод. Частично это может нивелировать грамотный архитектор, который заранее предсказал эти изменения и внёс их в архитектуру, но если он не угадает, то опять же будет говноархитектура, что может быть даже хуже говнокода. Всё это может предотвратить грамотная аналитика, которая в принципе не допустит изменения требований, ну это в идеале.
и такое тоже бывает
vsb>Понятно, что не всегда говнокод это плохо. Разумные временные рамки никто не отменял. Иногда надо поступаться принципами. Это жизнь.
+1
vsb>Ну и, конечно, главный источник говнокода это просто низкоквалифицированные программисты. Этим уже ничего не поможет кроме наработки опыта.
это да, потому и стараются нанять максимально квалифицированного на данный бюджет. ну а там как получится
Re[2]: Хорошее объяснение природы возникновения говнокода
Здравствуйте, vsb, Вы писали:
vsb>Видео не смотрел.
vsb>По моему опыту говнокод возникает тогда, когда не хотят тратить время на удаление старого кода.
Вот проект. Свеженький, с нуля. Но получили от тех, кто просто сдал свой кусок без комментариев, документации, истории (всё засунуто в наши репы одним коммитом и через год — ещё одним кумулятивным). Причины каждого решения непонятны.
И вот там что-то принципиально недоделано, например:
1. Ошибки отсутствия ресурса и невозможности получить его состояни объединены (знаменитое кагановское "Единая база повреждена или отсутствует").
2. Часть ошибок просто игнорируется.
3. Или вот анекдот. Доступ к некоторой подсистеме ведётся внутренними коннектами. Есть понятие "текущего каталога" его ресурсов, так вот каталог один на сервер доступа, а не на каждого клиента! Один сделал cd foo, другой рядом cd bar обламывается, потому что в /foo нет своего ./bar/.
4. Работа с железом имеет требования некоторого realtime но всё это делается через message queues специфического формата, и демоны, которые под общим шедулером безнадёжно тормозят.
5. Некоторый сервис падает. Его родитель неготов к этому и падает вслед за ним. Появляется зомби (уже не первый, кстати — общему родителю пофиг). Вместо добавки нескольких строк типа "moo_manager мог тоже упасть, давайте хоть в лог напишем" в ответ на тикет соседний отдел добавил, что на любой крэш (неважно, целевой процесс или нет) собирается набор данных (даже backtrace нет!) и бутается вся железяка (если на ней сидит шеллом админ в режиме диагностики — пофиг).
6. У некоторой функции "включить X" нет нужных параметров. Есть функция "подправить на ходу". Фича работает в ~90% случаев потому, что включение X проворачивается слишком медленно, чтобы "подправить" успевало. Но — не всегда.
Если точнее, "включить X" сбрасывает параметры в дефолтные, хотя это не документировано нигде. Поменять поведение — бюрократии на год с шансом на успех меньше половины.
Я бы наоборот рад увидеть "старый код" который надо удалить. Но тут всё свежайшее.
И да, некоторые априорные выводы относительно локации разработчиков справедливы не менее чем наполовину. Зато — сдали и довольны (наверно, кто-то даже рейз получил).
vsb>Понятно, что не всегда говнокод это плохо. Разумные временные рамки никто не отменял. Иногда надо поступаться принципами. Это жизнь.
vsb>Ну и, конечно, главный источник говнокода это просто низкоквалифицированные программисты. Этим уже ничего не поможет кроме наработки опыта.
Это тотальное отсутствие культуры.
Если культура есть — и в жёстком цейтноте будет сделано цивилизованно.
Если нет — никаких ресурсов не будет достаточно.
The God is real, unless declared integer.
Re: Хорошее объяснение природы возникновения говнокода
Оказалось что многие успешные проекты, код которых утек в публичный доступ, на самом дел вовсе не написаны в эстетском стиле а с применением говнокода, как некоторые бы сказали. Может поэтому они и успешные, что смогли найти баланс и успели выйти на рынок в нужное время с требуемой функциональностью. На ум приходит Эклипс (универсальная IDE на Javа), который был с самого начала спроектирован по уму со всеми патернами учоными мужами из университетов и компаний. В результате этот эклипс фондейшн таки исхитрился что-то произвести Visual Studio и Borland были практически везде на венде. Правда на Unix-as было немного альтернатив. Мало того, в то время Эклипс еле-еле шевелился и только сейчас производительность компов достигла того уровня, что он работает нормально без затыков и висюков. То потребовалось лет через 10 (или 20?) чтобы Эклипс развился и начал широко использоваться очень многими компаниями для создания своих IDE. Хотя по удобству работы ему до Visual Studio как до луны.
Re: Хорошее объяснение природы возникновения говнокода
А то у некоторых такой критерий: " я не понимаю почему здесь сделано именно так, ведь можно сделать вот так (как я считаю правильным) — значит говнокод".
Позвольте, но может быть ты не понимаешь этого потому что у тебя мозгов не хватает понять этого. Или может ты просто чего-то не знаешь, не знаешь причин почему сделано так, а если начнешь на свой вариант править, то какой-нибудь баг вылезет, о котором ты даже не подозреваешь
Re[2]: Хорошее объяснение природы возникновения говнокода
Здравствуйте, qqqqq, Вы писали:
q>На ум приходит Эклипс (универсальная IDE на Javа), который был с самого начала спроектирован по уму со всеми патернами учоными мужами из университетов и компаний.
Это другая крайность. Когда все слишком переусложняется, создаются абстракции над абстракциями для абстрацкий. Стоит ли удивляться, что и сама платформа работающая на абстрактном процессоре еле ворочалась под грудой этой абстрактной жути
Здравствуйте, Нomunculus, Вы писали:
Н>Отмаза. Обычно говно-код дает говно-результат.
Смотря какой результат тебе нужен. Быстрый и качественный код гораздо менее важен, чем доходы бизнеса здесь и сейчас. А завтра часть этих доходов можно пустить на разгребание говна.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[2]: Хорошее объяснение природы возникновения говнокода
Здравствуйте, Maniacal, Вы писали:
M>Есть два подхода: M>1. Делать сразу, основательно и чтобы всё хорошо работало. M>2. Делать быстро, что бы хоть как-то работало, потом допиливать, чтобы работало хорошо.
Что-то более менее сложное сразу основательно не напишешь, просто потому-что не знаешь как.
Поэтому сначала создаешь прототип, по сути занимаясь исследовательской работой,
выясняешь, какие сущности нужны, проводишь многократные рефакторинги, порой полностью переписывая.
Если на этапе прототипирования будешь заморачиваться стилем — никогда ничего не напишешь.
Re: Хорошее объяснение природы возникновения говнокода
Здравствуйте, Shmj, Вы писали:
S>Основа проекта выполняетя на говнокоде творческими ребятами — иначе будет слишком долго и никому не нужно. Тут работа на результат. S>Далее, когда проект прошел все этапы становления — уже нанимают ремесленников, работа которых разгребать говно за первыми ребятами, у которых получилось.
Спасибо за саммари, т.к. видео я смотреть, конечно, не буду.
По теме: да, есть такие стартапы, где MVP пишется на максимальной скорости и максимально быстро выходит на рынок. И уже затем ищется финансирование для развития продукта. Но — это далеко не все стартапы и помимо стартапов есть продуктовая разработка, есть инхаус разработка, где применяются совсем другие подходы.
Re[3]: Хорошее объяснение природы возникновения говнокода
Здравствуйте, rudzuk, Вы писали:
q>>На ум приходит Эклипс (универсальная IDE на Javа), который был с самого начала спроектирован по уму со всеми патернами учоными мужами из университетов и компаний.
R>Это другая крайность. Когда все слишком переусложняется, создаются абстракции над абстракциями для абстрацкий. Стоит ли удивляться, что и сама платформа работающая на абстрактном процессоре еле ворочалась под грудой этой абстрактной жути
Да и спроектировали как-то говёненько — у них нет понятия проекта, подсасывают тупо всё, что лежит в файловой системе. Нет бы дуракам понять, что у меня на базе одной кодовой базы пачка проектов собирается
Сейчас до сих пор нет внятных стандартов на написание кода. Думаю, это не скоро появится.
Например, один товарищ любит писать короткие функции, в одну-две строчки кода. Преимущество — такие функции обычно легко понять, легко тестировать, легко использовать и тд, но первое время вспотеешь прыгать по файлам что бы понять полную картину происходящего.
Другой любит писать функции размером в условный экран — преимущество в том, что лучше видна полная картина происходящего, больше пространства для оптимизаций, но хуже с тестированием и использованием.
Что делать, когда они оба считают подход друг друга говнокодом?
