Как заставить разработчиков следовать стандартам кодирования? [закрытый]
Удалить продукт обновления со страницы редактирования.
def edit
@message = Message.new
@message.build_company
@categories = Category.all
end
Метод product_parameters должен быть.
def product_parameters
params.require(:product).permit(:id, :name, :description, :picture,
:product_spec_id)
#params.require(:product).permit! for permitting all attributes.
end
Вы получаете эту ошибку, потому что вы пытаетесь обновить метод редактирования, который недопустим. В методе редактирования, как вы можете получить разрешенные параметры? если не передано никаких параметров.
41 ответ
Хотя я полностью согласен с автоматизацией ваших стандартов, мне действительно любопытно, каковы стандарты вашей компании и сколько людей здесь делают то же самое, что делают ваши разработчики.
Я работал с людьми, которые печатали полные документы того, что они считали стандартами, и пытались передать их своим коллегам. Вот где они потерпели неудачу:
- Они создали их в пузыре. С командами не консультировались.
- Они основывались на языке, который мы не использовали.
- У большинства правил была основа это большинство считается недостатком. "Если у вас есть большой метод / класс "был обоснование переменных префиксов; почему бы просто не иметь маленький методы / занятия и не беспокоиться о что вы называете вещами?
- Методология комментирования была основана на их академические правила. Чрезмерно подробные заголовки функций и т. д.
- Они были сосредоточены на неправильных вещах. В первую очередь они были сосредоточены на именовании переменных, методов и классов, чтобы они следовали определенной форме (определенным префиксам) вместо содержимого - «точно ли они указывают, что они / делают?» это единственный вопрос, который имеет отношение к именованию (за исключением языков, где это происходит ...).
- У них просто не было влияния на заботиться о людях.
Ваша лучшая ставка в том, чтобы провести еженедельное собрание по проверке кода, на котором вы поместите свой код , который соответствует стандартам, на экран и получите критику своих коллег. Вы увидите, где ваши стандарты не работают, и вы получите «хороший» код перед ними. Видение хороших практик в действии должно влиять на будущие решения.
Просто будьте готовы смириться - проблема может быть у вас.
It's hard to teoubleshoot something like this without more information, but in my experience I've seen people stray from established code standards for a number of reasons.
Here are some common causes:
- Deadlines keep changing causing technical debt (shifting goal posts),
- 'Just get it done' mentality (usually driven by management)
- Lack of peer review
- Lack of responsibility
- Disagreement about the coding standards or standards are too granular/restrictive
- Standards not clear enough or not properly understood
Your first step should be to try and understand why people aren't following the standards, before you figure out ways to enforce it - if this is the third project obviously something is wrong which isn't going to be easily solved.
At the end of the day you need to be able to justify the cost (time/effort) of enforcing a standard - i.e. if the standard is very granular, it's more expensive then more relaxed standards.
Secondly, if you want people to take them seriously, you need to have some clout within your company to enforce the standard. You may need to make an example of someone who doesn't follow the agreed standard (see below).
Lastly, you really need to seek input from the development team whether you believe they are experienced enough or not. If anything, you really need to be able to justify the coding standard by saying you've given everyone an opportunity to provide feedback and input into it - i.e. it's an agreed standard.
Simply telling them to do it, saying that your way is the right way is guaranteed to fail. Pretty much 100% guarantee that it will fail. I have seen no exceptions. (you can quote as many books and websites and experts on the subject, the outcome is the same)
Depending on the age of the company the momentum of the engineers is what made that company what it is, so if they are following the momentum they are the ones doing it the right way.
If you want to succeed
1) you must have significant buy in, which means the group has to work on the solution and not be dictated to
2) big changes will fail, if the company has been around long enough you have to work on polishing, not starting over. Make small tweaks, one or two tweaks only at first. If you succeed then you can try for another, if you fail then give up...when in rome...
If it is bothering you this much then perhaps you are either in the wrong job or in the right job at the wrong company.
Standards, process, etc are generally as touchy as abortion and religion, the more you push the more they dig in and the less likely you are to make any progress.
Using or quoting fads like tqm, cmm, 5s, iso, six sigma, etc are a recipe for failure. Now being a contractor going from company to company TEACHING those fads, that will make you wealthy, perhaps you should look into that.
There is no I in team if you are doing this without the team then you are going to fail. Getting management buy in but not the teams buy in results in mutiny then failure or layoffs and failure or walkouts and failure, losing your key staff members and failure. You have to join them not fight them, at this point you have to undo the fights you have already had, it will be an up hill battle.
Путем принудительного анализа кода на основе документа о стандартах кодирования и отклонения, если стандарты кодирования не соблюдаются, и включения средства улучшения кода ( http://sourceforge.net/projects/gcgreatcode ) в стандартном процессе сборки. После чистой компиляции (без ошибок, без предупреждений компилятора, без предупреждений о линтах, ..) вызовите greatcode.
На меня была возложена ответственность за внедрение стандартов в Наша компания. Есть ряд вещей, которые сработали, и ряд уроков, которые я извлек. Сообщество разработчиков, которое следовало бы этим стандартам, составляло около 25 человек. Первое, что нужно выяснить, - это культура и стремление к стандартам, поскольку это будет определять ваш подход. Одна из первых вещей, которые вам понадобятся, - это участие руководства. Могут быть менеджеры проектов, которые видят стандарты только в том, что они способствуют срыву сроков. По сути, вам нужна поддержка старших технических менеджеров, которые признают, что проверка кода и стандарты являются фундаментальными инструментами для решения проблемы «технического долга». Существует множество обоснований и ресурсов, описывающих это, но это огромная проблема для любой организации с большой устаревшей кодовой базой.
Если технический долг является проблемой, то у вашей организации уже будут проблемы со сроками разработки, тестирование, растущее отставание в поддержке и, возможно, даже высокая текучесть кадров. Все это должно быть возможным количественно (приблизительно), если вам нужно выделить проблемы для высшего руководства.
Следующими людьми, которых вам нужно убедить, являются сами разработчики. У вас будут одни позитивные люди, а другие - против. В нашей компании мы сформировали группу «стандартов» и пригласили ряд разработчиков принять участие в этой работе. Когда были представлены документы по стандартам, группа по стандартам обсудила и согласовала их, прежде чем внедрять их.
Мы сочли важным передать инклюзивное и позитивное сообщение. «МЫ» будем делать это, а не «ВЫ» должны это делать. Такие заявления, как «Стандарты помогут нам всем узнать больше и сделают нашу жизнь проще в долгосрочной перспективе», также помогают. Представьте стандарты как инструмент для обучения и приобретения новых навыков (которые вы, неизменно).
За пределами стандартов были формальные проверки кодекса. Процесс для этого вполне может быть адаптирован к индивидуальным потребностям вашей организации, но самое важное - дать понять, что проверка кода не является критикой. Также важно не связывать личную производительность с количеством неудачных проверок кода. Достаточно общего наблюдения об их общей готовности поддержать процесс.
В нашей организации после внедрения стандартов (особенно на раннем этапе) они оказались довольно подвижными и подверженными изменениям (по мере того, как мы узнали больше об их актуальности и применимость), поэтому у нас возникла проблема сообщить об изменениях сообществу разработчиков. Вместо того, чтобы пинговать документ, чтобы разработчики могли его просмотреть на досуге, мы проводили учебные дни и брифинги. Это времена, когда разработчики находятся вдали от своих рабочих мест, и это помогает людям почувствовать, что у них есть возможность бросить вызов и задать вопросы. На этих тренингах мы также представили новые методы и идеи, опять же, с сообщением «Это действительно полезно, это облегчит НАШУ жизнь».
Периодически мы проводим сессии по пересмотру стандартов, на которых каждый может поделиться своим мнением. чувствую, работает и не работает. Все это говорит о том, что разработчиков не навязывают, и что в долгосрочной перспективе мы просто пытаемся облегчить им жизнь. Безусловно, хорошее понимание стандартов и передовой практики (и участие в них) будет хорошо смотреться в любом резюме!
Любые оценки сроков должны учитывать анализ кода, и руководство должно осознавать, что, по крайней мере, на короткий период времени, после введения стандартов, «выход» может упасть.
Любое сопротивление, которое вы получите, почти наверняка будет пассивным, люди откажутся следовать стандартам или проверкам кода. С этим трудно справиться (и иногда это может быть неприятно, если вы дружите с ними). Если у вас есть адекватная система для записи обзоров кода и участия, тогда у вас будут некоторые показатели для использования в обзорах производительности (хотя я бы рекомендовал это только в крайнем случае). Именно здесь ваша поддержка со стороны руководства будет наиболее важной.
Наконец, будут такие сценарии, когда, когда чипы не работают, мы должны просто опустить голову и кодить как сумасшедшие. Они часто видят, что стандарты уходят в окно. Здесь важно иметь стандарты и обзоры, настолько встроенные в ваш процесс, что это просто невозможно.
Я мог бы, наверное, написать об этом целое эссе, и вдаваться в подробности. Надеюсь, сказанное выше имеет смысл, поскольку это настоящая свалка мозгов!
Для начала имейте разумный стандарт кодирования, утвержденный ветераном, который все уважают. Не отдавайте эту работу какому-нибудь MBA-специалисту по обеспечению качества, который ничего не знает о программировании или хочет применить первый попавшийся документ в Интернете. Прежде всего, принимайте комментарии и предложения от всех членов команды.
Далее, имейте в виду, что никто не будет читать этот документ. Мало того, что стиль кодирования для большинства из нас является религиозным вопросом, нам и так приходится слишком много читать, и мы обычно откладываем это дело.
Лучший способ - сделать это частью процесса разработки. Если код не компилируется, ваши программисты будут его исправлять. Если им придется делать больше кликов... Также вы можете иметь скрипт предварительной коммисии (в svn есть такие предварительные крючки). В общем, это процесс, который можно автоматизировать, и это как раз то, что все избегают делать вручную.
Однако! Будьте внимательны:
- если инструмент применяет какой-то другой стиль (ошибки конфигурации)
- элемент списка
устаревший код
Сделать это частью их должностных инструкций в их ежегодном обзоре, и привяжите его к своему годовому бонусу, если им это удастся.
Я бы, вероятно, коснулся проблемы несколько косвенно. Вместо того, чтобы указывать на его код и говорить, что он должен стать лучше (или что-то в этом роде), вы можете вернуться к спецификации того, что вы должны делать. Возможно, у него уже есть требования (или, по крайней мере, руководящие принципы), которые он нарушает; если так, у вас есть реальное основание утверждать, что то, что он делает на самом деле , не в порядке.
Если он еще не содержит таких требований, в зависимости от того, насколько гибка спецификация, вы можете работать над добавлением некоторых таких требований (или, по крайней мере, руководящих принципов).
Другая возможность - рассмотреть набор руководящих принципов кодирования для всей компании. Если он уже установлен, возможно, он нарушает его требования. Если это так, у вас (снова) есть реальное основание для того, чтобы сказать, что ему нужно изменить свой образ жизни. Если там уже есть , а не , вы можете попробовать его установить.
Так же, как всегда есть по крайней мере один кодировщик, который делает паршивую работу, всегда есть по крайней мере бюрократ, который приветствует введение новых правил и положений. Немного поискав, вы почти наверняка найдете хотя бы один такой. Вполне вероятно, что вы найдете кого-то вроде этого на должности, которая делает, по крайней мере, в некоторой степени разумным, чтобы такой набор руководящих принципов входил в сферу его ответственности.
Обратитесь к нему с предложением (не упоминая напрямую текущую проблему), что компания действительно должна иметь набор руководящих принципов того, как выполняется кодирование.Один из способов продать такие вещи - упомянуть стандарты ISO 9000 (и связанные с ними) и указать, насколько они являются лучшими практиками для бизнеса, даже если они не намерены проходить сертификацию как соответствующие со стандартами.
Однако будьте готовы: когда / если вы это сделаете, вы почти наверняка (эффективно) добровольно предложите приложить усилия для разработки руководства. Если вы достаточно моложе, они могут решить официально назначить ответственным кого-то другого, но они, вероятно, сочтут это «вашей идеей», так что, скорее всего, вы все равно будете выполнять большую часть работы. В таком случае, если вы собираетесь пойти по этому пути, будьте готовы сделать это «по-настоящему». Если вы действительно разрабатываете общекорпоративное руководство, вам действительно нужно думать о том, что подходит компании в целом, а не только о том, чтобы разбираться с вашими домашними раздражениями по поводу кодирования человека, о котором идет речь.
Также имейте в виду, что подобные вещи могут существенно повлиять на вашу карьеру - если вы больше всего хотите быть парнем, который сидит в своем кабинете и остается один, чтобы проверять код, это может быть не так. отличная идея. Это почти наверняка сделает вас более заметным и более или менее управленческим человеком, а не просто кодировщиком (и он наверняка последует за вами на вашу следующую работу, когда / если вы переедете). Это не всегда плохо, но нужно подумать, действительно ли это то, чего вы хотите.
Сотрудник? Вот оно - я отправляю таких людей в отдел кадров для беседы о трудовой этике, угрожая увольнением.
Следование стандартам не является факультативным. Как сотрудник - или подрядчик - следование стилям кодирования является обязательным. Умышленное невыполнение этого требования является нарушением контракта. Включая оплату услуг внешнего консультанта для наведения порядка. В том числе - при повторении - увольнение за нарушение контракта.
Это просто - если я нанимаю вас программистом в свою команду, а вы не выполняете приказы и делаете себя бесполезным в команде, вы не имеете права быть в этой команде.
http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
http://psycnet.apa.org/?fa=main.doiLanding&doi=10.1037/0022-3514.77.6.1121
Также объяснение того, почему большинство водителей считают себя выше среднего. Основная проблема заключается в том, что для точной оценки собственной компетентности вам необходимо быть достаточно компетентным для этого. Наименее компетентные также меньше всего осведомлены о навыках, которых им не хватает.
На вашем месте я бы также учел некоторые из приведенных выше советов.
Дайте им их собственный (друг друга) старый код для исправления, расширения, поддержки, модификации, рефакторинга, оптимизации и так далее. Предпочтительно каждый - несколько частей кода из нескольких других.
Запрашивать отчеты о качестве кода, с которым им приходилось работать.
Передайте отчеты первоначальным авторам кода.