数週間前、私は次のようにツイートしました:
レビューを依頼されました:
これは基本的に、課題駆動型開発のために私が行っているワークフローです。
課題駆動開発
問題駆動型開発とは、より機能駆動型の開発であり、基本的には非常に簡単です:
何かをプログラミングする前に、まず機能について考え、課題を作成します。これがその名前の由来です。課題には、説明と必要なすべての側面を入れます。
通常、一度に複数の機能に対してこれを行うため、多数の問題を作成します。
そうして初めて、実際に何かをプログラミングし始めます。私は、最も緊急性が高い、または最も楽しい機能を選び、それを実装し始めます。
マイルストーンは、いつ何をするかを計画するのに役立ちます。
実装
私は自分のプロジェクトを管理するために github を使用しているので、そこで問題を報告できますが、それらを公開したくありません。
これにはいくつかの理由があります。
1 つは、私が実際にどのくらいの頻度でプロジェクトに取り組んでいるか、主要な機能を完成させるのにどれくらいの時間がかかるかを誰もが確認できることです。
もう 1 つの理由は、機能を詳細に説明しているときに、実際には実装についてあまり考えていないことがあるということです。そのため、合理的に実装できない機能を計画する場合があります。つまり、実装せずに問題をクローズする必要はほとんどないということです。予定されているすべての機能を誰もが見ることができ、最終的に私がやらないことに非常に興奮する可能性があります。
公共の機能計画は、私が望んでいない私にプレッシャーをかけるだけです.
そのため、プライベート イシュー マネージャーをホストする必要がありました。Twitter で調査した後、私は Gogs に行きました。Gogs は Github や Gitlab と同様の機能を提供し、見た目は Github に非常に似ていますが、Go で記述されています。これは、古い Raspberry 上で簡単に実行できることを意味します。本格的な代替手段の代わりに Pi を使用します。
メリット
私は実際、Issue または Feature Driven Development をずっと行ってきました。
しかし、以前の私の問題のストレージは、Google Keep のメモ、ホワイトボードまたは紙のテキストの組み合わせでした.明らかに、このアプローチは維持できませんでした.Gogs に切り替えることで、より整理されました.
イシュー駆動型の開発により、より構造化されたものになります。何をすべきかについて明確な計画があり、どれだけの進歩を遂げたかを簡単に確認できます。
そして、問題をクローズできるときは、いつでも気分がいいものです。
欠点
しかしもちろん、このアプローチにはいくつかの欠点があります。
新しいプロジェクトで最も注目に値すること:standardese では、内部の問題が多すぎます。そのほとんどは将来の機能に関するものです。実際にプログラミングするよりも、問題に多くの時間を費やしているように感じます!プロジェクトは非常に初期の開発段階にあり、ほとんどすべてが欠けています。
しかし、利点は明らかに優れています。何をすべきか明確な計画があります。
結論
これはかなり短く、非技術的なブログ投稿でした。経験を共有したかっただけです.
イシュー駆動型開発は私が考案したものではなく、昔からの慣行ですが、非常にうまく機能しています。