Любой полезный бизнесу продукт меняется со временем: появляются новые функции, улучшаются старые. Возникает потребность оценить влияние таких изменений на пользователей продукта. Необходимо проверить, нет ли ошибок в реализации новой функциональности и справляется ли она с поставленными задачами. 

Первое, что хочется сделать — сравнить показатели работы продукта до внесения изменений и после. Но в таком случае нельзя утверждать, что разница в показателях обусловлена только новой функциональностью, так как на состояние продукта в любой момент времени может повлиять любой внешний фактор. Поэтому принято прибегать к контролируемым рандомизированным экспериментам, которые также называют А/Б-тестами. В том числе и для товарных рекомендаций в e-commerce.

Концепцию ООП часто применяют для отражения объектов реального мира в коде программ. Так объект реального мира "Пользователь" может быть описан в коде как класс "Пользователь", у которого есть поля: имя и адрес электронной почты, а действия, которые можно совершить над объектами реального мира, превращаются в методы класса: назначить администратором, удалить учетную и т.д. 

В первых двух частях (1, 2) мы обсудили общий принципы UML, о семантике и признаках хорошей модели. В этой части добавим ещё кое-что про хорошие модели и перейдём к плохим.

Я часто собеседую кандидатов на позиции .Net разработчиков в Retail Rocket. В прошлом работал в компаниях с различными командами. И далеко не один раз встречал и продолжаю встречать мнение, что “автотесты хорошо, но на них нет времени, писать их дорого, тестировать должны тестировщики”. Такое мнение не у всех, но встречается нередко (не исключаю, что мне так «везет»). В связи с этим хочу поделиться нашим подходом к автоматическому тестированию и обеспечению качества. Расскажу путь, который мы в Retail Rocket прошли за последние 3-4 года, к чему пришли сейчас, и —  главное — что дают нам автотесты и для чего мы их пишем. Надеюсь, статья кого-нибудь сподвигнет писать автотесты, кого-то — писать больше автотестов, а кому-то, возможно, поможет избежать ошибок, с которыми мы сталкивались.

Вторая часть перевода статьи Леона Старра, инженера программных моделей. Первая часть вот здесь. В этой части — о семантике и о том, что отличает хорошую модель.

Мне показался близким подход Леона Старра к объяснению чётких моделей классов и описанию их преимуществ. Настолько, что мы в Retail Rocket решили сделать перевод его большой статьи "How To Build Articulated UML Class Models". Будем выкладывать по частям, под катом — первая из трёх.

Предыстория