小規模プロジェクト向けのソロ開発者向けプログラミング方法論は何ですか?
4506 次
9 に答える
24
チームを明示的に必要とするもの (サイド バイ サイド プログラミングなど) を除いて、ほぼすべての開発方法論がソロ環境で機能します。しかし、その場合でも、架空の友人やチームメイトを作成するか、多重人格障害を発症するだけで、それを回避できます.
于 2009-06-12T14:59:44.580 に答える
12
単独の開発者であっても、大規模な開発チームに適用される方法論を使用できます。
- スペックを書く。
- UML をレイアウトします。
- 鉛筆と紙の UI デザインを行います。
- 廊下でのテスト: 大勢の人が集まると予想される場合は、使いやすいかどうかママに尋ねてください。
- ピア レビュー: 他の単独開発者とアドホック レビュー チームを構築できます。
- 最新のスケジュールを維持します。
- 等々...
私は常にソロで開発を行っており、これらのプラクティスにより、自分の仕事と歩調を合わせることができ、上司は自分が何をして、どこまで進んでいるかを知るための優れたリソースを得ることができます. そして、彼らは私を軌道に乗せてくれます。
于 2009-06-12T14:59:22.367 に答える
12
ラバーダックの方法論が思い浮かびます: http://lists.ethernal.org/oldarchives/cantlug-0211/msg00174.html
于 2009-06-12T14:59:51.133 に答える
9
多くのアジャイル手法は単独でうまく機能します。
- ユーザーのインタビューとストーリー:ユーザーが何を望んでいるかがわからない場合、そのソフトウェアはなぜ役立つのでしょうか?
- シンプルな仕様:または、単にミッション ステートメントにすることもできます。「人々が短いメッセージを購読者リストにブロードキャストできるようにします。」"in-degree を使用してインターネット検索結果を並べ替えます。" 「人々が協力してプログラミングの質問に答えられるようにしましょう。」なんでもいい。
- 厳密に並べられた ToDo リスト:考えに溺れるのを防ぐのに役立ちます。
- Tangents log:良いやることリストには「やらないこと」の要素が含まれているので、(まだ) やろうとしないことに執着することはありません。
- YAGNI:狙いを定めろ。これは、自分で作業する場合に非常に重要です。なぜなら、「いいえ! Java で動的型付けを再発明するな! プロジェクトに戻れ」と言う人は誰もいないからです。禁止事項リストはこれに役立ちます。
- テスト駆動型開発:テストを作成すると、実装の詳細に行き詰まるのではなく、最終結果について考える必要があります。とにかく、十分に行き詰まるでしょう。悪化させる必要はありません。
- 頻繁なリリース:締め切りを守りましょう。「金曜日までに、ユーザー ストーリー 1 ～ 4 を含む完全な機能を備えたバージョンを用意します。ネットワークに接続したり、データをディスクに保存したりしませんが、XYZ...」
- ユーザーテスト:かなり頻繁なスケジュールで、あなたが作っているものを友達に見てもらいます。友達の数やビールやピザをどれだけ食べさせたいかにもよりますが、月に 1 回、毎週かもしれません。ソフトウェアを使用するときは、彼らが何を言い、何をし、何を考えているかに細心の注意を払ってください。
また、大規模なプロジェクトでのみ意味があると思われるその他のことも、大いに役立ちます。
- ソース管理: gitをインストールします。骨の髄までシンプルです。これを使って。それに執着しないでください。
- オフサイト バックアップ:わかりました。住宅火災や水害の場合。
- ブログ:ただし、リリースが公開された場合にのみ、そこに書き込むことができます。;) また、出荷前に製品のオーディエンスを構築するのにも役立ちます。
お役に立てれば！大規模なプロジェクトでのソロ プログラミングは、非常に困難な場合があります。
于 2009-06-12T15:31:13.147 に答える
7
このスタック オーバーフローの質問に記載されている内容に従ってください。
また。ソース管理を使用します。私が個人的なプロジェクトで何回それに噛まれたか信じられないでしょう.
于 2009-06-12T14:59:28.340 に答える
2
于 2009-06-12T15:01:07.027 に答える
1
これは方法論というよりもトリックです。デバッグ中は、同僚に説明しようとしているかのように、大声でバグを自分自身に説明してください。ばかげているように感じますが、問題を大声で明確に表現するように強制すると、多くの場合、問題が何であるかが明らかになります.
于 2009-06-12T15:58:06.140 に答える
1
問題は、あなたが何に慣れていて、どのような問題を解決したいのかということです. ほとんどの方法論は、ある時点で単独の開発者によって使用されます (ペア プログラミングは顕著な例外です)。問題は、あなたが実際に一人なのか、それとも一人で働いているのかということです。アイデアを跳ね返すことができる人がいることは非常に貴重であることがわかりました. さらに、他の人に自分のコードを見てもらう (ピア レビュー) ことは、「見る」ことができない問題を見つけるための優れた方法です。したがって、Aiden Bell に同意するには、「oen でのプログラミングはクールではありません」。 他の人のアイデアを跳ね返すことができるコミュニティ (SO など) に接続しようとします。次に、アイデアを送信するときに中断できるように方法論を構築する必要があります。
それは理にかなっていますか？なぜ一人でプログラミングをしているのですか？
パット・オー
于 2009-06-12T15:20:55.560 に答える
1
正式な方法論ではありませんが、私は多くの個人開発 (独立したコンサルタントと ISV) を行ってきました。ここに、重要であることがわかったものを示します。
- 考えやアイデアを共有するオンライン組織 ( oisv.comなど) を見つける
- 現実世界の実際の人々と交流する時間をとってください。
- プロジェクトの目標、期限、マイルストーンを設定する
- 時間をかけて適切な事前設計とプロジェクト計画を行う
- 設定された労働時間はそれらに固執しています
- 働きすぎて燃え尽きないで
- 完璧なものはありません。完璧ではなく、機能する優れたコードを目指してください。
- プログラミング以外の趣味を持つ
于 2009-06-12T15:29:46.863 に答える