나는 3 개월 전에 프로젝트를 진행하던 중 갑자기 또 다른 급한 프로젝트가 나타 났고 관심을 끌라는 요청을 받았습니다.

내일부터 이전 프로젝트로 돌아갈 것입니다. 나는 내가 정확히 무엇을했는지 기억하지 못한다는 것을 알고 있습니다. 어디서부터 시작해야할지 모르겠습니다.

되돌아 볼 때마다 내가 떠난 곳에서 나가는 데 몇 분 이상 걸리지 않도록 프로젝트를 어떻게 문서화 할 수 있습니까? 모범 사례가 있습니까?

나는 현재 상황에서 유용하지 않을 조언을 제공하고 싶었지만 앞으로 도움을주기 위해 지금 구현을 시작할 수 있습니다.

물론 할 일 목록 및 문제 로그와 같은 명백한 후보가 있습니다. 최근에 추가 된 문제를 살펴보면 프로젝트에서 해고되었을 때 무엇을했는지에 대한 힌트를 얻을 수 있습니다.

내가 작업했던 이전 프로젝트에서 사람들은 품질 관리 프로세스의 일부로 프로젝트 로그를 유지해야했습니다. 내용은 명확하게 명시되지 않았지만, 향후 지속적인 작업이나 완료시 검토 활동에 유용 할 수있는 프로젝트와 관련된 사항을 매일 기록하는 것이 좋습니다. 예를 들면 다음과 같습니다.

• 프로젝트 품질에 대한 관찰

  이 코드는 리팩토링을 사용할 수 있습니다

  이것이 작동하도록 빠른 구현을했지만 ABC 가 더 좋을 것입니다.

• 이슈 트래커에 공식적으로 기록하고 싶지 않은 할일 항목 / 이슈

  "이 방법은 효과가 x < 0있지만 현재 범위를 벗어났습니다.

• 디자인 결정 -특히 사소한 결정 .

  표준 정렬 기능은 빠른 정렬을 수행하지만 정렬 조건에서 동일한 항목 순서를 유지하지는 않습니다.

  명백한 알고리즘은 ABC 이지만 x음수 일 수 있으므로 일반화 된 양식 ( Wikipedia link )이 필요하므로 여기서 실패합니다 .

• 발생한 문제 및 해결 방법 내 개인적인 견해로는 매우 중요합니다. 문제가 생길 때마다 로그에 적어 둡니다.

  코드를 확인했지만 XYZ0123 오류가 발생했습니다. 먼저 구성 요소 C를 버전 1.2 이상으로 업그레이드해야합니다.

후자의 두 점은 매우 중요합니다. 나는 종종 완전히 다른 프로젝트에서 비슷한 상황이나 문제를 겪어 왔으며 "음, 나는 이것에 하루를 보낸 것을 기억하지만 해결책은 무엇입니까?"라고 생각했습니다.

잠시 후 프로젝트로 돌아올 때 프로젝트 로그를 읽으면 (자신의 최신 개발자이든 최신 개발자이든), 떠났을 때의 흐름으로 돌아가서 몇 가지 함정에 대해 경고해야합니다. 그렇지 않으면 다시 떨어질 수 있습니다.

해야 할 일 목록은 마술입니다. 일반적으로 각 프로젝트에 대해 활동적인 할 일 목록을 유지해야하며 프로그래밍 중일 때라도해야 할 일을 생각하고 즉시 할 수없는 일이 있으면 목록에 표시됩니다. 이 목록은 전자적으로 또는 프로젝트 일지에있는 스프레드 시트 나 텍스트 파일로 잘 알려진 곳에 보관하십시오.

또한 프로젝트를 밤새 (또는 주말 동안) 떠날 때마다 포스트잇 메모를 작성하고 메모에 다음에 할 작업을 작성하여 모니터에 붙입니다. 그러면 다음 날 아침에 빨리 다시 들어갈 가능성이 높아집니다.

편집 :

해야 할 일 목록 (장소와 프로젝트별로 분리 된 우선 순위가 지정된 할 일 목록)은 내가 가장 중요하게 생각 하는 Getting Things Done 책 의 핵심 부분입니다 .

지금 무엇을해야합니까?

이제 내일부터 나는 오래된 프로젝트로 돌아가서 정확히 내가 무엇을하고 있었으며 어디서부터 시작해야하는지 기억하지 못한다는 것을 알게되었습니다!

내 생각 엔 다음 섹션을 수행하지 않은 것입니다. 따라서 할 일 목록을 조회해도 작동하지 않습니다.

1. 일정 시간을 차단하십시오. 이것을 달력에 넣고 프로젝트를 검토하는 데 시간을 보내십시오. 문서, 코드, 요구 사항 등을 검토하는 중일 수 있습니다.
2. 속도를 회복하는 데 시간이 걸릴 수 있습니다. 관련된 모든 사람들이 이것을 알고 있는지 확인하십시오. 확인 당신이 이것을 실현.
3. 작은 작업부터 시작하십시오. 작은 일을함으로써 자신감을 회복하십시오. 새 항목 목록이있는 경우 작은 항목부터 먼저 작업하십시오. 이것은 자신감을 회복시킬뿐만 아니라 프로젝트에 대해 스스로를 다시 알게하는 데 도움이됩니다.

미래에 이것을 더 잘 만드는 방법?

프로젝트를 문서화하는 방법을 알고 싶습니다. 되돌아 볼 때마다 내가 떠난 곳에서 몇 분 이상 걸리지 않아야합니다!

먼저 할 일을 추적 할 수있는 시스템이 필요합니다. 지금 그런 시스템이 있습니까? 현재 프로젝트를 어떻게 관리합니까?

나는 내일 버스에 부딪 칠 수 있었고 우리 팀은 내 행동 아이템의 90 % 이상을 잘 알고있을 것이다. 내 문서화를위한 응집력있는 시스템이 있기 때문입니다.

• 즉각적인 할일 (<1 주간 항목)
• 할일 "좋다"
• 이정표 및 매크로 할 일 (구체적으로 의미가없는 경우)
• 요구 사항 / 회의 메모

또한 VCS를 사용하고 적절한 경우 코드를 주석 처리합니다.

이것은 기본 개발자이기 때문에 나와 팀에 효과적입니다. 팀에 일종의 문제 추적 시스템을 사용할 수 있습니다. 또는 애자일 작업시 백 로그. 많은 옵션이 있습니다. 이것에 정말로 관심이 있으시다면, 당신이 묘사 한 것들 때문에 거의 정확하게 존재하는 일이나 다른 관련 작업 관리 방법론을 읽으 십시오 .

점은 무엇인가?

시스템의 특성은 응집력이있는 시스템보다 덜 관련이 있으며 사용합니다 . 그리고 당신은 그것을 사용합니다. 그리고 그것을 사용하십시오. 이것은 중요합니다. 사용하지 않는 완벽한 시스템보다 더 중요합니다. "내 작품의 대부분은 여기 있지만 일부는 내 머릿속에 있습니다"를 수행하지 마십시오.

또한 의견은 코드의 "무엇"이 아닌 "왜"를 설명해야합니다. "IE8로 버그를 수정하는 것"을 읽고 기술적 인 세부 사항을 설명하는 주석보다 코드의 기능을 기억하는 것이 훨씬 쉽습니다.

제 생각에는 코드 프로젝트를 "다시 시작"하는 두 부분이 있습니다.

1. 중단 한 지점 결정
2. 해야 할 일을 기억

이것은 버전 제어를 올바르게 수행하는 경우 "다른 두뇌"가 될 것이라고 생각합니다.

어디에서 떠나 셨습니까? 코드를 자주 커밋하는 한 마지막 변경 세트를 살펴보십시오. 그것은 아마도 당신의 마음에 무언가를 조깅 할 것입니다. 그렇지 않은 경우 가장 오래된 재생 커밋부터 시작하여 지난 몇 가지를 살펴보십시오.

에 관해서는 당신이해야 할 남은 것 , 백 로그 (당신이 미래에 대한. 기본적으로 아이템을 이름을 원하는대로 또는 할 일 목록, 또는) 그 목적을 제공한다.

전임 소프트웨어 개발자가 아닙니다. 나는 밤과 주말에 해킹하는 프로그래머입니다. 이 때문에 작업이나 프로그래밍 이외의 것들이 우선 순위가 높아지면 때로는 코드를 한 눈에 풀지 않고도 며칠과 몇 주를 갈 수 있습니다. 위의 내용은 매우 효과적입니다.

이것은 완전한 대답이 아니며 VCS 및 프로젝트 관리 소프트웨어를 사용하는 방법과 같은 중요한 것들을 언급하는 아주 좋은 것들이 있습니다. 도움이 될 것입니다. 다른 사람들도 도움이되기를 바랍니다.

1. 적어 놓을 작업이 너무 빠르거나 작습니다

사람들은 일반적으로 앞으로 할 일에 대해 TODO 목록을 작성하지만 프로그래밍에는 집중이 필요하기 때문에 언제라도 중단 될 수 있기 때문에 지금하고있는 일 을 적어 두는 것이 도움이된다는 것을 알게 되었습니다. 또는 몇 초 만에 시작하려고하는 것 . 당신은 당신이 영역에있어 느낄 수 있으며, 당신은 아마도 단지에서 당신을 공격하는 솔루션을 잊지 수 아하 순간,하지만 동료는 당신에게 자신의 감염 발가락의 사진을 보여 큐브로 떨어질 때 , 당신은 자신의 팔로 starting 아 먹음으로써 마침내 그를 제거 할 수 있다면, Post-It ™ 메모에만 있더라도 빠른 메모를 작성했을 수 있습니다.

물론 다른 좀 더 지속적인 매체가 더 나을 수도 있지만 (특히 OmniFocus를 좋아합니다 ), 20 분 안에 끝내고 Post-It ™을 버려도 적어도 어딘가에 있어야합니다 . 이 정보가 유용하다는 것을 알 수 있지만, 시간표 나 송장을 고객에게 제출하거나 상사 / 고객이 작업중인 내용을 묻고 기억할 수없는 경우. 이 모든 노트를 상자 나 서랍 또는 폴더에 놓으면 큰 중단이 발생하면 (중단 프로젝트가 발생 했을 때) 이를 통해 한 눈에보고 코드를 가져 오기 위해 수행 한 많은 작업을 기억할 수 있습니다. 프로젝트로 돌아올 때 찾으십시오.

2. 책상에서 화이트 보드를 사용하여 큰 그림 아이디어를 포착하십시오.

책상 옆에 ​​3 "x 4"화이트 보드가 있으므로 프로젝트를 시작할 때 프로젝트에서 인식하는 모든 문제에 대한 솔루션을 브레인 스토밍 할 수 있습니다. 아키텍처 다이어그램, 사용 사례, 위험 및 장애물 목록 또는 관련성이있는 것으로 보일 수 있습니다.

좀 더 공식화 된 접근 방식을 사용하려면 다이어그램이나 유스 케이스 등을 종이 또는 전자 형식의 "전달 가능 제품"으로 생성해야하지만 추가 작업 이 많이 발생 하고 일련의 하위 프로젝트가 될 수 있습니다. 주요 프로젝트의 실제 목적과 이혼하는 것, 그리고 여러분이해야 할 일이지만 아무도주의를 기울이지 않는 공식화 된 프로세스의 일부일뿐입니다. 화이트 보드는 적어도 내 경험으로는 실제로 작동하는 가장 간단한 것입니다. 카메라를 사용하여 원하는만큼 지속적이며 아이디어를 즉시 내려받을 수 있습니다.

내 손에 펜으로 생각하는 것이 더 좋으므로 내 생각을 하얀 표면에 버리는 것은 자연스럽게 나에게 올 수 있지만, 그 경우가 아니라면 관련 사항을 결정하는 데 도움이되는 몇 가지 질문이 있습니다. :

• 다른 개발자가 프로젝트를 완료 한 상태에서 3 개월 동안 신혼 여행을하려고한다면 수석 개발자라면 어떤 일반적인 방향을 제시 하시겠습니까? 그들이 어떤 아이디어를 알고 있는지, 또는 그들이 접근했는지 확인하고 싶은 접근법은 무엇입니까? 그들이 알고있는 라이브러리 나 다른 유용한 솔루션은 무엇입니까?
• 이 프로젝트가 내가 미래의 재정적 독립을 보장 할 것이라는 것을 알고있는 백만 달러짜리 아이디어 였지만, 3 개월 동안 나를 무력화시킬 수있는 비판적 수술을 계획했다면, 성공적인 미래를 달성하기 위해 미래의 자아를 갖고 싶을 것입니다 프로젝트?

(아이디어를 처음 낙서 할 때, 나는 현재 자신에게 이해가되는 것에 대해서만 걱정합니다. 일단 다운되면 아이디어를 더 비판적으로보고 내 미래의 자기 자신이나 다른 사람들에게 의미를 갖도록 변화를 줄 수 있습니다. 처음에 적어 놓을 때 다른 사람 과 의사 소통하는 것에 대해 글을 쓰는 사람의 차단으로 이어질 수 있습니다. 경쟁 목표로 인해 마음이 막혔습니다.

알맞은 화이트 보드 (3 "x 4")를 구입하고 평소에 일하는 공간에 걸어 두는 것이 좋습니다. 모든 가상 시스템에 비해 물리적 화이트 보드의 많은 장점이 있습니다.

• 크다. 많은 공간을 차지함으로써 존재감을 느끼게하고 계획은 작업 공간의 일부인 것처럼 느껴져 항상 올바른 방향으로 안내합니다.
• 지속적으로 존재합니다. 특정 앱이나 웹 사이트에 액세스하여 액세스하지 못하므로 액세스하는 방법을 잊어 버리거나 그곳에 있다는 것을 잊을 위험이 없습니다.
• 당신이 생각하고 싶은 생각이 있으면 즉시 액세스 할 수 있습니다.

회의실에서 화이트 보드를 사용하고 전화기로 스냅 샷을 찍으면 많은 이점을 잃게됩니다. 프로그래밍으로 돈을 벌면 괜찮은 화이트 보드 비용이 든다.

다른 프로젝트가있는 경우 귀하의 휴대 전화에 스냅 샷에 의존해야 할 수 있습니다, 화이트 보드를 사용했습니다 사람을 방해하지만, 적어도 당신이해야 한다는 3개월에서 "긴급"프로젝트가 완료되면 당신은해야 다른쪽으로 돌아갑니다. 화이트 보드에서 다시 작성하려면 15 분 정도 소요될 수 있으며 프로세스에서이를 많이 개선 할 수있어 적은 시간의 투자만으로도 가치가 있습니다.

3. 프로젝트 중단 비용을 이해 관계자에게 알리십시오.

비행기의 은유가 도움이된다는 것을 알았습니다. 프로젝트를 시작하고 완료하는 것은 비행기를 비행하는 것과 같습니다. 비행 중반에 구제하는 경우 비행기는 비행기로 돌아 오기를 기다리는 동안 공기에 앉아 있지 않으며 현재 프로젝트 / 비행에서 다음 비행으로 이동할 수있는 방법이 필요합니다. 실제로 피닉스에서 파고까지 비행하는 도중에 덴버에서 디트로이트까지 다른 비행기를 타려면 해당 비행을 중단해야한다고 말하는 경우, 덴버에 첫 번째 비행기를 착륙해야합니다. 운 좋게도 비행 경로에서 멀지 않은 곳에 있습니다 (실제로 중단되는 경우는 아님). 누군가화물 및 승객과 어떻게해야하는지 알아 내야합니다. 그들은 앉아서 영원히 기다릴 수 없습니다.

프로젝트의 요점은 한 프로젝트에서 다른 프로젝트로 전환하는 데 많은 시간이 걸리고 처리해야 할 손실이 많다는 것입니다.

프로젝트에는 작업하는 동안 머리에 계속해서 많은 일이 발생하며 모든 생각 이 서면 매체로 직렬화 될 수는 없으며 직렬화 된 생각의 모든 iota 가 직렬화 해제 될 때까지 남아 있는 것은 아닙니다 . 생각을 글로 부분적으로 포착 할 수는 있지만, 이는 손실이 많은 형식입니다.

(내가 보는 것처럼) 문제는 프로젝트 관리자와 다른 비즈니스 사람들이 프로젝트를 종종 순서대로 재정렬 할 수있는 일련의 단계로 생각한다는 것입니다 (Gantt 차트에 명시 적으로 의존하지 않는 한) 사람들에게 쉽게 배포 할 수 있습니다 비즈니스에 가장 편리 할 때까지 지연됩니다.

많은 양의 프로그래밍을 수행 한 사람이라면 누구나 소프트웨어 프로젝트를 원하는대로 이동할 수있는 레고 ​​블록처럼 취급 할 수 없다는 것을 알고 있습니다. 나는 항공 여행의 은유가 적어도 이해 당사자들이 생각할 수있는 구체적인 정보를 제공한다는 사실을 발견했다. 최소한 그러한 중단에 대한 비용이 있다는 점 을 이해 하기 쉽게 만듭니다 . 물론 그것은 여전히 ​​그들의 결정이지만, 한 프로젝트를 중단시켜 다른 프로젝트를주기 전에이를 알고 자합니다. 싸우지 말고 개발자에게 도움이되는 정보와 유용한 관점을 제공하고, 필요한 것은 무엇이든 할 수 있지만, 말하지 않으면 알지 못하는 정보 만 제공하는 것입니다.

한마디로 :

1. 당신이있어 모든 것을 적어 대해 당신이 당신이 이제까지 가능성이 적어 필요가 있다고 생각하지 않더라도, 할을. 짧은 연필조차도 긴 기억력을 능가합니다.
2. 지속적으로 액세스 할 수있는 물리적 화이트 보드에서 큰 그림을 브레인 스토밍하십시오.
3. 당신은 할 수 당신이 그런 중단에 비용이 있음을 의사 결정자들이 인식하게하는 경우 프로젝트 중단을 방지하고, 그들이 당신이 그것을 다시 시작하면 프로젝트가 길어질 것입니다 알 수 있도록 적어도 당신은 기대치를 설정해야합니다.

3 개월 전부터 버전 관리 소프트웨어에서 프로젝트 기록을 조회 할 수 있습니다. 커밋 메시지와 가장 최근의 diff를 읽고 작업 내용을 알 수 있습니다.

적절한 분기 및 병합 전략과 함께 소스 제어 시스템을 사용하고 이슈 추적 시스템 (예 : Redmine 또는 GitHub ) 과 연계 하여 변경 사항을 분류하고 방향을 제시하며 누락 된 '컨텍스트'를 문서화하는 데 도움이됩니다. 워크 플로우의 자연스러운 부분.

1. 코드 변경을 시작하기 전에 문제 추적 시스템에 '문제'가 기록되어 있는지 확인하십시오. 여기에는 누락 된 "내가 무엇을했는지"조각이 포함됩니다.
2. 소스 제어 시스템에서 분기를 작성하고 해당 분기의 변경 사항이 위에 언급 된 문제와 만 관련이 있는지 확인하십시오. 이렇게하면 변경 사항을 격리하고 변경 내역을 제공하여 "어디에서 나갔습니까?"라는 질문에 대답 할 수 있습니다. 나중에 작업을 다시 시작하면
3. 변경이 끝나면 트렁크에 다시 병합하고 문제를 닫습니다.

긴 답변이 많이 있습니다. 이것은 가장 도움이되는 것에 대한 짧은 것입니다.

• 깨끗한 코드.
• 깨끗한 코드.
• 깨끗한 코드.
• 버전 관리 (diffs 및 commit 커밋)
• Post-It 메모 또는 Todo-List 또는 Kanban-Board (Trello 및 Evernote 참조)

그러나 Diffs, Commit comment, Post-It notes, Todo-Lists 또는 Kanban-Board는 시간이 지남에 따라 컨텍스트가 부족하여 잘못 해석 될 수 있습니다. 가장 중요한 것은 다음과 같습니다.

청소 코드.

되돌아 볼 때마다 내가 떠난 곳에서 나가는 데 몇 분 이상 걸리지 않도록 프로젝트를 어떻게 문서화 할 수 있습니까?

우선, 이것은 명백한 구조가없고 주석이없는 단순한 코드 행이 아니라 몇 분 안에 쉽게 파악할 수있는 높은 수준의 설명 및 코드 구조가 프로젝트에 있음을 의미합니다.

모범 사례가 있습니까?

다음은 매우 작거나 큰 프로젝트에서 20 년 이상 경력을 쌓아온 모범 사례이며 저와 제 팀을 잘 지원했습니다. 프로젝트가 성장함에 따라 나열된 순서대로 적용하십시오.

1. 버전 관리를 사용 하면 변경 사항을 언제, 누가, 언제 적용했는지에 대한 무료 기록을 얻을 수 있습니다. 또한 언제든지 이전 버전으로 쉽게 넘어갈 수 있습니다.

2. 언어 및 프로그래밍 환경에 따라 클래스, 모듈, 패키지, 구성 요소를 사용하여 코드를 모듈화 하십시오.

3. 코드를 문서화 하십시오. 여기에는 각 파일의 상단에 요약 문서 (이 기능은 무엇입니까? 왜? 사용 방법)가 포함되며 함수, 프로 시저, 클래스 및 메소드 (이 기능은 무엇입니까?) 인수 및 반환 값 / 유형? 부작용?).

4. TODOFIXME코딩하는 동안 추가 하고 주석 을 추가하십시오 . 이것은 필연적으로 코드베이스에 들어가고 나중에 WTF에 물어볼 이유가 무엇인지 기억하는 데 도움이됩니다 ! . 예 :

   //TODO shall actually compute X and return it
   ... some code that does not compute X yet (maybe returns a fixed value instead)
   
   //FIXME make this constant time instead of n^2 as it is now 
   ... some code that works but is not efficient yet
   

5. 모듈 / 오브젝트 / 시스템 등의 호출 순서와 같은 구조 및 복잡한 동작을 문서화 하기 위해 다이어그램 을 그리는 습관을들이십시오 . 개인적으로 저는 UMLet 을 사용하는 것이 빠르고, 멋진 그래픽을 생성하며, 가장 중요하게 방해하지 않기 때문에 선호 합니다 . 물론 작업을 수행하는 모든 그리기 도구를 사용해야합니다. 그러한 도면의 목적은 간결하게 의사 소통하는 것이며 시스템을 세부적으로 지정하지는 않는다는 것을 명심하십시오 (!!).

6. 초기에 단위 테스트를 추가하십시오 . 단위 테스트는 회귀 테스트뿐만 아니라 모듈에 대한 사용 설명서 형식이기도합니다.

7. 초기에 코드 외부 문서를 추가하십시오 . 프로젝트를 실행하고 개발하는 데 필요한 종속성, 설치 방법, 실행 방법을 설명하는 README로 시작하십시오.

8. 반복적 인 작업 을 자동화 하는 습관을들이십시오 . 예를 들어, 컴파일 / 빌드 / 테스트주기는 어떤 형태 (예 : JavaScript grunt, Python fabric, Java Maven) 로 스크립팅되어야합니다 . 이렇게하면 돌아올 때 빠르게 속도를 낼 수 있습니다.

9. 프로젝트가 성장함에 따라 소스 코드 문서를 생성 하여 문서를 추가하십시오 (일부 양식의 JavaDoc 스타일 주석 및 HTML 또는 PDF를 생성하는 적절한 도구 사용).

10. 프로젝트가 단일 구성 요소를 넘어 확장되고 배포가 더 복잡한 경우 디자인 및 아키텍처 설명서 를 추가 하십시오 . 이것의 목적은 미세한 세부 사항보다는 구조와 종속성을 전달하는 것입니다.

프로젝트 추적, ToDo 목록, Trello 등에 대한 제안 외에도 TDD를 연습하는 데 도움이되는 내용은 프로젝트에 돌아올 때마다 구현할 수없는 새로운 테스트 실패로 항상 프로젝트에서 벗어나는 것입니다 (내일) , 다음 주 또는 다음 달)

앉아 '테스트 실행'을하고 중단 한 곳을 찾으십시오.

주석 / 할 일 목록 / 커밋 외에도 현실적인 것이 중요합니다.

규모, 복잡성 및 작업 상태에 따라 프로젝트를 다시 시작하는 데 시간이 걸릴 수 있습니다. 많은 상호 작용하는 구성 요소의 실질적인 코드베이스의 경우 최대 속도를 달성하는 데 며칠이 걸릴 수 있습니다.

좋은 인내심이 도움이 될 것입니다.

잠시 후 프로젝트로 돌아와서 압도 당했을 때, 나는 일반적으로 가장 단순하고 작은 작업 단위를 선택하여 구현합니다. 그것은 한 번에 많은 것들을 기억하려고 노력하면서 길을 잃지 않도록하고 자신감을 조금 강화시킵니다. 더 자주, 나는 몇 시간 만에 점점 더 큰 과제를 자동으로 선택합니다.

나는 내가하는 일에 대한 일지를 매일 기록한다. 오늘 내가 한 일, 오늘 어려운 일, 다음 단계, 미래에 대한 아이디어는 무엇입니까? 또한 그 날의 모습에 대해 약간의 이야기를 추가합니다. 재미있는 대화 나 모임이 있었습니까? 분노 나 즐거움이 있었습니까? 이것은 나중에 저널을 읽을 때 상황을 파악하는 데 도움이됩니다.

잠시 후 프로젝트로 돌아 오면 저널의 마지막 몇 개 항목을 읽고 프로젝트를 빠르게 진행할 수 있습니다. 모든 작은 세부 사항은 개발 프로세스를 기억하는 데 매우 중요합니다. 이들은 제품을 사용하는 방법뿐만 아니라 프로젝트에서 작업하는 것이 무엇인지 상기시켜주기 때문에 작업 목록 또는 일반 프로젝트 문서와 비교하여 많은 차이를 만듭니다.

저에게있어 프로젝트를 재개하는 가장 간단한 방법은 작업 내용을 지속적으로 기록하는 것입니다. Microsoft의 'OneNote'는 메모 페이지를 유지하고 그룹화하는 데 특히 좋습니다. 특히 검색 막대를 사용하면 무언가에 대한 메모를 빠르게 찾을 수 있습니다.

OneNote에서 프로젝트 진행을 다시 시작하는 데 도움이되는 작업은 다음과 같습니다.

• 일일 / 주간 로그 -일일 또는 주별 진행 로그를 보관하여 프로젝트에서 이미 진행 한 진행 상황을 파악할 수 있습니다.

• 할 일 목록 -일반적인 할 일 목록이 있지만 작업중인 프로젝트에 대해 별도의 할 일 목록을 유지하여 프로젝트에서 아직 수행하지 않은 작업을 기억합니다. 때로는 // TODO : items를 코드에 남겨 둡니다.

• 프로젝트 노트 - 내가 프로젝트 및 링크에 대한 발행 링크 / 프로젝트 추적 항목, 코드의 조각, 발생한 문제의 의사 결정, 계획과 가능한 해결책에 대한 설명, 코드 변경의 목록, 저장소 디렉토리를 코드에 링크, 이메일 등 참고 사항 프로젝트 문서.

따라서 프로젝트로 돌아갈 때마다 노트를 열 수 있으며 프로젝트에서 얼마나 많은 진전이 있었는지, 얼마나 많은 작업이 남아 있고 내 생각의 기차를 볼 수 있는지 거의 즉시 알 수 있습니다.

간단한 프로젝트의 경우 다음과 같이합니다.

1. 루트 디렉토리에있는 간단한 README 파일 (따라서 버전 제어로 끝날 것입니다). 개발 중에 나타나는 모든 것, 할 일, 버그, 개선 / 아이디어. 프로젝트를 백 버너에 놓아야 할 첫 번째 파일입니다.
2. TODO / FIXME / XXX 댓글
3. 나는 종종 ToDoList를 사용한다