Nivel 38. Respuestas a las preguntas de la entrevista sobre el tema del nivel.

Agile es una serie de enfoques para el desarrollo de software centrados en el uso del desarrollo iterativo, la formación dinámica de requisitos y asegurar su implementación como resultado de la interacción dentro de grupos de trabajo autoorganizados compuestos por especialistas de diferentes perfiles. Existen varias técnicas relacionadas con la metodología de desarrollo flexible, en particular programación extrema, DSDM, Scrum, FDD.

Conceptos básicos de métodos ágiles:

• las personas y las interacciones son más importantes que los procesos y las herramientas;
• un producto funcional es más importante que una documentación completa;
• la cooperación con el cliente es más importante que acordar los términos del contrato;
• La voluntad de cambiar es más importante que apegarse al plan original.

También se formularon los principios básicos de este enfoque:

• satisfacción del cliente mediante la entrega temprana e ininterrumpida de software valioso;
• aceptar cambios en los requisitos incluso al final del desarrollo (esto puede aumentar la competitividad del producto en el mercado);
• Entrega frecuente de software que funcione (cada mes o cada semana, o incluso con más frecuencia);
• comunicación cercana y diaria entre el cliente y el desarrollador durante todo el proyecto;
• el proyecto lo llevan a cabo personas motivadas que cuentan con las condiciones de trabajo, el apoyo y la confianza necesarios;
• El método recomendado para transmitir información es la conversación personal (cara a cara);
• el software que funciona es la mejor medida del progreso;
• patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida;
• atención constante a la mejora de la destreza técnica y el diseño fácil de usar;
• simplicidad: el arte de no hacer trabajos innecesarios;
• los mejores requisitos técnicos, arquitectura y diseño provienen de un equipo autoorganizado;
• Adaptación constante a las condiciones cambiantes.

Se reconoció que el principal problema del desarrollo era que ninguno de los participantes en ninguna etapa tenía información completa sobre qué hacer.

Scrum es una de las técnicas de desarrollo ágil. Se centra en el control de calidad del proceso de desarrollo. La característica principal de Scrum es la división del proceso de desarrollo en iteraciones con una duración clara (normalmente de 2 a 6 semanas; se denominan "sprints").

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Las anotaciones se utilizan para colocar junto a una clase, campo, método o variable alguna información de servicio adicional (metadatos) relacionada con él. Para indicar una anotación, es necesario escribir el nombre de la anotación (clase de anotación) después del título @ de la clase o método, o la declaración de un campo o variable, por ejemplo:

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

  Además, una anotación puede tener propiedades; se indican entre paréntesis, separadas por comas, en forma de pares “clave=valor”, donde la clave es el nombre de la propiedad y el valor es el valor real que esta propiedad deben tomar. Se parece a esto:

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

  Si especifica un valor para una sola propiedad, se pueden omitir el nombre de la propiedad y el signo igual: @SuppressWarnings("unchecked").

  También puede omitir los paréntesis por completo si no se asigna ningún valor a ninguna propiedad.

  Para crear su propia anotación, debe especificar el modificador de acceso, luego después del espacio la palabra clave " @interface " y luego nuevamente después del espacio el nombre de la anotación (comience con una letra mayúscula). Luego viene el cuerpo de la anotación entre llaves. Dentro del cuerpo, las propiedades se especifican en forma de declaraciones de métodos (como en las interfaces). También puede especificar valores predeterminados para las propiedades (los aceptarán si, al especificar una anotación en el lugar correcto, a esta propiedad no se le asigna un valor). En conjunto se ve así:

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

  Las anotaciones realizan las siguientes funciones:

  • proporcionar la información necesaria para el compilador;
  • dar información a diversas herramientas para generar otros códigos, configuraciones, etc.;
  • se puede utilizar mientras se ejecuta el código;
  • aumentar la legibilidad y comprensión del código por parte de los programadores.
  Actualmente, el compilador utiliza tres anotaciones : @Deprecatedy @Override. @SuppressWarningsLa primera anotación marca métodos y clases obsoletos cuyo uso no se recomienda (el compilador muestra una advertencia sobre ellos). La segunda anotación se coloca sobre los métodos anulados de la clase descendiente (esto le permite controlar la conexión entre el método original y el método anulado). La tercera anotación le permite suprimir (no imprimir) algunas de las advertencias excepcionales que normalmente emite el compilador con respecto a un método o clase determinado (por ejemplo, que está en desuso y en desuso).