Программист, ты должен писать плохой код
Vložit
- čas přidán 25. 06. 2024
- В этом видео разберем когда можно и нужно писать плохой код программисту.
Курсы для будущих JS-разработчиков:
JavaScript Start - go.foxminded.ua/3JsIAc3
FRONT-END (ANGULAR, REACT) - go.foxminded.ua/43WmlDk
Обучение на проекте - go.foxminded.ua/3NoYVzn
Как решать задачи как программист - • Как решать задачи как ...
Тайминг 🕐:
00:00 - Вступление
00:52 - Вы должны уметь писать плохо
01:45 - Как живут системы с точки зрения бизнеса:
02:56 - Пруф оф концепт
06:37 - Выход на рынок
07:45 - Первые версии
08:30 - Стабильное развитие
09:31 - Плохой код на ранних этапах разработки
09:58 - Плохой код и сеньйорность
11:00 - Обучение Front end в FoxmindEd
12:26 - Что означает писать плохой код?
12:28 - Хардкод
13:57 - Отсутствие тестов и подготовки под них
15:02 - Логирование
15:29 - Безопасность
16:24 - Овервью системы
17:09 - Нейминг
18:36 - Забить на код-стайл
19:20 - Еще раз про нейминг 🙂
19:51 - Два типа программистов🙂 и систем:
- стартап с 💩кодом
- саппорт-проект с 💩кодом
Есть вопросы по обучению в FoxmindEd? Пишите нам в телеграм - t.me/foxminded
Вы можете стать спонсором канала и получать плюшки - / @sergeynemchinskiy
❤ FoxmindEd в Instagram: / foxminded.ua
Курсы для будущих Java-разработчиков:
JAVA Start - go.foxminded.ua/43T6WUw
Инструментарий JAVA - go.foxminded.ua/3NHaaom
JAVA - go.foxminded.ua/433IvCE
Обучение на проекте - go.foxminded.ua/3NoYVzn
Курсы для будущих С#-разработчиков:
C# START - go.foxminded.ua/433IDC8
C#/.NET - go.foxminded.ua/3XmkZPL
Обучение на проекте - go.foxminded.ua/3NoYVzn
C# NEXT - go.foxminded.ua/43THE8N
Курсы для будущих Python-разработчиков:
PYTHON Start - go.foxminded.ua/46k3DHh
PYTHON - go.foxminded.ua/3CPCmPr
🎓 Другие направления:
ANDROID - go.foxminded.ua/44bzhVK
SALESFORCE Developer - go.foxminded.ua/3NleHeF
UI/UX дизайн - go.foxminded.ua/46gRGST
Unreal Engine - go.foxminded.ua/3qOkTnR
QA Automation - go.foxminded.ua/4478tGk
IOS разработка - go.foxminded.ua/3JQF3EH
PHP - go.foxminded.ua/44ev9Et
Unity - go.foxminded.ua/42W59MQ
GOLANG - go.foxminded.ua/46k3Qdx
NODE.JS - go.foxminded.ua/42ZTI6W
🎓Продвинутые курсы для состоявшихся девелоперов:
Enterprise patterns - go.foxminded.ua/3XofKPJ
GRASP and GoF Design patterns - go.foxminded.ua/3Xl4ROq
Алгоритмы и структуры данных - go.foxminded.ua/43Vy0ST
C# NEXT - go.foxminded.ua/3XmkZPL
🔧 Пробное техническое собеседование со специалистом уровня Senior Developer/ Team Leader - go.foxminded.ua/3NJYzVy
👔 Карьерная консультация с Сергеем Немчинским - go.foxminded.ua/3PtpJ4j
Сайт FoxmindEd для новичков: go.foxminded.ua/3Nqj6gA
Сайт для разработчиков уровня мидл+: go.foxminded.ua/3NpFFSm
FoxmindEd в ФБ: / foxmindedco
FoxmindEd в Instagram: / foxminded.ua
Мой Telegram: t.me/nemchinskiyOnBusiness
Для деловых запросов: youtube@foxminded.ua
#Плохойкод #немчинский
👨💻 После Senior ВСЕ? Как программисту развиваться после Senior и куда двигаться в айти? 👉 czcams.com/video/NnM1Od1TKdA/video.html
Напиши хороший код - бизнес будет нуждаться в тебе один раз
Напиши плохой код - бизнес будет нуждаться в тебе всегда
оооо, да ты познал жизнь....
именно поэтому компании придумали код ревью
Напиши плохо, чтобы тебя потом не нанимали +)
@@eprst0 за чей счет?
Гениально))
За свою жизнь, не будучи программистом, написал всего одну условно-коммерческую программу) Работал я тогда в НИИ железнодорожного транспорта и возникла задача как-то автоматизировать обработку данных с долгих опытных поездок - усреднить и проредить значения, найти на осциллограммах интересные для нас куски и вырезать их, а также посчитать по этим кускам кое-какие параметры и свести их в таблицу. В общем то, на что у предыдущих поколений инженеров нашего института уходило 1-2 месяца ручного труда.
В общем, получилось у меня примерно 5 тысяч строк не просто говнокода, а говнокода в квадрате) Я начисто игнорировал не только принципы ООП, о существовании которых тогда даже не подозревал, но даже такое понятие, как процедуры) Если какое-то действие (например, вычисление среднего) у меня в программе повторялось, то я тупо копировал кусок кода в нужное место несколько раз) В общем то, что получилось, наверняка повергло бы в обморок любого профессионального программиста, НО! Оно работало! И месяц сидения над этой программой потом сэкономил мне минимум полгода ручной работы) Причем потом, по мере узнавания все новых подробностей о программировании у меня не раз возникали мысли всё это отрефакторить, но всегда побеждала заповедь инженера "работает? не трогай!"😀
не удивлюсь если эта программа все еще работает и ее боятся трогать так как никто не может осознать всю глубину мыслей сваявшего ее человека.
ООП придумали задроты. Это как суп в столовой и в ресторане один и тот же. Но в ресторане тебе подадут красиво, в красивой тарелке и листочком какого-нибудь укропа сверху.
Я бы сказал это фича, а не баг. Я бы назвал этот стиль программирования "тетрадка". Чтобы понять любой участок кода не нужно метаться по всему файлику, всё сразу перед глазами.
И ни одного юнит-теста. Как вам такое, адепты секты TDD? 😆
Хороший код пишут не для себя, а для других людей - в этом цимес...) Твоя программа принесла ожидаемый результат ровно потому, что ты писал её ОДИН, и, судя по всему, раз и навсегда (без необходимости поддерживать и расширять). Если бы ты разрабатывал её в большой команде стремительно развивающегося проекта - твоё "работает же!" сильно замедлило бы работу целой команды ==> компания потеряла бы тьму денег. Вот и вся мораль)
В этот раз автора тоже зовут Сергей Немчинский? 🤔
Ужас😢
Он чуть позже представился… но тоже подозрительно 🧐
Его всё ещё зовут Сергей Немчинский
Нет, он сменил имя
А в чем прикол? Или у меня чувство юмора какое-то ущербное?😂
"...Я серьёзно изменил своё отношение к происходящему, когда у меня появился собственный проект с собственными всамделишными клиентами. И, на самом деле, если вот прямо здесь и сейчас надо подпереть стенку бомбой с часовым механизмом, за неимением ничего другого подходящего по размеру и весу, надо брать и подпирать - потому что иначе завтра вся конструкция потеряет свой смысл. Да, потом надо будет если не заменить бомбу, например, мешком с гантелями (наивно считать, что теперь туда влезет что-то стандартное без перестройки половины фундамента), то хотя бы перерезать провода таймера и, по возможности, выкрутить взрыватель и поставить пару тройку табличек «НЕ ТРОГАЙ!» для потомков. Но это всё потом, а сейчас - не с менеджером, а с разъярённым живым человеком на проводе и пальцами на клавиатуре надо очень быстро решить проблему любым доступным способом.
Я раньше поражался тому, как уродливы изнутри «взлетевшие» проекты. Сейчас я знаю: красивые проекты не взлетают, потому что они не успевают взлететь. Пока инженеры в белых халатах прикручивают красивый двигатель к идеальному крылу, бригада взлохмаченных придурков во главе с безумным авантюристом пролетает над ними на конструкции из микроавтобуса, забора и двух промышленных фенов, навстречу второму туру инвестиций"...
Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще? 🤗
Братан харош. Давай -давай вперёд. Контент в кайф. Можно ещё? Ваще красавчик. Можно вот этого вот почаще.
ну так раз в неделю даю :) и еще по разу в неделю стрим и новости
@@SergeyNemchinskiy это видео по сути пересказ видео с канала ExtremeCode, под названием Ты должен писать плохой код. А мое сообщение это коронная фраза этого канала.
@@SergeyNemchinskiy я понимаю, что одинаковые темы видео это только совпадение. Никакого умысла упрекнуть в пересказе другого видео у меня нет. Просто забавно получается, что темы и текст похожи, вот и все. Тебя люблю.
ExtreamCode)
@@SergeyNemchinskiy твое видео рекомендуется сразу после extreme code канала. я даже ничего не нажимал и автовоспроизведение сразу сюда привело)
А я вот за эту мысль на хабре минуса в карму ловил. Людям прям сложно принять реальность и они готовы обманываться.
Очень хорошо помню своего начальника, когда был юным и горячим ))) Подошел и сказал ему "Почему именно Windows? Давай Linux? Он же бесплатен!!!"
На что он мне сказал: "Конечно бесплатен. Поэтому ты выходишь на работу в субботу и воскресенье ставить всем Linux. Пишешь дополнительно инструкции для пользователей, но не снижая текущей нагрузки и задачи текущие должны быть выполнены в срок! И да, если у пользователей будут проблемы, они к тебе будут в любой момент обращаться! И да, чуть не забыл за субботу, воскресенье и переработки премию получать не будешь. Linux же бесплатен!"
Вот тогда то и стало до меня доходить, что не все в нашем ИТ мире настолько хорошо и красиво )
Плохой программист Джон сделал ошибку в коде, из-за которой каждый пользователь программы был вынужден потратить в среднем 15 минут времени на поиск обхода возникшей проблемы. Пользователей было 10 миллионов. Всего впустую потрачено 150 миллионов минут = 2.5 миллиона часов. Если человек спит 8 часов в сутки, то на сознательную деятельность у него остается 16 часов. То есть Джон уничтожил 156250 человеко-дней ≈ 427.8 человеко-лет. Средний мужчина живет 64 года, значит Джон убил примерно 6 целых 68 сотых человека.
Как тебе спится, Джон - серийный программист?
хм нифигась какая аргументация))
Человеколюди ужаснутся этой истории человеколета.
Сотых? :) То есть, Джон может убить полчеловека?!
Про 1,5 землекопа не слышал? 😁
Можно подумать все пишут программы для 10 млн. пользователей.
Лично мне приходится писать программы для корп. сектора у которых всего несколько десятков пользователей.
При этом раздражают ситуации когда пользователи достают с никчемными проблемками, которые да, согласен есть, но ни на что не влияют и забирают 10 секунд времени у каждого юзера. Но мне надо потратить несколько дней что-бы устранить каждую из них. И не факт что я попутно не наделаю гораздо больших проблем не обратив на что-то внимание...
Ну вот все встало на свои места: не криворукий г..нокодер, а программист первого типа, для стартапов! Спасибо.
Коли підписався на ExtreamCode).
В книге программист-прагматик было: хорошая программа сегодня лучше, чем отличная программа, но завтра. Спасибо за видео, мощнейшая концентрация полезного опыта. Работаю на саппорт проектах, теперь знаю причину, почему в стартапы не попадаю - просто не умею в говнокод)
Правильно) у меня дошло до того, что стало нравиться работать с легаси - сидишь в уютном болотце под капельницей в виде хорошей зп и исправляешь потихоньку старый код 😊
@@codingfox я прям себя в этих строчках увидел))
Братан, харош! Давай, давай, вперёд! Контент в кайф, можно ещё вот этого вот? Вообще красавчик! Можно такого вот прям вообще почаще?
Хаха! Коммент подходящий к соседнему каналу, но и здесь заходит!)😂
@@Scherbakov на соседнем канале есть видео на ту же тему 🙂
Я искал этот коммент🤣
В принципе, разложил по полочкам так, что ни добавить, ни убавить, все так и есть. Маленький комент с моей стороны - если говнокод пишут говнопрограммисты, то он имеет большой шанс не взлететь, а проект закроется. Так что тот говнокод что мы наблюдаем, он так сказать "выживший", то есть оправдавший себя для бизнеса, а стало быть он не такой плохой как тот что умер на самом старте. И вот причина провала часто банальное несоответствие скилла разработчика поставленной задаче, неоднократно был свидетелем такой ситуации.
За видео огромное спасибо, вот это видео просто супер терапия от синдрома самозванца. Просто иногда чувствуешь себя ну пагано, что мол пишешь ьез тестов. Не документиоуеншь функции, не логируешь. Сергей большое человеческое программистское спасибо за видео!
Одно из самых полезных видео, Спасибо!
Думал, ну зачем мне нужно видел про плохой код. А тут оказывается совсем не про код, а про то как думает и живёт бизнес! А такие видео я готов смотреть сутра до вечера
Наконец-то кто сказал как работа работает
потому что уже будешь глубже разбираться чем другие🤫😉
Спасибо большое! Очень полезная и нужная информация! Успокаивающая, доносящая, что все ок на самом деле
Сергей, спасибо!
Ох, не знаю, мне кажется, что не малая часть успешно стартовавших проектов потом умирает как раз из за говнокода. Ибо поддерживать и развивать то гамно, которое стартануло становится просто не реально, а написать все заново дорого, тем более, что бизнес не понимает, какого Х все надо переписывать, да еще за такие деньги. И неизбежные баги при обновлениях, потерянное время и деньги пользователей...
взято из жизни, респект Сереге!
Спасибо Вам!
Этим видео внесли много ясности 👍
Корисна інформація ! Вдячний
Доброго времени суток Уважаемые ! Полностью согласен с вами , что на практике, это оно !
Забавно, никогда не ожидал такую информацию услышать)))
рассуждения от практика очень полезны, спс
Коллега, приветствую!
Дада, всё так) спасибо за тему
Очень крутое видео,одно из лучших 100%,спасибо никак не могу вбить себе в голову эту прописную истину
Приветствую! На счёт хорошего и плохого кода. Я для себя вывел очень простое правило: любой код, который делает то, что от него требуется - хороший. Как бы он ни был написан. А тот, который не делает, что от него требуется - плохой (как бы он ни был написан). Следовательно, любой код, в том числе для стартапа и с поехавшим форматированием, странным именованием функций и магическими числами, если справился с поставленной задачей - хороший.
Ахах, картинка сложилась) Спасибо Сергей. А то я всё думал, откуда такая пропасть между собесом и реальным проектом.
Наводить порядок - наше всё 😁
БРАВО!
Хоспади, Сергей, я люблю Вас!
1. Заканчивается все тем, стоимость каждой новой фичи становится слишком дорогой и кастомео находит нового вендора, который начинает все сначала.
2. Никогда не будет и двух недель, чтобы заняться чисто долгами, а если вам такой спринт и объявят, то ожидания будут раз 10 выше у кастомера от такого спринта
3. Наводить порядок нужно постоянно и постепенно и фиксировать результаты ровно так же, как фиксируются бизнес фичи
4. Даже жуткое легаси можно приводить в божеский вид, сохраняя нужный для бизнеса темп. Но для этого нужна сильная политическая воля лидов, манагеров и прочих лоботрясов:)
4. деньги бизнеса для этого нужны.
чуть чуть "накидаю" =). (на 5 минуте)
С одной стороны, факт. Но с другой стороны, можно разделять этап "дискавери" от этапа "реализации". Простой пример - методология Plan-Do-Check-Act. Вот MVP это Do. На этапе планирования - идет полное описание (очевидно, что, кто, где, когда, зачем, почему, definition of done итд). Do - выбор конкретного решения (возможно сравнение вариантов решения). Check - проверка соответствия решения всем заданным параметрам, оценка, сравнение. Act - разворачивание (на кластера итд).
Да, можно возразить "зачем так сложно? Пока будешь проходить этапы итерации - потеряешь всех клиентов", но нет, "прелесть" этой методологии в том что она "саморасширяемая". Первый раз сделал - второй раз ее же переиспользуешь, возможно, дополняя параметрами (фидбеком, статистикой) по результатам первой итерации. И если эту методологию "вырезать в камне" - я считаю (но не гарантирую) что любая разработка, и вообще работа с проектами может сводиться буквально к step-by-step framework в итоге. Условно - взял набор документов, параметров, воркфлоу, применил - получил профит. Не запариваешься ни о технологиях, ни о документации (шаблон), ни о "творческом поиске" =). Просто получаешь вводные данные (допустим, решил что-то реализовать или что-то автоматизировать) - прошелся по пунктам - получил результат. Быстро, для всех понятно и очевидно (в плане отчета перед руководством), и эффективно.
Ааааа, бро, спасибо тебе! Я столько лет работал в сапорт проектах и сейчас недоумеваю, почему у меня так туго пишется пет-проект!!!! И вот тут я понял, ты прав!
Спасибо, успокоили
Идеально!!!м ))))
Тот случай, когда вещи настолько очевидные, что приходится их популярно объяснять :)
Понял теперь эту систему, но я придерживаюсь своего - глубоко познавать свою профессию в pet-проектах всегда стараться все сделать идеально а там уже и до senior недалеко.😄
В самом начале упёрся в стену мат. вычислений и загрустил. К счастью судьба очень вовремя свела с профессором ЛЭТИ, который прочел курс лекций (под водку на яхте) по практической математике. Оказалось, что дифференциальные уравнения можно заменять линейными измерениями, в программировании циклами.
Суть в том, что допустимые погрешности в вычислениях необходимо нивелировать в зависимости от целей.
Это откровение позволило двигаться дальше и стало одним из важнейших пониманий. Даже подумывал о выведении теории ошибок), т.к. применимо во всех областях. Спасибо, Ф.А. Новиков! Спасибо, Сергей, это очень важно!
Не знаю кто такой Новиков и в Питере никогда не был.
Но учился в Политехе и обратил внимание что высшую математику в объеме для инженеров профессора рассказывали гораздо более понятно чем училка в школе существенно более простой материал.
@@user-be2me4qu1l Ф.Новиков математик, написал учебник по UML в соавторстве... Не помню названия и соавтора. И книга мне не зашла, хотя тема моя была, но уж больно объемный труд, а необходимо было общее представление об архитектуре. Я воспользовался другими источниками и разобрался за несколько часов.
А с преподаванием да, школьные учителя втюхивают материал по совершенно тупой программе. От этого и сверх низкий уровень понимания у выпускников, если они сами по себе не гении.
Профессура в вышке на три головы выше)
Классное видео
спасибо)
Работаю в 1С. Именно так это и работает - это база
Смотрите, например у вас есть система, принимающая какие-то заказы. Так вот, по своему опыту скажу, что если даже из-за говнокода какие-то заказы будут с неверной информацией или что-то в этом роде, то бизнесу гораздо проще решить это через использование девочек на телефоне, нежным голоском успокаивающих клиента, чем тратить время на то, чтобы наводить порядок в коде вместо написания новых фич
Так вот мне куда надо своё резюме подавать. Надо добавить туда два пункта: "Пишу говнокод качественно и с любовью", "Юнит-тесты не перевариваю".
Ничего не пробовал, но стоит поробовать
Спасибо
Ты убил мои убеждения )))
RESPECT!
Когда ты сдал систему без багов ты становишься не нужен. А если еще и подковерные игры там где-то наверху, то и крайним.
Я жалею, что в огромной системе по межбанковскому переводу бабла не заложил дерьма. $200 в час "за обслугу" было бы неплохое дополнение к бюджету, а системка-то монопольная. Вот одня беда, работает без багов и обслуги, совковое воспитание делать "все на веки". Я не говорю о незаконных действиях и воровстве, так, прийти почистить систему от мусора...
P.S. На мою экспертизу попал код JAVA 98 листов разпечатки кода MAIN программы, все hard-coded вплоть то символов. Дык, он пошел в работу. Контрактор получал $120/час. Вот такой прикольный жизненный опыт программера в одном из ведущих банков Канады.
P.P.S. Автору добавлю, вы изпользуете 3rd party tools a on перестает работать и поддерживаться после новой версии винды, прикольно?
Безопасность и защита? По моим оценкам в критичеких сетевых приложениях процентов 60 работы, может быть и более. Я знаю, как бы хакал я, пригодилось предупреждать. А прикол в том, что начальству все это похрен!
Нет ничего сложного, чтобы сделать сразу нормально, с нормальной архитектурой.
Еще ошибки "сломанная черепица" желательно избегать когда вы копипастите одинаковый кусок кода в другое места. Потом вы можете в 1 месте поправить код, а в 2 месте забыть. Лучше дублирующийся код оформлять в виде отдельных процедур)
спасибо, Сергей
есть такая проблема что код иногда такое нефукциональное и баганутое гавно что далее не хочется иметь с данной конторой никаких дел после этого
С целью изучения языка на практике, C#. Написал для своей работы, программу, помогающую систематизировать рабочие процессы, и формирование отчетности по результатам выполненого. Потратил пол года, и сейчас еще добавляю всякие фичи))
Так вот, корил себя, что пишу говно код, так как регулярно смотрел ваши видео, в том числе и про правильный код))
А теперь вот узнаю, что можно и говнокодить))
главное идея, время и деньги, а говнокод сами сляпаем. Может потом и рефакторинг замутим. Сергей спасиб!! Ставлю класс
Первый мой коммерческий опыт. С нуля пилю уже 3 проект в компании и жутко выбешивало вот прям до сегодняшнего утра, что овнер и все остальные прям впереди паровоза постоянно бежат. Самолет только выруливает на взлет, а они уже на середине ВПП руками как крыльями машут и готовые лететь. Пилот им говорит «воу, народ, спокойно. Сядьте, пристегните ремни и лупите в окно, вас поднимут в воздух и принесут охладительные напитки». А они один хрен. Ну короче этот видос открыл мне глаза, помог понять, что вокруг меня происходит и я стал спокойнее к этому всему относится )
Ув. Сергей, как «по-научному» называется эта 2-фазовая методология? (Сначала быстро и коряво функциональность, затем внутренняя красота.) Имеется ли для нее английский термин?
Ща ребята после курсов такие: ОПА-НА, а вот этих слов то я как раз и ждал :D
ахахаха
На курсах люто выносят мозг этим идиотизмом. Там фанатичность 120 левела. Вся эта чистокодная фигня...
Думав клікбейт. Але насправді з багатьом згоден на досвіді
Сергей, что вы думаете про комментарии в исходном коде?
Есть ещё такой паттерн: изначально заложенные в систему решения были хороши, исходя из требований к продукту на момент зарождения. Но дальше жизнь внесла свои коррективы, и продукт начал развиваться в другую сторону. И эти решения требуют либо глубокого рефакторинга, либо написания костылей. Ясное дело, на практике чаще встречается второе. Т.к. рефакторинг - трата денег и времени. А бизнес этого не любит 🤣
Очень актуально для геймдева.)
Дякую!
В книге Мартина ччитал о методе TDD. Там СНАЧАЛА пишутся Unit-тесты, а ПОТОМ сам рабочий код. Но сам ни разу не сталкивался с таким подходом. Видимо таким только АССЫ занимаются типа Мартина. ))
"Повертаюся така додому на ніч дивлячись.
- Сестри, я танцювала весь день, грошей немає.
- - - - Сідай, співаєш. Завтра буде новий день."
В майбут(D)ня..Все сказано в назві вигляді.
Тот случай, когда Сергей Немчинский учит программированию с точки зрения реального мира, где советует забить на все важные моменты.
Прям как с универе: "забудьте что было в школе" а потом на работе: "забудьте что было в универе!".
Я аналогично всегда считаю, сначала надо реализовать идею, а после допиливать и приводить в порядок.
У мя так одна очень полезная лично для меня программа в первоначальном состоянии с 2021 года пашет каждый день. Правда руки доходят только сейчас для ее правки в принципам ООП :)
Какая красочный принт на футболке!)
Где заказать такую?
Это особенно к новичкам относиться, кто бы что не говорил, по-началу новичкам, без разницы какой код писать, ведь главное научиться решать задачи/проблемы, и хотя бы чтобы это запускалось, ведь у многих в самом начале, даже не получается просто решать задачи, они имеют представление как это примерно хотели бы сделать, но реализовать не могут, это главная, и самая сложная проблема, с которой надо начать, а потом уже улучшать код, ведь по началу это еще больше затруднит, и тогда вообще ничего не захочеться
Спасибо😊 вы рассказали про очень важный момент в работе . У многих кодеров элитистов сейчкс икота😂
Подход двух шапок... в одной шапке написал что бы работало, во второй шапке получаешь опыт от рефакторинга ))
Сергей, а что скажете касательно этого подхода, но применительно к автоматизации тестирования?
За Сергея не скажу, но выскажу мнение на своем опыте в АТ и разработке. Автотесты обычно начинают писать уже на довольно зрелых этапах развития системы, когда проект уже точно не стартап, его доработки тестируют вручную и это тестирование занимает довольно много времени. Тогда есть два варианта: 1)мануальщики начинают в автоматизацию и у них по неопытности может выходить только г*код б)код пишут более профессиональные автотестеры, то тут уже они могут писать что-то вменяемое. Но так как бизнес обычно требует полное покрытие тестами за максимально сжатые сроки и вводит какие-нибудь количественные метрики, то и тут код тестов будет далек от идеала. И дальше когда тесты становятся нестабильными или слишком медленными, все это приходится разгребать по новой.
Классное видео, спасибо! Если упростить, то во многом так и есть)) Однако мне кажется здесь есть ложная дихотомия - или так или не так. Как и во всем в жизни - реальность вполне себе может быть где-то в середине.
Мне довелось работать в разного рода конторах, поэтому позволю себе не согласиться с некоторыми моментами:
- не до конца согласен про юнит тесты, - в ядре множества современных продуктов заложена довольно сложная бизнес логика, которую без тестов сложно вывозить даже на начальных стадиях компании. Поэтому сложные и критические вещи покрывать всё-таки стоит.
- логирование и обзервабилити. На это действительно стоит забить до наличия продакшена, но как только прод появился - минимальное наличие логов / настроенных алертов может сэкономить огроменнейшее количество нервов и времени
Со всем остальным я согласен, и особенно плюсую за пункт про нейминги)
Это печально, так как рано или поздно количество архитектурных ошибок или просто ошибок превысит порог, после которого прога будет глючить, падать, вставать и опять лежать.
Особенно, если это касается красноглазной Java. 🙂
Фанат першої категорії, бо там завжди гаряче і досить цікаві виклики. При оптимізації часу на розробку згоден із Сергієм, можна опустити тести, але я ще практикую підхід написання коментарів в складних випадках або в завеликих класах і враховую це в оформленні коду, щоб потім було дуже легко розбити на рефакторингу.
По досвіду був в обох таборах.
Не економити на проектуванні, а лише на реалізації, тоді рефакторинг проходить навіть весело, навіть через значний час, система покращується, а не переписується.
Та не дуже згоден із тим, щоб відмовитись від логування, має бути мінімально достатнє, бо якраз те що зекономимо піде на дебаг
Нравится больше 1 вариант, активно создавать что-то новое
Тебе нравится создавать говно?
Вопрос не стоит так, что создавать новое или исправлять старое ) Скорее создавать новое за сколько денег и в какие сроки. Нормальные заказчики с деньгами не ведутся на дешевизну и скорость, потому что уже обжигались. И тут стоит выбор будешь ты работать в условном люкс сегменте или в говносегменте для ларьков на рынке без бюджета на проектах, которые занимают месяц-два.
Пожалуйста создайте видео о встроенных системах! Ксожалению на эту тему очень мало информации. Очень хотелось бы узнать Ваше мнение в этой сфере. Спасибо!
записала
писать плохой код выгодно,
пока твой код плохой ты нужен работодателю
как только код начинает работать без ошибок - ты не нужен...
конечно есть другой подход - постоянно выпускать обновения которые делают неприонамстаый код, ну какую то его часть...
Я бы отметил что говнкодить можно, но архитектура проекта должна быть продуманной, а также делать упор на композиции, а не наследовании, по код стайлу можно использовать автоформат, который отформатирует проект, также линтеры тоже очень быстро настраиваются
Работаю с задачами по бизнес решениям, еще ни один клиент не захотел потратить лишние деньги на оптимизацию удобства интерфейса или на оптимизацию кода. Поэтому пишу только говно-код...
Всего один раз было, когда сети магазинов все-таки потребовалось ускорить работу отчета, который за год формировался 15 минут.
Прекрасный "код" будущего - да-да, он обязательно настанет
80% всей работы делается за 20% времени
Добавил бы про минимальное комментирование. Хотя бы для себя - через месяц даже автор без этого не вспомнит, что и зачем.
А вообще всё видео - длинный пересказ бородатой байки про двух программистов, где говнокодер потом разбился на авто )))
Дайте название трека в начале видео пожалуйста
Повністю згоден з вище сказаним. На 3 курсі почав працювати помічником адміністратора в державній структурі, там був просто клондайк коду, який просто неможливо було прочитати, все це було написано на php і найсмішніше що це був зовсім не сайт, а самописна серверна програма яка по суті керувала цілою бібліотекою, база даних майкрософт, все це хостилось локально, на системі windows xp server.
Одного разу коли адмін був у відпустці, перестала працювати вигрузка на сайт (з сайту на можна було подивитись список книг і які зараз доступні).
Коли я почав вникати в те як це все працює я зрозумів що це навіть не програма а бекенд для скриптів, де кожна функція була окремим файлом, а в інтерфейсі просто записаний шлях до скрипта в домашній дерикторії програми.
А самі скрипти були написані в рядочок, без табуляції просто реченнями.
Розкопувати це все в мене не було бажання, але згодом в логах сайту я помітив що проблема була в тому що на сайті оновилась версія php.
Я так і не зміг це побороти, але адмін коли прийшов з відпустки успішно написав якийсь скрипт і все запрацювало, що для мене на той час виглядало магією.
Код всегда должен немножко говнишком попахивать, тогда без работы не останешься)
Давно так не ржал, причем с правды.
Супер, все именно так. Но с про нейминг нужно подробнее. Для примера. Часто советуют, что нужно писать что именно означает название переменной, функции и так далее. Но не все так просто. Если просто так делать, то появятся например сотни getPosts(). По сути итак ясно, что эта функция возвращает посты. Но непонятен контекст, и чем отличается от сотни других getPosts(). Вот нейминг и должен решать этот вопрос. Например, содержать в названии, к чем это относится, а не только что означает.
Добавь определение, каких posts. А ещё лучше - каких и с какими целями. Имя будет длиннее, но понятнее.
@@dobandvla если архитектура нормальная, то слишком длинное имя и не нужно. Функционал объекта ограничен родительским объектом.
я бы не назвал - это говнокодом, за что платят, то и пишем ... Приходит заказчик с 200 уе, ты пишешь на эти 200 уе, потом заказчик говорит, еще 50 уе, но мои заказчики в белых футболках страдают, и ты пишешь хак на этих, в белых футболках, потом еще 50 уе за тех кто кто в желтых футболках и тд, и когда этот ком накапливается, ты говоришь, проект говно, потому что там хаков , больше чем функционального кода, а заказчик - я тебе уже заплатил 1000500, и ты сейчас хочешь в два раза больше, за то чтобы переписать все с 0, ты офигел ??? и так этот франкеншейш продолжает жить дальше ... и заказчик скорее всего переходит к другому исполнителю, который обещает за 50 уе все исправить, потому что надеется, что с проектом все ок, в проекте не разбирается, и там 2 раза плюнуть и все наладится ... так и живем
ПППП
Примеры практического перфекционизма программирования 👍
пример ?
Если это возникает то это говорит только о том что на архитектуру приложения забили и если это случается то оно сделано из гомна и палок перевязанных изолентой.
Что гораздо более страшно чем неправильный нейминг или не следование СОЛИДу.
Приветствую. Я вообще нубас в АйТи. Но можно такой вопрос, почему выбираете ноутбук компании HP?
оптимальное цена\качество
Кодстайл лично авто-фиксится линтерами/ИДЕ-шкой одной комбинацией клавиш. Так что можно и с ним писать стартапы.
Я своё первое наказание за неверный код получил на уроке информатики в союзе, когда на тот урок нужно было приходить в специальном белом халате в специальную комнату с большими жужжащими (кстати задумайтесь почему наоборот не звучит) компьютерами ,и на всё про всё давался час ,потом следующая группа.
Так вот учили мы тогда бейсик, програма должна была завершаться командой END .Было там какое-то ветвление, и я поставил END дважды, по окончании каждого, за что получил низкую оценку и объяснение что END ставят только один раз в конце..И вот на практическом уроке я назло ввёл ту программу с двумя END и всё таки отработало..
По моему ТС немного путается в терминах: плохой код и непроверенный код - это разные вещи.
Жиза конечно. Однако стараюсь выдерживать золотую середину. Когда прям дедлайн - говнокодим. Когда средняя срочность - делаем золотую середину, не говнокодим, но и не устраиваем рокет сайнс растягивая сроки сдачи фичей.
Сам предпочитаю тоже на уже готовых проектах работать и заниматься отладкой / поддержкой. Староват уже для стартапов ))
Чаще бывает, что так называемый рокет сайнс сам по себе - завуалированный говнокод.
Работал я в одном таком проекте, с фабриками фабрик фабрик и проблемами на три дня, типа - как блин в этой архитектуре добавить кнопку.
По аджайлу, ничего не должно быть слишком сложным. Всё делается быстро, но в общем - правильно, и со временем становится качественным и надёжным.
Собственно, поэтому всё сейчас на микросервисах. В них довольно сложно создать неохватное чудовище. Сложность становится плоской. Ничего особо сложного. Просто, всего теперь много.
Я за качественный код. Я пока учусь в направлении front-end онлайн (хотя базовые навыки верстки HTML/CSS уже давно неплохие). До данного обучения я учился офлайн и чуть касался верстки в рамках веб-дизайна. Много спорил с преподавателем по офлайн обучению - по мне его код это говнокод. Мне было непонятно, что он много десятков лет верстает говнокодом, притом с частыми «!important» в CSS, и даже не парится. Для меня важна структура и куча правил, иначе меня бомбит. Для моего внутреннего равновесия, я скорее выберу второе. И для меня очень важен качественный опыт - не могу не стремиться стать профессионалом.. Но да, бизнес - есть бизнес. Классный ролик, теперь буду понимать этот нюанс (притом с меньшими нервами для себя). Для поиска работы, важная информация - помогло сложить в голове мою недавнюю пробу поучаствовать в стартапе по разработке соцсети (понял, что от меня ждали, и чего ждал я и почему не нашел).
Я даже больше скажу - так как JavaScript и его производные являются говноязыками, а всякие ангулары по своей сути являются говнофреймворками, то мне кажется на фронте вероятность написать не-говнокод стремится к нулю. Так что вы правы в оценке кода преподавателя - это должен быть говнокод, но и вы будете писать ковнокод, только другого сорта.
Препод юзает !important - это кринж))
разговоры о качестве кода могут начинаться с уровня мидла, ну ещё допускаю такие разговоры от очень опытных джунов в каких-то технологиях, но если ты учишься, то о качестве кода говорить рано
@@hunterxvov4ik Если ты учишься, о качестве твоего кода должны говорить тебе мидлы и синьоры. Так ты и научишься писать лучше со временем. Без практики можно вообще не смотреть ролики про хороший код.
@@hunterxvov4ik Обычно да - рано для начинающего говорить про качество кода. Если уточнить, то начинающему (1-3 года в процессе обучения и работы) трудно понять, что код плох (!). Но начинающие есть разного уровня. До начала нормального обучения я колупал сайты, на любительском уровне, много лет (на код первых моих работ без раздражения, действительно, не взглянешь - а ведь тогда я думал, что мой код неплох).
Другое дело - понимать, что код явно (!) плох. Еще круче понимать - что человек даже не стремится улучшать свой код. Если за много лет практики код «преподавателя-специалиста» все еще «говнокод», то ещё через много лет практики, чуда не произойдет - его код не станет «вдруг» лучше. Всегда видно, когда человек старается в своей области, и когда он остановился в развитии (типа «зачем?», «я итак крут»).
Во, то что нужно. Я вот тоже сейчас занят разработкой софта. И думаю продавать говно код или нет. Деньги то нужны и покрывать разработку нужно. И посмотреть востебована ли эта софтина или нет тоже нужно.
И по ходу я нашёл в этом видео ответ на этот вопрос. Благодарю 🤝
отлично :)
@@dobandvla Ну мои моральные принципы мне этого сделать на данный момент не позволяют. Да и я не хочу это делать.
Сергей сделайте курс Unity Start, просто с минимальным обучением по функциям, векторам и тд, по скольку в чистом С# такого нет, а сразу идти на менторинг Unity после C# Start это больно
обдумаем :)
Все реально как в жизни
Кстати интересно, что с похожей проблемой сейчас физики столкнулись. Что такое Стандартная Модель? Это целый зоопарк элементарных частиц. Физики даже шутят, что физика элементарных частиц стала похожа на ботанику! Это десяток физических констант, никак не связанных друг с другом (скорость света, постоянная Планка, гравитационная постоянная и тд). СМ - несвязанные друг с другом теории. Согласно договоренности, ТО используем для расчетов в макро-космосе (исходим из искривлений пространства под действием графитации). Для микроскопических явлений используем КМ. Удалось Фейнману связать КМ с электродинамикой и получил квантовую электродинамику). И даже у физиков появился соблазн все с нуля переписать!! Теория Струн - попытка переписать все заново от базового класса (струны). Но пока ни 1 одного экспериментального подтверждения существования струн (бран) не обнаружено за 40 лет, но теория красивая!)
Побывал в обоих случаях и немного не согласен в вопросе, что не надо на Стартап сеньора.
Как же вы будите делать тот же самый лейринг, удерживать команду в рамках скорости и говнокода, выбор технологий, и остального что вы ещё нужного перечислили? Неужели простой мидл сможет это все сделать?
Помоему как раз наоборот, в начале Стартап нужен один лид сеньор, который качественно все настроит и который будет понимать все эти тонкости, а потом добирать качественных мидлов, чтоб они уже приводили все в порядок под присмотром лида.
Был у меня в команде миддл, который хреначил по 3 тысячи строк кода в день. Причём, рабочего кода. Менеджеры удивлялись и хвалили.
Весь этот код пришлось выбросить. Вообще весь.
А денег на сеньёра то куча уйдёт...
@@MaxStrike-wx8gc необязательно, сеньор может сократить общий срок разработки, т.е. в итоге получится столько же по деньгам, но лучше