후배 프로그래머가 결점을 극복하도록 돕는가? [닫은]

팀에 합류하거나 함께 작업해야하는 주니어 개발자에 대한 일반적인 장점은 무엇입니까? 분명히 그들은 경험이 없어서 모든 것을 알기를 기대할 수는 없지만, 어떤 기술이 종종 설명하기 어려운 것이 있습니다.

나는 '조언에 귀를 기울이는 것'과 같은 대인 관계 기술을 의미하는 것이 아니라 다음과 같은 기술적 문제를 의미합니다.

• '당신은 SQL을 한 적이 없다?'

• '단위 테스트를 한 적이 없습니까?'

• '유닉스 명령 줄 사용법을 모른다?'

당신 이 기대 하는 것-나는 새로운 프로그래머에게 이러한 특정 단점을 극복하도록 가르치는 당신의 관찰과 기술을 듣고 싶습니다.

버전 관리가 무엇인지, 올바르게 사용하는 방법을 모르는 경우 .

최근 몇 달 동안 회사에 근무한 주니어 개발자 중 한 명이 Subversion의 매우 기본적인 내용을 배워야했습니다. 정말 울부 짖었습니다. 그녀는 코드를 확인하여 하루 종일 프로젝트를 진행하고있었습니다. 그녀가 무엇을하고 있는지 전혀 몰랐습니다.

충분한 질문을하지 않음

나는 그들이 후배라는 것을 알고 있습니다. 나는 그들이 실수를하고 물건을 알지 못할 것으로 기대합니다. 그래서 무언가를 가정하는 대신 질문을함으로써 많은 왕실의 업을 피할 수있었습니다. 솔직히 말해서, 나는 충분히 귀찮게 할 수 없습니다.

나는 시작할 때 많은 톤 의 질문을했다. 지옥, 나는 아직도 많은 질문을 가지고 있습니다 ... 나는 그들이 더 나은 질문이라고 생각하고 싶습니다.

기본 원리를 이해하려고하는 대신 붙여 넣기 및 시행 착오를 복사하십시오.

많은 주니어 개발자들은 가까이서 보이는 코드를 복사 한 다음 작동하는 코드에 부딪 칠 때까지 무차별 대입 방식으로 수정의 다른 순열을 거의 무작위로 시도합니다. 왜 그런지 모른다면 작동 경우 경계를 이해하는 사람이 나중에 정리해야 할 버그가 발생할 가능성이 있습니다.

코드의 "첫 번째 초안"유지

숙련 된 개발자가 특정 복잡성의 새로운 기능을 작성하면 컴파일 만하는 스텁으로 시작한 다음 전체 알고리즘에 대한 상위 의사 코드 주석을 추가하기 위해 다시 작성하고 다음과 같이 주석을 다시 작성합니다. 실제 코드, 테스트에 필요한 더미 코드 추가 및 제거를 수행 한 다음, 구현 중에 발생한 중복성을 제거하기 위해 다시 작성하는 등 일련의 연속적이고 점진적인 개선이 이루어집니다.

주니어 개발자는 하나의 큰 덩어리로 작성하는 경향이 있으며, 거대한 무차별 대입 디버깅을 수행합니다. 편집기에 코드를 입력하면 코드 줄을 삭제하는 것을 좋아하지 않으며 결국 기능이 향상되지 않은 상태로 다시 작성하는 것을 싫어하기 때문에 작동하게되어 기쁩니다. 그래서 가장.

당신이 가장 먼저 처한 상황이라고 생각하십시오.

당신이 직면하는 모든 프로그래밍 문제는 다른 일반적인 형태로 직면했습니다. 숙련 된 프로그래머로부터 많은 것을 배울 수 있습니다. Google 이전의 프로그래밍을 기억할만큼 나이가 들었습니다 . 우리가 검색 엔진을 가지고 있었을 때 더 나빴지 만 웹에는 아직 그다지 좋은 정보가 없었습니다. 몇 초 만에 글로벌 지식에 액세스 할 수 있으므로 프로그래밍이 훨씬 더 생산적입니다. 그것을 사용하지 않는 사람들은 위험에 처해 있습니다.

편집 :

분명히하기 위해, 나는 복사 / 붙여 넣기 프로그래밍을 옹호 하지 않습니다 . 그러나 올바른 결정을 내리기 전에 기존 지식을 검토해야합니다.

그들이 모든 것을 알고 있다고 생각합니다.

나는 jr를 가지고 있었다. 자바 스크립트로 모든 것을 해결하려고 노력한 인턴. 몇 가지 개념을 설명하려고 노력했지만 항상 더 잘 할 수 있다고 생각했습니다. 이제 그는 PDF와 같은 인쇄 준비 기술 대신 HTML을 사용하여 인쇄 출력용으로 구축 한 주요 프로그램을 종료하고 재 작업하고 있습니다. 다른 주요 문제는 말할 것도 없습니다.

수업은 프로젝트 초기에 노인들에게 주요한 중요한지도를 요청하는 것입니다. 도움없이 건축가를 떠나지 마십시오. 코드와 세부 정보 만 작성할 수 있지만 최소한 올바른 기술을 사용해야합니다.

후배가 기초를 알지 못할 때 거의 화가 나지 않으며 대학의 SCC와 같은 산업 기술을 배우지 못합니다. 그들을 가르치는 것은 수석 개발자 일입니다. 나는 성격의 충돌에 의해서만 화가 난다. 그러나 나는 기본을 모르는 선임 개발자들에게 가장 화가납니다.

저항을 최소화하기 위해 지식을 발전시키고 싶지 않습니다.

전날 그래픽 디자이너 (놀랍게도 프로그래밍에 능숙 함)와 함께 인턴이 jQuery에서 무언가를 구현하는 데 어려움을 겪어 도움을 요청했습니다. 닫을 수 없다면 클로저는 고통 스러울 수 있습니다.

나는 인턴과 함께 앉아서 무엇이 잘못되고 있는지 정확히 설명했습니다. 우리는 버그를 수정 한 다음, 몇 가지 추가 개선 사항 ( "여기에 있기 때문에")을 지적했으며 20 개가 아닌 10 줄로 버그가없는 유죄 기능을 다시 작성했습니다. 질문에 대답 한 후 세상의 모든 것이 한 번 더 정상이라는 것을 만족시키면서 떠났습니다.

그 다음날 인턴은 "음, 이해하기가 어려워서 약간의 변경을하고 기능을 다시 작성하고 싶다"는 질문을 받았습니다.

그는 대신 더 많은 노력을 기울 였을 수도있다 (추가 질문을하고 언급 한 개념을 읽음). 너무 짧은 코드 는 이해하기 가 어려울 수 없다 . 누군가 후자를 볼 때마다 슬퍼합니다.

OOP를 이해하지 못합니다. 슬프게도 이것은 대부분의 사람들이 알고있는 것보다 훨씬 일반적입니다.

클래스를 생성하는 방법, 추상 클래스, 인터페이스 또는 다형성을 아는 것은 하나의 일입니다. 프로그램의 이익을 위해 그것들을 올바르게 사용하는 방법을 이해하는 것은 또 다른 것 입니다.

이 질문을 피하고 싶다면 다음 질문과 그에 대한 답변이 깨달았습니다.

• 코드 냄새 : 상속 남용 — 상속의 위험
• "상속보다 선호되는 구성"이라는이 개념은 어디에서 유래합니까? — 상속을 피하는 것에 대한 진언의 위험

당신이 모르는 것을 모르고 무지한 생각으로 당신은 모든 것을 알고 있습니다.

(그리고 그 사촌은 묻고 싶지 않다.)

부분적으로 이것은 조직적인 것입니다-적절한 들어오는 유도는 이러한 것들 중 일부가 문제가되는 것을 막기 위해 먼 길을 갈 것입니다. 그러나 들어오는 유도에 사용할 수있는 시간이나 인력을 보유한 회사는 거의 없습니다. 며칠에서 몇 주가 걸리고 개발자가 작업을 수행하지 못하게해야합니다. 그래서 우리는 대신 불을 꺼야합니다.

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;
        }
            }

답답하지 않습니까?