3か月前のプロジェクトで自分が何をしていたのか、どうして覚えているのですか?


72

私は3か月前にプロジェクトに取り組んでいましたが、突然別の緊急プロジェクトが現れ、注意を向けるように頼まれました。

明日から、古いプロジェクトに戻ります。私は自分が何をしていたかを正確に覚えていないことに気付きます。どこから始めればいいのかわかりません。

振り返るときはいつでも、離れた場所から数分以内にプロジェクトを文書化できます。ベストプラクティスはありますか?


98
コメントとコミットメッセージ、人々がそれらを残すように言う理由がある
ラチェットフリーク14

5
これは、そもそもプロジェクトの追跡方法に依存していないのですか?メモリからすべてを行い、他のドキュメントは一切ないと仮定する必要がありますか?
ジェフ14

4
@ratchetfreak同じ原理を何にでも適用できることに気がつくまで、「これは開発者にのみ役立つ」と言いました。ほとんどのドキュメントリポジトリには、メモセクションまたは説明があります。電子メールを介した成果物にはメッセージ本文があります(多くの場合無視されます)。ドキュメントには、変更と注釈を追跡できます。PMの世界にもコメントとコミットメッセージのエコシステムがあります!</ひらめき>
corsiKa

6
バージョン管理システムを使用して、前回やったことを思い出させ、バグトラッカーを使用して、まだ何をする必要があるかを見つけます。
ライライアン14

2
そうそう、3か月の休職の後、就職の面接で最後のプロジェクトについて説明するように頼まれました。私はそれをやったが、彼らが詳細を尋ねたとき、私は彼らの人生を思い出すことができなかった。私はそれを覚えていない場合、明らかに私は偽物だから、彼らは私を断った。これは約15年前に起こりましたが、今でも覚えています。
アンドリューサビニク14

回答:


35

私はあなたの現在の状況では役に立たないだろういくつかのアドバイスを提供したかっただけですが、将来のために今すぐ実装を開始できます。

もちろん、todoリストや問題ログなどの明らかな候補があります。最近追加された問題を見ると、プロジェクトを中止したときに何をしていたのかがわかります。

私が取り組んできた以前のプロジェクトでは、品質管理プロセスの一環としてプロジェクトログを保持することが求められていました。内容はあまり明確に指定されていませんでしたが、そのアイデアは、将来の継続的な作業や完了時のレビュー活動に役立つかもしれないプロジェクトに関連するものの毎日のログを保持することでした。例えば:

  • プロジェクトの品質に関する観察

    このコードはリファクタリングを使用できます

    これを機能させるために簡単な実装を行いましたが、ABCの方が良いでしょう。

  • 課題トラッカーに正式に記録したくないTodoアイテム/課題

    「このメソッドを機能させる必要x < 0がありますが、現在は範囲外です。

  • 設計上の決定 -特に重要な決定

    標準の並べ替え関数はクイックソートを実行しますが、ここでは必要な並べ替え条件の下でアイテムの順序を保持しません。

    明らかなアルゴリズムはABCですが、xネガティブになる可能性があるためここでは失敗します。そのため、一般化された形式(Wikipediaリンク)が必要です。

  • 発生した問題とその解決方法。私個人の意見では、非常に重要なことです。問題が発生した場合は、ログに記録してください。

    コードをチェックアウトしましたが、エラーXYZ0123が発生したため、最初にコンポーネントCをバージョン1.2以降にアップグレードする必要がありました。

後者の2つのポイントは非常に重要です。私はよく似たような状況や問題に遭遇しました-時には完全に異なるプロジェクトで- 「うーん、これに1日を費やしたことを覚えていますが、再び解決策は何ですか?」

しばらくしてプロジェクトに戻ったときに、プロジェクトログを読み返すと(自分のものでも最新の開発者のものでも)、離れたときのフローに戻り、いくつかのトラップについて警告する必要があります。さもなければ再び落ちるかもしれません。


68

To Doリストは魔法です。一般に、プロジェクトごとにアクティブなTo Doリストを保持する必要があります。プログラミングに忙しいときでも、何かしなければならないことを考えてすぐにできない場合は、リストに追加します。このリストは、プロジェクトフォルダー内のスプレッドシートまたはテキストファイル、または紙のログブックなど、よく知られた場所に保管してください。

また、プロジェクトを夜通し(または週末に)離れる場合は、ポストイットメモを取り、そのメモに次にすることを書き、それをモニターに貼り付けます。これにより、翌朝すぐに戻ってくる可能性が高くなります。

編集

私は、to-doリスト(特に、開催地とプロジェクトごとに分けられた優先順位付けされたto-doリスト)が、Getting Things Doneブックの重要な部分であり、非常に影響力があると感じました。


22
また、小さなタスクでアジャイルプロジェクトに取り組んでいる場合、バックログはそのプロジェクトの主要なTo Doリストである必要があります。
バートヴァンインゲンシェナウ14

1
私は最近、あなたが最後の段落で述べたことをし始めました、そしてそれは私が朝に行くことを大いに助けました。
TMH 14

5
確かに。常に下り坂に駐車してください。それは習慣の問題です。コードまたはtodoリストで次に何をすべきかを自分で書き留めずにコードベースを離れることはありません。私がまだしなければならないことがわかっていることはすべて、ソース内のTODO(IDEが検出してリストとして表示できるコメントでTODO:規則を使用)または別のTODOリスト(Iすべてのプロジェクトに対して1つだけですが、分類および優先順位付けされています)。
ジョーリセブレヒト14

3
コード内のTODOは優れていますが、ごく小さなことでも、そこに配置することには熱心でなければなりません。持ってtodoそれらをダンプし、あなたのメイクファイルにターゲットすることも有用です。
Blrfl 14

4
trello.comは命の恩人です。先週何をしたか、今週何をすべきかを思い出すのに苦労している月曜日のMonringチーム会議でもです。それも無料です。
SimonGates

33

今何をする?

さて、明日から私は古いプロジェクトに戻り、自分が何をしていたのか、どこから始めたらいいのか覚えていないことに気付きます!

私の推測では、あなたは次のセクションのいずれも行っていません。そのため、todoリストの検索は機能しません。

  1. 一定期間ブロックします。これをカレンダーに入れて、プロジェクトのレビューに時間をかけます。これは、ドキュメント、コード、要件などを確認することです。
  2. 速度に戻るにはしばらく時間がかかります。関係者全員がこれを認識していることを確認してください。これ実現してください。
  3. 小さなタスクから始めます。何か小さなことをして、自信を取り戻しましょう。新しいアイテムのリストがある場合は、小さいアイテムから先に作業してください。これはあなたの自信を再構築するだけでなく、プロジェクトに慣れ親しむのにも役立ちます。

将来これを自分のために改善する方法は?

プロジェクトを文書化する方法を知りたいので、振り返るときはいつでも、離れた場所から数分で行くことができます!

まず、todoを追跡するシステムが必要です。そのようなシステムは今ありますか?現在のプロジェクトワークをどのように管理していますか?

明日はバスにぶつかる可能性があり、私のチームはアクションアイテムの90%をはるかに超える良いアイデアを持っているでしょう。これは、次のことを文書化するための凝集システムがあるためです。

  • すぐに行うこと(1週間未満のアイテム)
  • 「すてきな」todos
  • マイルストーンとマクロの仕事(具体的な意味がない場合)
  • 要件/会議メモ

さらに、VCSを使用し、必要に応じてコードをコメント化します。

私は主な開発者であるため、これは私と私のチームに有効です。チームで何らかの問題追跡システムを使用できます。または、アジャイルで作業する際のバックログ。たくさんのオプションがあります。これに本当に興味がある場合は、Getting Things Doneまたは他の関連するタスク管理方法論を読んでください。これは、あなたが説明していることによりほぼ正確に存在します。

ポイントは何ですか?

システムの詳細は、それが凝集システムであるよりも関連性が低いため、使用します。そしてそれを使用すること。そしてそれを使用します。これは重要。使用しない素敵な完璧なシステムよりも重要です。「私の仕事の大部分はここにあるが、一部は私の頭の中にある」ことをしないでください。そうしないと、プロジェクトに戻ることを嫌います。

また、コードの「何」だけではなく「なぜ」をコメントで説明するようにしてください。「これはIE8のバグを修正することです」と読み、技術的な詳細を単に説明するコメントよりもコードが何をするかを思い出す方がはるかに簡単です。


@TheIndependentAquariusは問題ありませんでした。その状況は圧倒的です。
エンダーランド14

@TheIndependentAquariusは、通常、コメントは多かれ少なかれポストイット/スティッキーを意図しているためです。Stack Exchangeが「この答えは素晴らしかった」と言うように設定する方法は、答えを支持するか受け入れるかです。ここでのコメントは、必ずしも長続きするものではありません。
エンダーランド14

この "to-do"リストのもっと合理化されたバージョンは、問題追跡システムを利用することです。多くの無料のシステムが利用可能であり、多くの無料のGitプロバイダーには、そのようなシステムがサービスに組み込まれています(GitHubを参照)。
BTownTKD

@BTownTKD私の答えで言う:)
enderland 14

その良い答えです。強調のために追加されました。
BTownTKD

14

私の意見では、コードプロジェクトを「再開」するには2つの部分があります。

  1. 中断した場所を特定する
  2. しなければならないことを思い出して

これは、バージョン管理を正しい方法で行っている場合、それが「他の頭脳」になることの1つです。

どこでやめましたか?コードを頻繁にコミットしている限り、最後の変更セットを確認してください。それはおそらくあなたの心の中で何かをジョギングします。そうでない場合は、最も古いコミットから順に、過去のいくつかを見てください。

左何をしなければならない、バックログは、その目的役立つはずである(またはto-doリスト、または何でもあなたはそれを名前を付けたいの。将来のための基本的項目)。

私はフルタイムのソフトウェア開発者ではありません。私は夜と週末にハッキングするプログラマーです。このため、仕事やその他のプログラミング以外のものが優先される場合、コードをひと目でプルアップすることなく、何日も何週間も行くことができます。上記は非常に効果的であることが証明されています。


10

これは完全な答えを意図したものではありません。VCSやプロジェクト管理ソフトウェアの使用方法など、重要なことを言及している非常に優れたものがすでにいくつかあります。他の人にも役立つと思います。

1.タスクが早すぎたり、小さすぎて書き留めたりできない

人々は通常、TODOは、彼らが行う予定のもののために示しています作る将来的には、しかし、プログラミングは濃度を必要とするため、私たちは中断することができますので、任意の時点で、私が書き留めて、それが役に立ったと評価していました、私が今やっているにも何または数秒で開始しようとしているもの。あなたは、ゾーンにいると感じて、あなたはおそらくそれだけであなたを打つそのソリューションを忘れることができなかったのAHAの瞬間が、あなたの同僚はあなたに彼の感染つま先の画像を表示するためにあなたのキューブによって低下したときに、あなたがしています自分の腕をかじり始めてようやく彼を取り除くことができるようになったのは、Post-It™のメモだけであったとしても、簡単なメモを書き留めておいたほうがよい場合があります。

もちろん、他のより永続的なメディアの方が良いかもしれません(私はOmniFocusが特に好きです)が、20分で終了してPost-It™を捨てたとしても、少なくともどこかにあることがポイントです。その情報が有用になること、クライアントにタイムシートや請求書を貼ったり、上司/クライアントがあなたが何に取り組んでいて覚えていないかを尋ねられたときに気づくかもしれません。これらすべてのメモをボックス、引き出し、またはフォルダーにドロップすると、大きな中断(中断プロジェクト)が発生したときに、それらを一目で確認して、コードを取得するために行った多くのことを思い出すことができますプロジェクトに戻ったときに見つけてください。

2.デスクでホワイトボードを使用して、全体像を把握します

机の横に3 "x 4"のホワイトボードがあるので、プロジェクトを開始するときに、プロジェクトで感じるすべての問題の解決策をブレインストーミングできます。それは、アーキテクチャ図、ユースケース、リスクと障害のリスト、またはあなたに関連があると思われるものです。

より形式化されたアプローチでは、紙または電子形式の「成果物」として図やユースケースなどを生成する必要がありますが、それにより多くの余分な作業が発生し、一連のサブプロジェクトになりますメインプロジェクトの実際の目的から離婚し、あなたがしなければならないが誰もあまり注意を払わない正式なプロセスのほんの一部です。ホワイトボードは、少なくとも私の経験では、実際に機能する最も単純なものです。それはあなたが望むように(カメラで)永続的であり、最も重要なことはあなたがすぐにあなたのアイデアをダウンさせることを可能にします。

ペンを手に持ったほうがいいと思うので、白い面に思いを投げかけるのは自然に思い浮かびますが、それがあなたに当てはまらない場合は、関連するものを判断するのに役立ついくつかの質問があります:

  • 私が主任開発者で、他の開発者がプロ​​ジェクトを完了している間に3か月間ハネムーンに行こうとしている場合、どのような一般的な方向性を与えたいですか?彼らが知っていることを確認したいアイデアや、彼らが取った方法を確認したいアプローチはありますか?どのライブラリまたは他の有用なソリューションを知っていることを確認したいですか?
  • このプロジェクトが私の将来の経済的自立を保証するという100万ドルのアイデアであった場合、3か月間無力化する重大な手術を予定されていました。プロジェクト?

(最初にアイデアを書き留めるとき、私はそれらが現在の自分に意味をなすことだけを心配します。いったんアイデアが落ちたら、私はそれらをより批判的に見て、変更を加えて自分の将来の自分や他の人に意味を持たせることができます。最初に書き留めるときに他の人コミュニケーションを取ることは、作家のブロックにつながる可能性があります-競合する目標によって詰まった心。

少なくとも3 "x 4"のまともなホワイトボードを購入し、通常作業をしているスペースに掛けるためにお金を使うことをお勧めします。物理ホワイトボードには、仮想システムと比べて多くの利点があります。

  • 大きいです。多くのスペースを使用することで、その存在感が感じられ、その計画はワークスペースの一部であるように感じられ、常に正しい方向にあなたを向けるのに役立ちます。
  • 常に存在します。特定のアプリやWebサイトにアクセスしてアクセスする必要はなく、アクセス方法を忘れたり、そこにあることを忘れたりするリスクはありません。
  • 考えたいアイデアがあればすぐにアクセスできます。

会議室でホワイトボードを使用し、携帯電話でスナップショットを撮ると、多くの利点が失われます。プログラミングでお金を稼ぐなら、まともなホワイトボードのコストに見合うだけの価値があります。

あなたが別のプロジェクトを持っている場合は、あなたのホワイトボードを埋めたものを中断し、あなたの携帯電話上のスナップショットに頼る必要があるかもしれませんが、少なくとも、あなたは持っているだろうことを 3ヶ月で「緊急」プロジェクトが終了したときに、あなたがする必要があります他に戻ります。ホワイトボードで再作成する場合は、おそらく15分しかかからず、プロセスで大幅に改善できる可能性があります。これにより、わずかな時間の投資が非常に価値があります。

3.プロジェクトを中断するコストを関係者に認識させる

飛行機のメタファーは役立つと思います。プロジェクトの開始と完了は飛行機の飛行に似ています。フライトの途中で脱出した場合、飛行機は空中に座って戻ってくるのを待つだけではなく、現在のプロジェクト/フライトから次のプロジェクト/フライトまで移動する何らかの方法が必要です。実際、フェニックスからファーゴへのフライトの途中で、デンバーからデトロイトへの別の飛行機に乗るためにそのフライトを中断する必要があると言われた場合、デンバーに最初の飛行機を着陸させる必要があります幸運にもあなたの飛行経路からそれほど遠くない-実際の中断が常にそうであるとは限らない)そして誰かが貨物と乗客をどうするかを理解しなければならない。彼らはただ座って永遠に待つのではありません。

プロジェクトのこの点は、あるプロジェクトから別のプロジェクトに移行するのに多大な時間を費やし、対処しなければならない多くの損失を残すことです。

このプロジェクトでは、あなたが仕事をしながら、あなたの頭の中に行くたくさん明らかにし、必然的にそこにあるすべての考えはない書かれたメディアにシリアライズすることができ、そしてないそれらの思考のすべてのイオタある直列化復元時にシリアライズさが残りますが。書面で自分の考えを部分的に捉えることはできますが、非常に損失の多い形式です。

問題(私が見るように)は、プロジェクトマネージャーや他のビジネスパーソンがプロジェクトを一連のステップと見なし、しばしばガントチャートに明示的な依存関係がない限り)順序を並べ替えることができ、人々の間で簡単に配布できることですまたはビジネスにとって最も便利になるまで遅らせます。

プログラミングを何度も行ったことのある人なら誰でも、ソフトウェアプロジェクトをレゴブロックのように扱うことができず、好きなように移動できることを知っています。少なくとも、空の旅の比theは、利害関係者が、気まぐれに並べ替えられる一連の異なるステップとして明確に扱うことができないことを考えることができる具体的なものを与えると思います。少なくとも、このような中断にはコストがかかるという点を理解しやすくします。もちろんそれは彼らの決定ですが、あなたは彼らがあなたに別のプロジェクトを与えるために1つのプロジェクトを中断する前にこれを認識させたいです。闘争するのではなく、役に立つ情報と開発者の役に立つ視点を提供し、あなたから必要なことは何でもできるようにしますが、伝えなければ知らない情報を提供するだけです。


要するに:

  1. あなたがしているすべて書き留めについてあなたは今まで、おそらくそれがダウンして書かれた必要とすることができるとは思わない場合でも、行うことを。短い鉛筆でさえ長い記憶を打ちます。
  2. 永続的にアクセスできる物理的なホワイトボードで全体像をブレインストーミングします。
  3. 意思決定者にそのような中断のコストがあることを認識させれば、プロジェクトの中断を避けることができます。少なくとも、再開するとプロジェクトに少し時間がかかることを彼らが知っているように期待を設定するでしょう。

1
利害関係者は、コード(後で)または他の誰か(いつでも)がプロジェクトを引き継ぐことができるように、コードをコメントおよび文書化しているプロの開発者に支払いをしていると想定します。もちろん、ほとんどの場合、彼らの仮定は間違っています。
ジェフ

そして、あなたはコメントして文書化すべきです!他の方法で提案しているとは思わなかったと思います。(ところで、私はあなたのコメントに同意します。)
iconoclast

2

3か月前のバージョン管理ソフトウェアでプロジェクトの履歴を調べることができます。コミットメッセージと最新のdiffを読んで、何に取り組んでいたのかを把握してください。


この答えが支持されなかったことに驚きました。バージョン管理ログは、プロジェクトが一時的に中断された数ヶ月前の誰かがどこにいたかを知る優れた方法です。明確なログメッセージは非常に役立ちます。変更されたファイルの差分とリストは、中断前にプロジェクトで何が起こっていたかのイメージを取得するための追加の方法です。最後に、バグ追跡システム(または単純なTo Do リスト)を使用する開発者の数と比較して、バージョン管理を使用する開発者が多く、この回答は、Scottの非常に支持された回答と比較して、より多くの人々にとって価値がありますホイットロック。
Arseni Mourzenko

2

問題管理システム(RedmineGitHubなど)と組み合わせて、適切な分岐およびマージ戦略を備えたソース管理システムを使用すると、行った変更を区分化し、方向性を与え、欠落している「コンテキスト」を次のように文書化できます。ワークフローの自然な部分。

  1. コードの変更を開始する前に、問題追跡システムに「問題」が記録されていることを確認してください。それはあなたの仕事の欠けている「私がやっていたこと」をカバーしています。
  2. ソース管理システムにブランチを作成し、そのブランチでの変更が前述の問題にのみ関連していることを確認します。これにより、変更を特定し、変更の履歴を提供して、「どこでやめたのか」という質問に答えることができます。後でその作業に戻ってきたら
  3. 変更が完了したら、トランクにマージして問題を閉じます。

1

たくさんの長い答えがあります。これは私に最も役立つものについての短いものです:

  • きれいなコード。
  • きれいなコード。
  • きれいなコード。
  • バージョン管理(差分とコミットのコメント)。
  • ポストイットノートまたはTodoリストまたはかんばんボード(TrelloおよびEvernoteなどを参照)

ただし、Diffs、Commitコメント、Post-It notes、Todo-Lists、またはKanban-Boardは、コンテキストがないために時間の経過とともに誤って解釈される可能性があります。したがって、最も重要なことは次のとおりです。

クリーンコード。


クリーンコードクリーンコード クリーンコードは、「3か月前のプロジェクトで何をしていたのか、なぜプロジェクトを忘れたのか」と、見逃したコンテキストをどのように助けますか?クリーンアーキテクチャクリーンアーキテクチャ クリーンアーキテクチャは、はるかに役立ちませんか?通常、最初に詳細に飛び込むことはありません。詳細を調べる前に全体像を把握することです。あいにく、遍在するおじさんはあなたを助けません。それにもかかわらず、私は他の2つの箇条書きに絶対に同意します。
JensG

@JensG:コードはアーキテクチャです。よく書かれたプログラムでは、functionのプログラムアーキテクチャの最上部を見ることができますmain。これは、かなりのサイズのプログラムではかなり抽象的です。その後、さらに深く掘り下げて、たとえばプログラムがそれ自体をクリーンアップする方法のアーキテクチャを確認できます。さらに、クリーンなコードとは、関数/変数/などを意味します。意味のある名前を持ち、その意味について声明を出す。私が代わりにSpaghetti / Write-Only-codeを書く場合、翌朝/月/年に目を覚まし、自分のコードを見ると、wtf-did-i-do-thereしか考えられません。それは同じだ...
phresnel

...本を読んだり書いたりする:Flesch-Kincaidの読みやすさのインデックスが10で意味がわからない、巨大なフレーズ、多くの複雑な単語構成、意味論ではなく構文に焦点を当てている、または読みやすいインデックスは約80なので、ストーリー自体の邪魔になりません。
フレネル

クリーンなコードの価値を私は見ています(そして、決して疑いません)が、アーキテクチャーであるコードには大きく反対します。コードはすべての標準で完全にクリーンで読みやすいものの、全体像を把握できない方法で記述できます。次に、質問は「自分が何をしていたかをどのように覚えるべきか」と「どこから始めればよいかわからない」でした。(クリーンな)コードの現在の状態と、OPが探しているものとの間に交差点はありません。アイデアから製品に至るプロセスの正確な中間点です。
JensG

@JensG:あなたの主張を認識しています。私たちは単に「自分が何をしていたのか正確に覚えていないことを認識している」と解釈を変えているだけだと思います。私にとって、これは「どのアルゴリズムとデータ構造をコーディングしたか、どのように拡張できるか覚えていないことを認識しています」と思われましたが、あなたにとっては、「私は何を覚えていないことを認識していますまさに私が実装しようとしていたのです」あいまいな人間の言語。...
フレネル

1

振り返るときはいつでも、離れた場所から数分以内にプロジェクトを文書化できます。

まず、これはプロジェクトにいくつかの高レベルの説明とコード構造があり、数分で簡単に把握できることを意味します-明らかな構造とコメントのない無数のコード行とは対照的です。

ベストプラクティスはありますか?

以下は、非常に小規模から非常に大規模なプロジェクトで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. プロジェクトが単一のコンポーネントを超えて成長し、より複雑な展開を行う場合は、設計とアーキテクチャのドキュメントを必ず追加してください。繰り返しになりますが、この目的は、詳細ではなく構造と依存関係を伝えることです。


0

プロジェクトの追跡、ToDoリスト、Trelloなどに関する提案に加えて、TDDを実践している場合は、プロジェクトに戻るたびに実装する新しい失敗したテストで常にプロジェクトから離れることが役立ちます、来週、または来月)

座って「テストの実行」を行い、中断したところから再開します。


1
これには2つの欠点があります。まず、継続的インテグレーションを使用する場合、失敗したテストを意識的にコミットすることは問題外です。第二に、あなたが複数のチームにいる場合、失敗したテストをコミットしても他の人は感謝しないかもしれません。
Arseni Mourzenko

1
@MainMa私はコミットを言わなかった。ただローカル。
ピート14

開発者への私の提案は、彼が数日間プロジェクトに取り組んでいないときにコミットすることです。物事が起こります。PCが盗まれたり、RAIDコントローラに障害が発生したために明日起動できない場合があります。あなたはプロジェクトを離れることができ、他の開発者があなたの代わりになるかもしれません。バスにぶつかる可能性があります。プロジェクトが場所を取りすぎているため、またはウイルスがOSを殺したために、プロジェクトをローカルで消去できます。いいえ、コミットされていないコードに依存することは選択肢ではありません。
Arseni Mourzenko

1
その後、@ MainMaはコミットし、という名前のブランチにプッシュしnext-stepsます。リビジョン管理アプローチの詳細についてのあなたの懸念が、何かに戻ったときにあなたの脳をキックスタートする助けとしての失敗したテストの基本的な前提とどう関係するのか分かりません。ここでも、これは、などのバックログ、TODOリストなどの標準的なアプローチに加えて、提案された
ピート

2
@MainMa:バージョン管理にはバックアップと多くの共通点がありますが、それは主な目的ではありません。バックアップシステムが必要で、バージョン管理の使用方法がその目的を達成できない場合は、Time Capsuleまたは同様のものを入手してください。VCSを強制的にバックアップとして機能させるためだけに強制的にコミットすることは決してしないでください。また、「すぐにすべてをコミットする」というポリシーに従っているため、それ以外の点で有益なことを行うことを妨げないでください。
iconoclast 14

0

コメント/ todoリスト/コミットに加えて、現実的であることが重要です。

サイズ、複雑さ、および作業を終了した状態によっては、プロジェクトの再開に時間がかかる場合があります。相互作用する多くのコンポーネントの実質的なコードベースの場合、フルスピードに達するには数日かかる可能性があります。

古き良き忍耐が役立つでしょう。

しばらくしてプロジェクトに戻って圧倒されたとき、私は通常、タスクの最も単純で最小の単位を選択して実装します。一度に多くのことを思い出そうとして迷子になるのを防ぎ、自信を少し高めます。たいていの場合、数時間でますます大きなタスクを自動的に拾い上げます。


0

私は自分がやった仕事の日記を毎日つけています。今日は何をしましたか、今日は困難でしたか、次のステップは何でしたか、未来のために今日どんなアイデアを持っていましたか。また、その日がどのようなものだったかについても少し説明します。興味深い会話や会議はありましたか?怒りや喜びがありましたか?これは、後で日記を読むときに物事を把握するのに役立ちます。

しばらくしてプロジェクトに戻ったときに、ジャーナルの最後のいくつかのエントリを読んで、プロジェクトの速度を確認しました。開発プロセスを思い出すには、これらの日々の詳細がすべて非常に重要です。彼らは、製品の使い方だけでなく、プロジェクトでの作業がどのようなものであったかを思い出させるので、todoリストや通常のプロジェクトドキュメントと比較して、大きな違いをもたらします。


ポイントが作られ、前11件の答えで説明した上で、これはかなりのものを提供していないようだ
ブヨ

0

私にとって、プロジェクトを再開する最も簡単な方法は、作業に関するメモを常に記録することです。Microsoftの「OneNote」は、メモのページを保持およびグループ化するのに特に適していることがわかりました。特に、検索バーを使用すると、何かに関するメモをすばやく簡単に見つけることができます。

OneNote内で、プロジェクトの進行を再開するのに役立ついくつかのことを次に示します。

  • 毎日/毎週のログ -毎日または毎週の進捗状況のログを保存して、プロジェクトですでに行った進捗状況を把握できるようにします。

  • To Doリスト -私は一般的なTo Doリストを持っていますが、私が取り組んでいるプロジェクト用に別のTo Doリストを保持して、プロジェクトのためにまだやっていることを覚えています。コードに// TODO:アイテムを残すこともあります。

  • プロジェクトノート -指摘事項には、問題/プロジェクトトラッキングアイテムへのリンク、コードスニペット、発生した問題、決定事項、解決策の計画と説明、コード変更のリスト、コードリポジトリディレクトリへのリンク、プロジェクトの電子メールおよびリンクが含まれますプロジェクトのドキュメント。

そのため、プロジェクトに戻るたびにメモを開くことができ、ほとんど瞬時にプロジェクトの進捗状況、残された作業量、思考の列を見ることができます。


-2

単純なプロジェクトの場合、これを行います。

  1. ルートディレクトリにある単純なREADMEファイル(したがって、バージョン管理にもなります)では、開発中に表示されること、つまり、やるべきこと、バグ、改善/アイデアなどに注意します。これは、プロジェクトをバックバーナーに配置する必要がある場合に最初に読むファイルです。
  2. TODO / FIXME / XXXコメント
  3. ToDoListもよく使う
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.