Сообщение Re: Из кубиков от 02.10.2020 12:43
Изменено 02.10.2020 12:45 Pauel
Re: Из кубиков
Здравствуйте, rosencrantz, Вы писали:
R>Когда сталкиваюсь с задачей, которая не выглядит специфичной для этого конкретного проекта, ни в коем случае не делаю своё решение, а ищу подходящую библиотеку/фреймворк. Без исключений.
Свойства твоего решения — огромное количество зависимостей. С ними всегда возникаются проблемы
— их всё равно желательно изолировать, врапать в своё, что бы они не проросли в основной код. Иначе есть шанс сесть себе на хер, когда потребуется поменять зависимость.
— иногда они глючат, а фикса нет или релизный цикл не совпадает с твоим
— иногда они конфликтуют
— иногда для них приходится выстраивать взаимодействие
— изменять дизайн этих вещей невозможно, а потому приходится дублировать часть их функционала, врапать и тд
— их нужно изучать
— их далеко не всега можно отлаживать, например, только ради того, что бы узнать, где в своём коде нужно поставить брейкпоинт
— их нужно периодически обновлять. Со временем это становится камнем преткновение и мешает промигрироваться, например, на новую версию фремворка
— следить за лицензией
— проект раздувается в размере
В целом, нужен баланс. Поначалу всё ускоряется, идет быстро. А потом всё замедляется из за проблем выше.
R>Объясните популярно почему я неправ, почему из-за таких как я кто-то страдает, и как нужно делать на самом деле. Спасибо.
Тащить зависимости нужно в тех случаях, когда
1. сложность известная и высока (сложные алгоритмы)
2. трудоемкость известная и высока (просто много работы)
3. цена ошибки велика (раз ошибся и клиент здох)
Отсюда ясно, что склейку строк проще, дешевле и надежнее выделить в отдельную функцию и покрыть юнит-тестом. Далее, если у тебя появится сотня правил для склейки, внутренности этой функции можно переделать хоть на шаблонизатор, хоть на что угодно. Но это потом — когда потребуется. п.3 цена ошибки
Переменные окружения — аналогично. Для разового проще, дешевле, надежнее вынести в функцию и покрыть тестом. Если много работы с переменными окружениям, п.3 цена ошибки.
Когда стоит брать 3rd party изначально
— ОРМ или подобная механика
— АПИ к какому либо сервису
— реализация протокола
— каркас приложения, если проект для продакшна
Стоит избегать 3rd party
— если пилишь свой фремворк. В этом случае желательно использовать подход zero dependency кроме исключительных случаяв
— проект изначально нетривиальный, здесь важнее контроль над всеми аспектами
— проект предполагается долгоиграющим — на длинной дистанции зависимости гарантировано умрут каждая по нескольку раз задолго до окончания проекта.
R>Когда сталкиваюсь с задачей, которая не выглядит специфичной для этого конкретного проекта, ни в коем случае не делаю своё решение, а ищу подходящую библиотеку/фреймворк. Без исключений.
Свойства твоего решения — огромное количество зависимостей. С ними всегда возникаются проблемы
— их всё равно желательно изолировать, врапать в своё, что бы они не проросли в основной код. Иначе есть шанс сесть себе на хер, когда потребуется поменять зависимость.
— иногда они глючат, а фикса нет или релизный цикл не совпадает с твоим
— иногда они конфликтуют
— иногда для них приходится выстраивать взаимодействие
— изменять дизайн этих вещей невозможно, а потому приходится дублировать часть их функционала, врапать и тд
— их нужно изучать
— их далеко не всега можно отлаживать, например, только ради того, что бы узнать, где в своём коде нужно поставить брейкпоинт
— их нужно периодически обновлять. Со временем это становится камнем преткновение и мешает промигрироваться, например, на новую версию фремворка
— следить за лицензией
— проект раздувается в размере
В целом, нужен баланс. Поначалу всё ускоряется, идет быстро. А потом всё замедляется из за проблем выше.
R>Объясните популярно почему я неправ, почему из-за таких как я кто-то страдает, и как нужно делать на самом деле. Спасибо.
Тащить зависимости нужно в тех случаях, когда
1. сложность известная и высока (сложные алгоритмы)
2. трудоемкость известная и высока (просто много работы)
3. цена ошибки велика (раз ошибся и клиент здох)
Отсюда ясно, что склейку строк проще, дешевле и надежнее выделить в отдельную функцию и покрыть юнит-тестом. Далее, если у тебя появится сотня правил для склейки, внутренности этой функции можно переделать хоть на шаблонизатор, хоть на что угодно. Но это потом — когда потребуется. п.3 цена ошибки
Переменные окружения — аналогично. Для разового проще, дешевле, надежнее вынести в функцию и покрыть тестом. Если много работы с переменными окружениям, п.3 цена ошибки.
Когда стоит брать 3rd party изначально
— ОРМ или подобная механика
— АПИ к какому либо сервису
— реализация протокола
— каркас приложения, если проект для продакшна
Стоит избегать 3rd party
— если пилишь свой фремворк. В этом случае желательно использовать подход zero dependency кроме исключительных случаяв
— проект изначально нетривиальный, здесь важнее контроль над всеми аспектами
— проект предполагается долгоиграющим — на длинной дистанции зависимости гарантировано умрут каждая по нескольку раз задолго до окончания проекта.
Re: Из кубиков
Здравствуйте, rosencrantz, Вы писали:
R>Когда сталкиваюсь с задачей, которая не выглядит специфичной для этого конкретного проекта, ни в коем случае не делаю своё решение, а ищу подходящую библиотеку/фреймворк. Без исключений.
Свойства твоего решения — огромное количество зависимостей. С ними всегда возникаются проблемы
— их всё равно желательно изолировать, врапать в своё, что бы они не проросли в основной код. Иначе есть шанс сесть себе на хер, когда потребуется поменять зависимость.
— иногда они глючат, а фикса нет или релизный цикл не совпадает с твоим
— иногда они конфликтуют
— иногда для них приходится выстраивать взаимодействие
— изменять дизайн этих вещей невозможно, а потому приходится дублировать часть их функционала, врапать и тд
— их нужно изучать
— их далеко не всега можно отлаживать, например, только ради того, что бы узнать, где в своём коде нужно поставить брейкпоинт
— их нужно периодически обновлять. Со временем это становится камнем преткновение и мешает промигрироваться, например, на новую версию основного фремворка
— следить за лицензией
— проект раздувается в размере
В целом, нужен баланс. Поначалу всё ускоряется, идет быстро. А потом всё замедляется из за проблем выше.
R>Объясните популярно почему я неправ, почему из-за таких как я кто-то страдает, и как нужно делать на самом деле. Спасибо.
Тащить зависимости нужно в тех случаях, когда
1. сложность известная и высока (сложные алгоритмы)
2. трудоемкость известная и высока (просто много работы)
3. цена ошибки велика (раз ошибся и клиент здох)
Отсюда ясно, что склейку строк проще, дешевле и надежнее выделить в отдельную функцию и покрыть юнит-тестом. Далее, если у тебя появится сотня правил для склейки, внутренности этой функции можно переделать хоть на шаблонизатор, хоть на что угодно. Но это потом — когда потребуется. п.3 цена ошибки
Переменные окружения — аналогично. Для разового проще, дешевле, надежнее вынести в функцию и покрыть тестом. Если много работы с переменными окружениям, п.3 цена ошибки.
Когда стоит брать 3rd party изначально
— ОРМ или подобная механика
— АПИ к какому либо сервису
— реализация протокола
— каркас приложения, если проект для продакшна
Стоит избегать 3rd party
— если пилишь свой фремворк. В этом случае желательно использовать подход zero dependency кроме исключительных случаяв
— проект изначально нетривиальный, здесь важнее контроль над всеми аспектами
— проект предполагается долгоиграющим — на длинной дистанции зависимости гарантировано умрут каждая по нескольку раз задолго до окончания проекта.
R>Когда сталкиваюсь с задачей, которая не выглядит специфичной для этого конкретного проекта, ни в коем случае не делаю своё решение, а ищу подходящую библиотеку/фреймворк. Без исключений.
Свойства твоего решения — огромное количество зависимостей. С ними всегда возникаются проблемы
— их всё равно желательно изолировать, врапать в своё, что бы они не проросли в основной код. Иначе есть шанс сесть себе на хер, когда потребуется поменять зависимость.
— иногда они глючат, а фикса нет или релизный цикл не совпадает с твоим
— иногда они конфликтуют
— иногда для них приходится выстраивать взаимодействие
— изменять дизайн этих вещей невозможно, а потому приходится дублировать часть их функционала, врапать и тд
— их нужно изучать
— их далеко не всега можно отлаживать, например, только ради того, что бы узнать, где в своём коде нужно поставить брейкпоинт
— их нужно периодически обновлять. Со временем это становится камнем преткновение и мешает промигрироваться, например, на новую версию основного фремворка
— следить за лицензией
— проект раздувается в размере
В целом, нужен баланс. Поначалу всё ускоряется, идет быстро. А потом всё замедляется из за проблем выше.
R>Объясните популярно почему я неправ, почему из-за таких как я кто-то страдает, и как нужно делать на самом деле. Спасибо.
Тащить зависимости нужно в тех случаях, когда
1. сложность известная и высока (сложные алгоритмы)
2. трудоемкость известная и высока (просто много работы)
3. цена ошибки велика (раз ошибся и клиент здох)
Отсюда ясно, что склейку строк проще, дешевле и надежнее выделить в отдельную функцию и покрыть юнит-тестом. Далее, если у тебя появится сотня правил для склейки, внутренности этой функции можно переделать хоть на шаблонизатор, хоть на что угодно. Но это потом — когда потребуется. п.3 цена ошибки
Переменные окружения — аналогично. Для разового проще, дешевле, надежнее вынести в функцию и покрыть тестом. Если много работы с переменными окружениям, п.3 цена ошибки.
Когда стоит брать 3rd party изначально
— ОРМ или подобная механика
— АПИ к какому либо сервису
— реализация протокола
— каркас приложения, если проект для продакшна
Стоит избегать 3rd party
— если пилишь свой фремворк. В этом случае желательно использовать подход zero dependency кроме исключительных случаяв
— проект изначально нетривиальный, здесь важнее контроль над всеми аспектами
— проект предполагается долгоиграющим — на длинной дистанции зависимости гарантировано умрут каждая по нескольку раз задолго до окончания проекта.