Вячеслав Благирев – Digital Book. Книга вторая (страница 6)
За свою практику я столкнулся с интересным фактом в отношении 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 (<cond>) {
<body>
}
• Стиль Олмана
В честь Эрика Олмана. очень крутой дядька из университета Беркли, участвовал в развитии и становлении систем Беркли (BSD систем). Это unix системы. Сейчас 90 % серверов работают на таких системах. Сейчас существует очень много разных UNIX систем.
if (<cond>)
{
<body>
}
• Стиль Уайтсмитс
Whitesmiths Limited была такая компания в 1980х годах, которая занималась разработкой. С языка
if (<cond>)
{
<body>
}
• Стиль GNU
GNU это одна из UNIX операционных систем, которая стала дико популярной, особенно из-за того, что придумала способ быстрого онлайн обновления через дистрибутив debian. Вообще про UNIX можно будет долго говорить.
if (<cond>)
{
<body>
}
• стиль TODO
Этот стиль появился в Java. Он связан с тем, что в коде вы пишите себе заметки, что нужно сделать с кодом в будущем. например:
Один из самых ранних стандартов описания кода является “венгерская нотация”. Придумал ее Чарьз Симони аж в 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 % (а может и больше) времени меньше на погружение в код чем в код, который написан без конвенций.