понедельник, 21 ноября 2016 г.

Горизонтальные и вертикальные слои приложения

«У лука есть слои, и у людоедов есть слои! Ты понял?» - Шрек

Эта заметка навеяна выступлением Jimmy Bogard на 0redev под названием “Solid Architecture in Slices not Layers”, которую я всячески рекомендую.

Как и у людоеда, у любого современного приложения есть слои. Классической моделью является мордочка наверху, бизнес-логика по центру и базейка снизу. Такое разделение вполне уместно и определяется множеством причин.

Conway’s Law

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

Такой разделение еще сильнее выстраивает барьеры между слоями приложения, поскольку тут начинает во всей красе проявляться Conway’s Law, когда архитектура приложения начинает повторять структуру организации.

понедельник, 14 ноября 2016 г.

Памятка ынтырпрайз кодера

После прочтения “Release It!” захотелось сохранить ряд мыслей по поводу разработки распределенного ынтырпрайз софта. То, о чем нужно думать, что нужно подпилить, о чем нужно не забыть и т.п.

1. Все что может отвалиться, обязательно отвалится

База ляжет, удаленный веб-сервис начнет тупить, перестанет проходить автортизация, ажура начнет отбивать запросы (throttling). Это значит, что любое взаимодействие с внешними системами должно это учитывать. К сожалению, это легче сказать, чем сделать, поскольку современные библиотеки для распределенного взаимодействия слоены до нельзя и с точки зрения API не вполне очевидно, что именно может пойти не так, какие исключения могут вылететь, и что с ними нужно будет делать.

понедельник, 24 октября 2016 г.

Менторинг и парное программирование

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

Итак, прежде всего немного контекста. В прошлой заметке шла речь об анализе классического подхода, описанного Кентом Беком в его «Экстремальном программировании», когда ни одна строка кода не попадает в финальный репозиторий, если над ней не работало два человека одновременно. Это весьма специфический вид совместной работы, главной целью которого является повышение качества кода. Обучение, обмен опытом, интересное время препровождение, все это пусть и полезные, но второстепенные артефакты этой активности.

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

Теперь давайте об этом более подробно.

понедельник, 17 октября 2016 г.

О парном программировании

Идея парного программирования в том, что работа над любым продуктовым кодом должна вестись совместно: вместе дизайним, пилим, ломаем и чиним. По идее, не должно быть ни одной закоммиченной строки кода, которые не прошли бы через 4 руки. И хотя в некоторых случаях совместная работа может быть полезной и продуктивной, но в подобной формулировке мне она всегда казалась через чур экстремальной.

До последнего времени у меня не было личного опыта парного программирования, поэтому мое мнение было сугубо теоретическим. За последние полгода у меня появился какой-то опыт, и именно им и хотелось бы поделиться.

PairProgramming

Итак, начнем с проблем.

четверг, 29 сентября 2016 г.

Hero Pattern

На некоторых особо популярных мировых галерах нередко можно встретить заболевание под названием Hero Pattern. Идея его в том, что гребец трудится усердно и много, монополизируя некоторый фронт работ, чтобы показать свою ценность и получить годовые плюшки с возможным повышением по службе.

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

Динамичность рынка труда требует роста на всех уровнях. Гребцы поматерее выдвигаются в рулевые, что автоматом выстилает дорогу в синьеры всем желающим. Просто нахождение тела на проекте автоматом дает ему шансы на продвижение независимо от талантов и умений. Наличие головы на плечах позволит довольно уверенно двигаться наверх внутри конторы. А в случае проблем на текущем месте, всегда найдется другой епам, которому позарез нужно стартовать очередной проект, и который не пожидится на +500 в месяц за тебя красивого.

понедельник, 19 сентября 2016 г.

О шаринге знаний и компетенций с коллегами

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

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

Для меня – делиться знаниями, даже скудными, это означает узнавать что-то лучше самому. Когда приходится рассказывать об архитектуре или используемых паттернах своему коллеге, то ты автоматически воспроизводишь все решение в голове и оцениваешь его валидность/корректность. Если коллега опытный, то он легко подправит твое понимание проблемы. Если же он новичок, то его стеклянные глаза будут прекрасным индикатором кривизны архитектуры или показателем полного отсутствия у тебя скила по донесению сложных вещей слушателю.

понедельник, 5 сентября 2016 г.

Инкапсуляция и сокрытие информации

В области проектирования существует два понятия, которые часто используются совместно – инкапсуляция (encapsulation) и сокрытие информации (information hiding).

Понятие инкапсуляции обычно используется в контексте ОО-языков и означает сокрытие данных (*). Открытые изменяемые (**) данные нарушают инкапсуляцию, поскольку теперь любой клиент класса сможет изменить внутреннее состояние объекта без ведома самого класса. Это может нарушить некоторые инварианты, т.е. условия на которые расчитывал автор класса и на которые, формально или неформально, должны полагаться его клиенты.

(*) – иногда понятие инкапсуляции применяется в более широком смысле. Например, говорят, что фабрика «инкапсулирует» информацию о конкретном типе создаваемого объекта. В этом контексте инкапсуляция является синонимом сокрытия информации.

(**) – хотя принято считать, что у класса недолжно вообще быть открытых данных, но с практической точки зрения, открытое неизменяемое поле хоть и нарушает инкапсуляцию, обычно не приводит к таким же серьезным проблемам сопровождения, как открытые изменяемые данные.