2013 2Framework | !2Framework Стоит ли строить свой фреймворк?

Зачем об этом говорить Perfect time hog Большое кол-во фэйлов связано именно с попытками вначале написать фреймворк, а потом полететь. Вина ли тут именно фреймворков?

Откуда есть пошли фреймворки Подпрограммы Библиотеки ОС Фреймворки, Runtime etc В 60-х годах идея написать свою ОС под задачу рассматривалась вполне серьезно В один мой знакомый писал многозадачную ОС альтернативную MS DOS, з/п ему платил завод (не скажу какой).

Рассмотрим пример

Пример «Вычисление факториала» По мотивам Задача – надо вычислить факториал Простой способ: public static int factorial(int n) { if (n == 0) return 1; return n * factorial(n-1); } Стоп, это же рекурсия public static int factorial(int n) { int ret = 1; for (int i = 1; i

Step 2 Давайте кэшировать результаты и использовать BigInteger static HashMap cache = new HashMap (); public static BigInteger factorial(int n) { BigInteger ret; if (n == 0) return BigInteger.ONE; if (null != (ret = cache.get(n))) return ret; ret = BigInteger.valueOf(n).multiply(factorial(n-1)); cache.put(n, ret); return ret; }

Step 3 Алгоритмов много, надо иметь возможность выбора

Step 4 Но как же динамическое подключение и регистрация алгоритмов? Надо иметь возможность добавлять алгоритмы «на ходу» из третье-стороннего кода

В результате 200 строк кода, 5 классов и один интерфейс, расширяемая архитектура. Что улучшить? – Добавить библиотеку алгоритмов – Сделать возможность конфигурирования в XML – Настраивать алгоритм в зависимости от пакета, из которого вызывается функция Мы молодцы? Это код достоин подражания?

Нет, не молодцы. В 99% случаев это никому не нужный код Такая архитектура делает простое действие нечеловечески сложным Если через год надо будет что-то добавить, вы вообще вспомните как тут все устроено? Или надо будет все переписать? Вместо того чтобы заменить 3 строчки кода в том редком случае, когда самый первый не- рекурсивный алгоритм действительно не подходит, мы нагородили кучу сложного кода

И, кстати, кто-нибудь вспомнил о том, что надо обрабатывать отрицательные значения?

А теперь серьезно За и против

Виды фреймворков 1.Business frameworks (функциональные требования) 2.Utility frameworks (не функциональные требования) 3.Area specific (3 rd party integration) 4.BLL (Business Level Layer) – не путать с #1

PRO Экономит время за счет code reuse Позволяет писать более чистый код в терминах бизнес логики == меньше ошибок, проще сопровождать В 90% случаях нравится команде «мы пишем не какой-то индусский код»

CON Требования меняются так, что все равно Фреймворк придется существенно переписывать В 95% случаев все до нас уже придумано В большом кол-ве проектов дешевле написать «в лоб» Те кто будут потом поддерживать код 1.Фреймворк не оценят, скажут, что написано на коленке и надо заменить на стандартное решение, даже если Фреймворк был мега-хороший. 2.Идею написания Фреймворка оценят, но скажут, что ваш фигня, и они напишут лучше.

CON 2 Передача знания существенно усложняется Писать Фреймворки для совершенствования какого-то аспекта ПО надо. Но надо, только если до этого 5-10 похожих проектов вы сделали руками. А мы обычно делаем ровно наоборот. Когда в 3-месячном проекте Вам надо 1 месяц на написание фреймворка НЕВОЗМОЖНО понять, в правильном ли направлении в течение этого месяца Вы движетесь. И особенно это сложно понять заказчику.

Почему вообще тема всплыла? Если Вы программировали на Turbo Pascal в 1990 году, то для построения UI вообще ничего не было Если Вы программируете сейчас на Яве для веб, то к вашим услугам >100 фреймворков. Ситуация изменилась, люди меняются медленнее

Немного теории: Талебский Черный Лебедь

Summary Если в проекте Вы хотите потратить >1-3 дней на что-то, что можно назвать словом Фреймворк, посоветуйтесь с коллегами Или даже если Вы хотите сделать REST библиотеку для реализации двух простых API вызовов, все равно посоветуйтесь Software development is overframeworked, будьте прагматичны

Вопросы Skype: denis.tsyplakov

Спасибо