Шизоидный язык программирования самообучающихся алгоритмов «Автор»

Я хочу поведать миру принципиально новый язык программирования, аналогов которому нет во всём мире.

В своё время я был, одержим идеей искусственного интеллекта. Когда я стал программистом, я понял, что всё не так просто, и можно сказать даже гораздо сложнее, чем казалось. Я не переставал работать над программами и осваивал все известные нынче языки программирования. Я пытался переложить на машину как можно больше собственных мыслительных процессов, и оказалось, что они занимали большие объемы кода и сами умели очень мало. Я пытался заставить программы учится, делать выводи, и использовать их в дальнейшем. Но все языки программирования имеют одинаковый недостаток – они не могут рассматривать алгоритмы, как данные. Программы не могут учиться, по тому, что они не имеют доступа к самим себе.

Так я пришел к тому, что нужно сделать «Си» подобный интерпретатор, программы на котором будут иметь возможность доступа к самим себе. Идея проста – чтобы учиться, нужно изменяться, а для этого нужно иметь доступ к собственному коду. Теперь обучение становится хотя бы возможным. После любого вмешательства в тело алгоритма, оно становится отличным от своего исходного кода программы и эти изменения нужно сохранить. Интерпретатор становится как бы автором новой программы. Поэтому язык использует следующую культуру. Файл с кодом «*.txt» имеет свой дубликат «*.code», который создаётся автоматически. Такая пара называется модулем. При загрузке модуля «Автор» выбирает, из пары, файл, записанный позже, а в случае отсутствия одного из пары, и выбирать не приходится. Таким образом, исходный код всегда остаётся нетронутым, а все изменения, которые произошли, будут видны программисту в файле дубликате. Стартовый модуль должен иметь точку входа (main) и для запуска нужно перетянуть мышкой файл на «author.exe». Любой модуль может запрашивать дозагрузку других модулей (#include <me.txt>). Также модули можно загружать и выгружать в процессе исполнения кода командой include(“me.txt”) и uninclude(“me.txt”). По завершении работы алгоритма, «Автор» выгружает стартовый модуль. Каждый модуль имеет счётчик количества модулей, которые его запросили, и в случае достижении нуля, модуль выгружает свой код в файл дубликат. До перезаписи файла дубликата модуля доходит только тогда, когда в нём (модуле) случилось хоть одно изменение или же дубликата не было вовсе. Таким образом, можно как угодно прописывать подключение модулей, не задумываясь о том, каким будет дерево подключений, модуль всегда будет в памяти в одном экземпляре. Главное не подключить самого себя.

Синтаксис языка «Си» подобный. Модуль содержит множество функций. В файлах программа представлена как текст. Но при загрузке, происходит преобразование и развитие кода до динамической структуры схемы алгоритма. Для каждой функции создаётся потоковый граф и уже к нему получает доступ программа. При выгрузке модуля происходит обратное преобразование, схемы в текст программы. «Автор» даже пытается придерживаться стиля программирования, чтоб код был не в одну строчку. Таким образом, можно, например, сделать функцию, которая сможет подсчитать количество условий или циклов в указанной функции, например в самой себе. Полагаю читателю будет интересно взглянуть на такую функцию, по этому, не смотря на запрет модератора, я приведу её:

 // noproblem.txt // Программа подсчёта собственных циклов и условий void main(){ 	f=getFunction(getThisFunctionName()); // доступ к себе 	tree=f.export(); // преобразовать в дерево алгоритма 	counterIF=0; 	counterWHILE=0; 	counterDO=0; 	counterFOR=0; 	// организация обхода дерева вложенных циклов и условий 	access={}; 	do{ 		n=tree.getRowSize(access); 		access.push(n); 		while(access.size()){ 			n=access.pop(); 			--n; 			if(n<0)continue; 			access.push(n); 			sub=tree.getSub(access); 			type=""; 			if(typeof(sub)=="program")type=sub.typeof(); 			if(type=="if")++counterIF; 			if(type=="while")++counterWHILE; 			if(type=="do")++counterDO; 			if(type=="for")++counterFOR; 			break; 			} 		}while(access.size()); 	trace("В алгоритме функции " + f.getName().export() + " содержится:"); 	trace("Условных ветвлений: "+counterIF); 	trace("Циклов while: "+counterWHILE); 	trace("Циклов do: "+counterDO); 	trace("Циклов for: "+counterFOR); 	getstring(); } 

В алгоритме функции «main» содержится:
Условных ветвлений: 6
Циклов while: 1
Циклов do: 1
Циклов for: 0

Переменные в языке не имеют привязки к типу подобно PHP и JS. Их даже необязательно объявлять. Тип, указанный при объявлении, служит не более чем комментарий. Переменная создаётся также при употреблении её в конструкции для записи (а=0;). При обращении для чтения из неизвестной переменной возвращается тип «void».

Значение любой переменной может иметь тип: void, int, float, double, digit, char, string, interval, vector (множество), set (уникальное множество), map (ассоциативный массив), program (дерево алгоритма), function (схема алгоритма), graf, module. В языке также присутствуют указатели, но в связи с шизоидной особенностью, они организованы как строка с данными для доступа к переменной. Переменная может содержать указатель на саму себя (p=&p;p=****p;). Можно взять строку с названием типа значения. «typeof(typeof(#))==”string”» – всегда истина.

В языке можно использовать особый операнд «#». Он возвращает тип «void» и служит символическим обозначением скрытого блока, который, как и любой другой операнд, можно поменять на конструкцию дерева операторов, какой угодно сложности. При попадании значения «void» в условие тернарного оператора, интерпретатор, каждый раз, на момент исполнения, случайным образом определяется между истиной и ложею. Выражения «#?1:0» и «rand()%2?1:0» – аналогичны. Но есть серьезная разница между «if(#);» и «if(#?1:0);».

При попадании значения типа «void» в условие, наступает шизофрения. Текущая точка исполнения алгоритма, в этот момент, делится на две. Одна переходит по истине, другая по лжи. В дальнейшей интерпретации, по мере необходимости, делится на две и вся карта памяти. Таким образом, можно сказать, что каждая точка исполнения имеет свою отдельную карту памяти.

 // Пример шизоидной программы: main(){ 	n=0; 	if(#)n=1+1; 	n+=10; 	trace(n); }  10 12 

Поскольку консоль никак не делим, вывод на него осуществляется по очереди в неопределённом порядке.

Деление точки исполнения можно сделать и особой функцией «rozpad()». Она принимает множество значений и возвращает каждое из них в своей точке исполнения. Таким образом, выражения «if(#);» и «if(rozpad({1,0}));» аналогичны. Выражение «n=rozpad({1,2,3})+rozpad({10,150});» причинит шизоидный распад на шесть процессов, с различным значением переменной «n»: 11, 12, 13, 151, 152 и 153.

Чтобы определится между всеми вариантами процессов случайным образом, нужно вызвать функцию «define();». Таким образом можно свести все точки исполнения в одну.

Пришло время сосредоточится на шизоидной особенности языка. Так я называю возможность обработки неоднозначных данных. Все современные языки программирования используют переменные для хранения разнообразных данных, но все их значения находятся в единственном варианте. «Автор» же позволяет хранить неоднозначные значения в любой переменной. Таким образом, алгоритмы написаны на этом языке, готовы в любой момент, столкнутся с возникновением неоднозначности в процессе решения поставленной задачи. Но, часто, бывает так, что сама задача, на человеческом языке звучит неоднозначно. Например, такая задача: «Дано массив из 4 – 5 чисел, нужно его отсортировать».
Неоднозначность алгоритма решения исходит из самой постановки задачи. Во-первых, не указан однозначно размер массива, а точнее размер его задан в двух вариантах. Допустим, мы можем сами определить значения чисел массивов. Во-вторых, отсортировать массив возможно как по возрастанию, так и по убыванию. Вот как выглядит программа для решения данной задачи:

// sort.txt
main(){
if(#)m={6,2,9,1}; else m={3,7,21,45,8};
m.sort();
if(#)m.reverse();
trace(«Результат: „+m.export());
}

Результат: {9,6,2,1}
Результат: {45,21,8,7,3}
Результат: {1,2,6,9}
Результат: {3,7,8,21,45}

Операнд «#» возвращает значение «void». При попадании его в условную конструкцию ветвления, из которой, между прочим, состоит любой цикл, точка исполнения алгоритма делится на две. Одна переходит по ветке истины, другая по ветке лжи. Для каждой точки исполнения существует своя карта памяти, то есть относительно одной позиции интерпретации, все переменные содержат однозначные значения. Таким образом, после исполнения первой строчки программы, компьютер как бы делится на два. Они оба продолжают исполнять одну и туже программу, но уже с разными значениями переменной «m». Во второй строчке программы, каждый компьютер сортирует свой массив по возрастанию. Далее происходит деление каждого компьютера ещё на два. Одна пара проходит через команду реверса массива, а другая – нет. Затем все компьютеры выдают отчёт на свой общий экран.

Теперь рассмотрим шизоидное деление на другом примере. Нужно найти, какая комбинация значений переменных «а» и «b» даст в сумме число 20, притом, что «а» может быть одним из множества {5,3,7}, «b» может быть одним из множества {15,17}.
Программист сразу увидит тут два вложенных цикла. А вот, как выглядит программа на «Автор»:

void main(){
a=rozpad({5,3,7});
b=rozpad({15,17});
if(a+b!=20)OFF;
trace(“a+b==»+a+"+"+b);
}

a+b==5+15
a+b==3+17

В первой строчке программы происходит деление точки исполнения на три параллельных, в каждой из которых функция «rozpad()» возвращает своё значение, одно из заданного множества. Во второй строчке происходит аналогичное деление каждой точки исполнения на две. Таким образом, переменные получат своё сочетание значений из указанных множеств. Далее идет условие, по которому все «компьютеры», у которых «a+b != 20» переходят к команде «OFF», по которой они исчезают. Таким образом, до команды отчёта дойдут только те «компьютеры», у которых «a+b == 20» и значение их переменных выводится на общий экран.
Часто приходится делать выбор и выбирать одну из альтернатив. Но для того, чтоб сделать любой выбор, нужно иметь один, чётко сформулированный, как угодно сложный, критерий. А как быть, если критерий выбора неизвестен или не задан? Случайный, равновероятный выбор. Вот универсальный и простейший критерий. Для указания в алгоритме потребности выбора одного варианта процесса, со своими данными, в языке есть встроенная функция/команда «define()». Она осуществляет выбор одной точки исполнения из существующего, на момент исполнения её, множества. Как это работает. Текущий процесс достигает команду «define()» и останавливается. Активным делается другой, не остановленный, процесс из списка параллельных процессов. Когда все процессы в списке стают, остановлены, это значит, что пришло время сделать выбор одного из них. Избирается одна точка исполнения из списка, а все остальные процессы закрываются. Выбранный процесс запускается на дальнейшее исполнение алгоритма. Таким образом, независимо от порядка обработки параллельных процессов, после исполнения команды «define()» объективно, гарантировано остаётся только одна точка исполнения, со своим вариантом данных.
main(){
trace(«Известные приветствия:»);
string str = rozpad( {«Привет.», «Здравствуйте.», «Доброго времени суток.»} );
trace(str);
define();
trace(«Я выбрал: „+str);
}

Известные приветствия:
Привет.
Здравствуйте.
Доброго времени суток.
Я выбрал: Привет.

Следующая программа определяет из заданного множества чисел одно отрицательное и одно положительное число:

void main(){
i=rozpad({-3,-2,-1,0,1,2,3});
if(i<0)define(); else define();
trace(i);
define(-1);
getstring(); // ждёт нажатия «Enter»
}

-3
1

В первой строчке кода происходит деление на варианты. Во второй – деление на две группы и определение одного варианта для каждой из условных групп. Далее выводим на экран результат и ждем нажатия «enter».
Функция «define()» может принимать одно числовое значение. Оно определяет приоритет определений. Первым произойдёт то определение, которое получит большее число. По умолчанию берётся ноль. Если порядок определения неважен, можно использовать одинаковое число. Вот пример кода, для которого порядок определения важен:

void main(){
int n=rozpad({-2,-1,0,1,2,3});
if(n>=0)define(1);
trace(n);
define(2);
trace(“OK»);
}

-2
-1
OK
2
OK

Продолжение следует.

ссылка на оригинал статьи https://habrahabr.ru/post/276895/

Способы генерации SVG-спрайтов на примере библиотеки svg-sprite

SVG sprites intro

Недавно я решал задачу организовать все SVG-файлы, используемые в проекте, в виде одного спрайта. До этого мне приходилось использовать самописное решение для такой задачи. На этот раз я решил воспользоваться популярной библиотекой svg-sprite, однако был сильно удивлен сколько разных способов создания она предлагает. Какой-то единой статьи где были разобраны все способы я не нашел, вся информация была разбросана по блогам и отдельным публикациям. Поэтому я решил собрать доступные в библиотеке способы для генерации спрайтов в одном месте, попутно проанализировав их преимущества и недостатки. Итак, поехали.



Режим CSS

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

Пример использования будет выглядеть так

<i class="svg-ei-archive">ei-archive</i>

и соответствующий CSS-код

.svg-ei-archive {     background: url("svg/sprite.css.svg") 12.5% 0 no-repeat;     width: 50px;     height: 50px; }

Приятно особенностью svg-sprite является возможность задать в каком виде вы хотите получить стили — в виде чистого CSS или под препроцессоры LESS, SASS, Stylus. Немного поигравшись с шаблонами вывода, можно настроить вывод иконок в виде миксинов и генерировать код только тогда, когда он действительно нужен.

Преимущества: метод просто и понятен каждому, кто до этого работал со спрайтами.

Недостатки: невозможно указывать произвольные размеры, управлять цветом иконки. Не получится использовать в теге img

Режим defs

Этот режим использует тег defs, внутри которого объявляется элементы для дальнейшего использования. Каждому элементу присваивается id, по которому этот элемент будет вызван в теге use.

Пример использования

<svg viewBox="0 0 50 50" width="50" height="50">     <use xlink:href="#ei-archive"></use> </svg>

Для того чтобы use из примера смог отрендерить элемент, SVG с defs должен быть также включен в тело документа. Стандартом допускается использовать внешний файлов в xlink:href, однако это не поддерживается всеми версиями Internet Explorer. К счастью, существует полифил svg4everybody, который решает эту проблему.

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

Недостатки: Скорее всего потребуется некий механизм (макрос, хелпер, функция), который будет генерировать код вставки иконки. При генерации приходится указывать атрибут viewBox и размеры. Согласно спецификации элементы внутри defs не должны отображаться, поэтому нельзя будет визуально оценить как выглядят спрайты после оптимизации. Впрочем, svg-sprite помогает в этом и может создать файл с образцами всех иконок.

В настоящее время использовать этот метод нет смысла, его улучшенной версией является Режим symbol.

Режим symbol

Принцип работы этого режима аналогичен предыдущему, но для задания элементов используется тег symbol. Этот элемент, согласно спецификации, может содержать атрибут viewBox, поэтому отпадает необходимость указывать его при использовании заданного символа. Также элементы, созданные с использованием symbol, отображаются при рендере, что упрощает визуальный контроль созданных спрайтов. В остальном применение этого метода не отличается от Режима defs.

Пример использования

<svg width="50" height="50">     <use xlink:href="#ei-archive"></use> </svg>

Преимущества: Аналогично предыдущему режиму (легкая смена цвета и размеров).

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

Режим view

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

Как обычную фоновую картинку из первого режима

<i class="svg-ei-archive">ei-archive</i>

и как отдельное изображение, встраиваемое с помощью идентификаторов фрагмента (fragment identifiers)

<img src="sprites.svg#ei-archive" width="50" height="50>

На мой взгляд очень удобно. Одна и та же иконка может быть и картинкой, и фоном в зависимости от ситуации. В настоящее время поддержка идентификаторов фрагмента полностью отсутствует в iOS 9.x, несмотря на то, что частичная поддержка была в предыдущей версии.

Преимущества: Можно использовать иконку как для фона, так и для изображения. Легко менять размер, если используется как изображение.

Недостатки: Проблемы с поддержкой в iOS в настоящий момент. Нельзя установить в качестве фона на блок произвольного размера. Нет возможности смены цвета через CSS.

Режим stack

Данный способ также использует именованные области просмотра, однако располагает их одну под другой, подобно слоям в Фотошопе. Каждая область скрыта по умолчанию и становится видна, при ссылке на нее через fragment idetifier

:root>svg {display:none} :root>svg:target {display:block}

Соответственно, нам также доступны два способа использования.

Как фоновая картинка

.svg-ei-archive {   background: url(sprites.svg#el-archive)  no-repeat 50% 50%; }

и как обычное изображение

<img src="sprites.svg#ei-archive" width="50" height="50>

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

Преимущества: Аналогично предыдущему способу, но нет ограничений для изменения размера в зависимости от способа использования.

Недостатки: Проблемы с поддержкой браузерами в настоящий момент. Нет возможности смены цвета через CSS. Из-за особенностей метода все иконки скрыты по умолчанию, поэтому визуально оценить готовый спрайт затруднительно.

Бонус-режим inline-css

Этот метод не является стандартным способом для библиотеки svg-sprite, но может быть создан на ее основе. Смысл его заключается во встраивании самой иконки в файл-стилей через data-url. Библиотека svg-sprite предоставляет широкие возможности для кастомизации шаблонов вывода и дает доступ к исходному коду самой иконки. Поэтому есть возможность создать свой шаблон, который будет генерировать следующий код.

.el-archive {   background: url("data:image/svg+xml;[icon-data]"); } 

Однако, на практике, решить эту задачу с наскока не удалось и вопрос требует более детального рассмотрения.

В качестве заключения

Представленные способы не являются единственными для создания SVG-спрайтов. Мне попадались и другие, более экзотические варианты. Какой способ лучше решаться придется вам исходя из того, какой набор иконок имеется и какие возможности для кастомизации вам нужны. На мой взгляд вполне production-ready можно считать режимы css и symbol.

ссылка на оригинал статьи https://habrahabr.ru/post/276463/

Записки правдивого архитектора: просто о самом главном (Ч.1)

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

«Хмм… правдивого архитектора… А что, такие бывают? – спросите вы и подумаете. — Врет, поди! Сейчас будет нам рассказывать очередную концепцию „бла-бла-бла.2.0“. Знаем, плавали, видали мы „витающих в небесах архитекторов“ и их умозрительные конструкции».
И будете правы: нормальный «пацанский» архитектор — человек очень занятой, и времени писать статьи у него, как правило, нет… Но! Бывает, что настает момент – и желание человека поделиться опытом, рассказать о своих удачах и сложностях миру настолько высоко, что и время находится, и присущий нашему брату-технарю страх публичных высказываний отступает. К тому же коллеги по цеху давно призывали меня начать подобную деятельность.

Стартовать я решила с темы несколько общего характера – ИТ-архитектуры в целом. Почему бы сразу не перейти непосредственно к деталям, которые наиболее занимают читателей технических блогов?
Ответ прост: уж больно много вопросов, трактовок и кривотолков возникают вокруг работы и задач архитекторов. И чтобы двигаться дальше, нужно выстроить некую «общую систему координат» — некую отправную точку.
За время моей работы сложилось некое «видение» происходящего, которым хотелось бы поделиться и обсудить с коллегами.

Итак, попробуем поискать ответы на следующие вопросы.

  • Что такое архитектура?
  • Что такое целевая архитектура?
  • Что такое архитектурные стандарты и фреймворки и зачем они нужны?
  • Кто заказывает архитектуру, какие у нашего заказчика могут быть желания и потребности, высказанные и невысказанные?
  • Какую архитектуру можно назвать хорошей архитектурой?
  • Зачем нужны архитекторы? Какова их роль? Чего от них ожидать и почему?
  • Когда компании нужно вкладываться в архитектуру? Что будет, если этого не делать?


Если вы когда-либо задавались подобными вопросами, и они представляют для вас интерес, то эта статья для вас — приглашаю поразмыслить вместе.


Что такое архитектура?

Итак, начнем «от печки» — попробуем дать определение этому понятию.
Не только архитекторы, но и древние философы обращали внимание на терминологию в своих беседах с досточтимыми правителями государств: image
«Если имя неправильно (не соответствует сущности), то слово противоречит делу, а когда слово противоречит делу, то дело не будет исполнено, а если дело не будет исполнено, то церемонии и музыка не будут процветать, а если церемонии и музыка не будут процветать, то наказания не будут правильны, а когда наказания будут извращены, то народ не будет знать, как ему вести себя. Поэтому для благородного мужа необходимо, чтобы он непременно [мог назвать правильные имена вещей с тем, чтобы] сказанное исполнить и чтобы в словах его не было ничего бесчестного (недобросовестного)»
/Конфуций «Суждения и беседы»/

image
И все-таки я не стану приводить все возможные, замечательные по своей полноте, оригинальности и глубоким смыслам, определения термина «архитектура». Да и нет такой задачи — дать идеальное определение (если это вообще возможно). Главное – это понять суть предмета.
А знаете… я вообще не стану приводить определение. По крайней мере, прямо сейчас. Сделаю это позже.
Даже в такой строгой науке, как математика, как говаривал мой педагог из универа, век идеальных определений давно прошел:
«Не помнишь определение из учебника – и не надо. Попробуй пойти от примеров – и таким образом выстроить понятие».

Итак, Архитектура… Да, именно подобные картинки помещаются частенько на титульный лист архитектурной ИТ-концепции и становятся символом («логотипом») архитектурных подразделений крупных компаний.
Конечно, первое, что приходит на ум – это связь с известной всем областью строительства. Архитектура зданий, сооружений, городов – сфера хорошо известная и имеющая давнюю историю.
Справедлива ли аналогия?
Безусловно! Более чем!
Известны целые исследования на эту тему – например, статья Пата Хелланда «Метрополис».

Архитектура зданий, сооружений, городских ландшафтов развивается столь давно и стала столь привычна для человеческого восприятия, что этот термин не требует объяснения даже людям, весьма далеким от строительной индустрии…
Какие ассоциации у нас возникают при слове «архитектура» в классическом его понимании?

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

и др.

Можно выделить два основных аспекта, направления, по которому прорабатывается архитектура:

  • восприятие человеком;
  • технологический аспект.

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

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

Первые вопросы, которые мы себе задаем, звучат так:

  • Зачем мы это делаем?
  • Какие проблемы и задачи есть сейчас? Кого это затрагивает? В чем это выражается? Что будет, если их не решать?
  • Как может выглядеть наша «картинка будущего», когда мы это сделаем?
  • Каким образом это затронет людей, которые сейчас работает и будет работать с этим функционалом?
  • Как это затронет другие системы? Как поменяются информационные потоки внутри компании?
  • Кому, как и когда должна быть доступна порождаемая при этом информация? Как она будет соотноситься с другой информацией, генерируемой компанией?
  • Какой набор шагов (проектов) мы должны сделать – чтобы прийти к желаемому результату?
  • Сколько это будет стоить? Какие есть альтернативы?
  • Нам раньше доводилось делать нечто подобное? Что мы хотим взять из этого опыта? Что хотим попробовать сделать иначе? Почему?
  • Возможно, кто-то это уже делал? Как они это делали? Какие результаты получили? С какими проблемами столкнулись?
  • Мы в это идем, потому что нам это даст…

Как видно, это очень разноплановый перечень вопросов. И все они в той или иной степени имеют отношение к ИТ-архитектуре предприятия. Не все из них находятся «во власти», в зоне непосредственной ответственности архитектора, но они находятся в зоне его влияния. И следующий раздел – как раз об этом. О чем стоит задуматься, прежде чем…

«Вижу цель – не вижу препятствий» или Что такое целевая архитектура?

Есть такая известная во всех крупных компаниях тема – “целевая архитектура”, мифическая и таинственная, почти как любовь: “Все о ней говорят, но мало кто ее видел” /Ларошфуко/
Стало быть, целевая архитектура должна ответить, прежде всего, на вопрос – зачем мы это делаем. Т.е. она обозначает цель, смысл нашей деятельности. И лишь затем мы задумываемся и решаем — каким образом мы будем этого достигать, за счет каких технологий, на каких платформах.

Прежде чем бросаться отвечать на вопрос «как» (делать, внедрять систему, платформу и т.д.) убедитесь, что ответили на вопрос «зачем».

Все просто! И если этого простого (и вроде бы очевидного, не так ли?) шага не сделать, а броситься бегом строить схемы и кодить, кодить, кодить… то есть большой шанс, что этот труд потом улетит в корзину! И в результате посетит и вас, и вашу команду, и ваших заказчиков великая печаль. Задавайте себе этот вопрос не в конце, а вначале своего “забега”.

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

Четко напрашивается, по крайней мере, один вывод: этими вопросами необходимо озадачиться до точки старта проекта. И даже до момента его инициации. “Но как же так?” – может возникнуть вопрос: “Мы же уже давно привыкли, что вся деятельность ИТ осуществляется в рамках проектов, а в случае гибких методов – в рамках спринтов”.
Вот тут начинается интересное… Послушаем, что говорят на эту тему “ведущие собаководы” ИТ-отрасли — т.е. организации, создающие и распространяющие разного рода стандарты и референсные практики.

Так, OpenGroup на этот счет выпустила недавно концепцию IT4IT. Операционная модель ИТ, которая там представлена, включает в себя набор четырех базовых «цепочек создания ценностей» (VAD). Одна из них – “Strategy to portfolio”, в рамках которого и формируется “портфель проектов”, отталкиваясь от того, что мы хотим видеть (целевое видение) и от ситуации as-is (текущая архитектура). Таким образом, через ИТ-стратегию и портфель проектов выстраивается мостик к нашей желаемой «картинке будущего».

/Самое время спросить себя о том, а как у нас в компании принято формировать «портфель проектов»? Как порождаются проекты? На каком этапе к этому процессу подключают архитекторов? Кто принимает решение о запуске проекта? /

Таким образом, правильным выглядит такой путь:
Сперва целевая архитектура… Точнее, сперва бизнес-стратегия, потом целевая архитектура, которая ее поддерживает, далее — стратегия ИТ, которая отражает переход от текущего состояния к целевой, и, наконец, в соответствие со ИТ-стратегией – формирование портфеля проектов.
Вот почему архитекторы на предприятии так упорно говорят о целевой, о необходимости соответствия проектов ее руслу, о необходимости фиксации отклонений (временных и обходных решений) и т.д. Это их прямая обязанность. Это их работа. И это их ответственность. И для них важно, чтобы разговоры об архитектуре не носили бесконечный характер, а завершались вполне определенным delivery – и определенными (зафиксированными решениями).

Часто ли так происходит?
Да нет, конечно… В нашу стройную систему вмешивается господин Хаос. Точнее люди, которые сами его создают, осознанно или неосознанно. Однако выбирать не приходится – и нам тоже надо как-то существовать в предлагаемых жизнью обстоятельствах – неопределенности, несогласованности, неразберихи и т.д.
Попробуем разобраться, как все происходит, и что с этим можно сделать.

О целевой архитектуре (как и о любви) можно говорить бесконечно… И поэтому, важно зафиксировать некое видение – получить «картинку будущего». Либо несколько вариантов – несколько «картинок».
Почему важно фиксировать? Казалось бы, очевидный вопрос, но как ни странно, много копьев ломается вокруг этого.
Потому как – целевая архитектура – это наша «опора из будущего». Представьте – какой возникнет хаос в нашем портфеле проектов, если она все время будет меняться?
Кто занимается подобной проработкой и отвечает за качество результата? Конечно, ИТ-архитектор – это его зона творчества, влияния и ответственности. При этом он общается с большим количеством людей, собирает и обрабатывает множество информации, изучает существующие аналоги, что-то пробует. И наконец, предлагает некое целостное решение – архитектурную концепцию. Она и представляется на дальнейшее обсуждение и утверждение как целевая архитектура – сперва в очень общем плане – как концепция или видение.

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

Хорошим способом является подход, в процессе которого некое предлагаемое решение «проверяется на устойчивость» — вопросы из серии «что будет если…». Взгляд на 360 вокруг этой темы.

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

Выйти в конструктив можно, если

  1. не привлекать к участию лишних людей;
  2. допускать к обсуждению замечания в рамках своей компетенции (зоны принятия решений и ответственности);
  3. приводить только аргументы, четкие и конкретные;
  4. иметь ясные критерии выноса вопросов на всеобщее обсуждение и понимание модели/формата этих обсуждений;
  5. четко модерировать собрание – придерживаться установленных правил и избегать «базара» (ввести и закрепить правило – в один момент времени говорит только один человек).

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

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

Здесь может возникнуть вопрос, что делать, если действительно такого настроя в данный момент не прослеживается? Можно ли его поменять?
Во-первых, необходимо увидеть и осознать проблему, приостановить дискуссию непосредственно по теме встречи, т.к. когда люди «сели на эмоции» уровень аргументации, логических доводов перестает работать.
Второй шаг – постараться увидеть позитивное намерение человека, который возражает, как нам может казаться, весьма странно – например, переводит фокус внимания к другой больной для него теме, уводит в сторону и т.п. И увидеть свою собственную приверженность, если вас это, в свою очередь, начинает раздражать. Если мы вовремя «поймали момент», и страсти еще не накались, успели «нажать на паузу», осознать и мысленно сформулировать это, то нас уже сложнее будет «выцепить на эмоцию» — уже хорошо.
Третий шаг – «возвращаем» человеку его же намерение, но в позитивной формулировке. Таким образом, ему не просто сказали, что «я тебя слышу», а его реально услышали и дали обратную связь. Хорошо бы это также записать и пообещать вернуться к этому важному и острому вопросу позже. И попросить разрешения продолжить встречу.
Острота спадает, конструктивный настрой остается.
Конечно, это не так просто. Легко написать — трудно сделать. Нужен опыт и тренировка в коммуникациях и переговорах. Эта тема весьма обширна, и раскрыть ее здесь не получится, только слегка наметить и создать уверенность, что такие подходы точно есть, они рабочие, и при желании их можно найти, изучить и проработать на практике (лучше с помощью опытного наставника).

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

Замечу, что «зрелость» по отношению к компании не определяется ее размером или ее возрастом. Бывают довольно крупные компании, которые не отличаются высоким уровнем зрелости: т.е. не стремятся «понять себя» — свой бизнес, своих сотрудников, свои цели. А стратегические инициативы часто носят формальный характер.
В то время как есть стартапы, в которых люди довольно быстро приходят к выводу, что например, одного классного кодинга (если говорить про ИТ-сферу) не достаточно – необходима некая организующая и направляющая сила.
И тому есть реальный примеры. Недавно моего друга-архитектора пригласили поучаствовать в подобном проекте, в котором уже работают хорошие разработчики, работают с драйвом и интересом, на новых технологиях и т.п. И при этом говорят: «как-то странно выходит – кодим-кодим, но как-то… не понятно, к какому результату мы движемся».

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

Сейчас много пишут о том, что банкам грозит конкуренция с ИТ-компаниями. И руководители банков начинают спешно перестраивать практики управления под ИТ – внедряют гибкие методы, покупают ИТ-стартапы и т.д. Но это их не сделает ИТ-компаниями. Почему? Потому что не будут в банках работать люди, которые работают в google или amazon. Это не «их формат». И дело тут не в формальных методах управления разработкой и ведения проектов. Сравните подходы к условиям работы, взаимоотношениям в этих компаниях, способам ведения бизнеса и т.д. В чем разница? Это компании разной культуры, разного «способа жизни». Банк – не ИТ-компания, и никогда ей не будет. (Также как и ИТ-компания никогда не будет банком). Так почему бы банкам… не оставаться банками, исследуя и развивая свои сильные качества? (А они у них, бесспорно, есть, в т.ч. и в ИТ.) Вместо того, чтобы бросаться из крайности – в крайность: то передаем ИТ на аутсорсинг как непрофильную обеспечивающую деятельность, то готовимся к конкуренции с ИТ-компаниями.
И это имеет прямое отношение к вопросу зрелости.
Зрелая компания, какого бы размера, возраста, уровня капитала, географии она не была, к какой бы отрасли она не относилась – знает «себя», видит «свое будущее», понимает свой бизнес, слышит своих сотрудников. И стремится найти и выстроить свой путь развития, а не слепо копирует и примеряет на себя чей-то чужой…
Вспоминая сказку про «Золушку» — как бы ни хотелось выйти замуж за принца, не стоит пытаться отрезать себе пятку, пытаясь влезть в чужую хрустальную туфельку.

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

Архитектурные стандарты и фреймворки

Теперь настало время обратиться к стандартам. И следуя, заветам мудрого Конфуция, дать ясные определения интересующих нас понятий, чтобы «церемония и музыка» процветали, а «сказанное» было исполнено.

По части ИТ-архитектуры существует несколько детально проработанных стандартов.
Прежде всего, это ISO/IEC 42010: 2007, где можно обнаружить следующее определение:

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

А вот определение из известного архитектурного фреймворка TOGAF от OpenGroup:

Архитектура обладает двумя значениями, в зависимости от контекста:
  1. формальное описание системы или детальный план системы на компонентном уровне как руководство к ее реализации;
  2. структура компонентов, их взаимосвязей, принципы и стандарты, которым следует руководствоваться в процессе проектирования и развития системы.

Почему я стала говорить об определениях в контексте фреймворков? Что означает само по себе понятие «фреймворк»?

Фреймворк определяет методологию решения задачи определенного класса. От слова «метод» — повторяемый подход, применение которого приводит к предсказуемым результатам.

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

В фреймворке присутствует два взаимодополняющих и разнонаправленных процесса:

  • генерализация (обобщение опыта) – с одной стороны;
  • адаптация (локализация референсных практик к конкретной ситуации, проблеме, компании) – с другой стороны.

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

Неслучайно требование «адаптивности» все чаще звучит по отношению и ИТ организации. Порой это приводит к неоправданно завышенным ожиданиям – получить возможность решения совершенно разных задач «из одной коробки». Это не всегда оправданно. Есть более эффективный путь – использовать компонентную архитектуру, не перегружая инструменты и технологии несвойственным и избыточным для них функционалом. Такой вариант гораздо прозрачнее и устойчивее в применении. Но он также требует и затрат – уже не достаточно лишь узкого знания некой одной системы – требуется объединить множество систем, интегрировать в единый ИТ-ландшафт.
И роль ИТ-архитектора, его задача – как раз помочь в этом процессе. Он не принимает решений единолично, он собирает и представляет информацию таким образом, чтобы то было понятно многим людям в компании – от бизнеса до инженеров – т.е. подготавливает почву для принятия коллегиального решения. Это не значит, что он не должен обладать технологическими знаниями – как раз наоборот – практика работы с технологиями – один из ключевых аспектов его деятельности. Но как будет показано далее, далеко не единственный.

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

Завершая тему с определениями, приведу еще одно, от компании Oracle, которое, как мне показалось, очень хорошо отражает суть и глубину предмета:

Архитектура – метод и организующий принцип, которые согласуют функциональные задачи и стратегии бизнеса с ИТ-стратегией и планом исполнения.


Кто наш заказчик и какие у него могут быть желания, высказанные и невысказанные

Как и у любого исполнителя, решающего поставленную кем-то задачу, у архитектора есть… правильно – тот, кто ее поставил – т.е. Заказчик! Кто может быть таким заказчиком и как может выглядеть «процесс заказа архитектуры» — зависит от принятых в конкретной организации подходов по организации ИТ-процессов и может стать темой для отдельной дискуссии.
Как бы то ни было, у Заказчика есть, прежде всего, некая потребность, которую ему нужно «закрыть». И у него также могут быть свои идеи и свое «видение» на этот счет, которые ему тоже может быть интересно воплотить.

Например, работая в одном банке, я получила такой заказ – «… а также хотелось бы, чтобы архитектура хранилища была такова, чтобы хранилище исполняло как оперативную, так и аналитическую функцию… короче – нужно хранилище real time!»
Это меня немного озадачило, т.к. это довольно нетипичное и трудновыполнимое требование для систем подобного класса, но как говорится, задача поставлена – надо выполнять. В результате возникла концепция, немного отличавшаяся от первоначальной – не “real time”, а “just-in-time” (идея была заимствована от знаменитого принципа организации производства в компании «Тойота» — «точно во время»). Таким образом, изначальное требование было несколько смягчено и более реалистично с точки зрения технического воплощения, а Заказчик при этом остался удовлетворен тем, как было учтено его изначальное «видение».

Таким образом, какой бы формальной и строгой ни выглядела наша сфера деятельности, нам необходимо знать и даже «чувствовать» Заказчика, его желания и потребности, его опасения и даже некий негативный опыт. И нам нужно уметь представить концепцию решения таким образом, чтобы ему захотелось «купить» данный продукт – т.е. чтобы представленная «картинка будущего» в конце концов (быть может после ряда обсуждений и дискуссий) совпала с его ожиданиями – и ему захотелось двигаться, вкладываться в этом направлении.

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

Заказчик может себе позволить жить сегодняшним днем, всевозможными «квиквинами», увлекаться то одной супер-инновацией, то другой, быть захваченным тенденциями и модными трендами, которые так умело представляют технические маркетологи на всевозможных конференциях и событиях от вендоров ИТ-индустрии.
Архитектор же, оставаясь профессионалом «с холодным носом» должен уметь смотреть на 3, 5, 10 шагов вперед. И более того – уметь переключать взгляд своего клиента в будущее. Пытаясь прийти к совместному пониманию, к совместной картине реальности, к которой хотелось бы прийти в обозримый период, которой хотелось бы следовать и вкладывать усилия по ее воплощению.

Архитектура – это про будущее…

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

ссылка на оригинал статьи https://habrahabr.ru/post/276527/

Записки правдивого архитектора: просто о самом главном (Ч.2)

Архитектура – это про будущее…
— именно на этой мысли мы остановились в конце 1й части статьи. Продолжаем.

Что такое хорошая архитектура?

Хорошая архитектура – та, что соответствует своему назначению, т.е. позволяет решать поставленные перед ней задачи.

Задачи бывают разные. Стандартные и специфичные. Локальные и масштабные.
Но в любом случае, как вряд ли кто-то захочет дом “на один сезон” (хотя такое тоже возможно, но это как раз из разряда “специфичного”, и едва ли для подобного строительства будут прибегать к услугам архитектора) — так и сомнительно, чтобы кто-то хотел получить в итоге систему без перспективы ее развития в будущем.

От правильности построения архитектуры зависит масса полезных характеристик системы, среди которых немаловажная — это показатель срока ее жизни в процессе наращивания функционала, роста объемов данных и нагрузки.
Хорошая архитектура должна обладать свойством устойчивости – т.е. изменение вышеперечисленных параметров не должно приводить к необходимости коренного пересмотра реализации решения.

Это возможно, если при проектировании учитывается набор так называемых нефункциональных требований. Пользователь начинает их замечать только в случае их нарушения — пользователь сосредоточен, прежде всего, на функционале, который ему необходим. Но это не значит, что этот аспект должен уйти из нашего фокуса внимания. Когда эти требования нарушаются, для пользователя зачастую это выглядит просто – система не работает.

Итак, к нефункциональным свойствам относятся:

  • Надежность;
  • Производительность;
  • Модифицируемость;
  • Масштабируемость;
  • Способность к интеграции;
  • Безопасность.

Кроме того, хорошо продуманная архитектура может позволить организовать параллельное развитие системы одновременно несколькими исполнителями, т.к. границы ответственности и точки интеграции компонентов хорошо очерчены и понятны.
И это положительно сказывается на сроках реализации проекта.

Архитектура – это способ борьбы со сложностью
image
Не думаю, что кто-то будет оспаривать факт: ИТ-системы – это, в целом, системы сложные. И вся практика создания ИТ-систем и комплексов идет под флагом борьбы со сложностью.

Позволю себе вспомнить одну давнюю историю замечательных студенческих времен.
Когда наступило время готовить дипломную работу, я попала к очень «правильному» преподавателю, который в обязательном порядке потребовал от меня главу с расчетом надежности моего «программно-аппаратного комплекса», как гордо именовалась мое небольшое приложение для персонального компьютера. Я попыталась возмущаться, потом расстроилась – мне казалось, очень бессмысленно и расточительно тратить драгоценное время на столь формальный вопрос…Но когда я пришла в библиотеку, я узнала для себя массу интересного. В частности, в руки мне попалась великолепная работа Г.Дж.Майерса “Надежность программного обеспечения” (“Software Reliability: Principles and Practices”).

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

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

Соответственно, в индустрии производства ПО появляется множество практик, подходов, инструментов, которые позволяют снизить сложность и управлять ею.
В частности, создание языков высокого уровня, специализированного (инфраструктурного) ПО – СУБД, серверы приложений и т.п. Все это попытки разбить сложный процесс реализации ПО на иерархические уровни, каждый из которых решает задачи своего уровня, а каждый последующий пользуется сервисом предыдущего, “не задумываясь”, как именно он это реализует.

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

Помимо улучшения надежности, мы здесь затрагиваем еще одно важное нефункциональное свойство системы – способность к модификации.
Избегая монолитных конструкций, разделяя систему на составные части — модули, которые понятным образом функционируют и взаимодействуют, мы повышаем возможности вносить изменения в отдельные компоненты, сводя влияние на другие ее части к минимуму. Проще говоря, в будущем в процессе развития системы это позволит не оказаться в ситуации “тут тронешь – там посыплется”.
Архитектура должна поддержать будущий процесс управления изменениями в системе, ограничив влияние компонентов друг на друга и предусмотрев средства выполнения оценки влияния предстоящих изменений.

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

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

Зачем нужны архитекторы? Какова их роль? Что от них можно ожидать и почему?

Теперь от высокого уровня “Enterprise” спустимся “на землю” – т.е. в проекты. И посмотрим на мир архитектора глазами участников проектов по разработке ПО.

Что это за таинственный человек — архитектор?
Код не пишет (может и писать, но реже и не сейчас, когда мы за ним наблюдаем). Сидит себе сперва в углу – мыслит, чертит, придумывает… «Витает в облаках» — думают разработчики. «Ну-ну, посмотрим» — думает начальник.

Да, код не пишет. Часто пишет на бумаге. Или на доске. Один или с кем-то – рисуют, рисуют… Обсуждают. Снова рисуют.
Потом у него вызревает… концепция (или видение (vision) – в зависимости от масштаба задачи).
В концепции реализуется основная идея, прозвучавшая от «заказчика архитектуры» (см. 1ю часть статьи).

Представление концепции (видения)

В итоге, у архитектора появляется набор картинок и краткая презентация, объясняющая суть проблемы, поставленную задачу и подход к ее реализации. Далее начинается процесс представления архитектуры заинтересованным сторонам и согласование – как со стороны «бизнеса», так и со стороны ИТ-специалистов, т.к. вопросы могут быть у всех разные. И они должны быть учтены. Задача этого этапа – достичь равного понимания. Это не так просто, как кажется. И это не всегда удается… И… это нормально. Это часть профессии.

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

Архитектор – это не сколько удачливый “кодер” и изобретательный “кулибин”. Это человек, наделенный ответственностью – за направление, за команду, за систему… От его экспертизы, вдумчивости и умения “заглядывать в будущее” зависит успех работы многих людей.

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

Архитектору надо уверовать в эту цель. Так как именно он отвечает за то, чтобы “отряд” по дороге не слился в неком непонятном направлении – например, решил отправиться в баню, попариться… или огороды кому-то копать… image
Когда целевое видение выбрано, всем понятно и созвучно, то именно на его основе потом осуществляет контроль правильности движения.
Предстоит путь “в 1000 миль”. Шаг за шагом – прежде чем возникнет что-то работающее и осязаемое. И задача архитектора– “не дать свинтить”. Поэтому, помимо технического бэкграунда и умения мыслить стратегически, ему крайне необходимы истинные лидерские качества и то, что сейчас модно назвать soft skills — т.е. способность вести переговоры, работать с людьми, хорошо владеть собой и управлять ситуацией.
Редко кому все эти разнообразные качества даются от природы. Что-то нам дано, а что-то надо воспитывать и выращивать.

Кто ты – идеальная спецификация?

Концепция или Vision — это лишь первый шаг.
Дальше нужно «заглубиться в детали» — проработать отдельные ключевые моменты будущей системы и ее компонентов.
И этот шаг включает в себя проработку несколько моделей разного уровня и назначения – например, модели данных, взаимодействия, бизнес-процессов, переходов состояний и т.п.
Для этого используются специализированные средства, предназначенные для того, или иного аспекта моделирования – так называемые, CASE-технологии. Существуют также проработанные стандарты в этой области – ER-модели, UML-диаграммы, нотации для описания бизнес-процессов (BPMN, EPC) и т.д.

Важным моментом здесь будет являться возможность поддержать непрерывный процесс разработки – из модели должна создаваться некая «рабочая» часть системы – на основе модели данных будет создана структура базы данных, на основе UML-диаграммы классов – заготовки классов и интерфейсов для будущего программного кода. Также со стороны CASE средства важно уметь поддержать обратный процесс – от кода – к модели.

И все-таки это еще не код. Это лишь первые «мосточки» — каркас – от концепции к будущему продукту.

Графическая нотация и модели – это хорошо. Но этого не достаточно. Должно быть некое описание – как с этим работать. Да-да – без текста – никуда. Здесь и появляется такой артефакт как спецификация.

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

Что важно для спецификации?
Прежде всего, соблюсти баланс между:

  • точностью, понятностью / и слишком высокой детальностью;
  • универсальностью / и простотой;
  • полнотой охвата / и реалистичностью по ресурсам.

Важен еще один момент.
Как ни странно, спецификация должна не только ограничивать разработчика, но и оставлять ему некоторую свободу — в области, где именно он принимает решение (и несет за него ответственность). Разумеется, он должен об этом знать.
Для чего это нужно?
Во-первых, трудно предусмотреть и предугадать все заранее. Разработка ПО – довольно сложная область, с бесконечной вариативностью возможных сценариев работы.
Во-вторых, если этого не делать, то это будет лишать “систему” и коллектив, который ее разрабатывает, пространства для саморазвития.

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

Когда компании нужно вкладываться в Архитектуру? И что будет, если этого не делать?

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

Что же произойдет, если не задумываться об архитектуре предприятия?
Ответ прост – либо будут упущены некоторые возможности (упущенная прибыль), либо случатся некие потери (дополнительные затраты).
Поскольку если мы не заглядываем в «картину будущего», не пытаемся его увидеть сегодня – оно настигнет нас «внезапно», но все равно настигнет. Что при этом будет? Может быть, и ничего страшного не произойдет. А может быть, компания немного потеряет от своей конкурентоспособности, а может – случится что-то более серьезное, что поставит под удар ее основной бизнес. Мы не знаем этого заранее.
Но надежда и «рулетка» — весьма ненадежная стратегия развития – как бизнеса, так и ИТ, обеспечивающего бизнес.
Элемент случайности и хаоса, безусловно, будет присутствовать в любом случае. Мы не можем предугадать все. Слишком много есть внешних факторов, влияющих на ситуацию.
Но вопрос – хотим ли мы сделать его управляемым? Хотим ли мы расширить зону нашего влияния, либо положиться «на авось»?

Если хотим, то это уже следующий уровень зрелости – когда есть осознание необходимости построения и управления архитектурой предприятия. В этом случае компания «говорит» себе, что мы готовы «посмотреть в будущее» и сформировать некую картину – на 1-3-5 лет вперед. Разумеется, она будет корректироваться «по ходу пьесы». Но мы должны осознать, какие направления для нас ценны, во что мы готовы вкладываться и почему? Где мы готовы рискнуть? Где может быть наше «вау»? Где нам нужна, прежде всего, стабильность, а в чем мы можем быть немного «сумасшедшими»? В чем мы хотим быть более талантливы, чем другие компании, какие наши реальные шансы? А где нам просто нужны проверенные тиражируемые решения?

Одного осознания мало. «Увидеть» архитектуру, выстроить архитектурные процессы (включая внесения изменений и контроля) не так-то просто. Это нельзя назвать «элементарным» (рутинным) действием. И не исключено, что при неправильных решениях и некорректных подходах мы можем нанести скорее вред, чем пользу — и компания в погоне за красивой, но не реалистичной картинкой может понести лишние затраты.
Здесь в какой-то степени на помощь могут прийти упомянутые ранее архитектурные фреймворки, которые включают себя как стандарты описания архитектур, так и методологию процесса ее развития. Опора на них не исключает, но уменьшает риск неудачи в этом непростом деле.
Ценность применения любого стандарта, любой референсной практики состоит в умении адаптировать. Любая компания уникальна. Не существует двух одинаковых банков, ритейл-компаний, заводов, городских администраций и т.д. Везде есть своя специфика – географическая, человеческая, организационная, технологическая и т.д. Поэтому, попытка «снять кальку» с одной организации – и применить подобную практику к другой, без каких-либо изменений – скорее всего, ни к чему хорошему не приведет. Можно перенять определенный опыт. Но и его надо адаптировать к своей компании.
Построение корпоративной архитектуры – процесс творческий, уникальный – как уникальна каждая компания и люди, которые в ней работают.
Кроме того, на архитектурные процессы влияют особенности корпоративной культуры компании – особенно модель принятия решений, способы коммуникации, информационная открытость и т.д.

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

ссылка на оригинал статьи https://habrahabr.ru/post/276613/

Rocker Gestures и другие новинки в еженедельной сборке Vivaldi 1.0.390.3

Всем привет!

На этой неделе почти вся команда разработчиков собралась в исландском офисе, чтобы ускорить исправление ошибок и недочётов в браузере Vivaldi, а также поработать совместно над новыми функциями. Сегодняшняя сборка включает часть того, что мы уже успели сделать за прошедшие дни. Полный список изменений, включая исправленные баги, вы найдёте в конце статьи, а сейчас о том, что появилось нового.

Жесты мышью

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

Ещё одна опция относится к числу давно ожидаемых пользователями — мы пока назвали эту функцию Rocker Gestures. Суть функции проста: быстро нажимая последовательно левую и правую кнопки мыши (или в обратном порядке) вы можете перемещаться в истории просмотра как назад, так и вперёд. Функция неактивна по умолчанию, включить её можно там же, в Инструменты->Настройки->Мышь->Rocker Gestures.

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

На этом всё. Загрузить новую сборку можно по ссылкам ниже:

Полный список изменений:

  • VB-9363 An option to control Alt key mouse gestures: disable by default
    VB-12762 [Mac] Upgrade menu bar code. Stage 3: Introduces favicons for the tab listing in the Window menu + highlight of the active tab.
    VB-9429 Background tab progress indicator does not work
    VB-12765 Empty section in address bar’s context menu
    VB-12738 Reload button is stuck in wrong state
    VB-9028 Chromecast addon popup appears blank: this also fixes may other issues with extension popups
    VB-12700 Simplify / clean up fill and color use
    VB-12387 Zoom indicator is black on black
    VB-12694 Tab and addressbar borders inconsistent
    VB-12348 Crash using drop-down list in the options of extension ImprovedTube
    VB-12466 [Windows] [Linux] Cannot see the window controls on dark pages with color area behind tabs
    VB-12687 Quick commands are not executed on click
    VB-12690 Bookmark folder disappear a few seconds after creating it,
    VB-12625 Typed fragment identifiers are stripped from current URL
    VB-12682 [Mac] Upgrade menu bar code. Stage 2: Introduces list of open tabs in the window menu
    VB-12541 Focused tab is marked unseen after restart.
    VB-12595 Regression: URL field shows different URLs while loading
    VB-12487 [Regression] Broken bookmarks shortcuts in Quick Command
    VB-10852 Add option to disable rocker gestures
    VB-12627 Add Help pages to main menus: this is work in progress, it just redirects to vivaldi.com for now
    VB-11215 When deleting characters in the address field focus moves to the end of the line
    Prevent clearing urlfield state while new tab is loading
    URL autcompletion score tweaked slightly: should improve results

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

ссылка на оригинал статьи https://habrahabr.ru/post/276893/