Рівень 38. Відповіді на запитання до співбесіди на тему рівня

Agile - це серія підходів до розробки програмного забезпечення, орієнтованих на використання ітеративної розробки, динамічне формування вимог та забезпечення їх реалізації в результаті взаємодії всередині робочих груп, що самооранізуються, що складаються з фахівців різних профілів. Існує кілька методик, що належать до гнучкої методології розробки, зокрема екстремальне програмування, DSDM, Scrum, FDD.

Основні концепції agile-методів:

• люди та взаємодія важливіші за процеси та інструменти;
• працюючий продукт важливіший за вичерпну документацію;
• співробітництво із замовником важливіше узгодження умов контракту;
• готовність до змін важливіша за проходження початкового плану.

Також було сформульовано основні засади такого підходу:

• задоволення клієнта за рахунок раннього та безперебійного постачання цінного програмного забезпечення;
• вітання змін вимог навіть наприкінці розробки (це може підвищити конкурентоспроможність товару над ринком);
• часте постачання робочого програмного забезпечення (кожний місяць або щотижня, або навіть ще частіше);
• тісне, щоденне спілкування замовника з розробником протягом усього проекту;
• проектом займаються мотивовані особи, забезпечені необхідні умовами роботи, підтримкою та довірою;
• рекомендований метод передачі інформації - особиста розмова (віч-на-віч);
• працююче програмне забезпечення - найкращий вимірник прогресу;
• спонсори, розробники та користувачі повинні підтримувати постійний темп на невизначений термін;
• постійно увагу покращення технічної майстерності та зручного дизайну;
• простота – мистецтво не робити зайвої роботи;
• кращі технічні вимоги, архітектура та дизайн отримають у самоорганізованої команди;
• постійна адаптація до умов, що змінюються.

Основною проблемою розробки було визнано те, що ніхто з учасників на жодному етапі не має всієї повноти інформації про те, що робити.

Scrum - це одна з методик гнучкої розробки. Вона наголошує на якісному контролі процесу розробки. Основна особливість скраму - це розбиття процесу розробки на ітерації, що має чітку протаженість за часом (зазвичай 2-6 тижнів; їх називають "спринтами").

На початку спринту проводиться "планування спринту" - нарада на 3-4 години, де обговорюються основні завдання, які вирішуватимуться протягом спринту. Наприкінці спринту проводиться демо – демонтація результатів роботи команди за цей спринт.

Перед першим спринтом замовник (або його представник) формує список вимог, що пред'являються до майбутнього продукту. Такі вимоги називаються "user story", а самого замовника називають "product owner". Також у цьому списку замовник (PO) вказує пріоритет для кожного завдання. Спочатку реалізовуватимуться завдання з вищим пріоритетом. Увесь список називається "product backlog", або "резерв продукту".

Окрім product owner, серед учасників ще виділяють scrum-майстри: він проводить усі наради, стежить за дотриманням усіх принципів скраму, дозволяє протиріччя та захищає команду від факторів, що відволікають. Зазвичай як скрам-майстри виступає хтось із команди.

На першій нараді на початку спринту кожному завданню, крім того, що призначається пріоритет, дається ще приблизна оцінка в "абстрактних людино-днях", які ще називають "story point". Потім команда вирішує, скільки вона встигне виконати задач під час спринту. Наприклад, замовник відібрав 7 завдань, а команда зможе зробити лише 5. Тоді решта двох завдань піде на наступний спринт. Якщо замовнику це не подобається, він може підвищити їхній пріоритет, але тоді інші завдання випадуть зі спринту. Крім того, скрам-майстер може розбити деякі завдання на дрібніші та розставити їм різні пріоритети, щоб замовник залишився задоволеним.

Список відібраних завдань на спринт називають "sprint backlog", або "резерв спринту". Для кращої наочності зазвичай складається таблиця, у якій вказуються завдання, які необхідно реалізувати, що у процесі реалізації, і які вже виконані. Також будується діаграма "згоряння завдань". Вона графічно показує, скільки завдань залишилося виконати. В ідеалі графік згоряння завдань до кінця спринту має опуститись до нуля.

Також протягом спринту кожен день або через день проводяться невеликі наради всередині команди на 5-15 хвабон, де кожен учасник команди розповідає, що зробив за цей день (або ці два дні), що ще йому належить зробити, а також розповідає про те, що йому заважає щось зробити.

Коли спринт завершується, scrum-master проводить demo, де демонструється список всього, що повністю зроблено. Потім проводиться "розбір польотів" - нарада теж на кілька годин. На ньому зазвичай намагаються з'ясувати, що було зроблено добре, а що (і як) можна зробити краще.

Зазвичай за 2-3 спринти можна виявити основні проблеми, які заважають команді працювати ефективніше, та усунути їх. Це призводить до більшої продуктивності, не збільшуючи навантаження на команду. Таке було неможливим до епохи гнучких методологій.

Також у середині спринту, іноді ще проводять «чісування» — нарада, присвячена плануванню наступного спринту. На ньому зазвичай уточнюють пріоритети завдань, а також можуть розбити деякі завдання на частини та/або додати нові завдання у product backlog – резерв продукту.

У скрам учасників ділять на "свиней" та "кур". "Свині" повністю задіяні у процесі, "кури" - лише частково. До категорії "свиней" відносять такі ролі:

• Скрам-майстер (проводить наради, стежить за виконанням принципів скраму тощо; це хтось із команди, produst owner не може бути скрам-майстром);
• Власників продукту (Product Owner) (представляє інтереси кінцевих користувачів та інших зацікавлених у продукті сторін);
• Команда розробки (Development Team) (крос-функціональна команда, що складається зі спеціалістів різних профілів: розробників, тестувальників, дизайнерів, архітекторів і т. д. Розмір команди в ідеалі складає від 3 до 9 осіб. Команда є єдиним повністю залученим учасником розробки і відповідає за результат як єдине ціле, ніхто, крім команди, не може втручатися в процес розробки протягом спринту).

До "кур" відносяться такі ролі:

• Користувачі (Users)
• Клієнти, продавці (Stakeholders) (особи, які ініціюють проект і для кого проект приноситиме вигоду. Вони залучені в скрам тільки під час оглядової наради зі спринту (Sprint Review));
• Керуючі (Managers) (люди, які керують персоналом);
• Експерти-консультанти (Consulting Experts).

Спринт – це одна ітерація циклу розробки програмного забезпечення у Скрамі. Зазвичай спринт жорстко фіксований за часом. Тривалість спринту вибирається виходячи з розміру команди, специфіки роботи, вимог, розміру проекту. Найчастіше це підбирається досвідченим шляхом, виходячи з спроб і помилок. У середньому спринт може бути тривалість від 2 тижнів до 4 (хоча в деяких компаніях його тривалість буває дорівнює 6 тижням). Для оцінка обсягу робіт у спринті може бути використана попередня оцінка, яка вимірюється в окулярах історії. Попередня оцінка фіксується у беклозі проекту.

QA розшифровується як Quality Assuarance (тобто "Гарантія якості", якщо дослівно перекласти). До цієї категорії належать тестувальники. Це люди, які виявляють у програмі баги та помилки. Для цього вони використовують різні засоби як ручні, так і автоматичні. Після виявлення багів та помилок вони повідомляють про це розробникам, і ті виправляють ці помилки.

Product Owner (власник проекту) – це замовник або представник замовника. Це або хтось з боку клієнта (стороння фірма або фіз.особа), або якийсь інший співробітник фірми, що визначає вимоги до кінцевого продукту та стежить за їх виконанням (наприклад, бізнес-аналітик). Як уже було сказано, він визначає вимоги до продукту та завдання, які має вирішити команда розробки, щоб отримати кінцевий продукт. Список вимог (або завдань) він оформляє у визначеному порядку та із заданим пріоритетом для кожної вимоги (завдання). Зазвичай він бере участь у плануванні спринту (перед початком спринту) та у демонстрації результатів спринту (після закінчення спринту).

На чолі ієрархії винятків у Java стоїть клас Throwable. Від не успадковуються два класи: Errorі Exception. Об'єкти першого класу викидаються, коли виникають якісь серйозні помилки в роботі програми та java-машини в цілому (а також у роботі ОС та апаратної частини комп'ютера), так що програма більше не може продовжувати працювати і закривається. Це може бути нестача пам'яті (OutOfMemoryError) або переповнення стека (StackOverflowError).

Примірники другого класу можуть вибратися за різних виняткових ситуацій. Власне від цього класу успадковується клас RuntimeExceptionта й інші класи. Перший клас так виділяють, тому що, по-перше, виняткові ситуації такого типу є неперевіреними (unchecked), а по-друге, до цих виняткових ситуацій належать помилки виконання програми. Зазвичай це виникає через недосконалість коду. Решта виняткових ситуацій зазвичай є наслідком непередбаченого збігу обставин, наприклад, помилки введення-виведення.

Також винятки поділяються на проверяемые (checked) і непроверяемые (unchecked). Перші необхідно або відловлювати в блоці try-catch, або вказувати як метод, що викидається в сигнатурі (використовуючи слово throws ). Неперевірені цього не вимагають, і вибір залишається за програмістом. До перевірених відносяться винятки типу Throwable(а також успадковані від нього) і типу Exception(та успадковані від нього, крім винятків типу RuntimeException). До неперевірених відносяться винятки типу Error(а також успадковані від нього) та винятки типу Runtime (і успадковані від нього).

Нічого, програма просто закриється. Зазвичай це критичні помилки, які не завжди виникли з вини програміста (наприклад, вихід з ладу жорсткого диска або збій операційної системи). Щоправда, серед них є дві помилки, які можу наслідком недосконалості коду — StackOverflowErrorі OutOfMemoryError. Перший тип помилок виник, при переповненні стека викликів, тобто коли викликається занадто багато методів і стек викликів стає занадто більшим (типовий приклад — нескінченна рекурсія або рекурсія з великою кількістю ітерацій). Друга помилка - OutOfMemoryErrorвиникає, коли переповнює пам'ять відведена під об'єкти, тобто коли створюється занадто багато великовагових об'єктів, і всі вони тримаються в пам'яті (або коли збирач сміття не встигає їх знищувати).

У Java 7 у плані виняток було введено три нові "речі":

• Multicatching. Це коли в одному catchблоці відразу обробляється кілька винятків:

  try {
   } catch (Exception1|Exception2|Exception3| ... | ExceptionN ex) {}

  У такому випадку параметр exнеявно матиме модифікатор final. Крім того, байт-код, згенерований компіляцією такого коду (з єдиним catchблоком) буде коротшим, ніж байт-код, згенерований компіляцією коду з кількома catchблоками.

• Try-with-resources. Ця конструкція дозволяє після слова tryв дужках вказати ресурси, які самі закриються після закінчення конструкції try () {} catch{}. Як ресурс у цій конструкції може бути використаний будь-який об'єкт, що реалізує інтерфейс AutoCloseable.

  Під час закриття ресурсів також може бути кинуто виняток. Додана try-with-resourcesможливість зберігання "пригнічених" винятків, і кинутий try-блоком виняток має більший пріоритет, ніж винятки, що виявабося під час закриття. Отримати останні можна викликом методу getSuppressed()від виключення, кинутого tryблоком.

• Rethrowing. Перекидання винятків із покращеною перевіркою відповідності типів.

  Компілятор Java SE 7 ретельніше аналізує винятки, що перекидаються. Розглянемо наступний приклад:

  static class FirstException extends Exception { }
  static class SecondException extends Exception { }
  
  public void rethrowException(String exceptionName) throws Exception {
      try {
          if ("First".equals(exceptionName)) {
              throw new FirstException();
          } else {
              throw new SecondException();
          }
      } catch (Exception ex) {
          throw e;
      }
  }

  У прикладі try-блок може залишити або FirstException, або SecondException. У версіях Java SE 7 неможливо вказати ці винятки в декларації методу, тому що catch-блок перекидає виняток ex, тип якого – Exception.

  У Java SE 7 ви можете вказати, що метод rethrowExceptionкидає лише FirstExceptionй SecondException. Компілятор визначить, що виключення Exceptionex могло виникнути тільки в tryблоці, в якому може бути кинуто FirstExceptionабо SecondException. Навіть якщо тип параметра catch— Exception, компілятор визначить, що це екземпляр або FirstException, або SecondException:

  public void rethrowException(String exceptionName) throws FirstException, SecondException {
       try {
           // ...
       } catch (Exception e) {
           throw e;
       }
   }

  Якщо FirstExceptionне SecondExceptionє спадкоємцями Exception, необхідно вказати й Exceptionу оголошенні методу.

• Анотації використовуються розміщувати поруч із класом, полем, методом чи зміною якоїсь додаткової, службової інформації (метаданих), що належить до неї. Щоб вказати інструкцію, треба над заголовком класу чи способу, або треба оголошенням поля чи змінної, написати після @ назву анотації (класу інструкції), наприклад так:

  ...
  @Override
  public void doSomeThing() {
  }
  ...

  Крім того, у анотації можуть бути властивості, вони вказують у дужках через кому у вигляді пар "ключ = значення", де як ключ виступає назва властивості, а як значення - власне, значення, яке має прийняти цю властивість. Виглядає це так:

  @CatInfo(manager=Catmanager.class, unique=true)
  class Cat {}

  Якщо вказується вказує значення лише однієї властивості, то ім'я якості і символ одно можна писати: @SuppressWarnings("unchecked").

  Також можна взагалі не ставити дужки, якщо ніяким властивостям не надаються ніякі значення.

  Щоб створити свою анотацію, треба вказати модифікатор доступу, потім після пробілу ключове слово " @interface " і далі знову після пробілу ім'я анотації (прийняти починати його з великої літери). Далі йде тіло інструкції у фігурних дужках. Усередині тіла вказуються властивості як оголошень методів (як інтерфейсах). Також у властивостей можна вказати значення за замовчуванням (вони їх прийматимуть, якщо при вказівці інструкції у потрібному місці, цій властивості не буде надано якесь значення). Все разом це виглядає так:

  @interface CatManager
  {
   Class manager();
   boolean unique();
   String name() default "Unknown Cat";
  }

  Анотації виконують такі функції:

  • дають необхідну інформацію компілятора;
  • дають інформацію різним інструментам для генерації іншого коду, конфігурацій тощо;
  • можуть використовуватись під час роботи коду;
  • підвищують читабельність коду та його розуміння програмістами.
  На даний момент компілятором використовують три інструкції: @Deprecated, @Overrideі @SuppressWarnings. Першою інструкцією позначаються застарілі методи та класи, нерекомендовані до використання (компілятор з їх приводу показує попередження). Друга аннтоція ставиться над перевизначеними методами класу-спадкоємця (це дозволяє контролювати зв'язок між вихідним методом та перевизначеним). Третя анотація дозволяє пригнічувати (не виводити) деякі виняткові попередження, які зазвичай виводять компілятор у зв'язку з даним методом або класом (наприклад, що він вже застарів і нерекомендований до використання).