Connect with us

Разработка

Григорий Петров: Стандарт оформления кода: и не стандарт, и не оформления, и не только кода

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

Григорий Петров

Опубликовано

/

     
     

Во многих компаниях первый рабочий день программиста начинается с изучения “стандарта оформления кода”, он же “стандарт кодирования”, “coding standard” или “coding convention”. Обычно это монструозный многостраничный документ, в котором подробно описано, как именно принято писать код в компании. Очень подробно.

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

Зачем нужна эта штука

Как я уже писал, над программистами довлеет страшный Кошелек Миллера. Чтобы бороться со сложностью, разработчики тренируют навыки работы с “типовым” кодом. Почти так же, как шахматисты постоянно разыгрывают этюды, чтобы не тратить внимание на их распознавание. Только вместо шахматных позиций разработчики тренируются писать код в определенном стиле, с выбранным набором готовых библиотек и фреймворков. Читая в дальнейшем такой код, они не тратят внимание на известные фрагменты и могут, как шахматисты, фокусироваться на более важных вещах.

shvedskie_shahmatu

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

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

Кнут, пряник и учебник под одной обложкой

Стандарты кодирования возникли естественным образом, практика прижилась, доказала свою пользу и теперь используется намного шире, чем просто внутреннее соглашение по оформлению кода. Эти документы является замечательным “внутренним учебником” для введения новых разработчиков в курс дел. Информация в таком документе накапливается постепенно, дополняясь и меняясь вместе с тем, как эволюционирует разработка в компании.

scheme_lisp_SICP_Japan_edition

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

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

Советы по созданию стандарта кодирования

Каждый разработчик хочет переписать все с нуля, и это естественно. Хороший стандарт кодирования всегда начинается со вступления, где вы рассказываете про сложность, про борьбу с ней, и о том, чем полезен стандарт кодирования. Если этого не сделать, то есть риск быть непонятным, и новый разработчик отнесется к вашим знаниям как к “блажи потерявшего связь с реальностью тим лида”. Будет очень обидно, да?

Интегрируйте стандарт кодирования в “onboarding” новых разработчиков. Внимательно относитесь к их вопросам, так как они смотрят на ваш стандарт свежим, “незамыленным” взглядом. Каждый новый разработчик, читающий ваш стандарт кодирования – это возможность что-то улучшить, переписать более понятным языком, внести ответы на часто задаваемые вопросы.

Разбейте стандарт кодирования на обязательные для исполнения правила; рекомендованные, но не обязательные; и просто рекомендованные. Слишком большой объем обязательных для исполнения правил в клочья разрывает кошелек Миллера новым разработчикам, понижает им удовольствие от работы и способствует возникновению напряженности в команде. Обратная сторона медали – если все правила будут только “рекомендациями”, то многие разработчики будут игнорировать их из-за лени. Постарайтесь подобрать баланс между обязательными и необязательными правилами так, чтобы оставить разработчикам свободу творчества, но при этом дать им возможность понимать код друг друга и не изобретать слишком много велосипедов.

Составление и поддерживание стандарта кодирования – задача тим лида. Наблюдая каждый день за работой команды, и читая написанный разработчиками код, он лучше всех видит возможности направить разработку в общее русло. При этом тим лиду не следует пытаться вынести в стандарт кодирования весь свой опыт. В чужие головы свои мозги не вставить, а слишком сложные вещи будут просто непонятны большинству разработчиков со средним опытом и навыками. Лучше всего выделить “ядро” простых правил и подкрепить их автоматикой в виде статического анализа. В такой ситуации разработчик, отгрузивший “не по правилам” написанный код получит автоматический ответ от системы непрерывной интеграции. А героем, сломавшим билд, никто быть не хочет.

Напоследок скажу традиционное. Стандарт кодирования, как и многие другие описанные мною практики – это всего лишь инструмент для решения определенных задач. Только понимание этих задач, а также сильных и слабых сторон используемых инструментов, поможет вам сделать процесс разработки чуть более стабильным и предсказуемым. А там, глядишь, и релизы начнут вовремя случаться.

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Новости

Интересные материалы: 23.01

Сегодня у нас мобильные облака, карьера разработчика Xamarin и новые библиотеки.

Леонид Боголюбов

Опубликовано

/

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

Комментарии
Продолжить чтение

Медиа

Podlodka #43: Профессия – архитектор

Продолжаем разбираться, что ждет разработчика после достижения сеньорности.

AppTractor

Опубликовано

/

Автор:

Podlodka

Переход в менеджмент мы уже обсудили, и в этот раз на очереди другой популярный вариант – карьера архитектора. Сергей Орлов, архитектор из Avito, помогает нам вникнуть в суть этой роли, определить её область ответственности и требуемый багаж знаний.

Комментарии
Продолжить чтение

Дизайн и прототипирование

Создание шрифта с нуля за 24 часа

Графический дизайнер Джеймс Барнард бросил себе вызов – он захотел за 24 часа создать шрифт и отправить его в Google Fonts. Как он это сделал и что узнал в процессе — в нашем переводе статьи Джеймса.

Анна Гуляева

Опубликовано

/

Я большой фанат One Day Builds Адама Сэвиджа. В начале дня у него есть только материалы, а в конце он становится обладателем чего-то, что он хотел.

Поэтому я бросил себе вызов: создать с нуля абсолютно новый шрифт и отправить его в Google Fonts за 24 часа.

В старом блокноте у меня были эскизы нескольких букв. Я хотел создать узкий шрифт без засечек, который можно будет использовать на постерах или на других больших изображениях. Во время работы в Men’s Health я использовал шрифты вроде Tungsten или Heron, которые выглядят ужасно в тексте, но отлично смотрятся в заголовках или промоматериалах (которые и были моей основной работой). Это был стиль, который я и хотел создать.

Очень грубые наброски

13:00, среда

Я отправился в Adobe Illistrator с двумя-тремя буквами, которые были у меня в эскизах. Я создал сетку из пяти строк – для линии нижних выносных, базовой линии, линии строчных, линии прописных и линии верхних выносных букв. Затем я определил ширину прописных букв и толщину основного штриха.

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

  • Линия строчных = 2 × высота линии верхних выносных / высота линии нижних выносных
  • Ширина основного штриха = ¼ ширины прописной буквы
  • Ширина строчной буквы = ¾ ширины прописной буквы

Вот как это выглядит на иллюстрации

Сначала я создал буквы O и B. Я решил, что эти буквы будут иметь не форму овала, а форму скругленного угла. Многие буквы будут выглядеть, как высокий прямоугольник, но O, B и D будут иметь скругленные углы вместо овалов.

Внешний угол имеет радиус 12 мм, а внутренний — 6 мм. С этими правилами я начал создавать прописные буквы.

Мой шрифт был очень простым, но с одним «украшением». Любая апертура, то есть, срез концов полуовала, должна была быть отрезана под углом. Самыми сложными буквами стали G и K.

Затем я приступил к строчным буквам. Это было сложнее, но с установленными правилами работать было проще. Я использовал больше «украшений», особенно в верхних выносных и нижних выносных элементах. Самыми сложными стали буквы f, g, a и e, так как они были абсолютно новыми.

21:00, среда

Я перешёл к другим символам, таким как восклицательный и вопросительный знаки. Я стал работать быстрее и успел создать около 35 знаков.

Утро четверга

Утром я довольно быстро закончил цифры от 0 до 9 и начал создавать файл с шрифтом. Это было совершенно новым опытом. Мой знакомый каллиграф Иэн Барнард посоветовал для этого программу Glyphs. Я скачал программу, посмотрел несколько обучающих видео и понял, что неверно создал файл в Illustrator. Поэтому мне пришлось вставлять каждый символ вручную и подгонять его под правила программы.

10:00, четверг

Я начал заниматься интервалами и кернингом. Это было ужасно долго. Прежде чем заняться этим, нужно освоить множество сочетаний клавиш в программе. И перед кернингом вам нужно сделать интервал как можно ближе к тому, что вы хотите видеть в итоге. Для этого нужно измерить ширину отверстия в букве О и разделить ее на три. Такой интервал стоит поместить слева и справа от буквы.

11:00, четверг

С расставленными интервалами я приступил к кернингу. Это стало очень болезненным процессом. Сначала я зашёл на этот сайт и вставил в их текст для кернинга свой шрифт.

Используя сочетания клавиш, я изменил каждое расстояние между буквами, которое меня не устраивало. Самым очевидным является сочетание V и A, но в этом тексте есть и такие сочетания, о которых я и подумать не мог.

Затем я конвертировал текст в прописные буквы и сделал то же самое для них.

12:59, четверг

Я экспортировал шрифт и конвертировал его в файл .ttf, чтобы отправить в Google. Несколько символов отсутствовали (квадратные скобки и символ копирайта), и я был уверен, что шрифт не примут. У меня также не было времени добавить различные знаки для поддержки разных языков.

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

Название шрифта? Odibee Sans (произносится как oh-dee-bee), то есть, One Day Build — ODB.

Заключение

Я отправил Odibee Sans в Google в мае 2017, и он все ещё находится в очереди на добавление. Команда предложила мне пока уделить время дизайну шрифта, хотя они признали, что это противоречит духу проекта.

Я поработал над шрифтом ещё один день. Я добавил все нужные знаки, а также внёс изменения примерно в 30 символов.

Более того, сейчас в шрифте существует более 1500 кернинговых пар, что стало значительным улучшением шрифта. А также я создал сайт: odibeesans.com.

Комментарии
Продолжить чтение

Разработка

Как сделать собственный VR-шлем за $100

Максим Кутте, 16-летний разработчик, создал свой open source шлем виртуальной реальности.

Леонид Боголюбов

Опубликовано

/

Меня зовут Максим Кутте. Мне 16 лет и я со своими друзьями, Йонасом Сессоном и Габриелем Комбе, сделал свой собственный шлем виртуальной реальности. Он стоил нам всего 100 долларов.

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

Я потратил один год на создание простой 8-битной операционной системы и участие в конкурсе роботов.

Затем я заинтересовался виртуальной реальностью. И мы с друзьями решили, что неплохо было бы создать собственный мир в VR, в котором мы могли бы проводить время после школы. Но Oculus  тогда стоил 700 долларов, и мы решили создать собственный шлем.

VR для всех

Напечатанная на 3D принтере запчасть

Причиной всего стало аниме под названием Sword Art Online. Его главный герой находится в ролевой виртуальной реальности – и так я влюбился в VR. Я хотел понять все ее аспекты.

Я купил самые дешевые компоненты, которые мог, и начал, изучая основы физики и математики виртуальной реальности (правильное ускорение, первообразные, кватернионы…) А потом мы заново изобрели VR. Я написал WRMHL, а затем с Габриелем FastVR. Объединив все это вместе, мы получили гарнитуру стоимостью $100.

Полностью открытая гарнитура для VR и комплект для разработки

Чтобы ускорить время разработки, мы сделали FastVR – SDK с открытым исходным кодом для разработчиков, который легко понять и кастомизировать. Он работает следующим образом:

  • Главный компьютер шлема вычисляет его позицию в пространстве
  • Позиция из шлема отправляется в WRMHL и часть вычислительной мощности процессора тратится на обработку этого сообщения
  • Затем FastVR извлекает данные и использует их для рендеринга VR-игры

Все, что вам надо – сделать на основе открытых исходников шлем.

Почему open source

Я хочу сделать VR мейнстримом. Поэтому я обратился к Уссаме Аммару, одному из соучредителей The Family. Я обсудил с ним создание компании и запуск на Kickstarter.

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

Мы отправились в Кремниевую долину, и Уссама познакомил меня с главным архитектором в Oculus, Атманом Бринштоком. И они дали мне ценный совет: сделай все это open source.

Следующий шаг

Есть еще много технических моментов, которые мы хотим улучшить.

Сейчас мы работаем над автономной VR-гарнитурой –  у нас уже есть как упрощенная версия с более дешевым 3D-трекингом.

Все это мы скоро выпустим.

Как начать

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

 

Комментарии
Продолжить чтение

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Вакансии

Популярное

X

Спасибо!

Теперь редакторы в курсе.