Когда сталкиваюсь с задачей, которая не выглядит специфичной для этого конкретного проекта, ни в коем случае не делаю своё решение, а ищу подходящую библиотеку/фреймворк. Без исключений. Даже если нужно просто прочитать одну переменную окружения и ругнуться, что там пусто, я возьму библиотеку, которая читает переменные окружения и валидирует, и буду использовать её. Если нужно собрать URL по кусочкам, я возьму библиотеку, которая строит URL по кусочкам, даже если мне всего-то надо "http://example.org/books/"+id сделать 1 раз на весь аппликейшн.
Мотивация такая:
1. Я могу не видеть всей сложности, поэтому чёрт его знает сколько это займёт.
2. Я могу не видеть всей сложности, поэтому моё решение может оказаться некорректным.
3. Я вижу достаточно сложности, чтобы не захотеть решать задачу самостоятельно.
4. В будущем я могу встретиться с вариацией этой задачи — и буду действовать более эффективно, если сейчас выясню, что есть готовое решение.
5. Взяв готовое решение я ещё забесплатно получаю сколько-то гибкости. Даже если сейчас мне ничего из этого не надо, я буду иметь в виду, что какие-то детали поведения поменять будет легко.
6. Чем меньше кода я напишу, тем меньше сопровождать, и тем меньше новым коллегам вникать.
7. Если я даже напишу своё решение, я же не буду его документировать, а у библиотеки есть документация.
8. Библиотека моделирует задачу, поэтому пристально посмотрев на библиотеку (на интерфейс) можно узнать больше о задаче, о том как её можно интерпретировать и о том, как вообще она решается.
Объясните популярно почему я неправ, почему из-за таких как я кто-то страдает, и как нужно делать на самом деле. Спасибо.
Здравствуйте, rosencrantz, Вы писали:
R>1. Я могу не видеть всей сложности, поэтому чёрт его знает сколько это займёт. R>2. Я могу не видеть всей сложности, поэтому моё решение может оказаться некорректным.
Эти моменты актуальны и для кубика.
R>5. Взяв готовое решение я ещё забесплатно получаю сколько-то гибкости. Даже если сейчас мне ничего из этого не надо, я буду иметь в виду, что какие-то детали поведения поменять будет легко.
Этот пункт подходит и для "не кубика"
R>6. Чем меньше кода я напишу, тем меньше сопровождать, и тем меньше новым коллегам вникать.
Сопровождение кубика всегда проще?
R>Объясните популярно почему я неправ, почему из-за таких как я кто-то страдает, и как нужно делать на самом деле. Спасибо.
R>Объясните популярно почему я неправ, почему из-за таких как я кто-то страдает, и как нужно делать на самом деле. Спасибо.
Страдать будет пользователь из-за того что на каждый чих ты инициализируешь свой трактор, там где обойтись можно было лопатой.
Здравствуйте, rosencrantz, Вы писали:
R>Объясните популярно почему я неправ, почему из-за таких как я кто-то страдает, и как нужно делать на самом деле. Спасибо.
Тут в чем дело.
Если библиотека нормальная, то это конечно все правильно и разумно.
Только вот "библиотеки" нынче пошли какие-то худосочные что ли. Получается замкнутый круг — и код большинство не пишет, а конструирует.
Если посмотришь на гитхаб например, часто получается ситуация, что реально пишет код какой-нибудь китаец, а потом сто человек потом тупо его копипастят.
1. В проекте будет огромное количество лишнего незадействованного кода. Это увеличивает число потенциальных уязвимостей. Простой пример: ты заюзал какую-нибудь XML-библиотеку, чтобы распарсить XML из трёх тегов. А XML-библиотека поддерживает миллиард возможностей, включая, например, скачивание DTD из внешних источников. И тебе подсовывают XML с DTD, который абузит это скачивание и закачивает тебе вирус на сервер. А ты про это вообще можешь не подозревать, ты библиотеку подключил, три строчки для парсинга написал и ушёл дальше.
2. Каждая библиотека это обязательство. Тебе нужно следить за её версиями. Тебе, возможно, нужно будет дорабатывать её, если автор решит прекратить выпускать обновления. Если тебе нужно внести изменения в код библиотеки, то тебе нужно будет либо работать с автором, чтобы перенести эти изменения в апстрим, либо поддерживать свою ветку со своим набором патчей, которые адаптировать после выхода новых версий.
3. Некоторые библиотеки написаны плохими программистами и несут с собой баги и ухудшение производительности.
4. Затрудняюсь сформулировать, что тут не так, но когда видишь, как простой проект тянет за собой сотни мегабайтов библиотек, есть ощущение, что что-то где-то пошло не туда.
Во многом это всё относится не только к непосредственно используемым библиотекам, но и к их зависимостям. Подтянул ты одну библиотеку, та подтянула вторую, а вторая подтянула древний asm, который не работает на какой-нибудь Java 15 и так просто не обновляется. И получается, что ты залочен на Java 14, пока вторую библиотеку не пофиксит автор. А автор ушёл в кругосветку и шатал все эти ваши джавы, у него просветление. И в итоге тебе придётся править библиотеку 2. А эти правки могут быть сложней, чем изначально написать небольшое количество кода, который ты решил заменить большой библиотекой 1.
А так, конечно, в целом библиотеки нужны и полезны. Особенно хорошие библиотеки. Лично я люблю велосипедить, но рекомендовать, наверное, не буду. Но плюсы и минусы есть в любом подходе.
Больше всего я люблю библиотеки, которые не тянут за собой другие зависимости, которые выполняют одну чётко очерченную задачу и неиспользуемый мной код никак не может заработать без моего ведома. Ну и которые написаны грамотно и давно.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, rosencrantz, Вы писали:
R>>1. Я могу не видеть всей сложности, поэтому чёрт его знает сколько это займёт. R>>2. Я могу не видеть всей сложности, поэтому моё решение может оказаться некорректным.
R3>Эти моменты актуальны и для кубика.
В какой-то степени может быть. Глядя на инструмент можно прикинуть сокращает он время решения или нет, делает ли он его более корректным или нет. Нормальные инструменты, как правило, ближе к "сокращают и/или делают более корректным", а не к "удлиняют и/или делают менее корректным".
R>>5. Взяв готовое решение я ещё забесплатно получаю сколько-то гибкости. Даже если сейчас мне ничего из этого не надо, я буду иметь в виду, что какие-то детали поведения поменять будет легко.
R3>Этот пункт подходит и для "не кубика"
Это разная гибкость. Пустой "int main()" — это виртуально бесконечная гибкость, но нафиг она такая нужна? Гибкость, которую дают кубики — это как правило готовые решения, которые остаётся только параметризировать под конкретную задачу.
R>>6. Чем меньше кода я напишу, тем меньше сопровождать, и тем меньше новым коллегам вникать.
R3>Сопровождение кубика всегда проще?
Вот из моего опыта — да. В большинстве случаев добавил и пользуешься, иногда переключаясь на более свежую версию. В редких случаях автор может забросить проект и тогда в какой-то момент нужно просто найти актуальный аналог. Такого что "прям сопровождать в шахте по пояс в холодной воде с руками, связанными за спиной" — ни разу не видел.
R>>Объясните популярно почему я неправ, почему из-за таких как я кто-то страдает, и как нужно делать на самом деле. Спасибо.
R3>Если что, я не против кубиков.
Здравствуйте, Muxa, Вы писали:
R>>Объясните популярно почему я неправ, почему из-за таких как я кто-то страдает, и как нужно делать на самом деле. Спасибо. M>Страдать будет пользователь из-за того что на каждый чих ты инициализируешь свой трактор, там где обойтись можно было лопатой.
Окей, пользователь страдает из-за тормозов, которых можно было избежать. Единственное ли это от чего страдает пользователь? Не страдает ли пользователь также из-за того, что у него синдром дефицита внимания и вообще функциональная неграмотность? Должен ли вместо пользователя страдать Я? Должен ли страдать дядька с деньгами, из-за которого я собственно делаю программу? Как правильно?
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, rosencrantz, Вы писали:
R>>Объясните популярно почему я неправ, почему из-за таких как я кто-то страдает, и как нужно делать на самом деле. Спасибо.
bnk>Тут в чем дело. bnk>Если библиотека нормальная, то это конечно все правильно и разумно.
bnk>Только вот "библиотеки" нынче пошли какие-то худосочные что ли. Получается замкнутый круг — и код большинство не пишет, а конструирует. bnk>Если посмотришь на гитхаб например, часто получается ситуация, что реально пишет код какой-нибудь китаец, а потом сто человек потом тупо его копипастят.
Как можно принципиально улучшить ситуацию? Я честно редко интересуюсь подробностями кто там кого за собой тянет. Я вижу библиотеку с кучей звёздочек на гитхабе, смотрю — выглядят ли примеры её использования вменяемо, и если всё ок — использую. Какие там за этим стоят китайцы — чёрт его знает. Как я мог бы поступать, чтобы и себе не в ущерб и худосочность не поощрять?
Здравствуйте, rosencrantz, Вы писали:
R>Окей, пользователь страдает из-за тормозов, которых можно было избежать. Единственное ли это от чего страдает пользователь? Не страдает ли пользователь также из-за того, что у него синдром дефицита внимания и вообще функциональная неграмотность? Должен ли вместо пользователя страдать Я? Должен ли страдать дядька с деньгами, из-за которого я собственно делаю программу? Как правильно?
Если от страданий пользователя зависит, купит он эту программу или нет, то вслед за пользователем будет страдать дядька с деньгами, а вслед за дядькой с деньгами ты.
Здравствуйте, vsb, Вы писали:
vsb>Минусы такого подхода:
vsb>1. В проекте будет огромное количество лишнего незадействованного кода. Это увеличивает число потенциальных уязвимостей. Простой пример: ты заюзал какую-нибудь XML-библиотеку, чтобы распарсить XML из трёх тегов. А XML-библиотека поддерживает миллиард возможностей, включая, например, скачивание DTD из внешних источников. И тебе подсовывают XML с DTD, который абузит это скачивание и закачивает тебе вирус на сервер. А ты про это вообще можешь не подозревать, ты библиотеку подключил, три строчки для парсинга написал и ушёл дальше.
Хороший минус! А как надо? Я наивно предполагаю, что если библиотекой пользуется куча народа, такого рода проблемы будут известны — либо конфигурация по умолчанию будет это запрещать, либо в документации жирными буквами будет написано на что обратить внимание при конфигурировании.
vsb>2. Каждая библиотека это обязательство. Тебе нужно следить за её версиями. Тебе, возможно, нужно будет дорабатывать её, если автор решит прекратить выпускать обновления. Если тебе нужно внести изменения в код библиотеки, то тебе нужно будет либо работать с автором, чтобы перенести эти изменения в апстрим, либо поддерживать свою ветку со своим набором патчей, которые адаптировать после выхода новых версий.
На практике ни разу с этим не сталкивался. Если автор бросает библиотеку, я ищу актуальный аналог и переписываю код, завязанный на старую библиотеку. Обычно это не редизайн, а реально мелочи. Если нужно вносить изменения в код библиотеки, с библиотекой однозначно что-то не то, и тут нужно либо искать другую, либо самостоятельно решать ту задачу, которую пытается решать библиотека.
vsb>3. Некоторые библиотеки написаны плохими программистами и несут с собой баги и ухудшение производительности.
Как убедиться, что этих плохие программисты — хуже меня?
vsb>4. Затрудняюсь сформулировать, что тут не так, но когда видишь, как простой проект тянет за собой сотни мегабайтов библиотек, есть ощущение, что что-то где-то пошло не туда.
vsb>Во многом это всё относится не только к непосредственно используемым библиотекам, но и к их зависимостям. Подтянул ты одну библиотеку, та подтянула вторую, а вторая подтянула древний asm, который не работает на какой-нибудь Java 15 и так просто не обновляется. И получается, что ты залочен на Java 14, пока вторую библиотеку не пофиксит автор. А автор ушёл в кругосветку и шатал все эти ваши джавы, у него просветление. И в итоге тебе придётся править библиотеку 2. А эти правки могут быть сложней, чем изначально написать небольшое количество кода, который ты решил заменить большой библиотекой 1.
Вот именно в этом случае — когда есть внятное объяснение "зачем писать руками", нужно взять и написать руками. Но ведь изначально ситуация была другая — есть задача и есть хорошая библиотека, которая эту задачу решает — зачем решать задачу самостоятельно?
vsb>А так, конечно, в целом библиотеки нужны и полезны. Особенно хорошие библиотеки. Лично я люблю велосипедить, но рекомендовать, наверное, не буду. Но плюсы и минусы есть в любом подходе.
Я тоже люблю велосипедить, но я это делаю отдельно от работы
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, rosencrantz, Вы писали:
R>>Окей, пользователь страдает из-за тормозов, которых можно было избежать. Единственное ли это от чего страдает пользователь? Не страдает ли пользователь также из-за того, что у него синдром дефицита внимания и вообще функциональная неграмотность? Должен ли вместо пользователя страдать Я? Должен ли страдать дядька с деньгами, из-за которого я собственно делаю программу? Как правильно?
ARK>Если от страданий пользователя зависит, купит он эту программу или нет, то вслед за пользователем будет страдать дядька с деньгами, а вслед за дядькой с деньгами ты.
Ну вот снова — если. А если изначально идея продукта хреновая? А если дизайн неудачный? Насколько я в общем случае улучшу ситуацию, если не буду тянуть тыщщи библиотек?
Здравствуйте, rosencrantz, Вы писали:
vsb>>1. В проекте будет огромное количество лишнего незадействованного кода. Это увеличивает число потенциальных уязвимостей. Простой пример: ты заюзал какую-нибудь XML-библиотеку, чтобы распарсить XML из трёх тегов. А XML-библиотека поддерживает миллиард возможностей, включая, например, скачивание DTD из внешних источников. И тебе подсовывают XML с DTD, который абузит это скачивание и закачивает тебе вирус на сервер. А ты про это вообще можешь не подозревать, ты библиотеку подключил, три строчки для парсинга написал и ушёл дальше.
R>Хороший минус! А как надо? Я наивно предполагаю, что если библиотекой пользуется куча народа, такого рода проблемы будут известны — либо конфигурация по умолчанию будет это запрещать, либо в документации жирными буквами будет написано на что обратить внимание при конфигурировании.
Ну как минимум выбирать форматы и код попроще. Т.е. в данном примере, возможно, лучше взять JSON. Ну или, прежде чем брать XML, хорошо изучить этот формат и понимать, что там происходит и убедиться, что в парсере отключено всё лишнее. А может быть достачно properties-файла.
vsb>>2. Каждая библиотека это обязательство. Тебе нужно следить за её версиями. Тебе, возможно, нужно будет дорабатывать её, если автор решит прекратить выпускать обновления. Если тебе нужно внести изменения в код библиотеки, то тебе нужно будет либо работать с автором, чтобы перенести эти изменения в апстрим, либо поддерживать свою ветку со своим набором патчей, которые адаптировать после выхода новых версий.
R>На практике ни разу с этим не сталкивался. Если автор бросает библиотеку, я ищу актуальный аналог и переписываю код, завязанный на старую библиотеку. Обычно это не редизайн, а реально мелочи. Если нужно вносить изменения в код библиотеки, с библиотекой однозначно что-то не то, и тут нужно либо искать другую, либо самостоятельно решать ту задачу, которую пытается решать библиотека.
Ну вот был log4j 1. Все на нём писали. Потом придумали logback, а log4j как-то умер. А код остался. Придумали ещё миллион адаптеров, всякие commons-logging, slf4j и прочее. Ещё там java util logging где-то болтается. Сейчас log4j внезапно воскрес в виде второй версии.
vsb>>3. Некоторые библиотеки написаны плохими программистами и несут с собой баги и ухудшение производительности.
R>Как убедиться, что этих плохие программисты — хуже меня?
Ну я читаю код и анализирую свои чувства. Смог бы я написать лучше или же я даже так не смог бы написать. Много ли у меня объективных придирок к этому коду. Например Spring в целом (его Core часть) мне очень нравится, я бы много там если бы и написал, то не с первого раза. А вот Spring JDBC уже не нравится. Apache POI меня откровенно раздражает (хотя альтернатив ему нет, так что тут, наверное, не в тему).
Здравствуйте, rosencrantz, Вы писали:
R>Когда сталкиваюсь с задачей, которая не выглядит специфичной для этого конкретного проекта, ни в коем случае не делаю своё решение, а ищу подходящую библиотеку/фреймворк.
В целом, подход верный. Чорт в деталях.
R> Если нужно собрать URL по кусочкам, я возьму библиотеку, которая строит URL по кусочкам, даже если мне всего-то надо "http://example.org/books/"+id сделать 1 раз на весь аппликейшн.
В составе фреймворка для этого есть класс UriBuilder.
R>1. Я могу не видеть всей сложности, поэтому чёрт его знает сколько это займёт.
Ты так же можешь не видеть всей сложности использования неизвестной библиотеки.
R>2. Я могу не видеть всей сложности, поэтому моё решение может оказаться некорректным.
Ровно так же стороннее решение тоже может оказаться некорректным, и это хуже потому что исходно эта библиотека для тебя — черный ящик.
R>3. Я вижу достаточно сложности, чтобы не захотеть решать задачу самостоятельно.
И не видишь сложности поиска и фикса баги внутри сторонней библиотеки.
R>4. В будущем я могу встретиться с вариацией этой задачи — и буду действовать более эффективно, если сейчас выясню, что есть готовое решение.
Ровно так же в будущем может оказаться, что вариаций этой задачи тебе больше не встретится и время на освоение гибкой библиотеки будет потрачено зря.
R>5. Взяв готовое решение я ещё забесплатно получаю сколько-то гибкости.
Как правило — совсем не забесплатно. За все приходится платить, в лучшем случае усложнением контрактов, в худшем — багами и перфомансом.
R>6. Чем меньше кода я напишу, тем меньше сопровождать,
Если тянуть библиотеку для проверки значения переменной среды, то может оказаться что кода придется написать больше.
R> и тем меньше новым коллегам вникать.
А в новую библиотеку коллегам вникать не надо? По моему в код в проекте вникнуть проще, чем в код сторонней библиотеки, не?
R>7. Если я даже напишу своё решение, я же не буду его документировать, а у библиотеки есть документация.
Или нет.
R>8. Библиотека моделирует задачу, поэтому пристально посмотрев на библиотеку (на интерфейс) можно узнать больше о задаче, о том как её можно интерпретировать и о том, как вообще она решается.
Здравствуйте, rosencrantz, Вы писали:
R>На практике ни разу с этим не сталкивался. Если автор бросает библиотеку, я ищу актуальный аналог и переписываю код, завязанный на старую библиотеку. Обычно это не редизайн, а реально мелочи. Если нужно вносить изменения в код библиотеки, с библиотекой однозначно что-то не то, и тут нужно либо искать другую, либо самостоятельно решать ту задачу, которую пытается решать библиотека.
Ниже привели отличный пример с логгером, который реально проникает повсюду и замену которому не так просто найти, потому что придётся тестировать буквально всё.
Также, например, дела обстоят с boost из С++, который может проникать повсюду. Много таких библиотек, на которые можно "подсесть".
Здравствуйте, rosencrantz, Вы писали:
R>Когда сталкиваюсь с задачей, которая не выглядит специфичной для этого конкретного проекта, ни в коем случае не делаю своё решение, а ищу подходящую библиотеку/фреймворк. Без исключений.
Свойства твоего решения — огромное количество зависимостей. С ними всегда возникаются проблемы
— их всё равно желательно изолировать, врапать в своё, что бы они не проросли в основной код. Иначе есть шанс сесть себе на хер, когда потребуется поменять зависимость.
— иногда они глючат, а фикса нет или релизный цикл не совпадает с твоим
— иногда они конфликтуют
— иногда для них приходится выстраивать взаимодействие
— изменять дизайн этих вещей невозможно, а потому приходится дублировать часть их функционала, врапать и тд
— их нужно изучать и это надо помножить на количество разработчиков.
— их далеко не всега можно отлаживать, например, только ради того, что бы узнать, где в своём коде нужно поставить брейкпоинт
— их нужно периодически обновлять. Со временем это становится камнем преткновение и мешает промигрироваться, например, на новую версию основного фремворка
— следить за лицензией
— проект раздувается в размере
В целом, нужен баланс. Поначалу всё ускоряется, идет быстро. А потом всё замедляется из за проблем выше.
R>Объясните популярно почему я неправ, почему из-за таких как я кто-то страдает, и как нужно делать на самом деле. Спасибо.
Тащить зависимости нужно в тех случаях, когда
1. сложность известная и высока (сложные алгоритмы)
2. трудоемкость известная и высока (просто много работы)
3. цена ошибки велика (раз ошибся и клиент здох)
Отсюда ясно, что склейку строк проще, дешевле и надежнее выделить в отдельную функцию и покрыть юнит-тестом. Далее, если у тебя появится сотня правил для склейки, внутренности этой функции можно переделать хоть на шаблонизатор, хоть на что угодно. Но это потом — когда потребуется. п.3 цена ошибки
Переменные окружения — аналогично. Для разового проще, дешевле, надежнее вынести в функцию и покрыть тестом. Если много работы с переменными окружениям, п.3 цена ошибки.
Когда стоит брать 3rd party изначально
— ОРМ или подобная механика
— АПИ к какому либо сервису
— реализация протокола
— каркас приложения, если проект для продакшна
Стоит избегать 3rd party
— если пилишь свой фремворк. В этом случае желательно использовать подход zero dependency кроме исключительных случаяв
— проект изначально нетривиальный, здесь важнее контроль над всеми аспектами
— проект предполагается долгоиграющим — на длинной дистанции зависимости гарантировано умрут каждая по нескольку раз задолго до окончания проекта.
Dependencies (coupling) is an important concern to address, but it's only 1 of 4 criteria that I consider and it's not the most important one. I try to optimize my code around reducing state, coupling, complexity and code, in that order. I'm willing to add increased coupling if it makes my code more stateless. I'm willing to make it more complex if it reduces coupling. And I'm willing to duplicate code if it makes the code less complex. Only if it doesn't increase state, coupling or complexity do I dedup code.
Здравствуйте, rosencrantz, Вы писали:
R>Окей, пользователь страдает из-за тормозов, которых можно было избежать. Единственное ли это от чего страдает пользователь? Не страдает ли пользователь также из-за того, что у него синдром дефицита внимания и вообще функциональная неграмотность? Должен ли вместо пользователя страдать Я? Должен ли страдать дядька с деньгами, из-за которого я собственно делаю программу? Как правильно?
А ты тоже будешь страдать. Вместо того, чтобы за минуту прочитать короткое описание функции getenv, ты будешь медитировать над библиотекой. Или над ошибками из-за неверного использования библиотеки. Но сначала окажется, что ее и подключить нетривиально.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, rosencrantz, Вы писали:
R>Когда сталкиваюсь с задачей, которая не выглядит специфичной для этого конкретного проекта, ни в коем случае не делаю своё решение, а ищу подходящую библиотеку/фреймворк. Без исключений. Даже если нужно просто прочитать одну переменную окружения и ругнуться, что там пусто, я возьму библиотеку, которая читает переменные окружения и валидирует, и буду использовать её. Если нужно собрать URL по кусочкам, я возьму библиотеку, которая строит URL по кусочкам, даже если мне всего-то надо "http://example.org/books/"+id сделать 1 раз на весь аппликейшн.
Про left-pad уже написали?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, rosencrantz, Вы писали:
R>>Окей, пользователь страдает из-за тормозов, которых можно было избежать. Единственное ли это от чего страдает пользователь? Не страдает ли пользователь также из-за того, что у него синдром дефицита внимания и вообще функциональная неграмотность? Должен ли вместо пользователя страдать Я? Должен ли страдать дядька с деньгами, из-за которого я собственно делаю программу? Как правильно?
Ops>А ты тоже будешь страдать. Вместо того, чтобы за минуту прочитать короткое описание функции getenv, ты будешь медитировать над библиотекой. Или над ошибками из-за неверного использования библиотеки. Но сначала окажется, что ее и подключить нетривиально.
Я думаю такие проблемы с библиотеками есть только у людей, не использующих библиотеки. Нет опыта с библиотеками -> сложно понять хороша очередная библиотека или нет -> не буду использовать библиотеку -> нет опыта с библиотеками.
Что именно ты будешь делать с getenv? Впилишь его по месту — где он нужен, без тестов, без обвязки? Или потратишь N часов на обвязку, тесты и документацию? В типичном аппликейшне из моей реальности есть, скажем, штук 10 параметров, которые приходят из переменных окружения. В коде они мне конечно нужны не как сырые строки, а как типизированные значения — и если там в каких-то из этих переменных оказалась ерунда, здорово помогает когда программа падает с внятными ошибками типа "в перменной окружения XXX должно быть число, а у вас там фигня какая-то" вместо стектрейса, рассказывающего про падение Integer.valueOf() где-то в readConfig на строчке 41.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, rosencrantz, Вы писали:
R>>Когда сталкиваюсь с задачей, которая не выглядит специфичной для этого конкретного проекта, ни в коем случае не делаю своё решение, а ищу подходящую библиотеку/фреймворк. Без исключений. Даже если нужно просто прочитать одну переменную окружения и ругнуться, что там пусто, я возьму библиотеку, которая читает переменные окружения и валидирует, и буду использовать её. Если нужно собрать URL по кусочкам, я возьму библиотеку, которая строит URL по кусочкам, даже если мне всего-то надо "http://example.org/books/"+id сделать 1 раз на весь аппликейшн.
Ops>Про left-pad уже написали?
Не писали, но я знаю этот прикол. Разница в том, что left-pad — это совсем тривиальная штука без каких либо вариаций, а "собрать URL" — нетривиальная. Сегодня у тебя "base_url + id" закрывает проблему, а завтра нужно по кусочкам добавить "?xxx=a%20b%20c&yyy=d%20e" — и всё, на тупой конкатенации далеко не уедешь. Вопрос — нахрена делать эту дизайн-пессимизацию оставляя себе и коллегам сюрприз на будущее, если построение URL — это типичная задача у которой уже есть готовые внятные решения? Есть задача — построить URL, ну так и используй язык построения URL, а не скручивание строк.
