Как бороться с плохим стилем / практикой кодирования пожилых людей? [закрыто]
У меня была такая же проблема сегодня, как правило, советуют использовать список скрытых флажков и эмулировать поведение с помощью css, таким образом, проще управлять, но в моем случае я не хочу изменять html.
На данный момент я тестировал этот код только с помощью google chrome, я не знаю, работает ли он с другим браузером, но он должен:
var changed;
$('select[multiple="multiple"]').change(function(e) {
var select = $(this);
var list = select.data('prevstate');
var val = select.val();
if (list == null) {
list = val;
} else if (val.length == 1) {
val = val.pop();
var pos = list.indexOf(val);
if (pos == -1)
list.push(val);
else
list.splice(pos, 1);
} else {
list = val;
}
select.val(list);
select.data('prevstate', list);
changed = true;
}).find('option').click(function() {
if (!changed){
$(this).parent().change();
}
changed = false;
});
Конечно, предложения приветствуются, но я не нашли другого пути
13 ответов
Лучшее и самое важное, что вы можете сделать, это подавать пример . Делайте все правильно и старайтесь постепенно улучшать ситуацию. Вы не собираетесь ничего исправлять в одночасье.
Убедитесь, что каждый фрагмент кода , за который вы отвечаете, стал лучше после того, как вы его закончите. Со временем система станет ощутимо лучше благодаря вашим усилиям.
После того, как вы заработаете прочную репутацию среди своих коллег, попробуйте начать некоторые обзоры кода или ланч-тренинги, чтобы познакомить всех с лучшими способами выполнения работы.
Вкратце: это будет сложно и разочаровывающе, но возможно. Удачи.
Лучше всего вообще НЕ заниматься этим. Вот возможные проблемы, если вы попытаетесь:
- Вас будут критиковать за то, что вы делаете то, о чем вам не говорили (из-за чего оценка производительности становится очень плохой).
- У вас будет меньше времени на самостоятельную работу.
- Вы не продвинет вашу карьеру, очищая рабочий код - если он не сломан, не трогайте его.
- Никогда не заводите врагов с людьми, которые контролируют вашу карьеру - непреднамеренно намекая, что они устаревшие идиоты, не поможет вашему делу (особенно в плохих экономия).
Сосредоточьтесь на совершенствовании собственного кода. Бороться с плохо написанным кодом - это часть плохого состояния инженера-программиста. Вы выбрали неправильную профессию, если не будете ее поддерживать.
Немного не в тему, но важно - вам может потребоваться сменить работу или команду, если это возможно, когда экономика пойдет на поправку.
Если вы младший разработчик, то единственное, что вы действительно можете сделать, это писать код настолько элегантно и читабельно, насколько это возможно.
Если ваш стиль действительно лучше, другие люди могут заметить и сказать: «Эй, мы должны принять эта формула »
Действия говорят громче, чем жалобы, что я заметил.
Так оно и есть, привыкните к этому или бросьте и найдите место, где это не так. Вы будете изолированы, если критикуете их усилия, и они могут почувствовать угрозу, если вы действительно напишете свой собственный, лучший код или улучшите их. В конце концов, они доставляют код, и руководство видит черный ящик, который работает, и это все, что имеет значение. Кроме того, вы будете просто еще одним парнем из колледжа, который думает, что знает что-то о развитии бизнеса, и смеется и подвергается остракизму, когда его нет рядом. Честно говоря, очень часто эти системы строятся подобным образом из-за неустойчивых требований, большого количества функциональных возможностей, привинченных со временем, и неуважения руководства к стабильному процессу разработки программного обеспечения.
Не все компании такие. Если честно, я бы начал искать новую работу.
Я искренне надеюсь, что это лучшая возможность для роста, столкнувшись с проблемой. Как сказал Роберт, постарайтесь показать пример. Если возможно, позвольте им перенять ваш образец.
Это основная причина, по которой установление стандартов кодирования и процессов проверки кода является хорошей идеей.
Я не буду писать трехстраничные функции, независимо от того, какие стандарты и процессы кодирования установлены, но некоторые люди сделают это. Вначале они создадут 20 локальных переменных, не инициализируя ни одну из них. У вас будут указатели и целые числа с неопределенными значениями. Вы не узнаете точное значение и объем каждой переменной. И т. Д. И т. Д.
Постарайтесь убедить своего менеджера, а затем и свою команду, с помощью веских аргументов. Может быть, вы могли бы начать с общего чтения Эффективного C ++ или Стандартов кодирования C ++ . Постарайтесь подчеркнуть, что, работая таким образом и создавая лучший код, выигрывают все. Если они увидят в этом беспроигрышную ситуацию, они будут более открыты для перемен.
Настоящее воплощено в гексаграмме 47 - К'ун (Угнетение): Несмотря на истощение, прогресс может быть и успех. Для твердого и правильного , действительно великого человека, будет удача. Он не ошибется. Если он произносит речи, его слова не могут быть исправлены .
Будущее воплощено в Гексаграмме 6 - Сун (Конфликт): Хотя в чьем-то утверждении есть искренность , он будет все же встречаются с оппозицией и препятствиями . Если он будет лелеять опасения , то будет удача. Если он доведет дело до конца, будет зло. Будет выгодно увидеть великого человека. Пересечь большой ручей будет невыгодно.
Вы не одиноки. Я тоже недавно столкнулся с этим, к счастью, у нас есть поддержка со стороны высшего руководства для проверки кода. 1. Даже одно изменение строки для исправления ошибки должно быть проверено в Интернете.
Комментарии к коду можно классифицировать как CodingStandard / Suggestion / Clarification / Major / Minor и т. Д.
Давая комментарии руководству, вы можете начать с Clarification / CodingStandard а не Major
Быть энтузиастом правильного кодирования - это хорошая черта, которой нужно обладать, и в индустрии программного обеспечения мы всегда будем сталкиваться с другими разработчиками, которые пишут код, который не совсем соответствует нашему "идеальному способу" кодирование. Это никогда не следует интерпретировать как мусорный код или неумелые кодеры, потому что все мы начинаем так в той или иной форме или форме.
Всегда уважайте своих сверстников вокруг вас, как хотите они уважают вас. Это, конечно, нелегко сделать в среде, которая высоко ценит эго, но попытка подойти к такой теме никогда не бывает легкой.
Это то, как вы общаетесь
Попробуйте разные подходы, помните, что вы здесь, чтобы узнать столько, сколько оказать услугу.
Итак, комментируя «плохой» стиль кода в «в лицо» Такой подход может оказаться не тем результатом, которого вы искали. Так что затем сделайте резервную копию и попробуйте подойти к теме с помощью «Я рассматривал стиль используемого кода, и у меня есть несколько предложений ...» и посмотрите, какая разница.
Где я сейчас работаю , единственное, что я узнал, это то, что можно комментировать то, что может быть не хорошего качества, но тогда мне лучше представить лучшее решение.
Другими словами, будьте готовы подкрепить свои слова полезных решений, а не потому, что вы так считаете.
Я могу сочувствовать.
Я ниже двух старших программистов, у которых есть очень уникальные стили, которые меня расстраивают. У нас есть код, состоящий из одной основной функции длиной в 1000 строк. (Это не опечатка.) Наши стандарты кодирования не одобряют глобальные переменные, поэтому мы делаем каждую программу одним объектом App. Теперь наши глобальные переменные являются переменными-членами! Когда нам нужен итерационный интерфейс для классов C ++, почему мы должны использовать соглашения begin , end и operator ++ , когда First , Вместо этого можно использовать AtLast и Next . Мы обернули сторонние библиотеки в пользовательские интерфейсы без уважительной причины. (Мы обернули log4cxx и потеряли функциональность по неизвестной мне причине, а один из наших классов даты состоит из общего указателя на boost :: date с небольшой долей функциональности.)
Вот как я сохранил рассудок. Я сосредоточился на новых языках и инструментах. Это первый проект нашей компании с использованием Python, и я тратил время на написание утилит и программ для него. Пока старшие программисты пишут то, с чем они знакомы, у меня почти полная свобода действий со всем кодом Python. Я терпеть не мог API-интерфейсы C ++, которые мы используем, поэтому я продублировал большую часть тех же функций в Python гораздо более дружественным образом, и другие разработчики тоже предпочитают его.
Точно так же мы мало знакомы с log4cxx и меньше - с boost-build, оба из которых я потратил на изучение и достаточно хорошо знаю, чтобы люди обращались ко мне с вопросами. Я написал несколько ресурсов на нашей вики, в которых даются советы по использованию log4cxx, numpy и других инструментов.
Вы можете решить проблему «мы боимся прикоснуться к нему из-за страха сломать», написав обширные модульные тесты. После того, как вы подготовите модульные тесты, вы сможете произвольно провести рефакторинг. Если ваши модульные тесты все еще проходят после рефакторинга, можете быть уверены, что ничего не сломали.
Просто поместите копию «Чистого кода» (Мартин), «Рефакторинг: улучшение дизайна существующего кода» (Фаулер) или «Эффективный C ++» где-нибудь в офисе, где люди могут начать просматривать книги. Отныне слухи будут распространяться. Серьезно, учиться никогда не поздно! ;)
Я был в точно такой же ситуации. Меня наняли в качестве программиста на C++, чтобы я "подвел команду" к тому, как использовать C++, менеджер-энтузиаст. Это было около десяти лет назад. Некоторые из новых инженеров любили меня, а старшие презирали. Наша система была по сути псевдо-С++ системой. Это было похоже на C с классами, но, похоже, люди даже не понимали полезности таких вещей, как конструкторы, поскольку они почти не появлялись.
Вы жалуетесь на функции длиной в 3 страницы; у нас были функции длиной в 8000 строк, полные длинных переходов, приведения указателей функций и т.д. Один из старшекурсников даже отформатировал код с отступами в 2 пробела, чтобы можно было писать сверхглубокие вложенные блоки, не используя много горизонтального пространства, поскольку у старшекурсников, похоже, была аллергия на написание функций и процедурное программирование в целом. Кто-то даже вставил функцию в 2000 строк, думая, что это ускорит работу. Возможно, вы имеете дело с плохим кодом, но я имел дело с самым ужасным кодом copy-and-paste, который только можно себе представить.
К сожалению, я был очень молод и самоуверен. Я не ладил со старшими, я сражался с ними в территориальных битвах за код. В ответ они создали стандарты кодирования, которым не мог следовать ни один здравомыслящий программист на C++ (например: можно использовать оператор new, но не использовать обработку исключений, не использовать конструкторы и деструкторы и т.д.). В результате я писал самый странный и глупый код на C++, обходящий стандарты, просто чтобы как бы восстать против этих стандартов, поскольку я отказывался писать код в стиле C, учитывая причину, по которой меня взяли на работу (я не так уж сильно ненавидел C, но написание кода на C не входило в должностные обязанности: Меня наняли, по сути, как консультанта по C++), даже несмотря на то, что стандарты делали кодирование в стиле C единственным практическим способом делать вещи. Я сохранил свою работу только потому, что много работал сверхурочно, чтобы убедиться, что мой код работает очень хорошо, несмотря на эти нелепые стандарты кодирования".
Только спустя годы, когда другие начали смотреть на вещи по-моему, мы отменили глупые стандарты и начали писать более естественный, легко читаемый код на C++, дополненный STL и boost, RAII, обработкой исключений и т. д. Это изолировало старшекурсников, которые отказывались писать код в более разумной манере, и они, наконец, были вынуждены адаптироваться".
Оглядываясь назад, я мог бы сделать все гораздо лучше. Старшекурсники были намерены не допустить, чтобы меня поставили на преподавательскую должность, но я думаю, что с опущенной головой я бы гораздо быстрее донес свою точку зрения. Самое большое мое сожаление - это попытка обойти невозможные стандарты кодирования, вместо того чтобы добиваться их исправления путем ясного и рационального обсуждения. В результате у меня в системе есть действительно глупый и запутанный код на C++, который люди приписывают мне, хотя я обычно пишу код на C++ не так. Обычные разработчики, с которыми я работаю, понимают это, но старшие все равно указывают на это как на пример того, почему C++ плох".
Короче говоря, я рекомендую вам сосредоточиться на том, чтобы завести больше друзей, а не врагов. Ваши друзья будут поддерживать вас, и если ваш способ лучше, и вы можете ясно продемонстрировать это, вы сможете изолировать тех немногих, кто никогда не согласится.