“2Framework | !2Framework” Стоит ли строить свой фреймворк? 2013 Зачем об этом говорить • Perfect time hog • Большое кол-во фэйлов связано именно с попытками вначале написать фреймворк, а потом полететь. • Вина ли тут именно фреймворков? Откуда есть пошли фреймворки • • • • Подпрограммы Библиотеки ОС Фреймворки, Runtime etc • В 60-х годах идея написать свою ОС под задачу рассматривалась вполне серьезно • В 90-91 один мой знакомый писал многозадачную ОС альтернативную MS DOS, з/п ему платил завод (не скажу какой). Рассмотрим пример Пример «Вычисление факториала» • По мотивам http://goo.gl/zoSa7 • Задача – надо вычислить факториал • Простой способ: 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 <= n; ++i) ret *= i; return ret; } Step 2 Давайте кэшировать результаты и использовать BigInteger static HashMap<Integer,BigInteger> cache = new HashMap<Integer,BigInteger>(); 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 (3rd 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, будьте прагматичны Вопросы Email: [email protected] Skype: denis.tsyplakov Спасибо