Помогаете младшим программистам преодолеть их недостатки? [закрыто]

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

Я не имею в виду межличностные навыки, такие как «выслушивание совета», я имею в виду технические вопросы, такие как (если применимо):

• 'Вы никогда не делали SQL?'

• 'Вы никогда не писали юнит-тест?'

• 'Вы не знаете, как использовать командную строку Unix?'

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

Не зная, что такое контроль версий или как правильно его использовать .

Один из младших разработчиков, который недавно работал в моей компании несколько месяцев, должен был научиться самым основам Subversion. Это действительно заставило меня съежиться ... она все время проверяла код для живых проектов ... и понятия не имела, что она делает ...?

Не задавая достаточно вопросов

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

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

Скопируйте вставку и метод проб и ошибок вместо того, чтобы пытаться понять основные принципы

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

Сохраняя свой «первый черновик» кода

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

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

Полагая, что вы первый столкнулись с ситуацией.

С любой проблемой программирования, с которой вы сталкиваетесь, сталкиваются другие в некоторой общей форме. У опытных программистов есть чему поучиться. Я достаточно взрослый, чтобы помнить программирование до Google, и это отстой . Еще хуже было, когда у нас были поисковые системы, но в Интернете еще не было так много хорошей информации. Программирование теперь намного продуктивнее, потому что у вас есть доступ к глобальным знаниям за считанные секунды. Люди, которые не используют его, игнорируют его на свой страх и риск.

Редактировать :

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

Думая, что они все знают.

У меня был младший стажер, который пытался решить все с помощью JavaScript. Пытался объяснить несколько понятий, но он всегда думал, что может сделать это лучше. Теперь он закрыл и перерабатывает основную программу, которую он создал для вывода на печать, используя HTML вместо технологии, готовой к печати, такой как PDF. Не говоря уже о куче других серьезных проблем.

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

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

Не желая продвигать свои знания - вместо этого они идут по пути наименьшего сопротивления.

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

Я сел с стажером и объяснил, что именно не так и почему. Мы исправили ошибку, затем я указал на несколько дополнительных улучшений («так как я здесь»), и в итоге мы переписали функцию виновности в 10 строк вместо 20 и без ошибок. Отвечая на любые вопросы, убедившись, что в мире снова все в порядке, я ушел.

На следующий день стажер пришел с вопросом, который показал, что он «хочет внести некоторые изменения и переписал эту функцию по-моему, потому что мне было трудно это понять» (по большей части отмена моих улучшений).

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

Не понимая ООП. К сожалению, это гораздо чаще, чем большинство из нас, вероятно, осознают.

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

Если вы хотите избежать этого, я нашел эти вопросы и ответы на них поучительными:

• Запах кода: Наследственное насилие - Опасность наследования
• Откуда взялась эта концепция «отдавать предпочтение композиции перед наследованием»? - Опасности мантр об уходе от наследства

Не зная, чего не знаешь, и в неведении думая, что ты знаешь все.

(И его близкий двоюродный брат, не желая спрашивать.)

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

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

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

Напишите код, который вычисляет N-е число Фибоначчи .

Они почти всегда идут на большинство, пишут очевидное, но неэффективное

int Fib(int n)
{
    if (n == 0) return 0;
    if (n == 1) return 1;
    return Fib(n-2) + Fib(n-1);
}

Когда меня просят прокомментировать алгоритмическую сложность, я обычно получаю «это хуже, чем O (N) ... хм ... O (N logN)». Это на самом деле (гораздо) хуже, чем это ...

Делать обратный код отступа!

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

try {
    switch(action){
        case case1:
            ...
            break;
        case case2:
            ...
            break;
        default:
            break;
    }
}
catch(Exception e) {
    e.printStackTrace();
}

она написала бы как (Боже, это все еще кажется мне невозможным!)

            try {
        switch(action){
    case case1:
...
break;
    case case2:
...
break;
    default:
break;
        }
            }

Разочарование не так ли?