24

個人的なプログラミング プロジェクトを開始するとき、最初のステップは何ですか? 現時点ではアイデアにすぎないプロジェクトを開始しようとしています。私はこれらをたくさん手に入れ、すぐにコードに飛び込み、しばらくすると完全に興味を失ったり、プロジェクトのことを忘れたりします。

あなたが始めたとき、あなたの最初のステップは何ですか?プロジェクトを計画していますか?図を作る?紙にコードを書く?成功することがわかっている方法でプロジェクトを開始するにはどうすればよいですか?

4

14 に答える 14

16

私にとってうまくいく唯一のことは、何らかの形で使用できる可能な限り最小の実装を作成してから使用することです。

于 2008-09-13T22:52:26.457 に答える
11

非常に効果的な人々の7つの習慣から、習慣2:目的を念頭に置いて始める.

どんなプロジェクトでも、「終わった」と言える明確な目標が必要です。明確な結果はあなたに方向性を与えます。それができたら、そこにたどり着く方法を計画し始めることができます。プロジェクトの規模と複雑さによって、計画に必要な詳細が決まりますが、一般的には、計画に対する進捗状況をかなり定期的に感じたいと思うでしょう。

次のステップは、必要なモジュールと各モジュール間の API の設計をスケッチすることです。API がクリーンであれば、モジュールはおそらく正しいでしょう。次に、モジュールの実装を開始し、テストを行います。

于 2008-09-13T23:01:00.150 に答える
10

キーボードに触れる前に、プロジェクトのさまざまな側面について考えることに多くの時間を費やしています。

以前のプロジェクトから学んだことを調べて、さまざまなカテゴリ (「技術」、「プロモーション」など) に書き留めます。

個人的なプロジェクトであろうとなかろうと、私は常にソース コード管理を設定しています。Git、Bazaar の Mercurial は、マスター サーバーをセットアップする必要がないため、邪魔にならないソース コード管理ツールの例です。簡単なコマンドを入力してプロジェクトを作成し、ファイルをチェックインしてコミットするだけです。将来、ファイルの 1 つを台無しにすると、「元に戻す」ことができるようになります。

また、1.issues と 2.ideas を追跡するための軽量のチケット システムもセットアップしました。「軽量」とは、これらのリストを含む 2 つのテキスト ドキュメントを維持することがうまくいくのであれば、それで十分だということです。

お役に立てれば。

于 2008-09-13T22:42:20.990 に答える
3

プロジェクトの目標を定義します。問題ではなく、ほぼ例外なく解決策を見ているように聞こえます。

プログラムは、何らかの問題に対処しない限り、あなたや他の人にとっては役に立ちません。動くためのコードを書くことは素晴らしいことですが、始めた後は興味と集中力を失っているように見えます-問題ではなくコードを見ているからです。

このコードを書くようになったきっかけを考えて、時間をかけてください。他の人が同じニーズをどのように発見するのか、あなたが解決しようとしたのと同じ欲求不満にどのような道をたどるのかを考えてください。

次に、それらの人々の何人かを見つけて、あなたの(部分的な)解決策を提供してください。そうすれば、あなたはそれらすべての間で興味と提案を生み出すでしょう。

それはあなたがあなたのプロジェクトを続けるでしょう。仲間の関心、共有、さらには意見の不一致-ソフトウェアを必要としているのは人々です!問題(人)を探すソリューション(ソフトウェア)を作成しないでください。あなたはあなたの必要性や欲求を持ってあなたから始めましたが、コードに焦点を合わせ、プロジェクトの推進力を失いました。

問題を解決しているときは、プログラミングの方がはるかに楽しいです。しかし、あなたはあなたの目の前で問題を維持する必要があります。問題を共有することでコミュニティが構築されます。それが本当の意味ですよね?

于 2008-09-17T10:13:08.540 に答える
3

すでに与えられた次のアドバイスに同意します。

  • 最初の完全なリリースとして役立つことを行う最小限の実装を計画します。
  • 達成したいことについて具体的な目標を立てて、進捗状況と比較できるものを用意してください。

また、製品を構築する方法のロードマップを作成できるように、アーキテクチャ全体の軽量設計から始めることをお勧めします。

少なくとも分解の最初のレベルでどのように見えるべきかについて明確な考えがない場合、何かを構築し始めるのは難しいと思います。機能以外に何が必要かを考えてください: 高いパフォーマンス?、拡張性のシナリオ?、どのシナリオ?、使いやすさの目標?、高いスケーラビリティ?、展開とインストールの容易さ?など。それらの建築品質を達成するには?

誤解しないでほしいのですが、私はアジャイル ソフトウェア開発の強力な支持者です。アーキテクチャの設計に多くの時間を費やす必要はありません (構築するにつれて進化し、何が機能し、何が機能しないかについてのフィードバックを得る必要があるため) 。そのアーキテクチャは、進行状況を計画し、現実的な目標を設定するのに役立ちます。

于 2008-09-14T08:20:45.780 に答える
2

簡単 - 興味を失う可能性があるすべてのプロジェクトを開始しないでください。作業を開始する前に、アイデアにコミットしたいことを確認するために、より多くの時間を費やしてください。

于 2008-09-14T05:22:15.550 に答える
2

私自身の個人的なプロジェクトについては、ただ飛び込んでいきます。もちろん、事前計画が必要なほど大規模なものはまだありません。これが深刻なプロジェクトまたは比較的大規模なプロジェクトになる場合は、少なくともプログラムの各部分が何をする必要があるか、およびそれらがどのようにそれを行うかについての高レベルのビューをフラッシュすることは常に良い考えです.

于 2008-09-13T22:31:49.813 に答える
2

他のプロジェクトと同様に、私の個人的なプロジェクトには常に次のようなものがあります。

  • 最終目標
  • タスクリスト
  • 小さな使用可能なユニット
  • ソース管理

追加の動機として、今まで使ったことのないテクノロジーを使おうとしています。新しいことを学ぶことは、一般的に私にとって最大の動機になります。

于 2008-09-14T01:28:04.273 に答える
1

それはプロジェクトによって異なります - それはどのくらいの大きさですか?

もし私が次のメモ帳のクローンを書いているなら、私はただ飛び込むかもしれません.

私はたくさんの図を描くのが好きで、ほとんどの開発に使用するツールはきれいな A4 用紙と鉛筆です。UI、ワークフロー、基本クラス、およびデータを保存する方法を描画します。コーディングは、既に描画したものをコンピューターで読み取り可能な方法で記述したものにすぎません。

ソース管理レグ SVN は数回のキーストローク/クリックであるため、オーバーヘッドは低く、利点は高く、何かを試して、機能しない場合は以前の状態に戻すのに便利です。

次に、機能する最も基本的なプロトタイプを作成します。何かが実際に進行すると、熱狂してさらに追加するのがはるかに簡単になります。圧倒される場合は、頭の中で問題が解決したと思うので、それで十分です。

于 2008-09-13T23:35:53.997 に答える
0

上記のすべてですが、計画を適切に固め始めます.....

いくつかのツールSmartSheetを利用してください-自分で作業している場合でも、いくつかの段階と日付を設定する必要があります-そしてwww.yworks.comのGraphity

于 2011-03-24T12:40:58.853 に答える
0

あなたの個人的なプロジェクトが既存のオープン ソース プロジェクトに似ている場合は、代わりにそのプロジェクトに貢献することを検討してください。いくつかの小さな貢献 (バグ修正など) は、半分完成したプロジェクトよりも価値があります。

于 2008-09-14T11:59:41.697 に答える
0

最初に、最終的なアプリケーションの基本的な概要を計画します。最も重要な機能、基本的な GUI、プログラム フローなど。次に、最初はやりすぎないように改良し、不要な機能を削除し、最初のバージョンで必要なものを追加します。次に、そのアウトラインを使用してタスク リストを開始し、可能な限り最小の作業バージョンのアプリケーションを作成します。そうすれば、機能を追加して完全に機能させることがはるかに簡単になります。

于 2008-09-13T23:00:53.613 に答える
0

私はマキシミリアンの答えが好きです..少し拡大すると、私の個人プロジェクトは、私がすでに取り組んでいるものを解決するために開発されています。だから繰り返しの作業に飽きたら、ソリューションのプロトタイプを作成します。そしてそれを使用します。以前のプロジェクトの 1 つと十分に類似している場合は、できるだけ多くのコードを借りて、自分の作業のレベルを向上させ、より専門的なものにしようとします。

Fusion でのソース管理の使用も重要です。SVN のインストールには 2 分かかります。

于 2008-09-14T00:36:32.370 に答える
0

それを公開のオープン ソース プロジェクトに変えたい場合は、Producing Open Source Softwareを読むとよいでしょう (オンラインと印刷物の両方で入手できます)。

于 2008-09-14T01:41:29.153 に答える