Ключевые выгоды

1. БЫСТРОЕ ОСВОЕНИЕ КОДА

Любой новый человек потратит на 20–30 % (а может и больше) времени меньше на погружение в код чем в код, который написан без конвенций.

2. ПОВЫШЕНИЕ КАЧЕСТВА И СНИЖЕНИЯ КОЛ-ВА ОШИБОК

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

3. ПОВЫШЕНИЕ СКОРОСТИ РАЗРАБОТКИ

Если вы уберете необходимость у разработчика придумывать, как же оформить и структурировать программный код, то он сфокусируется уже на алгоритме, а не на оформлении и скорость самой разработки у вас вырастет. По моим оценкам где – то на 15–20%


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

Встроенное программное обеспечение (Embedded Software)

Не все программы стоят отдельно от датчиков и устройств. Многие программы устанавливаются сразу в микросхему устройства и становятся неотделимым целым от девайса, т. е. встроенным (embedded). Основное отличие от обычных программы, к которым мы привыкли их называют application software заключается в том, что:

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

2. ES созданы, чтобы выполнять конкретную задачу.

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

4. ES часто работает без операционной системы и других приложений

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


ES приложение часто представляет собой Embedded computer

Часть 6. Карта технологий

Любую компанию можно представить в виде операционной модели, в которой есть набор функций, которые выполняются внутри этой компании. Например “Работа с клиентами”, “Бухгалтерия” и т.д. В этой операционной модели есть 3 уровня или слоя, как в пироге, это:

1. Фронт офис (от англ. “front”, т. е. спереди), там, где вы работаете с клиентами. Тут будут все функции и процедуры, которые касаются клиентов.

2. Миддл офис (от англ. “middle” – по середине), здесь находятся все процессы, функции, которые связаны с сопровождением клиентов, расчетом комиссий, оценки рисков.

3. Бек офис (от англ. “back” – сзади), здесь уже находятся все процессы, которые чаще не связаны с клиентами напрямую, например бухгалтерия, расчеты, переводы, открытие счетов, ведение складской деятельности, производство и т. д.


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



В проектировании, эти кубики называются Use Case (или сценарии использования технологии), в Agile, они носят название User Story (пользовательские истории) и т.д. Сам термин Use Case возник в языке UML (Unified Modeling Language – унифицированный язык проектирования). Этот открытый язык появился в период с 1984 по 1995 год, и стал активно использоваться в качестве, лучших практик моделирования и создания технологии. Любая технология решает определенные Use Case. Не больше, ни меньше. Я буду часто к этой аксиоме возвращаться, чтобы вы это запомнили. Нет универсальной технологии, каждая решает конкретные задачи. Если в вашей компании, технология не работает, а в другой компании работает, а это точно так, иначе бы технология не существовала, то видимо вы ее неправильно используете. В части кейсов, в мире появилось большое количество функциональных систем, которые заточены делать конкретную функцию, например управлять процессами (системы типа BPM) или управлять рисками внутри организации, например кредитными или операционными (такое семейство технологии можно назвать Risktech). Как вы заметили, название того или иного семейства технологий складывается из 2х слов, это “названия предметной области” + “tech”, краткого от англ. technology (технология). Часть таких акронимов вы, наверное, не слышали, например API Tech (технологии для управления интеграцией), а другие возможно слышали HR Tech (технологии в управлении персоналом – HR). Я специально все типы технологий привожу к единому знаменателю, чтобы вам было проще ориентироваться в них. Задача этой книги, не помочь вам выучить, все эти технологии, а помочь вам ориентироваться во всем этом множестве. Все эти названия, они не конечные, их можно дробить на подклассы, придумывать новые названия. Но в целом, это некий такой нулевой уровень, на мой взгляд с которого все начинается, и который является общим для 99 % компаний. Если не верите, можете взять свою компанию и попробовать составить для нее b-map.