Рубрика «проектирование систем» - 2

Вот цитата из Линуса Торвальдса за 2006 год:

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

Что очень похоже на «правило представления» Эрика Реймонда от 2003 года:

Сверните знания в данные, чтобы логика программы стала глупой и надёжной.

Здесь просто резюме идей, подобных мысли Роба Пайка от 1989 года:

Доминируют данные. Если вы выбрали правильные структуры данных и всё хорошо организовали, то алгоритмы почти всегда будут самоочевидными. Структуры данных, а не алгоритмы, играют центральную роль в программировании.

Читать полностью »

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

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

Дисклеймер

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

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

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

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

Читать полностью »

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


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

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

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

Читать полностью »

Введение

В рамках предыдущих статей мы описали: область применения, методологические основы, пример архитектуры и структуры. В данной статье, я хотел бы рассказать как описывать процессы, о принципах сбора требований, чем отличаются бизнес требования от функциональных, как перейти от требований — к коду. Рассказать о принципах применения Вариантов Использования (Use Case) и как они нам могут помочь. Разобрать на примерах варианты реализации шаблонов проектирования Interactor и Service Layer.

likeyourgrandmom

Примеры приведенные в статье даны с использованием нашего решения LunaPark, оно поможет вам с первыми шагами в описанных подходах.

Отделяем функциональные требования от бизнес требований.

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

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

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

Читать полностью »

Примечание: Если вы считаете, что на построении архитектуры съели хотя бы полпёсика, то эта статья не для вас.

Модель — абстрактное представление реальности в какой-либо форме.

Предполагаем, что архитектор уже закончил со сбором требований к будущей системе и их анализом.

Разработку архитектуры нужно начинать только с понятия и принятия фундаментальной концепции работы с информацией (данными): передача, хранение и обработка. Притом формы ввода/выводы информации, схемы обработки, абстрактные структуры массивов и элементов данных сами по себе тоже являются информацией (как и всё приложение) и подчиняются той же фундаментальной концепции.Читать полностью »

Дизайн классов: что такое хорошо? - 1

Автор: Денис Цыплаков, Solution Architect, DataArt

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

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

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

WG Contract API: zoo of services - 1

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

Если хотите познакомиться поближе с тем как команда Wargaming Platform справляется со сложностью системы из более чем сотни взаимодействующих друг с другом web-сервисов, то добро пожаловать под кат.
Читать полностью »

Введение

Итак, мы уже определились с областью применения, методологией и архитектурой. Перейдем от теории к практике, к написанию кода. Хотелось бы начать с шаблонов проектирования, которые описывают бизнес логику — Service и Interactor. Но прежде чем приступить к ним, изучим структурные паттерны — ValueObject и Entity. Разрабатывать мы будем на языке ruby. В дальнейших статьях разберем все паттерны, необходимые для разработки с использованием Вариативной архитектуры. Все наработки, являющиеся приложениями к данному циклу статей, соберем в отдельный фреймворк.

Blacjack & hockers

И мы уже подобрали подходящее название — LunaPark.
Текущие наработки выложенны на Github.
Разобрав все шаблоны, соберем один полноценный микросервис.

Читать полностью »

Введение

В рамках предыдущих статей мы выделили область применения подхода и рассмотрели основные методологические принципы Domain Driven Design.

В данной статье я хотел бы обозначить основные современные подходы к построению архитектуры корпоративных систем: Supple, Screaming, Clean и дать им свою четкую интерпретацию в виде полноценного готового решения.

WM

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

Читать полностью »

Список статей и литературы про NAS - 1

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

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

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js