Анализ и проектирование систем *

«Только со смертью догмы начинается наука.»
// Галилео Галилей

«Я начал завидовать рабам. Они всё знают заранее. У них твёрдые убеждения.»
// х/ф Марка Захарова «Убить дракона» по мотивам пьесы Евгения Шварца

Уже пару лет и дня не проходит, чтобы я не услышал (или не прочитал) от людей, начинающих новые проекты, фразу типа «Возьмем серверный движок для REST API и MVC, и погнали». Сначала я думал, что у этих слов есть один источник, может книжку какую завезли во все магазины или где-то в топе поисковиков лежит статья, зомбирующая разработчиков. Если же выяснять у них, что они понимают под REST и MVC, то можно повредиться умом. Ну с MVC уже все ясно, об этом я уже давно писал, ничего не изменилось, только усугубилось, стоит набрать в Google Images «mvc» и мы увидим страшное, стрелочки в любые стороны. Ну а про REST отвечают следующее: ну как же, нам нужно из браузерного GUI и мобильного приложения вызывать серверные методы, например: setUserCity(userId, cityId) или calculateMatrix(data) или startVideoConverter(options, source, destination) а потом мы столкнемся с большой нагрузкой и архитектура REST все решит. Дальше я задаю вопросы, от которых глаза округляются уже у тех, кто недавно еще горел праведной верой, рвался в бой и точно знал, что к чему в этом мире. Теперь можно перейти к рассмотрению терминологической катастрофы, в эпицентре которой мы с вами пребываем.

Короткая предыстория

Беседовал я некоторое время назад со знакомым роботом. Устроился он временно на Почту России сортировщиком писем. Работёнка не пыльная, смотрит индекс на письме и помещает их в нужное отверстие. Но есть проблема с письмами, у которых в индексе сделана опечатка. На выяснение правильного индекса уходит много времени и пиво успевает выдыхаться.

Заноза в голове

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

Оказывается улучшить можно.
Попробуем нарисовать новый вид цифры 0.
Если интересно, зачем и почему — прошу под кат.

Разработка, Направленная на Создание Мусора

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

Главным продуктом РНСМ являются бессмысленности, написанные по столь «ценным» идеям: концепты, графики, описания дизайна и прочие продукты, создаваемые для одной лишь цели — быть выброшенными в корзину.

Это работает так:

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

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

Нет-нет, статья не про план резервного копирования. Статья про план «Б».
Поддавшись массовой истерии, решил я перейти в НПФ. (Нет! Статья не про НПФ!)
Почитал обзоры и рейтинги, выяснил, что разные источники без зазрения совести публикуют разную доходность по одним и тем же НПФ (опять отвлекаюсь)… и решил перевести в ХХХ24 (нет смысла обсуждать).

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

Нет, это не реакция капризного ребенка. Да, системы, бывает, глючат. Но как себя ведет этой ситуации банк и НПФ? А никак. Они ничего не делают. У них нет плана «Б».
Как раз в те дни, когда всплеск активности переводов в НПФ.
А ведь это не мгновенные переводы, тут система вообще не нужна. Им достаточно принять от меня заявление с подписью, с правильно заполненными реквизитами, с бесполезной ксерокопией паспорта и СНИЛС-а, чтобы потом отослать его в пенсионный фонд и завести в систему.
То есть, где-то в банке сидит большой человек, ответственный за НПФ, получающий бонусы за его успешность, но ему пофигу, что клиенты несколько дней не могут написать заявления.
А ведь мог бы построить всех, разослать хоть по электронке, хоть курьером инструкции по приему заявлений в бумажном виде, отправил бы бланки для заполнения и процедуру, как их потом вводить при восстановлении работоспособности. Понятно, не сам, через подчиненных. Но он не делает этого.
Могу я быть уверенным, что когда нужно будет быстро отреагировать на изменения на рынке и перевести мои инвестиции из одних финансовых инструментов в другие, этот банк сможет быть эффективным?
Нет. Я не уверен.

Введение

В один прекрасный день я получил по почте извещение о долге за горячую воду, по причине несвоевременного оповещения коммунальных служб о показаниях водомеров. К этому моменту я, праздного любопытства ради, осваивал WiFi радиомодуль от “Roving Networks” с целью «обучить» его дистанционно включать/отключать электрический водонагреватель для экономии электроэнергии при долгом отсутствии пользователей. И так все сошлось, что решил я свести эти задачи и еще некоторые задумки «умного дома» к практической реализации. Ну и конечно, было бы не интересно, если бы я использовал знакомые мне технологии, поэтому я решил использовать как можно больше нового и интересного.

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

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

Сеть полна предупреждений и предостерегающих повествований об использовании подобного подхода. Есть ужасающие истории о потере данных, исчерпании памяти или людях неспособных эффективно управлять данными в Redis, вы, возможно, интересуетесь «О чём вы вообще думаете?». Так вот, наш рассказ, почему мы всё же решили использовать Redis и как мы преодолели все эти проблемы.

Статьи о разработке продуктов в сфере электроники — это большая редкость на Хабре. Я говорю не о любительских проектах или прототипах, а об успешных коммерческих устройствах для массового рынка.

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

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

Многие читатели Хабра знакомы с внутренней кухней разработки ПО, а ведь железо — это совсем другая история. Готовы? Тогда поехали.

Все чаще и чаще я слышу от разработчиков и читаю в статьях, что шаблоны проектирования (они же дизайн-паттерны) никому не нужны. Мол, они появились во времена «цветения» UML, RUP, CASE систем и прочих чересчур «сложных» инструментов, подходов и практик. А сейчас самое важное — это код рабочий написать, да побыстрее. На умные толстые книжки ни у кого нет времени, разве что для прохождения собеседования. Тех, кто хочет обсудить данную тему, прошу под кат.

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

Введение

В 2009–2011 гг. я вёл проект системы управления знаниями (СУЗ) для одной довольно крупной компании. Собственно, этот проект сам по себе является поводом если не цикла статей, то уж двух-трёх точно. Именно в ходе реализации этого проекта я в полный рост столкнулся с одной огромной проблемой — мифологизации информационных технологий. Самое страшное то, что ей подвержены вроде бы взрослые люди, и даже временами выходцы из этой отрасли.

Эрик Липперт — ветеран Microsoft, проработавший в компании 16 лет и стоящий за разработкой VBScript, JScript и C#.

На прошлой неделе в комментариях к одной из статей разгорелся спор о роли низкоуровневой оптимизации в программировании, и я вспомнил относящуюся к этому статью Эрика. Она была написана в конце 2003, и хотя реалии с тех пор несколько изменились — принципы остались теми же самыми. Можете мысленно заменить ASP и VBScript на PHP, JavaScript, или на другой скриптовый язык по вашему вкусу.

Эту статью я уже пытался перевести в 2005, но русский текст тогда получился неуклюжий, так что этот перевод — новый и ранее не публиковался, в соответствии с требованиями НЛО. В Переводе блога Эрика Липперта этого текста тоже нет — наверное, для них он слишком стар.

---

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

Например, за семь лет в Microsoft я получил десятки вопросов, аналогичных по своей сути этому, заданному в конце 1990-х:

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

Какой интересный вопрос! В компилируемом языке, таком как Си, объявление локальных переменных общим размером n байт всего лишь вычитает n из указателя стека при входе в функцию. Если n будет чуть больше или чуть меньше, затраты времени на вычитание никак не изменятся. Наверное, в VBScript точно так же? Оказалось, что нет! Вот что я написал автору вопроса:

Я рад приветствовать вас, дорогие читатели.

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

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

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

«Мы работаем для того, чтобы вы не боялись летать»


рис 1. Модель Bombardier BD 500 в аэродинамической трубе

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

Автор рассказывает о перипетиях пивоваров, производителей СУБД, себя и кратко о том как правильно проектировать приложения. Мне показалась полезной поучительная часть статьи.

В основе разработки ПО авионики лежит основополагающий стандарт RTCA\DO-178B. Несмотря на первый взгляд на его отстранённость от непосредственной рутины программиста, он описывает весь процесс разработки и выдвигает требования к подобному ПО. Тем не менее, в данной статье речь пойдёт и о том, как всё происходит на самом деле, на основе личного опыта разработки систем контроля и управления полётом, систем посадки и пр. для самолётов и вертолётов.

Бродил я тут по сайту университета Беркли и набрёл на вот такое меню (которому уже невесть сколько лет). Да, в Беркли всегда знали, что на самом деле нужно для развития IT-индустрии.

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

В прошлый раз в статье "АСУДД: Что висит над дорогой?" мы бегло прошлись по «железу», которое устанавливается на транспортных магистралях: по типам детекторов транспортного потока, светодиодным табло и дорожным контроллерам.

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

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