Как бороться со стилем/практикой плохого кодирования пожилых людей?

Ответ 1

Лучшее и самое важное, что вы можете сделать, это привести пример. Делайте все правильно и старайтесь медленно улучшать. Вы ничего не исправите за одну ночь.

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

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

Вкратце: это будет сложно и сложно, но это возможно. Удачи.

Ответ 2

Лучше всего не обращаться с ним вообще. Вот потенциальные проблемы, если вы попытаетесь:

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

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

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

Ответ 3

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

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

Действия говорят громче, чем жалобы, что я заметил.

Ответ 4

Настоящее воплощено в гексаграмме 47 - K'un (Угнетение): несмотря на усталость, может быть прогресс и успех. Для фирмы и правильного, действительно великого человека, будет удача. Он не ошибся. Если он произносит речи, его слова не могут быть хорошими.

Будущее воплощено в гексаграмме 6 - Sung (Conflict): хотя в одном утверждении есть искренность, он все же встретится с оппозицией и препятствием. Если он бережет опасную осторожность, будет удача. Если он преследует спор к горькому концу, будет зло. Будет полезно увидеть великого человека. Не будет выгодно пересекать большой поток.

Ответ 5

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

Вы жалуетесь на функции длиной 3 страницы; у нас были функции, длина которых составляла 8000 строк, длинные прыжки, функции-указатели функций и т.д. Один из старших даже отформатировал код с 2-пространственными углублениями, чтобы супер глубоко вложенные блоки могли быть написаны без использования большого горизонтального пространства, так как старшие казались аллергия на письменные функции и процедурное программирование в целом. Кто-то даже включил функцию линии 2000, думая, что это ускорит работу. Возможно, вы имеете дело с каким-то плохим кодом, но я имел дело с самым ужасным кодом для копирования и вставки, который можно себе представить.

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

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

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

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

Ответ 6

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

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

Как вы общаетесь

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

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

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

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

Ответ 7

Это самая основная причина, по которой создание стандартов кодирования и процессов проверки кода - хорошая идея.

Я не буду писать три функции страницы независимо от того, какие стандарты и процессы кодирования установлены, но некоторые люди будут. Они будут создавать 20 локальных переменных в начале, без инициализации ни одного из них. У вас будут указатели и целые числа с неопределенными значениями. Вы не будете знать точного значения и объема каждой переменной. Etc и т.д.

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

Ответ 8

Я могу сопереживать.

Я ниже двух старших программистов, у которых очень уникальные стили, которые я нахожу расстраивающими. У нас есть код, который состоит из одной основной функции, длина которой составляет 1000 строк. (Это не опечатка.) Наши стандарты кодирования препятствуют глобальным переменным, поэтому мы делаем каждую программу одним объектом App. Теперь наши глобальные переменные являются переменными-членами! Когда нам нужен итерационный интерфейс для классов С++, почему мы должны использовать соглашения begin, end и operator++, когда вместо First, AtLast и Next можно использовать. Мы внедрили сторонние библиотеки в пользовательские интерфейсы без уважительной причины. (Мы обернули log4cxx и потеряли функциональность без причины, я могу сказать, и один из наших классов дат состоит из общего указателя на объект boost:: date с долей функциональности.)

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

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

Ответ 9

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

Не все компании такие. Я бы начал искать новую работу, если честно.

Ответ 10

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

Ответ 11

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

2. Комментарии к коду могут быть классифицированы как CodingStandard/Suggestion/Clarification/Major/Minor и т.д.

3. Предоставляя комментарии старшим, вы можете начать с Clarification/CodingStandard, а не Major

Ответ 12

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

Ответ 13

Просто разместите копию "Чистого кода" (Martin), "Рефакторинг: улучшение дизайна существующего кода" (Fowler) или "Эффективный С++" где-нибудь в офисе, где люди могут начать просмотр книг. С этого момента слово будет распространяться. Серьезно, никогда не поздно учиться!;)