"버스 팩터"를 늘리기 위해 좋은 문서와 깨끗한 코드를 작성해야합니까?

소프트웨어 개발 회사의 주요 목표 중 하나는 버스 팩터 를 늘리는 것 입니다. 이는 Google이 주최 한 강연 에서도 옹호됩니다 .

즉, 내일 버스를 타더라도 프로젝트를 계속할 수있는 방식으로 모든 것을 코딩하고 문서화해야합니다. 다시 말해, 자신과 비슷한 기술을 가진 다른 프로그래머가 쉽게 교체 할 수 있어야합니다.

대체 가능한 것은 개발자의 이익에 반하는 것이 아닙니까? 이 책에서 48 개의 권력 법칙 11에 따르면 권력 을 얻으려면 사람들이 당신에게 의존하도록 노력해야하는데, 이는 금전적 보상으로 해석됩니다.

6 개월의 일시 정지 후에 프로젝트를 계속하기 위해 직접 문서를 작성해야하는 시나리오 외에도, 개발자와 소프트웨어 회사간에 명백한 이해 상충이있는 것 같습니다.

따라서 프로그래머라면 누구나 훌륭한 문서와 쉽게 읽을 수있는 코드를 작성해야합니다. 또는 업무를 수행하는 방식으로 코드와 문서를 작성해야하며 자신이 이해할 수 있지만 다른 사람이 이해하지 못하는 경우가 있습니까?

다른 사람이 이해하는 코드를 작성하는 것이 아니라 다른 사람보다 더 많은 경험과 지식을 수집하여 대체 할 수 없도록 노력해야합니다. 전자는 개발자가 작성한 코드 유지를 두려워하고 혐오하므로 개발자는 모든 사람과 함께 작업하지 않도록 노력합니다. 후자는 관리자가 팀에 갖고 싶어하는 팀원이되는 방법입니다.

필자의 경험상 깨끗하고 잘 문서화 된 (그리고 바람직하게는 자체 문서화) 코드를 작성하는 것이 항상 성과를 거두었습니다. 사실 나는 다른 사람들을 도와주고 가르 칠 수있는 거의 모든 기회를 가졌으며 (그들이 더 잘 알고있을 때 배우는 것뿐만 아니라) 나보다 능력이없는 사람으로 대체 될 위험이 거의 없었습니다. 실제로 이것은 일반적으로 전체 팀이 더 나은 작업을 수행하고 문제를 더 빨리 해결하는 데 도움이되었으며, 이는 모든 관리자의 꿈입니다. 그리고 현명한 관리자는 좋은 팀의 구성원을 교체하고 싶지 않습니다.

조직이나 사람들을 투명하게 조작하려는 경우 어리 석거나 잼을 사용하여 다른 선택을하지 않는 것이 좋습니다. 잘 운영되는 소프트웨어 개발 상점은 모호한 코드와 누락 된 문서를보고 많은 피해를 입기 전에 해고합니다. 그들이 제대로 운영되지 않거나 다른 개발자들이 그들을 위해 일할 수 없다면 왜 그들과 함께 사인을 원할까요?

PS Greene 씨나 Machiavelli는 실제로 당시의 "열심 한 남자들"을 아첨하려는 책을 쓰는 것 외에는 별다른 성과를 거두지 못했습니다. 소금 한알로 조언을 구하십시오.

대체 할 수없는 경우 승진 할 수 없습니다.

대체 할 수없는 것을 원하지 않습니다. 당신은 사람들이 당신에 따라 느낌을 느끼게하고 싶지 않고, 당신이 그들을 감사하게하기를 원합니다. 일반적으로 권력 법칙의 절반 만 관계 (직업적 또는 개인적)에 적용되어야한다고 생각하는 사람들과 멀리 떨어져 있어야합니다.
이 규칙은 상실 상황을 성공적으로 설정하는 방법에 대한 지침입니다. 당신이 원하는 것은 윈윈 상황입니다.
사람들이 느끼기 시작하자마자, 당신은 승패 상황에서 패배하는쪽으로 밀어 붙이고 자 노력하고 있습니다. 상실 상황을 설정하려는 시도는 파트너의 전반적인 성공에 투자하는 대신 파트너를 잃어버린 입장에 효과적으로 자원을 낭비하기 때문에 종종 상실 결과로 이어집니다.

고용주와 함께이 작업을 수행하면 지식 독점을 줄이기 위해 조치를 강요합니다. 대부분 이것들은 당신이 일을 어떻게해야하는지에 대한 우스운 지침 일 것입니다. 또한 문제가 해결 될 때 밤 3시에 전화를 해줄 것입니다. 왜냐하면 당신이 그것을 고칠 수있는 유일한 사람이기 때문입니다. 레버리지와 같은 상황을 악용하려고 시도하면 역효과를 일으키고 더 많은 문제를 일으킬 수 있습니다.

묘지에는 없어서는 안될 사람들이 가득합니다.
-골, 샤를 드

쓰레기를 자르고 제대로 작업하십시오. 다른 어떤 것이 아니라면, 2 년 후에 코드를 약간 변경 해야하는 가난한 영혼이 될 가능성이 있기 때문에 당신을 위해.

이 사이트가 유치하는 평균 이상의 프로그래머가 많기 때문에 부정적인 반응은 그리 놀라운 일이 아닙니다. 재능있는 사람들은 일반적으로 이러한 종류의 난독 화 전술에 의지 할 필요가 없습니다. 그러나 나는 그들이 열심히에 대한 문서의 풍부한 양의 생성을 지키고 자신을 위해 작은 영지을 조각했던 몇 그리 재능있는 개발자와 포춘 500 대 자동차 부품 업체에서 근무 끔찍한 그들이 디자인 한 인터페이스를.

한 사람의 전체 업무는 두 개의 완전히 별개의 하위 시스템을 연결하는 모듈의 코드를 유지 관리하는 것이므로 각 시스템의 모듈이 UART를 통해 통신 할 수 있습니다. 기본적으로 직렬 프로그래밍 101이었습니다. 다음과 같은 일반적인 인터페이스를 만드는 대신 :

  int sendData (int targetModule, void * data, size_t byteCount);
  int recvData (int sourceModule, void * data, size_t maxBytes);

그는 두 개의 통신 모듈이 서로에게 보낼 수있는 모든 단일 메시지에 대해 별도의 opcode를 작성했습니다 . 이는 그의 모듈이 모든 메시지에 대해 알아야하고, 메시지가 추가되거나 변경 될 때마다 업데이트되어야한다는 것을 의미했습니다. 부적절한 친밀감에 대해 이야기하십시오!

문제는이 사람이 모든 opcode / 메시지를 깔끔하게 나열하는 Word 문서를 유지하고 필요에 따라 부지런히 업데이트 한 것입니다. 그것은 그의 직업 이되었습니다 . 일주일에 몇 번, 그는 모든 사람들에게 불행히도 자신의 중요한 길을 갈 수있을 정도로 새로운 개정판을 보냈습니다. 경영진 이 문서를 보는 것을 좋아 했기 때문에 이것은 '전문적인'것으로 여겨졌습니다 . Kinda는 자동차 산업에 대해 울었습니다.

필자의 요점은 다음과 같다. 때때로 문서를 작성하면 실제로는 평범한 프로그래머를 보호 할 수있다 . 관리자는 종종 좋은 디자인과 나쁜 디자인의 차이점을 알 수 없으며 많은 사람들이 제한된 정보로 기술적 결정을 내려야합니다. 그들에게는 엄청나게 스트레스가됩니다. 수십 개의 깔끔한 형식의 테이블이있는 Word 문서를 보는 것은 기본적으로 나쁜 생각이더라도 매우 편안 할 수 있습니다 .

대체 가능한 것은 개발자의 이익에 반하는 것이 아닙니까?

나는 당신 에게 그것을 나누는 것을 싫어하지만 모든 사람 이 교체 가능합니다. 물론, 때로는 경험이 많고 밝 으면 당신을 대신하는 것이 약간의 도전이 될 수 있지만, 불가능한 일이 몇 년이되지 않습니다.

방법이 진정으로 당신의 고용주에 가치있는 상품으로 (단지 현재하지 고용주하지만, 어떤 고용주가) 코드를 읽는 사람에 의해 grok 수 쉬운 코드를 작성하는 능력을 증명하는 것입니다 및 문서 (작은 함께 작동하는 램프 업 (ramp up) 시간을) 코드 (모든 사람이 코드를 파지 않고도 시스템에 대한 높은 수준의 개요를 얻을 수 있음).

실제로 코드 문서 에 능숙하다는 것은 요즘에는 어려운 품질이므로 혼자서도 다른 사람과 차별화되는 데 도움이됩니다.

깨끗하고 잘 문서화 된 코드는 또한 이력서 (적어도 실질적인 결과, 즉 " n내 문서로 인해 최소한의 램프 업 및 지원으로 새로운 개발자 를 끌어 올릴 수 있었다" )에 적합합니다. 자신은 "바꿀 수없는"것이 아닙니다.

대체 가능한 것은 개발자의 이익에 반하는 것이 아닙니까?

해당 개발자의 관심사에 따라 다릅니다. 당신이 당신의 전체 경력을 위해 하나의 직업에서 그것을 내놓고 싶어하는 사람이라면, 무능을 보상하고 좋은 돈을 버는 회사에 완전히 없어서는 안될 것입니다.

그러나 회사가 추락하면 어떻게 될까요? 아마 그런 사람들을 너무 많이 고용했기 때문일까요? 다음에 어디로 갈 건가요? 왜 15 년 동안 같은 직업을 유지했는지 물어볼 때 어떻게해야합니까? 등등.

이제 다른 방식으로 보아라. 누구나 읽을 수있는 코드를 작성하는 사람이되어 몇 명의 개발자가 일자리를 잃었 는가?

그 일이 일어날 가능성은 회사가 어려움에 처해 있고 사람들을 여분으로 만드는 것입니다. 그런 일이 일어나면 나가는 것이 좋으며 앞으로 나올 인터뷰에 잘 대비할 수있을 것입니다. 또한 양심은 완전 무료입니다. 자신의 이익을 위해 작성한 설명 할 수없는 코드를 남기지 않을 것입니다.

나는 당신이 어떤 종류의 사람인지 모릅니다. 그러나 그것은 나의 관심사를 더 잘 제공합니다.

개인적으로, 나는 나의 가장 큰 장점 중 하나는 내 자신의 업무를 자동화하는 것입니다. 내 요구 사항을 충족시킬 때 회사가 어떻게 생각 하는가? 그들은 "좋아요, 우리는 지금 그를 제거 할 것"이라고 생각합니까?

대체 가능한 것은 개발자의 이익에 반하는 것이 아닙니까?

당신 말이 맞지만, 나는 당신이 교체의 의미를 잘못 이해했다고 생각합니다. 나는 문서화되지 않은 바쁜 코드를 작성하는 1000 명의 개발자를 찾을 수 없어서 유지 보수 할 수없는 혼란으로 빠르게 변할 수 있습니다.

하지 만 꾸준한 프로그램뿐만 아니라 깨끗한 코드, 정보 문서를 작성하고 프로젝트의 연속성을 보장 개발자, 즉 그건뿐만 아니라 대체 할 수없는입니다 귀중한 .

이미 여러 가지 훌륭한 답변이 있기 때문에 다른 관점에서이 질문을 다룰 것입니다.

다른 사람이 코드 작동 방식을 배우지 못하도록하면서 자신을 "바꿀 수없는"것으로 만들어 사소한 게임을 할 때 어떤 일이 발생하는지 고려하십시오. 회사가 당신을 용인하는 한 자신의 혼란을 유지하면서 같은 일을 계속합니다. 그리고 이것이 가장 좋은 시나리오입니다. 최악의 시나리오는 회사의 더 재능 있고 윤리적 인 엔지니어와 관리자가 자신의 열악한 관행이 회사에 미치는 방해를보고 해고와 재 작성을 통해 무언가를하기로 결정하는 것입니다. 처음부터 모든 것. 끝났습니다. 실제로, 그것은 매우 흔한 일입니다.

이제 좋은 코드와 좋은 문서를 작성할 때 어떤 일이 발생하는지 고려하십시오. 당신은 잘 작동하는 구성 요소 또는 시스템을 생성합니다. 작동 중 잠시 후에 버그가 부드럽게 작동하고 거의 볼 필요가 없습니다. 그것을 유지하는 데 약간의 노력이 필요합니다. 그런 다음 자신의 벨트에서 확실한 승리를 거두고 더 크고 더 나은 프로젝트로 넘어갈 수 있습니다. 사람들은 좋은 일을했다고 당신을 인식하고 당신의 의견을 존중하기 시작할 것입니다. 푸드 체인으로 올라가서 더 의미있는 결정을 내리거나 더 중요하고 영향력있는 작업을 수행하거나 프로젝트를보다 높은 수준에서 관리 할 수 ​​있습니다. 경력이 향상되고, 승진하고, 더 많은 돈을 벌고, 동료로부터 인정과 승인을 얻고, 점점 더 중요한 프로젝트의 성공을 트랙 레코드에 더 많이 추가 할 수 있습니다.

어느 경로를 선호하십니까?

단일 장애 지점 인 경우 고객 (또는 고용주)이 귀하를 대신하려고 할 것입니다. 아무리 중요해도 소프트웨어를 유지 관리하는 것보다 소프트웨어를 교체하는 것이 비용이 적게 드는 지점이 항상 있습니다. IT가 가장 아웃소싱 가능한 직업 중 하나 인 이유가 있습니다.

반면에 교체 가능하면 몇 가지 귀중한 이점이 있습니다.

• 휴가를 보낼 수있는 것
• 통화 중이 아님
• 새로운 프로젝트를 떠나고 일할 자유

빠른 문서를 작성하는 데 5 분을 소비하지 않으면 코드를 사용해야 할 때 사람들에게 문서를 다시 읽고 설명하는 데 1 시간을 소비하게됩니다.

상사가 유지 관리 가능한 코드를 작성하지 않았다는 것을 알게 되었기 때문에 새로운 일자리를 찾는 데 며칠이 더 걸릴 수도 있습니다.

리팩토링 / 진화 (refactoring / evolution)로 훌륭한 문서화는 더 이상 사용되지 않으며, 최신 상태를 유지하는 데 시간이 많이 걸립니다.

깨끗한 코드 + 단위 테스트> 우수한 문서

귀하의 질문에 대한 답변은 "예"입니다. 예, 좋은 문서와 깨끗한 코드를 작성해야합니다. 고의로 달리 수행하는 것은 무결성의 부족을 나타내며, 비즈니스 세계에서 점점 더 널리 퍼져 있지만 갑자기 "좋은"일이 아닙니다.

대체 할 수있는 사람은 없습니다. 그들이 자신이 아닌 어려운 길을 찾는 경향이 있다고 생각하는 상황을 만드는 사람들. 자신을위한 공동 의존성을 제조하는 것은 고용주뿐만 아니라 귀하를 제한하기 때문에 비생산적입니다.

소프트웨어 개발 회사의 주요 목표 중 하나는 버스 팩터를 늘리는 것입니다

거짓 전제. 소프트웨어 개발 회사 (내가 일한 모든 회사)의 주요 목표는 반드시 그 순서대로가 아니라 가능한 최고의 소프트웨어를 생산하고 돈을 버는 것입니다. "버스 팩터"를 줄이면 돈을 잃지 않을 수 있습니다.

법 11 사람들이 당신을 의지하는 법을 배우십시오.

그게 당신에게 무엇을 의미합니까?

사람들이 당신의 도움을 받아 앞으로 나아갈 수있는 방식으로 그들을 훼손했기 때문에 사람들이 당신에게 의지하고 싶습니까? 아니면 똑똑하고 통찰력이 있고, 신뢰할 수 있고, 신뢰할 수 있고, 다른 사람들이 자신의 일을 더 잘 수행하도록 도울 수 있기 때문에 사람들이 당신에게 의지하고 싶습니까? 당신의 도움없이 동료들을 나쁘게 보이게 하시겠습니까, 아니면 그들이보기 좋게 만들어서 당신에게 감사하기를 원하십니까?

당신의 전화입니다.

(제조 코드를 가정)

나는 조금 더 나아가는 경향이 있습니다. 나는 프로그램을 "멍청한 증거"로 만드는 것에 대해 글을 썼지 만, 항상 자격이되는 것은 아니다 : 나는 다른 사람들이 보거나 다루지 않을 많은 코드를 작성한다 (적어도 그것이 쓰여질 때의 기대치이다). 나는이 경우 내가 자신을 방어하려는 바보입니다. 프로그램이 문제를 감지했을 때 좋은 일이며 문제가 너무 단순화되어 오류와 그 원인이 있음이 분명합니다. 사실은 프로그램을 작성할 때 구현 세부 사항이 분명하지만 (초기 구현하지 않는 한) 클라이언트에 대해 추상화되고 오류에 강해야합니다 (모듈 위치가 존재하더라도). 그 이유는 프로그램이 매우 복잡해지기 때문입니다. 때로는 문제를 분리 할 수 ​​있지만 항상 그렇지는 않습니다. 구성 요소를 매우 엄격하고 단순하며 캡슐화가 잘되어 있고 바보 같은 증거로 유지하는 경우 구성 요소가 제대로 확장되는 경향이 있으며 대부분의 결함은 배송 전에 감지됩니다. 재사용이 쉬우 며, 프로그램을 재사용 할 수있는 자신감과 시간이 늘어납니다. 여러분이 작성하는 복잡한 프로그램은 프로그램을 마치고 나면 더 복잡해집니다 (심지어도). 6 개월 안에 읽으면 바보 증명 버전에 비해 이해하고 디버깅하는 데 시간이 오래 걸릴 수 있습니다. 구성 요소에 주요 변경 사항이 있으면 구성 요소가 오랫동안 감지되지 않을 수 있습니다. 프로그램은 복잡합니다. 그 현실을 벗어날 수는 없지만, 바보 증거를 만들 수 있습니다. 어떤 것이 잘못되거나 재사용되거나 변경되어야 할 때 인생을 훨씬 쉽게 만듭니다. 따라서 바보 증명 방식은 소프트웨어를 숙달 된 직원이나 팀원들 (귀하의 선량 / 경험이있는 사람이 아닌 사람)이 소프트웨어를 이해, 재사용 또는 유지 관리 할 수 ​​있음을 의미합니다. 대체는 별도의 관심사입니다. 사람들이 프로그램 작업을 좋아한다면 좋은 일을하는 것입니다. 교체에 대해 걱정하지 마십시오. 물론, 이해할 수없는 프로그램이 직업을 구할 수있는 시나리오를 생각 해낼 수 있지만, 다른 사람이 사용하고 유지할 수있는 좋은 프로그램을 작성하는 것은 분명히 덜 악합니다 (다른 사람들의 반응을보십시오). 내가 바보 증거가 아닌 것을 쓰면 내가 고치려고 노력한다.

6 개월의 일시 정지 후에 프로젝트를 계속하기 위해 직접 문서를 작성해야하는 시나리오 외에도, 개발자와 소프트웨어 회사간에 명백한 이해 상충이있는 것 같습니다.

휴면 구현을 다시 방문 할 때 어떤 생각을하고 있는지 전혀 알지 못합니다. 실제로 경험 이 있으면 기존의 방법론이나 접근 방식에 더 의존 할 수 있기 때문에 문제가 더 간단 해집니다. 그러나 이러한 방법론은 변하지 않는다고 가정합니다. 문서가 느슨해 지더라도 여전히 구현에 방어 적이어야합니다 (예 :이 시나리오에서 NULL을 전달하는 것보다 잘 알고 있습니다-그 조건을 테스트하십시오).

따라서 프로그래머라면 누구나 훌륭한 문서와 쉽게 읽을 수있는 코드를 작성해야합니다. 또는 업무를 수행하는 방식으로 코드와 문서를 작성해야하며 자신이 이해할 수 있지만 다른 사람이 이해하지 못하는 경우가 있습니까?

나는 버스 팩터 접근 방식보다 더 명확하고 오류에 대한 내성이있는 바보 증명 접근 방식을 권장합니다. 프로젝트 외부의 누군가가 쉽게 이해할 수 있도록 프로그램과 문서를 작성하십시오. 그렇게하면 회사와 팀에 대한 가치가 높아지고 대신 당신을 대신 하고 싶지 않을 것입니다.

당신은 기본적으로 게임을 오해했습니다. 게임은 이전에했던 것과 똑같은 일을 계속하지 말고, 아무도 그것을 얻지 못하기 때문에 작성한 모든 코드를 책임집니다. 이 게임은 프로젝트를 완료하고 다음 프로젝트로 넘어 가서 다른 사람이 부재시 쉽게 이해하고 작업 할 수있는 코드를 남겨두고 새로운 일을하고 더 많은 책임을 맡을 수 있도록하는 것입니다. 당신의 전제는 배우거나 개선 할 기회없이 똑같은 일을 계속 반복해서 기뻐하는 경우에만 효과가 있습니다.

또한 그 코드를 자주 볼 기회가 없다면 의도적으로 난독 화하면 6 개월 만에 코드를 알아내는 데 어려움을 겪을 것이라고 지적합니다.

내가 작성한 작은 코드를 문서화하여 다른 사람들이 읽을 수 있도록하는 것이 아니라 3 개월 안에 읽을 수 있도록합니다 . 유지 관리가 쉬워집니다. 작성한 코드에 대한 책임이 있고 나중에 줄에 나타나는 버그를 수정할 수 없다면 문서화를 원할 것입니다. 당신의 일을하기 위해!

내가 대화 할 수없는 불행한 컴퓨터 전문가들은 대체로 고용주의 자원을 인질로 잡으려고했기 때문에 대체되었다. 나에게보고하는 사람들에게 자신의 시간이 문서를 "폐기"하는 데 가치가 있다고 말해 주었을 때 가능한 빨리 교체합니다.

예비 직원이 48 가지 권력 법칙을 윤리적 또는 도덕적으로 수용 가능한 것으로 간주한다면, 그 법이 없으면 더 나아질 것입니다.

대체 할 수없는 것을 원한다면 (모든 답을 읽은 후에 다시 생각하고 싶을 수도 있습니다 ...)-왜 코드를 문서화하지 않는 것이 좋습니까?

유지 관리 할 수없는 코드를 작성하는 방법에 대한 정말 훌륭한 안내서가 있습니다. http://thc.org/root/phun/unmaintain.html

즐겨! (가장 확실했습니다 ...)