Текст книги "Digital Book. Книга вторая"

Автор книги: Вячеслав Благирев

сообщить о нарушении

Текущая страница: 3 (всего у книги 4 страниц)

Правила разработки (Code Convention)

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

begin

a: integer;

end

Часто многие языки начинаются вот с похожих конструкций begin end, которые означают начало и конец выполнения программы. a: integer означает, что параметр a будет иметь тип integer, этот тип во многих языках означает “целое положительное число”. Вообще задумайтесь, как много общего во многих языках программирования, как и в обычных языках. Так, например тип integer или int практически во всех есть. Он обусловлен не тем, что одни и те же люди создавали языки, а тем что такой тип “органически необходим всем”. То есть он как золотое сечение, который всегда будет, потому что алгоритмы на этой планете требуют этот тип для работы. Есть, например другой тип float. Это тоже числовой тип, но с плавающей точкой, т. е. это дробное число. Ну так вот вернемся к “а”. Вам понятно, что “a”, это age или возраст? Конечно нет. А если вы например передадите вашу программу другому программисту исследователю, то поймет ли он что такое a? нуу… если вы ему не скажете, или не дадите инструкцию или не укажите комментарий прямо в коде, то точно нет. Получается сторонам нужен некий свод правил, чтобы можно было передавать друг другу информацию описанную в виде программного кода. Ну и обеспечить преемственность для будущих поколений. Я немного пишу тут как археолог и историк, но так оно и есть. Чтобы ваш код прошел через поколения, должны быть правила его прочтения. Наша современная письменность прошла через поколения, потому что был алфавит, орфография, грамматика и фонетика, которые кто-то придумал. Это все некие правила. Они и называются Code Conventions (Код конвешионс). Если провести параллель, между алфавитом и обычными языками, то фактически это алфавит и правила его использования – орфография и грамматика. Вы тут сейчас такие, наверное, скажете, “воу воу полегче парень! Ведь в языке программирования, это вроде все есть”. Не совсем так. Этого там нет, машине можно скормить все что угодно, она понимает только 0 и 1 и поэтому живет в бинарном измерении, а мы другом измерении. Даже если в языке есть минимальный набор правил написания кода, который называется синтаксис, то нужно помнить. что задача синтаксиса совершенно другая чем обеспечить преемственность программного кода. Задача синтаксиса всего ли обеспечить конвертацию вашего программного кода в машинный язык.

За свою практику я столкнулся с интересным фактом в отношении code conventions (для простоты я буду называть их Правилами). Так вот не в каждой развитой с точки зрения ИТ организации были Правила. Если эти наблюдения, как – то обобщить, то можно сказать, что Правила мне встречались где-то в среднем в 20–30 % внутри организации и в 1 из 5 организаций в целом. При этом среди эти организаций были большие ИТ бюджеты, солидные ИТ руководители, но не было сформировано ИТ культуры и никакого намека на Правила. Это странно. Иногда мне приходилось лоббировать или требовать создания Правил в том числе и со стороны Заказчика. Обычно слышишь много клевых аргументов, почему разработчики не хотят делать программный код по Правилам, они ведь художники:). Самые классные это – “Это первый и последний раз!”, “Мне срочно нужно вывести доработку на бой иначе все сломается”, “я один кто поддерживает эту систему и мне все понятно. не вижу смысла”, ну или “это все для хипстеров. Бессмысленная трата времени”. Но Правила, это основа ИТ культуры, иначе вы будете в заложниках у вашего разработчика, а еще его знание просто потеряются с годами, и никто не сможет понять, а как же проходит те или иные вычисления. Есть программы, в которых тысячи строчек года, если все строки кода будут одинаковыми, все переменные будут просто называться – a, b, c, d и тд, то такой код невозможно будет расшифровать или потребуется очень много. Например, взять шумерские таблички им почти 5000 лет. Вот табличка с письмом царю Лагашу:

Вы что-нибудь понимаете?:). Ну вряд ли. Дешифровка этого языка идет уже почти 200 лет с переменным успехом. В ИТ такая организация программного кода называется “спагетти-код”. Его так называют, потому что он весь извилистый и непонятный.

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

Сами Правила должны быть для каждого языка и для каждой системы свои. Вам не удастся создать общие для всех Правила, ну и это бессмысленно. Сами Правила можно разделить на 2 типа:

1. Code Standards – правила построения алгоритмов и использования переменных и тд):

○ длина идентификаторов и переменных

○ какие имена можно назначать переменным – используют только смыслово значимые переменные, например Age вместо a73fsfBd для хранения возраста

○ регистра букв и цифры – например некоторые языки чувствительные к регистрам, т. е. переменные Age и AGE будут восприняты, как разные.

○ правила использования спец. символом – тут они тоже есть, это всякие /? и другие

○ слова, разделенные буквами, – AgeOfEmpires итд

○ правила формирования типов переменных – каким значениям можно присвоить логические типы, а каким числовые. Например, когда присваивать логический тип boolean, а когда числовой

○ когда переменная должна быть глобальной и доступа другим модулям и библиотекам

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

○ наличие комментариев и аннотаций

○ какие внешние библиотеки являются общими и обязательными

○ согласованность в коде и приложениях

○ обработка исключений и ошибок

○ принципы объявления переменных (не объявляйте переменные, если не используете, не забывайте закрывать переменные)

2. Code Style – это непосредственно правила написания кода, т. е. стиль. Если проще сказать, то это правило, когда вы ставите в коде кавычки и когда их закрываете. Это называется конструкция. Например, размер отступа или структура кода. Еще в школе и университете меня учили, что у кода должна быть структура. Самой машине все равно, как его читать, а вот человеку нет. Различают основные стили программирования, еще их называют стили “отступов”, потому что для того, чтобы их соблюдать надо делать отступ в коде слева:

• Стиль Керниган и Ричи

Назван в честь Брайна Кернигана и Дениса Ричи, которые написали 100500 книг по программированию СИ. А Денис Ричи был его создателем. Фишка стиля в том, что практически все примеры в книжках были оформлены соответствующим образом, так что это стало мейнстримом

if () {

      

}

•  Стиль Олмана

В честь Эрика Олмана. очень крутой дядька из университета Беркли, участвовал в развитии и становлении систем Беркли (BSD систем). Это unix системы. Сейчас 90 % серверов работают на таких системах. Сейчас существует очень много разных UNIX систем.

if ()

{

      

}

•  Стиль Уайтсмитс

Whitesmiths Limited была такая компания в 1980х годах, которая занималась разработкой. С языка

if ()

      {

      

      }

• Стиль GNU

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

if ()

   {

      

   }

•  стиль TODO

Этот стиль появился в Java. Он связан с тем, что в коде вы пишите себе заметки, что нужно сделать с кодом в будущем. например:

// TODO: Remove this code after the UrlTable2 has been checked in.

// TODO: Change this to use a flag instead of a constant.

Один из самых ранних стандартов описания кода является “венгерская нотация”. Придумал ее Чарьз Симони аж в 1999, когда работал в компании Microsoft. Одним из его проектов был проект Word, да тот самый:). Он создал один из первых в мире WYSIWYG процессоров. У Симони каждая переменная кодировалась особым образом, если быть точке префикс переменной создавался по особым правилам.

WYSIWYG процессор – это инструменты для редактирования текста, которые широко используются в редактировании и веб приложениях. Например, эта книга написана в google docs, который является WYSIWYG редактором. Само слово появилось от аббревиатуры What You See Is What You Get, «что видишь, то и получишь. Вообще это сейчас любой онлайн редактор. Поэтому, если вам нужно на сайт прикрутить такой редактор или в приложение, вы тут же понимаете, что вам нужен просто визивиг редактор

https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/

Самое интересное, что нотация в конце концов была интерпретирована большинством программистов неправильно и когда появилась новая платформа для программирования у Microsoft,NET, то Microsoft начали говорить, что лучше не использовать венгерскую нотацию. В целом, если вам интересно почитать что такое хорошая и плохая нотация, то есть достаточно клевая статья Making Wrong Code Look Wrong (как сделать неправильный код выглядеть неправильным)

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

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.

Давайте попробуем разобрать, этот разноцветный ковер.

Process Tech

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

1. Технологии, которые позволяют управлять процессом (ВРМ)

2. Технологии, которые позволяют автоматизировать простое действие в процессе (роботизация)

3. Технологии, которые изучают эффективность процесса (Processes Mining)

BPM

ВРМ (бипиэм читается:), появились на пороге прошлого столетия. Не система, конечно, а предпосылки. к тому, что любая организация – это прежде всего набор процессов. Хотя вы не поверите, но до сих пор есть люди, которые в это не верят, ну не будем их расстраивать:). 100 лет назад, компании были очень неповоротливыми, никто толком не изучал и не пытался их систематизировать. Первым человеком, кто это попробовал сделать, был Фредрик Тейлор, не путать с Бруком Тейлором, математиком, и основоположником теоремы Тейлора, который жил лет на 250 раньше. Ф. У. Тейлор был замечательным инженером и придумал систематизацию труда. Фактически он утверждал, что любой труд может быть систематизирован и проанализирован, из-за чего Тейлор подвергался нападкам и компании всеобщего презрения. Профсоюзы не любили его за то, что он раскрывал секреты их мастерства и рассказывал из чего же строится процесс на работе, а капиталисты не любили за то, что он считал, что оптимизация процессов должна приносить доход рабочим, а не владельцам компаний. В общем все его называли “смутьяном”, представляете. Сейчас, спустя 100 лет, смутьяном назовут того, человека, кто захочет противиться систематизации процессов. Вот все неоднозначно. Угадайте, кто был первым применил практики и теорию Тейлора на практике? Это был Генри Форд. Сейчас конвейер Генри Форда, считается эталоном в области построения конвейерного производства, а 100 лет назад, его тоже считали сумасшедшим. Тейлор написал, интересный труд, под названием “Принципы научного менеджмента”, где описал, что одна из основных целей внедрения эффективной организации труда в компании, это рост доходов, как самого предпринимателя, так и работников. Т. е. технология позволяет зарабатывать 2м классам, 1) предпринимателю, 2) рабочему классу, в частности рост их благосостояния (well-being, так звучит благосостоянии на англ. языке). Это очень интересный термин, что означает благосостояние сейчас? Фактически это символ процветания соответствующей социальной группы. Тейлор считал, неправильным потребность предпринимателя получить максимальную прибыль со своих рабочих, за счет максимизации их труда. Что такое благосостояние для предпринимателя? Это получить максимальную прибыль. А для рабочего, это получить максимальную производительность без доп. затрат. Как вы, наверное, догадались, это можно достичь, лишь только тогда, когда работа осуществляется с минимальными затратами для обеих сторон. А значит, тут самое место для автоматизации. “Автоматом” называли в Древней Греции самодействующие механизмы, которые не требовали участия человека. Вернемся к Тейлору, помимо, наверное, очевидных выводов, он затрагивает интересный момент, который у него называется “недовыработка” или работа “с прохладой”, отсюда пошло слово “прохлаждаться”. Он говорит, что одни и те же люди играя в бейсбол могут показывать высочайшие результаты и будут стремится выиграть, но приходя на работу их работа не будет содержать той самой мотивации. Исключая вот такую вот “медленную” или “неинтересную” работу, он считал, что можно в 2 раза повысить производительность труда, количество выпускаемой продукции и т.д. Причины, по его мнению, которые способствуют распространению такой вот “прохладной” работы, является:

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

2. Ошибочная организация управления компанией, которая, наоборот, позволяет работать прохладно (никаких таймеров, счетчиков и тд, нет)

3. Распространение непроизводительных и грубых методов. Т. е. если ваши рабочие работают “лопатой и мотыгой”, то бессмысленно от них ждать каких-то сверх результатов.