“Должно быть легко для младшего разработчика понять” [закрытый] аргумент

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание: я не предполагаю что "x = (p == ПУСТОЙ УКАЗАТЕЛЬ)? "значение по умолчанию": p-> значение"; является сложным, но когда кто-то использует тернарные операторы, которые охватывают много строк, вкладываются и делают интенсивное использование оператора запятой, код быстро становится нечитабельным.

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

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

Старая кавычка является соответствующей здесь:

Делают все максимально простым, но не более простые.

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

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

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

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

Scott Muc сказал:

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

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

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

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

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

ОБНОВЛЕНИЕ: , Поскольку некоторые люди, кажется, думают, что наличие младшего dev изучение усовершенствованных тем при прохождении через запутываемый код я хочу добавить еще одну вещь здесь.

, Когда ЛЮБОЙ разработчик (младший или иначе) сталкивается с кодом они, don’t понимают, их первый подход должен осуществить рефакторинг его во что-то, что понятно. Это называют “Wow, что код является дерьмом, я должен переписать его! Синдром ”. I’m, готовый поставить всех на этой плате, испытал его. Так, как бизнес-владелец, я хочу заплатить за код, который будет разработан каждый раз, когда новый человек приезжает, или я хочу заплатить за новые возможности, которые будут добавлены?

Предположение, который человек I’m, собирающийся иметь в наличии дольше.

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

Я не соглашаюсь с менеджером: Что потребности быть простым является кодом, не, технология раньше писала это.

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

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

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

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

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

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

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

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

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

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

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

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

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

Существует различие между кодом загадки и сложным кодом.

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

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

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

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

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

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

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

Удостоверьтесь, что можно понять то, что это делает 6 месяцев в будущем.

, Когда в сомнении, ПРОКОММЕНТИРУЙТЕ свой код. Это - то, для чего комментарии.