Чистая архитектура

МЕНЮ


Главная страница
Поиск
Регистрация на сайте
Помощь проекту
Архив новостей

ТЕМЫ


Новости ИИРазработка ИИВнедрение ИИРабота разума и сознаниеМодель мозгаРобототехника, БПЛАТрансгуманизмОбработка текстаТеория эволюцииДополненная реальностьЖелезоКиберугрозыНаучный мирИТ индустрияРазработка ПОТеория информацииМатематикаЦифровая экономика

Авторизация



RSS


RSS новости


В книжках и статьях про архитектуру и как писать "чистый, совершенный код" дается много догматичных советов без примеров. А вот труд Роберта Мартина "Чистая архитектура" содержит кучу воспоминаний, которые интересно читать, даже будучи не программистом, а просто интересующимся историей компьютеров. Эти легенды каменного века кодеров находятся в конце книжки, и если вы найдете её в гостях - можете смело открывать, листать до последнего раздела - "Часть VII. Приложение. Архитектурная археология" - и зачитывать избранные цитаты, стоя на табуретке.

Цитаты:

"...совершим путешествие по последним 45 годам и познакомимся с некоторыми проектами, над которыми я работал начиная с 1970 года..."

"...Наша программа состояла примерно из 20 000 строк кода, а ее компиляция занимала примерно 30 минут. Шансы получить в это время ошибку чтения с ленты были 1 : 10. Если ассемблер сталкивался с такой ошибкой, он издавал сигнал на консоли и затем начинал выводить поток ошибок на принтер. Этот сигнал можно было услышать во всей лаборатории. Также можно было услышать проклятия несчастного программиста, только что узнавшего, что ему придется вновь запустить 30-минутный процесс компиляции...."

"...Повсюду были связи (внутри кода - прим. kvisaz). Но это было типично для программного обеспечения начала 1970-х...."

--- другой код ---

"... Мой друг и я занялись переводом программ для COLT с языка ассемблера M365 на язык ассемблера 8085. Перевод выполнялся вручную и занял почти 6 месяцев. В результате получилось около 30 Кбайт кода 8085
...
Однажды ко мне зашел мой начальник и попросил решить эту проблему. Он сказал, что нужно найти какой-то способ изменения микропрограммы без замены всех 30 микросхем ПЗУ. Мы в коллективе обсудили эту проблему и приступили к проекту «Векторизация». На его реализацию ушло 3 месяца.

Идея была до смешного простой. Мы разбили 30 Кбайт программного кода на 32 файла с исходным кодом, компилирующихся независимо в блоки меньше одного 1 Кбайт. В начало каждого файла с исходным кодом мы вставили инструкцию, сообщающую компилятору, в какой адрес должен компилироваться данный код (например, ORG C400 для микросхемы ПЗУ, вставляемой в гнездо C4).

Также в начало каждого файла с исходным кодом мы добавили структуру фиксированного размера с адресами всех подпрограмм в этом блоке (вектор переходов). Эта структура имела размер 40 байт, поэтому могла хранить до 20 адресов. Это означало, что блок для одной микросхемы не мог содержать более 20 подпрограмм.

Затем мы создали особую область в ОЗУ, которую называли массивом векторов. Она содержала 32 таблицы по 40 байт — достаточный объем для хранения указателей на начало каждого блока в отдельных микросхемах.

Наконец, мы заменили вызовы подпрограмм в каждом блоке косвенными вызовами через соответствующий вектор в ОЗУ.

Когда происходила загрузка программы, в массив векторов в ОЗУ загружались векторы переходов из всех микросхем ПЗУ, а затем осуществлялся переход в точку запуска главной программы.

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

Мы сделали блоки кода независимо развертываемыми. Мы изобрели полиморфную диспетчеризацию. Мы изобрели объекты.

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

--- другой код ---

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

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

В конце концов наше руководство предложило нам просто «заморозить» этот код и никогда не менять его. Этот код официально стал незыблемым.

Этот опыт показал мне, насколько ценным может быть хороший, чистый код.

(этот абзац подчеркивает значение "чистого кода" у Роберта Мартина - это хорошо понятный среднему работнику код, хорошо заменяемый, легко меняющийся - прим.)

--- другой код ---

"... Прошли годы, потом еще несколько лет, затем еще несколько и еще. Я не знаю, когда, наконец, была развернута первая система SAC на базе UNIX; полагаю, что это случилось уже после моего ухода (в 1988 году). На самом деле я вообще не уверен, что она была хоть когда-то развернута.

Почему так долго? Просто потому, что команде, занимавшейся созданием новой системы, было сложно угнаться за огромной командой, активно развивавшей старую систему.
....
не предпринималось никаких серьезных попыток интегрировать произведенные изменения с программным обеспечением в США. Эта работа велась задолго до появления сетей, позволявших передавать большие объемы кода через океан. Британские разработчики просто взяли за основу код из США и исправляли его под свои нужды.

Это, конечно, вызывало трудности. Ошибки обнаруживались по обе стороны Атлантики, и их требовалось исправлять на обеих же сторонах. Но модули значительно изменились, поэтому было трудно определить, будет ли исправление, сделанное в США, работать в Великобритании.
...
После нескольких лет изнуряющей гонки и появления скоростной линии, связавшей офисы в США и Великобритании, была предпринята серьезная попытка интегрировать две системы, переместив все различия в настройки. И первая, и вторая, и третья попытки провалились.
...
Я мог бы продолжать рассказывать истории об этой системе, но это неприятные для меня воспоминания. Достаточно сказать, что многие из этих горьких уроков в моей карьере программиста были получены в процессе погружений в ужасный ассемблерный код SAC. ...»

О языке С

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

О телефонной революции

"... Конец 1970-х — начало 1980-х годов было шумным временем для телефонных компаний. Одной из причин волнений стала цифровая революция... ... телефонные компании приступили к замене старого аналогового коммутационного оборудования современными цифровыми коммутаторами.
...
Проблема состояла в том, что на каждый модуль CCU приходилось много модулей CMU. Информация о том, какой модуль CMU использовать для каждого телефонного номера, содержалась в самом цифровом коммутаторе. То есть модуль CCU должен был опросить цифровой коммутатор, чтобы определить, с каким модулем он должен взаимодействовать.

Мы пообещали телефонным компаниям, что создадим эту новую архитектуру к моменту их перехода. Мы знали, что это займет месяцы, если не годы, поэтому чувствовали себя раскованно. ..."

О телефонной революции, Ловушка планирования

"...мой начальник вызвал меня к себе в кабинет и сказал: «Один из наших клиентов развертывает цифровой коммутатор в следующем месяце. К тому времени у нас должен быть рабочий комплекс CCU/CMU».

Я был в ужасе! Как за месяц выполнить работы, требующие одного человеко-года? Но у моего начальника был план...

...нам в действительности нужна не полная архитектура CCU/CMU, а только простой компьютер в телефонной станции, связанный модемными линиями с двумя стандартными компьютерами COLT в распределительных пунктах. Компьютер SAC мог бы связываться с нашим компьютером в телефонной станции, а тот, в свою очередь, мог бы декодировать телефонный номер и посылать команды на выполнение тестирования в компьютер COLT, находящийся в соответствующем распределительном пункте.

Так родилась система pCCU.

Это был первый продукт, написанный на C и использующий BOSS, развернутый у клиента. На разработку мне понадобилось что-то около недели. ..."

--- другой код ---

"...ROSE — это гигантское приложение на C++. Оно состояло из уровней со строго соблюдаемым правилом зависимости. Это не то правило, что я описал в данной книге. Мы ориентировали наши зависимости не в сторону политик более высокого уровня, а в более традиционном направлении — в направлении потока управления. Пользовательский интерфейс зависел от представления, которое зависело от правил выполнения операций с данными, которые зависели от базы данных. В результате эта, не совсем удачная ориентация зависимостей способствовала кончине продукта.

Архитектура ROSE была похожа на архитектуру хорошего компилятора. Графическая нотация «преобразовывалась» во внутреннее представление; затем это представление обрабатывалось правилами и сохранялось в объектно-ориентированной базе данных.

Объектно-ориентированные базы данных были относительно новой идеей, и мир ОО был взволнован возможными перспективами. Каждый объектно-ориентированный программист желал иметь объектно-ориентированную базу данных в своей системе. Идея была относительно простой и глубоко идеалистической. База данных хранила объекты, а не таблицы. База данных должна была выглядеть как ОЗУ. Когда производилось обращение к объекту, он просто возникал в памяти. Если этот объект ссылался на другой объект, тот другой объект тоже появлялся в памяти при первой попытке обратиться к нему. Это было похоже на волшебство.

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

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

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

Так я узнал, что великие архитектуры иногда приводят к великим провалам. Архитектура должна быть достаточно гибкой, чтобы подстраиваться под размер задачи. Разработка архитектуры для уровня предприятия, когда в действительности нужен маленький и удобный инструмент для настольного компьютера, — это верный рецепт провала...."

Там много такого и на самом деле каждую такую историю можно было бы издавать как короткий рассказ для медитаций.

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

Когда-нибудь, из этого сформируют общую абстрактную науку - если наверно, уже не сформировали. Что-нибудь подобное пишут сейчас в учебниках по ТАУ (теории автоматического управления)? В годы моего студенчества - нет.


Источник: m.vk.com

Комментарии: