직책을 수행하기 전에 잠재적 고용주 코드의 품질을 어떻게 확인합니까? [닫은]

회사에서 일을 시작하기 전의 경험에서 코드베이스를 볼 기회가 없었습니다. 코드가 어떤 상태에 있는지 묻는 가장 중요한 질문이라고 생각하십니까 (결국 개라면 매일 걸어야하는 가난한 불행한 사람이 될 것입니다)?

최신 정보:

점검 목록 : 질문;

• 어떤 이들은 코드베이스 생각합니다. 그리고 당신이 할 때, 얼굴 표정과 반응에 걸리는 시간에 세심한주의를 기울이십시오. [곧]
• 회사의 CMM 레벨 [DPD]는 무엇입니까 (그리고 레벨 5가 다른 방식으로 실행되는 경우 [Doug T])
• 그들이 사용하는 수명주기 [DPD] (그리고 "애자일"이 들리면, "애자일"에 의해 "애자일"또는 "카우보이 코딩"[Carson63000]을 의미하는지 알아 내기 위해 약간의 침투성 질문을하기 시작할 때입니다.)
• 코드 품질을 평가하기 위해 어떤 도구를 사용합니까? [DPD]
• 개발에 어떤 도구를 사용합니까? [DPD] (리팩토링 도구 및 지속적인 빌드 서버를 찾으십시오)
• 그들이 사용하는 소스 코드 (버전 제어) 시스템은 무엇이며 그 이유는 무엇인지 묻는 것입니다. [Zachary K].
• 테스트 절차는 어떻습니까? [Karl Bielefeldt] (특히 모의 프레임 워크를 사용하고 NUnit / JUnit과 같은 기존 프레임 워크를 통한 철저한 자동화 된 단위 테스트에 중점을 둔 팀을 찾으십시오. 테스트 중심 개발 TDD를 사용하지 않는 팀은 연기하지 마십시오. 테스트가 견고한 소프트웨어 개발의 필수 요소라고 생각하지 않는다면주의하십시오. 전용 테스터가있는 팀을 찾으십시오.)
• 새로운 개발자에게 어떤 종류의 과제가 부여됩니까? 숙련 된 개발자에게? [칼 빌레펠트]
• 한 프로젝트에서 몇 사람이 일합니까? [칼 빌레펠트]
• 리팩토링이 허용됩니까? 격려? [칼 빌레펠트]
• 어떤 품질 관련 프로세스 또는 아키텍처 변경이 고려되고 있거나 최근에 이루어 졌습니까? [칼 빌레펠트]
• 개인이 모듈에 대해 얼마나 많은 자율권을 가지고 있습니까? [칼 빌레펠트]
• 새로운 프로젝트 (그린 필드 개발) 또는 레거시 프로젝트 (브라운 필드 개발)를 개발할 예정입니까? (그린 필드 개발은 일반적으로 더 재미 있고 다른 사람의 실수로 정리하지 않기 때문에 문제가 적습니다).
• 조직 또는 팀에서 직원 이직률이 높습니까? (이는 종종 코드 품질이 낮음을 나타냅니다) [M.Sameer]
• 자신 만의 프로그래밍 문제; 그러나 바보처럼 보이지 마십시오. [스파키]
• 개발자는 어떻게 협업하고 팀간에 지식은 어떻게 공유됩니까? (이것은 당신의 성격과 일치해야합니다. 나는 솔로와 페어 작업의 혼합이 아마도 사회적 요구에 맞는 비율로 최고라고 말할 것입니다)
• 데이터베이스가 3NF (3rd Normal Form)에 얼마나 가깝고 어디에서 왜 벗어난가? ( "3NF ???"라고 말하면 그대로 두십시오. 그렇지 않은 경우에는 그 이유가 없을 수 있습니다.)

참고 : 나는 약 1 주일 후에 커뮤니티가 최고의 커뮤니티라고 생각하기 때문에 Anon의 대답을 받아 들였습니다. 그러나 나는 모든 사람들이 말할 가치가 있다고 생각합니다.

코드를 보도록 요청하는 대신 코드베이스에 대해 어떻게 생각하는지 물어보십시오. 그리고 당신이 할 때, 얼굴 표정과 반응에 걸리는 시간에 세심한주의를 기울이십시오.

그런 다음 문화의 비언어적 제스처에 대한 지식을 적용하여 실제로 말하는 내용을 해석하십시오. 북미 회사의 경우 다음이 정확해야합니다.

• 작은 어깨를 으,하고 "더 좋을 수있다"는 빠른 반응 : 아마 꽤 좋을 것입니다.
• 오래 멈추고 숨을들이 쉬고 약간의 웃음이있을 수 있습니다. 기분이 좋지 않으며, 인터뷰하는 사람들은 그 말을하는 것이 편하지 않습니다.
• 구르는 눈, "빨리"의 빠른 반응 : 좋을 수도 있고 나쁠 수도 있지만, 정치적 게임이 일어나고 있습니다. 당신이 그 게임을하거나 조용한 사람이 될 준비가되어 있지 않다면, 멀리 있으십시오.
• 눈썹을 올리거나 수축 : 그들은 질문을 이해하지 못하며 코드베이스는 거의 확실합니다.

물론, 대인 관계 의사 소통에 문제가 있으면 효과가 없을 수 있습니다.

당신이 물어 본 것에 놀랐습니다. 가입하기 전에는 코드를 보여주는 회사가 없습니다. 기밀 유지 계약에 서명하지 않는 한 컨설턴트에게도 프로세스를 요청하지 않았습니다.

여기 당신이 알아낼 수있는 것이 있습니다.

• 회사의 CMM 수준 은 무엇입니까 (이상 5)
• 예비 프로젝트에서 수행되는 프로세스는 무엇입니까 (BTW, 당신이 어떤 직업이 아니라 "이 직업"에 관심이 있다는 것을 보여주기 때문에 이것이 좋은지 묻습니다)
• 어떤 수명주기를 사용합니까 ( "민첩한"소리가 들리지 않으면 판단하지 마십시오. 구식 모델을 사용하는 유효한 이유가있을 수 있습니다)
• 코드 품질을 확인하기 위해 도구와 측정 항목을 사용하는지 묻습니다. 그리고 어느 것이 그렇다면 (적어도 하나의 도구를 사용하고 다른 도구를 품질에 사용한다면 좋은 징조입니다.)
• 또한 그들이 사용하는 도구에 유의하십시오. 프리웨어 도구 대신 Resharper와 같은 고가의 도구 인 경우 품질에 대해 심각하게 죽은 것입니다.

1. 그들이 소스 컨트롤을 사용하는지 물어보십시오.
   • 소스 컨트롤이 없습니까? -> 가장 시끄러운 코드
2. 얼마나 자주 코드 검토를하는지 물어보십시오.
   • 코드 검토가 없습니까? -> 코드가 의심 스러울 수 있습니다 (그러나 반드시 그런 것은 아니지만 특히 괜찮은 개발자로 구성된 소규모 팀인 경우).
3. 프로덕션에 들어가기 전에 테스트 및 배포 방법을 물어보십시오.
   • 테스트 환경이 없습니까? 프로덕션에 직접 배포 하시겠습니까? -> 코드가 엉망입니다.
4. 그들이 지속적으로 통합하는지 물어보십시오 (즉, Hudson으로 빌드 실행)
   • 지속적인 통합이 없습니까? -> 코드가 의심 스러울 수 있지만 반드시 그런 것은 아닙니다.
5. (# 3과 관련하여) 테스트 환경이 개발 환경 과 분리되어 있는지 물어보십시오 .
   • 시험은 개발자입니까? -> 실제로 현금으로 묶지 않는 한 좋은 표시는 아니지만 여분의 상자는 얼마나 비쌀까요?
6. 프로덕션에 배치하기 전에 조치 목록을 검토 할 것인지 물어보십시오.
   • 프로덕션 배포 전에 작업을 검토하지 않습니까? -> 나쁜 주주.
7. 그들에게 빌드를하는 데 얼마나 많은 단계가 필요한지 물어보십시오.
   • 3 이상? -> 일반적으로 나쁜 주주.
8. 그것들은 순환 복잡성이나 LCOM (클래스 응집력의 척도)과 같은 코드 메트릭스를 취하거나 추측합니다.
   • 예? -> 아마도 코드 품질과 관련하여 좋은 신호 일 것입니다.
   • 아니요, 그러나 개념을 이해합니다 (적어도 사이클로 틱 복잡성)? -> 말하기 어렵다
   • 그들은 순환 적 복잡성이 Timbuktu의 이국적인 접시 또는 최음제라고 생각합니다 (즉, 그것이 무엇인지 모릅니다)? -> 나쁜 배주 가능성.
   • 그들은 그것이 관련없는 똥 (또는 다른 종류의 태도)이라고 생각합니까? -> 도망가
9. 그들이 어떻게 버그를 추적하는지 물어보십시오.
   • 그들은 어떤 메트릭 (예 : 프로젝트 당, 변경된 모듈 수 또는 요구 사항 / 변경 요청 수 등)에 대한 버그 수를 추적합니까? -> 코드 및 소프트웨어 프로세스에 대한 좋은 신호.
   • 그들은 위의 하나를 수행 하고 그들이 예상 메트릭을 기반으로 미래 (또는 진행) 프로젝트에서 발생할 수있는 가능한 버그의 수 (변경 요청, 프로젝트 크기의 # 등)를 예측하려고? -> 아주 좋은 징조.
   • 그들은 버그 해결을 위해서만 버그를 추적합니까? -> 말하기 어렵다
   • 일관된 추적이 없습니까? -> 도망가

그것은 내 머리 꼭대기에서 온 것입니다. 내 질문 중 일부는 코딩에만 국한된 것이 아니라 소프트웨어 개발 프로세스에 관한 것입니다. 후자의 질은 전자의 질과 직접적인 관련이있다.

그런 말을하면서 이러한 질문을 할 때는주의해서 진행하십시오. 인터뷰 할 때 그것들을 연구하고 몇 가지를 선택하십시오.

명심해야 할 몇 가지 사항. 좋은 개발 팀은 인터뷰 대상자가 이러한 질문을하는 것을들을 수있어 기쁠 것입니다. 잘못하면 면접관에게 오만과 완벽주의에 대한 인상을 줄 수 있습니다. 개발자 팀이 아무리 우수하더라도 완벽한 그룹은 없으며 문제 해결, 품질 저하 등의 문제가 있습니다. 그들은 파괴적인 완벽 주의자가 아니라 품질에 대한 찬사를 가진 팀 플레이어를 원합니다. 그러니 조심해.

또한 외부 환경에 따라 품질이 낮은 코드로 작업해야하는 선량한 팀이있는 경우도있을 수 있습니다 (주니어 개발자 일 수 있음). 품질 향상을 위해 헌신하는 자원.) 주변 사람들이 좋은 사람이라면 (개인적으로나 직업적으로도) 지루한 코드로 작업하고 여전히 좋은 근무 경험을 가질 수 있습니다. 당신이 질문을 할 때 그들에게 잘못된 인상을 주면, 그들은 당신을 완전히 고용하는 것을 피할 수 있습니다.

• btw, 나는 소프트웨어 개발자가 적어도 한 번은 어떤 유형의 너머로 희망하는 (또는 너머로 희망을 벗어난) 코드로 일한 것이 필수적이라고 믿습니다. 당신은 그로부터 살아남아 좋은 일을하게됩니다. 그것은 귀중한 교훈입니다.

시끄러운 사람들과 함께 시끄러운 개발 그룹을 만날 수도 있습니다. 분명히, 그들의 코드는 혼란 스러울 것이며,이 질문들 중 어느 하나에 빠질 것입니다. 그들은 어려운 질문을하는 것에 대해 당신을 경멸 할 수도 있고 (따라서 당신에게 호의를 베풀고있을 수도 있습니다), 또는 그들이 당신을 필요로하기 때문에 당신을 고용 할 것입니다.

그런 일이 발생하면 이 일이 그토록 나쁜지 스스로에게 물어봐야합니다 . 때때로, 당신은 스파게티 똥 더미에 뛰어 들어야합니다. 때때로 당신은하지 않습니다 (즉, 당신은 할 여유가 없습니다.)

면접관에게 코드 및 소프트웨어 프로세스의 품질에 대해 질문 할 때 고려해야 할 사항입니다.

실제 코드 품질 대신 코드 품질의 중요성을 잘 알고있는 회사를 찾고 싶습니다.

예를 들어, 회사 A에 "계획이 낭비되는 시간"이라고 생각하고 "나중에 설계 문제를 해결할 수 있습니다 (예 : 지옥이 얼어 붙을 때. 그때 시간이 걸릴 것"). 그 회사가 지금 좋은 코드 기반을 가지고 있었더라도 오래 가지 않을 것입니다. 그리고 당신은 그것을 악화시킬 (강제로) 사람이 될 것입니다.

반면, 회사 B는 잘못된 코드 기반을 가지고 있지만 경영진은 코드 품질로 인해 모든 버그와 지연이 발생한다는 사실을 이해하고 변화의 필요성을 인식하고 이에 대해 무언가를 할 의향이 있다고 말합니다 (예 : 대규모) 리팩토링 또는 다시 쓰기). 이 회사는 코드 기반을 개선하고이를 달성하도록 도울 수 있습니다.

어디에서 일하고 싶은지 알고 있습니다.

시작하기 전에 99.9 % 확률로 코드를 볼 수 없습니다. (물론 무료 소프트웨어 제품을 내놓지 않는 한)

그래서 당신이 할 수있는 일은 프로세스에 대해 물어볼 것입니다. 일반적으로 좋은 프로세스는 좋은 코드를 생성합니다. Joel 테스트부터 시작하여 개발 방법에 대해 묻습니다. 또한 기본을 넘어서십시오. 예를 들어, 나는 항상 어떤 소스 코드 시스템을 사용하는지 묻기 때문에 왜 그것을 사용하는지 물어 보는 것이 좋습니다.

내가 매우 높은 품질의 코드로 작업 한 곳은 기본적으로 개발자의 3 분의 2가 코드를 만질 수 없었습니다. 다른 사람들은 자동 블랙 박스 테스트 스크립트를 대신 작성했습니다. 실제 코드를 변경할 가치가 있다고 판단되면 요구 사항이 너무 과도하게 지정되어 기본적으로 소스 코드로의 변환에 지나지 않습니다. 테스트 스크립트는 실제로 작성하는 것이 더 재미있었습니다.

내가 가장 낮은 품질의 코드를 보았던 곳은 정반대였습니다. 상대적으로 훈련받지 않은 프로그래머 나 프로그래머가 아닌 사람 만이 코드를 건 드렸습니다. 보통 회사 제품과 직접 관련이 없거나 실험적인 도구이기 때문입니다.

일하기 가장 즐거운 곳은 균형이 맞습니다. 새로운 개발자에게는 실제 과제가 주어 지지만 멘토링됩니다. 실수를 포착 할 수있는 좋은 품질 관리 부서와 동료 검토 프로세스가 있습니다. 당신은 실수를 한 것에 대해 형벌을받지는 않았지만, 실수를 고쳐서 배워야합니다. 때로는 잘못 작성된 모듈이 균열을 겪지 만 코드 품질을 향상시키는 데 시간을 소비한다고 비판을받지 않는 경우가 있습니다. 회사 전체는 코드를 개선하는 새로운 방법을 찾기 위해 지속적으로 노력하고 있습니다.

따라서 코드 품질을 평가하기 위해 묻는 질문은 다음과 같습니다.

• 테스트 절차는 어떻습니까?
• 새로운 개발자에게 어떤 종류의 과제가 부여됩니까? 숙련 된 개발자에게?
• 한 프로젝트에서 몇 사람이 일합니까?
• 리팩토링이 허용됩니까? 격려?
• 어떤 품질 관련 프로세스 또는 아키텍처 변경이 고려되고 있거나 최근에 이루어 졌습니까?
• 개인이 모듈에 대해 얼마나 많은 자율권을 가지고 있습니까?

@DPD와 @Zachary가 말했듯이 프로세스와 SDLC는 매우 중요한 요소이지만 경험에 따라 코드 품질에 큰 영향을 미치는 다른 요소를 추가하고 싶습니다.

• 비교적 새로운 프로젝트에서 개발하거나 레거시 응용 프로그램을 유지 관리 할 것인지 묻습니다. 레거시 응용 프로그램은 새로운 프로젝트보다 덜 깨끗합니다.
• 조직이나 팀에서 직원의 이직률이 높은지 확인하십시오. 이것은 코드의 품질을 떨어 뜨릴 가능성이 높습니다.

프로세스는 많은 도움이되지만 위의 요소에 대한 완전한 면역력을 제공하지는 않습니다. 많은 개발자가 프로젝트를 진행할 때마다 모든 사고 방식이 달라집니다. 아키텍트와 개발자는 이전 모델의 정확한 방식을 따르지 않아 일부 불일치가 발생할 수 있습니다.

내 태도는 이것입니다. 코드는 코드입니다. 나쁘면 더 좋게 만드는 것이 어렵습니다. 그것이 좋으면, 그것을 더 좋게 만드는 것은 훨씬 더 어려운 도전입니다!

나에게 가장 중요한 것은 내가 상호 작용할 기회가있는 회사와 사람들을 위해 일하고 싶은지 여부입니다. 코드는 변경 될 수 있습니다.

약간 농담으로 나는 인터뷰를한다 .

나는 보통 코드 기반의 실제 버그 (이미 수정 된)를 인터뷰 테스트로 사용하므로 실제 코드를 볼 수 있습니다. 일반적으로 약간 복잡한 코드이며 버그가 있습니다.

이미 버그가 실제로 있다는 것을 알고 문제가 실제로 있다는 것을 알고 수정하는 데 걸리는 시간을 알고 있으므로 모두가이 기술을 사용하도록 권장합니다.

좋은 점은 측정하기 어려운 문제가 있다는 것입니다.

나는 전문가와 전문가를 분리하기 위해 마지막 인터뷰 질문으로 매우 어려운 문제를 사용했습니다.

OP의 질문과의 관련성은 물리적 인터뷰에 참여하는 모든 사람이 일부 코드를 보게된다는 것입니다. (회사 기밀 콘텐츠는 포함되지 않음)

코드 기반의 욕설로 인해이 기술을 사용할 수없는 경우, 예상 직원이 "코드를 볼 수 있습니까?"라고 묻고 응답이 "오, 당신은 할 수 없습니다. 욕설 가득 "

물론 표준 "그것은 모두 회사의 비밀"입니다.
내 증거 : 이전 고용주에서 군사 제품 의 기밀이 아닌 부분은 인터뷰 질문의 코드 샘플이었습니다. [운행되지 않은 분류]

나보다 똑똑한 사람에게 작업하기 전에 분류 된 디자인의 품질을 결정하는 문제가 있습니다. 분류가 감독과 무관 한 것이 일반적 일 수 있습니다.

그들이 당신에게 그들의 코드를 보여줄지는 의심 스럽지만, 당신이 그들에게 프로그래밍 숙제를 주면 그것이 어떻게 될지에 대한 아이디어를 얻을 수 있습니다. 많은 곳에서 인터뷰 대상자들에게 귀하를 평가하는 데 사용할 수있는 집으로가는 프로그래밍 과제를 제공합니다. 호의를 돌려주십시오. 그들 중 하나를 예상하여 자신이 무엇을 얻을 수 있는지 더 잘 측정하십시오.

프로덕션 빌드에 코드를 작성하는 데 필요한 것이 무엇인지 물어보십시오. '어 .. 개발자가 커밋 ...'을 얻는다면 거의 확실히 쓰레기입니다.

코드의 품질을 높이려는 경향이있는 것들이 많이 있습니다 (분명히 보장 할 수는 없습니다).

• 정적 분석 (.NET에서는 fxcop / stylecop와 같은 것입니다)
• 테스트 스위트의 하위 세트 (또는 전체 세트)-단위 / 통합 / 회귀 / 수동 등
• 버디 빌드 (팀의 다른 개발자가 변경 사항을 빌드하여 기계 / 사용자 의존적 문제가 있는지 확인합니다-때로는 빠른 정신 이상을 실행하기도 함)
• 코드 검토

이것들은 코드의 강도뿐만 아니라 코드의 품질을 향상시키는 데 도움이 될 수 있습니다.

단위 테스트에 대해 문의하십시오. 그들이 진지하게 받아 들인다면, 면접관은 아마도 그 주제에 대해 확실한 의견을 가질 것이며, 그것들을 공유하게되어 기쁠 것입니다. 답변이 모호한 경우 큰 경고 신호입니다.

Java 상점 인 경우 사용중인 ORM 라이브러리를 물어보십시오. 그들이 자신의 롤을 굴렸다면 어느 쪽이든 갈 수 있습니다-빨거나 잘 될 수 있습니다. 그들이 아무것도 사용하지 않는다면, 바로 문을 향해 달려가십시오.

다른 나쁜 코딩 방법 이 너무 많아 모든 것을 예측할 수 없기 때문에 어려운 작업 입니다.

불행히도 할 수 없습니다. 어떤 회사도 자신의 코드를 보지 못하게 할 것입니다 (그러나 코드를 보라고 요청할 것입니다 ...). 당신이 그들에게 ""버전 관리? 우리가 사용 .. 으음 .. 사고 하위 .. 하위 뭔가 ") 또는 (품질에 대한 오해"우리가 사용하고있는 최신의 그리고 최고의 .NET 4 "만 찾으려면 그 그들이 .NET 4를 사용하는 동안 그들이 ' .NET 1.1과 같이 다시 작성하십시오).

과거에 여러 번 화상을 입었지만 품질을 측정하는 좋은 방법을 찾지 못했습니다. 일반적으로 가장 좋은 방법은 자신의 판단을 사용하는 것이며, 판단이 나빠지면 생각보다 나빠지면 즉시 떠나십시오. 직업 호퍼가 생길 수도 있지만 건강을 유지할 수 있습니다.