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

Обучение

Истории разработчиков, получивших первую работу после 30, 40 и 50 лет

Куинси Ларсон, преподаватель в freeCodeCamp, собрал более 300 историй разработчиков, которые доказывают, что начинать учиться программированию никогда не поздно.

Анна Гуляева

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

/

Почему я это сделал

Каждый день я получаю письма от начинающих разработчиков со всего мира, в которых задаётся один и тот же вопрос:

Мне __ лет. Мне уже поздно учиться разработке?

Это один из самых распространенных вопросов в разработке в целом. Чтобы показать вам, сколько разработчиков волнует их возраст, я зашёл на Quora. Конечно, я нашел людей всех возрастов, которые переживают из-за того, что они «слишком старые», чтобы учиться программированию и становиться разработчиком: 60, 59585756555453, 52, 51504948474645444342414039383534333231, 29282726252423222120191817161514.

Что вы скажете кому-то, кто переживает, не слишком ли уже поздно? Многие люди ограничатся старой цитатой Уолта Диснея: «Если вы можете представить это, вы можете сделать это!»

Но я понимаю эти переживания. Я работал учителем и не умел программировать до 30 лет. До этого возраста я не мог написать даже простой код на JacaScript. Я не мог установить Linux. Да, я даже не мог настроить роутер без помощи жены.

Я получил первую работу в качестве разработчика в 31. И, конечно, я верю, что возраст — это просто число. И что все, кто могут вложить в обучение свои силы, могут научиться программировать и получить работу.

Но как мне убедить всех этих людей, задающих этот вопрос каждый день? Просто говорить «не переставайте верить» — неэффективно.

Я собрал доказательства, чтобы убедить людей расслабиться по поводу возраста

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

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

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

Поэтому однажды, после очередной попытки успокоить тревоги людей, я пересмотрел свой подход. Я подумал: «Возможно, я смогу найти список разработчиков, которые получили первую работ в 30, 40 или больше лет. Может быть, это убедит людей перестать так беспокоиться о возрасте».

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

Оказалось, что многие разработчики получили первую работу в 30, 40 или 50 лет. Вот несколько историй:

Я создал список из 300 разработчиков, которые начали после 30, чтобы показать, сколько людей начали переход к разработке ПО в более старшем возрасте. Я буду и дальше вести этот список. Поэтому, если вы разработчик, получивший первую работу после 30, твитните мне с хэштегом #DevAfter30, и я добавлю вас в список.

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

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

Новости

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

Под конец дня – Unity 2018, приложение по доставке и огромное академическое исследование стоимости разработки игр.

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

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

/

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

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

Мероприятия

Как я участвовал в хакатоне с 13 днями опыта в программировании

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

Анна Гуляева

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

/

Я даже не понял, что подал заявку на хакатон. Я услышал этот термин в подкасте CodeNewbie, когда кто-то делился своей историей. Из подкаста я запомнил рекомендацию стать частью сообщества. Поэтому, когда я увидел пост в группе freeCodeCamp Las Vegas о мероприятии StartUp Weekend, он привлек мое внимание.

Это мероприятие было посвящено созданию новых компаний через объединение предпринимателей, дизайнеров и разработчиков. Но, согласно моему аккаунту freeCodeCamp, я занимался программированием всего 13 дней. Я оставил комментарий под постом и спросил, могу ли я получить пользу от этого мероприятия, несмотря на нехватку знаний и опыта. Мне ответил Майк Зиетлоу и сказал, что я могу получить пользу, только мне нужно будет постараться. Поэтому я оставил заявку на то, что я сначала принял за митап.

Когда я приехал на место и не мог найти нужную комнату, я начал сомневаться в себе, но встреча с дружелюбными людьми помогла мне почувствовать себя уверенней. Я встретил Майка и мы обсудили, что я могу сделать на хакатоне.

Я объяснил, на каком этапе обучения я сейчас нахожусь. Я только закончил проект с созданием страницы о выдающемся человеке. Майк сказал, что группам понадобится человек для создания лендинговых страниц для их идей. Это помогло мне успокоиться: я мог сделать хоть что-то.

Майк на питче своей идеи

Выбор команды

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

Поэтому я искал команду, в которой будут опытные разработчики. Так получилось, что Майк питчил идею создания сайта для связи предпринимателей и разработчиков из Лас-Вегаса. Пять разработчиков и два бизнес-аналитика вступили в эту команду, и так появилась Developers.Vegas.

Две вещи подкрепили мое решение вступить в эту команду. Одна произошла, когда мы впервые встретились и обсуждали свои планы и подготовку. Майк упомянул, что в какой-то момент ему нужны будут фотографии. У меня был опыт в фотографировании и я предложил свою помощь. Майк был рад её принять, но затем он отказался. Он сказал, что я собирался быть разработчиком, и у меня были свои дела. Действительно, я пришел туда, потому что хотел учиться программированию, и Майк помнил об этом и уважал мое решение.

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

Работа над проектом

Наконец пришло время работы над проектом. До этого мероприятия я писал код в браузерных редакторах в freeCodeCamp и CodePen. После общения с командой я скачал VS Code. Я понял, что не понимаю, как все это работает. Мне нужно было разобраться с git, концепцию которого я понял, но мне ещё многому предстояло научиться. В один момент я работал над master вместо своей ветки. Эта работа была довольно нервной. Я думал, что подведу всю команду. Но, к счастью, я ничего не разрушил.

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

Мне напомнили заходить в Google, как только я застряну. Это звучит несложно, но я думаю, здесь есть особая техника. Я должен был знать, что задаю верные вопросы и получаю нужные ответы. Потом я понял, что никто не хотел браться за работу, которую дали мне. Я пока слишком мало знаю, чтобы понять, почему все ненавидят CSS.

На мероприятии я мог поучиться у других разработчиков. Я немного узнал о React и работе компонентов. Мы обсуждали код, когда пытались понять, как извлечь данные из базы данных, чтобы отобразить их на сайте. Я даже помог решить одну из проблем, когда захотел попробовать что-то новое. В процессе мы поняли, почему один участник команды не мог справиться с проблемой: мы управляли кое-чем как массивом, когда это на самом деле был объект. Тогда я понял, что действительно вношу вклад в работу команды.

Итоги

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

Я думаю, что значительная часть успеха команды основана на лидере. С самого начала Майк страстно относился к своему проекту. Большую роль сыграло его решение уделить время познакомиться друг с другом. Он также сыграл роль куратора, и наш успех во многом основан на том, что в команде был человек, который понимал конечную цель и средства для её достижения.

В итоге мы заняли второе место! Я рад, что поучаствовал в этом событии. Хотя оно и прервало мою 13-дневную серию на freeCodeCamp, я бы сделал это снова.

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

Разработка

Как приложение Wikipedia готовится к работе в офлайне

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

AppTractor

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

/

Автор:

Представляем вашему вниманию статью Риты Хо, соучредителя Wikimedia.

Нам в Wikimedia нам нравится начинать процесс проектирования с понимания аудитории. В 2017 году наша инициатива «Новые читатели» проводила этнографические исследования в Нигерии и Индии. Несколько моментов сильно повлияли на Android-команду Wikipedia:

Мобайл доминирует в выходе в Интернет, а Android — главная платформа. Мобильные приложения бьют все рекорды: мгновенные сообщения и социальные медиа находятся в топе.

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

Особенности работы в офлайне

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

  • Списки чтения. Пользователи могут легко сохранять статьи в списках чтения, чтобы просматривать их позже в автономном режиме.
  • Кеширование по умолчанию. Все открытые статьи кешируются и остаются доступными даже при потере интернет-соединения.
  • Офлайн-библиотека. Эта функция предусматривает бесшовный просмотр Википедии в онлайне и офлайне. Пользователи могут загружать коллекции статей Википедии в свою «автономную библиотеку» и продолжать поиск и чтение этих статей вне зависимости от наличия интернета.

Проектирование для офлайн

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

1. Осознавать состояние

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

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

2. Контекстные действия

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

Когда пользователь подключен к Сети, отображается предварительный просмотр связанной статьи, но когда он находится в автономном режиме, вместо того, чтобы показывать сообщение «нет соединения», им предоставляется возможность сохранить статью для чтения позже, как только соединение будет восстановлено.

Разница между онлайн и офлайн.

3. Обратная связь на медленном соединении

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

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

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

Мы также планируем обновить экран загрузки, чтобы показать “скелет” приложения – так пользователи смогут понимать, какой контент получается в момент открытия приложения,  это лучший индикатор прогресса, чем текущий статический экран с буквой «W» от Wikipedia.

4. Умное кеширование для ненадежных соединений

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

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

5. Контроль использования данных

Теперь доступны дополнительные настройки для тех, кто хочет экономить использование данных – есть возможность отключения изображений, и еще один вариант «предпочитать офлайн-контент», а не всегда загружать последнюю версию статьи.

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

В будущем планируется еще больше контроля, в том числе:

  • Возможность загрузки статей только по WiFi
  • Исключительно автономный режим
  • Загрузка изображений с низким разрешением перед загрузкой изображений с полным разрешением

6. Использование и хранение данных

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

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

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

7. Обучение пользователей

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

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

Экран обучения пользователей для офлайн-библиотеки.

Пустые экраны.

8. Совместное использование офлайн

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

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

Наконец, помимо функции «Автономная библиотека», само приложение Wikipedia также может быть загружено из сторонних источников, доступно на F-Droid (за пределами магазина Google Play), его можно скачать как APK на нашем сайте.

9. Вопросы экономии батареи

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

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

Что любопытно, эту функцию мы внедрили после того, как наше сообщество попросило об этом.

Примеры черного режима.

Приложение для Wikipedia является открытым проектом и вы можете принять участие в его развитии. Официальная страница: https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/App_hacking.

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

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

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

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

Вакансии

Популярное

X

Спасибо!

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