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

Почему я? Когда-то давно, когда я ещё не была техлидом, я заметила, что у нас есть проблема с глобальными процессами. От этого страдали все, и я в том числе. В конце концов страдать мне надоело, поэтому я решилась изменить что-то хотя бы в собственной команде. И мне это удалось. Хочу поделиться опытом и рассказать о одном принципе, который помог мне тогда и помогает по сей день.

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

Представим простую историю. Вы заканчиваете делать рефакторинг, которым занимались последние 2 недели. Вы хорошо над ним поработали, сделали несколько ключевых изменений в проекте. Делаете долгожданный pull request, и ... 12 конфликтов.

Или другой вариант. Вы работали и постоянно подливали себе основную ветку, так чтобы код сильно не расходился. Делаете pull request, он висит несколько дней, после этого вы получаете approve и ... 15 конфликтов. Кто-то слил свой большой pull request раньше.

Но ведь вы всё делали правильно. Работали над рефакторингом в отдельной ветке. Почему вам надо разрешать эти конфликты и можно ли как-то попроще? Можно ли работать в какой-то особой ветке, которую потом легко сливать в главную ветку без конфликтов? Оказывается, можно.

В этой статье поговорим про технику Branch by Abstraction. Как она может помочь не копить большие изменения в нашей ветке, избегать merge hell и прокачать ваш CI.

Я буду описывать примеры из Android-разработки, но они также справедливы для большинства типов проектов и платформ.

1. Retrofit

1.1. Что такое Retrofit

Репозиторий является посредником между слоем доступа к данным и доменным слоем,
работая как in-memory коллекция доменных обектов. Клиенты создают декларативные
описания запросов и передают их в репозиторий для выполнения.
  — свободный перевод Мартина Фаулера

EntityFraemwork предоставляет нам готовую реализацию паттернов Repository: DbSet<T> и UnitOfWork: DbContext. Но мне часто приходится видеть, как коллеги используют в своих проектах собственную реализацию репозиториев поверх существующих в EntityFraemwork.

Чаще всего используется один из двух подходов:

1. Generic Repository как попытка абстрагироваться от конкретного ORM.
2. Repository как набор запросов к выбранной таблице БД (паттерн DAO).

И каждый из этих подходов содержит недостатки.

Дорогие Хабраколлеги!

Хочу предложить вашему вниманию возможность приобщиться еще к одному языку программирования: F#. Идея писать такого рода заметки возникла из жизни — по роду своей деятельности мне приходится рассказывать про F#, и когда меня спрашивают, где можно попродробнее прочитать об этом языке — приходится ссылаться на англоязычные ресурсы. Поэтому я решил потихоньку рассказывать про F# в своем блоге, а теперь еще и на хабре, увидев замечательное сообщество стартап-программист. Поскольку F# — очень красивый язык, который никого не оставит равнодушным — я решил озаглавить цикл статей "влюбляемся в F#", а каждую из статей называть "дозой": по окончании их употребления вы должны будете подсесть на F#, а я буду мучительно эксплуатировать ваше терпение, делая вынужденные (из-за недостатка времени) перерывы между дозами.