Как преобразовать программистов КОБОЛа в современных дневных [закрытых] программистов

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

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

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

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

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

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

«Но что это? память? И зачем мне ее использовать? »

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

• записывать
• вещи, которые вы делаете do to the record

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

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

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

Сможете ли вы как-нибудь заставить их работать над хорошим кодом? Делаете небольшие изменения?