Стандарт оформления кода
Содержание
Применение
Образцом для стандарта кодирования может стать набор соглашений, принятых в какой-либо распространённой печатной работе по языку (например, стандарт кодирования на языке Си, получивший сокращённое наименование K&R, происходит из классического описания Си его авторами — Кернинганом и Ричи), широко применяемая библиотека или API (так, на распространение венгерской нотации явно повлияло её использование в MS-DOS и Windows API, а большинство стандартов кодирования для Delphi используют, в той или иной мере, манеру кодирования библиотеки VCL). Реже разработчик языка выпускает подробные рекомендации по кодированию. Например, выпущены стандарты кодирования на C# от Microsoft и на Java от Sun. Предложенная разработчиком или принятая в общеизвестных источниках манера кодирования в большей или меньшей степени дополняется и уточняется в корпоративных стандартах.
Состав
Стандарт сильно зависит от используемого языка программирования. Например, стандарт оформления кода для языка Си будет серьёзно отличаться от стандарта для языка BASIC. В целом, исходя из назначения стандарта, обычно он имеет целью добиться такого положения, когда программист достаточной квалификации мог бы дать заключение о функции, выполняемой конкретным участком кода, а в идеале — также определить его корректность, изучив только сам этот участок кода или, во всяком случае, минимально изучив другие части программы. Иными словами, смысл кода должен быть виден из самого кода, без необходимости изучать контекст. Поэтому стандарт кодирования обычно строится так, чтобы за счёт определённого визуального оформления элементов программы повысить информативность кода для человека.
Обычно, стандарт оформления кода описывает:
Вне стандарта подразумевается:
Стандарты кодирования и синтаксис языков
Стандарты кодирования и другие практики в IT
Много приходится читать и обсуждать разные стандарты кодирования, ограничивающие применение тех или иных конструкций языка (goto, множественное наследование классов в C++) или приемов программирования (рекурсия, динамическое выделение памяти после инициализации приложения). Применительно к С/С++, наиболее известными стандартами кодирования являются MISRA, HICPP, Google C++ Style Guide. Интересной является и статья на Хабре про 10 правил, которые позволяют NASA писать миллионы строк кода с минимальными ошибками.
Под катом немного юмора и серьезных рассуждений о применении различных практик ведения проектов.
Как утверждается, эти стандарты позволяют писать более чистый и легко читаемый код. Они позволяют избегать некоторых видов ошибок кодирования, и облегчают поддержку программного продукта.
Однако, на мой взгляд, незаслуженно мало внимания уделяется тому, как члены команды взаимодействуют друг с другом. Слаженная работа команды, эффективная коммуникация между людьми не менее важна для успеха проекта. Недопонимание, неправильная интерпретация сказанного, трудно понимаемые комментарии в исходном коде в конечном итоге сказываются на качестве программного продукта.
Для того, чтобы заполнить этот пробел, предлагаю ввести 10 правил, которые бы позволили бы избежать наиболее досадных ситуаций, происходящих из неясного изложения своих мыслей:
А теперь абсолютно серьезно.
Есть правила, имеющие универсальное и повсеместное применение. Это уголовный и гражданский кодексы, правила техники безопасности и пр. Соблюдение этих правил иногда позволяет избежать определенного рода неприятностей, но эти правила никоим образом не являются инструкцией, как достичь успеха.
Есть также книжки и психологические курсы о том, как быстро разбогатеть. Но мало кто воспринимает это всерьез. Не существует сколько-нибудь серьезно воспринимаемых правил или инструкций, гарантирующих успех проекта или успех в личной жизни.
Означает ли это, что к стандартам кодирования, разного рада практикам (SCRUM, Continues Integration, Code Review и пр.) не стоит относиться серьезно? Вовсе нет. Но надо понимать, что ни одна из практик в IT не является универсальной. Ни одна практика не приводит к гарантированному повышению эффективности проекта. Только накопленный опыт, интуиция и профессионализм менеджеров и ведущих разработчиков помогает принять правильное решение в каждой конкретной ситуации. Иначе бы наша профессия не была настолько трудной и интересной.
Если какой-то менеджер говорит о необходимости использования юнит тестов и аргументирует это красивыми диаграммами, убеждающими, что стоимость бага в геометрической прогрессии зависит от того, на какой стадии развития проекта этот баг найден – бегите из этого проекта или из этой компании. Я ничего не имею против юнит тестов. Однако, решение о том, использовать их или нет, и как их реализовывать, должно исходить из специфики данного проекта. Вот неполный перечень вопросов, на которые надо ответить прежде, чем принять решение:
Если мне надо что-то разрубить, я ищу топор. Но если у меня есть топор, и я хорошо умею им пользоваться, то это вовсе не означает, что я буду бегать и искать, что бы разрубить. Точно также и с правилами/практиками в программировании. Если я хорошо владею какой-либо практикой, я не буду требовать, чтобы ее применяли повсеместно.
1.6. СТАНДАРТЫ И ПРОГРАММИРОВАНИЕ
1.6. СТАНДАРТЫ И ПРОГРАММИРОВАНИЕ
Стандарты давно используются в технике и программировании. Создание сложной системы немыслимо без стандартов. Они нужны для борьбы с хаосом и неразберихой, но вместе с этим стандарт не должен быть слишком «узким» и мешать техническому прогрессу.
Государственные стандарты отслеживают тенденции развития программирования и дают обязательные рекомендации по их соблюдению. Помимо государственных стандартов (ГОСТ) действуют отраслевые стандарты (ОСТ), стандарты предприятий (СТП).
Группа стандартов ГОСТ «Единая система программной документации» (ЕСПД) претерпела мало изменений с момента ее создания, пережила несколько поколений ЭВМ и революционных изменений технологий разработки программ. При этом она до настоящего времени никогда не затрудняла новаций.
Помимо вышеизложенных стандартов де-юре имеются стандарты де-факто. Ряд стандартов устанавливается де-факто ведущими фирмами-разработчиками программ и вычислительной техники. Стандарты де-факто появляются на основе идей какой-то широко известной разработки. Выгодно делать продукты в стиле разработки какой-то фирмы, так как пользователи уже имеют навыки работы с меню в стиле «Lotus», электронными таблицами, текстовыми редакторами. Обычно стандартом де-факто определяются используемые операционные системы, трансляторы с языков программирования, организация файлов и средний уровень качества, достигаемый по окончании тестирования программ. Конкретному разработчику выгодно следовать таким стандартам.
В области программирования общепризнанной ведущей организацией по разработке стандартов является институт ANSI (Американский национальный институт стандартов). Данный институт является лидером по установке стандартов языков программирования, кодовых таблиц клавиш и символов, выводимых на экран, и еще многих других. Необходимо также отметить стандарты ISO.
К сожалению, самое благородное дело стандартизации — достижение всеобщей унификации и взаимозаменяемости — может также стать тормозом развития. Вводя новый стандарт, надо учитывать последствия ввода, особенно если стандарт является опережающим и опережает практику развития или если стандарт является слишком «узким» и тормозит эволюцию прогресса. Во всем мире руководствуются следующим отношением к стандартам: или полностью им следуй, или делай свой собственный стандарт. Стандарты дают дополнительные ограничения.
Программист должен уметь не только использовать готовые стандарты, но и разрабатывать новые. Так, например, правила однотипного оформления исходного текста программы определяются стандартом проекта, который может быть изменен при начале разработки нового проекта. Однако в течение выполнения одного проекта оформление всех частей программы должно быть однотипным. Поэтому зачастую перед началом нового проекта конкретным программистам следует разрабатывать свои стандарты, которые не нарушают ГОСТ, ОСТ и СТП и действуют в пределах конкретного проекта.
Читайте также
Основные стандарты
Основные стандарты UNIX явилась первой действительно переносимой системой, и в этом одна из причин ее успеха.Как в ранние, бесплатно распространяемые, исследовательские версии, так и в сегодняшние коммерческие и свободно распространяемые версии UNIX постоянно вносятся
1.10. Стандарты Unix
1.10. Стандарты Unix Когда писалась эта книга, наибольший интерес в сфере стандартизации Unix вызывала деятельность группы Остина по пересмотру общих стандартов (The Austin Common Standards Revision Group, CSRG). Ими было написано в общей сложности около 4000 страниц спецификаций, описывающих более
Битва за стандарты
Битва за стандарты Как следует из предшествующего изложения, со временем различия между клонами UNIX становились все более значительными. Во-первых, в основе существовавших её вариантов лежали разные базовые системы – SVR3, SVR4, 4BSD.Во-вторых, каждый разработчик считал своим
B.5 Стандарты RFC
B.5 Стандарты RFC В документе RFC периодически публикуется официальный список стандартов и их текущий статус. Этот список является самостоятельным стандартом (STD 1). Информация в таблицах от B.1 до B.5 была взята из RFC 1920, опубликованного в марте 1996 г. и отражающего статус и
17.1.2. Стандарты С
17.1.2. Стандарты С Разработка стандартов С была консервативным процессом, в котором серьезное внимание уделялось «сохранению духа» оригинального С, а акцент был сделан скорее на утверждении экспериментов в существующих компиляторах, чем на создании новых функций.
17.1.2. Стандарты С
17.1.2. Стандарты С Разработка стандартов С была консервативным процессом, в котором серьезное внимание уделялось «сохранению духа» оригинального С, а акцент был сделан скорее на утверждении экспериментов в существующих компиляторах, чем на создании новых функций.
STL и Стандарты
STL и Стандарты В книге я часто ссылаюсь на Стандарт С++, потому что основное внимание уделяется переносимой, стандартной версии С++. Теоретически все примеры, приведенные в книге, должны работать во всех реализациях С++. К сожалению, на практике это не так. Вследствие
Firebird и стандарты
Соглашения и стандарты.
Соглашения и стандарты. В настоящий момент к PGP относятся два зарегистрированных документа Интернет: RFC 1991 («Формат обмена сообщениями PGP») и RFC 2015 («Обеспечение безопасности MIME с помощью PGP», определяющий формат PGP/MIME).Введение новых алгоритмов и возможностей в PGP 5.x
Стандарты Wi-Fi
Стандарты Wi-Fi Сегодня используются три стандарта беспроводных сетей: IEEE 802.11b, 802.11a и 802.11g. Современные ноутбуки чаще всего оснащаются поддержкой всех стандартов.802.11b – первый стандарт беспроводных сетей, поэтому он является самым медленным (скорость до 11 Мбит/с). Стандарты
Стандарты кодирования
Сетевые стандарты
Сетевые стандарты Локальная сеть состоит из огромного количества компонентов. Это компьютер и сетевая операционная система; сетевая карта; концентраторы, маршрутизаторы и т. п.; программное обеспечение компьютера, работающее с сетевой картой. Требования к компонентам
Стандарты и совместимость
Стандарты и совместимость Лазерные носители информации, работающие с ними приводы описаны множеством стандартов и спецификаций, а также их модификаций, расширений и дополнений. Пока пользователь записывает и читает диски на конкретном приводе отдельно взятого
Региональные стандарты
Для чего нужны стандарты при написании программ
Многие программисты в своей работе так или иначе сталкиваются с различными стандартами. Хотя многие, в данном случае, вовсе не подразумевает большинство, потому что, к сожалению, на просторах бывшего СССР стандарты даже для оформления исходного кода скорее экзотика нежели правило.
Что представляют собой стандарты в программировании? Зачем их вводят солидные компании и даже open source сообщества? И почему их всё-таки лучше вводить и придерживаться?
Что включает в себя стандарт в программировании
Говоря о стандартах в сфере разработки программного обеспечения следует чётко различать четыре категории:
Стандарты первой категории устанавливаются государством и компетентными международными организациями.
Стандарты последней категории влияют на разработку за счёт того, что помимо всего прочего регламентируют такие документы как техническое задание, а также программа и методика приёмо-сдаточных испытаний. Однако сам процесс разработки как таковой они не затрагивают.
Так как написание и оформление программного кода в настоящий момент находится в ведении самих программистов, мы поговорим о стандартах, которые относятся ко второй и третьей категориям.
Что регламентируют они? Да, практически всё что угодно их составителям.
Начиная с банальных правил именования переменных и отступов от начала строки. Заканчивая архитектурой приложения.
Есть небольшие стандарты, которые регулируют лишь некоторые вопросы (в основном самые общие). А, есть и целые комплексы, которые покрывают программную систему целиком.
Причём и то, и другое является уделом не только крупных коммерческих организаций. Например, сообщество разработчиков CMS WordPress сформировало так называемый «Кодекс WordPress». Свод стандартов, регламентирующих почти все вопросы разработки для этой CMS.
Для чего нужны стандарты в программировании
Первая цель которую преследует стандартизация, это приведение рабочего процесса к некоторому «общему знаменателю». Разрабатывать программу гораздо проще если общие вопросы оговорены изначально. Также в исходном коде значительно легче разобраться, когда он оформлен единообразно.
Вторая задача, которую могут решить стандарты, это предотвращение грубых ошибок путём исключения из практики программирования в рамках стандарта тех или иных потенциально опасных приёмов.
В качестве примера, можно привести CMS WordPress. Плагин содержащий форму отправки данных не пройдёт code review при публикации, если форма не имеет специальных скрытых полей, которые подтверждают, что данные отправлены с «правильной» станицы.
Поэтому, стандарты играют важную роль не только в совершенствовании рабочего процесса, но и обеспечении надёжности работы программы.
Соблюдать стандарты или нет
Ответ на это вопрос напрямую зависит лот контекста.
Если речь идёт о стандартах Вашей компании или сообщества разработчиков, то здесь выбор безусловно не богат…
Однако даже если вы просто пишите код для себя или в рамках фриланс проекта, лучше всё-таки хотя бы выработать некоторые личные стандарты для разработки. Если вы грамотно выстраиваете архитектуру приложения и качественно оформляете код, это не только упростит вам процесс работы, но и даст понять потенциальному работодателю и заказчику что перед ним на самом деле профессионал.
Правда, даже те программисты, которые не ищут работу, со временем либо принимают уже сформированные кем-либо стандарты, либо вырабатывают собственные на основе своего опыта. Таким образом формируется так называемый «code style».
Конечно, в подобных вопросах последнее слово всегда за конкретным разработчиком или руководителем. Только банальное нежелание потратить немного времени на решение ключевых вопросов чаще всего приводит к огромным потерям времени и денег за счёт дополнительных затрат на разработку и сопровождение проекта (вникание в неоформленный код, ошибки, антапаттерны и т.д.), который, как это ни странно, при лучшем качестве мог бы стоить гораздо дешевле.
Стандартизация разработки ПО
«Первый шаг к совершенствованию — это стандартизация. Там, где нет норм, не может быть улучшения.»
Канбан и точно вовремя на Toyota
В этой статье вас ждёт мысленный эксперимент, в ходе которого я покажу, что может дать компании стандартизация разработки программного обеспечения, и проблемы, к которым она может привести. Статья не претендует на полный охват этой большой темы, но, я надеюсь, в ней будет тот минимум, который позволит вам по-новому взглянуть на разработку в своей компании.
Выводы и практические рекомендации, о которых я пишу, получены из моего опыта стандартизации в одном из крупнейших IT-разработчиков в России. Поэтому все названия вымышлены, а совпадения случайны.
В тексте вы встретите некоторые термины из фронтенда, в котором я работаю последние несколько лет, пусть вас это не смущает, сами принципы применимы и в других направлениях разработки.
Предположим, уже пару лет две питерские компании разрабатывают web-приложения для собственного бизнеса и сторонних заказчиков. В каждой компании работают четыре разработчика, по два в двух командах.
В первой компании, назову её Diversity, разработчики постоянно пробуют технологические новинки и любят поспорить друг с другом о преимуществах разных технологий. Одна команда пишет на TypeScript и использует React, вторая команда предпочитает JavaScript без типизации и использует Vue (подставьте здесь свои любимые технологии и фреймворки).
Во второй компании, пусть это будет Standard & Co, решили стандартизировать разработку и всё пишут на одном стеке с подробным регламентом разработки, пусть это будет React и Flow (типизированный JavaScript).
Давайте посмотрим, как эти компании будут справляться с традиционными задачами компании-разработчика web-приложений, и как стандартизация будет помогать (или мешать) их решению в Standard & Co.
Общие проблемы и общие решения
Стандартизация стека
Представьте, что обе компании решили внедрить в свои приложения календари с удобным выбором диапазона дат. Что произойдёт в этом случае?
Большая часть задач разработчика однотипны и уже имеют решения. Часто работа сводится к поиску готового решения в интернете и адаптации его под нужды конкретного проекта.
В примере с календарями разработчики сначала нагуглят готовые решения для своих фреймворков и выберут те, которые легче адаптировать под свои нужды. В Diversity разработчикам придётся проделать эту работу дважды, для первой команды и для второй, разные фреймворки не допускают общих решений. В Standard & Co эту работу можно поручить одной команде, вторая команда сможет быстро воспользоваться наработками первой.
Если речь идёт о разработке с нуля, Standard & Co сможет разделить работу между командами, в Diversity обеим командам придётся выполнить весь объём самостоятельно.
Руководители проектов каждой из команд обеих компаний пишут оптимистичные отчёты, разработка идёт своим чередом, разработчики выполняют свои задачи в нормальном режиме, но если посмотреть на эффективность компании в целом, то Standard & Co решила задачу с меньшими затратами ресурсов.
Отсюда мораль: единый стек — первый шаг к стандартизации разработки ПО.
Шаблон приложения
Бизнес Standard & Co развивается, компания постоянно создаёт новые приложения, поэтому разработчики решили создать для них общий шаблон, чтобы команды могли быстро стартовать и не терять время на разработку типичных архитектурных решений. В шаблон кроме самых базовых вещей решили включить модуль запросов к серверу, стандартизировали обработку ошибок, показ уведомлений, лоадеров, модальных окон и т.д. Обе команды создают стандартные части приложений одинаково, быстро и на автомате.
В Diversity команды каждый раз пробуют новые модули и решения независимо друг от друга, за обедом они увлечённо рассказывают друг другу о своих находках.
Standard & Co опять впереди с точки зрения общей производительности, они устранили расход времени на решение повторяющихся задач.
Мораль: стандартная архитектура экономит время.
Библиотека стандартных решений
Общая библиотека готовых решений (или даже не одна) рано или поздно появляется в каждой компании, которая создаёт ПО. Во фронтенде это библиотека компонентов интерфейса. Разработчики обычно ищут подходящее опенсорсное (или платное) решение или создают собственную библиотеку.
В Standard & Co взвесили за и против и решили сами создать одну общую библиотеку готовых компонентов (календари, поисковые строки с автодополнением и прочее) с прицелом на собственную дизайн-систему.
Diversity продолжает эксперименты с технологиями и даже может похвастать наличием нескольких библиотек в одном приложении. Под каждую отдельную задачу подбирается идеально подходящий модуль. Это интересная задача, но иногда такие модули требуют большого количества времени для интеграции.
Обе компании пришли к одному выводу: использование библиотек готовых решений высвобождает время разработчиков для реализации бизнес-логики, т.е. создания ценности для заказчика. Но в Standard & Co обнаружили ещё и некоторые дополнительные эффекты от использования общей библиотеки. Читайте далее!
Тестирование
Ещё один плюс, который обнаружила Standard & Co во время использования общих решений — это уменьшение количества ошибок в приложениях. Дело в том, что общие решения, которые используются в обеих командах, тестируются в разных сценариях, и с каждым новым приложением этих сценариев становится всё больше. Уверенность компании в надёжности общих решений и библиотек растёт со временем. Одна из аксиом тестирования — нет ПО без ошибок, поэтому увеличенный ресурс тестирования общих решений постоянно повышает качество конечного продукта.
Diversity подвергается большему риску, постоянно интегрируя новые решения. Ей приходится тратить значительные усилия для поддержания необходимого качества своих приложений.
Ротация проектов и людей
Ситуация на рынке изменилась, обеим компаниям пришлось на некоторое время приостановить разработку в одной из команд, тогда как другой команде наоборот, добавили работы и сократили сроки вывода продукта на рынок.
Standard & Co быстро усилила вторую команду разработчиками из первой, избежав простоя и поиска новых разработчиков. Переход на другой проект не занял много времени, разработчики снова погрузились в знакомую среду, им нужно было только разобраться с бизнес-логикой.
Так же легко Standard & Co решает и другие вопросы с перераспределением людей по проектам, будь то переходы из команды в команду из-за личных предпочтений или объединение команд.
В Diversity руководство встало перед сложным выбором: переучивать разработчиков первой команды на технологии второй, с чем, кстати, не все будут согласны, или открывать вакансии и набирать новых разработчиков. В любом случае потребуется дополнительное время для усиления второй команды, и может быть простой в работе первой.
Планирование
В Diversity уже накопили достаточный опыт планирования и понимают, какой запас времени необходимо заложить, чтобы учесть риски разработки.
В Standard & Co планирование имеет свои особенности. Благодаря большому количеству стандартных решений руководители проектов точно планируют время разработки, и в типовые проекты не закладывают дополнительные риски. Чтобы так делать, нужно заранее выяснить, какие части приложения потребуют нестандартных решений. Если разработка пойдёт не по плану, последствия могут быть серьёзными.
Рост компании
Маркетологи объявили следующий год годом расширения бизнеса в обеих компаниях. Пока точный объём работ не определён, но начать готовиться к росту нужно уже сейчас. Необходимо расширить разработку и нанять новых людей.
Standard & Co решает вопрос наймом начинающих разработчиков, которые могут обучаться и набираться опыта в любой из двух команд, и затем остаться в них или работать по общим стандартам как самостоятельные команды. Благодаря проведённой стандартизации возможны любые перестановки.
Diversity решает набрать новую команду, которая самостоятельно определит, с какими технологиями она будет работать, нужно быть в курсе технологических трендов. Вероятно, у них будет получаться лучше, чем у первых двух, но лучше подготовиться и к неожиданностям.
Контроль за разработкой и ревью кода
После появления новой команды, разработчики Standard & Co по очереди проводят ревью кода новичков, обучая их работе по стандартам компании и перенимая у них новые знания. Контролировать разработку в новом проекте может практически любой сотрудник компании с достаточным опытом разработки, там всё стандартно. Контроль и ревью требуют ресурсов, здесь Standard & Co снова имеют пространство для оптимизации.
В Diversity руководству приходится полагаться на лидов разработки. На эти позиции в компании попадают только зарекомендовавшие себя профессионалы. Компания полагается на честность и профессионализм этих ребят, ценит их вклад, постоянно заботится об их профессиональном развитии и высокой мотивации.
Эффективное общение
Программисты в Diversity любят спорить, о том, какая технология круче. Со стороны эти споры могут выглядеть, как битвы титанов. Матёрые разработчики кладут друг друга на лопатки очередным изящным выпадом в слабое место противника. Однако, пошумели и разошлись. Обычно такие баталии бывают эффектными, но не эффективными.
Разработчики Standard & Co после таких разговоров идут дорабатывать общий для них код. Помогая себе, разработчики помогают и другим, и наоборот. Ещё после недавнего набора новых разработчиков в Standard & Co проводят обучающие мероприятия. Раз в неделю кто-то из разработчиков разбирает технический вопрос из ежедневной практики, теперь можно с пользой для дела в рабочее время поговорить на общие темы.
Модернизация и быстрые технологические улучшения
Ещё одно преимущество стандартизации Standard & Co обнаружила после выхода новой версии языка TypeScript. Она показалась разработчикам удобнее для разработки, чем Flow, который они уже давно использовали. Разработчики Standard & Co переписали шаблон приложения и библиотеку компонентов интерфейса на TypeScript, сделав разработку проще, а код лаконичнее.
Сколько бы команд не было у компании, после обновления общих шаблонов и библиотек новый функционал сразу становится доступным для всех и проходят разностороннюю обкатку и тестирование. Инициатива о модернизации может исходить от любой из команд, за актуальностью стека в Standard & Co следит уже коллективный разум.
В Diversity каждой команде приходится самостоятельно следить за актуальностью своего стека и своевременно обновлять технологическую базу, что требует дополнительного времени и трудозатрат.
Негативные эффекты стандартизации
Потеря квалификации
Разработчики в Diversity — настоящие профи с широким кругозором и большим опытом в разных технологиях, а в Standard & Co много начинающих разработчиков и однотипных несложных задач, часто программистам становится скучно и хочется новых вызовов.
Если разработчик всё время выполняет стандартные рутинные операции, он может перестать развиваться и интересоваться технологиями. В таких условиях кто-то может даже перестать видеть свою ценность за пределами одной компании и постоянно терять мотивацию, и даже закончить тем, что вместо творческого труда будет просто ходить на работу за зарплату. Да и сама эта зарплата не будет высокой и не будет быстро расти, потому что система настроена на стандартизацию и упрощение работы каждого отдельного сотрудника и увеличение производительности системы в целом.
Стандартизация может негативно повлиять на уровень программистов.
В Standard & Co понимают эту проблему и стараются стимулировать творческую энергию своих разработчиков и направлять её на поиск более эффективных решений в собственном процессе разработки, углубление фундаментальных знаний, постоянную актуализацию стека и самообразование. Очень важно, что в Standard & Co направляют деньги и другие ресурсы как на технологическое развитие, так и на построение карьерного плана своих сотрудников.
Привязка к стеку
Бизнес-модель Diversity позволяет взять в разработку проект, часть которого уже готова или для которого заказчик определил стек технологий. Для этого ей нужно сформировать новую команду и наладить в ней процессы, что для Diversity совсем не сложно, учитывая её предыдущий опыт.
Руководство Standard & Co постарается договориться о переводе проекта на уже знакомые ей технологии. Если переговоры не приведут к желаемому результату, скорее всего компания откажется от проекта, новые для компании технологии — источник больших рисков.
Отклонения от стандартов — источник прогресса и ошибок
У новых разработчиков Standard & Co часто есть искушение вместо стандартного решения использовать какое-то другое, возможно более подходящее для конкретной задачи. В этом случае руководство компании предлагает тщательно взвесить все за и против.
Если новое решение окажется заметно лучше стандартного, то его нужно включить в стандарт и использовать во всех командах.
Если новое решение вместе с преимуществами также обладает и недостатками по сравнению со стандартом, или его преимущества невелики, такое решение не стоит использовать. Оно приведёт к дополнительным затратам времени на разработку, ревью, тестирование, обучение и прочее. Новым разработчикам придётся тратить больше времени на изучение технологий проекта.
Нестандартные решения могут содержать ошибки. Время, необходимое на исправление нестандартного кода обычно больше, чем время на доработки стандартного, уже знакомого кода.
В Standard & Co разработали специальные программы, которые мотивируют разработчиков с одной стороны придерживаться стандартов, с другой стороны постоянно их улучшать.
Стандартизация не происходит сама
Может показаться, что Standard & Co всё время экономит время и деньги благодаря стандартным решениям в разработке. Это так, но картина будет неполной, если не учесть издержки на сам процесс стандартизации.
Стандартизацию нужно направлять, кто-то должен разработать сами стандарты, написать регламенты, создать инфраструктуру, постоянно мотивировать коллег к пользованию стандартными решениями, контролировать их правильное понимание и применение. Для этого требуются время и усилия, которые Diversity может потратить на новый проект, обучение или улучшение условий труда.
Сами стандарты кто-то должен постоянно пересматривать и совершенствовать, иначе компанию ждёт технологический застой. Во фронтенде это особенно опасно, всего пара лет, и вы счастливый обладатель тяжёлого legacy, которое отнимает у компании ресурсы.
Два иероглифа в начале — кайдзен, японская философия постоянного совершенствования процессов производства, управления, бизнеса, жизни. Стандартизация — один из принципов этой философии. В середине прошлого века Toyota применяла принципы кайдзен, и в результате получила теперь уже знаменитую систему Канбан.
Стандартизация ускорила развитие промышленности, постепенно меняет и разработку ПО. Но здесь всё не так просто, человеческое мышление поменять сложнее, чем фрезерный станок.