2Framework | !2Framework

“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: lc@yandex.ru
Skype: denis.tsyplakov
Спасибо