Как преобразовать программистов COBOL в современных программистов

Ответ 1

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

Запрет на то, чтобы все читали Code Complete.

Ответ 2

Купите им копию "Code Complete" и попросите их написать отчет о книге.

Ответ 3

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

• Очень длинные методы. Смотрите, я посмотрел на ваш длинный метод и понял, что вы используете одну и ту же логику в двух местах. Я сломал это, и теперь вам не нужно вводить один и тот же код два раза. Кроме того, нам нужно только один раз проверить эту часть.
• Глобальные переменные и множество определений в начале каждого метода. См., я переместил ваши переменные ближе к их точке использования. Теперь этот тестовый код, который я написал о том, что побочные эффекты вашего кода с нулевым указателем, убивающим систему, не может оказать побочное воздействие на мою.
• Гигантский переключатель. Иногда гигантский переключатель очень трудно избежать (а иногда и не стоит). Тем не менее, если вы пытаетесь построить объект, говорит слово "factory". См. Мой метод factory эффективно выполняет то же самое, что и ваш factory, но я допускаю, что полиморфизм (например) заменяет некоторые из методов управления коммутатором. Меньше кода = меньше ошибок = мы возвращаемся домой вовремя.

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

Ответ 4

Мое осознание того, что, возможно, никогда не было встречи разума между мной и программистами COBOL, появилось много лет назад, когда я преподавал курсы коммерческого обучения на C и С++. Я только что закончил раздел курса по malloc() и free(), к общему удовлетворению большинства игроков, когда один парень COBOL на курсе пришел и спросил:

"Но что это за" память "? И почему я когда-нибудь захочу его использовать?"

Чтобы быть немного более конструктивным, опыт состоит в том, что программисты COBOL были обучены думать о двух вещах:

• запись
• вещи, которые вы делаете с записью

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

Ответ 5

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

Ответ 6

Как и Code Complete (возможно, после этого), попросите их прочитать Рефакторинг: Улучшение дизайна существующего кода (по крайней мере, введение). В нем рассматриваются как стандартные запахи кода, так и способы их исправления.

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

Ответ 7

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

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

• Это работает? Если то, что они делают, работает, без каких-либо проблем, чем ваш код, и они могут поддерживать его так легко, как вы можете, то это может быть просто предпочтительным. Если это не так, то вы можете указать на свой код и сказать: "Это было проще в обслуживании, посмотреть, как это займет всего 30 минут, и у него не было проблем?" Не пытайтесь втирать носы в него, но приводите пример. Гораздо лучше сказать "посмотри, как это сработало для меня", чем "ты должен сделать это так, потому что это что-то для тебя".
• Могут ли все это понять? Программирование с помощью новейших самых сложных методологий может показаться классным, но если половина команды не сможет отлаживать ваш код, не введя дважды ошибки, это потому, что они просто не знают, как этот способ выполнения вещей должен работать. Убедитесь, что вы не вводите новые вещи быстрее, чем команда может их усвоить. Это может усугубить ситуацию, когда вы не используете LINQ или что-то новое, но это правильный шаг для компании.
• Нужно ли это? ПОЦЕЛУЙ. Или как Альберт Эйнштейн был перефразирован: "Все должно быть сделано максимально простым, но не проще".

Ответ 8

Вы можете заставить их начать работать над хорошим кодом? Выполнение небольших изменений?