プロジェクトを切り替える/プロジェクトに頻繁に戻る場合のベストプラクティスは何ですか?


8

私の仕事の本質は、数週間ごとにプロジェクトを切り替えなければならないことです。私の生産性に対する最大の障害の1つは、関連するすべてのコードを一定期間表示しなかった後、再び「頭の中で」元に戻すための立ち上げ時間であることがわかりました。これは、より短い休憩/より長い休憩では、より小さな範囲で発生します。

明らかに、優れた設計、ドキュメント、コメント、および物理構造がすべてこれに役立ちます(プロジェクトの切り替えをできるだけ頻繁に行うことは言うまでもありません)。しかし、私が見逃している可能性のあるプラクティス/ツールがあるかどうか疑問に思っています。これを改善するための具体的な方法は何ですか?

回答:


7

私はさまざまなプロジェクト(技術と非技術の両方)を頻繁に切り替えます。整理または「検索のしやすさ」が私にとって重要でした。プロジェクトを終了する前に、状況を頭に戻せるように、物事を整理しておくことを確認します。私にとって、これはすべての関連するもの(ブックマーク、ファイル、ドキュメント、電子メールなど)またはそれらへのリンクを1つのフォルダーに入れて、情報源を探す必要がないようにすることを意味します。

最近始めたのは、大規模なプロジェクトごとに1つの仮想マシンを使用することです。別のプロジェクトに切り替える必要がある場合は、関連するすべてのアプリを開いたままにして、仮想マシンを一時停止します。したがって、プロジェクトに戻る必要がある場合は、VMを起動すると、画面にすでに表示されているすべての情報が表示されます。


VMの
適切な

4

役立ついくつかのこと:

  • 読みやすさと明確さのためにコードを最大限に最適化します。
  • コメントの形で、ポインタとヒントをコードに残します。
  • KISSとDRYをフォローしてください。
  • 各プロジェクト内およびプロジェクト間で一貫している。
  • リファクタリングについて宗教的になる。
  • すべてを文書化します。あなたの将来の自分を、現在の自分に質問する方法のない別の人だと考えてください。
  • IDE /エディタを壊す「賢い」コードを避けてください。
  • ソース管理を使用して、正確にどこに置いたかを知らせるコミットメッセージを使用します。出荷可能と見なすバージョンにタグを付け、出荷可能バージョン間の短い期間を目指します。
  • プログラミング言語を選択できるようになった場合は、適切な処理に役立つ言語を選択してください。
  • これは個人的な好みの問題ですが、私にとってはうまく機能するので、とにかくおすすめします。次のタスクを含むシンプルで簡潔なテキストドキュメントを保管し、タスクが完了するたびに更新してください。また、このドキュメントは、コードのコメントに収まらない設計レベルのメモにも使用してください。基本的に、このテキストドキュメントにはデザイン全体が凝縮された形式で含まれている必要があります(理解するには十分な情報ですが、10分以内にサドルに戻れるように十分に短い情報です)。バグトラッカーも機能しますが、テキストドキュメントにはいくつかの利点があります。つまり、綿毛をカットして関連するものに集中する必要があり、実際のコードと一緒にソース管理にコミットすることができます。 SCMバージョン。

素晴らしいポスト。「IDEを破壊する可能性のある賢いコードを避ける」ことを明確にできますか?
ozz

1

私はRonEと同じようなことをしています。

プロジェクトが読みやすく、デザインが良いと役立ちますが、プロジェクトを終了する前に、頭の中にあるすべてのコンテキストと情報が書かれているか、どこかに保存されていることを確認してください。たとえば、これまでに使用したことがない新しいものである場合、使用していたサードパーティのライブラリ関数に関するメモ。自分が学んだり考えたりすることについては、常に自分の言葉でメモを書きます。

また、ファイルに書き込むことが最も重要だと思うのは、コードにTODOコメントを記述し、最後に作業していたコメントをコピーして、新しいテキストファイルに貼り付け、TODOという名前を付けることです。TODOタグがどこに属しているかに関するコンテキスト情報を記述し、自分の考えたこと、またはそのタスクについて知りたいと思うことを書きます。


0

私にとって重要なのは、一貫性と仕様の2つです。

コードの一貫性は重要です。自分がやったことを推定できる場合、すべてがどこにあるか、すべてがどのように相互作用するかを覚える必要はありません。面倒になるのが他の人とのプロジェクトの場合、コード標準はかなり役立ちます。それを見て何か安全な仮定をすることで何かがわかると、オンボーディング時間が少し短縮されます。

仕様は設計に役立ちます。少なくとも私にとっては、休憩後の製品デザインのニュアンスを忘れがちです。または私が戻ったとき、プロジェクトにすぐに忍び寄るこの素晴らしいアイデアが原因です。プロジェクトに適切な要件がない場合(ウォーターフォール仕様または製品バックログのいずれか)、プロジェクトに戻るたびに、基本的にこれらを再発明する必要があります。ソフトウェア開発のベストプラクティスのほとんどすべてが、個人プロジェクトの場合でもベストプラクティスです。それらをけちるしないでください。


0

重要なIMOは、すべてのプロジェクトのスマートAPIです。また、コードをGITなどのリポジトリにアップロードすると、コードへのコミットを通じて「タイムトラベル」することができます。


0

私は複数のクライアントの開発とプロダクションサポートを行っているため、1日に複数回プロジェクトを切り替えています。最も役立つ2つのことは、すべてを保存するまで1つのプロジェクトを離れることはありません(ローカルブランチがコミットされていない場合は、ソース管理のメインブランチに戻します)。中断した場所にブレークポイントを設定します。中断した正確なラインをすばやく見つけることができるので、プロジェクトのスイングにすばやく戻ることができます。私はまた、主要なプロジェクトごとにToDoリストを作成し、完了時にチェックする傾向があるため、これを簡単に確認すると、自分がどこにいるかがわかり、プロジェクトの思考プロセスを思い出すことができます。また、一般的に、自分が考えていたけれども、必要に応じてまだ完了していないことについて、自分に簡単なメモを書きます(次のようなもの:

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.