97 этюдов для программистов. Опыт ведущих экспертов

Сделав эту коллекцию напрямую доступной клиентам, мы нарушили принцип инкапсуляции. Это не только снижает потенциал рефакторинга, но и заставляет пользователей кода нарушать DRY, поскольку каждому из них придется заново реализовывать потенциально идентичный запрос. Такой ситуации легко избежать, если убрать открытые коллекции из API. В данном примере можно ввести новый предметно-ориентированный тип коллекции с именем CustomerList. Этот класс семантически лучше согласован с предметной областью. Естественным образом он станет местом, в котором содержатся все наши запросы.

Наличие этого нового типа-коллекции позволит также легко выяснить, являются ли эти запросы узким местом в смысле производительности. Включив запросы в класс, мы устраняем необходимость открывать клиентам варианты представления, такие как ArrayList. Это дает нам свободу для последующего изменения реализаций без нарушения контрактов с клиентами:

public class CustomerList {

   private ArrayList customers = new ArrayList();

   private SortedList customersSortedBySpendingLevel =

     new SortedList();

   //…

   public CustomerList findCustomersThatSpendAtLeast(Money amount) {

      return new CustomerList(

         customersSortedBySpendingLevel.elementsLargerThan(amount));

}

}

public class UsageExample {

   public static void main(String[] args) {

     CustomerList customers = new CustomerList();

     //…

     CustomerList customersOfInterest =

       customers.findCustomersThatSpendAtLeast(someMinimalAmount);

     //…

   }

}

В этом примере следование принципу DRY позволило нам ввести измененную систему индексирования, в которой используется SortedList, а ключом служит объем трат наших покупателей. И, если абстрагироваться от данного примера, намного важнее, что следование DRY помогло найти и исправить узкое место. Пиши мы код по принципу WET, сделать это было бы труднее.

Когда программисты и тестировщики сотрудничают Джанет Грегори

Когда тестировщики и программисты начинают сотрудничать, происходят чудеса. Меньше времени уходит на игру в пинг-понг дефектами в системе отслеживания дефектов. Меньше времени тратится на обсуждение того, является ли поведение ошибкой или новой функцией, а больше — на разработку качественного программного обеспечения, отвечающего ожиданиям заказчиков. Существует много возможностей наладить сотрудничество еще до того, как начнется написание кода.

Тестировщики могут помочь заказчикам написать приемочные тесты на языке их предметной области с помощью таких инструментов, как Fit (Framework for Integrated Test). Если передать эти тесты программистам перед тем, как они начнут писать код, те смогут применить практику разработки на основе приемочного тестирования (acceptance test-driven development, ATDD). Программисты пишут фреймворки для прогона тестов, а потом код с проверкой на прохождение этих тестов. Далее эти тесты входят в набор регрессионных тестов. При такой организации сотрудничества функциональное тестирование проходит быстро, и остается больше времени на экспериментальное тестирование граничных условий или сценариев более изощренных рабочих процессов.

Можно пойти еще дальше. Будучи тестировщиком, я могу изложить свои соображения по тестированию еще до того, как программисты начнут писать код новой функции. Если я интересуюсь соображениями программистов, они почти всегда предоставляют мне сведения, позволяющие мне добиться лучшего покрытия кода или сократить затраты времени на ненужные тесты. Часто нам удавалось предотвратить появление дефектов за счет того, что тесты проясняют многие первоначальные идеи. Например, в одном из проектов, где я участвовала, я передала программистам Fit-тесты, которые показывали, какие результаты ожидаются при поиске по маске. Программист до этого твердо намеревался реализовать только поиск по конкретным словам. Нам удалось пообщаться с заказчиком, и мы смогли договориться о правильной интерпретации поиска до того, как начать писать код. В результате мы предотвратили возникновение дефекта и сэкономили всем уйму времени.