can3p (can3p) wrote,
can3p
can3p

Category:

Про программирование, выпуск 2

Граф зависимостей

Здесь все порой просто и очевидно, иногда менее заметно. Проще всего программировать, когда программа представляет собой дерево зависимостей: вверху главный модуль/main, который в свою очередь создает нужные объекты, которые зовут что-то еще уровнем еще ниже с минимальным количеством взаимосвязей между кодом на одном уровне и уж тем более без спорадических эвентов из любого места в программе, которые меняют логику где-то еще.

Когда подобная архитектура нарушается, сложность начинает расти по экспоненте, и вот уже во сне бредишь тем моментом, когда получится спихнуть проект кому-нибудь еще.

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

Именно из-за этого раньше в эпоху отсутствия модулей и засилия jquery было трудно делать сложные проекты. Грав зависимостей остуствовал, изоляции не было, все в одном index.js, и все, надежды нет. Только палочные наказания и расстрелы.

И именно поэтому redux нашел такое широкое применение. И я тут про подход, а не про свзку с реактом. Граф зависимостей выпрямился, и внезапно стало получаться просто рассуждать о вещах, о которых раньше даже думать вразумительно было невозможно.

Деплой

Тут все просто, он должен быть простым и быстрым. Есть прямая зависимость качества продукта и счатья программистов от скорости деплоя (и роллбека, конечно). Быстрый деплой означает, что программисты будут выкатывать код сто раз на дню безо всяких последствий. Тестировать будет легко и ловить баги будет легко, т.к. изменения минимальные.

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

Децентрализация

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

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

Ровно также работает на нижних уровнях - если фронтенд компоненты / шаблоны независимы, то с любым из них работать легко и приятно. Можно заменить или переписать, можно сделать все, что хочешь, но это никак не отразится на логике других приложений. Тестировать тоже просто.

Tags: coding
Subscribe

  • Друзья рекоммендуют

    Есть уже давненько в ЖЖ раздел друзья рекоммендуют. Отличная идея, кстати, но как бы было здорово, если бы можно было этот раздел фильтровать! Я…

  • Весеннее обострение

    Зашел почитать новости про Амстердам на at5.nl (сайт/телеканал, который специализируется на Амстердаме и окрестностях) и от прочитанного немного…

  • Эмоджи

    Сегодня болтали, и внезапно подумалось (может я жираф, и последний догадался), что смайлики и эмоджи - это одна из фундаментальных новаций если не…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 2 comments