ソフトウェアプロジェクトの最初に物事を正しく行うにはどうすればよいですか？
私は1年の経験を持つプログラマーですが、最近、プロジェクトを正しく開始することはほとんどありません（ほとんどのサイドプロジェクト）。通常、プロジェクトサイクルは次のようになります。
- いくつかのユースケースから始めます
- コーディングを開始
- 私がうまく処理できず、現在のコードベースにうまく適合しないいくつかのことを理解してください。
- コードの大部分を書き直す
そしてこれは数回行くかもしれません
だから私の質問は
- そのような慣習は一般的ですか、それとも私が能力がないことを意味しますか？
- どうすればこの面で自分を改善できますか？
あなたが説明するサイクルは正常です。物事を改善する方法は、このサイクルを回避することではなく、それを合理化することです。最初のステップはそれを受け入れることです：
- プロジェクトの初日everythingを知ることはほとんど不可能です。
- 何とかしてすべてを知っていても、プロジェクトが完成するまでにsomething（クライアントの要件、彼らがいる市場、あなたが取り組んでいる技術、彼らの顧客の希望） ）が変更され、無効または正しくないことがわかっているものの少なくとも一部が作成されます。
したがって、すべてを事前に計画することは不可能であり、たとえ計画できたとしても、その計画に従うと、不完全または時代遅れの何かを構築することになります。これを知って、変更を計画に統合します。あなたのステップを見てみましょう：
- いくつかのユースケースから始めます
- コーディングを開始
- 私がうまく処理できず、現在のコードベースにうまく適合しないいくつかのことを理解してください。
- コードの大部分を書き直す
それは実際には素晴らしい出発点です。これが私がそれに取り組む方法です：
1.いくつかのユースケースから始めます
良い。 「ユースケース」と言うことで、ソフトウェアが何であるかに焦点を当てていますfor。 「いくつか」と言っても、すべてを発見しようとしているわけではありません。あなたは扱いやすい量の仕事にこだわっています。ここで追加するのは、それらに優先順位を付けることだけです。クライアントまたはエンドユーザーと一緒に、この質問に対する答えを考え出します。
あなたの状況を改善するために私があなたに与えることができる最小で最も単純なソフトウェアの一部は何ですか？
これはあなたの実行可能な最低限の製品-これよりも小さいものはユーザーにとって役に立ちませんが、大きいものはあまりに早く計画しすぎるリスクがあります。これを構築するのに十分な情報を取得してから、次に進んでください。この時点ではすべてを知っているわけではないことに注意してください。
2.コーディングを開始します。
すごい。あなたはできるだけ早く働き始めます。あなたがコードを書くまで、あなたのクライアントは何の利益も受け取りませんでした。計画に費やす時間が長くなるほど、クライアントは返済なしで待機するのに時間がかかります。
ここでは、goodコードを書くようにリマインダーを追加します。 SOLID Principles を覚えて従い、壊れやすいものや複雑なものについてまともな単体テストを書き、忘れがちなものや後で問題を引き起こす可能性のあるものについて書き留めます。変更によって問題が発生しないように、コードを構造化する必要があります。これを行うには、何かを構築することを決定するたびにthatの方法ではなくthisの方法で、その決定によって影響を受けるコードをできるだけ少なくするようにコードを構成します。一般に、これを行うための良い方法は、コードを分離することです。
- シンプルで個別のコンポーネントを使用します（言語と状況に応じて、このコンポーネントは関数、クラス、アセンブリ、モジュール、サービスなどになります。また、たくさんの関数を持つクラス、またはたくさんのクラスを持つアセンブリ。）
- 各コンポーネントは1つのジョブ、または1つのことに関連するジョブを実行します
- 1つのコンポーネントの内部動作を変更しても、他のコンポーネントを変更する必要はありません。
- コンポーネントはfetchingまたはcreatingではなく、givenそれらが使用または依存するものである必要があります
- コンポーネントはfetching情報と自分で作業するのではなく、他のコンポーネントにgive情報を提供して作業を依頼する必要があります
- コンポーネントは、他のコンポーネントの内部動作にアクセスしたり、使用したり、依存したりするべきではありません。公開されているアクセス可能な機能のみを使用してください。
これを行うことで、変更の影響を分離して、ほとんどの場合、問題を1か所で修正でき、残りのコードは気付かないようになります。
3.デザインの問題または欠点に遭遇します。
これが起こります。やむを得ない。これを受け入れます。これらの問題の1つを見つけたら、それがどのような問題であるかを判断してください。
いくつかの問題は、ソフトウェアが行うべきことを実行するのを困難にするコードまたは設計の問題です。これらの問題については、戻って設計を変更して問題を修正する必要があります。
いくつかの問題は、十分な情報がないか、またはあなたが前に考えていなかった何かを持っていることが原因です。これらの問題については、ユーザーまたはクライアントに戻って、問題への対処方法を尋ねる必要があります。答えがわかったら、それを処理するように設計を更新します。
どちらの場合も、コードのどの部分を変更する必要があるかに注意を払う必要があり、さらにコードを書くにつれて、将来変更する必要のある部分について考える必要があります。これにより、相互にリンクしすぎている可能性のある部分や、より分離する必要のある部分を簡単に特定できます。
4.コードの一部を書き直す
コードの変更方法を特定したら、変更を加えることができます。コードを適切に構造化している場合、これには通常1つのコンポーネントのみの変更が含まれますが、場合によってはいくつかのコンポーネントの追加も含まれることがあります。多くの場所で多くのことを変更しなければならないことがわかった場合は、その理由を考えてください。このコードをすべて内部に保持するコンポーネントを追加して、これらすべての場所でそのコンポーネントを使用することはできますか？可能であれば変更してください。次回この機能を変更する必要がある場合は、1か所で変更できます。
5.テスト
ソフトウェアの問題の一般的な原因は、要件を十分に理解していないことです。これは多くの場合、開発者の責任ではありません-多くの場合、ユーザーは自分が何を必要としているのかわかりません。これを解決する最も簡単な方法は、質問を逆にすることです。 「ソフトウェアに何をする必要があるか」と尋ねる代わりに、これらの手順を実行するたびに、これまでに作成したものをユーザーに提供し、「私はこれを作成しました-必要なことを行いますか？」と尋ねます。彼らがイエスと言うなら、あなたは彼らの問題を解決する何かを構築しました、そしてあなたは仕事をやめることができます！彼らがいいえと言った場合、彼らはあなたのソフトウェアの何が悪いのかをより具体的な言葉であなたに伝えることができ、あなたはその特定のことを改善し、より多くのフィードバックを得るために戻ってくることができます。
6.学ぶ
このサイクルを進むときは、見つけている問題と加えている変更に注意してください。パターンはありますか？あなたは改善できますか？
いくつかの例：
- 特定のユーザーの視点を見落としていることに気づいた場合、そのユーザーを設計段階により深く関与させることができますか？
- テクノロジーとの互換性を保つために物事を変更し続ける必要がある場合、コードとそのテクノロジーの間のインターフェースを構築するためにインターフェースを変更するだけでよいですか？
- ユーザーがUI内の単語、色、画像、その他のことについて考えを変え続ける場合、それらをすべて1か所にまとめるように、残りのアプリケーションにそれらを提供するコンポーネントを作成できますか？
- 変更の多くが同じコンポーネントにあることがわかった場合、そのコンポーネントは1つのジョブのみに固執していますか？それをいくつかの小さな部分に分割できますか？他のコンポーネントに触れることなく、このコンポーネントを変更できますか？
アジャイルになる
ここに向かっているのは、アジャイルと呼ばれる作業スタイルです。アジャイルは方法論ではありません。それは、さまざまなもの（スクラム、XP、カンバンなど）を組み込んだ方法論のファミリーですが、それらすべてに共通しているのは、物事が変化するという考え方です。変更を回避または無視するのではなく、変更に適応するように計画する必要があります。その中核となる原則のいくつか（特に、状況に関連するもの）は次のとおりです。
- 自信を持って予測できるよりも先に計画しないでください
- あなたが行くにつれて物事が変化することを考慮に入れてください
- 大きなものを一度に構築するのではなく、小さなものを構築してから段階的に改善する
- エンドユーザーをプロセスに関与させ続け、定期的かつ迅速なフィードバックを得る
- あなた自身の仕事と進歩を調べて、あなたの過ちから学びなさい
これは正常です。
次の2つの方法のいずれかをとることができます。
- ようこそ変更
間違っていると思われる場合は、変更可能なオープンなコードベースをビルドする必要があります。ほとんどの場合、これにはリファクタリングに関する本の最後でコードを取り上げ、最初からその方法でコードを構築することが含まれます（分解可能性、優れたテストカバレッジなど）。
- 変化を避ける
この場合、BDUF（大きなデザインを前もって）する必要があります。紙のプロトタイプをたくさん作成し、潜在的なユーザーや自分とアイデアをラバーダッキングで話し合ったり、プロトタイプやモックアップでさまざまなことを試したり、完全な仕様を書き留めたりして、ソリューションを見つけたと感じたときにのみ、最後にコーディングを開始できます。予期しない変更を実際に取り除くわけではないことをすべて実行しても、最初の1年ほどは少し減ります。したがって、変更しやすいようにコードをビルドする必要があります。
したがって、基本的に、変更は当然です。それが起こると仮定します。それに応じてコードをビルドします。実際には、設計の前倒しとコーディング開始のアプローチの中間点を見つけることができ、分析麻痺に陥ることなく、不必要な変更を回避できます。少し経験が必要です。
ソフトウェア開発は、本質的に「邪悪な」一連の問題として説明されています 。
Horst RittelとMelvin Webberは、「邪悪な」問題を、それを解決することによって、またはその一部を解決することによってのみ明確に定義できる問題として定義しました*。このパラドックスは、本質的に、問題を明確に定義するために一度問題を「解決」し、それを解決して機能するソリューションを作成する必要があることを意味します。このプロセスは母性であり、Apple数十年にわたるソフトウェア開発のパイ
これはあなたが直面している問題を完全に説明しています。基本的に、私たちがやっていることは難しい。 「ルーチン」と表現できる部分がある場合は、時間の経過とともに分離して自動化します。ですから、残っているのは新しいものか難しいものです。
このような問題を克服する方法は他にもあります。一部の人々は、事前に問題を検討し、設計に慣れるまでコードを記述しないことに多くの時間を費やしています。他の人たちは、ペアプログラミングまたはこのようなサイトを介して、すでにこのような問題を扱ってきた人々からのガイダンスを求めています。
しかし、確かにあなたのアプローチは無能を示唆していません。唯一の問題は、前に戻ったときに、最初にこの方法で何かを行うことを選択した理由を振り返っていないかどうか、および「なし」で「より良い」方法を見ることができたかどうかです。リライト。
多くの場合があり、次回の設計プロセスに組み込むことができます。場合によってはありませんでした（または、コストは他のアプローチのコストと同じかそれよりも高かったでしょう）。そして、あなたは心配事を手放すことができます。
- はい、これは一般的ですが、おそらく「コードの書き換えmost」の部分は除きます。最初からすべての要件を取得することはできないため、変化に適切に対処することが重要です。それが「コードの保守性」のコンセプトです。もちろん、要件と設計を正しくするためにより多くの時間を費やすことにも役立ちます。
- 最初に、過去のプロジェクトでどのような変更が必要であったか、またそれらをどのように予測したり、より適切に準備したりできるかを考えます。プロジェクトの最初に、ユースケースの詳細について考えます。実装を開始する前に、いくつかの抽象的な設計（コードの主要コンポーネントとそれらの通信方法、APIについて）を行ってください。最も重要なことは、コードをできるだけシンプルで簡単に変更できるようにして、SOLID、DRY、KISSおよびYAGNIなどの概念を読んでください。
そのような慣習は一般的ですか、それとも私が能力がないことを意味しますか？
それらは相互に排他的ではありません。パターンは一般的である可能性があり、それでも能力がない可能性があります。あなたの能力はあなたの目標に対するあなたのパフォーマンスを測定することによって決定することができます。目標を達成していますか？
このパターンは一般的ですか？残念ながらそうです。多くの人々は、どのような問題を解決しているか、どのようにして正しい解決策を生み出すか、そしてどのメトリックが成功を構成するかについて明確な考えがないプロジェクトに飛び込んでいます。
どうすればこの面で自分を改善できますか？
どこかに行くことに決めて歩いたばかりで、象をケープタウンからニューヨークシティまで運ぶことが本当に必要な1日であるとわかった場合、歩いている時間はすべて無駄になりました。あなたがそれを始める前に、あなたが何をしているかを理解してください。
それを始めたら、次のことを考慮してください。これまでに書き換える必要がないのコードはどのようなものですか？そのコード：
- 1つの便利なことを行います。
- 正しく行います。
- 十分なパフォーマンスでそれを行います。
したがって、そのコードが1つの有用なことを正しく、適切に、優れたパフォーマンスで実行するコードを書くほど、書き換える必要のあるコードは少なくなります。
私はあなたがより良い働き方からそれほど遠くないと言っても安全だと思います、そしてあなたはこのボートの唯一のものではありません。
あなたが見逃していると私が思うのは、あなたがwhatを決定したとしても、-howに対して同じプロセスを実行するのをやめないということです。
問題全体に取り組む方法を停止して考えるこのステップは、設計と呼ばれます。これは、システムの構造またはアーキテクチャの開発に時間を費やして、そこから行うすべてのことが最終的なソリューションに貢献するようにするステップです。エッジを作成したら、ピースをジグソーパズルに合わせます。
多くの人はこのステップを実行しませんが、私がコーディングを始めたとき、それは必須でした。違いは開発ツールにあると思います。テキストエディタから始めたのに対して、今では、ジャンプして入力することができるあらゆる種類の機能を利用できます。
したがって、少し時間をかけてコードの作成を始める前に、広い領域、コンポーネント、およびそれらの間の相互運用性を理解し、ソリューションを構成するオブジェクトを定義してください。それは非常に詳細である必要はありません、そしてあなたが最初にそれを完全に正しく得られないのでそれが時間とともに進化することを理解します、しかしこれはあなたがすべきでないことを再検討する努力の無駄を止めるのを助けることです大幅に変更する必要があります。
ポインタをいくつか追加したい
1）私は個人的にvisualizingのものから始めるのは非常に便利だと思いました。ボックス、矢印、線を描く...使用するモデリング言語を気にしないでください。そもそもあなたは自分のためにやっているのです。それはあなたの思考の流れを助けるはずです。
2）sparring partner-を見つけ、上からコーヒーやフリップチャート/図などを入手して、町に向かいます。一致する技術スキルを持っていない場合、私見それはさらに良いです。ユースケースを実装するためのアイデアを行き来します。あなたは行き止まりを見つけます-あなたは解決策を見つけます。アジャイルマインドでは、多くの場合、この段階で費やされる時間はコードを書く場合よりも少なくなり、機能せず、作業のチャンクを削除するか、やり直す必要があります
3）あなたがありそうなことを理解できる上司を見つけましょう決してあなたの書かれたソフトウェアの改善を終えました。あなたの机に捨てられ、ソフトウェアに決してケアしない新機能/要件を常にプラグインするならば、それはバグ、メンテナンスの不便さ、そして数年の髪の引っ張りであなたに逆戻りしますライン。このソフトウェアのメンテナンス時間/予算を割り当ててください！私の良い丸い魔法の数は、ソフトウェアの開発に必要な時間の約20％であり、ソフトウェアの寿命が尽きるまでその状態を維持するために1年に必要です。
4）このインクリメンタル学習のプロセスは決して止まることはありません（そして止めるべきではありません）。 10年後を振り返り、笑顔になります。
これがほんの少しの幸運に役立つことを願っています！
あなたはすでにいくつかの素晴らしい答えを持っていますが、あなたの質問は私が触れようとすると思ったいくつかのことを思い起こさせます。
将来、変更が発生することに気づいたように、プロジェクトにどのような影響があり、設計/コーディングの選択によって影響を最小限に抑えながら、人々が頻繁に変更を加えるかについてのメンタルマップを生成する方法について考えることをお勧めします。経験があれば、重要になることがわかっているものに対してある程度の柔軟性を予測してコーディングできます-業界ではこの概念について意見の相違がありますが、具体的に要求されていない領域への投資に反対している人もいます。
テストの最前線であるプロジェクトの利害関係者のためにプロトタイプを投入することは、要件を改善するための優れた方法です。ただし、開発中は、コードを複雑にしたり混乱させたりせずに、コードで何が起こっているかを「確認」する方法を探すことができます。役立つツールは確かにありますが、必要に応じて、それらがなくても多くのことができます。どちらの方法でも、批判的な目で何が起こっているかを確認するためにコードから出てくると、さまざまなタイプの洞察が得られる場合があります。
一般的な活動を探します。同じ問題を何度も何度も処理することになります。しばらくすると、さまざまな選択肢の不足やトレードオフを発見し、それらを回避するのに役立つ方法論に重点を置く必要があります。もちろん、フレームワークで作業している場合、これらの問題のいくつかは、すでに使用しているツールにまとめられる可能性があります。
フレームワーク内で作業している場合は、時間を費やして、余裕があれば、最初からやり直す方法を検討してください。たとえば、要求メッセージを簡単に組み立て、ソケットを開き、GETまたはPOST要求を手動で発行できます。XMLメッセージを手動で解析したい場合は、何をしても、生成する質問そして、あなたが見つけた答えはあなたのスキルを向上させます。もちろん、あなたはどのタイプの根本的な問題が重要であるか興味があるかを選ぶことができます。私はこの個人的な発展を考慮し、ここで多くの時間を費やすことを期待しません。
銀の弾丸、方法論、高い話題性の問題は至る所にあります。基本的に、情報を扱うという根本的な現実は、それほど急速には変化していません。導入されているフレームワーク、ツールセット、または方法論が、さまざまな状況において助けになるか、妨げになるかをメモします。大企業では、会社が効果的に実行できなかったものの、多くの方法論が試みられているのを見てきました。フレームワークと同様に、方法論は、たとえいくつかの高機能チームのプラクティスに基づいていても、高レベルで機能するためのフェイルセーフな方法ではありません。
経験を煮詰めてアクセス可能にするのは難しい。これらすべてをまとめる簡単な方法は、目を開いたままにし、見えているものについて考え、学習を止めないことです。