Niveau 38. Réponses aux questions d'entretien sur le sujet du niveau

Agile est une série d'approches de développement logiciel axées sur l'utilisation du développement itératif, la formation dynamique d'exigences et la garantie de leur mise en œuvre grâce à l'interaction au sein de groupes de travail auto-organisés composés de spécialistes de différents profils. Il existe plusieurs techniques liées à la méthodologie de développement flexible, notamment la programmation extrême, DSDM, Scrum, FDD.

Concepts de base des méthodes agiles :

• les personnes et les interactions sont plus importantes que les processus et les outils ;
• un produit fonctionnel est plus important qu’une documentation complète ;
• la coopération avec le client est plus importante que l'accord sur les termes du contrat ;
• la volonté de changer est plus importante que de s’en tenir au plan initial.

Les principes de base de cette approche ont également été formulés :

• la satisfaction du client grâce à une livraison rapide et ininterrompue de logiciels de valeur ;
• accueillir les changements d'exigences même en fin de développement (cela peut augmenter la compétitivité du produit sur le marché) ;
• Livraison fréquente de logiciels fonctionnels (chaque mois ou chaque semaine, voire plus souvent) ;
• une communication étroite et quotidienne entre le client et le développeur tout au long du projet ;
• le projet est réalisé par des personnes motivées qui bénéficient des conditions de travail, du soutien et de la confiance nécessaires ;
• La méthode recommandée pour transmettre des informations est la conversation personnelle (face à face) ;
• un logiciel fonctionnel est la meilleure mesure du progrès ;
• les sponsors, les développeurs et les utilisateurs doivent maintenir indéfiniment un rythme constant ;
• une attention constante à l'amélioration de l'excellence technique et à une conception conviviale ;
• simplicité - l'art de ne pas faire de travail inutile ;
• les meilleures exigences techniques, l'architecture et la conception proviennent d'une équipe auto-organisée ;
• adaptation constante aux conditions changeantes.

Le principal problème du développement a été reconnu car aucun des participants, à aucun moment, ne disposait d'informations complètes sur ce qu'il fallait faire.

Scrum fait partie des techniques de développement agile. Il se concentre sur le contrôle qualité du processus de développement. La principale caractéristique de Scrum est la division du processus de développement en itérations d'une durée claire (généralement de 2 à 6 semaines ; elles sont appelées « sprints »).

Au début du sprint, une « planification du sprint » a lieu - une réunion de 3 à 4 heures, au cours de laquelle sont discutées les principales tâches qui seront résolues pendant le sprint. A la fin du sprint, une « démo » est organisée - une démonstration du travail de l'équipe pour ce sprint.

Avant le tout premier sprint, le client (ou son représentant) dresse une liste d'exigences pour le futur produit. De telles exigences sont appelées « user story » et le client lui-même est appelé « propriétaire du produit ». Toujours dans cette liste, le client (PO) indique la priorité de chaque tâche. Les tâches ayant une priorité plus élevée seront mises en œuvre en premier. L'ensemble de la liste est appelé « product backlog » ou « réserve de produits ».

Outre le Product Owner, le Scrum Master se distingue également parmi les participants : il dirige toutes les réunions, contrôle le respect de tous les principes Scrum, résout les contradictions et protège l'équipe des distractions. Habituellement, quelqu'un de l'équipe agit en tant que Scrum Master.

На первом совещании в начале спринта каждой задаче, кроме того, что назначается приоритет, даётся ещё приблизительная оценка в "абстрактных человеко-днях", которые ещё называют "story point". Затем команда решает, сколько она успеет выполнить задач за время спринта. Например, заказчик отобрал 7 задач, а команда сможет сделать только 5. Тогда остальные две задачи пойдут на следующий спринт. Если заказчику это не нравится, он может повысить их приоритет, но тогда другие задачи выпадут из спринта. Кроме того, скрам-мастер может разбить некоторые задачи на более мелкие и расставить им различные приоритеты, чтобы заказчик остался доволен.

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

Также в течение спринта каждый день or через день проводятся небольшие совещания внутри команды на 5-15 minutes, где каждый участник команды рассказывает, что сделал за этот день (or эти два дня), что ещё ему предстоит сделать, а также рассказывает о том, что ему мешает что-то сделать.

Когда спринт завершается, scrum-master проводит demo, на котором демонстрируется список всего, что fully сделано. Затем проводится «разбор полетов» — совещание тоже на пару часов. На нем обычно пытаются выяснить, что было сделано хорошо, а что (и How) можно было сделать лучше.

Обычно за 2-3 спринта можно выявить основные проблемы, которые мешают команде работать эффективнее, и устранить их. Это приводит к большей продуктивности, не увеличивая нагрузку на команду. Такое было невозможным до эры гибких методологий.

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

В скрам участников делят на "свиней" и "кур". "Свиньи" fully задействованы в процессе, "куры" — только частично. К категории "свиней" относят следующие роли:

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

К "курам" относятся следующие роли:

• Пользователи (Users)
• Клиенты, продавцы (Stakeholders) (лица, которые инициируют проект и для кого проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review));
• Управляющие (Managers) (люди, которые управляют персоналом);
• Эксперты-консультанты (Consulting Experts).

Спринт — это одна итерация цикла разработки программного обеспечения в Скраме. Обычно спринт жёстко фиксирован по времени. Продолжительность спринта выбирается на основании размера команды, специфики работы, требований, размера проекта. Чаще всего это подбирается опытным путём, на основании проб и ошибок. В среднем спринт может быть продолжительность от 2 недель до 4 (хотя в некоторых компания его продолжительность бывает равна и 6 неделям). Для оценка объёма работ в спринте может быть использована предварительная оценка, измеряемая в очках истории. Предварительная оценка фиксируется в беклоге проекта.

QA расшифровывается How Quality Assuarance (то есть "Гарантия качества", если перевести дословно). К этой категории относятся тестировщики. Это люди, которые выявляют в программе баги и ошибки. Для этого они используют разные средства, How ручные, так и автоматические. После выявления багов и ошибок они сообщают об этом разработчикам, и те исправляют эти ошибки.

Product Owner (владелец проекта) — это заказчик or представитель заказчика. Это либо кто-то со стороны клиента (сторонняя фирма or физ.лицо), либо Howой-то другой сотрудник фирмы, определяющий требования к конечному продукту и следящий за их выполнением (например, бизнес-аналитик). Как уже было сказано, он определяет требования к продукту и задачи, которые должна решить команда разработки, чтобы получить конечный продукт. Список требований (or задач) он оформляет в определённым порядке и с заданным приоритетом для каждого требования (задачи). Обычно он участвует в планировании спринта (перед началом спринта) и в демонстрации результатов спринта (после окончания спринта).

Во главе иерархии исключений в Java стоит класс Throwable. От не наследуются два класса: Error и Exception. Объекты первого класс выбрасываются, когда возникают Howие-то серьёзные ошибки в работе программы и java-машины в целом (а также в работе ОС и аппаратной части компьютера), так, что программа больше не может продолжать работать и закрывается. Это может быть недостаток памяти (OutOfMemoryError) or переполнение стека (StackOverflowError).

Экземпляры второго класса могут выбраться при самых различных исключительных ситуаций. Собственно от этого класса наследуется класс RuntimeException и все остальные классы. Первый класс так выделяют, потому что, во-первых, исключительные ситуации такого типа являются непроверяемые (unchecked), а, во-вторых, к данным исключительным ситуациям относятся ошибки выполнения программы. Обычно это возникает из-за несовершенства codeа. Все остальные исключительные ситуации обычно являются следствием непредвиденного стечения обстоятельств, например, ошибки ввода-вывода.

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

Ничего, программа просто закроется. Обычно это критические ошибки, не всегда возникшие по вине программиста (например, выход из строя жёсткого диска or сбой операционной системе). Правда, среди них есть две ошибки, которые могу следствием несовершенства codeа — это StackOverflowError и OutOfMemoryError. Первый тип ошибок возник, при переполнении стека вызовов — то есть, когда вызывается слишком много методов и стек вызовов становится слишком больший (типичный пример — бесконечная рекурсия or рекурсия с большим количеством итераций). Вторая ошибка — OutOfMemoryError — возникает, когда переполняет память отведённая под an objectы, то есть когда создаётся слишком много тяжеловесных an objectов, и они все держатся в памяти (or когда сборщик мусора не успевает их уничтожать).

В Java 7 в плане исключение были введены три новых "вещи":

• Multicatching. Это когда в одном catch-блоке сразу обрабатывается несколько исключений:

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

  В таком случае параметр ex будет неявно иметь модификатор final. Кроме того, byte-code, сгенерированный компиляцией такого codeа (с единым catch-блоком) будет короче, чем byte-code, сгенерированный компиляцией codeа с несколькими catch-блоками.

• Try-with-resources. Эта конструкция позволяет после слова try в скобках указать открываемые ресурсы, которые сами закроются после окончания конструкции try () {} catch{}. В качестве ресурса в данной конструкции может быть использован любой an object, реализующий интерфейс 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. В versionх до Java SE 7 невозможно указать эти исключения в декларации метода, потому что catch-блок перебрасывает исключение ex, тип которого – Exception.

  В Java SE 7 вы можете указать, что метод rethrowException бросает только FirstException и SecondException. Компилятор определит, что исключение Exception ex могло возникнуть только в try-блоке, в котором может быть брошено FirstException or SecondException. Даже если тип параметра catch — Exception, компилятор определит, что это экземпляр либо FirstException, либо SecondException:

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

  Если FirstException и SecondException не являются наследниками Exception, то необходимо указать и Exception в объявлении метода.

• Аннотации используются для размещения рядом с классом, полем, методом or переменой Howой-то дополнительной, служебной информации (метаданных), относящейся к ней. Whatбы указать аннотацию, надо над заголовком класса or метода, либо надо объявлением поля or переменной, написать после @ название аннотации (класса аннотации), например так:

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

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

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

  Если указывается указывает meaning только для одного свойства, то Name свойства и знак равно можно не писать: @SuppressWarnings("unchecked").

  Также можно вообще не ставить скобки, если ниHowим свойствам не присваиваются ниHowие значения.

  Whatбы создать свою аннотацию, надо указать модификатор доступа, потом после пробела ключевое слово "@interface" и дальше опять после пробела Name аннотации (принять начинать его с большой буква). Дальше идёт тело аннотации в фигурных скобках. Внутри тела указываются свойства в виде объявлений методов (How в интерфейсах). Также у свойств можно указать значения по умолчанию (они их будут принимать, если при указании аннотации в нужном месте, этому свойству не будет присвоено Howое-то meaning). Всё вместе это выглядит так:

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

  Аннотации выполняют следующие функции:

  • дают необходимую информацию для компилятора;
  • дают информацию различным инструментам для генерации другого codeа, конфигураций и т. д.;
  • могут использоваться во время работы codeа;
  • повышают читабельность codeа и его понимание программистами.
  Actuellement, le compilateur utilise trois annotations : @Deprecated, @Overrideet @SuppressWarnings. La première annotation marque les méthodes et classes obsolètes dont l'utilisation n'est pas recommandée (le compilateur affiche un avertissement à leur sujet). La deuxième annotation est placée sur les méthodes substituées de la classe descendante (cela vous permet de contrôler la connexion entre la méthode d'origine et celle substituée). La troisième annotation vous permet de supprimer (et non d'imprimer) certains des avertissements exceptionnels généralement émis par le compilateur concernant une méthode ou une classe donnée (par exemple, qu'elle est obsolète et obsolète).