Как поощрить позитивное поведение разработчика с IDE?

Question

Целью IDE является повышение производительности. Они делают большую работу в этом. Рефакторинг, навигация, встроенная документация, автозаполнение помогают значительно повысить производительность.

Но: Каждый инструмент - это оружие . Сама же IDE помогает создавать чанк-код. Некоторые функции IDE - приглашение создавать плохой код: генерация кода, инструменты форматирования кода, инструменты рефакторинга.

Чрезмерное использование IDE, как правило, изолирует разработчиков от необходимых деталей. Это хорошо, что вы можете начать работать , но в какой-то момент вашей карьеры вы должны быть в состоянии понять, как начать процесс. Вы можете игнорировать эту деталь в течение некоторого времени, в конце концов, они важны для написания работающего продукта (вместо того, чтобы соединить все вместе, что работает в 90% случаев).

Как вы поощряете позитивное поведение других разработчиков, работающих с IDE? Этот вопрос старый, как копирование и вставка.

Чтобы получить правильное впечатление: разработчики должны иметь максимальную свободу мобилизации своего максимального творческого потенциала и мотивации . Они могут использовать IDE и все связанные инструменты по своему усмотрению. Никто не должен навязывать им драконовские меры. Я не хочу демотивировать и заставлять кого-то что-то делать. Хорошее поведение должно поощряться. Это должно немного зудеть, если ты поступаешь неправильно. В той же строке, что и SO, показатель «принимаемая ставка» (и репутация). Вы можете игнорировать это, но жизнь станет лучше, если вы будете следовать правилам .

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

Answer 1

Тренируйте свою IDE, а не обучайтесь ей.

Настройте форматирование кода так, как вы (или ваша команда) хотите. Черт возьми, даже отключите его в тех случаях, когда это имеет смысл. Я никогда не видел, чтобы IDE выровнял что-то вроде этого с разумной комбинацией символов табуляции и пробелов (где \t, очевидно, символ табуляции):

{
\tcout << "Hello "
\t     << (some + long + expression +
\t         to_produce_the_word(world))
\t     << endl;
}

В таких языках, как Java, вы не можете избежать шаблонов. Лучший вариант - проверить сгенерированный код, убедившись, что он совпадает с тем, что вы написали от руки. Измените его по мере необходимости. Сконфигурируйте вашу IDE для генерации точного кода, который вам нужен, если это возможно. Затмение довольно хорошо в этом.

Answer 2

Я думаю, что прежде чем кто-либо использует инструмент RAD любого типа, он должен иметь возможность писать приложение с нуля (с нуля, соединяя компоненты каркаса) в блокноте, потенциально на компьютере, который на 10 лет старше текущей технологии: P. Незнание тонкостей парадигмы / фреймворка приводит к плохому коду от начинающих разработчиков, которые изучают вещи только с точки зрения платформы, для которой они разрабатывают. Возможно, они должны сделать это в нескольких технологиях - то есть, программирование GTK полностью отличается от MVC, которое тогда также отличается от SWING и .NET.

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

Answer 3

Знайте, что происходит под капотом.

Знайте, что ваша IDE фактически вызывает компилятор. Имейте некоторое представление о флагах, которые это передает. Уметь вызывать компилятор из командной строки.

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

Answer 4

Попытка разработки (хотя бы изредка) с использованием только текстового редактора и запуска компиляции, тестирования и т. Д. Из командной строки.

Ввод команд очень быстро утомителен, поэтому создайте сценарии или (еще лучше) выучите rake, ant, msbuild.

Если IDE выполняет генерацию кода для вас, и генерация кода действительно важна (например, генерация классов из xsd или прокси-классов из wsdl), попробуйте выяснить, как запустить генерацию кода из командной строки - затем подключите генерация кода в сборку (поэтому вы никогда не будете испытывать желание редактировать сгенерированный код).

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

Добавление инструментов качества кода в ваши проверки в стиле сборки, размеры классов и методов, сложность, дублирование кода, покрытие тестами и т. Д. (Complexian, simian, flog, flay, ndepend, ncover и т. Д.) Будут препятствовать сгенерированному IDE-коду.

Answer 5

это открытый вопрос, но ...

У нас есть файл формата Eclipse, которым все делятся, поэтому мы все отформатируем код в одной и той же усадьбе. (За исключением одного одинокого парня из InteliJ, который у нас есть).

Каждый публикует файл словаря. Это помогает удалить все красные линии из кода. Сделать его более чистым и читаемым.

Я запускаю EMMA поверх кода, чтобы выяснить, кто не тестирует их код, а затем стону на них.

Основные проблемы, с которыми мы сталкиваемся, заключаются в том, что большая часть команды не знает всех функций / возможностей IDE (затмение). Не знал ни о CTRL + O (дважды), ни об автоматическом коде gen. Все, что я могу сделать как «мастер горячих клавиш», - это делиться с ними своими знаниями, чтобы помочь им стать более продуктивными.

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