レベル 38. レベルのトピックに関するインタビューの質問への回答

こんにちは。繰り返しますが、このレベルの質問に対する答えはないようです。ということで、いつものように私の投稿をさせていただきます。突然、誰かが助けてくれます（または誰かが何かを追加したり、より良い答えを返したりします）。 そこで質問は次のとおりです。

アジャイルとは何ですか?
スクラムとは何ですか?
スクラムの役割を知っていますか?
スプリントとは何ですか? 詳細を教えてください
QAとは誰ですか?
プロダクトオーナーとは誰ですか?
例外階層の説明
JVM がエラーをスローした場合はどうすればよいでしょうか?
Java 7 の例外分野におけるどのような革新を知っていますか?
なぜ注釈が必要なのでしょうか? それらの使い方は？

そして今の私の答えは次のとおりです。

アジャイルは、反復開発の使用、要件の動的な形成、およびさまざまなプロファイルの専門家で構成される自己組織化ワーキンググループ内での対話の結果としての確実な実装に重点を置いたソフトウェア開発への一連のアプローチです。柔軟な開発方法論、特にエクストリームプログラミング、DSDM、スクラム、FDD に関連するテクニックがいくつかあります。

アジャイル手法の基本概念:
- プロセスやツールよりも人々と相互作用の方が重要です。
- 実用的な製品は包括的なドキュメントよりも重要です。
- 顧客との協力は、契約条件に同意することよりも重要です。
- 最初の計画に固執するよりも、変化する意欲の方が重要です。
このアプローチの基本原則も次のように定式化されました。
- 価値のあるソフトウェアを早期かつ中断なく配信することで顧客満足度を高めます。
- 開発の終了時であっても要件の変更を歓迎します（これにより、市場での製品の競争力が向上します）。
- 動作するソフトウェアを頻繁に配信します (毎月、毎週、またはそれ以上の頻度)。
- プロジェクト全体を通して、顧客と開発者の間で毎日緊密なコミュニケーションを行う。
- プロジェクトは、必要な労働条件、サポート、信頼を与えられた意欲的な個人によって実行されます。
- 推奨される情報伝達方法は個人的な会話 (対面) です。
- 動作するソフトウェアは進歩を測る最良の尺度です。
- スポンサー、開発者、ユーザーは、一定のペースを無期限に維持しなければなりません。
- 技術力の向上とユーザーフレンドリーなデザインへの絶え間ない注意。
- シンプルさ - 不必要な作業を行わない技術。
- 最高の技術要件、アーキテクチャ、設計は自己組織化されたチームから生まれます。
- 変化する状況への絶え間ない適応。
開発の主な問題は、どの段階においても、何をすべきかについての完全な情報を持っている参加者が一人もいなかったことであることが認識されました。
スクラムはアジャイル開発手法の 1 つです。開発プロセスの品質管理に重点を置いています。スクラムの主な特徴は、開発プロセスを明確な期間 (通常は 2 ～ 6 週間、「スプリント」と呼ばれます) を持つ反復に分割することです。

В начале спринта проводится "планирование спринта" — совещание на 3-4 часа, где обсуждаются основные задачи, которые будут решаться на протяжении спринта. В конце спринта проводится "демо" – демонтрация результатов работы команды за этот спринт.

Перед самым первым спринтом заказчик (or его представитель) формирует список требований, предъявляемых к будущему продукту. Такие требования называются "user story", а самого заказчика называют "product owner". Также в этом списке заказчик (PO) указывает приоритет для каждой задачи. Сначала будут реализовываться задачи с более высоким приоритетом. Весь список называется "product backlog", or "резерв продукта".

Кроме product owner, среди участников ещё выделяют scrum-мастера: он проводит все совещания, следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов. Обычно в качестве скрам-мастера выступает кто-то из команды.

На первом совещании в начале спринта каждой задаче, кроме того, что назначается приоритет, даётся ещё приблизительная оценка в "абстрактных человеко-днях", которые ещё называют "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 в объявлении метода.
- 注釈は、クラス、フィールド、メソッド、または変数の隣に、それに関連する追加のサービス情報 (メタデータ) を配置するために使用されます。アノテーションを示すには、クラスまたはメソッドの @ タイトル、またはフィールドまたは変数の宣言の後にアノテーションの名前 (アノテーションクラス) を記述する必要があります。次に例を示します。
```
...
@Override
public void doSomeThing() {
}
...
```
  さらに、アノテーションにはプロパティを含めることができます。プロパティは、「key=value」ペアの形式でカンマで区切られ、かっこ内に示されます。ここで、キーはプロパティの名前であり、値はこのプロパティが持つ実際の値です。取るべきだ。次のようになります。
```
@CatInfo(manager=Catmanager.class, unique=true)
class Cat {}
```
  1 つのプロパティのみに値を指定する場合は、プロパティ名と等号を省略できます@SuppressWarnings("unchecked")。
  
  プロパティに値が割り当てられていない場合は、括弧を完全に省略することもできます。
  
  独自のアノテーションを作成するには、アクセス修飾子を指定し、スペースの後にキーワード「@interface」を指定し、さらにスペースの後にアノテーションの名前 (大文字で始める) を指定する必要があります。次に、中括弧で囲まれた注釈の本体が続きます。本体内では、プロパティはメソッド宣言の形式 (インターフェイスなど) で指定されます。プロパティのデフォルト値を指定することもできます (適切な場所に注釈を指定するときに、このプロパティに値が割り当てられていない場合は、デフォルト値が受け入れられます)。すべてまとめると次のようになります。
```
@interface CatManager
{
 Class manager();
 boolean unique();
 String name() default "Unknown Cat";
}
```
  注釈は次の機能を実行します。
  - コンパイラに必要な情報を提供します。
  - 他のコードや構成などを生成するためにさまざまなツールに情報を提供します。
  - コードの実行中に使用できます。
  - プログラマーによるコードの読みやすさと理解力が向上します。
  現在、コンパイラは、、の 3 つの注釈を使用@Deprecatedし@Overrideます@SuppressWarnings。最初のアノテーションは、使用が推奨されない廃止されたメソッドとクラスをマークします (コンパイラはそれらについて警告を表示します)。2 番目のアノテーションは、子孫クラスのオーバーライドされたメソッドの上に配置されます (これにより、元のメソッドとオーバーライドされたメソッドの間の接続を制御できます)。3 番目のアノテーションを使用すると、特定のメソッドまたはクラスに関してコンパイラによって通常発行される例外警告の一部を抑制する (出力しない) ことができます (たとえば、非推奨であることなど)。