Какова фактическая ценность согласованного стиля кода

Я являюсь частью команды консультантов, внедряющих новое решение для клиента. Я отвечаю за большинство обзоров кода на клиентской кодовой базе (React и javascript).

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

Пример 1 (одноразовые встроенные функции)

React.createClass({
  render: function () {
    var someFunc = function () {
      ...
      return someValue;
    };
    return <div>{someFunc()}</div>
  }
});

Автор утверждает, что, присвоив значимое имя someFunc, код будет легче читать. Я считаю, что, добавив функцию и добавив комментарий, можно добиться того же эффекта.

Пример 2 (несвязанные функции)

function renderSomePart(props, state) {
    return (
      <div>
        <p>{props.myProp}</p>
        <p>{state.myState}</p>
      </div>
    );
}

React.createClass({
  render: function () {
    return <div>{renderSomePart(this.props, this.state)}</div>;
  }
});

Вот как мы обычно это делаем (избегая необходимости передавать состояния и реквизиты):

React.createClass({
  renderSomePart: function () {
    return (
      <div>
        <p>{this.props.myProp}</p>
        <p>{this.state.myState}</p>
      </div>
    );
  },
  render: function () {
    return <div>{this.renderSomePart()}</div>;
  }
});

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

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

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

Вопрос:

Какова ценность того, что клиент и его разработчики воспринимают как единообразную кодовую базу по сравнению с тем, чтобы такие несоответствия сохранялись и могли распространяться?

Преимущество передачи кода

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

Потенциальные проблемы обратной совместимости

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

Новые члены команды становятся продуктивными быстрее

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

Потенциальные неоткрытые проблемы

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

При этом инновации - это всегда риск, если вы твердо уверены, что ваш подход лучше и он работает для вашей команды, сделайте это!

Несоответствия заставляют вас задуматься, почему , где и где :

• Когда вы читаете часть кода и видите, что он использует стиль, отличный от остального кода, возникает вопрос : почему эта конкретная часть отличается? Есть ли у меня особая причина, о которой мне нужно знать? Это опасно, потому что если на самом деле есть причина отличия этой части, вы должны знать об этом, иначе вы можете создать некоторые неприятные ошибки. Таким образом, вместо того, чтобы думать об исходной проблеме, которая заставила вас перейти к этому коду, вы теперь теряете время на размышления о том, почему он отличается, и вы не можете понять это, поэтому вы идете к первоначальному автору, чтобы спросить их, тратя их время тоже, и еще хуже - в процессе вы теряете ментальную модель проблем, над которыми работали.

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

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

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

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

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

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

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

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

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

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

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

То, что вы ищете, является счастливой средой вашей команды.

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

У меня складывается впечатление, что в глубине души вы уже знаете ответ на этот вопрос, и вы бы даже не столкнулись с ним, если бы не это:

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

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

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

К сожалению, как заявил eBusiness, если ваш клиент не является технически подкованным или не собирается самостоятельно обслуживать код, им трудно оценить ценность согласованных стандартов кодирования. Тем не менее, любой разумный бизнесмен должен быть в состоянии понять концепцию, что «немного профилактического обслуживания сейчас» (в форме хорошего кодирования) «поможет избежать значительных затрат на ремонт позже» (в виде потраченного впустую времени разработчика, более поздней очистки беспорядок).

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

Слишком большое внимание к мелочам может привести к потере внимания к более важным вопросам, таким как, как решить работу в целом наиболее эффективным способом.

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

Гораздо более серьезная проблема - это запутанный код. Функции обертки, иерархии классов и все виды других конструкций, где окружающий код достаточно сложен, так что не очевидно, что они не служат никакой реальной цели. Если в коде присутствует явное раздувание, вероятно, существует гораздо больше неочевидного раздувания. С этим гораздо сложнее что-то сделать, и его сложнее обнаружить, но это также гораздо более серьезная проблема.

О клиентах

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

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