Стартапы и говнокод
Многие считают, что в стартапах программисты пишут плохой код, так называемый "говнокод". Как оказалось, по этой причине могут отказать в работе. Но так ли это?
НЕТ ВОЙНЕ!
Выразить благодарность
ko-fi.com/larchanka
boosty.to/larchanka
yoomoney.ru/to/410011886858328
BTC: 127J5x79L9bb7T4jiYJ2U7jHNDLXEx4kT3
USDT (TRC20): TWRQit8o1JJGWjAph3DZFysygUxSwqiq9Q
TON: UQBDiFGDTLpp1zWLefv0LnH9TbEeUIcPSoO5uDNwhzktKP33
Как я стал программистом
• КАК Я СТАЛ ПРОГРАММИСТОМ
Как я переехал в Европу
• Как я переехал в Европу
Стрим: Карьера программиста
• Карьера программиста: ...
VPN, который я использую
get.surfshark.net/SH1Wy
➡️ Сайт: i.mobila.name/xT
➡️ Instagram: i.mobila.name/yp
➡️ Twitter: i.mobila.name/Ua
➡️ Telegram: i.mobila.name/b7d
👉🏻 Больше влогов здесь:
#larchankavlog #larchanka
👉🏻 Ежедневные влоги:
#larchankadaily
👉🏻 Чем я снимаю:
➡️ iPhone 14 Pro
➡️ Еще одна камера: DJi Osmo Action
➡️ Еще одна камера: Sony DSC-WX500
Музыка:
Rich People Dreaming - Siine
Drag Me Down - Conditional
Мне кажется, если код легко читать, то это уже не говнокод.
не всегда, он может быть легко читаем, но опасен иметь утечки иметь решение в лоб, которое абсолютно никак не мастабируется иметь решение которое может ломать другие части и тд и тп
Ловко подмечено! Мне данный ролик вообще показался невнятным, потому что само определение говнокода тут не дано. Если код работает, выполняет свои функции, легко читается, зарабатывает бабло и не парит никому мозги, то это уже не говнокод. Хотя может и быть написан "не по красоте", не масштабируемый, не абстрактный, не ооп, не проходит проверки линтерами - но всё это неважно, всё это синтетика, о которой переживают только те программисты, которые не в состоянии понять, что они работают на бизнес, и должны эффективно решать задачи бизнеса, а не страдать графоманством.
нет никакого определения, то что-то одному конфетка другому жуть. имхо бизнесу код со скрытыми изъянами также не нужен, а вот будет он плохо читаться или нет бизнесу все равно. поэтому часто пишу большие функции без переносов после каждого действия, главное чтобы они помещались на экране (это куда важнее для понимания чем все best practices) и имели тесты. а вот архитектура *выше* этих макаронных функций должна быть красивой, а не обратным перегибом в Равиоли\Лазанья\Пица код... имхо тогда будет и скорость поддержки и масштабируемый и скрытых багов не будет.
@@xyzw777 как владелец бизнеса могу сказать, что не согласен ни с чем из сказанного вами. Мне важно чтобы код читался. Я и сам его читаю по необходимости. В экстренной ситуацит могу и правки внести. Людей, которые пытаются всё на одну страничку уместить, увольняю сразу - пусть идут в школе доучиваются. А скрытые дефекты в коде меня вообще не пугают, пока они проблем в бизнесе не создают. А если вдруг дефекты вылазеют и начинают портить бизнес, то мы их по факту правим. Оперативно. Если оперативно вы в вашем коде не можете отлажить и поправить внезапный баг, значит это говнокод. И он приносит убытки мне и увольнение вам. Вот и критерий говнокода сформулирован - пользуйтесь на здоровье!
Я пишу код в два-три этапа. - Говнокод, но работающий. - Первое причесывание - лучший нейминг, декомпозиция длинных функций, выделение классов, если они прям на поверхности и просятся. Если время поджимает, то это в принципе уже можно отправлять на ревью. А если есть запас по времени, то тут уже третьим этапом можно посидеть и почесать репу над тем, надо ли добавить какую абстракцию или переделать существующие. В стартапах же часто могут ограничиться первым этапом. Эт не говоря о том, что местами еще и ревью может не быть, ибо оно тратит время, а надо еще вчера.
раньше тоже так делал, последние годы, сначала проектирую сущности, потом разработка, если в файле появляется более 50 строк кода, то опять проектирование, рефакторинг и т.д.
Есть такой антипаттерн, который называется преждевременной оптимизацией. Это когда начинают всё бешенно оптимизировать ещё до того, как оно вообще хоть как-то работает. Часто это одна из, хотя и не единственная причина говнокода. В больших компаниях аналогом этого является заумное проектирование на уровне разного рода предварительной документации, такой как Solution Concept, HLD, TRD. При этом люди, которые это пишу и тем более всякого рода руководство (group leader, scrum master) никогда не пробуют написать несколько POC проектов, сравнить их работу с реальными данными или юскейсами. Никого не волнует потраченное время, переделывание service-foo в service-foo-v2, а затем v2.5, v3 и так далее. Главное вовремя закрывать таски в Jira и получать хорошие отзыва на ежегодных performance review ради бонусов. Так работают большие компании. Много бюрократии, мало эффективности. Спасает лишь наличие больших бабок за счёт других, обычно очень старых, проектов.
не согласен: 1) что надо выделять классы всегда ибо получится Равиоли\Лазанья\Пица код 2) что преждевременная оптимизация зло, наоборот оптимальную архитектуру нужно закладывать сразу ибо потом уже не сможете 3) что говно код вообще нужно править, если он корректно работает в отдельной функции, проходя все тесты то 99% вы к нему не вернетесь и это правильно, красота она для архитектуры а не для ее темных закутков (которые всегда будут т.к. оптимизированный код не красив)
@@xyzw777 Про оптимальную архитектуру вы мне напомнили рассказ про одного израильского прапорщика, который услышав сколько времени нужно для разработки, тестирования и отладки какого-то армейского софта сказал: пишите без ошибок. Оптимальной архитектуры сразу не бывает. Ну если только вы не пишите очередной велосипед, который написали до этого в других компаниях уже несколько раз под аналогичные задачи.
Google пишет некачественный код. Вижу это по постоянно ломающимся, то здесь то там, функционалам. Например сейчас у них в поисковике периодически пропадает кнопка в виде шестирёнки для входя в дополнительные опции поиска. Раньше они ломали другие вещи и потом очень долго их чинили. Ну а Facebook - это вообще один сплошной глюкодром. При этом попасть программистом в эти компании довольно трудно, по крайней мере гораздо труднее, чем в обычные компании. Выходит, что заумствие рождает глупость, то есть говно реализацию. То есть внешне код вероятно красивый, но откровенно глючный.
у них ютуб сломан, вижу баги постоянно
В случае Гугла пропадание чего-то может оказаться A/B-тестированием, они часто так издеваются над пользователями.
@@sawpaaduegulusf Менее всего это похоже на A/B-тестирование, потому что при таком тестировании сравнивают две полноценные версии, а тут мы имеем заведомо явную потерю функциональности. Более того, в Гугле об этом знают и я видел сообщение от них с обещанием скоро починить, но с тех пор прошёл почти месяц, а шестирёнка периодически пропадает, не оставляя никакой альтернативы, кроме специальной ссылки, котору нужно открыть в отдельном табе, перенести туда свой запрос и уже там играться с дополнительными параметрами, которые иначе временно недоступны. Раньше у них был баг, приводящий к потере запроса при переходе между разными видами поиска, например из обычного в новости или в дискуссионные группы. Тогда это чинили около года.
это неизбежно, когда программы очень большие, над ними работает много человек.
Добавлю ещё 2 копейки. Мне приходилось работать в компаниях разного размера, от стартапов до таких как F5. Как инсайдер ответственно заявляю: говнокод есть везде. А ещё есть говноменеджмент с кучей ненужных совещаний, бездумным тестированием и сканированием, ужасными архитектурными решениями и внутренними интригами или, как это тут называют, политиками. Для себя я пришёл к выводу, что работать в больших корпорациях не стоит. Конечно, если выбора совсем нет, то можно и там, но лучше в конторе не более 200 человек или в стартапе начиная с 20 - 30 человек.
Если красивый код читается хуже чем говнокод, то есть вероятность что их метами перепутали
Автор почему-то решил, что красивый код обязан быть изощрённо сложным и неочевидно читаемым. 🙄
@@user-ub3hd4sy4e автор встал на место человека который отказал человеку в работе, потому что он работал в стартапе и с его точки зрения попробовал порассуждать что такое говнокод и что такое красивый код. мне кажется как то так.
красивый-чистый-спагетти-говно код... да это все субъективщина, люди не знаю что эти термины значат, каждый вкладывает свое, при чем то что для одного хорошо у другого вызовет подгорание и войну правок
@@xyzw777 вроде да, но и не совсем, я полагаю что у каждого решения и архитектуры есть метрики, по которым их и выбирают, и вкусовщиной могут быть разные приоритеты, но сами метрики, особо вкусовщиной не назвать
@@jonkarmok1840 например длина кода и его скорость, но мы не машины и читать "идеальный" (по этим метрикам) js c обфускацией вряд ли вам захочется, скорее субъективно он воспримется как говнокод... а метрики красоты субъективны
Про то, что стартапы принимают хороших разработчиков, улыбнуло. Он на то и стартап, что денег в обрез. К нам в наш стартап прошлый год зазывали таких. Приходили. Но ценник, который они называли, у директора сразу глаза на лоб лезли.))) В итоге приняли студента в помощь, но толку от него как оказалось мало)))
где это видано чтобы задешево не могли сделать то
Работал с стартапе, тех директор бы заморочен на качестве, все по DDD, без тестов код не принимался и т.д. У нас не было возмонжности взять в штат много тестировщиков, приходилось сразу делать хорошо. P.S. работал с коллегой, он писал классный код, но ни черта не понтый: вместо двух foreach у него был reduce от map от filter, а данные брались не из массива, а из генератора.
Я люблю использовать вложенные array_map('array_map', ...
Шо в итоге, стартап заработал или заглох с таким подходом?
@@maestro256 Лет 5 проработал, проблема была в экономике, а не в IT
4:35 вспомнил код quake, где в функции для нахождения корня используются побитовые операции, и кто то это увидел и оставил комментарий по типу "что это за фигня"
Нужны критерии говнокода. Иначе говнокодом можно назвать всё что угодно. При этом самое забавное, что качество кода ≠ качество продукта.
Качество кода это его читабельность и хорошая структурированность. Первое влияет на время необходимое программисту чтоб понято что и как тут происходит. А второе влияет на объем правок необходимых для расширения или изменения функционала. Если у вас спагеттикод где напихано скажем в компонент расчета зарплаты функционал формирования и отправки имейла о зп и еще бог весть что, то разобраться и внести изменения которые не поломают другой функционал будет все сложнее. Проблема будет нарастать как ком. Таким образом со временем будет наблюдаться рост затрат человекочасов (денег) и падение объема получаемого результата (обновление фич, добавление фич) и при этом скорее всего будет увеличиваться число багов. Потому позволю себе не согласиться: качество кода = качество продукта.
@@AntowaKartowa качество продукта обеспечивают тесты, которые контролируют, что продукт работает в соответствии с заданными требованиями
@@maestro256 качество кода и качество продукта это не совсем одно и то же. Вы можете написать спагеттикод весь функционал в одном файле. Результат может работать идеально и проходить все тесты, но качество кода при этом будет ужасающим. И я бы использовал слово не обеспечивают, а проверяют. А вот, что они обеспечивают так это уверенность, спокойствие и скорость проведения рефакторинга. И при правильной организации тесты выступают своего рода "документацией" тех. требований к компоненту, который они покрывают.
Ну и если даже в стартапе был говнокод, это не значит, что человек не может писать по-другому. Иногда действительно нужно чтобы просто работало здесь и сейчас, а красиво когда время появится.
проблема в том, что времени не будет
О, мне тоже приходилось исправлять баги два года назад в репозитории Mytonctrl, как знакомо))
Согласен с Вами, Миша.
На прошлой работе у нас была культура код ревью, но главная задача была - имплементация фичей, но каждый последний спринт на квартал был клинап спринт (спринт для рефакторинга). Ну и про то что такое хороший код - для меня это код который сохраняет баланс между производительностью и читаемостью/поддержкой.
Если бы можно было, то поставил 100 лайков. 👍👍👍👍👍👍👍👍 Полностью согласен про маленькие функции и абстракции.
Большое количество абстракций - это скорее плохой код Абстрактные функции могут стать узким горлышком, их к тому же сложнее поддерживать, так как они задевают очень много зависимостей
По личному опыту, качество кода очень редко зависит от уровня разработчика, а чаще от объема работы и дедлайнов, а если уж и проводить корреляцию между опытом и количеством говнокода, то она будет прямая, потому что менее опытным разрабам обычно дают более простые задачи и время с запасом, а более опытным - сложные и с дедлайнами
Недавно наткнулся на программы с 90-х под dos и win95-98 они крохотные по сравнению с нынешними, а количество функций порой удивляет (к примеру аська на джаве). И как итог сейчас есть программы для вывода пары слов на экран тяжелее игр из прошлого... у которых если сделать скриншот, то будет весить больше самой игры. Как идея автору канала, осветить тему: почему они так распухли? Не уж-то программисты разленились оптимизировать код? Может это сговор программистов и производителей процессорной техники? Сколько будет весить программа на Ассемблере?🙃
Давай, давай контент в кайф! Надо писать не супер-мега-ультра код, который, а код который требует бизнес с его возможностью и временем. А кст каркассон на заднем фоне топ)
еще у всех понятие "говнокод" свое)) и часто оно очень широкое
к вопросу о том, что «тот кто пишет говнокод - не скажет что он пишет говнокод» видимо я исключение и понимаю что сейчас я пишу говнокод, потому что надо было сделать вчера, а тз пришло - сегодня
да, я тоже пишу говнокод. ) но я стремлюсь чтобы мой говнокод был максимально простым и понятным :)
Я агент 007: 0 паттернов 0 адекватного нейминга 7 признаков говнокода в каждом модуле
В бизнесе\стартапе (на ранних этапах проекта) часто случаются спешка\условия неопределенности\быстро реализовать и показать фичу\срочно исправить баг\сделать рабочую демку\ и т.д. В таких случаях лучше сделать на 3ку, но чтобы работало и успеть вовремя. А потом в спокойной обстановке все по фэншую отрефакторить. Разработчики-перфекционисты в таких ситуациях - это ад.
Быстро реализовать одно, быстро реализовать другое, а возвращаться и что-то переделывать уже ни сил, ни времени нет. Проходят года и разработчику приходит гениальная мысль: найти новую работу.
❤
💖💖💖❤❤❤
100%
Снова напрашивается вывод, что в резюме нужно писать то что нужно работодателю, а не факты. И попасть в цикл жалоб, что разрабы обманывают потому что не трудоустраиваются.
Смотрел видео про говнокод. Оказывается, говнокод - это такой код, который ты не сразу понимаешь. Соответственно хороший код - такой, который тебе понятен. Так что сама идея говонокода это субъективщина и боязнь RTFMa. Я в своем проекте не стесняюсь щедро вставлять комменты, и не ставлю читаемость во главу угла. И еще у меня такой проект, что читаемость там с трудом можно пропихнуть. Ситуёвина такая.
Говнокод - это и есть то, что не возможно прочитать, вроде так всегда и было.
Я считаю если код работает, это хороший код
Ну и плохо. Хороший код - это тот, который легко понятен другим программистам. А работать обязан любой код.
вообще абстракция это инструмент и если он используется не по назначению или 'на будущее' это тоже говнокод
Имхо: Написать легко используемый/читаемый/изменяемый код - сложная задача. А что еще можно подразумевать под понятием красивого кода - хз.
Есть ещё другой прикол: вот я работаю в лютом Enterprise, в одном из топовых банков, и блин, качество кода меня прям весьма расстраивает. И вопрос не спешки, а в том что например есть очень давние сотрудники, которые работают в компании по 15 лет, которые не следят за последними трендами, которые не понимают почему в JS сейчас не используют var или шаблонные литералы. Также есть проблема с тем что порой Recode занимаются просто коллеги не вникаю щие в суть того что сделано, и вообще с другой технологии.
И оправданий для качества кода может быть много но суть это не меняет вчера качество кода удручающее, и мне было бы страшновато брать на работу коллегу много лет проработавшего в той же компании где и я
Ну что-то у меня во многом не совпадает мировозрение. Хотя в тех двух стартапах в которых я успел поработать и правда к своему удивлению я не встретил того что мог бы назвать красивым понятным структурированным кодом. С другой стороны в аутсорс проектах гигантский компаний с мировым именем я встречал удивительно неоптимальные, крайне странные куски кода, а так же мертвый код. Но все же легко пишущийся это вообще не легко читающийся. Может если ты начинаешь писать компонент то в начале эти два понятия как-то могут сосуществовать. Но подход легкого написания без структурирования, выделения отдельных абстракций часто ведет к связанности кода, когда ты даже если не хочешь вынужден добавлять в компонент функционал, который к нему не должен относится. И чем дальше тем менее он понятный и читаемый, сложнее понять как все взаимосвязано и для того чтоб переписать его понадобится уйма когнитивных усилий и времени. Его и читать сложно и понимать и самое главное поддерживать (менять, расширять). Ведь стартап это про поиск идеи бизнес модели (слак появился из проекта создания игры). Стартап предполагает очень динамичное изменение и появление новых идей, концепции, фич. Конечно такая динамика и темп предполагают некоторую свободу и отсутствие очень строгих рамок, но не говнокод, не "что вижу, то пою".
я как раз залетал в интересные, но, к сожалению, не очень успешные стартапы, хотя я самоучка, не еще закончивший школу, с видео я по пунктам не согласен. Только сегодня слушал Женю Давыдова на подкасте EL.together, который на своем нехилом опыте вещает более оптимистичные вещи для джуниоров и миддлов
Думаю, хороший код прост в понимании, элегантен, в него очень легко и быстро можно вносить изменения. Да и если в нем есть абстракции, то это ж не плохо, ведь цель абстракций тоже упростить понимание и увеличить простоту внесения изменений. А если это какие-то говноабстракции, то и создают они говнохороший код. Хороший код легко читается и легко масштабируется. Все остальное это уже говнокод, который мнит себя хорошим кодом. :)
пацаны если это так, то почему в продуктах столько гавнокода?
звук - видео +
Проблема говнокода, скорее, не в самом говнокоде, а в том, что люди будто бы не допускают мысли о том, что их решение будет читать (встраивать, интерпретировать в своей голове, поддерживать) другой человек. Какая-то форма аутизма накрыла ИТ или набежали люди, провалившие тест Салли-Энн. А может, это и просто примета нашего времени, в любой сфере.
Давайте для начала определимся что есть говнокод?) Код, который не работает, или плохо читается?) Ну о чем мы тут рассуждаем)))) Ставят задачу, ставят ценник. Требование: надо быстро, чтоб работало) Ну так получите и распишитесь))) Работает? Да) Ну и досвидос)
Говнокод это когда 99.8% процессорного времени уходит на интерпретацию кода. Мы пришли к тому, что вычислительные ресурсы нерационально используются.
без чёткого определения всё это путой разговор. что такое говнокод? позабавила фраза "говнокод, но легко читается". Ну так а почему это тогда говнокод то? Читаемость и легкоизменяемость вроде как самые главные признаки как раз таки хорошего кода.
Красивый код это для Эстетов,а говнокод для истинных гуманнов😊
Говнокод это не только код без абстракций а еще кривой нейминг, форматирование, неправильная декомпозиция. Код оформленный в этом плане не как говнокод читать проще. Сложно читать именно код с большим количеством абстракций. Можно и говнокодом делать оверинжениринг с абстракциями (но сложно, т.к. чтобы это сделать нужно уже какой-то порядок иметь, иначе это будут говно-абстракции с кривыми зависимостями). В говнокоде обычно присутствует большое количество запутанности, т.к. решения проектируются на ходу. Когда кодовая база увеличивается, все эти запутанности и неочевидности очень сложно держать в голове, т.к. нужно помнить все эти особенности, не подчиняющиеся какой то общей логике и воспринимать и поддерживать такой код становится очень сложно. Про стартапы согласен - стартап стартапу рознь, просто людям при прочих равных когда есть и так предложения - проще отсекать риски, т.к. в среднем скорее всего все таки в стартапах будет чаще говнокод (думаю именно так думают hr-ы)
С чего это в стартапы нанимают хороших программистов? У меня был обратный опыт. Люди 2 года пилили проект. Без аналитики. Без опыта. Концепция проекта несколько раз поменялась. Программисты до этого пилили простые сайты где с ними и познакомился инвестор.
Автор про компании-единороги рассказывает. В бомжатнях, конечно, всё очень грустно. И дело не в том, что у них нет хороших программистов. Дело в отсутствии хорошего менеджмента, который стоит намного дороже, чем хорошие программисты.
@@user-ub3hd4sy4e единороги - это одна компания на тысячу. Да и когда все начинается никто не знает чем это кончится.
"чистый код" - это просто книга!🤣все хотят что было как там в книге описано, хрен кто когда так пишет!🤣
чистый код это код, который легко читается и который ( в контексте проекта ) легко поменяеть/расширить функционал.
в книгах описаны приёмы и подходы, но тут как в спорте: команда звёзд не равно звёздной команде. Т.е. смотреть надо по ситуации всегда
если все пишут говнокод, может это и не говнокод ?)
С кодом ситуация такая же, как с литературой: талантливых писателей мало. А "просто писать" могут многие.
Про красивый код в больших компаниях это тоже сказки. Там говкода не меньше. Слитые сорцы Яндекса тому подтверждение.
Очень крутое видео!
не соглашусь, что простой понятный код - это говнокод. ИМХО говнокод - это как раз уродливый непоятый код, с плохим неймингом, простой и понятый код - это хороший код :)
речь о нагромождении абстракций, такой код писать сложно и он явно не говнокод, но и читать и поддерживать его крайне сложно
@@user-je8vr1rz9s ну с его слов получается, что фукция без абстракций - это говнокод, даже если она понятая и простая 😅
Да что такое этот ваш красивый код
Как говорил мой прадед: "Если код работает, то это не может быть гавнокодом".
Еще говорили, что некрасивый код не работает.
Миша, подумай о втором ребенке.
Столько раз услышал слово "говнокод", что непроизвольно гимн Украины напевать начал
да все ваши скрипты бесполезные - это однодневный никому не нужный авнакод ахаха!
Как писать говнокод: 1) Начать писать на Руби, пхп, жабаскрипте или питоне 2) Сапир-Ворф позаботятся об остальном