"Должно быть легко для младшего разработчика понять" аргумент

Ответ 1

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

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

Здесь сообщение в блоге обсуждает эту тему.

Ответ 2

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

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

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

Ответ 3

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

Здесь альтернативный способ формулировки: "Напишите свой код, чтобы было достаточно легко понять, что если вы вызвали в 3 часа ночи и попросили исправить ошибку, вы все равно можете это понять".

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

Ответ 4

Есть разница между паролем и сложным кодом.

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

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

Ответ 9

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

Это означает:

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

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

Ответ 10

Да. Это очень веская причина, чтобы снять его с надреза. Реальность такова, что очень-очень много разработчиков (как и в большинстве) находятся на младшем уровне.

Насколько вам следует делать... Скажите "Да, сэр" или "Да, мадам" и сделайте это. В этих отношениях есть только один босс.

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

Когда ЛЮБОЙ разработчик (jr или иначе) запускается в код, который они не понимают, их первый подход заключается в том, чтобы реорганизовать его во что-то понятное. Это называется "Вау, этот код - дерьмо, я должен его переписать!" синдром. Я готов поспорить, что все на этом совете испытали это. Итак, как владелец бизнеса, я хочу платить за код, который будет разрабатываться каждый раз, когда приходит новый человек или я хочу платить за новые функции, которые нужно добавить?

Угадай, какой человек я собираюсь держать дольше.

Ответ 11

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

Я бы, однако, наложил тесно связанные требования:

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

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

Ответ 12

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

Ответ 13

Скотт Мук сказал:

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

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

Как такая ситуация помогает ремонтопригодности? Эта ситуация является одной из моих главных говядинок с программистами на C++. Намного лучше иметь беспорядок простого кода С, который можно взломать, чем алмазный кристалл inpenetrably супер-факторизованного кода, который почти никто не может понять, как разумно изменить, не разрушая кристаллическую структуру.

Ответ 14

Один из способов "обмануть" код, который я на самом деле считаю превосходной практикой, - использовать более длинные имена переменных и более длинные имена функций. Именование переменных и функций, чтобы сделать их цели легко понятными, - важная инженерная задача, IMHO, и требует дополнительных усилий со стороны оригинального автора кода. У Damian Conway есть отличные примеры в "Perl Best Practices". Некоторые примеры включают: Предпочитают "final_total" to "sum"; предпочитают "previous_appointment" to "previous_elem", предпочитают" next_client" to "next_elem". Предпочитайте "sales_records" к "данным" . и т.д. Он также подталкивает к использованию грамматических шаблонов (Noun-прилагательное) и остается последовательным. Не используйте max_displacement одно место, а затем используйте VelocityMax в другом. Индексные переменные также нуждаются в реальных именах:
sales_record[i] vs sales_record[cancelled_transaction_number]

Я часто "реорганизую" свой код в конце цикла разработки, нахожу новые имена для всех моих функций и переменных. В современном редакторе тривиально менять их все, и только в конце я действительно понимаю, для чего я их использовал. Код "Dumbing down" таким образом не классический C, но мне легче, когда я вернусь через несколько месяцев, спросив WTF, что я сделал?

Ответ 15

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

Ответ 16

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

Ответ 17

Я знаю разработчиков, которые писали сильно запутанный код, который, по их мнению, был продвинут, но остальная часть команды чувствовала себя нечитабельной и недостижимой. Частично это связано с чрезмерным использованием расширенных функций языка (в C, тройном операторе и операторе запятой) и написании в неясной личной идиоме (например, заменяя ptr- > элемент на (* ptr).item везде), что никто иначе он сможет поддерживать. Автор пытался перехитрить оптимизатора (что было бы справедливым, было далеко не хорошо).

Примечание. Я не предполагаю, что "x = (p == NULL)?" default ": p- > value;" сложный, но когда кто-то использует тройные операторы, которые охватывают многие строки, вложенные и активно используют запятую, код быстро становится нечитаемым.

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

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

Ответ 18

Старая цитата подходит здесь:

Сделайте все как можно проще, но не проще.

Ответ 19

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

Ответ 20

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

Ответ 21

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

Ответ 22

Я согласен на 100% с аргументом. С одним основным дополнением: Обучите своих младших разработчиков, пока они не поймут ваш код; -)

Ответ 23

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

Я думал, что это намного лучше и чище, чем использование синтаксиса привязки данных в ASP.NET, который не имеет проверки времени компиляции и испортил макет html.

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

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

Ответ 24

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

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

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

Жалоба менеджера никогда не должна быть "не делать этого, потому что наши младшие парни не понимают этого" - это всегда должно быть "делать x вместо y, когда это возможно, потому что x легче читать/понимать". Это также предполагает, что x и y эквивалентны (принимают один и тот же ввод и дают тот же результат).

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

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

Ответ 25

Удостоверьтесь, что вы можете понять, что он делает через 6 месяцев.

В случае сомнений, КОММЕНТАРИЙ ваш код. Для чего нужны комментарии.