Антихрупкий софт

Некоторые размышления о том, как делать свои разработки таковыми

Настройки отображения темы Показывать по сообщений с сортировкой .
Выводить , отправленные .
Одна страница
Распечатать
4X_Pro
Создатель сайта
Всего сообщений: 3526
Зарегистрирован: 9 дек. 2015 г., 19:20
Рейтинг пользователя: 1719

0
#1
Работая над своим frameworkом, задумался над вопросом, что лучше — подключить через composer какую-нибудь известную стороннюю библиотеку для генерации RSS-потоков или скопировать свой собственный код для RSS из движка Intellect Board с необходимой адаптацией. С одной стороны, первый вариант лучше тем, что более тщательно протестирован, тогда мой тестировался только на типичных сценариях использования, а на каких-то экзотических данных могут вылезти ошибки.
Но с другой — это путь к тому, что в книге Нассима Талеба «Антихрупкость» называется хрупкодельством. Подключая стороннюю библиотеку, я получаю код—«чёрный ящик», в который никогда не буду заглядывать. Который в свою очередь, может иметь ещё несколько зависимостей, в которые, скорее всего, точно так же не заглядывает разработчик библиотеки.
Само по себе в этом ничего плохого бы не было, если бы соблюдался принцип «хороший код — это тот, который пишется раз и навсегда и впоследствии не меняется, потому что решает поставленные задачи». Но увы, об этом остаётся только мечтать: все эти сторонние библиотеки постоянно обновляются. Каждое обновление — это риск, что что-то сломается. Соответственно, чем больше зависимостей, тем больше риск, что что-то сломается. И разрабатываемый софт становится всё более и более хрупким.
Поэтому, на мой взгляд, правильный подход должен быть таким (оговорюсь, что речь идёт о некоммерческой разработке):
1) использовать зависимости только для того, на что не хватает либо квалификации, либо желания реализовывать самому;
2) если зависимость всё же использовали, то фиксировать версию, и обновляться только в том случае, если в этом есть обоснованная необходимость;
3) предусматривать возможность ставить свой софт не только через composer, а и скачать единым архивом, в который сразу будут включены все необходимые библиотеки, как это делалось в старые добрые времена. (К сожалению, уже не раз сталкивался с софтом, установка которого без composerа превращается в весьма непростой процесс. Хотя бы тот же Twig 2 и 3 версий.)

Ребята, давайте жить спокойно!

4X_Pro
Создатель сайта
Всего сообщений: 3526
Зарегистрирован: 9 дек. 2015 г., 19:20
Рейтинг пользователя: 1719

2
#2
Наткнулся на Хабре на интересную дискуссию на тему устаревания софта, в частности, библиотек, которая непосредственно связана с вопросом антихрупкости. Очередная битва БЛ против ЧЛ, выражаясь языком соционики. Одна сторона (пользователь DabjeilQutwyngo) считает, что качественно написанный софт не устаревает, если методы решения соответствующих задач не меняются в принципе, а необходимость его переписывать — искусственна. Другая (пользователи nronnie, selivanov_pavel, luckman) — придерживается позиции, что устаревание — это естественный процесс, которому нет смысла (да и невозможно) противодействовать.
Лично мне позиция DabjeilQutwyngo гораздо ближе, сам неоднократно озвучивал такую же позицию. Но в то же время, когда заходит речь о том, чтобы взять какой-то совсем старый класс, зачастую испытываю настороженость и опасение, что делаю что-то не так. Хотя, как показывает практика, зачастую более старый код оказывается лучше в плане производительности/потребления памяти. А вам что ближе?

Ребята, давайте жить спокойно!

10geek
Единомышленник
Нет Всего сообщений: 333
Зарегистрирован: 29 июн. 2018 г., 09:36
Рейтинг пользователя: 40

2
. Редактировалось 1 раз, последний — #3
4X_Pro написал(а):
А вам что ближе?

Мне ближе позиция DabjeilQutwyngo. Потому, что это минимизация человеческого труда (здравый смысл с точки зрения ЧЛ, как ни странно). Если код качественный и поддаётся доработке, то для его полного переписывания должны быть какие-то ну очень веские причины. Иначе так можно постоянно переписывать и переписывать, сизифов труд получается. У меня был только один раз, когда я одну свою программу переписывал полностью. Это был парсер, который был очень большим и сложным. Дорабатывать его было настолько тяжело, что нецелесообразно, плюс мне не нравилась его архитектура. Когда же под устарелостью понимается несоответствие модным тенденциям, у меня это вызывает лютое охреневание и непонимание, так как несоответствие моде само по себе веской причиной не является. Следование моде есть ни что иное, как выполнение чужой воли, тех, кто её задаёт (если не сказать диктует). Многое из советской техники до сих пор работает и выполняет свою задачу ничем не хуже, а то и лучше современной, особенно что касается надёжности. Поводом для её замены может послужить разве что внешний вид или доступность запчастей. Вот и с софтом примерно так же. На эту тему есть известная фраза из анекдота: «вам шашечки или ехать?».

Одна страница
Распечатать

У вас нет прав для отправки сообщений в эту тему.

Задать вопрос

Здесь можно задать мне вопрос или спросить совета по любой теме, затронутой в блогах или на форуме. После того, как я отвечу, вопрос и ответ появятся в соответствующем разделе. Но не забываем, что я — сторонник slow life, поэтому каких-либо сроков ответов не обещаю. Самые интересные вопросы станут основой для новых тем на форуме или записей в блоге.
Сразу предупреждаю: глупости, провокации, троллинг и тому подобное летит прямо в /dev/null.