Если у моей команды низкий уровень мастерства, я должен опустить умение моего кода? [закрыто]

Например, в JS есть общий фрагмент, чтобы получить значение по умолчанию:

function f(x) {
    x = x || 'default_value';
}

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

Должен ли я использовать этот трюк? Это делает код менее понятным для сверстников, но более читаемым, чем следующее, в соответствии с любым JS dev:

function f(x) {
    if (!x) {
        x = 'default_value';
    }
}

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

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

155 голосов | спросил Florian Margaine 3 J000000Wednesday13 2013, 00:48:38

13 ответов


135

Хорошо, вот мой вопрос по этой большой и сложной теме.


Плюсы для сохранения стиля кодирования:

  • Вещи вроде x = x || 10 являются идиоматичными в разработке JavaScript и предлагают форму согласованности между вашим кодом и кодом используемых внешних ресурсов.
  • Более высокий уровень кода часто более выразителен, вы знаете, что получаете, и его легче читать среди высококвалифицированных специалистов.
  • Вам больше понравится ваша работа. Я лично ценю создание красивого кода. Я думаю, что это приносит мне большое удовлетворение в моей работе.
  • Как правило, он создает более читаемый стиль. Придерживаться идиом языка может быть очень ценным - они часто являются идиомами по какой-то причине.

Против сохранения стиля кодирования:

  • Программистам более низкого уровня будет сложнее идти в ногу. Это часто люди, поддерживающие ваш код, и те, кому придется на самом деле читать материал, который вы пишете.
  • Поддерживает код, часто код JavaScript поступает с других языков. Ваши программисты могут быть компетентными в Java или C #, но не понимать, как и когда JavaScript отличается точно. Эти точки часто являются идиоматическими - пример такой конструкции немедленно вызывается выражение функции (IIFE).

Мое личное мнение

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

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

Самое главное - оставаться последовательным.

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

ответил Benjamin Gruenbaum 3 J000000Wednesday13 2013, 01:03:50
46

Комментарий Well

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

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

Вопрос стиля?

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

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

Научите человека рыбу ...

Преподавание ваших товарищей по команде - это, вероятно, лучший способ помочь всем, кто участвует. Прояснить, что если у кого-то есть вопрос по фрагменту кода с вашим именем в журнале фиксации или отметках времени, они должны чувствовать бесплатно спросить вас об этом. Если у вашей команды есть обзоры кода, это отличная возможность объяснить любой возможный смущающий (ahem) код с комментариями для ваших товарищей по команде. Если ваша команда не имеет отзывов о кодах, почему бы и нет? Подходите к нему!

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

«Умные» трюки

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

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

ПОЦЕЛУЙ

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

ответил Corion 3 J000000Wednesday13 2013, 03:42:51
34

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

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

x = x || 'default_value';

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

Когда я смотрю на этот код, я вижу «если это null или undefined), тогда установите его на это значение по умолчанию. он также будет неявно рассматривать +0, -0, NaN, false и "" как неприемлемые значения. Мне придется помните, что через 3 месяца, когда это нужно изменить. Я, вероятно, забуду это. ".

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

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

Вы можете пойти с:

function f(x) {
    x = valueOrDefault(x, "default_value");
}

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


Теперь, как вы различаете функцию расширенного языка, такую ​​как передача функции в качестве аргумента или умный трюк как || "default"

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

| 0 или версия культового культиватора ~~num, используемая для напольных покрытий, предполагает положительные и 32-разрядные знаковые целые границы.

|| "default" предполагает, что все значения falsy одинаковы, не передавая вообще аргумент.

И так далее.

ответил Esailija 3 J000000Wednesday13 2013, 17:12:13
23

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

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

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

ответил Bryan Oakley 3 J000000Wednesday13 2013, 00:59:24
7

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

Общее руководство

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

  1. Если для этого не существует определенного недостатка, весь код должен быть написан в соответствии с определенным шаблоном или директивой, что позволит легко поддерживать разработчиков, которые будут его поддерживать. (Оговорка: следующие плохие шаблоны только потому, что они в настоящее время находятся в базе кода, - это ужасная практика.)
  2. Если вы можете найти вескую причину использовать специфичную для языка идиому, которая не легко читается целевой аудиторией, добавить комментарий. . Если вы обнаружите, что вам нужно добавить комментарий к каждому в другой строке, вы можете переписать свой код, чтобы быть более читаемым вашей аудиторией. Я не считаю ценным быть идиоматичным ради того, чтобы быть идиоматичным.

Конкретный пример

У нас есть большое количество Perl-скриптов в нашей базе кода. Обычно мы используем perl только для очень простых операций, и подавляющее большинство кода написано java-разработчиками, поэтому оно очень похоже на java. У нас есть набор скриптов perl и структура, написанная «perl-гуру», которая с тех пор оставила нашу фирму. Этот код содержит многие из более неясных perl-идиом, и ни один из наших разработчиков, включая меня, не может читать этот код perl без дополнительных усилий. Мы часто проклинаем его за это. :)

ответил user606723 3 J000000Wednesday13 2013, 04:22:41
5

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

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

ответил DavidR 3 J000000Wednesday13 2013, 02:33:14
3

Я бы не назвал ваш пример трюком, а просто идиоматичным. Если вы должны использовать, это зависит от ИМХО не столько на текущем уровне вашей команды, но если (по крайней мере некоторые из) ваши товарищи по команде готовы изучить некоторые новые идиомы. Конечно, вы должны обсудить эту тему с ними и не применять этот стиль для них. И вы не должны просить их каждый день изучать 5 новых вещей или «трюков». Но, честно говоря, если у вас есть только товарищи по команде, они не хотят изучать что-то новое, даже это так просто и мало, как эта идиома, вы должны подумать об изменении в другой команде.

ответил Doc Brown 3 J000000Wednesday13 2013, 00:59:12
3

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

В первом случае имеет смысл использовать улучшения и расширенные функции. Например: в C # вам не нужно использовать выражения Linq или Lambda, но большинство людей это делает, потому что это делает код более аккуратным и понятным, как только вы действительно знаете, что он делает. Сначала это выглядит странно.

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

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

Итак, как вы вводите эти изменения? Попытайтесь и обсудите с коллегами следующие направления: знаете ли вы, что эту функцию можно написать таким образом? Обзор кода и парное программирование могут быть хорошими временами, чтобы обеспечить «перекрестное опыление» идей. Мне сложно определить, что делать, потому что я не знаю среды, в которой вы работаете. Я считаю, что некоторые программисты могут быть очень защитными и устойчивыми к изменениям. Опять я виноват в этом. Лучший способ работать с такими программистами - потратить некоторое время на изучение того, что заставляет их тикать, изучать их предысторию, а затем сравнивать и сравнивать свои стили и опыт с их. Это требует времени, но это время хорошо проведено. Если возможно, попробуйте и поощрите их.

ответил Daniel Hollinrake 10 J000000Wednesday13 2013, 14:03:26
3

Просто не работайте в Royal McBee Computer Corp, потому что кто скажет, что вы не неопытный программист.

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

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

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

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

ответил gbjbaanb 8 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 08 Sep 2013 04:09:43 +0400 2013, 04:09:43
2

Хорошо, для стартеров это выглядит как базовый JS для меня.

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

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

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

ответил jmoreno 7 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 07 Sep 2013 22:11:35 +0400 2013, 22:11:35
1

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

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

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

ответил JB King 3 J000000Wednesday13 2013, 00:56:45
1

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

Я бы предположил, что нам нужны лучшие инструменты для решения этой проблемы. Ничего сложного, разумеется, у нас была технология, чтобы сделать это уже более 50 лет. Включите парсер в редакторе, и редактор сохранит источник в форме sexps (да, точно так же, как lisp). Затем источник читается, редактор разоблачает его в синтаксическом и типографском (вы знаете, пробелы, табуляции, запятые), который предпочитает пользователь.

Таким образом, вы можете вводить и читать x = x || 10, а другие программисты будут читать его как

if (0 == x) { x = 10;}

emacs имеет все части, чтобы сделать это легко.

ответил Pascal Bourguignon 3 J000000Wednesday13 2013, 10:13:50
-1

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

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

ответил jwenting 3 J000000Wednesday13 2013, 15:48:57

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132