엄격하거나 실용적입니까?

저는 소프트웨어 개발이 (다른 것들 중에서도) 끊임없이 자신에게 질문하는 과정이라는 것을 깨닫기 시작했습니다. 코드 품질, 우려 분리, 종속성 최소화 등에 관한 질문 ...

그러나 주요 질문은 정신 병원에 가지 않고 얼마나 멀리 갈 수 있습니까?

새 일자리를 신청하고 있습니다. 어제 나는 미래의 고용주와 함께 프로그래밍 능력을 테스트하고 싶었다. 연습 중 하나는이 코드의 기능을 설명하는 것입니다. 나는 그들이 개발 한 응용 프로그램 코드 (vb.net의 winforms)를 겪었습니다 (병원의 관리 응용 프로그램입니다). 이것은 그들이 어떻게 접근하는지 실제로 볼 수있는 기회를줬고 그것은 다소 실망 스러웠습니다.

몇 가지 예 :

• 어딘가에 보았다 : [서브 루틴의 이름을 입력하시오]-> 맞았다 : VB6에서 나온 것이 아닌가?
• 그들은 ado.net을 사용하여 별도의 데이터 계층을 가지고 있지만 검사 해야하는 한 가지 방법은 데이터 계층을 호출 계층에 반환합니다. 따라서 별도의 데이터 계층 여부에 관계없이 응용 프로그램은 ado.net에 연결되어 있습니다 (다른 데이터 액세스 방식으로 전환하지 않으면 결코 문제가되지 않습니다).
• 이 데이터 세트는 그대로 읽혀지기 때문에 여전히 데이터 중심 접근 방식입니다 (물론 "환자"또는 "LabAnalysisRequest"와 같은 클래스에 얼마나 많은 로직 / 동작을 사용할 수 있는지 논쟁 할 수 있습니다.
• 또한 문자열 연결로 SQL 쿼리를 구성하는 것을 보았습니다.
• 그들은 저장 프로 시저를 사용합니다 (나에게 의미 : 논리의 산란)
• 뷰 / 컨트롤러에 대한 언급 없음 : 모든 형태의 구동
• 내가 본 가장 추악한 것은 :

      TestEnvironment.IsTesting 인 경우
         someVar = [일부 하드 코딩 된 값]
      그밖에
         someVar = [일부 동적으로 검색된 값]
      경우 종료
      [여기에서 기능의 나머지]
  

그것은 내가 학교에서 배운 것과 완전히 다릅니다 : (지속성 불가지론) 도메인 계층, 지속성 계층, 프레젠테이션 계층, 단위 테스트 ...

그래서 나는 내 질문을 바꾸어 놓았습니다. 프로그래머는 어느 정도까지 자신의 원칙을 고수하거나 업무를 수행하는 코드를 작성해야합니까?

나는 그것이 귀하의 질문에 직접 대답하지는 않지만 여전히 이것이 의견 이상의 가치가 있다고 생각합니다.

면접을 할 때, 그들은 당신을 인터뷰하는만큼 면담하고 있습니다 . 인터뷰 내용을 배에서 크롤링하여 무언가를 제공하도록 간청하는 습관을들이십시오. 그들은 당신을 체크 아웃 하지만 당신도 그들을 체크 아웃합니다 . 그들이 당신을 좋아하지 않는다면, 그들은 당신을 고용하지 않을 것입니다. 마음에 들지 않으면 거기서 일하지 마십시오.

그렇습니다. 업계에서 10 년이 지난 레거시 코드 기반은 배경, 기술 및 열정이 서로 다른 30 명 이상의 개발자가 긴밀한 마감일, 리소스 부족 및 재정적 제약으로 인해 해킹 당 했으므로 코드는 결코 당신이 (보아야 할) 배워야 할 방식을 살펴보십시오. 양보를해야합니다. 그러나 선의 수와 위치는 전적으로 귀하에게 달려 있습니다.
물론, 적은 양보를 구하기 란 직업이 어렵습니다. 그러나 그들은 더 즐거울 수 있습니다.

FWIW, 나는 지금까지 (업계에서 10 년 이상) 많은 개발자가있는 대기업에서 일한 적이 없었습니다 (약 30 명의 개발자가 가장 많았으며 수십 명의 표준). 소규모로 무언가를 바꿀 가능성이 훨씬 높기 때문에 회사. 아이들을 굶지 않을만큼 돈을 벌면 대기업의 작은 톱니 바퀴가되고 싶지 않습니다. 여기서해야 할 일은 나머지 기어와 동기화하는 것입니다.
그들이 통과하기를 원하는 시험을 본 후에 구인 제안을 거절했습니다. 나는 C ++ 개발자이며 발톱이 혐오감으로 인해 너무 나빠서 많은 C ++ 테스트가 있으며 깨끗한 코드를 작성할 수없는 morons를 고용했기 때문에 풍차와 싸우는 데 시간을 보내고 싶지 않습니다.
또한 인터뷰에서 다른 말을 했음에도 불구하고 프로그래밍 철학 (단기 목표, 내년은 신경 쓰지 않음)이 내 능력 (장기 코드 안정성)에 맞지 않기 때문에 몇 달 후에도 일자리를 떠났습니다.

작업을 수행하는 코드를 작성하지 마십시오. 그러나 교리를 똑같이 기꺼이 검토하십시오. 학교에서 배운다고해서 그것이 현재의 사고, 또는 타당한 사고라는 의미는 아닙니다. 프로그래밍은 비즈니스 세계에보다 반응해야하므로 소프트웨어 설계 수명주기가 더 이상 사용되지 않습니다. 시간이 지남에 따라 부품이 교체되어 어색하게 연결된 소프트웨어 솔루션이 어색하게 연결되는 경우가 있습니다.

다음은 회사의 코딩 라이프 스타일에 얼마나 적합한 지 결정하는 컴파일 된 문제 목록입니다.

1. 리팩토링하고 코드 기반을 최신 상태로 유지하기 위해 설정 시간을 소중히 생각합니다. 그들이 코드베이스 업데이트를 어떻게 보는지는 당신이 얼마나 잘 적응 하는지를 결정하는 중요한 요소가 될 것입니다.
2. 사내 코딩 대신 타사를 얼마나 자주 구매합니까?
3. 그들은 오픈 소스 소프트웨어에 대해 어떻게 생각합니까? 그들은 코드 변경에 유연성이 있다는 것을 알고 있습니까? 그들은 타사를 구매하는 것과 같은 방식으로 보십니까?
4. 특정 추상화 계층에서 작업합니다. 당신의 인터페이스 팀이 당신의 인터페이스를 결정합니까? 어떤 레이어 / 팀 / 인터페이스 인터페이스가 의사 결정에 더 많은 힘을 가지고 있는지
5. 결정을 내릴 때 감독자가 프로그래머의 말을 얼마나 많이 듣습니까? 프로그래머가 빨간색 깃발을 던지면 감독관이 중단하고 결정을 검토합니다.
6. 경영 경험이 풍부한 프로그래머를 고려하십니까? 그들은 그들의 경험을 어떻게 여깁니까? 그들의 경험이 유효합니까? 구식 경험이 의사 결정에 영향을 미치게합니까?
7. 코드베이스는 얼마나 끈적 끈적한가?
8. 프로그래밍 도구 (IDE 등)를 얼마나 자주 업데이트합니까?

이 질문들에 대한 답은 그들이 당신의 교리와 일치하는지 보는 것보다 프로그래밍 라이프 스타일을 어떻게 평가할 것인지에 더 잘 맞습니다.

교리가 필연적으로 깨질 것입니다 (X를 업데이트 할 시간이 없습니다). 그러나 우선 순위는 스타일 및 의사 결정과 충돌하는 정도를 정의합니다.

나는 당신이 이것을 전체의 일부로 무게를 측정해야한다고 생각합니다. 첫 번째 직업 중 하나는 그룹 내에서 객체 지향 C ++을하고 있다고 말한 것입니다.

그들의 자기 평가는 잘못되었습니다-그들은 다소 C를하고있었습니다. 그것은 여전히 ​​매우 기능적으로 디자인되어 있었으며, 나 자신에게 printf와 getf 그리고 내가 배운 적이없는 다른 C 메커니즘을 가르쳐주기 위해 C 책을 가져 가야했습니다. 팀원 중 아무도 C가 코드를 좋아하는 방식을 깨닫지 못했다는 사실조차도이 "C ++ 디자인"이 어떻게 떨어졌는지 지적하지 못했습니다. 당시 저의 목표는 OO 개발을하는 것이 었습니다.

그러나 결국 나는 팀을 고집하게되어 기쁘다. 그들은 매우 똑똑한 사람들의 역동적 인 그룹이었고 많은 어려운 문제로 발이 젖었 고 전체 수명주기를 다룰 수 있었고 문제 도메인 (PKI)에 대해 배운 것들이 그 이후로 내 경력에 활력을 불어 넣었습니다. 팀이 기능 영역에서 수행 한 작업은 놀라웠으며 여전히 해당 제품과 해당 작업 경험을 매우 좋아합니다. 더 나은 아직-나는 아직도 몇몇 사람들 (나중에 몇몇 회사들)과 함께 일하고 있으며, 그들은 여전히 ​​영감을 받고 있으며, 우리는 여전히 좋은 일을하고 있습니다.

나는 코딩 언어의 모범 사례를 완벽하게 구현하는 것이 좋은 업무 경험이나 좋은 팀을 만들거나 깨는 것이라고 생각하지 않습니다. 경력에 활력을 불어 넣는 일은 그 이상이며 제품이 괜찮다면 품질, 팀은 괜찮은 근무 조건을 가지고 있으며 (Joel Test와 같이) 팀은 똑똑하고 일을하는 사람들로 가득 차 있으며, 구현의 완성은 부차적입니다. 좋은 일, 좋은 사람, 좋은 근무 조건과 같은 요소를 제거하십시오. 코드가 이상하게 조합되어 있는지 여부와 관계없이 가치가 없습니다.

얼마나 근본적이거나 독단적이어야합니까? 프로그래머는 어느 정도까지 자신의 원칙을 고수하거나 업무를 수행하는 코드를 작성해야합니까?

여기서 기억해야 할 가장 중요한 것은 당신의 목적 이 무엇 입니까?

대부분의 회사 에서 인생 의 목적 은 완벽한 코드를 작성하는 것이 아닙니다. 귀하의 목적은 사용자에게 가치를 제공하는 것입니다. 좋은 코드를 작성하는 것은 일반적으로 유지 관리, 문제 해결 및 개발이 쉬운 우수한 제품을 제공하는 가장 좋은 방법 입니다.

좋은 코드는 좋은 ROI를 제공하는 곳에 적용해야하는 도구입니다.

몇 가지 예 :

1. API, 특히 비즈니스 계층의 API를 디자인하고 코딩하는 데 많은 시간을 할애했습니다. 다른 많은 프로그래머들이 그것들을 사용할 것입니다. 제대로 설계되면 많은 시간과 문제를 절약 할 수 있습니다.
2. 프리젠 테이션 레이어에서 규칙을 약간 완화합니다. 더 많은 기능을 추가하기 위해 코드 "완벽 성"을 희생하려는 경향이 있습니다.

결론적으로, 당신은 원칙을 가져야하지만 가치보다 더 해를 끼칠 때 그 원칙을 깨뜨리기에 충분히 유연해야합니다.

몇 년 동안 전자 상거래 소매 업체에서 근무했습니다. 거기에서 시작했을 때 내부 응용 프로그램의 코드는 모두 MS Access 용 VB로 작성되었으므로 가장 말이 안됩니다. 저는 3 명의 개발자로 구성된 팀을 보유하고 있으며, 향후 몇 년 동안이를 적절한 VB.Net 응용 프로그램으로 대체했습니다.

그러나 채용 예산이 극히 제한적이기 때문에 주니어 프로그래머 만 감당할 수있었습니다. 물론 그들이 만든 코드는 그다지 크지 않았습니다. 그러나이 회사는 효과가 있었으며이 애플리케이션을 사용하여 매일 돈을 벌었습니다.

그리고 나는 내 친구들과 일하기 시작했습니다. OOD, 데이터베이스 디자인, MVC 및 C #에 대한 약간의 교육 그리고 수년에 걸쳐 상황이 개선되었습니다. 4 년 후에 떠났을 때 코드베이스는 여전히 좋지 않았지만 시작했을 때보 다 100 배 나았습니다.

설명하는 상황과 같은 상황은 종종 사용 가능한 자원과 관련하여 발생하는 결과입니다. 우리는 이상적인 세상에 살고 있지 않습니다. 동시에 이것은 실제로 변화를 일으킬 수있는 좋은 기회입니다.

BTW : 이러한 응용 프로그램 중 일부는 여전히 사용되고 있으며 약 3 년 전과 거의 변함이 없으며 여전히 돈을 벌고 있습니다.

나는 당신의 원칙을 고수하는 것이 매우 중요하다고 생각합니다. 주어진 제약 조건 내에서 가능한 최고의 코드를 만들기 위해 항상 노력해야합니다. 그러나 원칙 목록에 "잘못된 코드 를 읽 거나 변경할 필요가 없습니다"를 추가 하면 작업을 찾는 데 많은 어려움을 겪게됩니다. 프로그래머의 50 %가 수업의 하반기에 졸업했습니다. 한 남자 팀에서도 "오늘 당신"은 "지난 달 당신"보다 문제를 해결하기에 더 적합합니다. 비 이상적인 코드로 작업 할 수 있다는 것은 작업의 일부일뿐입니다.

많은 고용주들이 자신이 읽은 코드가 코드베이스에서 최악의 코드가 아니라 최고 코드를 나타낼 수 있다는 것을 인식하고 있습니다. 문맥에서 명확하지 않은 경우에는 물어보십시오. 내가 때때로 인터뷰하는 한 동료는 인터뷰 질문으로 사용하기 위해 의도적으로 잘못 작성한 코드 페이지를 가지고 있습니다.

99 %의 경우 전화 할 때«dogma»를 고수해야합니다. 교리는 수년간의 실습 경험이있는 사람들에 의해 만들어졌으며 어떤 시점에서 실용적으로 보일 수있는 것은 실제로는 그렇지 않습니다. 이것은 일반적으로 문제를 올바르게 처리하기에 충분하지 않다는 사실보다 더 관련이 있습니다.

그러나 교리를 맹목적으로 따르지 마십시오. 사람들이 그 교리를 따르게하는 결론을 기억하십시오. 따르지 말아야 할 경우의 작은 부분을 찾을 수 있기 때문입니다. 어쨌든 이러한 경우는 매우 드물기 때문에 그러한 결정을 내리기 전에 항상 다른 숙련 된 프로그래머와상의해야합니다.

중요 할 때는 엄격해야합니다. 중괄호 스타일 (또는 다른 코딩 규칙)? 중요하지 않습니다. 상점에서 사용하는 것을 사용하십시오. 특별한 이유없이 캡슐화 (또는 다른 기본 프로그래밍 원칙)를 깨뜨리고 있습니까? 그리 사소하지 않습니다.

Stack Exchange는 레이아웃을 위해 테이블을 사용합니다 ( 돈을 버는 다른 많은 주요 웹 사이트와 마찬가지로 ). 그것이 순수 주의자 귀에서 연기가 나게합니까? 물론입니다. 그러나 실용주의는 매번 순도를 능가합니다. 해운 제품은 언제나 완벽 해집니다.

전체 도메인 레이어, 퍼시스턴스 레이어, 프리젠 테이션 레이어, 단위 테스트는 역사적 관점에서 볼 때 여전히 비교적 새롭습니다. 여전히 클라이언트 / 서버 모델을 사용하는 소프트웨어가 많이 있으며 "더 나은"최신 아키텍처 스타일로 변경되지 않습니다.