Поделитесь мнением про оптимизации и подходы, которые вам никогда не пригодились или оказались ложными/вредными

Мне всё детство говорили: «Учись старательно, слушайся старших, и всё будет хорошо». Врали.

Расскажите про ваши откровения из своего опыта.

Шаблоны проектирования (паттерны) на деле оказались более вредны, чем полезны, ибо побуждают программистов возводить ненужные нагромождения кода.

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

А FreeDOS на каком месте?

На самом деле macOS, iOS это самые передовые десктопные операционные системы в плане безопасности

Это которыми нельзя нормально без единого id пользоваться, не сливая свои данные? iOS и десктоп это кстати мощно %)

В Linux есть много простых инструментов типа firejail, ufw.

И какая опасность из за того что gnu coreutils получат доступ к моему Safari Google Chrome? Срочно меняем порт?

Мне всё детство говорили: «Учись старательно, слушайся старших, и всё будет хорошо». Врали.

вот станешь взрослым, поймешь родителей.

А по поводу ORM могу вот что сказать.

Все ORM, которые я видел, плохи. Впрочем я их видел не так уж много, допускаю, что есть хорошие.

Какой должна быть хорошая ORM:

1. Никакого псевдоязыка. Общение с БД идёт путём использования SQL.

2. Задача ORM - преобразовывать результаты запроса в граф объектов, либо преобразовывать объекты в параметры запроса.

3. ORM должна поддерживать частичные выборки. Более того: частичные выборки должны быть абсолютной нормой во всех запросах.

И вот это вот третье это самая «мякотка».

В идеале частичная выборка должна быть частью языка. Т.е. наш метод возвращает не объект Person, а в общем случае некое подмножество полей из объекта Person. В TypeScript это можно отразить в системе типов. В большинстве языков нельзя.

На практике частичная выборка должна таки возвращать объект Person, делать новый класс для каждого запроса это непрактично. Но у каждого поля объекта Person должны быть состояния undefined помимо обычного и null. И при любом попытке чтения этого значения должны сразу выбрасываться исключения.

В совсем идеале язык должен быть построен с учётом SQL. Идеальный язык для работы базой это PL/SQL. Никому в голову не приходит создавать ORM для PL/SQL, ибо там SQL это часть синтаксиса языка. Но до этой мысли человечество пока не доросло. Язык следующего поколения это язык, который включает в себя и SQL и XML (с поддержкой XML Schema для типизации) и JSON (с поддержкой JSON Schema), который одновременно динамически и статически типизируемый, и вообще расширяемый. Который запускается не на компьютере, а в кластере. Где вызов функций может быть как локальным, так и удалённым. Пока такого на горизонте не видать.

Но до этой мысли человечество пока не доросло

В 1С доросли до идеи ORM на SQL: https://v8.1c.ru/upload/platforma/bazovye-mehanizmy/mnogomernoe-i-mnogourovne...

Единственное там переведенный SQL.

В идеале частичная выборка должна быть частью языка.

Языку такая поддержка не нужна, с рефлексией это вообще безболезненно можно сделать. Просто не будет проверок в компилтайме.

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

Есть RPG, помимо SQL там есть возможность низкоуровнево обращаться с БД. XML как в типичном поделии IBM прилагается.

Где вызов функций может быть как локальным, так и удалённым.

На динамике такое часто делают.

В идеале частичная выборка должна быть частью языка.

Языку такая поддержка не нужна, с рефлексией это вообще безболезненно можно сделать. Просто не будет проверок в компилтайме.

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

function get_person_info(id) {
  var person = query("select last_name, age from person where id = ?", id);
  return person.last_name + " " + person.first_name + ": " + age;
}

И уж очень не хотелось бы, чтобы этот код вернул «Ivanov null: 18» без всяких ошибок.

Ну согласись к запросам это слабо относится. Скорее к типам итд. В RPG есть проверка схемы БД и запросов при компиляции.

Где вызов функций может быть как локальным, так и удалённым.

На динамике такое часто делают.

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

Язык 1959 года от IBM это, конечно, интересно и я про него постараюсь почитать, но полагаю, что там хватает других проблем. Но допускаю, что идеи там правильные.

Тут у меня есть идея, опять связанная с RPG, он начинался как язык для обработки стопки перфокарт, поэтому там обычно склеивают задания в последовательности выполнения:

Input -> Step A -> Step B +-> Step C -> End E
                          |
                          +-> End F  

Каждый шаг отдельная RPG программа. С такой парадигмой некоторые шаги уже хорошо изолированны от остальных и можно заниматься раскидыванием их по ресурсам. Особенно с учетом что про открытие БД и таблиц компилятор в курсе.

Ну и к этому прилагается монитор для отладки зависших задач, логирования, итд.

Ну это хлам уже естественно, просто от него мне знакомы идеи которые сейчас не на слуху, и где то еще я их не видел.

понавешали тут сверху свои оптимизации и подходы
игнорируя известный факт - 99% всех проблем решаются при помощи топора
причОм каменного

в смысле аскетика и минимализм наше всё
KISS и вот это вот всё

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

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

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

вот и стоит топор не точен и рукоять его не полирована

а это значит что?
а это значит мамонта били уже и забыли когда
живем сытно, беззаботно
хорошо живем

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

изложил детально: Самый вредный и опасный подход в программировании

О, это само собой.

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

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

А вот очиститель воздуха - это охренеть какая тема. Я не знал, что в воздухе столько дряни, пока сей девайс не поставил.

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

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

У меня на самом деле нет чёткого понимания, как это должно работать.

В Эрланг такое 30 лет уже как работает. Только физические ограничения никто не отменял, если это замыкание с большими данными эти данные нужно переслать по сети и обратно переслать ответ, версии кода на разных машинах одновременно обновить невозможноя, поэтому всегда будет момент несогласованности версий, и так далее. Все это надо использовать очень осторожно, понимая что делаешь.

upd - даже с файлами работает. Открыть на одной машине, передать хэндл на другую и читать/писать как из локального.

Я согласен, что это дело непростое.

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

Во-вторых - да, вся история с сериализацией должна быть продумана. Более того, протокол вообще очень желательно делать на основе HTTP или конфигурируемым.

В-третьих - два раза «да», версионирование это вопрос одновременно сложный и очень важный. Обычно его на самотёк пускают. А это плохо.

Тут есть над чем подумать.

В RoR это одна строчка. Две, если хочется сначала получить айдишники товаров, а потом уже по ним найти нужные товары - это может быть чуть шустрее.

Моё откровение - х..як-х..як javascript без типов и контроля инстансов объектов. И всякий кал из практик JS (типа у нас проблемы с пространством имён и проблемы с управлением памятью - поэтому мы черезжопу запилим объект и назовём это «замыкание», но использовать будем как скоуп и чтоб память не текла)

Всё верно, можно натягивать, а можно отлично мапить. Всё зависит от контекста. Ну и конечно использовать орм как универсальный драйвер можно только если понимаешь, что и зачем делаешь, иначе нужно выбирать орм, которая лучше мапит твои объекты и лучше связывает твои нормальные формы. А для веба годная пагинация вообще приятный бонус.

Я сейчас борюсь с ленивыми коллегами, топящими за gomock. Одна из самых бесполезных и вредных тулзов. Слава богам, адептов ORM мы уже побороли. (До следующего раза.)

вот этот подход оказался вредным - в 95% становится неактуальной и некорретной, так как не обновлеятся при изменениях кода

Он скорее был безальтернативным. Я сейчас перешел на то что документация пишется специализированной инструкт сетью прямо в коде, комментариями-аннотациями в нотации OpenAPI v3. Затем, по мере надобности, меняются человеком, поле там добавить или еще что. Саму документацию собирает и показывает swagger, причем такая документация собирается налету сканом исходных файлов за доли секунды и всегда актуальна.

Все ORM, которые я видел, плохи.

Я ожидал что-то типа: ORM плохи потому что реализуют AR, а это антипаттерн, тк нарушает SRP в моменте смешения представления объекта и его CRUD и прочие бла бла и ррряя.

А тут просто:

В идеале частичная выборка должна быть частью языка. Т.е. наш метод возвращает не объект Person, а в общем случае некое подмножество полей из объекта Person.

В Doctrine есть:

$db->select('partial person.{id, name}');

В Eloquent/Illuminati:

$this->db->select('id, name')->from('person');

Скорее всего дело в:

Впрочем я их видел не так уж много

Я ожидал что-то типа: ORM плохи потому что реализуют AR, а это антипаттерн, тк нарушает SRP в моменте смешения представления объекта и его CRUD и прочие бла бла и ррряя.

Я ничего не понял.

В Doctrine есть: В Eloquent/Illuminati:

Это похоже на PHP или Perl. Мне эти языки не интересны. Весь смысл ORM в статически-типизируемых языках. Если кому хватает хеш-карты на стероидах, это реализуется в десяток-другой строк и не представляет интереса.

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

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

«портабельный» appimage вообще превращается в тыкву на системах с musl.

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

И чем

$this->db->select('id, name')->from('person');

и ещё более всратое

$db->select('partial person.{id, name}');

лучше условного

$this->db->select('select id, name from person');

Ради чего эти тонны обёрточного говнокода?

Доказать начальнику, что он тупой мудак оказалось вредным.

Везде это одна строчка.

топят за ORM потому что он умеет поддерживать множество диалектов баз данных. Но в 95% случаев это не нужно.

Нужно. Дело не в диалектах, а в том, что ORM является контрактом, способствует тому чтобы писать модульный, открытый код. Причём контракт работает как в сторону софта, позволяя комбинировать разные системы хранения (например легко прикрутить кэш поверх ORM), так и в сторону разработчиков, не давая им писать всякую дичь.

вот станешь взрослым, поймешь родителей.

Мне тоже так говорили. 47 лет — достаточно взрослый? Не понял.

Мне тоже так говорили. 47 лет — достаточно взрослый? Не понял.

не понял, зачем хорошо учиться и слушать родителей? значит у тебя еще все впереди.

Вот я тоже смотрю и сомневаюсь. Наиболее частая проблема когда нет ОРМ - добавили-удалили поле, поменяли все 100500 запросов, где использовалсяь таблица, а про редко используемый 100501 запрос забыли или сделали опечатку, и без 100% покрытия тестами оно все грохнулось.

Ну наверно в этих орм помимо запросоов есть еще выборка по связям, это тоже помогает.

В идеале частичная выборка должна быть частью языка

Чтобы что? БД внезапно может вычитывать всю запись, даже если ты просишь одно поле (а может и не вычитывать). Кроме того объект может быть при этом помещён в кэш и дальше по коду могут использоваться и другие поля (а ты их не прочитал и придётся снова ходить в БД). Вот чтобы пони горбатые не пытались умничать и нужны ОРМ: это средство угнетения тупорылых мидлов со стороны архитектора.

Ну, и зачем хорошо учиться? Чтобы что? Покажи мне карреляцию между оценками и уровнем благостояния. Окей, не в деньгах счастье. Покажи мне карреляцию между оценками и чем-либо хорошим. Слушать родителей == продолжать династию горя и бедности. Потому что 99% родителей - несчастны и бедны.

Я у себя когда нет возможности использовать ОРМ, делаю следующим образом. Во всех sql запросах все имена таблиц пишу через макросы, и каждый раз меняя структуру таблицы меняю имя макроса типа MYTABLE11 вместо MYTABLE10. И оно перестает компилироваться, пока я не пройдусь и не проверю каждый запрос, заодно поменяв имя макроса. Избавляет от 99% проблем связанных с отсутствием ОРМ.

Покажи мне карреляцию между оценками и чем-либо хорошим.

вот я хорошо учился и пишу корреляция через О. разве это плохо?

а ты учился плохо, и стал лениным. разве это хорошо?

А кому из нас лучше, как ты думаешь?

почему?

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

а во многих знаниях многие печали.

Нет, товарищ. Чтобы всегда было хорошо, нужен ум. Житейский ум, а не эти вот задачки и пятёрки. Потому что тётка у меня в номере убирается и жалуется, что у неё высшее образование. А у мистера Билла Гейтса высшего образования нет.

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

Но соблазн решить все проблемы чем-нибудь быстрым и легковесным никуда не исчез.

Я ничего не понял.

Ну и ничего, не всем это надо, скачите на лужайку. *улыбнулся и шлепнул по крупу.

Во первых, это красиво (с). Запросы читабельнее и проще меняются, хотя это скорее вопрос насмотренности.

Основные преимущества:

1. Миграции. С ORM они не причинят боль.
2. Безопасность. ORM сам фильтрует входные данные, позволяя избегать SQL иньекций на уровне приложения.
3. Переносимость. Один и тот же код будет работать без изменений с большинством современных баз данных. Тогда как SQL лапшу в коде придется переписывать.

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

Переносимость. Один и тот же код будет работать без изменений с большинством современных баз данных

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

то есть, если ты не понял, запросы уровня select ... from ... join ... переносится руками но механически, а за пределами таких запросов ORM ничего и не умеет (да даже такие примитивные простейшие по общей структуре запросы на практике построитель на самом деле не может, а орм тем более. шаг влево от order by id и всё).

то есть ничего оно не сэкономит в данном случае.

все остальные задачи перехода на другую СУБД тем более никакое ORM не упрощает так как в принципе не может, а «всё остальное» - оно 99% задачи и образует, а вовсе не тупой перенос тупых селектов

Безопасность. ORM сам фильтрует входные данные, позволяя избегать SQL иньекций на уровне приложения.

чушь какая. ORM не защищает от SQL-иньекций. ты банально не понимаешь даже на каком уровне что делается, кто кого от кого защищает и пр.

Безопасность.

кроме того, ремарка. любой средне-грамотный программист обязан понимать, что «SQL-иньекций» - это не про безопасность вообще. просто так сложилось, что для совсем дебилов придумалось этакое устоявшееся название.

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

это в принципе некорректный код, это баг, такая программа работать не сможет даже если она локальная, однопользовательская, с файлом в качестве хранилища а не сетевой БД, без сети, даже локальной, без хакеров, оно банально не будет работать. ну следуя этой тупой терминологии теперь это не sql-injection тогда.

Безопасность.

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

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