А потом для премиум юзеров потом еще и текстовое описание сториз) В коротком и художественном вариантах) Пример короткого варианта: "Полуголая, красивая девушка, на пляже, во время заката".
Хм. Мешанина из логики, здравого смысла, и подкрепляющих исследований. Сильно в статье не хватает исследований доказывающих обратную точку зрения. С ними можно было бы получить более сложную, но более правильную систему. А так какая-то реклама образа жизни вышла, не плохая, просто плоская и однобокая. Много для кого работает, но не для всех.
А вообще версии с патчами иногда лучше) Как пример те же игры без denuvo тратят меньше ресурсов, и соответственно работают быстрее и плавнее. Опять таки, если патч удаляет эпизодическое стучание в инет, то огромное ему спасибо. Даже в современном мире, иногда инета нету, например отключили свет в доме, через который идет провод, в результате комп с лицензиями начинает подтормаживать. Разработку без инета вести можно, давно есть виртуалки на домашнем компе, а вот остальное страдает.
Обновления это отдельная боль. Везде идет тезис о том какие обновления хорошие, как они закрывают уязвимости, что-то оптимизируют и добавляют отдельные функции. А на деле уязвимости закрывают, вот только этим их заодно показывают, и не факт что про них до этого знали. Оптимизации зачастую теоретические, т.е. что-то что длилось 0.01с начинает длиться 0.0001с, что вроде пара порядков, и все же время обновления значительно превышает выгоду, а пользователь разницу не заметит. Ну а изменения интерфейсов и прочее, про то как их любят - "Дуров верни стену", в общем нужны далеко не всем, и привычный интерфейс лучше чем продуманный. Хорошие же апдейты вечно продают. Типа новой версии винды, или дополнения для игры. А еще с новой версией может что-то исчезнуть. Как пример музыка из-за окончания лицензии на нее, или проигрывание определенного формата, тоже из-за юридической возни. Конечно это не призыв не обновляться.
Да, про конкретную систему правил и даже несколько конкретных игр слышал. Вот только в детстве я жил посреди ничего (это где-то в сибири, в городе с самым грязным воздухом в мире, в красноярске), и тогда, в девяностые, мы дэнженом (ну вот так), называли вообще игру, где ты сам придумываешь персонажа и сюжет) В общем это была даже не настолка, ибо никто не мешал играть в нее словами, пока гуляешь по лесу.
Поэтому считать ДнД конкретную систему правил не получится. Ибо понятие разошлось шире игры. Намного шире) Даже в ту глубинку где я жил. Без книг, без правил, без знания. Этакий диабло на словах. Та еще фигня, но веселая.)
Да, "ваншот" это обычно убийство одним выстрелом, или персонаж которого можно одним выстрелом убить. Лучше использовать другое слово, более понятное. Например DnD-like игра. Или что это. Это на компе запускается? Это настолка? Для этого нужен софт? Почему то что Foundry VTT это движок становится понятно только из комментариев?
В общем у вас много локальных базовых понятий. И на данном ресурсе было бы вежливым дать им определения. Ибо любителей ВоВа (хотя бы как фольклора) тут много, а вот людей которые могут понять статью мало.
Кстати DnD - Это не на компе. В смысле да, на компе много DnD-like, но много для кого DnD - это общий класс настольных игр. Даже не игры определённой фирмы и названия, нет, это просто жанр настолок - ролевок.
Для кого интересно что тут... Ну в самой статье есть ссылка с текстом https://www.gmbinder.com/share/-L6TGIh9J0x2AqFHovf4 и это и правда DnD настолка.. И видимо ее реализация на каком-то популярном, для порта настолок на комп, движке.
Мой каммент ниже отвечает на часть ваших вопросов, сначала написал потом прочитал) И да это все для свойства версии 2. Кстати у одного ИБ могут и те и другие свойства, но это вообще мрак, и тот кто хочет с этим заморачивать точно должен знать что он делает и зачем)
Еще заметил что работа через эти таблицы на пол порядка быстрее чем работа через orm для инфоблоков, ну и вообще orm для инфоблоков еще крайне сырой, часто входит в бесконечные циклы, поглощая всю оперативку. Про то что $objItem->GetProperties(); использовать не надо, даже особо писать не буду) Не очень знаю уместно ли тут использовать sprintf('b_iblock_element_prop_m%s', $iblockId) ибо если $iblockId это число, то и париться с искейпом не надо, да и делает ли sprintf искейп... Но влом было все строчки менять)
Запятая это не просто обозначение, которое надо ставить по правилам. Это что-то несущее информацию. Например она может обозначать паузы, и это самый простой способ ее ставить или не ставить. Не важно насколько это правильно, важно то, что вы лучше передали информацию. Однако не стоит забывать, что неграмотность это тоже информация, которую вы возможно передаете, а я уж тем более)
В общем если запятые улучшат понимание текста читателю, то лучше их ставить. Для текстов, которые прочитает куча разного народа, лучше пользоваться стандартными правилами. Да и вообще...
В дополнение.
Казнить нельзя помиловать.
Подобные двусмысленные высказывания являются основным примером мест, в которых запятые лучше все же ставить.
Тут не спорю, за годы обратной совместимости он так и не смог перейти в нормально стандартизированную систему. Т.е. старые методы разные, но про них есть документация (не на все), да и комментарии, ответы на разных источниках. Новое ядро лучше, но на него нету документации, примеры только на внешних источниках и т.д.. Более того в старом ядре много не хорошего, типа запросов в цикле, всяких костылей и прочего. Что еще веселее новое ядро крайне ограничено в работе с инфоблоками и пользователями, т.е. двумя основными сущностями. Молчу о багах и бесконечных циклах в нем. Плюс отсутствие нормальной работы с массивом сущностей. Тут полностью согласен, это не нормальная система и явный пример говнокода.
Однако не так плоха битра как разработчики ее использующие. Там почти постоянно такой треш, что не знаешь не то смеяться, не то плакать. И тебе запросы в шаблонах, и использование чистого sql при чем конечно с возможностью инъекций, да и куча другой фигни.
Однако и плюсы у нее есть, с ней можно развернуть магазин вообще без навыков программирования. При чем большой и сложный. Плюс знакомая одинаковая админка, куча роликов про то, как в ней что сделать. Также вся интеграция с 1с, по хорошему должна быть со стороны 1с (жаль готовый модуль умеет мало). В общем каждый инструмент полезен для своих целей.
Боюсь я не встречусь из-за легкого окр, говорящего мне что, пока я не спустился до примитивов я еще не прочитал. Т.е. с тем же .Domain() это не был бы метод получающий домен как в описании, а мне пришлось бы и правда хотя бы его алгоритм прочитать, или что еще хуже его реализацию.
В целом чтобы увидеть код моими глазами, представьте что вы сначала меняете все названия переменных и методов на случайные. Просто чтобы они вам не мешали, намекая на то как это должно работать. Тогда открывается возможность понять что код делает на самом деле, а не что хотел написать автор.
Да у меня просто накипело, и на очередной депрессивный приступ, вызванный изменениями внешнего мира, наложилось.
А если чуть более серьезно. То видел много примеров, где ооп фанатизм очень вредил.
Код битры, в которой приходится работать. Это сразу чтобы словить все помидоры. В битре есть компоненты, они не так давно стали переходить на классы. Основной рекомендованный путь модификации стандартных компонентов, это пара файликов исполняющихся после них. У этого подхода есть проблемы с ajax, ибо компоненты в битре это нифига не контроллеры, хотя последнее время и пытаются таковыми стать. В общем с переходом компонентов из тупо кода в классы открыло новый путь расширения, а именно унаследовать оригинальный класс, перегрузить один из методов и все счастливы. Вот только деление на публичные и приватные методы было сделано, не лучшим образом. Настолько не лучшим, что лучше бы все сделали публичным, я серьезно. А еще лучше если бы доступ к методам указывал на вероятность их поломки обновлением битры.
Как-то опять таки на битре захотели построить нормальную систему. Федерального уровня. В общем одни классы упаковывали в другие, нифига не выносили код в абстрактные классы и т.д. Про именование методов я вообще молчу. Оно было в стиле
$Users = generator["Users"]; // тут было правило, что название переменной должно быть именем сущности
$list = $Users->GetUsersListByIds($ids, [$select, $filter, $order, $limitOrPage, $whatever]);
/* зачем-то есть название сущности в названии метода,
порядок других полей - случайный,
даже когда написал абстрактный GetListByIds все равно делали методы GetЧто-тоListByIds
*/
В общем там было очень много фигни, которая пыталась походить на что-то нормальное, а в результате отнимало время. Ни читать ни писать в таком стиле не хотелось почти никому, поэтому проект на полгода для одного человека, затянулся на два года для команды из менее десятка людей. 3. Самый спорный пример, ваша позиция скорее выдаст степень подсказок вашей ide. Иногда просто хешмапы оборачивают в классы. Все по красоте, геттеры-сеттеры для каждого каждого свойства, легко расширять, дополнять методами если вдруг нужно. Все очень правильно, ибо с такими классами не придется переписывать код, если вдруг понадобится их расширить. Хешмапы для этого явно не подходят. Казалось бы не на что ругаться. Вот только, эти классы никогда не потребуются как классы. С ними даже проще работать как с ассоциативными массивами (опять таки php), у массива легко посмотреть список ключей и значений, пройтись по ним всем и это все что нужно для этой сущности. Конечно в какие-то языки и редакторы встроены очень хорошие инструменты для работы с классами. Они подскажут название методов и кому-то по этим названиям легко ориентироваться, вот только для массивов уже есть куча готовых методов. И это я не к тому, что мол переписывайте классы на массивы, это я к тому, что класс не всегда лучше. Он очень часто лучше, но не всегда и не везде.
Все это хорошо, но только когда пользовательская база достаточно большая, чтобы тратить на это время. Все же написать что-то в стиле
"user@server.domain".split("@")[0] // хоть и сложно читается, но просто пишется
"user@server.domain".Domain() // пишется не очевидно, откуда-то большие буквы, домен и поддомен объединены в общем нужно где-то искать доку
Дальше больше поводов для холивара)
Использование только примитивов - проще читать. Просто потому что заучить примитивы можно, а расширяемую систему типов нет. Ее можно либо знать если писал сам, либо каждый раз подглядывать, ибо в другой фирме уже будут другие типы.
Несмотря на улучшение безопасности, на деле одни уязвимости переходят в другие. Тут все просто, кода без багов не бывает, поэтому чем известней кодовая база, тем больше в базах уязвимостей записей о ней. По факту, работа с безопасностью перекладывается на разработчиков либ, и админов их обновляющих.
Инкапсуляция это зло. Очень прикольно, когда для валидации имейла у тебя есть очень мощная и страшная либа, с кучей регулярок, учета доменов в стиле IPv6 и т.д.. Однако, что-то всегда меняется, а что-то нет, и единственный способ проверить имейл по настоящему это отправить на него письмо. Это не очень очевидно, но представим что вы пытаетесь зарегать пользователя, js проверил имейл, и тот подошел, а вот бек как ни странно, на такой имейл отправлять не умеет, хотя это и правда существующий и валидный имейл. В общем валидация на беке отличалась от валидации на фронте, они обе инкапсулированы, поэтому никто не залез смотреть.
Еще про инкапсуляцию. Со сложными типами невозможно работать без доки. Где-то нужно иметь список всех методов, что они принимают и возвращают. И работа в стиле, пишешь код, альт-таб в браузер, снова в код - это не нян. Порой проще вместо доки использовать исходники. А поглядев на исходники, зачастую возникает желание вообще не использовать эту либу) Да и хорошие доки встречаются редко. В общем все круто, когда сделано идеально, однако в реальности так бывает только когда работают за идею, а сделанным за деньги, пользоваться можно тоже только за деньги.
Еще про инкапсуляцию. Часто в либах зачем-то используют private и protected, еще конечно константы и прочий сахар, мешающий все поломать. Это конечно прекрасно для разработки либы, однако для публики лучше все делать публичным XD это кажется очень плохой идеей по началу, однако будет меньше людей которые скопировали исходники или применяли хаки, чтобы сделать публичными один два метода, которые им зачем-то все же нужно перегрузить.
Типы не наводят порядок. Порядок должен быть в голове, если порядок в голову занесло вместе с типами, то это фальшивый порядок, пиритовое золото, он вроде как есть, только стоит без фундамента, поэтому рушится как только возникают проблемы.
Дальше уже не столь холиварные рассуждения.
Для разного размера компаний актуальны разные правила. Для маленьких можно даже от код-ревью отказаться, а для больших наоборот заставлять всех писать этими типами.
За все нужно платить. Готовый код - менее гибкий, нужно изучать, содержит баги.
За все нужно платить. Не готовый код - менее универсальный, нужно писать, содержит баги.
Далеко не везде нужно учитывать разницу в написании количества денег в Германии и Великобритании.
Очевидных названий методов, классов, констант - не бывает. (Всегда найдутся люди которым не понятно)
Очевидного поведения, не требующего документации - не бывает.
Хорошей понятной документации - не бывает.
А теперь рассуждения о том когда все же пора.
Если 0.1% ваших пользователей генерируют больше вашей зарплаты, то пора писать код и под них.
Если у вас очень много кода, то пора его рефакторить, и запихивать в классы или что там в вашем языке.
Если всем в вашей компании привычно, то можно и не то что в языке, но тогда вы привязаны к команде, а команда к компании.
Если другим разработчикам не привычно, то вас ждет вечный холивар, т.е. у вас есть небольшие шансы, что каждый конкретный разработчик скажет "да так лучше, вы были правы, а я нет", но от команды в целом вы этого никогда не услышите.
А если все же услышали, то в вашей компании есть более важные проблемы, чем плохой код.
Просто странно, в мою деревню подделки добрались через пару лет после айфонов, а еще через пару лет, они внезапно стали с айфонами почти на одном уровне и в чем-то даже лучше.
Вообще был странный момент в моей жизни. Когда оказалось, что китайские ноунеймы не просто ужасная подделка под именитые бренды, а что-то полноценное и даже хорошее.
А еще были смешные подделки под айфоны, где вместо тачскрина был чехол с клавиатурой.
Я понял как пояснить. Звездными войнами. Я за республику, а сейчас империя. У республики куча проблем, ниже уровень жизни, и т.д. но в империи вообще жить не хочется.
Да, что войны важный двигатель прогресса известно. Поражение кстати не так обязательно, хотя и увеличивает Коэф, на который умножается случайная, при настройке нейросети) В общем все логично, победа уменьшает размер шага, поражение увеличивает. Когда прогал нейросеть, глупо и наивно так и делал, что весьма сократило количество поколений на обучение.
И кстати хорошо бы, если градиентный спуск. Нет, тут случайный шаг динамической длинны. Из-за того что пространство работы слишком многомерное. Точнее градиентный спуск есть, но то только в определенных измерениях, типа где политика понятна, там идем дальше, а где хрен пойми что, случайный шаг.
Очень хочется, но это как раз и есть инфантилизм. Можно конечно разделить на своих и чужих, захватить страну, убрать чиновникам все льготы/зарплаты/пенсии. Только сколько жертв в результате. Надо рефакторить и пилить монолит. Сдвигать обратно окно овертона. Только сложно. Вот даже честно позицию высказать страшно. И родные не поддерживают, говорят что охотней на войну соберут, чем из страны бежать помогут.
Эх… А так хотелось бы нормальную страну. Чтобы антимонопольщики делили всякие вк, яндексы и сберы на отдельные фирмы. А то банк доставкой занимается — смешно, да еще и в открытую продвигает себя, в этом магазине. Да еще чтобы судьи были судьями, а не бездумно соглашались с обвинением от силовиков. Чтобы войско занималось хранением покоя, а не служило способом набрать политические баллы. И чтобы по телевизору была куча мнений, на любой вкус. Я ведь не против патриотизма, даже глупого, с клоунами, но пусть и другие точки зрения будут не под запретом. Мечты-мечты.
Он и сейчас в рамках закона, вертикаль власти же)))))
Я не про бюрократию как попытку узаконить, а про бюрократию, как систему распределения ответственности, с разделением власти и вообще «система сдержек и противовесов». Т.е. важна не законность действий, важна возможность снизу отпор давать. Не важно в каком вопросе. Это конечно создает кучу проблем, мешая быстро решать важные вопросы. Однако, заодно сильно ограничивает власть. Вплоть до того, что незаконно собранные доказательства в суде не работают, и даже наоборот за них могут посадить вполне себе хороших полицейских.
В общем-то бюрократия зло, и все обычно радуются, когда ее упрощают чтобы решить проблему. Ну и вот, доупрощались.
А потом для премиум юзеров потом еще и текстовое описание сториз) В коротком и художественном вариантах) Пример короткого варианта: "Полуголая, красивая девушка, на пляже, во время заката".
Хм. Мешанина из логики, здравого смысла, и подкрепляющих исследований. Сильно в статье не хватает исследований доказывающих обратную точку зрения. С ними можно было бы получить более сложную, но более правильную систему. А так какая-то реклама образа жизни вышла, не плохая, просто плоская и однобокая. Много для кого работает, но не для всех.
А вообще версии с патчами иногда лучше) Как пример те же игры без denuvo тратят меньше ресурсов, и соответственно работают быстрее и плавнее. Опять таки, если патч удаляет эпизодическое стучание в инет, то огромное ему спасибо. Даже в современном мире, иногда инета нету, например отключили свет в доме, через который идет провод, в результате комп с лицензиями начинает подтормаживать. Разработку без инета вести можно, давно есть виртуалки на домашнем компе, а вот остальное страдает.
Обновления это отдельная боль. Везде идет тезис о том какие обновления хорошие, как они закрывают уязвимости, что-то оптимизируют и добавляют отдельные функции. А на деле уязвимости закрывают, вот только этим их заодно показывают, и не факт что про них до этого знали. Оптимизации зачастую теоретические, т.е. что-то что длилось 0.01с начинает длиться 0.0001с, что вроде пара порядков, и все же время обновления значительно превышает выгоду, а пользователь разницу не заметит. Ну а изменения интерфейсов и прочее, про то как их любят - "Дуров верни стену", в общем нужны далеко не всем, и привычный интерфейс лучше чем продуманный. Хорошие же апдейты вечно продают. Типа новой версии винды, или дополнения для игры. А еще с новой версией может что-то исчезнуть. Как пример музыка из-за окончания лицензии на нее, или проигрывание определенного формата, тоже из-за юридической возни. Конечно это не призыв не обновляться.
Да, про конкретную систему правил и даже несколько конкретных игр слышал. Вот только в детстве я жил посреди ничего (это где-то в сибири, в городе с самым грязным воздухом в мире, в красноярске), и тогда, в девяностые, мы дэнженом (ну вот так), называли вообще игру, где ты сам придумываешь персонажа и сюжет) В общем это была даже не настолка, ибо никто не мешал играть в нее словами, пока гуляешь по лесу.
Поэтому считать ДнД конкретную систему правил не получится. Ибо понятие разошлось шире игры. Намного шире) Даже в ту глубинку где я жил. Без книг, без правил, без знания. Этакий диабло на словах. Та еще фигня, но веселая.)
Да, "ваншот" это обычно убийство одним выстрелом, или персонаж которого можно одним выстрелом убить. Лучше использовать другое слово, более понятное. Например DnD-like игра. Или что это. Это на компе запускается? Это настолка? Для этого нужен софт? Почему то что Foundry VTT это движок становится понятно только из комментариев?
В общем у вас много локальных базовых понятий. И на данном ресурсе было бы вежливым дать им определения. Ибо любителей ВоВа (хотя бы как фольклора) тут много, а вот людей которые могут понять статью мало.
Кстати DnD - Это не на компе. В смысле да, на компе много DnD-like, но много для кого DnD - это общий класс настольных игр. Даже не игры определённой фирмы и названия, нет, это просто жанр настолок - ролевок.
Для кого интересно что тут... Ну в самой статье есть ссылка с текстом https://www.gmbinder.com/share/-L6TGIh9J0x2AqFHovf4 и это и правда DnD настолка.. И видимо ее реализация на каком-то популярном, для порта настолок на комп, движке.
Мой каммент ниже отвечает на часть ваших вопросов, сначала написал потом прочитал) И да это все для свойства версии 2. Кстати у одного ИБ могут и те и другие свойства, но это вообще мрак, и тот кто хочет с этим заморачивать точно должен знать что он делает и зачем)
Чуть добавлю.
Для получения датакласса одиночных свойств
Ну и для множественных
Еще заметил что работа через эти таблицы на пол порядка быстрее чем работа через orm для инфоблоков, ну и вообще orm для инфоблоков еще крайне сырой, часто входит в бесконечные циклы, поглощая всю оперативку.
Про то что $objItem->GetProperties(); использовать не надо, даже особо писать не буду)
Не очень знаю уместно ли тут использовать sprintf('b_iblock_element_prop_m%s', $iblockId) ибо если $iblockId это число, то и париться с искейпом не надо, да и делает ли sprintf искейп... Но влом было все строчки менять)
Еще
[аниме / киберпанк] Serial Experiments Lain (1998)
[аниме / комедия стиля ванпанчмен] Battle Programmer Shirase (2003)
[аниме / попадание в игру] Sword Art Online (2014)
[аниме / попадание в игру] Log Horizon (2013)
[книга / попаданцы] Анджей Ясинский - Ник (2009)
Это из еще не упомянутых в статье, но повлиявших на мой выбор профессии.
Запятая это не просто обозначение, которое надо ставить по правилам. Это что-то несущее информацию. Например она может обозначать паузы, и это самый простой способ ее ставить или не ставить. Не важно насколько это правильно, важно то, что вы лучше передали информацию. Однако не стоит забывать, что неграмотность это тоже информация, которую вы возможно передаете, а я уж тем более)
В общем если запятые улучшат понимание текста читателю, то лучше их ставить. Для текстов, которые прочитает куча разного народа, лучше пользоваться стандартными правилами. Да и вообще...
В дополнение.
Подобные двусмысленные высказывания являются основным примером мест, в которых запятые лучше все же ставить.
Тут не спорю, за годы обратной совместимости он так и не смог перейти в нормально стандартизированную систему. Т.е. старые методы разные, но про них есть документация (не на все), да и комментарии, ответы на разных источниках. Новое ядро лучше, но на него нету документации, примеры только на внешних источниках и т.д.. Более того в старом ядре много не хорошего, типа запросов в цикле, всяких костылей и прочего. Что еще веселее новое ядро крайне ограничено в работе с инфоблоками и пользователями, т.е. двумя основными сущностями. Молчу о багах и бесконечных циклах в нем. Плюс отсутствие нормальной работы с массивом сущностей. Тут полностью согласен, это не нормальная система и явный пример говнокода.
Однако не так плоха битра как разработчики ее использующие. Там почти постоянно такой треш, что не знаешь не то смеяться, не то плакать. И тебе запросы в шаблонах, и использование чистого sql при чем конечно с возможностью инъекций, да и куча другой фигни.
Однако и плюсы у нее есть, с ней можно развернуть магазин вообще без навыков программирования. При чем большой и сложный. Плюс знакомая одинаковая админка, куча роликов про то, как в ней что сделать. Также вся интеграция с 1с, по хорошему должна быть со стороны 1с (жаль готовый модуль умеет мало). В общем каждый инструмент полезен для своих целей.
Боюсь я не встречусь из-за легкого окр, говорящего мне что, пока я не спустился до примитивов я еще не прочитал. Т.е. с тем же .Domain() это не был бы метод получающий домен как в описании, а мне пришлось бы и правда хотя бы его алгоритм прочитать, или что еще хуже его реализацию.
В целом чтобы увидеть код моими глазами, представьте что вы сначала меняете все названия переменных и методов на случайные. Просто чтобы они вам не мешали, намекая на то как это должно работать. Тогда открывается возможность понять что код делает на самом деле, а не что хотел написать автор.
Да у меня просто накипело, и на очередной депрессивный приступ, вызванный изменениями внешнего мира, наложилось.
А если чуть более серьезно. То видел много примеров, где ооп фанатизм очень вредил.
Код битры, в которой приходится работать. Это сразу чтобы словить все помидоры. В битре есть компоненты, они не так давно стали переходить на классы. Основной рекомендованный путь модификации стандартных компонентов, это пара файликов исполняющихся после них. У этого подхода есть проблемы с ajax, ибо компоненты в битре это нифига не контроллеры, хотя последнее время и пытаются таковыми стать. В общем с переходом компонентов из тупо кода в классы открыло новый путь расширения, а именно унаследовать оригинальный класс, перегрузить один из методов и все счастливы. Вот только деление на публичные и приватные методы было сделано, не лучшим образом. Настолько не лучшим, что лучше бы все сделали публичным, я серьезно. А еще лучше если бы доступ к методам указывал на вероятность их поломки обновлением битры.
Как-то опять таки на битре захотели построить нормальную систему. Федерального уровня. В общем одни классы упаковывали в другие, нифига не выносили код в абстрактные классы и т.д. Про именование методов я вообще молчу. Оно было в стиле
В общем там было очень много фигни, которая пыталась походить на что-то нормальное, а в результате отнимало время. Ни читать ни писать в таком стиле не хотелось почти никому, поэтому проект на полгода для одного человека, затянулся на два года для команды из менее десятка людей.
3. Самый спорный пример, ваша позиция скорее выдаст степень подсказок вашей ide. Иногда просто хешмапы оборачивают в классы. Все по красоте, геттеры-сеттеры для каждого каждого свойства, легко расширять, дополнять методами если вдруг нужно. Все очень правильно, ибо с такими классами не придется переписывать код, если вдруг понадобится их расширить. Хешмапы для этого явно не подходят. Казалось бы не на что ругаться. Вот только, эти классы никогда не потребуются как классы. С ними даже проще работать как с ассоциативными массивами (опять таки php), у массива легко посмотреть список ключей и значений, пройтись по ним всем и это все что нужно для этой сущности. Конечно в какие-то языки и редакторы встроены очень хорошие инструменты для работы с классами. Они подскажут название методов и кому-то по этим названиям легко ориентироваться, вот только для массивов уже есть куча готовых методов. И это я не к тому, что мол переписывайте классы на массивы, это я к тому, что класс не всегда лучше. Он очень часто лучше, но не всегда и не везде.
Все это хорошо, но только когда пользовательская база достаточно большая, чтобы тратить на это время. Все же написать что-то в стиле
Дальше больше поводов для холивара)
Использование только примитивов - проще читать. Просто потому что заучить примитивы можно, а расширяемую систему типов нет. Ее можно либо знать если писал сам, либо каждый раз подглядывать, ибо в другой фирме уже будут другие типы.
Несмотря на улучшение безопасности, на деле одни уязвимости переходят в другие. Тут все просто, кода без багов не бывает, поэтому чем известней кодовая база, тем больше в базах уязвимостей записей о ней. По факту, работа с безопасностью перекладывается на разработчиков либ, и админов их обновляющих.
Инкапсуляция это зло. Очень прикольно, когда для валидации имейла у тебя есть очень мощная и страшная либа, с кучей регулярок, учета доменов в стиле IPv6 и т.д.. Однако, что-то всегда меняется, а что-то нет, и единственный способ проверить имейл по настоящему это отправить на него письмо. Это не очень очевидно, но представим что вы пытаетесь зарегать пользователя, js проверил имейл, и тот подошел, а вот бек как ни странно, на такой имейл отправлять не умеет, хотя это и правда существующий и валидный имейл. В общем валидация на беке отличалась от валидации на фронте, они обе инкапсулированы, поэтому никто не залез смотреть.
Еще про инкапсуляцию. Со сложными типами невозможно работать без доки. Где-то нужно иметь список всех методов, что они принимают и возвращают. И работа в стиле, пишешь код, альт-таб в браузер, снова в код - это не нян. Порой проще вместо доки использовать исходники. А поглядев на исходники, зачастую возникает желание вообще не использовать эту либу) Да и хорошие доки встречаются редко. В общем все круто, когда сделано идеально, однако в реальности так бывает только когда работают за идею, а сделанным за деньги, пользоваться можно тоже только за деньги.
Еще про инкапсуляцию. Часто в либах зачем-то используют private и protected, еще конечно константы и прочий сахар, мешающий все поломать. Это конечно прекрасно для разработки либы, однако для публики лучше все делать публичным XD это кажется очень плохой идеей по началу, однако будет меньше людей которые скопировали исходники или применяли хаки, чтобы сделать публичными один два метода, которые им зачем-то все же нужно перегрузить.
Типы не наводят порядок. Порядок должен быть в голове, если порядок в голову занесло вместе с типами, то это фальшивый порядок, пиритовое золото, он вроде как есть, только стоит без фундамента, поэтому рушится как только возникают проблемы.
Дальше уже не столь холиварные рассуждения.
Для разного размера компаний актуальны разные правила. Для маленьких можно даже от код-ревью отказаться, а для больших наоборот заставлять всех писать этими типами.
За все нужно платить. Готовый код - менее гибкий, нужно изучать, содержит баги.
За все нужно платить. Не готовый код - менее универсальный, нужно писать, содержит баги.
Далеко не везде нужно учитывать разницу в написании количества денег в Германии и Великобритании.
Очевидных названий методов, классов, констант - не бывает. (Всегда найдутся люди которым не понятно)
Очевидного поведения, не требующего документации - не бывает.
Хорошей понятной документации - не бывает.
А теперь рассуждения о том когда все же пора.
Если 0.1% ваших пользователей генерируют больше вашей зарплаты, то пора писать код и под них.
Если у вас очень много кода, то пора его рефакторить, и запихивать в классы или что там в вашем языке.
Если всем в вашей компании привычно, то можно и не то что в языке, но тогда вы привязаны к команде, а команда к компании.
Если другим разработчикам не привычно, то вас ждет вечный холивар, т.е. у вас есть небольшие шансы, что каждый конкретный разработчик скажет "да так лучше, вы были правы, а я нет", но от команды в целом вы этого никогда не услышите.
А если все же услышали, то в вашей компании есть более важные проблемы, чем плохой код.
Просто странно, в мою деревню подделки добрались через пару лет после айфонов, а еще через пару лет, они внезапно стали с айфонами почти на одном уровне и в чем-то даже лучше.
А еще были смешные подделки под айфоны, где вместо тачскрина был чехол с клавиатурой.
И кстати хорошо бы, если градиентный спуск. Нет, тут случайный шаг динамической длинны. Из-за того что пространство работы слишком многомерное. Точнее градиентный спуск есть, но то только в определенных измерениях, типа где политика понятна, там идем дальше, а где хрен пойми что, случайный шаг.
Эх… А так хотелось бы нормальную страну. Чтобы антимонопольщики делили всякие вк, яндексы и сберы на отдельные фирмы. А то банк доставкой занимается — смешно, да еще и в открытую продвигает себя, в этом магазине. Да еще чтобы судьи были судьями, а не бездумно соглашались с обвинением от силовиков. Чтобы войско занималось хранением покоя, а не служило способом набрать политические баллы. И чтобы по телевизору была куча мнений, на любой вкус. Я ведь не против патриотизма, даже глупого, с клоунами, но пусть и другие точки зрения будут не под запретом. Мечты-мечты.
Я не про бюрократию как попытку узаконить, а про бюрократию, как систему распределения ответственности, с разделением власти и вообще «система сдержек и противовесов». Т.е. важна не законность действий, важна возможность снизу отпор давать. Не важно в каком вопросе. Это конечно создает кучу проблем, мешая быстро решать важные вопросы. Однако, заодно сильно ограничивает власть. Вплоть до того, что незаконно собранные доказательства в суде не работают, и даже наоборот за них могут посадить вполне себе хороших полицейских.
В общем-то бюрократия зло, и все обычно радуются, когда ее упрощают чтобы решить проблему. Ну и вот, доупрощались.