프로젝트 인수-이전 프로그래머에게 무엇을 물어야합니까?

프로젝트 인수-이전 프로그래머에게 무엇을 물어야합니까?

---

나는 상업 웹 사이트의 개발을 맡고 있습니다. 이 사이트는 다른 프로그래머가 2 년에 걸쳐 개발했습니다. 대부분 1 인 작업 (사이트 유지 및 확장)입니다. 다른 프로그래머가 시스템을 보여줄 때 2-3 일의 전환 기간이 있습니다. 그러나 내가 아는 한 문서는 거의 없습니다. 모든 것이 코드에 있습니다 (일종 문서화 됨). 지금까지 내가 물어볼 계획은 다음과 같습니다.

• 시스템의 가장 복잡한 요소에 대한 설명
• 전체 아키텍처에 대한 설명
• 지원 도구에 대한 설명 (IDE 설정, 단위 테스트, 배포 메커니즘)
• 시스템 아키텍처에 영향을 미치는 데 사용한 모든 책, 웹 사이트, 팟 캐스트

내가 놓친 다른 것이 있습니까?

[편집] 모두에게 감사합니다. 좋은 제안을 잃었습니다. 하나 이상의 답변을 받고 싶었습니다! 또한 다음을 추가합니다.

• 시스템의 성능을 개선하기 위해 특별히 어떤 작업을 수행했으며 현재 병목 현상은 어디에 있습니까?
• 이와 관련하여 시스템 보안과 관련하여 무엇을 했습니까? (무엇을했으며 현재 보안 허점은 어디에 있습니까?)

마지막으로, 개발자는 나중에 필요할 경우 내 질문에 대답 할 수 있다고 말했습니다. 결국 그의 "아기"입니다. 그러나 나는 6 개월 후에 그가 이사 할 것이고 그의 가용성은 훨씬 더 줄어들 것이라고 정말로 생각합니다!

---

웹 서버, 도메인 등록 기관, 데이터베이스 서버, 이메일 서버 및 기타 생각할 수있는 모든 것에 대한 모든 로그인 정보 를 요청하십시오 . 이상하게 들리지만 종종 개발자는 관리 및 기술 담당자로 도메인 이름을 등록합니다. 원래 프로그래머에게 연락 할 수없는 경우 회사는 도메인을 되찾기 위해 등록 기관과 모든 종류의 후프를 거쳐야합니다.

---

코드를보기 전에 :

objs와 exes를 지우고 그 / 그녀가 물건을 다시 만들도록하십시오. 수동 상호 작용을 확인하십시오 ( "만들기"만 통해 빌드하거나 약간의 조작이 필요함).

더 좋은 방법은 그 / 그녀에게 알몸 (방금 구입 한) 기계를주고 계산대를 시연하고 재건하게하십시오. 그런 다음 앱이 어떻게 시작되고 표시되는지 확인합니다 (입력 할 비밀 옵션이 있습니까?).

그런 다음 쌍 프로그래밍 세션에서 시스템에 하나 또는 두 개의 기능을 추가하고 이러한 기능이 구현되는 위치와 방법을 확인합니다.

위의 내용은 어리석게 들릴지 모르지만, 건물 하나만으로는 악몽이되고 많은 지식이 개발자의 두뇌에만있는 프로젝트를 본 적이 있습니다. 신뢰할 수있는 빌드 환경이없고 재 구축 방법을 파악해야하는 것은 거의 불가능합니다.

---

"돌아가서이 시스템을 재개발 할 수 있다면 어떻게 하시겠습니까?"

---

질문 : a)이 시스템에 대해 내가 당신에게 묻기를 원하지 않는 것은 무엇입니까? b)이 프로젝트에서 더 이상 작업하지 않을 때 가장 만족할만한 것은 무엇입니까? c) 문서화하기에는 너무 복잡한 시스템 부분은 무엇입니까?

---

그의 전화.

---

전문 사용자는 누구입니까? 누구의 의견을 찾거나 신뢰해야합니까?

위험한 비전문 사용자는 누구입니까? 누구의 말을 듣고 적극적으로 무시해야합니까?

---

시스템에 필요한 주기적 "수작업"은 무엇입니까?

아시다시피, 아직 자동화되지 않은 아주 자주 발생하는 작은 직업. 당신은 그것을 어떻게 고치고 그것을 어떻게 인식합니까?

---

실제 요구 사항이 무엇인지 물어보십시오 . 대부분의 프로젝트에는 서면 요구 사항이 없거나 오래된 서면 요구 사항이 있습니다. 실제 문서는 일반적으로 구두 대화입니다. 누구와 이야기해야하는지 알아보십시오. 다른 사용자의 요구 사항이 상충하는 경우 행복하게 만드는 데 가장 중요한 사람을 찾으십시오.

---

• 알려진 ^{1 개의} 문제
• 알려진 ¹ 개 개선 영역
• 기준으로 사용할 기존 코드 커버리지 데이터, 테스트 통과율 등
• 문제 해결 팁 (로그 파일 이해, 충돌 디버깅, 일반적인 문제)
• 구성 매개 변수에 대한 설명

¹ 그 또는 그녀에게만 알려진

---

프로젝트를 인수 할 때 일반적으로 묻는 첫 번째 질문은 소스 제어에서 해제하는 방법입니다 (기본적으로 "어디에 있습니까?"). 그 외에는 모든 최고점을 달성했다고 생각합니다.

IDE 설정, 단위 테스트, 배포 메커니즘

질문 할 수있는 가장 중요한 것입니다.

어떤 웹 사이트가 당신이 맡고있는 웹 사이트에 영향을 주 었는지 물을 때, 링크 목록을 확인하십시오. 많은 개발자가 샘플링 한 사이트에 대한 북마크를 유지하는 것을 발견했습니다. 당신이 그것을 얻을 수 있는지 확인하십시오.

---

그것을 구축하고 릴리스 할 수 있는지 확인하십시오.

정보 누락 문제가 너무 많이 발생합니다.

You need to KNOW ALL THE ancillary stuff.

Get a fresh machine and make sure you can duplicate a build and release.

EDIT: after that it would be: "What are all the things you have been meaning to fix but did not get to and are not documented anywhere"?

---

Don't ask. Lock him in a room - instruct him that he will not get food or water until he starts from the beginning and tells you everything he knows about the system. Then ask relevant questions as they come up. After this - spend a couple of days looking at the code. Then repeat the process. Do this until you feel comfortable with the system.

---

• How you would install the site on a brand new server.
• What the site does & what it's used for.
• What databases are used & where they are.

---

Make sure to get all the "gotchas" for the application. They are often the data or business items that are too minute or quirky to have formal documentation, but wind up having big impacts or lots of debug time if you don't know what's going on.

For instance, in one of the applications I currently maintain, we interface with a third party system that has a "web viewer" type client. The "gotcha" with this is that the web viewer doesn't properly maintain the user's session state (broken when it was updated to their latest version to fix other critical issues). As a result, I have to remind the users from time to time to simply minimize the browser window so that the timeout occurs naturally, otherwise they will get locked out for a prolonged period of time until the Ops folks around here get the newer version installed.

---

What the biggest problems that the site has run into have been and how they were solved? It's way too easy to try and fix something that doesn't make sense at all only to discover that what appears nonsensical is actually the only fix for some subtle but nasty bug.

Going through the code and looking at anything that looks at all hard to understand and just asking "what does this do, why did you add it?"

Make sure you write down their responses - perhaps even comment them in the code so they are there when you need them. There is nothing more annoying than that feeling of "I know I was told about this..."

---

As well as the techy stuff (that's 'easy' to figure out :)) find out about the business rules! These are rarely documented properly (in my experience) and you usually only find out the hard way when something goes wrong.

---

2 to 3 days sounds short for the handover so don't be afraid to ask for more.

First get a working local environment with source control, ide, build and release steps all up on running locally.

Then try and get an impression of the code quality by going through it briefly. If it looks bad then you may not get so much useful information regarding the implementation from your predecessor.

However everything regarding deployments, db servers, backup strategy , registrations etc. should be checked. Also all licenses for libraries etc and also a list of the most common errors (if they have a bug tracker tool this may be useful)

Also you need to see how helpful your predecessor is as I've seen several styles of handover form ones where the person giving the handover was friendly but misleading to where they gave sarcastic answers to the questions asked of them in a form of a questionaire (which while funny wasn't professional) to just plain disinterested.

---

Looking at the code for 5mins is the best start, if the code is really well organized and commented, there might not be any reason to talk to him at all.

If the code is hideous, well don't expect any intelligent reasons why he hacked something together, at best you can use him as a reference for some cruddy code and asks what's the purpose.

Either way, talking to the past developer is the least useful thing to do because either way, you're stuck with it now.

---

Carefully review the application and try to figure it out first. Then go into your meeting with questions, and most importantly, context.

---

Have you been working at the same company?
If not, and this is not directly related to the project, but I'd ask him why he's leaving. It may give you some insight into the politics involved or if anything is bothering him working with it or with the client.

---

Ask about any roadblocks or work-arounds the original developer came across.

Learn about your customers as well. Are they picky? What do they expect?

ReferenceURL : https://stackoverflow.com/questions/436212/taking-over-a-project-what-should-i-ask-the-previous-programmer