1 / 23

2013

“2Framework | !2Framework”. Стоит ли строить свой фреймворк ?. 2013. Зачем об этом говорить. Perfect time hog Большое кол-во фэйлов связано именно с попытками вначале написать фреймворк, а потом полететь. Вина ли тут именно фреймворков ?. Откуда есть пошли фреймворки. Подпрограммы

ezra
Télécharger la présentation

2013

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

  5. Пример«Вычисление факториала» • По мотивам 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; }

  6. Step 2 Давайте кэшировать результаты и использовать BigInteger static HashMap<Integer,BigInteger> cache = new HashMap<Integer,BigInteger>(); public static BigInteger factorial(int n) { BigIntegerret; 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; }

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

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

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

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

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

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

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

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

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

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

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

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

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

  20. Вопросы Email: lc@yandex.ru Skype: denis.tsyplakov

  21. Спасибо

More Related