У либ в большинстве нет обратной совместимости.
Древняя программа, работающая с либой 1.0, скорее всего не будет работать с либой 3.0.
В java мире тоже есть репозитории либ, но там поступили умнее — у каждой либы есть группа, название и версия. В одном репозитории может одновременно храниться и использоваться одна либа разных версий. В линуксовых репах такое невозможно, отсюда проблемы с обязательным сносом старых либ и попутной поломкой софта
В винде. Копируешь папочку с программой — и программа работает. А не как в линуксе — с копаниями в репозиториях, поиске нужной версии, потом эта софтина засирает тебе всю систему с попутным сносом старых либ (от чего ломаются другие софтины). Именно из-за этого dependency hell и проблем с установкой и поднятием окружения в линуксе и был придуман докер.
Вот какой надмозг придумал репозиторий либ без поддержки версионирования этих либ?
Поддержку автора. Простой пример: написать установщик под максимум возможных систем.
Под винду один единственный — и всё работает на всех версиях и системах.
Под линукс — сразу появляется зоопарк deb, rpm, zypper, pacman,emerge, etc. Разная работа с рутом, для каждого дистрибутива разный софт, проблема с версиями.
Так что в лучшем случае пишется какой-нибудь шельник под убунту, а на остальное забивается большой и толстый. Выбрали конструктор — вот сами и пишите сами себе установщик
обратная сторона — функции с одним действием, как советует какой-то очередной апологет. В итоге вместо чтения кода сверху вниз приходится прыгать по всему коду и куче файлов. Стало ли это удобнее? Нет. Стало ли кода меньше? Нет, стало больше.
Когда стоит делить:
Когда кусок кода используется в нескольких местах
Когда большую портянку возможно разбить на логические блоки
Пожалуй это все причины.
2. В проекте имеется закомментированный код
Чтобы искать в истории надо знать время и место. Закомментированный код показывает место, по нему же можно узнать время.
Или можно делать как в офисном холодильнике — если за n месяцев старый код не понадобился — удаляем его.
Solid это не более чем "нормально делай нормально будет". Там нет конкретных рекомендаций, только ряд весьма спорных абстрактных качеств.
И упоминание этого солид выдает в человеке каргокультиста, начитавшихся модных статей, при этом без понимания — что это и зачем
У вас аргументы в стиле «надо делать хорошо, и тогда проблем не будет». Глупость.
Методы класса зависят от состояния класса — факт. Повреждение состояний вызовет повреждение метода.
И уж тем более завязываться на внутреннее состояние. Давайте уж сразу глобальными переменными хуячить.
Микросервисы — зло.
Тесты это в первую очередь клиентский код
Нет. Юнит-тесты это закрепление текущей реализации кода. Белый ящик, дублирование логики.
Интеграционные тесты — действия пользователей, внешнее воздействие
1) Объекты только в виде POJO, никакой логики внутри. Ибо если внутрь класса класть бизнес-логику, он быстро превращается в god object, внутри появляется очень много зависимостей и зависимостей от вызовов методов. Плюс нарушается принцип инкапсуляции — зона ответственности весь класс и все потомки, нет четких границ. В случае же процедурного-подобного подхода зона ответственности четко ограничена, и четко видны вход и выход.
Плюс объекты с бизнес-логикой внутри сложно тестировать, ибо оно зависит от внутренних состояний
2) Бизнес-логика в виде процедурно-подобных методов в классах-сервисах. Легко тестировать, легко расширять, легко видна зона ответственности, легко делится на слои, легко разделяется на разные классы
3) Наследование только в виде расширения POJO объектов, в соответствии с первым пунктом
4) Делим приложение на слои, минимальное количество: слой записи, слой чистой бизнес-логики и слой взаимодействия с внешним миром
5) Юнит-тестирование только в случае непонятного или страшного кода, в котором я не уверен. Гнаться за 100% покрытием — вредно, ибо увеличивает кодовую базу и затрудняет рефакторинг и правки.
Вместо юнит-тестов по максимуму интеграционные тесты, прогоняющие реальные сценарии работы с начала и до конца
паршивое решение — смешивать бизнес-логику и протокол передачи данных. Давайте уж на команды TCP завязываться, хуле.
Это разные уровни, их нельзя смешивать. Как нельзя смешивать TCP и HTTP.
И уж тем более невозможно уберечься от падения. А обвинять в «криворукости» — это подход прыщавой школоты
По мне так самым удобным был wsdl — в xml было описание всех возможных запросов, форматов запросов и ответов, виды ошибок.
И протокол сам следит за корректностью данных, чтобы они соответствовали шаблону. Полный ordnung. Опять же автоматическая генерация кода сервисов на основе этой wsdl
Для 100% ответа о различии рас нужно проводить сложный социальный элемент когда дети разных рас и полов воспитываются абсолютно одинаково и после этого измеряются их интеллектуальные характеристики в разных задачах.
Такого эксперимента никто не проводит,
Сейчас не проводит, так как это запрещает sjw сообщество.
В 1915 году, доктор Г.В.Ферфусон взял 1000 школьников в Вирджинии, разделил их на 5 расовых категорий, и проверил их умственной способности. В среднем. Чистокровные негры показали 69.2 % от показателей Белых. Негры на три четверти – 73.0 %. Негры-полуровки – 81.2 %. Негры на одну четверть – 91.8 %. Все эти чернокожие жили как и рассматриваемые чистокровные негры. Их среды обитания и «преимущества» или неудобства были точно такими же.
Занятия, проводимые с идентичными близнецами, воспитанными отдельно в радикально различных средах обеспечивают заключительное доказательство, что полное влияние наследственности превышает влияние среды в отношении приблизительно 3 к 1.
Идеологи пресловутого «равенства» часто обесценивают результаты тестов на I.Q. с оправданием, что они – искусственно подтасованы. Тем не менее, НИКТО, ни Объединенный Негритянский Фонд, ни любая другая пронегретянская организация не оказалась способна разработать тест интеллекта, который показывает одинаковость чернокожих и Белых.
Американские индейцы, которые часто живут в условиях далеко хуже чем американские чернокожие в течение всей жизни, тем не менее постоянно обгоняют их на I.Q. тестах
Мышление это не что-то абстрактное и непознаваемое.
Мышление это стандартный физический процесс, напрямую зависящий от физических характеристик органа.
Физически мозг различается, с чего вы решили что мышление при этом не различается?
Древняя программа, работающая с либой 1.0, скорее всего не будет работать с либой 3.0.
В java мире тоже есть репозитории либ, но там поступили умнее — у каждой либы есть группа, название и версия. В одном репозитории может одновременно храниться и использоваться одна либа разных версий. В линуксовых репах такое невозможно, отсюда проблемы с обязательным сносом старых либ и попутной поломкой софта
Вот какой надмозг придумал репозиторий либ без поддержки версионирования этих либ?
Под винду один единственный — и всё работает на всех версиях и системах.
Под линукс — сразу появляется зоопарк deb, rpm, zypper, pacman,emerge, etc. Разная работа с рутом, для каждого дистрибутива разный софт, проблема с версиями.
Так что в лучшем случае пишется какой-нибудь шельник под убунту, а на остальное забивается большой и толстый. Выбрали конструктор — вот сами и пишите сами себе установщик
обратная сторона — функции с одним действием, как советует какой-то очередной апологет. В итоге вместо чтения кода сверху вниз приходится прыгать по всему коду и куче файлов. Стало ли это удобнее? Нет. Стало ли кода меньше? Нет, стало больше.
Когда стоит делить:
Когда кусок кода используется в нескольких местах
Когда большую портянку возможно разбить на логические блоки
Пожалуй это все причины.
Чтобы искать в истории надо знать время и место. Закомментированный код показывает место, по нему же можно узнать время.
Или можно делать как в офисном холодильнике — если за n месяцев старый код не понадобился — удаляем его.
Мисс слаба на передок и не может совладать с инстинктами?
Solid это не более чем "нормально делай нормально будет". Там нет конкретных рекомендаций, только ряд весьма спорных абстрактных качеств.
И упоминание этого солид выдает в человеке каргокультиста, начитавшихся модных статей, при этом без понимания — что это и зачем
Методы класса зависят от состояния класса — факт. Повреждение состояний вызовет повреждение метода.
И уж тем более завязываться на внутреннее состояние. Давайте уж сразу глобальными переменными хуячить.
Микросервисы — зло.
Нет. Юнит-тесты это закрепление текущей реализации кода. Белый ящик, дублирование логики.
Интеграционные тесты — действия пользователей, внешнее воздействие
1) Объекты только в виде POJO, никакой логики внутри. Ибо если внутрь класса класть бизнес-логику, он быстро превращается в god object, внутри появляется очень много зависимостей и зависимостей от вызовов методов. Плюс нарушается принцип инкапсуляции — зона ответственности весь класс и все потомки, нет четких границ. В случае же процедурного-подобного подхода зона ответственности четко ограничена, и четко видны вход и выход.
Плюс объекты с бизнес-логикой внутри сложно тестировать, ибо оно зависит от внутренних состояний
2) Бизнес-логика в виде процедурно-подобных методов в классах-сервисах. Легко тестировать, легко расширять, легко видна зона ответственности, легко делится на слои, легко разделяется на разные классы
3) Наследование только в виде расширения POJO объектов, в соответствии с первым пунктом
4) Делим приложение на слои, минимальное количество: слой записи, слой чистой бизнес-логики и слой взаимодействия с внешним миром
5) Юнит-тестирование только в случае непонятного или страшного кода, в котором я не уверен. Гнаться за 100% покрытием — вредно, ибо увеличивает кодовую базу и затрудняет рефакторинг и правки.
Вместо юнит-тестов по максимуму интеграционные тесты, прогоняющие реальные сценарии работы с начала и до конца
Это разные уровни, их нельзя смешивать. Как нельзя смешивать TCP и HTTP.
И уж тем более невозможно уберечься от падения. А обвинять в «криворукости» — это подход прыщавой школоты
И протокол сам следит за корректностью данных, чтобы они соответствовали шаблону. Полный ordnung. Опять же автоматическая генерация кода сервисов на основе этой wsdl
При этом каждый месяц новые 8 символов. И пару десятков систем, где у каждой свой пароль, который тоже надо запоминать и менять раз в месяц
а как вы собираетесь обновлять эти данные?
И вы серьезно думаете, что например Java медленнее чем pgSQL?
Сейчас не проводит, так как это запрещает sjw сообщество.
Мышление это стандартный физический процесс, напрямую зависящий от физических характеристик органа.
Физически мозг различается, с чего вы решили что мышление при этом не различается?
Не даун, а «альтернативно одаренный».