다른 사람의 코드를 배우는 과정을 어떻게 설명해야합니까? (인보이스 발행 상황에서) [닫힘]

편집 : 저스틴 케이브 (Justin Cave)는 이런 종류의 커뮤니케이션이 내 견적 / 견적에서 선행되어야한다는 좋은 지적을했습니다. 이 경우에도 사람들이 '기존 코드 학습'활동을 설명하기 위해 어떤 종류의 언어를 사용하는지 알고 싶습니다. 특히 소프트웨어 계약 업체를 다루지 않은 회사에 특히 그렇습니다. 편집 종료

대기업을 위해 사내 소프트웨어를 업그레이드하기로 계약했습니다. 이 회사는 여러 가지 기능 추가와 몇 가지 버그 수정을 요청했습니다. 이것은 나의 첫 번째 프리랜서 스타일 직업입니다.

먼저, 응용 프로그램의 작동 방식에 익숙해 져야했습니다. 마치 마치 마치 사용자 인 것처럼 배웠습니다.

다음으로 소프트웨어 작동 방식을 배워야했습니다. 광범위한 개념으로 시작한 다음 각 버그 수정 및 기능을 수행하기 전에 필요한 세부 사항으로 좁혔습니다.

적어도 프로젝트가 시작될 때 추가 기능을 작성하는 것보다 기존 코드를 배우는 데 훨씬 오래 걸렸습니다.

인보이스에서 기존 코드를 학습하는 프로세스를 어떻게 설명 할 수 있습니까? (이 회사 의이 부분은 일반적으로 사내 작업을 수행하므로 나와 같은 소프트웨어 계약자를 다루는 경험이 많지 않아 다른 사람의 코드를 배우는 오버 헤드를 이해하지 못할 수도 있습니다). 실제 기능 업그레이드에 대해 학습 시간을 단축하고 싶지는 않습니다. 경우에 따라 '간단한 작업'이 너무 오래 걸리는 것처럼 보이기 때문입니다. 송장을 관련 단계로 나누고 다른 사람의 코드를 배우기 전에 다른 사람의 코드를 배우는 데 드는 많은 오버 헤드를 청구하고 있음을 알리고 싶습니다.

일자리를 청구 할 때 이런 종류의 활동을 설명하는 표준적인 방법이 있습니까?

"기존 기능 검토"및 / 또는 "기존 코드 검토"와 같은 작업에 송장을 작성합니다. 새로운 기능의 복잡성에 따라 기존 코드의 통합 지점을 파악하는 데 소요되는 시간을 포함하는 "Design xxx"작업을 추가합니다.

고객에게 새로운 컨설턴트의 속도를 높이는 데 약간의 오버 헤드가 있음을 분명히하는 것이 좋습니다. 결과에 만족하는 경우 동일한 컨설턴트와 계속 작업하면 비용을 절약 할 수 있습니다. 돈.

문제 진단.

익숙한 용어입니다. 자동차를 고치거나 의사에게 가면 진단은 무엇이 잘못되었는지를 나타내는 일반적인 용어입니다. 또한 정확합니다. 후드 아래로 가서 작동하지 않는 것을 파악하기 위해 모든 것이 어떻게 연결되어 있는지 확인해야합니다. 실제로 매뉴얼없이 엔진 작업을하는 것과 비슷하기 때문에 회사는 이전에 다른 엔진을 보지 않고 엔진을 만들어 냈습니다.

오래 걸리거나 이상하게 표현 된 광고 항목은 실제로 원하지 않는 추가 질문을받습니다. "문제 진단"은 어느 정도 보편적으로 이해되는 개념입니다.

고객에게 청구서에 아무것도 놀라지 않아야합니다. 그 점을 감안할 때, 고객의 관점과 개발자의 관점에서 응용 프로그램을 익히는 데 많은 시간이 소요될 것이라는 고객의 기대를 이미 설정했으면합니다. 그리고 처음 몇 가지 기능에 대한 귀하의 추정에는 코드에 익숙해지는 데 상당한 시간이 포함되어 있기를 바랍니다.

초기 송장에 대한 대부분의 시간이 응용 프로그램에 익숙해 지도록 고객과의 기대치를 이미 설정 한 경우 송장에 목록을 표시하는 방식이 너무 중요하지는 않습니다. 견적을 제공하고 기대치를 설정할 때 사용한 언어를 사용하십시오. 지금이 대화 만하려고한다면 문제가있는 것입니다.

프리랜서로서의 능력으로, 나는 이것을 일반적으로 "지식의 동화"와 같은 것으로 칭할 것입니다. 그리고 이것은 고객에게 처음 제공된 견적에 포함되었을 것입니다.

여기에서는 도움이되지 않을 수 있지만 나중에 참조 할 수 있도록 앞으로 더 활발한 작업을 수행 할 것을 권장합니다. 예를 들어, 처리 한 시간 동안 주석 처리되지 않은 코드에 주석을 추가하고, 테스트되지 않은 코드에 단위 테스트를 추가하는 등의 시간 동안 고객에게 송장을 보내십시오. 이는 코드 기반에 대한 이해를 돕기 위해 최소한의 가치를 더하는 작업의 예입니다. .

문서화하는 동안 읽기와 읽기가 크게 다르지 않더라도 고객은 이러한 '활동적인'작업에 대해 약간의 심리적 선호를 가질 것입니다. 그리고 실제로 다른 사람의 코드를 단순히 읽는 것보다 문서화하여 더 많은 것을 배울 수 있습니다. (이 것입니다 확실히 당신이 자신의 코드에 대한 테스트를 작성하는 경우 경우가).

이렇게하면 "지식 평가 및 레거시 코드 테스트 / 문서"와 같은 송장 라인 항목이있을 수 있습니다.

편집 : 설명 된 상황에서 솔직히이 활동의 ​​비용을 먹을 것입니다. 나는 당신의 재정에 대해 말할 수 없으며, 추정 할 의향이 없지만, 시작할 때, 몇 시간의 청구보다 고객의 평가와 고객 만족을 높이는 데 더 큰 가치를 두었습니다. 그것이 초기에 효과적인 낮은 비율을 의미한다면, 그것은 좋은 투자 일 수 있습니다. 장기적으로 청구 가능 시간을 먹는 것은 공정한 흔들림이 있다고 생각하는 만족스러운 고객에게 지불하는 작은 가격 일 것입니다.

버그 수정 : 근본 원인 분석.

새로운 기능 : 분석, 설계, 통합 및 테스트.

새로운 버그 소개 : 작업 보안. :)

일이 어떻게 작동하는지 이해하고 꿈꾸는 눈으로 저의 말을 듣는 것을 좋아하는 고객과 함께, 나는 똑바로 갈 것입니다 Codebase Familiarization. 나는 그가 그에게 어떤 고통의 흐름을 가져다 주 었는지, 그리고 추가 업그레이드를 위해 나에게 오는 이점을 이미 설명했을 것입니다.

다른 유형의 고객과 함께 ... (동일한 치료이지만 그는 내가 말하는 한 단어를 듣지 않습니다 ) 나는

• Planning Phase

• Intervention Planning

  (실제로는 이것을 사용하지만 이탈리아어로 작성하면 더 좋게 들립니다)

• 그렇다면 ... Solution Planning

Diagnosis의 Problem Diagnosis제안 부분이 마음에 anon들지만, Problem제게는 들리지 않습니다. 온화하고 편견이 있고 무지하며 피상적 인 비판에 노출 될 수 있습니다.

모두들 외부 컨설턴트에게 다트를 던지고 싶어합니다. (... 그는 문제에 대해 이야기하면서 문제의 근본 원인을 이해하기에 충분하지 않았고 그의 우둔함을 청구해야했거나 신이 무엇을 알고 있는지)

내 정비공이 "오일 교환, 스파크 플러스, 점검 필터, 타이어 회전 점검"을 보냅니다. 엔진 딸랑이, 도로 시험 문제 해결 .....

부품 (항목),

노동 x @ $ y / hour = z)

그는 노동을 분해하지 않으며, 당신도 마찬가지입니다. 총 시간을 청구하고 수행 한 내용을 설명하십시오.