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

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

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

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

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

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

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

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

Хорошо, вот мой взгляд на эту большую и сложную тему.

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

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

Минусы для сохранения вашего стиля кодирования:

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

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

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

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

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

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

Комментарий хорошо

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

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

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

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

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

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

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

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

"Умные" хитрости

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

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

ПОЦЕЛУЙ

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

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

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

x = x || 'default_value';

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

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

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

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

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

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

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

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

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

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

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

И так далее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну, для начала это выглядит как базовый JS для меня.

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

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

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

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

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

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

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

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

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

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

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

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

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