Допомогти молодшим програмістам подолати свої недоліки? [зачинено]

Які ваші загальні поради щодо молодших розробників, які приєднуються до вашої команди або з якими вам доведеться працювати? Очевидно, що вони недосвідчені, тому ви не можете очікувати, що вони все знають, але яких навичок часто незрозуміло не вистачає - і як, зокрема, ми можемо допомогти їм у формуванні цих відсутніх навичок?

Я не маю на увазі міжособистісні навички, такі як "слухати поради", я маю на увазі технічні питання на кшталт (якщо застосовується):

• "Ви ніколи не робили SQL?"

• "ти ніколи не писав одиничний тест?"

• "Ви не знаєте, як використовувати командний рядок Unix?"

Речі , які ви б очікувати , - я хотів би почути ваші зауваження і методи для навчання нових програмістів , щоб отримати повз цих конкретних недоліків.

Не знаючи, що таке управління версіями, або як правильно ним користуватися .

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

Не задаючи достатньо питань

Я знаю, що вони юніори, сподіваюся, що вони помиляться і просто не знають речей. Стільки королівських f ** k ups можна було уникнути, просто задавши питання, а не припускаючи щось. Чесно кажучи, я не можу бути достатньо скутим.

У мене виникли TONNES запитань, коли я починав - задаючи їх, рятував мою дупу. Чорт, у мене ще багато запитань ... Мені просто подобається вважати, що вони зараз кращі.

Скопіюйте пасту, випробування та помилки, а не намагайтеся зрозуміти основні основи

Багато молодших розробників скопіюють код, який виглядає близько, а потім майже випадковим чином спробують різні перестановки модифікацій грубою силою, поки вони не потраплять на той, який працює. Якщо ви не знаєте, чому це працює, швидше за все, ви вводите помилки в прикордонних випадках, коли хтось, хто це розуміє, повинен буде прибрати пізніше.

Зберігаючи свій "перший проект" коду

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

Молодші розробники мають тенденцію писати це в один великий шматок, а потім робити масивну грубу силу налагодження. Їм не подобається видаляти рядок коду, як тільки він набирається в редактор, і вони такі щасливі, що нарешті змусили його працювати, що їм неприємно переписувати для нефункціональних вдосконалень, але саме вони повинні зробити тому найбільше.

Вважаючи, що ви вперше зіткнулися з ситуацією.

Кожна проблема програмування, з якою ви стикаєтеся, стикалася з іншими, у деякій загальній формі. Є чому багато чому навчитися досвідченим програмістам. Я досить стара, щоб запам'ятати програмування перед 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) ... uhm ... 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;
        }
            }

Розчарування, чи не так?