Разработка веб-приложений 01

Transcript

1. Разработка веб-приложений лекция 1
2. Цели курса Изучить принципы разработки программного обеспечения: узнать о задачах и возможностях их решений Пройти все этапы создания продукта от идеи до выкладывания на публику Решить задачи клиентов Серверное программирование: Ruby on Rails Клиентское программирование: HTML, CSS, AJAX, JavaScript Развёртывание приложения
3. Литература http://beta.saasbook.info http://www.ozon.ru/context/detail/id/5704300/ http://pragprog.com/book/rails4/agile-web- development-with-rails http://pragprog.com/book/hwcuc/the-cucumber-book http://pragprog.com/book/achbd/the-rspec-book
4. Разработка программного обеспечения отличается от создания аппаратного обеспечения
5. Software vs. Hardware В: Почему существует так много программных катастроф и нет аппаратных? Ariane 5 ($ 350М)
6. Software vs. Hardware В: Почему существует так много программных катастроф и нет аппаратных? Ariane 5 ($ 350М) О: Это две разные среды и, соответственно, культуры разработки.
7. Готовый продукт vs. постоянное улучшение Стоимость апгрейда. Hardware: ∞ Разработка должна быть завершена до начала производства и доставки. В случае ошибок: возврат (очень плохо). Software: ~0 Ожидается, что со временем программа будет улучшаться. Есть ошибки? Скачай новую версию. Hardware устаревает. Software живёт очень-очень долго.
8. Унаследованный код vs. Красивый код Legacy code: старое SW, которое всё ещё удовлетворяет потребности клиента. Его сложно развивать и улучшать из-за ошибок в проектировании или древних технологий. 60% от стоимости поддержки старого кода — добавление нового функционала. 17% — исправление ошибок. Beautiful code: удовлетворяет потребности клиента и легок в поддержке и развитии.
9. Модели разработки ПО: Водопад + Спираль + Agile
10. Модели разработки ПО Водопад или каскадная модель a.k.a. «Big Design Up Front» или BDUF
11. Водопад Водопад или каскадная модель a.k.a. «Big Design Up Front» или BDUF Этапы: Определение требований Проектирование Воплощение Тестирование Инсталляция Поддержка
12. Водопад Полностью закончить одну фазу перед стартом следующей. Зачем? Чем раньше найден баг — тем дешевле он обходится проекту. Очень-очень много документации: новому человеку проще втянуться в работу. Для кого это хорошо работает? Для NASA. Какие проблемы? Клиентам может не понравиться то, что они увидят в конце. Очень часто только по завершении работы разработчики понимают как это надо было сделать на самом деле.
13. Спираль Объединение BDUF с прототипами. Вместо того, чтобы документировать все требования сразу, разрабатываются прототипы, постепенно приводящие продукт к завершению.
14. Спираль
15. Спираль Клиенты привлекаются до полного завершения работ, что уменьшает шансы недопонимания. Тем не менее, это требует очень много времени (от 6 до 24 месяцев). Клиенты могут передумать: «Это то, что мы просили, но не то, что мы хотим.»
16. Agile Manifesto http://agilemanifesto.org Личности и их взаимодействия важнее, чем процессы и инструменты. Работающее программное обеспечение важнее, чем полная документация. Сотрудничество с заказчиком важнее, чем контрактные обязательства. Реакция на изменения важнее, чем следование плану.
17. Agile цикл Изменения неизбежны — примите это. Вместо циклов разработки — постоянное улучшение продукта. Разработчики постоянно улучшают не до конца готовый, но работающий продукт, получая отзывы от клиентов в конце каждой итерации (каждые ~2 недели). Agile использует Test-Driven Development (TDD) для уменьшения ошибок, User Stories для валидации требований клиентов, Velocity для измерения прогресса.
18. Agile итерация Говорим с клиентом Behavior-Driven Design: User Stories Test-Driven Design: Unit Test Измеряем velocity Развёртываем
19. Разница между водопадом и Agile в том, что Agile не изпользует спецификацию требования?
20. Разница между Agile и Спиралью заключается в разработке версий продуктов и общению с заказчиками во время работы.
21. Гарантия: тестирование и формальные методы
22. Гарантия Верификаци: Вы создали продукт правильно? Продукт отвечает спецификации? Валидация: Вы создали правильный продукт? Это то, что хотел клиент? Верна ли спецификация? HW — верификация, SW — валидация. 2 варианта проверки: тестирование и формальные методы.
23. Тестирование Всестороннее тестирование невозможно Разделяй и властвуй: на разных этапах разработки пишутся разные тесты. Одни тесты не должны повторять другие. Системные или приёмочные тесты Программа отвечает своим спецификациям. Интеграционные тесты Интерфейсы между модулями соответствуют предположениям и работают корректно. Модульные (функциональные) Проверяют работу между классами, а не внутри класса. Юнит-тесты Отдельный метод делает то, что должен.
24. Ещё тестирование Покрытие кода: % от кода, который проверяется при тестировании. Регрессионное тестирование: выполнение старых тестов, чтобы удостовериться, что новый функционал не сломал старый. Непрерывная интеграция: постоянное регрессионное тестирование на каждом этапе. Agile => Test-Driven Design (TDD): написание тестов до написания самого кода.
25. Эдсгер Дейкстра Лауреат премии Тьюринга 1972 года. «Тестирование программ может использоваться для демонстрации ________ ошибок, но оно никогда не покажет их __________.»
26. Эдсгер Дейкстра Лауреат премии Тьюринга 1972 года. «Тестирование программ может использоваться для демонстрации наличия ошибок, но оно никогда не покажет их отсутствие.»
27. Формальные методы Начинаем с формальной спецификации и доказываем, что поведение программы ей соответствует. Варианты: Человек Компьютер с помощью методов автоматического доказательства теорем. Компьютер с помощью проверки моделей. Проверяет все возможные состояния системы.
28. Формальные методы Очень много вычислений: Небольшие, редко меняющиеся функции. Сложные в починке, сложные в тестировании. SW критичное к безопасности. Тестирование ядра ОС: 10К LOC => $500/LOC NASA SW $80/LOC В веб-разработке SW быстро меняется, легко чинится, легко тестируется => формальные методы не нужны.
29. Все перечисленные методы помогают при верификации продукта. Какой из них лучше всего подходит для валидации? Юнит-тесты, модульные тесты, интеграционные тесты или приёмочные тесты?
30. Все перечисленные методы помогают при верификации продукта. Какой из них лучше всего подходит для валидации? Юнит-тесты, модульные тесты, интеграционные тесты или приёмочные тесты?
31. Что из этого неверно? Чем больше покрытие кода тестами, тем вероятнее, что вы найдете ошибки в коде. Хоть и трудно достижимо, но 100% покрытие кода тестами даёт уверенность в праивльности работы программы. Каждый тест верхнего уровня делегирует детальное тестирование на тесты низких уровней. Юнит-тестирование работает с отдельным классом, а модульное тестирование с набором классов.
32. Что из этого неверно? Чем больше покрытие кода тестами, тем вероятнее, что вы найдете ошибки в коде. Хоть и трудно достижимо, но 100% покрытие кода тестами даёт уверенность в праивльности работы программы. Каждый тест верхнего уровня делегирует детальное тестирование на тесты низких уровней. Юнит-тестирование работает с отдельным классом, а модульное тестирование с набором классов.
33. Продуктивность Закон Мура: каждые 18 месяцев мощность оборудования увеличивается в 2 раза. HW становится можщнее. Быстрые процессоры и много памяти. SW становится «мощнее». Приходится увеличивать КПД своей работы. Ясность и краткость Синтез Повторное использование Автоматизация и инструменты
34. Ясность и краткость Синтаксис, короткий и хорошо читаемый assert_greater_than_or_equal_to(a, 7) vs. a.should be >= 7 Повышение уровня абстракции: Языки высокого уровня против ассемблера Автоматическое управление памятью: Java против C Скриптовые языки программировани: отражение и метапрограммирование.
35. Повторное использование Лучше использовать написанное еще раз, чем писать новое. Техники повторного использования: процедуры и функции стандартные библиотеки объектно-ориентированное программирование: повторное использование набора поведений Паттерны проектирования: повторное использование архитектуры системы, даже в тех случаях, когда реализации отличаются.
36. Автоматизация и инструменты Замена повторяющихся рутинных действий на автоматические, чтобы экономить время и повысить аккуратность. make Инструменты должны быть надёжными, функциональными и «комфортными». Хороший разработчик постоянно изучает новые инструменты: Cucumber, RSpec, ...
37. Какой механизм повышения продуктивности имеет наименьшее значение при разговоре о компиляторах? Ясность и краткость Синтез Повторное использование Автоматизация и инструменты
38. Какой механизм повышения продуктивности имеет наименьшее значение при разговоре о компиляторах? Ясность и краткость Синтез Повторное использование Автоматизация и инструменты
39. Copy+Paste — хороший метод повторного использования. Из 4 методик увеличения производительности главной для языков высокого уровня является повторное использование кода. Ясный синтаксис скорее всего будет приводить к меньшему количеству ошибок и будет легче в поддержке. Что из этого верно?
40. Copy+Paste — хороший метод повторного использования. Из 4 методик увеличения производительности главной для языков высокого уровня является повторное использование кода. Ясный синтаксис скорее всего будет приводить к меньшему количеству ошибок и будет легче в поддержке. Что из этого верно?
41. DRY = Don’t Repeat Yourself Если придётся чинить/менять — это придётся делать в нескольких местах.
42. SaaS Software as a Service = Программное обеспечение как услуга. Традиционное SW: программа устанавливается и работает на компьютере пользователя. SaaS доставляет SW и данные пользователю через интернет с помощью тонкого клиента (браузер). Поиск, социальные сети, видео Microsoft Office 365 SaaS — это будущее.
43. 6 причин для SaaS Не надо устанавливать, заботиться о HW, OS. Не надо переживать за утрату данных. (Почти!) Группам легче работать с одими и теми же данными. Если данных много и они часто меняются, проще держать одну копию на центральном сервере. 1 копия SW, контролируемое HW окружение => разработчики не отвлекаются на совместимость. 1 копия => упрощает апгрейд для разработчиков и «прячет» от пользователей.
44. SaaS любит Agile и Rails Частые апгрейды соотносятся с Agile циклом. Много фреймворков для Agile/SaaS. Ruby on Rails = <3 Ruby — современный скриптовый язык: объектно- ориентированный, функциональный, автоматическое управление памятью, динамическая типизация, повторное использование с помощью модулей, метапрограммирование. Rails популярен: Twitter, Github, Groupon, ...
45. Что является самым слабым аргументом в популярности приложений Google, как SaaS? Не теряет данные: Почта. Работа в группах: Документы. Большой/изменяющийся объем данных: YouTube. Нет необходимости в апгрейде при обновлении приложения: Поиск
46. Что является самым слабым аргументом в популярности приложений Google, как SaaS? Не теряет данные: Почта. Работа в группах: Документы. Большой/изменяющийся объем данных: YouTube. Нет необходимости в апгрейде при обновлении приложения: Поиск
47. Заключение Agile цикл — итерации с рабочими прототипами. Test-Driven Development: от юнит-тестов до приёмочных тестов. Продуктивнось: ясность, синтез, повторное использование, автоматизация и инструменты. SaaS — очень удобно для разработчиков и пользователей.