Comments by "Puk-Puk-Puk" (@guxershmeg) on "Winderton" channel.

И поэтому был придуман макроассемблер. Он позволял по сути сделать свой собственный язык, который другой программист не понимал. Это привело к стандартизации таких конструкций и появлению языка C. И вот с этого уровня уже макросы и шаблоны это абсолютное зло, потому что там такие ребусы появляются, что проще все переписать. Зачем придумывать свой синтаксис? Макросы это вообще эквивалент целого Lisp. А с этим SOLID приходится при поиске ошибки смотреть одновременно в 10-20 исходных файлов, вместо 1-го, где кода-то всего на тысячу строк. Офигеть как удобно сделано. Ну и главное - если посмотреть на реализацию Андроида, то там суперклассы по 10 тысяч строк, а это коммерчески успешная система. Шах и мат. А на SOLID какие крупные успешные проекты есть? Там проблемы начинаются уже от объёмов 20к строк в коде.
6
@AlexandrUral ну так на кассе на старте платят больше, чем на галере. Я начинал это платили как сейчас 50к в течение первых 3 лет, в Москве на такое не выжить. А молодежь хочет с дипломом сразу 100к, так еще на какой-нибудь веб стек, где учиться меньше.
4
Обработка строк, это то чего там нет и быть не должно никогда. По сути весь STL появился для етого. Все высокоуровневые языки предлагают такое из коробки.
2
Сеньор должен иметь опыт поддержки приложений с неудачной архитектурой, в том числе и своих. Чем больше неудачных проектов ты видел, тем ты более ценный сотрудник. Я думаю что значение говнокода слишком преувеличено, на практике если он локальный, то это быстро чинится. А вот плохую архитектуру исправить уже практически невозможно. Почему сеньоров этому не учат? Так же некоторые сеньоры очень любят писать ребусы. Зачем? Вот уволится он, и весь код придется выкинуть. Но самое плохое, что писать сложно советуют в книжках. Это все очень круто и красиво для модельного проекта на пару страниц. Надо по возможности использовать конструкции попроще, которые понятны почти всем, но осознание этой необходимости приходит только во время поддержки чужого кода.
1
@chelol208 если ты делаешь небольшие пет проекты, то да. Но когда проект большой, то там все равно получается тонна текста. Зато C как минимум читаем, ты просто не сможешь написать на нем большой проект, если делаешь плохой дизайн. А вот на языках с ООП запросто и потом ето говно другой программист не способен поддерживать. Если бы Линукс был на C++, распределённая его разработка была бы невозможна, т.к. все бы только и делали, что разгадывали ребусы.
1
@Алексей-ц1г9е на ум приходит только strict aliasing, который реально можно задушить директивой компилятора. Если честно, я только в общих чертах помню. Но вообще нарушать strict aliasing не надо.
1
А ещё C это надёжно и портируемо между платформами, кроме возможно Visual Studio, не поддерживающего полностью C-99. Тогда как C++ вне десктопа, андроида и ios везде сильно порезан и компиляторы даже на десктоп стали стабильны может лет 20 назад и компилируется в 10 раз медленнее, и бинари толще, и еще несовместимость по версиям STL. Когда выходит новая платформа, она идёт сразу с C, потом через может пару лет C-подобный C++, потом еще через 5 лет STL и всё остальное, чтобы можно было применить как раз ети книжки Страуструпа, это слишком долгий срок. С другой стороны имея основной софт на языках типа C++, корпорации удерживают у себя пользователей, на своих платформах. Вероятно в этом и был смысл, чтобы усложнить портирование и стричь больше денег, учитывая например, что C++ от Visual Studio сразу не запустится в компиляторе gcc из-за кастомного синтаксиса Майкрософта.
1
По личному опыту могу сказать, что чистый код так же очень тяжело поддерживать другому человеку, не автору. Учитывая что в цепочке наследований например в наших проектах 7 классов и обилие "понятных" имён вроде Do, Agent, Worker, Model, Listener. Почти нет комментариев. Как бы это неплохие имена, но когда у тебя 10 разных Listener и 10 разных Worker это уже проблема. Так же засада таится в интерфейсах. Несмотря на то, что функция потребляет абстрактный интерфейс, ожидает-то она конкретную реализацию. Теперь надо найти в коде и понять, какой из имеющихся 20 классов, реализующих этот интерфейс, тебе надо туда передать, или в каком надо исправить ошибку, а может во всех 20-ти?. Это требует невероятно много времени, ведь никакой документации и комментариев там нет, а все люди уволены. То есть помимо алгоритмических проблем и проблем с интеграцией нового функционала ты ещё большую часть времени долбишься с архитектурными проблемами. А если тебе нужен какой-то 1 новый параметр в алгоритме, то надо внести изменения в 50 файлов, чтобы этот параметр протащить.
1
@odiiibo это зависит от масштабируемости, производительности. Если это всё не важно, то любой программист С сможет на коленке сделать топорно под любой формат. А зачем в проект тащить сторонние базы данных или там файловые системы, если это пара полей?
1
Я подозреваю, что Clean Code противоречит правилам MISRA, которые придумали специальные комиссии в борьбе за безопасность на жизненно важных объектах, а не балабол Боб.
1
@sir.Geronis если джун не прочитает тонкую книжку "Жемчужины программирования"
1