0:23 Стиль написания кода. Инструменты его выработки , линтовщик. 2:15 Коммиты. Сообщение до коммита. !"а так же". 4:26 Тесты. Тест переживатет рефакторинг. No test for test. 5:50 Опечатки. SpellChecker. 6:34 Комментарии. 8:40 Мёртвый код. 10:23 Излишняя сложность.

@avejantzero9090

5 жыл бұрын

Спасибо!

@somestrangeperson

5 жыл бұрын

Спасибо!

@DrovitoBrazzi

5 жыл бұрын

отвечу тут, тк заспамили видос, а тут больше вероятность дискуссии с автором. тесты - тоже могут тестироваться, это называется мутационным тестированием. и в целом по поводу тестов, они не всегда уместны. допустим когда делается Proof of Concept, с заранее неизвестным ТЗ. то есть есть некоторое желаемое приложение с базовым набором функциональности, но источник данных/протокол/модель данных заранее не известны и изучать приходится методом проб и ошибок. в таком случае покрывать бизнес-логику тестами нет никакого смысла, тк все очень волатильно. Более того в таких случаях иногда и нет смысла делать нормальную декомпозицию кода, до момента когда функциональность проекта не будет заморожена и уже тогда можно приступать к рефакторингу и покрытию тестами (это про еще и про то, что test first конечно прекрасная идея, но в реальном мире не всегда работающая)

@SeniorSoftwareVlogger

5 жыл бұрын

Лучше в личку на патреоне.

@Soprachev

5 жыл бұрын

name eman ф

За 14 лет в професси, я для себя вынес пару очень простых правил, которых стараюсь придерживаться: 1) Кода должны быть как можно меньше. 2) Код должен быть как можно более простым. Все остальное, вытекает из этих двух принципов: 3) Код должен легко читаться. Любой джуниор должен без проблем сесть и быстро разабраться, как и что ваш код делает. 4) Код должен легко поддаваться модификации. Если вы сделали архитектуру, а потом, спустя время, от вас потребовали внедрить новую фичу и вы видите, что архитектура этого не позволяет - значит ваша архитектура - говно. 5) Код должен быть максимально модульным и пригодным к юнит-тестированию. Как-то так.

@yurim7756

5 жыл бұрын

Ага, но вот, деталь одну не раскрыли. Что значит легко поддаваться модификации? Я, например, считаю, что код должен быть ПРОСТЫМ и ЖЕСТКИМ, а не гибким. Т.е. код должен быть как можно проще и достаточно жестким, чтобы выполнялись требования. И ни в коем случае не закладывается преждевременная гибкость. А простота модификации достигается с помощью DRY. Любое утверждение в коде должно встречаться раз. Т.е. код не на шарнирах, а когда меняется какое-то требование, надо найти ту косточку и ее сломать. Т.е. простота в приоритете перед гибкостью. 15 лет в профессии. YAGNI, DRY, KISS

@konst3d

5 жыл бұрын

​@@yurim7756Да, это главные принципы для создания хорошей, гибкой архитектуры. Опытный программист пишет минимальный, работающий код, и потом, в случае необходимости, добавляет\изменяет фичу добавив и изменив пару\тройку файлов. Джуниор как правило, тратит кучу времени на создание гибкой, как ему кажется системы, с кучей интерфейсов и шаблонов и потом, когда действительно нужно добавлять\изменять фичу, выясняется, что именно этот случай, он и не предусмотрел. :) И в итоге опять тратится куча времени на переделывание архитектуры, на добавление новых интерфейсов и взаимосвязей - дабытеперь уже система стала на 100% гибкой. :) Нужно ли говорить, что следующая новая фича, скорее всего опять не впишется в старую абстракцию? :) Так что - да, я тоже за гибкость через простоту и жесткость.

@yurim7756

5 жыл бұрын

@@konst3d Ну да. Преждевременная гибкость, это как правило гибкость только в предугаданных направлениях, но чрезмерная жесткость в неугаданных. В результате, если требования как-то пошли не так, джуниоры обижаются на заказчика, потому что тот сразу не сказал, что так может быть )) Или, если гибкость слишком большая, то это в ущерб статической типизации. Т.е. вроде код и гибкий, но место для счастливой и беззаботной жизни багов. Гибкость по-сути - антипод правильности. В первую очередь код должен заботиться о правильности выполнения требований. А гибкость - проблема индейская. Но к сожалению, большинство программистов именно с нее начинают. Поэтому: простота, декларативность (по возможности), в коде должны читаться требования, а не алгоритмы. И я бы выделил локальную читаемость. Большинство программистов стараются создать архитектуру, которую видно с птичьего полета. А как по мне, главнее, чтобы открыл любой файл с кодом, и чтобы он читался ну как повествовательная книга.

Я понял, это Киану Ривз, который выбрал синюю таблетку)

@SeniorSoftwareVlogger

5 жыл бұрын

Развитие темы пошло 👍

Ура, под всем подписываюсь, большое спасибо за видео, его можно использовать для объяснения этих идей :)

Спасибо вам за интересные видео!

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

Спасибо большое за информацию🙋

Согласна со всеми пунктами из видео. Такой подход действительно очень помогает держать код в порядке, другим разработчикам легче работать с таким кодом (а это важно, когда проект делается в команде). Также такой подход сильно упрощает поддержку (потому что через полгода ты ни за что не вспомнишь, зачем комментировал три строчки тут и еще вон ту переменную в другом классе). Хочу также дополнить, что есть прекрасная книга Clean Coder, где в деталях и с примерами из жизни рассказано, почему все вышеперечисленное хорошо и для проекта, и для разработчика.

Воу, вот такого видео реально не хватало!

Видео очень правильное. Мне бы эта инфа очень пригодилась в начале карьерного пути

Очень круто! О правилах хорошего кода за 13 с половиной минут. Спасибо!:)

Cпасибо узнал новое о spell shecker!

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

@griel80

4 жыл бұрын

Если честно, перечитывая даже свой код спустя какое-то время комментарии не очень уж сильно помогали разобраться. Я по своим проектам наблюдаю следующую динамику: уменьшение количества комментариев и увеличение количества UML-диаграм. Когда видишь какое место функция или компонент занимают в программе, как они используются и видишь это графически и наглядно, анализ кода становится куда более посильной задачей.

@delir0

2 жыл бұрын

Комментарии для очевидного кода - это дублирование этого же кода на другом языке (обычно английском), то есть, бесполезная трата времени на написание и бесполезная трата времени на чтение (особенно передаю привет сидящим на макбуках 13 дюймов). Если же комментарий для неочевидного кода, значит код стоит переписать чтобы он стал очевидным, что переносит нас на первый пункт. И есть лишь небольшая доля кода, который действительно стоит комментировать, потому что его невозможно написать более очевидно. Но во всех этих случаях комментарий должен отвечать не на вопрос "что делает этот код?", а на вопрос "нафига он это делает?"

@alexandranesterenko

Жыл бұрын

Очень круто, спасибо!

@InconspicuousChap

3 ай бұрын

Смотря, что делает этот код. Когда смотрим сложный алгоритм (например, в сишных библиотеках Питона), то пространные шапки комментариев очень помогают схватить основную идею. А кода формошлёп пишет над каждым методом своей CRUD-приложеньки шапку с подробным однотипным описанием параметров, потому что так положено, это - просто засорение кода. Но оно требуется, потому что разработчикам CRUD-приложений платят фактически за строки кода: они должны разработать ненужную по сути вещь, но она должна выглядеть, как настоящая, а цель этой разработки - освоение ИТ-бюджета менеджерами.

Спасибо за видос 👍

Отличный видос, спасибо

Такое ощущение, что 80% комментирующих решили написать "не согласен, автор не прав" еще до того, как начали смотреть видео. Да, с примерами было бы лучше, фокус камеры и звук можно улучшить, но меня это не напрягло, материал менее ценным от этого не стал. Я с 12 годами опыта почерпнул интеренсные детали. Спасибо.

Спасибо за материал!!! Было классно с вами поработать!!!)))

Интересен вопрос про тестирование. Хотелось бы глубже изучить этот момент.

@vladislavrazgonyaev4428

5 жыл бұрын

Дядюшка Боб советует: 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

@vanzo16

5 жыл бұрын

а что скажешь про савин "тестирование дот ком"?

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

как говаривал один из преподавателей, "я должен ваш код(Java) читать как художественную литературу, не напрягаясь, не отгадывая что откуда и зачем"

@InconspicuousChap

3 ай бұрын

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

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

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

@user-zv5bf2fh7w

4 жыл бұрын

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

@user-jn1px7rp3h

4 жыл бұрын

@@user-zv5bf2fh7w ха-ха-ха, смешно-смешно)) можно посмотреть ваш код?)))

@user-zv5bf2fh7w

4 жыл бұрын

@@user-jn1px7rp3h, я комментирую свой код, у меня немного другая сфера в которой приходится все комментировать

@avazart614

4 жыл бұрын

Это только касается небольших комментариев в начале файла описывающих задачу и направление решения и проблемные участки в коде где входит путаница/сложность из-за предметной области. В остальных случая да код с комментариями это гавнокод.

Можешь посоветовать хороший материал по стилю и структуре кода, или это все с опытом приходит?

Хотелось бы услышать больше на тему софт скила (это скорее к твоему прошлому видео). Сильно ли влиял другой язык на работе на твой професиональный рост? Как с опытом развиваеться скилл? Какие умение (не технические) должны быть что бы можно было претендовать на роль такого себе мини тим лида))

@SeniorSoftwareVlogger

5 жыл бұрын

У меня есть одно старое видео про софтскилы

Программист понимает, что он говнокодер. А говнокодер думает, что он программист ))

@svarodzic

5 жыл бұрын

Мощно! )))

@dicloniusN35

5 жыл бұрын

прямо как психи в больнице

@InconspicuousChap

3 ай бұрын

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

Я чуть-чуть говнокодер 1. Плохая история коммитов, т.к. я коммичу обычно в тот момент, когда жалко потерять изменения. Логики при этом мало - все происходит достаточно спонтанно. Стараюсь придерживаться правила "атомарное изменение = коммит", но в реальном процессе это не так быстро привить себе и переучиться, как оказалось 2. Я не понимаю, зачем нужен prettier, если есть eslint. Кмк, они решают одну и ту же задачу, но eslint уже всем известен и понятен, а prettier просто еще одно решение. Месяцем ранее был бы еще более говнокодер, очень помогло научиться думать перед тем, как писать код. Самое фиговое сразу кидаться стучать по кнопкам, сначала надо прикинуть, в том числе продумать корнер кейсы. Потом планирование (конкретно что и где меняем), и только потом код (когда точно знаешь что надо писать). С плохой историей коммитов стал бороться через хуки гита. В репо есть прогоны тестов и линтера, но я себе заблочил возможность коммита, если линтеры не приведены в порядок. Это занимает 15 секунд, но коммитов стало в разы меньше, т.к. получилось избавиться от "lint fix", "flow errors fix", "another flow errors fix". Хз, мб поможет кому

"взять и этот кусочек кода удалить" Самый сок, когда для релизов ПО используется бранчевание по версиям, соответственно через несколько бранчей SVN в упор не видит эти самые изменения. Просто привожу пример ситуации, когда комментирование кода вместо удаления - спасает. Я не в курсе как настроен сервер, так как я не RE, а они в свою очередь не будут менять конфигурацию, поэтому просьба об этом не писать.

@SeniorSoftwareVlogger

5 жыл бұрын

Используйте гит

@ShcherbynaM

5 жыл бұрын

@@SeniorSoftwareVlogger , Вы представляете, сколько стоит в международной компании перевести все CI сервера, обучить разработчиков, сконвертировать GIT в SVN (чтобы коммиты были отдельными), и т.д. Это очень большая сумма денег. А ещё это очень большое количество человеко-часов

Спасибо, все как есть.

Написание кода и разбор его это как целое расследование шерлока холмса и доктора ватсона, иногда волосы шевелятся от того откуда что берётся куда что идёт зачем эта функция нужна, что она описывает, а потом вылет вылет вылет 🙏😁шикарный видос. 2 правила пиши чтобы разобрался даже ребёнок, 1 чем меньше написано тем лучше

Насчет тестов не все так плохо - те же пхпшные тесты можно проверить с помощью infection и почти уверен что для других тестовых фреймворков должен быть инструментарий для мутационного тестирования. Естественно MSI - не истина в последней инстанции, но все же дает представление насчет корректности написанных тестов

Дима, спасибо, хорошее видео. Могу подсказать кучу Python штучек, большинство встроено в IDE Eric, free. Линтер, сложность, refactoring rope/

Можно поподробнее про стиль? Это какое-то общее между использованием выбранной нотации ( например camelCase, snake_case), стандартов языка (например PEP8 для Python) и использованием возможностей языка (функциональщина, enumerate и т.д.) или это нечто более сложное, уникальное, идущее от конкретного человека?

@x3n0n3

5 жыл бұрын

Все вместе.

Сделай что-нибудь с фокусом, пожалуйста. Напрягает глаза)

Я не уверен ESLInt ли работает для TypeScript, но очень часто когда с ним работаю на AngularTS он раздражает. Начинает переносить аргументы для вызова метода на новую строчку даже если по сути имя аргумента было небольшое, в итоге файл порой превращается в эту узкую башню, в которой вызов функции растянут на 4-5 строк.

К примеру если есть такое место в коде, где код запускается постоянно и много раз в секунду, + состоит из нескольких больших лупов, поэтому создание лишних функций добавляет оверхед, плюс нужно в каждой из маленьких функций заново рассчитывать локальные переменные, либо же передавать огромное количество переменных то в одну функцию, то в другую, что тоже плохо, поэтому у меня в том месте одна большая функция (~200 строк), это проблема? Тоесть я всёравно должен разбивать функцию на куски, даже если это пусть и незначительно, но всё же вредит производительности или нет?

@user-xs1rc3ih9b

3 жыл бұрын

Если язык компилируемый, то компилятор может эти функции инлайнить и все оверхеды пропадают

@aerahtv0000

3 жыл бұрын

@@user-xs1rc3ih9b не все методы инлайнятся

@aerahtv0000

3 жыл бұрын

@@user-uz6dy3mj7o нет не много, всего 1 место, в котором работает либо одна функция, либо другая, обе сильно огромные по 200-300 строк, я там всё довёл до микрооптимизации, разбивать не собираюсь, спасибо за ответ.

Самое любимое, это когда весь код излишне сложен и нет никаких комментариев )))) А потом ты идешь к тому, кто это мракобесие написал и он пытается вспомнить как это работает 🤗👍

По поводу коменарий. А как насчет JsDock? В этом случае нормально писать очевидные коментарии ради генерации документации?

@avazart614

4 жыл бұрын

Как по мне это жесть. Тут что важнее экономить на документации или писать читаемый код.

Поделись методикой как ты изучаешь Что_То_Новое . Какие техники изучения и запоминания ты используешь ?

@SeniorSoftwareVlogger

5 жыл бұрын

ищи видео "стратегии самообучения"

Чувак походу на разговорах зарабатывает больше чем на программировании, молодец. До 100к подписчиков доберешь так вообще кодить не понадобится :)

@SeniorSoftwareVlogger

5 жыл бұрын

Я гляжу ты имеешь слабое представление о заработках на рутьюбе

@user-dd9ph8fh5d

5 жыл бұрын

@@SeniorSoftwareVlogger возможно, но по идее если будет много подписчиков то можно будет продавать рекламу общаясь напрямую с рекламодателями, вот там должны быть заработки

@SeniorSoftwareVlogger

5 жыл бұрын

Ахахаха, это ты yubikey прищепкой назвал? :)

@Dimarious.G

5 жыл бұрын

А на чём надо? На мыльницах с присоской и укреплённых плечиках для одежды?😂

Спасибо, поставила SpellChecker

Прочитал коментарии и понял что большинство разработчиков не понимают насколько важны такие понятия как стиль, единые подходы, избегание излишней сложности, чистота и тд потому что не участвовали в действительно больших и продолжительных проектах. Да возможно когда ты делаешь проект, который в стадии активной разработки продлиться 3 месяца, после которых все на его забьют тут не важно насколько он чисто будет написан. Но, поверьте, если проект делается 5+ лет группой 50+ человек, то в случае игнорирования данных практик его разработка будет невероятно сложной, болезненной и демотивирующей. Но если следить за этим, уделять достаточное время дизайну и устранению технического долга, то и сложные системы могут быть достаточно внятными, прозрачными и понятными для изменений.

Наконец-то знающий человек на ютюбе появился!

0:23 вообще я думал что под стилем ты имеешь ввиду именно стиль, а ты про форматирование. а вот с 10:23 это уже ближе именно про стиль программирования. PS: из самого простого, например индусы вполне могут писать - if ( boolvar == true ) then ... и т.п. ну да и закрученные циклы, когда в JS можно использовать различные итераторы и т.п.

@user-iq2st2el2d

2 жыл бұрын

и пустые циклы) им платят за количество строк

@ERge77

2 жыл бұрын

@@user-iq2st2el2d , пустые циклы? )) Это индус 80го уровня ))

@user-dd1di2fv6i

2 жыл бұрын

на самом деле ничего невероятно плохого в сравнении с true нет. Да, избыточно, но понятно и однозначно. А вот сишные приколы типа while (!a++) прямо скажем, не лучшая идея.

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

@SeniorSoftwareVlogger

5 жыл бұрын

Стильный говнокодер

@ainurayegizbayeva319

5 жыл бұрын

ахахаха😂👍

@dicloniusN35

5 жыл бұрын

говномист)

@avazart614

4 жыл бұрын

@@SeniorSoftwareVlogger Не важно откуда растут руки, если они золотые.

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

@darthmalokhz5997

5 жыл бұрын

Экспортные функции нужно комментировать.

@Trecoolerok

3 жыл бұрын

Сам начинающий, в планах прочитать книжку clean code, чего и вам советую.

@InconspicuousChap

3 ай бұрын

@@Trecoolerok точно, прочитать и никогда не использовать этот бред.

@InconspicuousChap

3 ай бұрын

Не нужно комментировать каждую функцию. Это только засоряет код пустопорожним текстом. Если в проекте это требуют, значит, проект - суть освоение ИТ-бюджета, и из него надо валить в приличное место, пока тебе голову не загадили так же, как они загаживают код.

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

Отлично все расписал. Последний момент - это главное, что отличает говнокодера от хорошего разработчика. Тем, кто хочет перестать говнокодить, советую прочитать и перечитывать Clean Code by Robert Martin.

@Acid31337

5 жыл бұрын

Боб разрабатывал байтомешалки на Clojure и Java, поэтому у него есть религиозные убеждения о unit-тестах как о серебряной пуле, что не никак не помогает, и даже вредит, например при разработке Android приложений.

@nikitabobyshew7927

5 жыл бұрын

а чем android-приложения отличаются? и как unit-тесты могут вредить?

@Acid31337

5 жыл бұрын

@@nikitabobyshew7927 у unit-тестирования android-приложений есть такая особенность: приложение будет рассыпаться на части, а все unit-тесты ни разу не упадут. Зато дадут ложное чувство уверенности. Потому что тестируется не тот код, в котором будут ошибки. - ну так надо тестировать там где возникают ошибки - для этого нужны НЕ unit-тесты.

я не программист, а профессиональный гуглер и стиль кода для меня не существует

Про эго верно подмечено...)

Про один коммит спасибо. Сделайте может бест практис по гиту?

Дмитрий, не знаю как ты к этому относишься, я сначала ставлю лайк потом смотрю)))) а можно все это напримере показать???

@vladalter4222

5 жыл бұрын

Почитайте книгу Стив Макконнелл - Совершенный код, там все структурировано и с примерами

Мы с коммитами сделали иначе. все задачи были через трелло. А в коммит писали хеш из ссылки на таск + инфа.

XD однозначно лайк автор молодец XD

Но неизменность теста, т.е. его слабая связанность с особенностями реализации кода, может также означать недостаточный контроль кода. Может оказаться, что мы просто мало что тестируем; тестируем какие-то очевидные вещи. Можно ведь написать тест, который не будет зависеть от кода, но также и не будет зависеть от ошибок в нём. :)

@SeniorSoftwareVlogger

5 жыл бұрын

Пишем маленькие чистые функции и нет таких проблем

@sergzach

5 жыл бұрын

Дмитрий, а это правда, что Вы фанат функционального программирования?

@SeniorSoftwareVlogger

5 жыл бұрын

Я фанат рационального программирования :)

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

А что лучше веловипед или зависимость ради зависимости?

Надо программыровать камеру что бы автофокус хорошо работал. А Так нормально...

Что с фокусом камеры? у меня глаза заболели

А архитектуры и паттерны???

Вполне хорошая инфа для джуна!

Как начинающий 💩 кодер скажу- спасибо за видео👍✊️

2:52 во-первых я таки будучи простым сисадминским скриптером до сих пор подхожу под определение программиста :) во-вторых это больше к умению излагать мысли, чем к программированию. Соответственно во-время собеседования возможно имеет смысл не только дать человеку написать кусок кода, но и попросить написать диалог/зарисовку/рассказ. Заодно и умение нестандартно мыслить проверится.

В python идыешка pycharm все подсвечует ) но говнокодить приходится, скорее всего из-за нехватки опыта) я получаю удовольствия от того что пишу код, но моя нынешняя профессия мне не нравится, хочу стать кодером, надеюсь когдато кто-то возьмет меня каким-то интерном или джуном... смотрю видео автора, для мотивации =) Спасибо тебе!

@AlexNatkin

2 жыл бұрын

Как успехи?) Получилось сменить профессию?

@lolbefree

2 жыл бұрын

@@AlexNatkin нет

@AlexNatkin

2 жыл бұрын

@@lolbefree а цель осталась или передумал?

@lolbefree

2 жыл бұрын

@@AlexNatkin я пишу каждый день, что-то новое, завел git, но мне приходится работать сисадмином(принтера, сервера, сервисы) и параллельно кодить для этой же компании, за премии

@AlexNatkin

2 жыл бұрын

@@lolbefree ну это отлично! молодец!) на python'e пишешь?

Экран макбука настолько четкий, что камера отказывается фокусироваться на лице владельца. Вот Эпл так Эпл!!!

@ukrainian333

5 жыл бұрын

@script с какой стати макбук это не макбук?

@ukrainian333

5 жыл бұрын

​@script Открою секрет - там под экраном есть буковки, вот это и есть название устройства - MacBook Pro... хотя там и по тачпаду все понятно

5:34 "Тесты это программа на которые нет тестов", несколько раз прослушал перед тем как понять)

@DrovitoBrazzi

5 жыл бұрын

это не так, на тесты есть автоматические тесты - так называемое мутационное тестирование, это проверка качества самих тестов.

Есть только два типа программистов: if(condition) { //... } и if(condition) { //... } Все остальное от лукавого. А теперь смотрим видео...

@SeniorSoftwareVlogger

5 жыл бұрын

А ещё есть языки без фигурных скобочек

@fearmear

5 жыл бұрын

Единственно верный вариант: if (condition) // ( { // } //... } // {

@avazart614

4 жыл бұрын

@@fearmear Терпеть не могу k&r стиль скобок как до такого можно было дойти.

В последнее время использую дополнительно sonarlint (SonarTS для typescript), очень рекомендую. Особенно помогает cognitive-complexity rule.

С умной рожей восклицаю: 2:23 не версирование, а версионирование! Кстати, Дмитрий, что думаешь по поводу вот этого: habr.com/company/infopulse/blog/345826/?

Интересно

Я программист, для меня все эти рекомендации очевидны

@user-ub3hd4sy4e

5 жыл бұрын

Писать код без комментариев? Нуууу, не знаю.

@user-pr6sk5vc2u

5 жыл бұрын

@@user-ub3hd4sy4e Почему же без комментариев? Если приходится писать костыль или просто сложную штуку, то я оставляю комент. Но чаще всего мой код читабелен и без комментариев, потому что все переменные, функции и т.д. названы правильно

@avazart614

4 жыл бұрын

Для опытных очевидно - то да. Но навряд ли поможет в понимании для новичков без конкретных примеров кода на конкретном ЯП и проекте.

Спасибо! Респект от нубасов!)

Ох уж этот шальной фокус

Ох уж эти жаваскрипт разработчики и вайтишники.

@Dimarious.G

5 жыл бұрын

Ох уж эти комментаторы с 1 подписчиком и видео про правый сектор 🙃

@user-xd1uv8nn2t

5 жыл бұрын

@@Dimarious.G flawless victory

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

@Holms

5 жыл бұрын

Тебя не кто не заставляет комитить сразу. Я пишу в экстазе громадное количество строк и потом делаю много комитов :) Любой git клиент умеет partial commits. Идешь в файл помечаешь строки для комита в этом файле и комитишь ) Конвенцию для текста лучше брать с linux kernel репозитория: "action description"

@MrThreeda

5 жыл бұрын

Holms в моём случае это пустая трата времени. Хорошо если ты можешь себе это позволить...

@kassymkhantorgayev5423

5 жыл бұрын

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

@kassymkhantorgayev5423

5 жыл бұрын

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

@MrThreeda

5 жыл бұрын

Разногласие в том что он привёл это как аргумент того что микрокоммиты - показатель хорошего программиста. Хотя это не так. Джуна гораздо проще делать микрокоммиты потому что от него выхлоп меньше :)

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

@SeniorSoftwareVlogger

5 жыл бұрын

Это не могу подсказать

@antonshtihov7662

5 жыл бұрын

конкретный курс думаю назвать наврядли можно. посмотрите на ютубе курсы html+cssдля начинающих. верстать научитесь можно по jsпочитать. для начала нативный библиотеки и фичи оставте на потом. или вас серверная чамть больше интересует? вообшем надо определиться с направлением для начала! ;))

@Dimarious.G

5 жыл бұрын

Одним курсом не обойтись. Пробуй все, какие заходят, все смотри. Главное пиши руками побольше кода. Старайся не переписывать втупую, а понять, запомнить, закрыть учебный материал, постараться воспроизвести по памяти: так понимание будет лучше.

@Dimarious.G

5 жыл бұрын

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

@pafnuteus

5 жыл бұрын

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

Я думаю уйти из кодинга и взять направление хардвера ...

Камера ужасно прыгает фокусом! Обрати внимание на этом в будущем!

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

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

@Trecoolerok

3 жыл бұрын

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

@_4ado

3 жыл бұрын

А на английском негатива нету, ага

@alazarnfreeman9216

3 жыл бұрын

@@_4ado намного меньше, еще и зависит от того, кто на инглише пишет

@_4ado

3 жыл бұрын

@@alazarnfreeman9216 Если ты так считаешь, то значит ты просто не знаешь английский лол

@alazarnfreeman9216

3 жыл бұрын

@@_4ado вот, русский сразу на личности перешел) ты живое доказательство

Было бы круто, если бы вы показали пару примеров говнокода из реальных проектов)

@SeniorSoftwareVlogger

5 жыл бұрын

Было бы круто найти пару примеров реальных проектов БЕЗ говнокода!

@volodia9509

5 жыл бұрын

@@SeniorSoftwareVlogger ну вы ведь вроде как пишите без него, так что проблемы не вижу. Сравните свои работы и аналогичные чужие. Будет интересно

Все правильно сказал

эй, гуру программирования, у тебя фейс не в фокусе

@user-ns1kl8wh3u

5 жыл бұрын

@@sawabigboy вся суть говнокодеров/трупрограммеров (не важно)

Это как судить по почерку рукописного текста о таланте писателя... Т.е. вообще мимо... Почти всё о рюшечках в коде, бестпрактиз и подобных вещах не влияющих на функционал и качество самого кода. Только про чрезмерную сложность и тесты можно отнести действительно к программированию. На мой взгляд, говнокодер, это человек плохо понимающий что делает, чаще всего, скопипащенный им откуда-то, код (своего кода у них обычно мало). Мне, лично, по барабану на большинство опечаток, пропущенные отступы и подобный "стиль" - хорошо, если он есть, но говнокодером за отсутствие точно не назову. А вот когда одна бездумная копипаста другую погоняет и код можно сократить в несколько раз без потери функционала - вот это для меня и есть признаки говнокодера. Когда не используются возможности языка/библиотек упрощающие код. Когда программист не может придумать ничего своего, но очень следит в пул-реквестах за "стилем" тех, кто реально придумывает, выставляя тех говнокодерами за неправильные пробелы и опечатки. И очень жаль, что сейчас тенденция считать таких говнокодеров хорошими спецами только потому, что он делает всё, что описано в данном видео :(

@InconspicuousChap

3 ай бұрын

Абсолютно в точку.

С каких пор Киану Ривз на русском говорит?

я видео две фунукуии по 20 строк абсолютно идентичные рядом, или 10 повторов вместо цикла, вот интересно если это будет написано отличным стилем с гитом и тестами это уже не говнокод будет?

@InconspicuousChap

3 ай бұрын

Не трожь птичку. Дублирование кода - основной способ повышения его количества. 90+% ИТ-проектов никому не нужны и открываются только для движения денег в нужные карманы. В них приветствуются клинкод, избыточные комментарии, копипаста методов по 1000 строк и любые другие "лучшие практики" создания раздутой кодовой базы. И все проектные документы должны выглядеть, как взрослые, на десятки и сотни страниц. А ну как придёт инспекция посмотреть, за какой такой софт банк А заплатил бодишопу Б 50 или 100 миллионов? Есть разница, по 10000р или по 100р за строчку кода получилось? Конечно, когда за первое можно присесть, а за второе - отпустят с миром.

1) Ни слова не сказал про архитектуру 2) Нулевой взгляд на экономическую составляющую. Иногда может быть дешевле 3 раза сделать приложение заново, только для того чтоб внести маленькое изменение, но это приложение будет стоить по 100 долларов от индуса-говнокодера. Чем один раз заказать приложение у студии за 4000 долларов, где всё будет покрыто тестами и легко модифицироваться. Или другой пример: иногда дешевле снять дополнительный сервер, чем потратить месяц работы дорогостоящего программиста, который будет оптимизировать приложение. Нужно в деньгах всё это взвешивать, а не в "говнокодер vs программист"

@joma0305

5 жыл бұрын

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

@AlexAlex-rc9di

5 жыл бұрын

@@joma0305 Ни о чём таком речь не шла. Не нужно додумывать. Я много раз видел как в видео человек говорит "белое это белое", и тут же три ветки комментов: одна пишет "автор, не правда, белое это черное", вторая пишет "автор, не правда, белое это белое", а третья "я тоже против негров". Всё что не было в видео - это лишь ваша фантазия, умноженная на ваши триггеры. Того, кто изучает кулинарное дело, увидит в сообщении автора призыв к употреблению смузи. Кто-то тут увидит политику, не зависимо от темы видео. Кто-то подумает что автор говорит про кастовую систему и пытается его унизить, сверкая своим статусом. Кто-то подумает что это реклама ноутбука и будет убеждать что макбук всё равно лучше. И каждый будет на своей волне. Большинство из этих людей уже хотели что-то написать на какую-то определенную тему, ещё задолго до случайной находки этого видео. Они просто умножили то что они хотели сказать на предмет самого видео. К примеру, я уже знал что хочу написать про экономический вопрос, просто увидев слово "программист", ещё до того как я полностью прочитал название видео и увидел там слово "говнокодер" и ещё до того как я посмотрел видео. Если бы в видео автор сказал что-то вроде "тема это кликбейт, на самом деле я хотел бы обсудить автомобили", я бы всё равно как-то модифицировал экономическую составляющую, перенеся её на работников завода автомобильной промышленности и их менеджеров. Люди заходят на ютуб не чтоб узнать чужое мнение, а чтоб написать своё. Вот и всё.

@konstantinp5156

5 жыл бұрын

@@AlexAlex-rc9di есть только два мнения. Субъективное и мое...

@MrYurgens

3 жыл бұрын

Про 2 пункт люто плюсую! Рассмотрены идеальные условия, про реальность в 90% случаях ни слова, к сожалению.

@InconspicuousChap

3 ай бұрын

Архитектуру (типовую) ему архитекторы сверху спускают без права апелляции. Ему остаётся только накопипастить типового кода в контроллеры, адаптеры, дата-объекты и прочее. Понятно, что если такой код взять в чистом виде, получится мало и несерьёзно. А не сумеешь объяснить, за что тут заказчиком уплачено 50 миллионов, - вылетишь с работы. Вот так и рождаются всякого рода "клинкоды", шапки комментариев над каждой тривиальной функцией, и тонны юнит-тестов на сеттеры и геттеры. Они просто помогают никчёмному и ненужному приложению выглядеть, как взрослое. Так что автор, осознанно или неосознанно, взвешивает в деньгах, но взвешивание - специфичное для ниши.

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

@InconspicuousChap

3 ай бұрын

Да, в чём-то ты прав, назвав видео "донным".

Какой линтовщик для python посоветуете?

@Holms

5 жыл бұрын

pylint

@5ka_

5 жыл бұрын

Я думаю в PyCharm'e все уже стоит, что надо

Спасибо. Пойду дальше писать код на латыни

Видео понравилось. Подробности по каждому пункту можно погуглить при желании. Взял на заметку разбивку больших коммитов на более мелкие, атомарные. Часто говорят, типа, в моей компании сжатые сроки, мы не пишем тестов, нет общих правил и стиля написания кода, нам не до статических анализаторов, у нас постоянно гарь... Профессионализм - это ещё и умение выбирать компанию и проект для работы. Зачем лезть в гарь, когда можно работать в компании с нормальным планированием и качественными процессами? Где говнокод тебе не навязывают, а отучают от него!

Посоветуй спелчекер

Еще очень важная штука это отличать символы Юникода. Например ни одна IDE (VS, VSCode) не поняла разницы между русской С "с" и англицкой Ц "с" а вот гитлаб в мердж реквест е смог. Когда вы используете IDE для команды монолита - все ОК. Но когда у вас Pyhton, NodeJS, C# на микросервисах - все становистся критичным адсци, на эту ошибки ушло три дня ресерча и 5 минут моего ревью в GitLab реквсета, который уже был слит. Рекомендую запретить все языки вкроме английского в коде!!!

@61DANTE

5 жыл бұрын

вчера наткнулся на классную фичу. В файлах переводов один из разработчиков написал 2 ключа, в виде "MY_SPECIAL_KEY" и "MY_SPEСIAL_KEY". Как получилось 2 одинаковых ключа? Все просто, во втором случае используется русская буква "С"

@alexyetto969

5 жыл бұрын

webstorm отличает, показывает как опечатку. К сожалению, vscode расхайплен и бесплатный, но очень сильно уступает по функционалу webstorm

Когда говорили про комментарии, то как будто пересказывали главу с книги "Чистый Код"

@STIVESification

5 жыл бұрын

он web developer

@antongromov8093

5 жыл бұрын

Iurie Cojocari хорошо, спасибо за информацию))

@dmitry9728

5 жыл бұрын

Это плохо?

@antongromov8093

5 жыл бұрын

Dmitry не хорошо и не плохо. Это просто на заметку другим, если хотят узнать чуточку больше обо всём том, что в ролике. Ну и автору на заметочку, конечно же, куда без этого?! :)

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

@SeniorSoftwareVlogger

5 жыл бұрын

Задавай

камера считает стену более интересной чем ты(

хорошие советы

Подскажите, есть что нибудь на пайтон?

@foreginwall7753

3 жыл бұрын

есть такой язык программирования

@user-pj1qb7lq5i

3 жыл бұрын

С питоном выходи вообще удобнее всего, ведь у него есть единый стандарт написания кода - PEP8. Обычно он поддерживается любым IDE врооде PyCharm и там наряду с синтаксическими будут подчёркиваться ошибки именно в стилистике написания кода

@positiv8509

3 жыл бұрын

@@user-pj1qb7lq5i хорошо, спасибо.

я в профессии 10 лет но до сих пор говнокодер

@user-vh5xv3sx1y

5 жыл бұрын

Jenya Space каждый год клипают ролики о говнокоде))) кажись это заговор разработчиков языков программирования

@stepbystep8525

5 жыл бұрын

я 15 лет говнокодю, зарабатываю 15к$

@denyshriaznov786

5 жыл бұрын

Сочувствую тем, кто работает с тобой

Камера вечно фокус теряет звук плохо синхронизирован. Программист возможно хороший, но не мультипотенциал

функционал ;) Запнулся так запнулся