Skip to main content

Posts

На пути к публичному API

На пути к публичному API выясни, кому оно нужно. Публичное API затратно: проверка безопасности, тестирование на обратную совместимость, поддержание обратной совместимости, разработка примеров, разработка документации, проведение семинаров, разработка семинаров, генерация API reference, создание сайта. Если заказчик платит только за интеграции с выбранными партнерами, то все эти затраты излишни. Если заказчик думает только в терминах краткосрочной окупаемости, то публичное API ему не нужно. Выдав партнеру аннотацию swagger/raml, ты достигаешь 80/20 эффекта и пусть партнер ругает, но пишет. Разработчики с обеих сторон недовольны, каждый апдейт лишь увеличивает технический долг, но деньги от интеграций идут и KPI соблюдаются. Так к чему перфекционизм? Отринь его, смирись и понимай, что цель бизнеса в получении прибыли, а не создании более прекрасного мира.
Recent posts

Архитектор - как адаптер

Одна из главных функций архитектора - формирование единого непротиворечивого видения системы у различных stakeholder-ов. Архитектор описывает систему на языке, понятном бизнес-людям (деньги-сроки), разработчикам (критерии качества в количественной оценке), тестировщикам (ожидаемое поведение), интеграторам (точки сшивки системы), мейнтейнерам (связи компонентов, подсистем) и т.д. Очевидно, что если эти люди будут иметь разное представление о системе, то качества (качественного тестирования, достаточного времени на разработку, предсказуемого поведения и пр) системе не видать. Если говорить аллегорически, то эту функцию архитектора можно представить как адаптер. Так что Ленин - гриб (с), а архитектор - адаптер.

system design interview. practioner's guide

Разбираю обширную базу ссылок по архитектуре https://github.com/donnemartin/system-design-primer мотивация создателя ресурса - проходить system design интервью в крупных компаниях. но меня ресурс зацепил подборкой любопытных ссылок из индустрии уровня "а мы делаем так" и обсуждением конкретных технологий и решений (в противовес более абстрактным SEI-имским практикам). Этакая выкристализованная практика. 

восьмидесятипроцентное программирование

Не так давно была в прекрасном офисе крупной IT компании Х. Красивый просторный офис, фрукты и овощи на кофепоинтах, умненькие мальчики и девочки в коридорах, ухоженные и открытые. И три истории, как они пишут код заведомо плохого качества. У некоторых даже есть выражение на эту тему - "выблевать в продакшн". Я пыталась понять, что же приводит к этому низкому качеству. Это не отсутствие квалификации - ребята грамотные. Это не отсутствие денег - компания не настолько бедна, кроме того технический долг стоит немало. Единственное, что смогла придумать - это пресловутые 80%. Те 80% качества, которые получаются из 20% усилий. И все так привыкли, что можно получить эти 80% достаточно легко, что это становится стандартом индустрии. Видела, как у нас в компании продвигались люди, которые могли не стесняясь быстро наваять 80%, предъявить их руководству и оставить на других (на сопровождение) 20%, а потом размышлять что остальные страдают фигней. Разработка стоит дорого. И не-ит-шни...

Архитектурное ревью

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

ACDM

" A key concept of ACDM (Architecture Centric Design Method) is to accept the fact that these unknowns (precise production and cost estimates) exist and the architecture is used to reduce the period of uncertainty. Because of the period of uncertainty and the role architecture design has in mitigating the uncertainty, architectural design (like any kind of discovery) cannot be a one-time activity. ACDM provides specific techniques geared toward using the architecture to aggressively explore unknowns and overcome the period of uncertainty as quickly as possible " © Anthony Lattanze  "Architecting software intensive systems:  A Practitioner's Guide" Две вещи зацепили в этом кусочке: Архитектор - как борец с неопределенностью. Архитектор и вправду не может сказать "не знаю". Он (и команда) отвечают за свойства системы. И он дает гарантии. И за это ему платят. То есть, иногда архитектор может и не изменить значительно существующий дизайн, но...