0:23 Стиль написания кода. Инструменты его выработки , линтовщик. 2:15 Коммиты. Сообщение до коммита. !"а так же". 4:26 Тесты. Тест переживатет рефакторинг. No test for test. 5:50 Опечатки. SpellChecker. 6:34 Комментарии. 8:40 Мёртвый код. 10:23 Излишняя сложность.
отвечу тут, тк заспамили видос, а тут больше вероятность дискуссии с автором. тесты - тоже могут тестироваться, это называется мутационным тестированием. и в целом по поводу тестов, они не всегда уместны. допустим когда делается Proof of Concept, с заранее неизвестным ТЗ. то есть есть некоторое желаемое приложение с базовым набором функциональности, но источник данных/протокол/модель данных заранее не известны и изучать приходится методом проб и ошибок. в таком случае покрывать бизнес-логику тестами нет никакого смысла, тк все очень волатильно. Более того в таких случаях иногда и нет смысла делать нормальную декомпозицию кода, до момента когда функциональность проекта не будет заморожена и уже тогда можно приступать к рефакторингу и покрытию тестами (это про еще и про то, что test first конечно прекрасная идея, но в реальном мире не всегда работающая)
За 14 лет в професси, я для себя вынес пару очень простых правил, которых стараюсь придерживаться: 1) Кода должны быть как можно меньше. 2) Код должен быть как можно более простым. Все остальное, вытекает из этих двух принципов: 3) Код должен легко читаться. Любой джуниор должен без проблем сесть и быстро разабраться, как и что ваш код делает. 4) Код должен легко поддаваться модификации. Если вы сделали архитектуру, а потом, спустя время, от вас потребовали внедрить новую фичу и вы видите, что архитектура этого не позволяет - значит ваша архитектура - говно. 5) Код должен быть максимально модульным и пригодным к юнит-тестированию. Как-то так.
Ага, но вот, деталь одну не раскрыли. Что значит легко поддаваться модификации? Я, например, считаю, что код должен быть ПРОСТЫМ и ЖЕСТКИМ, а не гибким. Т.е. код должен быть как можно проще и достаточно жестким, чтобы выполнялись требования. И ни в коем случае не закладывается преждевременная гибкость. А простота модификации достигается с помощью DRY. Любое утверждение в коде должно встречаться раз. Т.е. код не на шарнирах, а когда меняется какое-то требование, надо найти ту косточку и ее сломать. Т.е. простота в приоритете перед гибкостью. 15 лет в профессии. YAGNI, DRY, KISS
@@yurim7756Да, это главные принципы для создания хорошей, гибкой архитектуры. Опытный программист пишет минимальный, работающий код, и потом, в случае необходимости, добавляет\изменяет фичу добавив и изменив пару\тройку файлов. Джуниор как правило, тратит кучу времени на создание гибкой, как ему кажется системы, с кучей интерфейсов и шаблонов и потом, когда действительно нужно добавлять\изменять фичу, выясняется, что именно этот случай, он и не предусмотрел. :) И в итоге опять тратится куча времени на переделывание архитектуры, на добавление новых интерфейсов и взаимосвязей - дабытеперь уже система стала на 100% гибкой. :) Нужно ли говорить, что следующая новая фича, скорее всего опять не впишется в старую абстракцию? :) Так что - да, я тоже за гибкость через простоту и жесткость.
@@konst3d Ну да. Преждевременная гибкость, это как правило гибкость только в предугаданных направлениях, но чрезмерная жесткость в неугаданных. В результате, если требования как-то пошли не так, джуниоры обижаются на заказчика, потому что тот сразу не сказал, что так может быть )) Или, если гибкость слишком большая, то это в ущерб статической типизации. Т.е. вроде код и гибкий, но место для счастливой и беззаботной жизни багов. Гибкость по-сути - антипод правильности. В первую очередь код должен заботиться о правильности выполнения требований. А гибкость - проблема индейская. Но к сожалению, большинство программистов именно с нее начинают. Поэтому: простота, декларативность (по возможности), в коде должны читаться требования, а не алгоритмы. И я бы выделил локальную читаемость. Большинство программистов стараются создать архитектуру, которую видно с птичьего полета. А как по мне, главнее, чтобы открыл любой файл с кодом, и чтобы он читался ну как повествовательная книга.
Комментарии - почему их не должно быть? Реальность это когда код пишется, переписывается и поддерживается разными людьми. Реальность это когда клиент не всегда платит за время на вникнуть в полную логику, и в результате переписания кусков кода он становится сложно читаемым. Как по мне, это не правильно хэйтить комментированный код. Я считаю что в условиях реальной жизни комментарии позволяют быстрее разобраться в коде и в ходе мыслей предыдущих разработчиков. А хэйт комментов как по мне это понты и высокомерие.
Если честно, перечитывая даже свой код спустя какое-то время комментарии не очень уж сильно помогали разобраться. Я по своим проектам наблюдаю следующую динамику: уменьшение количества комментариев и увеличение количества UML-диаграм. Когда видишь какое место функция или компонент занимают в программе, как они используются и видишь это графически и наглядно, анализ кода становится куда более посильной задачей.
Комментарии для очевидного кода - это дублирование этого же кода на другом языке (обычно английском), то есть, бесполезная трата времени на написание и бесполезная трата времени на чтение (особенно передаю привет сидящим на макбуках 13 дюймов). Если же комментарий для неочевидного кода, значит код стоит переписать чтобы он стал очевидным, что переносит нас на первый пункт. И есть лишь небольшая доля кода, который действительно стоит комментировать, потому что его невозможно написать более очевидно. Но во всех этих случаях комментарий должен отвечать не на вопрос "что делает этот код?", а на вопрос "нафига он это делает?"
Смотря, что делает этот код. Когда смотрим сложный алгоритм (например, в сишных библиотеках Питона), то пространные шапки комментариев очень помогают схватить основную идею. А кода формошлёп пишет над каждым методом своей CRUD-приложеньки шапку с подробным однотипным описанием параметров, потому что так положено, это - просто засорение кода. Но оно требуется, потому что разработчикам CRUD-приложений платят фактически за строки кода: они должны разработать ненужную по сути вещь, но она должна выглядеть, как настоящая, а цель этой разработки - освоение ИТ-бюджета менеджерами.
Для учебной задачи в 100 строк кода, реализующих бинарный поиск, который этот преподаватель уже 1000 раз видел, может быть, и годный принцип. А пусть он попробует так прочитать алгоритм, которого он не видел.
Согласна со всеми пунктами из видео. Такой подход действительно очень помогает держать код в порядке, другим разработчикам легче работать с таким кодом (а это важно, когда проект делается в команде). Также такой подход сильно упрощает поддержку (потому что через полгода ты ни за что не вспомнишь, зачем комментировал три строчки тут и еще вон ту переменную в другом классе). Хочу также дополнить, что есть прекрасная книга Clean Coder, где в деталях и с примерами из жизни рассказано, почему все вышеперечисленное хорошо и для проекта, и для разработчика.
Такое ощущение, что 80% комментирующих решили написать "не согласен, автор не прав" еще до того, как начали смотреть видео. Да, с примерами было бы лучше, фокус камеры и звук можно улучшить, но меня это не напрягло, материал менее ценным от этого не стал. Я с 12 годами опыта почерпнул интеренсные детали. Спасибо.
Вообще не про говнокод, грамматические ошибки, комменты, тесты - это все наживное. А вот если код пишется в лоб, без знаний того как работает то что используется, в чем его смысл итд. Не к месту используемые инструменты и библиотеки. Отсутствие обработки исключений и невнимательность
Комментировать необходимо для улучшения параметра читаемости программы. Что бы через несколько месяцев понимать, что именно происходит в коде. Для этого необходимо писать комментарии, хотя бы в одну строку.
Это только касается небольших комментариев в начале файла описывающих задачу и направление решения и проблемные участки в коде где входит путаница/сложность из-за предметной области. В остальных случая да код с комментариями это гавнокод.
Хорошее высказывание "тест это код на который нету тестов". И как следствие из этого, тесты должны быть очень маленькими и тестировать всёго один кейс. Таким образом, хоть это и код на который нету теста, он становится очень простым, понятным и минимизирует ошибки.
"взять и этот кусочек кода удалить" Самый сок, когда для релизов ПО используется бранчевание по версиям, соответственно через несколько бранчей SVN в упор не видит эти самые изменения. Просто привожу пример ситуации, когда комментирование кода вместо удаления - спасает. Я не в курсе как настроен сервер, так как я не RE, а они в свою очередь не будут менять конфигурацию, поэтому просьба об этом не писать.
@@SeniorSoftwareVlogger , Вы представляете, сколько стоит в международной компании перевести все CI сервера, обучить разработчиков, сконвертировать GIT в SVN (чтобы коммиты были отдельными), и т.д. Это очень большая сумма денег. А ещё это очень большое количество человеко-часов
@@SeniorSoftwareVlogger возможно, но по идее если будет много подписчиков то можно будет продавать рекламу общаясь напрямую с рекламодателями, вот там должны быть заработки
Самое любимое, это когда весь код излишне сложен и нет никаких комментариев )))) А потом ты идешь к тому, кто это мракобесие написал и он пытается вспомнить как это работает 🤗👍
Я чуть-чуть говнокодер 1. Плохая история коммитов, т.к. я коммичу обычно в тот момент, когда жалко потерять изменения. Логики при этом мало - все происходит достаточно спонтанно. Стараюсь придерживаться правила "атомарное изменение = коммит", но в реальном процессе это не так быстро привить себе и переучиться, как оказалось 2. Я не понимаю, зачем нужен prettier, если есть eslint. Кмк, они решают одну и ту же задачу, но eslint уже всем известен и понятен, а prettier просто еще одно решение. Месяцем ранее был бы еще более говнокодер, очень помогло научиться думать перед тем, как писать код. Самое фиговое сразу кидаться стучать по кнопкам, сначала надо прикинуть, в том числе продумать корнер кейсы. Потом планирование (конкретно что и где меняем), и только потом код (когда точно знаешь что надо писать). С плохой историей коммитов стал бороться через хуки гита. В репо есть прогоны тестов и линтера, но я себе заблочил возможность коммита, если линтеры не приведены в порядок. Это занимает 15 секунд, но коммитов стало в разы меньше, т.к. получилось избавиться от "lint fix", "flow errors fix", "another flow errors fix". Хз, мб поможет кому
@@ОнуфрийНечепуренко Почему же без комментариев? Если приходится писать костыль или просто сложную штуку, то я оставляю комент. Но чаще всего мой код читабелен и без комментариев, потому что все переменные, функции и т.д. названы правильно
Написание кода и разбор его это как целое расследование шерлока холмса и доктора ватсона, иногда волосы шевелятся от того откуда что берётся куда что идёт зачем эта функция нужна, что она описывает, а потом вылет вылет вылет 🙏😁шикарный видос. 2 правила пиши чтобы разобрался даже ребёнок, 1 чем меньше написано тем лучше
Отлично все расписал. Последний момент - это главное, что отличает говнокодера от хорошего разработчика. Тем, кто хочет перестать говнокодить, советую прочитать и перечитывать Clean Code by Robert Martin.
Боб разрабатывал байтомешалки на Clojure и Java, поэтому у него есть религиозные убеждения о unit-тестах как о серебряной пуле, что не никак не помогает, и даже вредит, например при разработке Android приложений.
@@nikitabobyshew7927 у unit-тестирования android-приложений есть такая особенность: приложение будет рассыпаться на части, а все unit-тесты ни разу не упадут. Зато дадут ложное чувство уверенности. Потому что тестируется не тот код, в котором будут ошибки. - ну так надо тестировать там где возникают ошибки - для этого нужны НЕ unit-тесты.
Дядюшка Боб советует: 1. Test Driven Development by Kent Beck 2. xUnit Test Patterns Refactoring Test Code by Gerard Meszaros 3. Growing Object-Oriented Software, Guided by Tests by Steve Freeman
С умной рожей восклицаю: 2:23 не версирование, а версионирование! Кстати, Дмитрий, что думаешь по поводу вот этого: habr.com/company/infopulse/blog/345826/?
Прочитал коментарии и понял что большинство разработчиков не понимают насколько важны такие понятия как стиль, единые подходы, избегание излишней сложности, чистота и тд потому что не участвовали в действительно больших и продолжительных проектах. Да возможно когда ты делаешь проект, который в стадии активной разработки продлиться 3 месяца, после которых все на его забьют тут не важно насколько он чисто будет написан. Но, поверьте, если проект делается 5+ лет группой 50+ человек, то в случае игнорирования данных практик его разработка будет невероятно сложной, болезненной и демотивирующей. Но если следить за этим, уделять достаточное время дизайну и устранению технического долга, то и сложные системы могут быть достаточно внятными, прозрачными и понятными для изменений.
Хотелось бы услышать больше на тему софт скила (это скорее к твоему прошлому видео). Сильно ли влиял другой язык на работе на твой професиональный рост? Как с опытом развиваеться скилл? Какие умение (не технические) должны быть что бы можно было претендовать на роль такого себе мини тим лида))
По поводу микро-коммитов не соглашусь. Когда вошёл в поток и активно делаешь изменения, особенно если они связаны с рефакторингом, это в итоге затрагивает большие куски кода. И если пытаться разделить эти изменения по смыслу и разбивать по коммитам, то уйдёт гораздо больше времени из-за того что будешь откладывать на будущие коммиты то что нужно сделать сейчас. Если же сделать кучу нужных изменений сразу, а затем пытаться разбить используя возможности системы контроля версий - это опять окажется болью, потому что изменения в одном и том же файле могут оказаться разными по смыслу... Поэтому всё зависит от процессов выстроенных в компании и темпа разработки. Если контроль качества имеет более высокий приоритет, тогда имеет смысл вести разработку медленно используя все возможности для того чтобы свести к минимуму незапланированные ошибки. В молодых же проектах вполне можно делать быстрые изменения и большие коммиты, которые включают в себя много разноплановых вещей.
Тебя не кто не заставляет комитить сразу. Я пишу в экстазе громадное количество строк и потом делаю много комитов :) Любой git клиент умеет partial commits. Идешь в файл помечаешь строки для комита в этом файле и комитишь ) Конвенцию для текста лучше брать с linux kernel репозитория: "action description"
А в чем тут несогласие, он вроде так и сказал: по возможности делать частые и мелкие коммиты но если изменения вдруг стали глобальные то делай большой коммит
в больших проектах делать большие коммиты, которые включают в себя много разноплановых вещей думаю будет не очень хорошей практикой так как со временем разработчикам придется со всем этим разбираться
Разногласие в том что он привёл это как аргумент того что микрокоммиты - показатель хорошего программиста. Хотя это не так. Джуна гораздо проще делать микрокоммиты потому что от него выхлоп меньше :)
Бля кодер это программист одиночка, главнре что бы работало и быстро. Программист это тот кто в компании других кодеров, красивый и рабочий код удобен для всех окружающих!
Это как судить по почерку рукописного текста о таланте писателя... Т.е. вообще мимо... Почти всё о рюшечках в коде, бестпрактиз и подобных вещах не влияющих на функционал и качество самого кода. Только про чрезмерную сложность и тесты можно отнести действительно к программированию. На мой взгляд, говнокодер, это человек плохо понимающий что делает, чаще всего, скопипащенный им откуда-то, код (своего кода у них обычно мало). Мне, лично, по барабану на большинство опечаток, пропущенные отступы и подобный "стиль" - хорошо, если он есть, но говнокодером за отсутствие точно не назову. А вот когда одна бездумная копипаста другую погоняет и код можно сократить в несколько раз без потери функционала - вот это для меня и есть признаки говнокодера. Когда не используются возможности языка/библиотек упрощающие код. Когда программист не может придумать ничего своего, но очень следит в пул-реквестах за "стилем" тех, кто реально придумывает, выставляя тех говнокодерами за неправильные пробелы и опечатки. И очень жаль, что сейчас тенденция считать таких говнокодеров хорошими спецами только потому, что он делает всё, что описано в данном видео :(
0:23 вообще я думал что под стилем ты имеешь ввиду именно стиль, а ты про форматирование. а вот с 10:23 это уже ближе именно про стиль программирования. PS: из самого простого, например индусы вполне могут писать - if ( boolvar == true ) then ... и т.п. ну да и закрученные циклы, когда в JS можно использовать различные итераторы и т.п.
на самом деле ничего невероятно плохого в сравнении с true нет. Да, избыточно, но понятно и однозначно. А вот сишные приколы типа while (!a++) прямо скажем, не лучшая идея.
К примеру если есть такое место в коде, где код запускается постоянно и много раз в секунду, + состоит из нескольких больших лупов, поэтому создание лишних функций добавляет оверхед, плюс нужно в каждой из маленьких функций заново рассчитывать локальные переменные, либо же передавать огромное количество переменных то в одну функцию, то в другую, что тоже плохо, поэтому у меня в том месте одна большая функция (~200 строк), это проблема? Тоесть я всёравно должен разбивать функцию на куски, даже если это пусть и незначительно, но всё же вредит производительности или нет?
@@vodchiy нет не много, всего 1 место, в котором работает либо одна функция, либо другая, обе сильно огромные по 200-300 строк, я там всё довёл до микрооптимизации, разбивать не собираюсь, спасибо за ответ.
Спасибо за видео. Недавно смотрел одного зарубежного блогера, как оказалось - он русский, но при этом ведёт канал на английском. Основная причина - тонна негатива в комментах. Сейчас подобное замечаю и у вас, даже не знаю, почему в русскоязычном коммьюнити такая ситуация...
И еще вопрос: действительно ли необходимо такое количество коммитов? Мне кажется нехорошей ситуация с огромным количеством коммитов, я даже готов использовать некоторые инструменты для слияния коммитов.
Спасибо за ценный материал, я только год как (сам обучаюсь), прям чувствую что это моё. И данный ролик помог осознать некоторые фундаментальные истины которые я считаю нужно закладывать с самого начала. Сложнее всего для меня это избавиться от привычки комментировать функции, я понимаю что в идеале стоит писать документацию описывающую взаимодействие и функционал, но у меня пока туго с абстрактным мышлением, и держать в голове понимание того как что работает, бывает очень трудно. В добавок к этому я крайне паршиво знаю английский, и совмещать изучения двух языков крайне трудно, по этому стараюсь давать названия переменным, функциям, классам, всегда на английском, зачастую приходится лазить в переводчик конечно)) а потом через пару дней тупить, что это за слово я тут написал) но в целом это помогает их запоминать.
Не нужно комментировать каждую функцию. Это только засоряет код пустопорожним текстом. Если в проекте это требуют, значит, проект - суть освоение ИТ-бюджета, и из него надо валить в приличное место, пока тебе голову не загадили так же, как они загаживают код.
1) Ни слова не сказал про архитектуру 2) Нулевой взгляд на экономическую составляющую. Иногда может быть дешевле 3 раза сделать приложение заново, только для того чтоб внести маленькое изменение, но это приложение будет стоить по 100 долларов от индуса-говнокодера. Чем один раз заказать приложение у студии за 4000 долларов, где всё будет покрыто тестами и легко модифицироваться. Или другой пример: иногда дешевле снять дополнительный сервер, чем потратить месяц работы дорогостоящего программиста, который будет оптимизировать приложение. Нужно в деньгах всё это взвешивать, а не в "говнокодер vs программист"
Alex Alex думаю речь шла о том, что уже принято решение программировать однозначно. Нанят программист. И вот тут то и нужно это все чтоб стать лучше как программист. А так конечно если зацикливаться о тех вопросах, которые вы пишите, можно вообще ничего не делать.
@@joma0305 Ни о чём таком речь не шла. Не нужно додумывать. Я много раз видел как в видео человек говорит "белое это белое", и тут же три ветки комментов: одна пишет "автор, не правда, белое это черное", вторая пишет "автор, не правда, белое это белое", а третья "я тоже против негров". Всё что не было в видео - это лишь ваша фантазия, умноженная на ваши триггеры. Того, кто изучает кулинарное дело, увидит в сообщении автора призыв к употреблению смузи. Кто-то тут увидит политику, не зависимо от темы видео. Кто-то подумает что автор говорит про кастовую систему и пытается его унизить, сверкая своим статусом. Кто-то подумает что это реклама ноутбука и будет убеждать что макбук всё равно лучше. И каждый будет на своей волне. Большинство из этих людей уже хотели что-то написать на какую-то определенную тему, ещё задолго до случайной находки этого видео. Они просто умножили то что они хотели сказать на предмет самого видео. К примеру, я уже знал что хочу написать про экономический вопрос, просто увидев слово "программист", ещё до того как я полностью прочитал название видео и увидел там слово "говнокодер" и ещё до того как я посмотрел видео. Если бы в видео автор сказал что-то вроде "тема это кликбейт, на самом деле я хотел бы обсудить автомобили", я бы всё равно как-то модифицировал экономическую составляющую, перенеся её на работников завода автомобильной промышленности и их менеджеров. Люди заходят на ютуб не чтоб узнать чужое мнение, а чтоб написать своё. Вот и всё.
Архитектуру (типовую) ему архитекторы сверху спускают без права апелляции. Ему остаётся только накопипастить типового кода в контроллеры, адаптеры, дата-объекты и прочее. Понятно, что если такой код взять в чистом виде, получится мало и несерьёзно. А не сумеешь объяснить, за что тут заказчиком уплачено 50 миллионов, - вылетишь с работы. Вот так и рождаются всякого рода "клинкоды", шапки комментариев над каждой тривиальной функцией, и тонны юнит-тестов на сеттеры и геттеры. Они просто помогают никчёмному и ненужному приложению выглядеть, как взрослое. Так что автор, осознанно или неосознанно, взвешивает в деньгах, но взвешивание - специфичное для ниши.
Но неизменность теста, т.е. его слабая связанность с особенностями реализации кода, может также означать недостаточный контроль кода. Может оказаться, что мы просто мало что тестируем; тестируем какие-то очевидные вещи. Можно ведь написать тест, который не будет зависеть от кода, но также и не будет зависеть от ошибок в нём. :)
Я не уверен ESLInt ли работает для TypeScript, но очень часто когда с ним работаю на AngularTS он раздражает. Начинает переносить аргументы для вызова метода на новую строчку даже если по сути имя аргумента было небольшое, в итоге файл порой превращается в эту узкую башню, в которой вызов функции растянут на 4-5 строк.
Мне лично далеко до профи или сеньера...но, все же, выскажу свое возражение. Мне кажется, что бОльшая часть придирок из видео в стиле граммар наци. Опечатки, комментарии, описание коммитов..понятно, что хороший программист обязан соблюдать нормальный нейминг и не злоупотреблять вложенностью и тп. Но, все же, программист должен уметь делать хороший уровень абстракций, должен следить за зависимостями, должен использовать паттерны проектирования и вообще хорошие практитики..а доебываться (простите за грубость) до грамматики в переменных или что код иногда выбивается из стройного стиля, не сказав ни слова о действительно важных для профи вещах, это как-то странно. Если об этом где-то сказали, а я , по неопытности, просто не понял - прошу прощения.
Silver Shadow ну вот и видно, что тебе далеко от профи. Предположу что автор описывал правила для тех кто работает от нуля до двух лет и эти правила в работе с командой куда важнее чем знание паттернов, которые с легкостью могут стать антипаттереами. Новичкам никто не будет давать писать архитектуру и как правило она продумывается командой, а не одним человеком и большая часть работы кодера заключается в том, что бы написать маленький функционал или исправить багу - по сути сделать маленькую прогу внутри большой где ты будешь пользоваться уже существующими абстракциями и архитектурой
Не совсем понятно, зачем было дополнительно язвить и принижать, если я открыто признался, что являюсь относительно новичком...это сразу ставит под сомнение адекватность вашего дальнейшего ответа. Тем не менее спасибо за ответ, вы разъяснили мне позицию автора. Команды бывают разного размера чем меньше команда, тем шире зона отвтетсвенности и больше кода надо проектрировать самостоятельно, а на фриалнсе и вовсе часто работает один человек. И все же, оформление кода, так что бы он был удобен для команды != профи программирование. Я не отрицаю важность сказаного, и про антипаттерны, естественно, согласен. Просто не буду же я трактат со всеми подробностями писать на 4 листа в комментах...я лично( и некоторые более опытные единомышленники) фундаментально разделяю говнокодерство и плохое оформление. Если говорить по видиео, то к говнокодерству, например, относится высокий уровень вложенности. Точно так же же я отношу к нему отсутвие или неадекватное использование абстракций( делает код немасшатабируемым), я понял, что лично вы абстракции не пишите, а только рабтаете с готовым, но абстракции возможны и неболшой проге, так что вы задумайтесь ( хотя я и не уверен, практикуется ли такое в JS, но обращение было не к вебразработчикам). Отсуствие тестов там же, хотя следуя вашей логике отсутсвие тестов нельзя относить к говнокодерству, ведь в компании же есть отдельные люди Тестировщики, чья работа писать их. В общем, всегда приятно получить корректировку от более опытного специалиста, и я не хочу с вами спорить, потому что для вашей сферы и рода дейтельности вы очевидно правы. Я просто хотел очертить более широкую позицию. И разделить говнокодерство и плохое оформление, как два различных греха и степень тяжести у них различная.
@@silvershadow13 Я не знаю, буду ли я в твоих глаза считаться опытным программистом, но я работаю тимлидом и руковожу командой из 9 человек. Автор видео затронул базовые проблемы из-за которых возникает множество проблем с коммуникацией. Какие бы ты там "хорошие уровни" абстракций не писал и как бы ты хорошо не следил за зависимостями, но если у тебя коммиты не выстроены логически и в каждом коммите по 40+ файлов изменены, то с тобой работать будет некомфортно и тебя заставят переучиться. Нравится тебе это или нет. Если ты пишешь с грамматическими ошибками, то на код ревью тебя заставят их исправить. Нравится тебе это или нет. А оформление кода вообще невероятно важно, так как отсматривать кучу файлов, написанных в одном стиле куда быстрее, чем отсматривать кучу файлов, написанных в разном стиле. Да и вообще, глаз привыкает к стилю и поэтому некомфортно работать, когда кто-то выбивается из стиля. И это никак не отменяет того, что ты должен использовать паттерны (когда это нужно), следить за зависимостями и тд. Ты вообще пишешь про другое. Ты пишешь вообще про абстрактные знания, которыми вообще любой должен обладать. И если человек не умеет паттернами пользоваться, то о чём с ним дальше разговаривать? Это всё уже давно само собой разумеющееся и тебя никакая нормальная команда ждать не будет, если у тебя таких знаний нет. Это базовые вещи.
Насчет юнит-тестов не совсем согласен. Возможно я не так понял высказывание, но тест не всегде должен переживать рефакторинг. Вот пример : у вас есть мок на метод, в ассерт части вы чекаете сколько раз замоченный метод вызывается, скажем, это был репозиторий, который вычитывает данные из таблицы имя и фамилию. Какой-то интерн\джун\вы в прошлом написал так, что значение вычитывалось несколько раз, и вы успешно это заюниттестили. После того, как у вас БД на проде загружена на 146% вы обнаруживаете, что этот код должен быть отрефакторен так, что бы метод вызывался один раз. Вам нужно менять тесты! Не бойтесь проверять в тесте количество вызовов метода или еще что-нибудь фажное в угоду будущему рефакторингу, не подставляйте себя! :) Может быть пример не очень корректный, но суть вы, надеюсь, поняли. Юнит тесты должны быть как ваша математичка, строгие, но справедливые! =D
После обнаружения множественной загрузки одних и тех же данных из БД возникают серьёзные вопросы к авторам кода. Ведь нагрузочные требования должны были быть в проектной документации. А если их там не было, то почему взялись за разработку незнамо чего? Так что какой там рефакторинг, тут профессиональное несоответствие в полный рост. Но я скажу, почему в большинстве случаев такие вопросы не задаются. Потому что сам проект не нужен, открывается только ради освоения бюджета на автоматизацию и поставить галочки: "бизнес в этом году автоматизирован на 87.5%". И в таких проектах - как раз хорошо, что БД загружена на 146%, т.к. это помогает пускать пыль в глаза: вот какая нужная приложенька, и сколько сложных вычислений она делает. А давайте закупим ещё 20 серверов и с них тоже снимем себе откатов.
@@InconspicuousChap ого некропост)) но да, вы же робот и пишете идеально продуманный код. А условие в конце, что пример не корректный служит лишь для иллюстрации, вы, почему то пропустили не как робот, а как человек.
@@MayDay-g4k Ну да, в понятиях ЕГЭшных поколений я робот. Я знаю, что я делаю, когда пишу код. Так же, как и люди, у которых я учился, вся старая школа знала, что делала, когда писала код. И зачем писала (кто пользователи, каков эффект) - тоже знала. И у буржуев так же: Дэйв Катлер, Линус Торвальдс, Джон Маккарти, Никлаус Вирт, Кен Томпсон и другие - все формировали постановку задачи, а потом проектировали решение перед тем, как кодить. Это вы только лепите, сами не зная, что и зачем. И получается у вас 100% говнокод, как его ни отформатируй и каких юнит тестов ни понапиши. И работа у вас есть исключительно в части распильных никому, кроме откатчиков, не нужных проектов, поэтому всем по барабану на полуработающие решения.
@@MayDay-g4k Узколобость или нет, но к счастью, софтостроение - дело такое. Или взлетит, или нет. Так что шлёпай свои формы дальше, "продвинутый" и "современный" ты наш. И знай своё место формошлёпа. Ты будешь его занимать, пока не научишься уважать старших.
Можно поподробнее про стиль? Это какое-то общее между использованием выбранной нотации ( например camelCase, snake_case), стандартов языка (например PEP8 для Python) и использованием возможностей языка (функциональщина, enumerate и т.д.) или это нечто более сложное, уникальное, идущее от конкретного человека?
Видео понравилось. Подробности по каждому пункту можно погуглить при желании. Взял на заметку разбивку больших коммитов на более мелкие, атомарные. Часто говорят, типа, в моей компании сжатые сроки, мы не пишем тестов, нет общих правил и стиля написания кода, нам не до статических анализаторов, у нас постоянно гарь... Профессионализм - это ещё и умение выбирать компанию и проект для работы. Зачем лезть в гарь, когда можно работать в компании с нормальным планированием и качественными процессами? Где говнокод тебе не навязывают, а отучают от него!
@@SeniorSoftwareVlogger где то видел рецепт у Вас яблочный уксус и что то ещё - не могу найти это видео. Т.к. испытываю проблемы со сном с засыпанием и просыпаюсь ночью часто. По поводу экрана и яркого света это связано с выработкой мелотанина - которая подавляется(таблетки есть) - думаю что моя трабла не в этом
Я до просмотра этого видео думал что говнокод - это код, который растянут, сложен, и то что можно было написать за строчек 10 в итоге написан на 100 (по сути последний твой пункт), но было перечисленно столько пунктов, которые даже к кодингу особого отношения не имеют и их можно пофиксить за пару дней, а вот в этом пункте ты сам сказал что иногда приходится использовать сложный код, вложенные циклы, условия в них. Иногда у меня возникает вопрос, я пишу говнокод или это вынужденная мера? это можно как-то выявить и пофиксить?
никак это не узнать. Зовешь другого твоего же уровня и пускай разбирается, если спотыкается значит говнокод, это единственный вариант. Можно еще читать собственный год написанный давно, если спотыкаешься, то говнокод.
@@VORASTRA нет, он не это говорит, а то, что если к коду требуются комментарии, то, значит, код написан плохо. Слишком радикальная позиция, как мне кажется.
@@pumbo_nv всё ты правильно говоришь. Фраза "если коду требуются комментарии, то значит код написан плохо" - это фраза обычных теоретиков, которые к реальному программированию отношения не имеют и программируют в книгах задачи, которые в конце главы расположены))) Я в программировании уже около 10 лет и я прошел через огромное число проектов и работаю тим лидом на данный момент. И я могу со 100% уверенностью сказать, что код без комментариев - это просто ублюдство, так как сразу видно, что писал какой то человек, который думает только о себе и не думает, что его код будет смотреть другие. И реальность такова, что есть полно сложных вещей, которые приходится делать. Алгоритмически сложных вещей и сложную логику. Само собой, глупо писать комментарии в очевидных местах. И ровно так же глупо НЕ писать комментарии там, где они реально нужны. Какой бы не был красивый код, если сама функциональность сложная, то гораздо проще будет понять код, который написан с комментариями.
Еще очень важная штука это отличать символы Юникода. Например ни одна IDE (VS, VSCode) не поняла разницы между русской С "с" и англицкой Ц "с" а вот гитлаб в мердж реквест е смог. Когда вы используете IDE для команды монолита - все ОК. Но когда у вас Pyhton, NodeJS, C# на микросервисах - все становистся критичным адсци, на эту ошибки ушло три дня ресерча и 5 минут моего ревью в GitLab реквсета, который уже был слит. Рекомендую запретить все языки вкроме английского в коде!!!
вчера наткнулся на классную фичу. В файлах переводов один из разработчиков написал 2 ключа, в виде "MY_SPECIAL_KEY" и "MY_SPEСIAL_KEY". Как получилось 2 одинаковых ключа? Все просто, во втором случае используется русская буква "С"
Программист отличается от говнокодера только тем, что его код отлажен, протестирован и оптимизирован. Остальное все задротство. А форматировние кода в любом редакторе сейчас одной комбинацией клавиш делается.
Книгу упомянули раза 3-4 под этим видео с отсылкой на то, что советы похожие. Если это действительно так, то одобряю конечно. Опять же авторитетные для меня люди ее читали и рекомендовали. Достаточно?
работаю в силиконовой долине, 80% окружающих меня людей не придерживаются стиля, как и я. Просто пусть все знают, что у компании ***z*n программисты гавнокодеры) Успехов тебе, Senior программист.
В python идыешка pycharm все подсвечует ) но говнокодить приходится, скорее всего из-за нехватки опыта) я получаю удовольствия от того что пишу код, но моя нынешняя профессия мне не нравится, хочу стать кодером, надеюсь когдато кто-то возьмет меня каким-то интерном или джуном... смотрю видео автора, для мотивации =) Спасибо тебе!
@@AlexNatkin я пишу каждый день, что-то новое, завел git, но мне приходится работать сисадмином(принтера, сервера, сервисы) и параллельно кодить для этой же компании, за премии
Dmitry не хорошо и не плохо. Это просто на заметку другим, если хотят узнать чуточку больше обо всём том, что в ролике. Ну и автору на заметочку, конечно же, куда без этого?! :)
Насчет тестов не все так плохо - те же пхпшные тесты можно проверить с помощью infection и почти уверен что для других тестовых фреймворков должен быть инструментарий для мутационного тестирования. Естественно MSI - не истина в последней инстанции, но все же дает представление насчет корректности написанных тестов
всегда в комментариях к классу или методу пишу для чего он предназначен, что возвращает и описываю переменные и их типы. получается я говнокодер по новым веяниям поколения ноде-джс ?
По разному. Вообще, любые комментарии - это скорее плохо чем хорошо. Но к функциям терпимо (хотя я не пишу), если они сложные, тяжело ясно назвать (например, в сложных алгоритмах), чтобы не смотреть в тело. А еще неплохо, если они в каком-то специальном формате, который может читать редактор и делать потом подсказки. Вообще, всё что улучшает понятность, всё это хорошо. Но с комментариями часто такая штука, что если они нужны, значит код говно, по нему не понятно, что он делает. Или слишком сложный оправдано, но непонятно что делает. Так вот, комментарии + непонятный код, это может быть сложнее, чем просто код. Ведь вы увеличили количество информации, это точно сложнее. А еще часто комментарии могут нагло врать. Код чаще меняется, может даже средствами автоматического рефакторинга. Где-то из другого места изменили имя переменной, функции, и комментарий устарел. В общем, желательно, чтобы код читался, как книга. Буквально повествовательно, декларативно. По возможности. Имхо, даже намного важнее локальная читаемость кода, чем какая-то общая архитектура кода. Но, описывать функции, это олдскул, не так и плохо. Но, согласен с автором, комментарии - это то, к чему не надо стремиться. Я их пишу, когда уже сдаюсь. Когда уже соглашаюсь, что я недостаточно хорош, чтобы выразить это кодом понятно. Вообще в ролике про говнокодеров ничего в общем-то не сказано, несмотря на название. Говнокодить можно и с гитом, и писать прекрасный код можно без гита.
Во, во. Сейчас веду проект под STM32, в штатных либах там комменты по десять строк к каждой функции. Это что ж получается, в компании запилившей ставший стандартом де-факто микроконтроллер одни говнокодеры что ли работают?
Большое количество комментов ухудшает читаемость самого кода, да и далеко не каждый программист умеет хорошо писать документацию к собственному коду. Комментировать имеет смысл только очень оригинальный код, который сложно работает и не является типовым, в плане выполняемой задачи. Да и то, скорее всего, это просто хреново написанный код. Комменты хороши для каких-то сложных инструментов, или когда реализация скрыта. В противном случае достаточно делать коммент к сложному методу или классу, если его функция не выходит из его названия.
2:52 во-первых я таки будучи простым сисадминским скриптером до сих пор подхожу под определение программиста :) во-вторых это больше к умению излагать мысли, чем к программированию. Соответственно во-время собеседования возможно имеет смысл не только дать человеку написать кусок кода, но и попросить написать диалог/зарисовку/рассказ. Заодно и умение нестандартно мыслить проверится.
Все херня. Если делать все методично, по полочкам, с тестами, коммитами, трекерами и прочей моральной мастурбацией, то вы никогда не запустите свой сраный проект. И уже нахрен никому не будут нужны ваши коммиты, тесты и читаемость. А вот если вы в одиночку способны наговнокодить за пару дней работающий продукт, то вы реальный маньяк, и не слушайте никого. Людям сейчас просто нечем заниматься, вот и выдумавают всякие эджайлы, кодревью, тдд, метрики, трекеры и прочую лабуду. Ибо херачить код мало кто жаждет, а кушать и руководить хотят все.
В одиночку наговнокодил проект и пусть потом остальные в этих дебрях разбираются - это уже их проблемы. Главное, что у них есть такой красавчик, умеющий валить в одиночку, кладя на всех вокруг.
@@re1neke_f0x ну да, а чем еще заниматься, пока остальные обсуждают задачу, анализируют методы решения, открывают запись в трекере, пишут две строчки кода, тестируют их, документируют, ревьюят, рефакторят коммитят, билдят, проводят интеграционное и нагрузочное тестирование, а затем размазывают во всех пабликах как они круто и методично справились с поставленной задачей. Если в команде нет красавчика, все ресурсы быстро съедает бюрократия. Любой реально работающий проект начинался с говнокода.
Интересно, почему такие спецы как ты все еще не лидируют в индустрии. Хм, возможно потому, что твой говнокод нахер никому не сдался в крупных проектах? Попробуй написать что-то подобное с претензией на лучший код для, скажем логистической индустрии, и ты будешь отправлен в свободное плавание. Хотя… вы, ребят, продолжайте мнить себя экспертами. Так конкуренции меньше.
@@AlexiosLair именно такие спецы и лидируют в индустрии, но у них нет времени п-ть на конференциях и по пабликам, поэтому их и не особо заметно. Ваши "крупные проекты" после активной фазы разработки -- это 90% неподдерживаемого легаси, тонны устаревшей никому не впившейся документации и куча самопальных велосипедов прикрученых сбоку, которое еще и билдится через раз. Откуда такое берется, ведь все же разрабатывали правильно и методично? Ну и по поводу говнокода: любой код есть по определению говно, как бы правильно он ни был написан. Ибо здоровый спец всегда критичен к результатам своей работы. И если однажды вы посчитали, что высрали розу, значит ваша эволюция как спеца завершена -- можете идти в менеджеры.
0:23 Стиль написания кода. Инструменты его выработки , линтовщик.
2:15 Коммиты. Сообщение до коммита. !"а так же".
4:26 Тесты. Тест переживатет рефакторинг. No test for test.
5:50 Опечатки. SpellChecker.
6:34 Комментарии.
8:40 Мёртвый код.
10:23 Излишняя сложность.
Спасибо!
Спасибо!
отвечу тут, тк заспамили видос, а тут больше вероятность дискуссии с автором.
тесты - тоже могут тестироваться, это называется мутационным тестированием.
и в целом по поводу тестов, они не всегда уместны. допустим когда делается Proof of Concept, с заранее неизвестным ТЗ. то есть есть некоторое желаемое приложение с базовым набором функциональности, но источник данных/протокол/модель данных заранее не известны и изучать приходится методом проб и ошибок. в таком случае покрывать бизнес-логику тестами нет никакого смысла, тк все очень волатильно. Более того в таких случаях иногда и нет смысла делать нормальную декомпозицию кода, до момента когда функциональность проекта не будет заморожена и уже тогда можно приступать к рефакторингу и покрытию тестами (это про еще и про то, что test first конечно прекрасная идея, но в реальном мире не всегда работающая)
Лучше в личку на патреоне.
name eman ф
За 14 лет в професси, я для себя вынес пару очень простых правил, которых стараюсь придерживаться:
1) Кода должны быть как можно меньше.
2) Код должен быть как можно более простым.
Все остальное, вытекает из этих двух принципов:
3) Код должен легко читаться. Любой джуниор должен без проблем сесть и быстро разабраться, как и что ваш код делает.
4) Код должен легко поддаваться модификации. Если вы сделали архитектуру, а потом, спустя время, от вас потребовали внедрить новую фичу и вы видите, что архитектура этого не позволяет - значит ваша архитектура - говно.
5) Код должен быть максимально модульным и пригодным к юнит-тестированию.
Как-то так.
Ага, но вот, деталь одну не раскрыли. Что значит легко поддаваться модификации?
Я, например, считаю, что код должен быть ПРОСТЫМ и ЖЕСТКИМ, а не гибким. Т.е. код должен быть как можно проще и достаточно жестким, чтобы выполнялись требования. И ни в коем случае не закладывается преждевременная гибкость. А простота модификации достигается с помощью DRY. Любое утверждение в коде должно встречаться раз. Т.е. код не на шарнирах, а когда меняется какое-то требование, надо найти ту косточку и ее сломать.
Т.е. простота в приоритете перед гибкостью. 15 лет в профессии. YAGNI, DRY, KISS
@@yurim7756Да, это главные принципы для создания хорошей, гибкой архитектуры. Опытный программист пишет минимальный, работающий код, и потом, в случае необходимости, добавляет\изменяет фичу добавив и изменив пару\тройку файлов.
Джуниор как правило, тратит кучу времени на создание гибкой, как ему кажется системы, с кучей интерфейсов и шаблонов и потом, когда действительно нужно добавлять\изменять фичу, выясняется, что именно этот случай, он и не предусмотрел. :)
И в итоге опять тратится куча времени на переделывание архитектуры, на добавление новых интерфейсов и взаимосвязей - дабытеперь уже система стала на 100% гибкой. :)
Нужно ли говорить, что следующая новая фича, скорее всего опять не впишется в старую абстракцию? :)
Так что - да, я тоже за гибкость через простоту и жесткость.
@@konst3d Ну да. Преждевременная гибкость, это как правило гибкость только в предугаданных направлениях, но чрезмерная жесткость в неугаданных. В результате, если требования как-то пошли не так, джуниоры обижаются на заказчика, потому что тот сразу не сказал, что так может быть ))
Или, если гибкость слишком большая, то это в ущерб статической типизации. Т.е. вроде код и гибкий, но место для счастливой и беззаботной жизни багов. Гибкость по-сути - антипод правильности. В первую очередь код должен заботиться о правильности выполнения требований. А гибкость - проблема индейская. Но к сожалению, большинство программистов именно с нее начинают.
Поэтому: простота, декларативность (по возможности), в коде должны читаться требования, а не алгоритмы. И я бы выделил локальную читаемость. Большинство программистов стараются создать архитектуру, которую видно с птичьего полета. А как по мне, главнее, чтобы открыл любой файл с кодом, и чтобы он читался ну как повествовательная книга.
Я понял, это Киану Ривз, который выбрал синюю таблетку)
Развитие темы пошло 👍
Комментарии - почему их не должно быть? Реальность это когда код пишется, переписывается и поддерживается разными людьми. Реальность это когда клиент не всегда платит за время на вникнуть в полную логику, и в результате переписания кусков кода он становится сложно читаемым. Как по мне, это не правильно хэйтить комментированный код. Я считаю что в условиях реальной жизни комментарии позволяют быстрее разобраться в коде и в ходе мыслей предыдущих разработчиков. А хэйт комментов как по мне это понты и высокомерие.
Если честно, перечитывая даже свой код спустя какое-то время комментарии не очень уж сильно помогали разобраться. Я по своим проектам наблюдаю следующую динамику: уменьшение количества комментариев и увеличение количества UML-диаграм. Когда видишь какое место функция или компонент занимают в программе, как они используются и видишь это графически и наглядно, анализ кода становится куда более посильной задачей.
Комментарии для очевидного кода - это дублирование этого же кода на другом языке (обычно английском), то есть, бесполезная трата времени на написание и бесполезная трата времени на чтение (особенно передаю привет сидящим на макбуках 13 дюймов). Если же комментарий для неочевидного кода, значит код стоит переписать чтобы он стал очевидным, что переносит нас на первый пункт. И есть лишь небольшая доля кода, который действительно стоит комментировать, потому что его невозможно написать более очевидно. Но во всех этих случаях комментарий должен отвечать не на вопрос "что делает этот код?", а на вопрос "нафига он это делает?"
Очень круто, спасибо!
Смотря, что делает этот код. Когда смотрим сложный алгоритм (например, в сишных библиотеках Питона), то пространные шапки комментариев очень помогают схватить основную идею. А кода формошлёп пишет над каждым методом своей CRUD-приложеньки шапку с подробным однотипным описанием параметров, потому что так положено, это - просто засорение кода. Но оно требуется, потому что разработчикам CRUD-приложений платят фактически за строки кода: они должны разработать ненужную по сути вещь, но она должна выглядеть, как настоящая, а цель этой разработки - освоение ИТ-бюджета менеджерами.
как говаривал один из преподавателей, "я должен ваш код(Java) читать как художественную литературу, не напрягаясь, не отгадывая что откуда и зачем"
Для учебной задачи в 100 строк кода, реализующих бинарный поиск, который этот преподаватель уже 1000 раз видел, может быть, и годный принцип. А пусть он попробует так прочитать алгоритм, которого он не видел.
Ура, под всем подписываюсь, большое спасибо за видео, его можно использовать для объяснения этих идей :)
Согласна со всеми пунктами из видео.
Такой подход действительно очень помогает держать код в порядке, другим разработчикам легче работать с таким кодом (а это важно, когда проект делается в команде). Также такой подход сильно упрощает поддержку (потому что через полгода ты ни за что не вспомнишь, зачем комментировал три строчки тут и еще вон ту переменную в другом классе).
Хочу также дополнить, что есть прекрасная книга Clean Coder, где в деталях и с примерами из жизни рассказано, почему все вышеперечисленное хорошо и для проекта, и для разработчика.
Программист понимает, что он говнокодер. А говнокодер думает, что он программист ))
Мощно! )))
прямо как психи в больнице
Явно недооценённый комментарий. Поставлю штуку баксов, что тысячи говнокодеров нажали здесь дизлайк.
Такое ощущение, что 80% комментирующих решили написать "не согласен, автор не прав" еще до того, как начали смотреть видео. Да, с примерами было бы лучше, фокус камеры и звук можно улучшить, но меня это не напрягло, материал менее ценным от этого не стал. Я с 12 годами опыта почерпнул интеренсные детали. Спасибо.
Воу, вот такого видео реально не хватало!
Вообще не про говнокод, грамматические ошибки, комменты, тесты - это все наживное. А вот если код пишется в лоб, без знаний того как работает то что используется, в чем его смысл итд. Не к месту используемые инструменты и библиотеки. Отсутствие обработки исключений и невнимательность
Комментировать необходимо для улучшения параметра читаемости программы.
Что бы через несколько месяцев понимать, что именно происходит в коде.
Для этого необходимо писать комментарии, хотя бы в одну строку.
Не нужно, хороший код понятен без комментариев, если код не понятен без комментариев - его написал говнокодер
@@Кулинарноеугаралово ха-ха-ха, смешно-смешно))
можно посмотреть ваш код?)))
@@Asiro-S, я комментирую свой код, у меня немного другая сфера в которой приходится все комментировать
Это только касается небольших комментариев в начале файла описывающих задачу и направление решения и проблемные участки в коде где входит путаница/сложность из-за предметной области. В остальных случая да код с комментариями это гавнокод.
Очень круто! О правилах хорошего кода за 13 с половиной минут. Спасибо!:)
Хорошее высказывание "тест это код на который нету тестов". И как следствие из этого, тесты должны быть очень маленькими и тестировать всёго один кейс. Таким образом, хоть это и код на который нету теста, он становится очень простым, понятным и минимизирует ошибки.
"взять и этот кусочек кода удалить"
Самый сок, когда для релизов ПО используется бранчевание по версиям, соответственно через несколько бранчей SVN в упор не видит эти самые изменения.
Просто привожу пример ситуации, когда комментирование кода вместо удаления - спасает. Я не в курсе как настроен сервер, так как я не RE, а они в свою очередь не будут менять конфигурацию, поэтому просьба об этом не писать.
Используйте гит
@@SeniorSoftwareVlogger , Вы представляете, сколько стоит в международной компании перевести все CI сервера, обучить разработчиков, сконвертировать GIT в SVN (чтобы коммиты были отдельными), и т.д. Это очень большая сумма денег. А ещё это очень большое количество человеко-часов
Чувак походу на разговорах зарабатывает больше чем на программировании, молодец. До 100к подписчиков доберешь так вообще кодить не понадобится :)
Я гляжу ты имеешь слабое представление о заработках на рутьюбе
@@SeniorSoftwareVlogger возможно, но по идее если будет много подписчиков то можно будет продавать рекламу общаясь напрямую с рекламодателями, вот там должны быть заработки
Ахахаха, это ты yubikey прищепкой назвал? :)
А на чём надо? На мыльницах с присоской и укреплённых плечиках для одежды?😂
Cпасибо узнал новое о spell shecker!
чем меньше времени у меня на выполнение задачи, тем больше я гавнокодер
Самое любимое, это когда весь код излишне сложен и нет никаких комментариев )))) А потом ты идешь к тому, кто это мракобесие написал и он пытается вспомнить как это работает 🤗👍
Экран макбука настолько четкий, что камера отказывается фокусироваться на лице владельца. Вот Эпл так Эпл!!!
@script с какой стати макбук это не макбук?
@script Открою секрет - там под экраном есть буковки, вот это и есть название устройства - MacBook Pro... хотя там и по тачпаду все понятно
Я чуть-чуть говнокодер
1. Плохая история коммитов, т.к. я коммичу обычно в тот момент, когда жалко потерять изменения. Логики при этом мало - все происходит достаточно спонтанно. Стараюсь придерживаться правила "атомарное изменение = коммит", но в реальном процессе это не так быстро привить себе и переучиться, как оказалось
2. Я не понимаю, зачем нужен prettier, если есть eslint. Кмк, они решают одну и ту же задачу, но eslint уже всем известен и понятен, а prettier просто еще одно решение.
Месяцем ранее был бы еще более говнокодер, очень помогло научиться думать перед тем, как писать код. Самое фиговое сразу кидаться стучать по кнопкам, сначала надо прикинуть, в том числе продумать корнер кейсы. Потом планирование (конкретно что и где меняем), и только потом код (когда точно знаешь что надо писать).
С плохой историей коммитов стал бороться через хуки гита. В репо есть прогоны тестов и линтера, но я себе заблочил возможность коммита, если линтеры не приведены в порядок. Это занимает 15 секунд, но коммитов стало в разы меньше, т.к. получилось избавиться от "lint fix", "flow errors fix", "another flow errors fix". Хз, мб поможет кому
Я программист, для меня все эти рекомендации очевидны
Писать код без комментариев? Нуууу, не знаю.
@@ОнуфрийНечепуренко Почему же без комментариев? Если приходится писать костыль или просто сложную штуку, то я оставляю комент. Но чаще всего мой код читабелен и без комментариев, потому что все переменные, функции и т.д. названы правильно
Для опытных очевидно - то да. Но навряд ли поможет в понимании для новичков без конкретных примеров кода на конкретном ЯП и проекте.
Написание кода и разбор его это как целое расследование шерлока холмса и доктора ватсона, иногда волосы шевелятся от того откуда что берётся куда что идёт зачем эта функция нужна, что она описывает, а потом вылет вылет вылет 🙏😁шикарный видос. 2 правила пиши чтобы разобрался даже ребёнок, 1 чем меньше написано тем лучше
Наконец-то знающий человек на ютюбе появился!
Отлично все расписал. Последний момент - это главное, что отличает говнокодера от хорошего разработчика. Тем, кто хочет перестать говнокодить, советую прочитать и перечитывать Clean Code by Robert Martin.
Боб разрабатывал байтомешалки на Clojure и Java, поэтому у него есть религиозные убеждения о unit-тестах как о серебряной пуле, что не никак не помогает, и даже вредит, например при разработке Android приложений.
а чем android-приложения отличаются? и как unit-тесты могут вредить?
@@nikitabobyshew7927 у unit-тестирования android-приложений есть такая особенность: приложение будет рассыпаться на части, а все unit-тесты ни разу не упадут. Зато дадут ложное чувство уверенности. Потому что тестируется не тот код, в котором будут ошибки.
- ну так надо тестировать там где возникают ошибки
- для этого нужны НЕ unit-тесты.
Интересен вопрос про тестирование. Хотелось бы глубже изучить этот момент.
Дядюшка Боб советует:
1. Test Driven Development by Kent Beck
2. xUnit Test Patterns Refactoring Test Code by Gerard Meszaros
3. Growing Object-Oriented Software, Guided by Tests by Steve Freeman
а что скажешь про савин "тестирование дот ком"?
У меня выдержен стиль говнокода, значит я програмист?
Стильный говнокодер
ахахаха😂👍
говномист)
@@SeniorSoftwareVlogger Не важно откуда растут руки, если они золотые.
Спасибо вам за интересные видео!
Спасибо, классная тема, подчеркнул для себя несколько моментов над которыми буду работать
Сделай что-нибудь с фокусом, пожалуйста. Напрягает глаза)
5:34 "Тесты это программа на которые нет тестов", несколько раз прослушал перед тем как понять)
это не так, на тесты есть автоматические тесты - так называемое мутационное тестирование, это проверка качества самих тестов.
С умной рожей восклицаю:
2:23 не версирование, а версионирование!
Кстати, Дмитрий, что думаешь по поводу вот этого: habr.com/company/infopulse/blog/345826/?
Спасибо за видос 👍
Отличный видос, спасибо
Прочитал коментарии и понял что большинство разработчиков не понимают насколько важны такие понятия как стиль, единые подходы, избегание излишней сложности, чистота и тд потому что не участвовали в действительно больших и продолжительных проектах. Да возможно когда ты делаешь проект, который в стадии активной разработки продлиться 3 месяца, после которых все на его забьют тут не важно насколько он чисто будет написан. Но, поверьте, если проект делается 5+ лет группой 50+ человек, то в случае игнорирования данных практик его разработка будет невероятно сложной, болезненной и демотивирующей. Но если следить за этим, уделять достаточное время дизайну и устранению технического долга, то и сложные системы могут быть достаточно внятными, прозрачными и понятными для изменений.
я не программист, а профессиональный гуглер и стиль кода для меня не существует
эй, гуру программирования, у тебя фейс не в фокусе
@@sawabigboy вся суть говнокодеров/трупрограммеров (не важно)
Хотелось бы услышать больше на тему софт скила (это скорее к твоему прошлому видео). Сильно ли влиял другой язык на работе на твой професиональный рост? Как с опытом развиваеться скилл? Какие умение (не технические) должны быть что бы можно было претендовать на роль такого себе мини тим лида))
У меня есть одно старое видео про софтскилы
Спасибо за материал!!! Было классно с вами поработать!!!)))
Видео очень правильное. Мне бы эта инфа очень пригодилась в начале карьерного пути
По поводу микро-коммитов не соглашусь. Когда вошёл в поток и активно делаешь изменения, особенно если они связаны с рефакторингом, это в итоге затрагивает большие куски кода. И если пытаться разделить эти изменения по смыслу и разбивать по коммитам, то уйдёт гораздо больше времени из-за того что будешь откладывать на будущие коммиты то что нужно сделать сейчас. Если же сделать кучу нужных изменений сразу, а затем пытаться разбить используя возможности системы контроля версий - это опять окажется болью, потому что изменения в одном и том же файле могут оказаться разными по смыслу... Поэтому всё зависит от процессов выстроенных в компании и темпа разработки. Если контроль качества имеет более высокий приоритет, тогда имеет смысл вести разработку медленно используя все возможности для того чтобы свести к минимуму незапланированные ошибки. В молодых же проектах вполне можно делать быстрые изменения и большие коммиты, которые включают в себя много разноплановых вещей.
Тебя не кто не заставляет комитить сразу. Я пишу в экстазе громадное количество строк и потом делаю много комитов :) Любой git клиент умеет partial commits. Идешь в файл помечаешь строки для комита в этом файле и комитишь ) Конвенцию для текста лучше брать с linux kernel репозитория: "action description"
Holms в моём случае это пустая трата времени. Хорошо если ты можешь себе это позволить...
А в чем тут несогласие, он вроде так и сказал: по возможности делать частые и мелкие коммиты но если изменения вдруг стали глобальные то делай большой коммит
в больших проектах делать большие коммиты, которые включают в себя много разноплановых вещей думаю будет не очень хорошей практикой так как со временем разработчикам придется со всем этим разбираться
Разногласие в том что он привёл это как аргумент того что микрокоммиты - показатель хорошего программиста. Хотя это не так. Джуна гораздо проще делать микрокоммиты потому что от него выхлоп меньше :)
Бля кодер это программист одиночка, главнре что бы работало и быстро. Программист это тот кто в компании других кодеров, красивый и рабочий код удобен для всех окружающих!
Это как судить по почерку рукописного текста о таланте писателя... Т.е. вообще мимо...
Почти всё о рюшечках в коде, бестпрактиз и подобных вещах не влияющих на функционал и качество самого кода. Только про чрезмерную сложность и тесты можно отнести действительно к программированию. На мой взгляд, говнокодер, это человек плохо понимающий что делает, чаще всего, скопипащенный им откуда-то, код (своего кода у них обычно мало). Мне, лично, по барабану на большинство опечаток, пропущенные отступы и подобный "стиль" - хорошо, если он есть, но говнокодером за отсутствие точно не назову. А вот когда одна бездумная копипаста другую погоняет и код можно сократить в несколько раз без потери функционала - вот это для меня и есть признаки говнокодера. Когда не используются возможности языка/библиотек упрощающие код. Когда программист не может придумать ничего своего, но очень следит в пул-реквестах за "стилем" тех, кто реально придумывает, выставляя тех говнокодерами за неправильные пробелы и опечатки. И очень жаль, что сейчас тенденция считать таких говнокодеров хорошими спецами только потому, что он делает всё, что описано в данном видео :(
Абсолютно в точку.
0:23 вообще я думал что под стилем ты имеешь ввиду именно стиль, а ты про форматирование.
а вот с 10:23 это уже ближе именно про стиль программирования.
PS: из самого простого, например индусы вполне могут писать - if ( boolvar == true ) then ... и т.п.
ну да и закрученные циклы, когда в JS можно использовать различные итераторы и т.п.
и пустые циклы) им платят за количество строк
@@БорисОстроумов-т7к , пустые циклы? )) Это индус 80го уровня ))
на самом деле ничего невероятно плохого в сравнении с true нет. Да, избыточно, но понятно и однозначно.
А вот сишные приколы типа while (!a++) прямо скажем, не лучшая идея.
К примеру если есть такое место в коде, где код запускается постоянно и много раз в секунду, + состоит из нескольких больших лупов, поэтому создание лишних функций добавляет оверхед, плюс нужно в каждой из маленьких функций заново рассчитывать локальные переменные, либо же передавать огромное количество переменных то в одну функцию, то в другую, что тоже плохо, поэтому у меня в том месте одна большая функция (~200 строк), это проблема? Тоесть я всёравно должен разбивать функцию на куски, даже если это пусть и незначительно, но всё же вредит производительности или нет?
Если язык компилируемый, то компилятор может эти функции инлайнить и все оверхеды пропадают
@@АндрейБурачковский-й1з не все методы инлайнятся
@@vodchiy нет не много, всего 1 место, в котором работает либо одна функция, либо другая, обе сильно огромные по 200-300 строк, я там всё довёл до микрооптимизации, разбивать не собираюсь, спасибо за ответ.
Спасибо за видео. Недавно смотрел одного зарубежного блогера, как оказалось - он русский, но при этом ведёт канал на английском. Основная причина - тонна негатива в комментах. Сейчас подобное замечаю и у вас, даже не знаю, почему в русскоязычном коммьюнити такая ситуация...
И еще вопрос: действительно ли необходимо такое количество коммитов? Мне кажется нехорошей ситуация с огромным количеством коммитов, я даже готов использовать некоторые инструменты для слияния коммитов.
А на английском негатива нету, ага
@@_4ado намного меньше, еще и зависит от того, кто на инглише пишет
@@alazarn7 Если ты так считаешь, то значит ты просто не знаешь английский лол
@@_4ado вот, русский сразу на личности перешел) ты живое доказательство
Есть только два типа программистов:
if(condition) {
//...
}
и
if(condition)
{
//...
}
Все остальное от лукавого. А теперь смотрим видео...
А ещё есть языки без фигурных скобочек
Единственно верный вариант:
if (condition) // (
{ // }
//...
} // {
@@fearmear Терпеть не могу k&r стиль скобок как до такого можно было дойти.
Спасибо за ценный материал, я только год как (сам обучаюсь), прям чувствую что это моё. И данный ролик помог осознать некоторые фундаментальные истины которые я считаю нужно закладывать с самого начала. Сложнее всего для меня это избавиться от привычки комментировать функции, я понимаю что в идеале стоит писать документацию описывающую взаимодействие и функционал, но у меня пока туго с абстрактным мышлением, и держать в голове понимание того как что работает, бывает очень трудно. В добавок к этому я крайне паршиво знаю английский, и совмещать изучения двух языков крайне трудно, по этому стараюсь давать названия переменным, функциям, классам, всегда на английском, зачастую приходится лазить в переводчик конечно)) а потом через пару дней тупить, что это за слово я тут написал) но в целом это помогает их запоминать.
Экспортные функции нужно комментировать.
Сам начинающий, в планах прочитать книжку clean code, чего и вам советую.
@@Trecoolerok точно, прочитать и никогда не использовать этот бред.
Не нужно комментировать каждую функцию. Это только засоряет код пустопорожним текстом. Если в проекте это требуют, значит, проект - суть освоение ИТ-бюджета, и из него надо валить в приличное место, пока тебе голову не загадили так же, как они загаживают код.
Поделись методикой как ты изучаешь Что_То_Новое . Какие техники изучения и запоминания ты используешь ?
ищи видео "стратегии самообучения"
Можешь посоветовать хороший материал по стилю и структуре кода, или это все с опытом приходит?
1) Ни слова не сказал про архитектуру
2) Нулевой взгляд на экономическую составляющую. Иногда может быть дешевле 3 раза сделать приложение заново, только для того чтоб внести маленькое изменение, но это приложение будет стоить по 100 долларов от индуса-говнокодера. Чем один раз заказать приложение у студии за 4000 долларов, где всё будет покрыто тестами и легко модифицироваться. Или другой пример: иногда дешевле снять дополнительный сервер, чем потратить месяц работы дорогостоящего программиста, который будет оптимизировать приложение. Нужно в деньгах всё это взвешивать, а не в "говнокодер vs программист"
Alex Alex думаю речь шла о том, что уже принято решение программировать однозначно. Нанят программист. И вот тут то и нужно это все чтоб стать лучше как программист. А так конечно если зацикливаться о тех вопросах, которые вы пишите, можно вообще ничего не делать.
@@joma0305
Ни о чём таком речь не шла. Не нужно додумывать. Я много раз видел как в видео человек говорит "белое это белое", и тут же три ветки комментов: одна пишет "автор, не правда, белое это черное", вторая пишет "автор, не правда, белое это белое", а третья "я тоже против негров".
Всё что не было в видео - это лишь ваша фантазия, умноженная на ваши триггеры. Того, кто изучает кулинарное дело, увидит в сообщении автора призыв к употреблению смузи. Кто-то тут увидит политику, не зависимо от темы видео. Кто-то подумает что автор говорит про кастовую систему и пытается его унизить, сверкая своим статусом. Кто-то подумает что это реклама ноутбука и будет убеждать что макбук всё равно лучше. И каждый будет на своей волне.
Большинство из этих людей уже хотели что-то написать на какую-то определенную тему, ещё задолго до случайной находки этого видео. Они просто умножили то что они хотели сказать на предмет самого видео. К примеру, я уже знал что хочу написать про экономический вопрос, просто увидев слово "программист", ещё до того как я полностью прочитал название видео и увидел там слово "говнокодер" и ещё до того как я посмотрел видео. Если бы в видео автор сказал что-то вроде "тема это кликбейт, на самом деле я хотел бы обсудить автомобили", я бы всё равно как-то модифицировал экономическую составляющую, перенеся её на работников завода автомобильной промышленности и их менеджеров.
Люди заходят на ютуб не чтоб узнать чужое мнение, а чтоб написать своё. Вот и всё.
@@AlexAlex-rc9di есть только два мнения. Субъективное и мое...
Про 2 пункт люто плюсую! Рассмотрены идеальные условия, про реальность в 90% случаях ни слова, к сожалению.
Архитектуру (типовую) ему архитекторы сверху спускают без права апелляции. Ему остаётся только накопипастить типового кода в контроллеры, адаптеры, дата-объекты и прочее. Понятно, что если такой код взять в чистом виде, получится мало и несерьёзно. А не сумеешь объяснить, за что тут заказчиком уплачено 50 миллионов, - вылетишь с работы. Вот так и рождаются всякого рода "клинкоды", шапки комментариев над каждой тривиальной функцией, и тонны юнит-тестов на сеттеры и геттеры. Они просто помогают никчёмному и ненужному приложению выглядеть, как взрослое. Так что автор, осознанно или неосознанно, взвешивает в деньгах, но взвешивание - специфичное для ниши.
Спасибо большое за информацию🙋
Но неизменность теста, т.е. его слабая связанность с особенностями реализации кода, может также означать недостаточный контроль кода. Может оказаться, что мы просто мало что тестируем; тестируем какие-то очевидные вещи. Можно ведь написать тест, который не будет зависеть от кода, но также и не будет зависеть от ошибок в нём. :)
Пишем маленькие чистые функции и нет таких проблем
Дмитрий, а это правда, что Вы фанат функционального программирования?
Я фанат рационального программирования :)
А архитектуры и паттерны???
Как начинающий 💩 кодер скажу- спасибо за видео👍✊️
Ох уж эти жаваскрипт разработчики и вайтишники.
Ох уж эти комментаторы с 1 подписчиком и видео про правый сектор 🙃
@@Dimarious.G flawless victory
Я не уверен ESLInt ли работает для TypeScript, но очень часто когда с ним работаю на AngularTS он раздражает. Начинает переносить аргументы для вызова метода на новую строчку даже если по сути имя аргумента было небольшое, в итоге файл порой превращается в эту узкую башню, в которой вызов функции растянут на 4-5 строк.
С каких пор Киану Ривз на русском говорит?
Что с фокусом камеры? у меня глаза заболели
Мне лично далеко до профи или сеньера...но, все же, выскажу свое возражение. Мне кажется, что бОльшая часть придирок из видео в стиле граммар наци. Опечатки, комментарии, описание коммитов..понятно, что хороший программист обязан соблюдать нормальный нейминг и не злоупотреблять вложенностью и тп. Но, все же, программист должен уметь делать хороший уровень абстракций, должен следить за зависимостями, должен использовать паттерны проектирования и вообще хорошие практитики..а доебываться (простите за грубость) до грамматики в переменных или что код иногда выбивается из стройного стиля, не сказав ни слова о действительно важных для профи вещах, это как-то странно. Если об этом где-то сказали, а я , по неопытности, просто не понял - прошу прощения.
Silver Shadow ну вот и видно, что тебе далеко от профи. Предположу что автор описывал правила для тех кто работает от нуля до двух лет и эти правила в работе с командой куда важнее чем знание паттернов, которые с легкостью могут стать антипаттереами. Новичкам никто не будет давать писать архитектуру и как правило она продумывается командой, а не одним человеком и большая часть работы кодера заключается в том, что бы написать маленький функционал или исправить багу - по сути сделать маленькую прогу внутри большой где ты будешь пользоваться уже существующими абстракциями и архитектурой
Не совсем понятно, зачем было дополнительно язвить и принижать, если я открыто признался, что являюсь относительно новичком...это сразу ставит под сомнение адекватность вашего дальнейшего ответа. Тем не менее спасибо за ответ, вы разъяснили мне позицию автора.
Команды бывают разного размера чем меньше команда, тем шире зона отвтетсвенности и больше кода надо проектрировать самостоятельно, а на фриалнсе и вовсе часто работает один человек. И все же, оформление кода, так что бы он был удобен для команды != профи программирование. Я не отрицаю важность сказаного, и про антипаттерны, естественно, согласен. Просто не буду же я трактат со всеми подробностями писать на 4 листа в комментах...я лично( и некоторые более опытные единомышленники) фундаментально разделяю говнокодерство и плохое оформление. Если говорить по видиео, то к говнокодерству, например, относится высокий уровень вложенности. Точно так же же я отношу к нему отсутвие или неадекватное использование абстракций( делает код немасшатабируемым), я понял, что лично вы абстракции не пишите, а только рабтаете с готовым, но абстракции возможны и неболшой проге, так что вы задумайтесь ( хотя я и не уверен, практикуется ли такое в JS, но обращение было не к вебразработчикам). Отсуствие тестов там же, хотя следуя вашей логике отсутсвие тестов нельзя относить к говнокодерству, ведь в компании же есть отдельные люди Тестировщики, чья работа писать их.
В общем, всегда приятно получить корректировку от более опытного специалиста, и я не хочу с вами спорить, потому что для вашей сферы и рода дейтельности вы очевидно правы. Я просто хотел очертить более широкую позицию. И разделить говнокодерство и плохое оформление, как два различных греха и степень тяжести у них различная.
Silver Shadow моей целью не было принизить или оскорбить. Прошу прощения если мой коммент вызвал негативные эмоции.
@@ievgenk.8991 Месье, ручаюсь, он соблаговолит отпустить вам ваше окаянство
@@silvershadow13 Я не знаю, буду ли я в твоих глаза считаться опытным программистом, но я работаю тимлидом и руковожу командой из 9 человек. Автор видео затронул базовые проблемы из-за которых возникает множество проблем с коммуникацией. Какие бы ты там "хорошие уровни" абстракций не писал и как бы ты хорошо не следил за зависимостями, но если у тебя коммиты не выстроены логически и в каждом коммите по 40+ файлов изменены, то с тобой работать будет некомфортно и тебя заставят переучиться. Нравится тебе это или нет. Если ты пишешь с грамматическими ошибками, то на код ревью тебя заставят их исправить. Нравится тебе это или нет. А оформление кода вообще невероятно важно, так как отсматривать кучу файлов, написанных в одном стиле куда быстрее, чем отсматривать кучу файлов, написанных в разном стиле. Да и вообще, глаз привыкает к стилю и поэтому некомфортно работать, когда кто-то выбивается из стиля. И это никак не отменяет того, что ты должен использовать паттерны (когда это нужно), следить за зависимостями и тд. Ты вообще пишешь про другое. Ты пишешь вообще про абстрактные знания, которыми вообще любой должен обладать. И если человек не умеет паттернами пользоваться, то о чём с ним дальше разговаривать? Это всё уже давно само собой разумеющееся и тебя никакая нормальная команда ждать не будет, если у тебя таких знаний нет. Это базовые вещи.
Было бы круто, если бы вы показали пару примеров говнокода из реальных проектов)
Было бы круто найти пару примеров реальных проектов БЕЗ говнокода!
@@SeniorSoftwareVlogger ну вы ведь вроде как пишите без него, так что проблемы не вижу. Сравните свои работы и аналогичные чужие. Будет интересно
я в профессии 10 лет но до сих пор говнокодер
Jenya Space каждый год клипают ролики о говнокоде))) кажись это заговор разработчиков языков программирования
я 15 лет говнокодю, зарабатываю 15к$
Сочувствую тем, кто работает с тобой
По поводу коменарий. А как насчет JsDock? В этом случае нормально писать очевидные коментарии ради генерации документации?
Как по мне это жесть. Тут что важнее экономить на документации или писать читаемый код.
камера считает стену более интересной чем ты(
Насчет юнит-тестов не совсем согласен. Возможно я не так понял высказывание, но тест не всегде должен переживать рефакторинг. Вот пример : у вас есть мок на метод, в ассерт части вы чекаете сколько раз замоченный метод вызывается, скажем, это был репозиторий, который вычитывает данные из таблицы имя и фамилию. Какой-то интерн\джун\вы в прошлом написал так, что значение вычитывалось несколько раз, и вы успешно это заюниттестили. После того, как у вас БД на проде загружена на 146% вы обнаруживаете, что этот код должен быть отрефакторен так, что бы метод вызывался один раз. Вам нужно менять тесты! Не бойтесь проверять в тесте количество вызовов метода или еще что-нибудь фажное в угоду будущему рефакторингу, не подставляйте себя! :) Может быть пример не очень корректный, но суть вы, надеюсь, поняли. Юнит тесты должны быть как ваша математичка, строгие, но справедливые! =D
После обнаружения множественной загрузки одних и тех же данных из БД возникают серьёзные вопросы к авторам кода. Ведь нагрузочные требования должны были быть в проектной документации. А если их там не было, то почему взялись за разработку незнамо чего? Так что какой там рефакторинг, тут профессиональное несоответствие в полный рост. Но я скажу, почему в большинстве случаев такие вопросы не задаются. Потому что сам проект не нужен, открывается только ради освоения бюджета на автоматизацию и поставить галочки: "бизнес в этом году автоматизирован на 87.5%". И в таких проектах - как раз хорошо, что БД загружена на 146%, т.к. это помогает пускать пыль в глаза: вот какая нужная приложенька, и сколько сложных вычислений она делает. А давайте закупим ещё 20 серверов и с них тоже снимем себе откатов.
@@InconspicuousChap ого некропост)) но да, вы же робот и пишете идеально продуманный код. А условие в конце, что пример не корректный служит лишь для иллюстрации, вы, почему то пропустили не как робот, а как человек.
@@MayDay-g4k Ну да, в понятиях ЕГЭшных поколений я робот. Я знаю, что я делаю, когда пишу код. Так же, как и люди, у которых я учился, вся старая школа знала, что делала, когда писала код. И зачем писала (кто пользователи, каков эффект) - тоже знала. И у буржуев так же: Дэйв Катлер, Линус Торвальдс, Джон Маккарти, Никлаус Вирт, Кен Томпсон и другие - все формировали постановку задачи, а потом проектировали решение перед тем, как кодить. Это вы только лепите, сами не зная, что и зачем. И получается у вас 100% говнокод, как его ни отформатируй и каких юнит тестов ни понапиши. И работа у вас есть исключительно в части распильных никому, кроме откатчиков, не нужных проектов, поэтому всем по барабану на полуработающие решения.
@@InconspicuousChap апелляция к авторитетам и к возрасту. Ну дальше и разговаривать не о чем, это просто узколобость. :)
@@MayDay-g4k Узколобость или нет, но к счастью, софтостроение - дело такое. Или взлетит, или нет. Так что шлёпай свои формы дальше, "продвинутый" и "современный" ты наш. И знай своё место формошлёпа. Ты будешь его занимать, пока не научишься уважать старших.
Можно поподробнее про стиль? Это какое-то общее между использованием выбранной нотации ( например camelCase, snake_case), стандартов языка (например PEP8 для Python) и использованием возможностей языка (функциональщина, enumerate и т.д.) или это нечто более сложное, уникальное, идущее от конкретного человека?
Все вместе.
Ох уж этот шальной фокус
Видео понравилось. Подробности по каждому пункту можно погуглить при желании. Взял на заметку разбивку больших коммитов на более мелкие, атомарные.
Часто говорят, типа, в моей компании сжатые сроки, мы не пишем тестов, нет общих правил и стиля написания кода, нам не до статических анализаторов, у нас постоянно гарь... Профессионализм - это ещё и умение выбирать компанию и проект для работы. Зачем лезть в гарь, когда можно работать в компании с нормальным планированием и качественными процессами? Где говнокод тебе не навязывают, а отучают от него!
Напомните пожалуйста рецепт для того что бы засыпать быстро?
Ложиться и вставать строго в одно и то же время. Никакого экрана за пол часа до сна 👍
@@SeniorSoftwareVlogger где то видел рецепт у Вас яблочный уксус и что то ещё - не могу найти это видео. Т.к. испытываю проблемы со сном с засыпанием и просыпаюсь ночью часто. По поводу экрана и яркого света это связано с выработкой мелотанина - которая подавляется(таблетки есть) - думаю что моя трабла не в этом
Яблочный уксус с медом может повредить эмаль зубов и пищ тракт. Погугли apple cider vinegar sleep.
300мг 5% экстракта ашваганды перед сном
Показал бы сам код... был бы лайк!
Ага, щас
Какой линтовщик для python посоветуете?
pylint
Я думаю в PyCharm'e все уже стоит, что надо
Надо программыровать камеру что бы автофокус хорошо работал. А Так нормально...
Я до просмотра этого видео думал что говнокод - это код, который растянут, сложен, и то что можно было написать за строчек 10 в итоге написан на 100 (по сути последний твой пункт), но было перечисленно столько пунктов, которые даже к кодингу особого отношения не имеют и их можно пофиксить за пару дней, а вот в этом пункте ты сам сказал что иногда приходится использовать сложный код, вложенные циклы, условия в них. Иногда у меня возникает вопрос, я пишу говнокод или это вынужденная мера? это можно как-то выявить и пофиксить?
никак это не узнать. Зовешь другого твоего же уровня и пускай разбирается, если спотыкается значит говнокод, это единственный вариант. Можно еще читать собственный год написанный давно, если спотыкаешься, то говнокод.
Про комментарии - не согласен. Например, в бизнес-логике без комментариев не разберешься почему надо так, а не иначе.
Он говорит, что не нужны в очевидных местах комменты
@@VORASTRA нет, он не это говорит, а то, что если к коду требуются комментарии, то, значит, код написан плохо. Слишком радикальная позиция, как мне кажется.
Чекни книгу Чистый код. Там есть отдельная глава про комментарии
есть особи которые вообще коментов не пишут. как бывший прогер в фирме где я пока что оаботаю.
за такое следует топить при рождении!!
@@pumbo_nv всё ты правильно говоришь. Фраза "если коду требуются комментарии, то значит код написан плохо" - это фраза обычных теоретиков, которые к реальному программированию отношения не имеют и программируют в книгах задачи, которые в конце главы расположены))) Я в программировании уже около 10 лет и я прошел через огромное число проектов и работаю тим лидом на данный момент. И я могу со 100% уверенностью сказать, что код без комментариев - это просто ублюдство, так как сразу видно, что писал какой то человек, который думает только о себе и не думает, что его код будет смотреть другие. И реальность такова, что есть полно сложных вещей, которые приходится делать. Алгоритмически сложных вещей и сложную логику. Само собой, глупо писать комментарии в очевидных местах. И ровно так же глупо НЕ писать комментарии там, где они реально нужны. Какой бы не был красивый код, если сама функциональность сложная, то гораздо проще будет понять код, который написан с комментариями.
Камера ужасно прыгает фокусом! Обрати внимание на этом в будущем!
А чем кодер отличается от говнокодера?
говна больше :)
Мы с коммитами сделали иначе. все задачи были через трелло. А в коммит писали хеш из ссылки на таск + инфа.
Еще очень важная штука это отличать символы Юникода. Например ни одна IDE (VS, VSCode) не поняла разницы между русской С "с" и англицкой Ц "с" а вот гитлаб в мердж реквест е смог. Когда вы используете IDE для команды монолита - все ОК. Но когда у вас Pyhton, NodeJS, C# на микросервисах - все становистся критичным адсци, на эту ошибки ушло три дня ресерча и 5 минут моего ревью в GitLab реквсета, который уже был слит.
Рекомендую запретить все языки вкроме английского в коде!!!
вчера наткнулся на классную фичу. В файлах переводов один из разработчиков написал 2 ключа, в виде "MY_SPECIAL_KEY" и "MY_SPEСIAL_KEY".
Как получилось 2 одинаковых ключа? Все просто, во втором случае используется русская буква "С"
webstorm отличает, показывает как опечатку. К сожалению, vscode расхайплен и бесплатный, но очень сильно уступает по функционалу webstorm
А что лучше веловипед или зависимость ради зависимости?
Программист отличается от говнокодера только тем, что его код отлажен, протестирован и оптимизирован. Остальное все задротство. А форматировние кода в любом редакторе сейчас одной комбинацией клавиш делается.
Александр М Только почему-то не все пользуются этой одной комбинацией...
Редакторы нейминг не исправляют
Да и только форматирует не всегда так нужно/хочется.
А каждый раз настраивать под себя - харит.
@@drovoseg В python PyCharm подсказывает,подсказывает вариант там по PEP но это иногда выводит из себя.
@@avazart614 в нем нет искусственного интеллекта который бы подбирал наиболее понятное название в соответствии с предметной областью
Камера держала фокус на стенке, а не на лице.
Откуда советы? Пахнет книгой: "Чистый код"...
Из личного опыта. Книгу не читал, но одобряю.
Senior Software Vlogger Как вы можете одобрять книгу, если вы её не читали, расскажите, пожалуйста?
Книгу упомянули раза 3-4 под этим видео с отсылкой на то, что советы похожие. Если это действительно так, то одобряю конечно. Опять же авторитетные для меня люди ее читали и рекомендовали. Достаточно?
Senior Software Vlogger да, спасибо за ответ
8:48 такие моменты нужно делать чёрно-белым.
ага и чтобы типа рамочка как будто экран видеокамеры, да?
И еще надпись сделать в уголочке "Fail cam".)
Спасибо, все как есть.
Тебе не в программисты надо а в филологи. Один трёп.Где примеры то?
работаю в силиконовой долине, 80% окружающих меня людей не придерживаются стиля, как и я. Просто пусть все знают, что у компании ***z*n программисты гавнокодеры)
Успехов тебе,
Senior программист.
Спасибо! Интересно узнать, что столько говнокодеров в Амазоне. Где берете? Специальный вопрос на собеседовании есть?
я думаю этим хвастаться не стоит) Даже если ты крутой чувак! Это как есть руками в ресторане только потому что ты можешь это себе позволить)
В python идыешка pycharm все подсвечует ) но говнокодить приходится, скорее всего из-за нехватки опыта) я получаю удовольствия от того что пишу код, но моя нынешняя профессия мне не нравится, хочу стать кодером, надеюсь когдато кто-то возьмет меня каким-то интерном или джуном... смотрю видео автора, для мотивации =) Спасибо тебе!
Как успехи?) Получилось сменить профессию?
@@AlexNatkin нет
@@lolbefree а цель осталась или передумал?
@@AlexNatkin я пишу каждый день, что-то новое, завел git, но мне приходится работать сисадмином(принтера, сервера, сервисы) и параллельно кодить для этой же компании, за премии
@@lolbefree ну это отлично! молодец!) на python'e пишешь?
Краткий пересказ Чистого кода
Правда? А то я не читал
отчасти, там обсуждаемных тем побольше (SRP, обработка ошибок, TDD), но в целом, да
@@SeniorSoftwareVlogger так в чём же дело? Прочти и сравни
это вы в 1С не работали... там есть стандарт для разработчиков, а сами программы от "1С" этим стандартам не соответствуют )))))))))))))
Когда говорили про комментарии, то как будто пересказывали главу с книги "Чистый Код"
он web developer
Iurie Cojocari хорошо, спасибо за информацию))
Это плохо?
Dmitry не хорошо и не плохо. Это просто на заметку другим, если хотят узнать чуточку больше обо всём том, что в ролике.
Ну и автору на заметочку, конечно же, куда без этого?! :)
Насчет тестов не все так плохо - те же пхпшные тесты можно проверить с помощью infection и почти уверен что для других тестовых фреймворков должен быть инструментарий для мутационного тестирования. Естественно MSI - не истина в последней инстанции, но все же дает представление насчет корректности написанных тестов
Дима, спасибо, хорошее видео. Могу подсказать кучу Python штучек, большинство встроено в IDE Eric, free. Линтер, сложность, refactoring rope/
Снобизм одноклеточных
всегда в комментариях к классу или методу пишу для чего он предназначен, что возвращает и описываю переменные и их типы. получается я говнокодер по новым веяниям поколения ноде-джс ?
По разному. Вообще, любые комментарии - это скорее плохо чем хорошо. Но к функциям терпимо (хотя я не пишу), если они сложные, тяжело ясно назвать (например, в сложных алгоритмах), чтобы не смотреть в тело. А еще неплохо, если они в каком-то специальном формате, который может читать редактор и делать потом подсказки.
Вообще, всё что улучшает понятность, всё это хорошо. Но с комментариями часто такая штука, что если они нужны, значит код говно, по нему не понятно, что он делает. Или слишком сложный оправдано, но непонятно что делает. Так вот, комментарии + непонятный код, это может быть сложнее, чем просто код. Ведь вы увеличили количество информации, это точно сложнее. А еще часто комментарии могут нагло врать. Код чаще меняется, может даже средствами автоматического рефакторинга. Где-то из другого места изменили имя переменной, функции, и комментарий устарел.
В общем, желательно, чтобы код читался, как книга. Буквально повествовательно, декларативно. По возможности. Имхо, даже намного важнее локальная читаемость кода, чем какая-то общая архитектура кода.
Но, описывать функции, это олдскул, не так и плохо. Но, согласен с автором, комментарии - это то, к чему не надо стремиться. Я их пишу, когда уже сдаюсь. Когда уже соглашаюсь, что я недостаточно хорош, чтобы выразить это кодом понятно.
Вообще в ролике про говнокодеров ничего в общем-то не сказано, несмотря на название. Говнокодить можно и с гитом, и писать прекрасный код можно без гита.
дело не в наличии, а в сути коментов, если вам так нравится дело вкуса, но если это необходимость без которой код никто не разберет стоит задуматся
если комениы вроде "не уберайте эту переменную иначе гдето сломается" пора задуматся о смене професии
Во, во. Сейчас веду проект под STM32, в штатных либах там комменты по десять строк к каждой функции. Это что ж получается, в компании запилившей ставший стандартом де-факто микроконтроллер одни говнокодеры что ли работают?
Большое количество комментов ухудшает читаемость самого кода, да и далеко не каждый программист умеет хорошо писать документацию к собственному коду. Комментировать имеет смысл только очень оригинальный код, который сложно работает и не является типовым, в плане выполняемой задачи. Да и то, скорее всего, это просто хреново написанный код.
Комменты хороши для каких-то сложных инструментов, или когда реализация скрыта. В противном случае достаточно делать коммент к сложному методу или классу, если его функция не выходит из его названия.
Дядюшка Боб существенно помолодел и отпустил бороду и усы:)
еще переехал в Германию и начал писать на javascript)
а на чем раньше писал ?
глянь тут github.com/unclebob?tab=repositories
Что с фокусом камеры?
Баг, репорть в джиру, пофиксят в следующем релизе
2:52
во-первых я таки будучи простым сисадминским скриптером до сих пор подхожу под определение программиста :)
во-вторых это больше к умению излагать мысли, чем к программированию. Соответственно во-время собеседования возможно имеет смысл не только дать человеку написать кусок кода, но и попросить написать диалог/зарисовку/рассказ. Заодно и умение нестандартно мыслить проверится.
Спасибо. Пойду дальше писать код на латыни
где то фокус потерял
Киану хуйни не скажет
Все херня. Если делать все методично, по полочкам, с тестами, коммитами, трекерами и прочей моральной мастурбацией, то вы никогда не запустите свой сраный проект. И уже нахрен никому не будут нужны ваши коммиты, тесты и читаемость. А вот если вы в одиночку способны наговнокодить за пару дней работающий продукт, то вы реальный маньяк, и не слушайте никого. Людям сейчас просто нечем заниматься, вот и выдумавают всякие эджайлы, кодревью, тдд, метрики, трекеры и прочую лабуду. Ибо херачить код мало кто жаждет, а кушать и руководить хотят все.
В одиночку наговнокодил проект и пусть потом остальные в этих дебрях разбираются - это уже их проблемы. Главное, что у них есть такой красавчик, умеющий валить в одиночку, кладя на всех вокруг.
@@re1neke_f0x тут автор имел в виду свой проект на одного человека, на кого он клал?
@@re1neke_f0x ну да, а чем еще заниматься, пока остальные обсуждают задачу, анализируют методы решения, открывают запись в трекере, пишут две строчки кода, тестируют их, документируют, ревьюят, рефакторят коммитят, билдят, проводят интеграционное и нагрузочное тестирование, а затем размазывают во всех пабликах как они круто и методично справились с поставленной задачей. Если в команде нет красавчика, все ресурсы быстро съедает бюрократия. Любой реально работающий проект начинался с говнокода.
Интересно, почему такие спецы как ты все еще не лидируют в индустрии. Хм, возможно потому, что твой говнокод нахер никому не сдался в крупных проектах? Попробуй написать что-то подобное с претензией на лучший код для, скажем логистической индустрии, и ты будешь отправлен в свободное плавание.
Хотя… вы, ребят, продолжайте мнить себя экспертами. Так конкуренции меньше.
@@AlexiosLair именно такие спецы и лидируют в индустрии, но у них нет времени п-ть на конференциях и по пабликам, поэтому их и не особо заметно. Ваши "крупные проекты" после активной фазы разработки -- это 90% неподдерживаемого легаси, тонны устаревшей никому не впившейся документации и куча самопальных велосипедов прикрученых сбоку, которое еще и билдится через раз. Откуда такое берется, ведь все же разрабатывали правильно и методично? Ну и по поводу говнокода: любой код есть по определению говно, как бы правильно он ни был написан. Ибо здоровый спец всегда критичен к результатам своей работы. И если однажды вы посчитали, что высрали розу, значит ваша эволюция как спеца завершена -- можете идти в менеджеры.