Connect with us

Разработка

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

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

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

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

/

     
     

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

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

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

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

shvedskie_shahmatu

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

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

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

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

scheme_lisp_SICP_Japan_edition

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

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

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

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

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

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

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

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

Григорий Петров
Комментарии Facebook
Продолжить чтение
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Обучение

Разработка iOS 11 приложений на Swift

Стэнфордский университет опубликовал новую версию курса по Swift в iTunes U.

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

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

/

В новом курсе учтены все изменения, сделанные в iOS 11 и новой версии Swift.

Темы:

  • Инструменты и API, которые понадобятся для разработки приложений для iPhone и iPad/
  • Пользовательский интерфейс.
  • MVC-парадигма.
  • Анимации.
  • Многопоточность.
  • Работа с сетью.

Курс бесплатен и доступен для прохождения на iPhone и iPad. Язык – английский.

 

Леонид Боголюбов
Комментарии Facebook
Продолжить чтение

Новости

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

Лучшие материалы о разработке и маркетинге технологических продуктов.

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

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

/

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

Леонид Боголюбов
Комментарии Facebook
Продолжить чтение

Разработка

Почему не надо патентовать идею мобильного приложения

Студия AppCraft рассказала нам, стоит ли патентовать идею мобильного приложения, а если нет, то как лучше подойти к развитию своего продукта.

AppCraft

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

/

Автор:

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

В этой статье мы тезисно перечислим причины этого не делать.

Что такое патент

Патент – это охранный документ, удостоверяющий исключительное право, авторство и приоритет изобретения, полезной модели либо промышленного образца. В случае с разработкой мобильного приложения, являющегося программным обеспечением, получить патент в России и Европе на алгоритмическую часть (непосредственно программу) не удастся: статья 52 европейской патентной конвенции прямо запрещает патентование программ для ЭВМ.

Поэтому в случае с мобильными приложениями, как правило, защищается не сам продукт, а общая идея функционирования сервиса, отражающая некоторую новизну подхода к решению той или иной задачи. Запатентовать код тоже можно, но только в некоторых юрисдикциях, например, в США или Южной Корее.

Это долго и дорого

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

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

Вы потратите минимум 50–100 тысяч рублей (если часть работы будете делать самостоятельно) и не меньше 3–4 месяцев, если делать все очень быстро.

После этого вы можете получить отказ на регистрацию от патентного бюро, потому что описание недостаточно детальное, не содержит инновационности, дублирует уже существующие патенты и т.д. Только 56% патентов регистрируется, соответственно, 44% – отклоняется.

При этом, по статистике, 97% (!) патентов генерируют прибыли меньше, чем стоимость их оформления.

Вы патентуете не то, что нужно

Практически всегда желание защитить бизнес возникает на стадии первой идеи. Как только прошло достаточно времени на обдумывание плана, сразу возникает мысль о защите еще будущего предприятия. Желание понятно, однако идея и ее реализация – всегда разные вещи.

Пол Грэм, один из известнейших предпринимателей в IT и основатель Y Combinator, говорит, что по его опыту от 70 до 100% проектов имеют разные ключевые идеи на старте и через 3 месяца операционной работы.

Так происходит из-за того, что бизнес – это решение реальных проблем. Он развивается и растет в синергии с потребностями людей, которые:

  1. вам досконально неизвестны на стадии идеи;
  2. меняются со временем;
  3. решаются так, как хочется им, а не вам.

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

Забывается главное

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

Фокусируясь на защите идеи, вы сразу же отстаете в скорости ее развития и реализации.

Патент – не единственный способ защититься

Если патент – неэффективный способ защиты бизнеса в самом его начале, то это вовсе не означает, что не нужно принимать вообще никаких оборонительных мер. В силу простоты и дешевизны можно использовать такие способы:

  • Купите домен с именем продукта. Хорошее имя дает сильный эффект, а при решении любых споров покупка вашего домена в более ранний срок, чем оформление торговой марки конкурента, решает многие вопросы.
  • Создайте группы в социальных сетях с названием проекта. Как и в случае с доменом, хорошие названия имеют и хорошие поисковые позиции, и неплохо запоминаются, и становятся недоступны конкурентам.
  • Зарегистрируйте торговую марку. Это не быстро в некоторых юрисдикциях (например, в России), но во многих странах осуществляется в течение нескольких дней и с минимальными затратами.

Итого

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

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

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

Календарь

ноябрь

17ноя - 19Весь деньТИЛТЕХ МЕДХАК

24ноя - 26Весь деньWhat the hack?!

25нояВесь деньSmart Taler 2017

25нояВесь деньLadies Code: время технологий

30нояВесь деньSmart Cars & Roads 2017

декабрь

5дек18:30- 22:00Яндекс изнутри: глазами iOS-разработчика

8дек - 9Весь деньКубок СTF России

9дек - 10Весь деньGames Gathering 2017

9декВесь деньЛекционный день по игровой индустрии

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

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

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

Наш Facebook

Популярное

X

Спасибо!

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