- Он не работает! - Ну и что, ты посмотри как я красиво оформил иерархию наследования - Для создания списка клиентов? - Нет, для алгоритма его группировки, нам нужно чуть передвинуть дедлайн...
Автор прав, но по моему мнению, все равно, даже когда пишешь первоначальный вариант кода, не стоит забывать про базовые правила по типу не называть переменные а б с, пользоваться функциями, классами и тд. А то получится так в итоге, что ты либо сидишь до фанатизма прописываешь аннотацию каждой переменной либо сам же путаешься в своем коде в процессе написания первоначального варианта, что там что тут ты тратишь время нерационально, поэтому баланс должен быть
Ну в целом я конечно же подразумевал, что ты стараешься писать код максимально правильно с учетом своих текущих знаний, но главное без фанатизма чистого кода, которого начитался, но еще не умеешь использовать. К концу видео специально отметил, что нужен баланс и, что изучать best practices и т.д все равно нужно.
Сам так и делал когда учился, дошел интуитивно до того же самого!) Спасибо Автору за смешных обезьянок, обожаю эти ролики, они меня заставляют улыбаться)
Как говорил мой друг, для того чтобы написать хороший/идельный код надо в начале написать дерьмовый. А я когда напишу код и он работает уже считаю что он идеален, и понятия не имею как его улучшить=)
Главный посыл не в том, чтобы его избегать. А в том, что если схожу пытаешься его писать и тратишь систематически куча часов на старт задачи, то начинай упрощенно, а после рефактори. А если ты успеваешь свои таски закрывать сходу чистенько, то так и делай - все классно 🤜🤛
Это как на Егэ со второй частью, сначала ты пишешь решение и постепенно с каждой последующей выполненной задачей у тебя оформление улучшается и улучшается. И тебе ставят заветные Максимус баллов(зп по аналогии), но также нужно найти точку после которой можно ничего делать, когда любой джун сможет понять твой код.
На мой взгляд нужно соблюдать баланс, не нужно прям жестко говнокодить, но и не нужно пытаться писать идеальный код сразу, написал нормальный код, выкатил, а потом уже рефакторишь до того момента пока он не будет «идеален» (в кавычках, потому что для каждого идеальный код выглядит по разному), но на ранних этапах проекта нужно все таки продумать некоторые ключевые моменты, чтобы в будущем не пришлось переписывать все приложение из-за неправильно выбранного подхода, стоит думать наперед хотя бы на пару шагов (в глобальном плане), но не на 10 лет вперед, иначе ты уйдёшь в такие дебри, что мама не горюй, и по итогу ни к чему толковому не придешь. Все выше сказанное является чисто моим субъективным мнением и является выжимкой из моего 4-х летнего опыта.
Тут существует еще вторая крайность, которая заключается в том, что на фазу рефакторинга забивают) Про таких кстати на лурке хорошая статья написана: "быдлокодер". Ну и бизнесу все-равно на чистоту кода только в моменте и пока косты на выполнение, и время имплементации задач не начинают увеличиваться из-за воняющей кодовой базы, так что тут такой себе аргумент. Но в целом согласен, надо просто баланс соблюдать, проекты с "идеальным" кодом никогда не релизятся)
Все верно, я поэтому специально в виде делал акцент, что не идет речи о том, что вообще надо забить на чистоту и начать люто гавнокодить. Рефакторинг важен и нужен!
Ну не всегда. Если вы инди-разраб приложений, лучше сразу делать хорошо, иначе вы не сможете его обновлять и переиспользрвать, а значит придётся начинать следующий проект сначала, а это потеренное время впустую и ноль заработанных денег и жизнь начинается сначала :) ну разве что вы только старше стали за это время
Главное свой говнокод в мастер не вливать и не закрывать задачу пока не отрефакторишь. Бизнесу поддержка говнокода обходится дороже, это тоже стоило бы подчеркнуть.
@@lightcode-group "скорее всего" надо заменить на "может" или даже "если повезет" т.к. кодревью проводится далеко не в каждой компании. До сих пор есть такие, где вообще сразу в мастер всё льют. А некоторые вообще без системы контроля версий живут еще 🤭.
собственно, есть такая мантра "Do it work Do it smart Do it fast", кажется именно в такой последовательности. Соответственно, пока не сделано предыдущее - на территорию следующего do ты не заходишь. все!
Ну слишком в лоб слова мои воспринимать не стоит. Я конечно же не несу посыл вообще не думать. Я лишь пытаюсь донести, что слишком много тратить времени на это не стоит. Если ты конечно знаешь, что после долгих раздумий ты всегда успеваешь в срок сдать задачу, то классно (можно так и делать). Я конечно же тоже при решении задач трачу время на обдумывание, чтобы сходу сделать все чисто. Просто новички, когда с первого раза пытаются писать чисто, то бывают в ступоре сидят часами и по итогу также гавнокодят. Для них лучше сразу решать в лоб задачу, а после рефакторить.
1:00 Ты не прав в этом моменте, заказчику нужен не просто работающий код, а хорошо работающий код, или ты не понимаешь, что если ты напишешь функцию не так как положено, то у этого кода будут проблемы из-за тебя безответственного и заказчик будет переплачивать чтобы исправлять твои ошибки, так если из-за тебя одни проблемы, то не лезь в то дело которые не смыслишь.
Господи, очевидно это посыл для джунов был. Если ты уж так придераешься, то ты должен понимать, что любой гавнокод джуна будет отправлен на код ревью его тим лиду / ответственному за него. А вот он уже конечно учтет все то, о чем ты пишешь.
@@lightcode-group кодревью не во всех компаниях есть. Так что тут можно попасть в ситуацию уже постфактум. Тут именно правильно сказал, что надо показывать свой код, спрашивать.. но обычно всем впадлу его смотреть т.к. у самих жопа горит.
Обычно такие задачи Джуну не доверят, тут посыл больше для джунов в видосе. А так конечно есть ряд нетривиальных задач, на которые изначально дается большой запас времени (та же неделька). Тут уже весь карт-бланш и можно думать сколько хочешь.
Хоть посыл видео и такой у меня, однако конечно же на работе у меня также возникают задачи, когда мне приходится собрать инфу / разобрать все best practices в данном кейсе, чтобы взвешенно выбрать удачное решение задачи. На такие задачи может и не одна неделя уходить. Особенно, если речь о переписывании проекта на новый стек технологий и нужно, переписывая не забрать старые костыли с собой.
Слушайте этого парня, зрители. Он прав! Я когда понял, что вокруг меня люди (включая программистов) вовсе не умнее меня, такие же неуверенные некоментентные распистяи, мне стало легче и я перестал загоняться. Теперь есть задача и есть рабочее решение. ВСЁ. Мнение окружающих в этом уравлении отсутствует.
Я не понял, что за прогон в начале. "Тритишь кусу времени в раздумьях, вместо того, чтобы писать код". Такую чушь может сказать только тот, кто ни разу в жизни не писал сложнее хеллоу ворлд. Как раз лучше подумать десять раз и написать систему с ресурсом к расширению и фичам, чем макаронную функцию на 1000 строк.
Сомнительно, но окей. Я много чего писал: и микро сервисы, и ddd, и mvpvm, и куча всего остального. Я к концу видео говорил, что речи не идет писать первое, что пришло в голову вообще без раздумий. Очень много джунов ловят ступор при решении задачи, потому что пытаются сходу сделать все идеально, хотя сами такой расширяемый код еще не писали. Посыл в том, что в таком случае надо сперва сделать рабочее решение, а после уже его отрефакторить. Так они не будут парализованные сидеть и париться, что скоро дедлайн, а у них ничего не готово. (Мое субъективное мнение)
а что делать с оверинженерингом? У меня в последнее время жесткая проблема с этим, для каких то простых вещей пишу большую логику и думаю наперед хотя можно было бы сделать гораздо проще
Субъективно, но могу сказать, как сам делаю. Обычно я учитываю разные факторы в таком случае: срок задачи, насколько вероятно, что к этому проекту будем возвращаться и будут ли его долгосрочно поддерживать. Условно, если ты делаешь микро-проект, которые решает задачу здесь и сейчас и после запуска к нему уже возвращаться не планируется, то можно и пренебречь частью best practices, ибо масштабироваться он точно уже никогда не будет.
я джуниор по питону я когда у меня после закрития проги в пайчарме вилетаєт ошибка но в exe файлах он не висвечиваиться и так работает не используя PEP8 и перемение ето иероглифи : "и так сойдет"
@@standbyuu тут скорее ты берешь то, что есть). В целом почти на любом стеке ты можешь найти работу, если хорошо его выучишь. Плюс пересесть со стека на стек не сильно сложно, особенно в моем случае т.к java и c# уж слишком похожи.
Господи, какая нахер разница, как ты пишешь код. Главное, чтоб тебе, как программисту было удобно его писать. Просто достаточно соблюдать какие-то базовые вещи типа: поставить отступ, где это надо и т.д. Люди, не ебите себе мозги.
Железный болван (ака чатджипити и прочие) отлично придумывает названия переменным. И еще тесты неплохо пишет, ну черновики тестов. В остальном он правда иногда ересь несет и врет как троечник при сдаче лабы, так что будьте осторожны :)
Не забывайте использовать буковки для написания комментариев, это сильно поможет в развитии канала! ❤
P.S: смогли разгадать бинарный код на превью? 🫣
Я нихуя в паттернах не разбираюсь но часами думать над структурой и названиями классов это про меня
😁
- Он не работает!
- Ну и что, ты посмотри как я красиво оформил иерархию наследования
- Для создания списка клиентов?
- Нет, для алгоритма его группировки, нам нужно чуть передвинуть дедлайн...
Ахахахаха, вот-вот)
ХАХАХХАХАХАХХАХАХАХАХХАХАХАХХАХАХАХАХ
Классные мысли в видео, спасибо за качественный контент!
Автор прав, но по моему мнению, все равно, даже когда пишешь первоначальный вариант кода, не стоит забывать про базовые правила по типу не называть переменные а б с, пользоваться функциями, классами и тд. А то получится так в итоге, что ты либо сидишь до фанатизма прописываешь аннотацию каждой переменной либо сам же путаешься в своем коде в процессе написания первоначального варианта, что там что тут ты тратишь время нерационально, поэтому баланс должен быть
Ну в целом я конечно же подразумевал, что ты стараешься писать код максимально правильно с учетом своих текущих знаний, но главное без фанатизма чистого кода, которого начитался, но еще не умеешь использовать. К концу видео специально отметил, что нужен баланс и, что изучать best practices и т.д все равно нужно.
Сам так и делал когда учился, дошел интуитивно до того же самого!) Спасибо Автору за смешных обезьянок, обожаю эти ролики, они меня заставляют улыбаться)
Спасибо за коммент)
Дельные советы. Спасибо за полезную информацию. 👍🏼
Спасибо за хорошие мысли 👍
Спасибо за коммент 🔥
@@lightcode-group Всегда рад поддержать хороший контент
Как говорил мой друг, для того чтобы написать хороший/идельный код надо в начале написать дерьмовый. А я когда напишу код и он работает уже считаю что он идеален, и понятия не имею как его улучшить=)
Тебе нужно почитать книги / статьи по рефакторингу, что научиться бафать свой код) А так, твой друг толковые вещи говорит))
Классная информация, интересный контент. Лайк 👍
Спасибо
Мотивируешь и интересно доносишь информацию 👌🏻
Спасибо за коммент 🔥
Видос Мощь , Спасибо за информацию , Прекрасно, эти правильные мудрости и истина в программирование помогает
Рад, что нравится, надеюсь новые рубрики тоже понравятся на канале)
Если я не буду писать чистый код, Сеньор мне даст по шапке 🥲
Главный посыл не в том, чтобы его избегать. А в том, что если схожу пытаешься его писать и тратишь систематически куча часов на старт задачи, то начинай упрощенно, а после рефактори. А если ты успеваешь свои таски закрывать сходу чистенько, то так и делай - все классно 🤜🤛
Видео с каждым раз становятся лучше и лучше👍
Спасибо 🙏
Корпоративный линтер: "неееее так низя называть переменные, а вот тут у тебя чёт вложенность большая. Давай-ка переделывай"
Емко. Красиво. Спасибо!
Спасибо за коммент, это помогает в развитии канала 🔥
Это как на Егэ со второй частью, сначала ты пишешь решение и постепенно с каждой последующей выполненной задачей у тебя оформление улучшается и улучшается. И тебе ставят заветные Максимус баллов(зп по аналогии), но также нужно найти точку после которой можно ничего делать, когда любой джун сможет понять твой код.
На мой взгляд нужно соблюдать баланс, не нужно прям жестко говнокодить, но и не нужно пытаться писать идеальный код сразу, написал нормальный код, выкатил, а потом уже рефакторишь до того момента пока он не будет «идеален» (в кавычках, потому что для каждого идеальный код выглядит по разному), но на ранних этапах проекта нужно все таки продумать некоторые ключевые моменты, чтобы в будущем не пришлось переписывать все приложение из-за неправильно выбранного подхода, стоит думать наперед хотя бы на пару шагов (в глобальном плане), но не на 10 лет вперед, иначе ты уйдёшь в такие дебри, что мама не горюй, и по итогу ни к чему толковому не придешь. Все выше сказанное является чисто моим субъективным мнением и является выжимкой из моего 4-х летнего опыта.
Тут существует еще вторая крайность, которая заключается в том, что на фазу рефакторинга забивают) Про таких кстати на лурке хорошая статья написана: "быдлокодер". Ну и бизнесу все-равно на чистоту кода только в моменте и пока косты на выполнение, и время имплементации задач не начинают увеличиваться из-за воняющей кодовой базы, так что тут такой себе аргумент. Но в целом согласен, надо просто баланс соблюдать, проекты с "идеальным" кодом никогда не релизятся)
Все верно, я поэтому специально в виде делал акцент, что не идет речи о том, что вообще надо забить на чистоту и начать люто гавнокодить. Рефакторинг важен и нужен!
Очень круто, спасибо
Спасибо за коммент
Ну не всегда. Если вы инди-разраб приложений, лучше сразу делать хорошо, иначе вы не сможете его обновлять и переиспользрвать, а значит придётся начинать следующий проект сначала, а это потеренное время впустую и ноль заработанных денег и жизнь начинается сначала :) ну разве что вы только старше стали за это время
Если ты в плане того, что уже готовые хорошо написанные механики переиспользовать на следующих проектах, то да - тут соглашусь.
Спасибо! 👍
Спасибо за комментарий 🤜🤛
10 лет я до сих пор ищу идеальный код
Тогда тебе стоит писать на 1С. Там он сходу находится)
Я заканчиваю frontend но не знаю как применить true false, return false, preventdefault с function, как из совместить с function?
Главное свой говнокод в мастер не вливать и не закрывать задачу пока не отрефакторишь.
Бизнесу поддержка говнокода обходится дороже, это тоже стоило бы подчеркнуть.
Ну в Реале то скорее всего твой комммит будет код ревью проходить, поэтому там уже должны такого не допустить.
@@lightcode-group "скорее всего" надо заменить на "может" или даже "если повезет" т.к. кодревью проводится далеко не в каждой компании. До сих пор есть такие, где вообще сразу в мастер всё льют. А некоторые вообще без системы контроля версий живут еще 🤭.
собственно, есть такая мантра "Do it work Do it smart Do it fast", кажется именно в такой последовательности. Соответственно, пока не сделано предыдущее - на территорию следующего do ты не заходишь. все!
Не слышал о таком, но звучит разумно, в целом именно такой посыл и был моих мыслей на основе своего опыта)
Так то да но лучше подумать над переменными и классами чем потом жалеть об этом
Ну слишком в лоб слова мои воспринимать не стоит. Я конечно же не несу посыл вообще не думать. Я лишь пытаюсь донести, что слишком много тратить времени на это не стоит. Если ты конечно знаешь, что после долгих раздумий ты всегда успеваешь в срок сдать задачу, то классно (можно так и делать). Я конечно же тоже при решении задач трачу время на обдумывание, чтобы сходу сделать все чисто. Просто новички, когда с первого раза пытаются писать чисто, то бывают в ступоре сидят часами и по итогу также гавнокодят. Для них лучше сразу решать в лоб задачу, а после рефакторить.
1:00 Ты не прав в этом моменте, заказчику нужен не просто работающий код, а хорошо работающий код, или ты не понимаешь, что если ты напишешь функцию не так как положено, то у этого кода будут проблемы из-за тебя безответственного и заказчик будет переплачивать чтобы исправлять твои ошибки, так если из-за тебя одни проблемы, то не лезь в то дело которые не смыслишь.
Господи, очевидно это посыл для джунов был. Если ты уж так придераешься, то ты должен понимать, что любой гавнокод джуна будет отправлен на код ревью его тим лиду / ответственному за него. А вот он уже конечно учтет все то, о чем ты пишешь.
@@lightcode-group кодревью не во всех компаниях есть. Так что тут можно попасть в ситуацию уже постфактум.
Тут именно правильно сказал, что надо показывать свой код, спрашивать.. но обычно всем впадлу его смотреть т.к. у самих жопа горит.
вот чел написал 5 уровней абстракции в своем коде, и мне чтоб его понять нужно читать часа 3. я считаю это херовый код
Сейчас посмотрим и УЗНАЕМ ШЕДЕВР? ИЛИ НЕТ
как обычно шедевр
Если задача скорость и отказоустойчивость но стоит все таки подумать недельку.
Обычно такие задачи Джуну не доверят, тут посыл больше для джунов в видосе. А так конечно есть ряд нетривиальных задач, на которые изначально дается большой запас времени (та же неделька). Тут уже весь карт-бланш и можно думать сколько хочешь.
Хоть посыл видео и такой у меня, однако конечно же на работе у меня также возникают задачи, когда мне приходится собрать инфу / разобрать все best practices в данном кейсе, чтобы взвешенно выбрать удачное решение задачи. На такие задачи может и не одна неделя уходить. Особенно, если речь о переписывании проекта на новый стек технологий и нужно, переписывая не забрать старые костыли с собой.
Идеальный код это как чистый спирт
Слушайте этого парня, зрители. Он прав! Я когда понял, что вокруг меня люди (включая программистов) вовсе не умнее меня, такие же неуверенные некоментентные распистяи, мне стало легче и я перестал загоняться. Теперь есть задача и есть рабочее решение. ВСЁ. Мнение окружающих в этом уравлении отсутствует.
не ну делать переменые х1 жто не оч(в обучении можно но когда делаешь чтото большое лучше делай нормально)
Ну тут речи о таком гавнокоде не идет) гавно код - гавно коду рознь 😄
Я не понял, что за прогон в начале. "Тритишь кусу времени в раздумьях, вместо того, чтобы писать код". Такую чушь может сказать только тот, кто ни разу в жизни не писал сложнее хеллоу ворлд. Как раз лучше подумать десять раз и написать систему с ресурсом к расширению и фичам, чем макаронную функцию на 1000 строк.
Сомнительно, но окей. Я много чего писал: и микро сервисы, и ddd, и mvpvm, и куча всего остального. Я к концу видео говорил, что речи не идет писать первое, что пришло в голову вообще без раздумий. Очень много джунов ловят ступор при решении задачи, потому что пытаются сходу сделать все идеально, хотя сами такой расширяемый код еще не писали. Посыл в том, что в таком случае надо сперва сделать рабочее решение, а после уже его отрефакторить. Так они не будут парализованные сидеть и париться, что скоро дедлайн, а у них ничего не готово. (Мое субъективное мнение)
а что делать с оверинженерингом? У меня в последнее время жесткая проблема с этим, для каких то простых вещей пишу большую логику и думаю наперед хотя можно было бы сделать гораздо проще
Субъективно, но могу сказать, как сам делаю. Обычно я учитываю разные факторы в таком случае: срок задачи, насколько вероятно, что к этому проекту будем возвращаться и будут ли его долгосрочно поддерживать. Условно, если ты делаешь микро-проект, которые решает задачу здесь и сейчас и после запуска к нему уже возвращаться не планируется, то можно и пренебречь частью best practices, ибо масштабироваться он точно уже никогда не будет.
@@lightcode-group понял, спасибо за ответ!
я джуниор по питону я когда у меня после закрития проги в пайчарме вилетаєт ошибка но в exe файлах он не висвечиваиться и так работает не используя PEP8 и перемение ето иероглифи : "и так сойдет"
Очень интересно, но ни**я не понятно…
ммм
😂 хахахахаха
Лайк кто разгадал бинарный код на превью, лол 😜
Ахахахах, дааа
я думал я один😂😂😂
🔥
А ты знаешь языки программирования ? Если да то какие, просто интересно
Начинал с java, после пересел на шарпы, ибо нашел работу. Сейчас работаю fullstack .net разрабом. Из фронта на реакте пишу.
@@lightcode-group ва, поздравляю, хорошей тебе работы
@@lightcode-groupJava невостребованная? Или это была работы мечты, ради которой можно было пересесть?)
@@standbyuu тут скорее ты берешь то, что есть). В целом почти на любом стеке ты можешь найти работу, если хорошо его выучишь. Плюс пересесть со стека на стек не сильно сложно, особенно в моем случае т.к java и c# уж слишком похожи.
Господи, какая нахер разница, как ты пишешь код. Главное, чтоб тебе, как программисту было удобно его писать. Просто достаточно соблюдать какие-то базовые вещи типа: поставить отступ, где это надо и т.д. Люди, не ебите себе мозги.
Многие новички не сразу к этому приходят)
так и делаю
Железный болван (ака чатджипити и прочие) отлично придумывает названия переменным. И еще тесты неплохо пишет, ну черновики тестов. В остальном он правда иногда ересь несет и врет как троечник при сдаче лабы, так что будьте осторожны :)
Все верно, для черновых вариантов он вполне годится.
ExtremeCode?
Ахахахах, нет, но есть нюанс…))
tytht