私は1年の経験を持つプログラマーです。最近、プロジェクトを正しく開始することはほとんどないことに気付きました（ほとんどのサイドプロジェクト）。通常、プロジェクトサイクルは次のようになります。

1. いくつかのユースケースから始めます
2. コーディングを開始
3. うまく処理できず、現在のコードベースにうまく適合しないいくつかのことを理解してください。
4. コードの大部分を書き換える

そして、これは数回行くかもしれません

だから私の質問は

1. そのような慣行は一般的ですか、またはそれは私が能力がないことを意味しますか？
2. この面でどうすれば自分を改善できますか？

説明するサイクルは正常です。物事を改善する方法は、このサイクルを回避することではなく、それを合理化することです。最初のステップはそれを受け入れることです：

1. プロジェクトの初日にすべてを知ることはほぼ不可能です。
2. どうにかしてすべてを知っていても、プロジェクトを終える頃には、何か（クライアントの要件、彼らがいる市場、あなたが働いている技術、顧客の希望）が変わってしまいます。無効または不正確であることがわかっているものの少なくとも一部。

したがって、すべてを前もって計画することは不可能であり、可能であっても、その計画に従うと、不完全または時代遅れの何かを構築することになります。これを知って、変更を計画に統合します。あなたのステップを見てみましょう：

1. いくつかのユースケースから始めます
2. コーディングを開始
3. うまく処理できず、現在のコードベースにうまく適合しないいくつかのことを理解してください。
4. コードの大部分を書き換える

それは実際には素晴らしい出発点です。アプローチ方法は次のとおりです。

1.いくつかのユースケースから始めます

良い。「ユースケース」と言うことで、あなたはソフトウェアの目的に焦点を合わせています。「少数」と言うことで、あなたはすべてを発見しようとしているのではありません。管理しやすい量の仕事にこだわっています。ここで追加するのは、優先順位を付けることだけです。クライアントまたはエンドユーザーと一緒に、この質問に対する答えを見つけてください。

あなたの状況を改善するために私があなたに与えることができるソフトウェアの最小で最も単純な部分は何ですか？

これは最小の実行可能な製品です。これよりも小さいものはユーザーにとっては役に立たないが、それよりも大きいものは計画が早すぎます。これを構築するのに十分な情報を入手してから先に進みます。この時点ですべてを知っているわけではないことに注意してください。

2.コーディングを開始します。

すばらしいです。できるだけ早く作業を開始します。コードを書くまで、クライアントはゼロの恩恵を受けています。計画に費やす時間が長いほど、クライアントは返済なしで待機する時間が長くなります。

ここで、良いコードを書くためのリマインダーを追加します。SOLID Principlesを覚えて従い、壊れやすいものや複雑なものについてきちんとした単体テストを書き、忘れそうなものや後で問題を引き起こす可能性のあるものについてメモします。変更によって問題が発生しないようにコードを構造化したいと思います。これを行うには、そのような方法ではなく、この方法で何かを構築することを決定するたびに、コードができるだけ少なくなるようにコードを構築します。一般的に、これを行う良い方法は、コードを分離することです：

• シンプルで個別のコンポーネントを使用します（言語と状況に応じて、このコンポーネントは関数、クラス、アセンブリ、モジュール、サービスなどになります。また、多数の関数を含むクラス、または多数のクラスを含むアセンブリ）
• 各コンポーネントは1つのジョブ、または1つのことに関連するジョブを実行します
• 1つのコンポーネントの内部動作の方法を変更しても、他のコンポーネントを変更する必要はありません
• コンポーネントには、取得または作成するのではなく、使用または依存するものを与える必要があります
• コンポーネントは、必要があります与える他のコンポーネントに情報をしてではなく、仕事をするためにそれらを求めるフェッチ情報を、作業そのものをやって
• コンポーネントは、他のコンポーネントの内部動作にアクセスしたり、使用したり、依存したりしてはなりません-公的にアクセス可能な機能のみを使用してください

これを行うことで、変更の影響を隔離し、ほとんどの場合、問題を1か所で修正でき、残りのコードは気付かないようにします。

3.デザインの問題または欠点に遭遇します。

これは起こります。やむを得ない。これを受け入れます。これらの問題の1つを見つけたら、それがどのような問題であるかを判断します。

いくつかの問題は、ソフトウェアがすべきことを実行するのを難しくするコードまたは設計の問題です。これらの問題については、戻って問題を修正するために設計を変更する必要があります。

いくつかの問題は、十分な情報を持っていないか、以前は考えもしなかった何かを持っていることが原因です。これらの問題については、ユーザーまたはクライアントに戻って、問題の解決方法を尋ねる必要があります。答えが得られたら、デザインを更新して処理します。

どちらの場合も、コードのどの部分を変更する必要があるかに注意を払う必要があります。また、コードをさらに書くにつれて、将来どの部分を変更する必要があるかを考える必要があります。これにより、どの部分が相互にリンクされすぎている可能性があり、どの部分をより分離する必要があるかを簡単に判断できます。

4.コードの一部を書き換える

コードを変更する方法を特定したら、変更を加えることができます。コードを適切に構造化した場合、通常は1つのコンポーネントのみを変更しますが、場合によってはいくつかのコンポーネントを追加することも含まれます。多くの場所で多くのことを変更しなければならないことがわかったら、それがなぜなのかを考えてください。このコードをすべて内部に保持するコンポーネントを追加し、これらすべての場所でそのコンポーネントを使用するようにできますか？可能な場合は変更してください。次回この機能を変更する必要がある場合は、1か所で実行できます。

5.テスト

ソフトウェアの問題の一般的な原因は、要件を十分に把握していないことです。これは多くの場合、開発者のせいではありません。多くの場合、ユーザーは必要なものがわからないこともあります。これを解決する最も簡単な方法は、質問を逆にすることです。「ソフトウェアに何が必要なのか」と尋ねる代わりに、これらの手順を実行するたびに、これまでに作成したものをユーザーに提供し、「これを作成しました-必要なことを行いますか？」彼らが「はい」と言ったら、あなたは彼らの問題を解決する何かを構築したので、仕事をやめることができます！彼らがノーと言うなら、彼らはあなたのソフトウェアのどこが悪いのかをより具体的な言葉であなたに伝えることができます。

6.学ぶ

このサイクルを経て、見つけている問題と行っている変更に注意してください。パターンはありますか？改善できますか？

いくつかの例：

• 特定のユーザーの視点を見落としていることに気付いた場合、そのユーザーを設計段階により深く関与させることができますか？
• テクノロジーとの互換性を保つために物事を変更し続けなければならない場合、コードとそのテクノロジーの間のインターフェースを構築することで、インターフェースを変更するだけで済みますか？
• ユーザーがUIの単語、色、写真、またはその他のことについて考えを変え続けている場合、アプリケーションの残りの部分にそれらをすべて1か所で提供するコンポーネントを構築できますか？
• 多くの変更が同じコンポーネントにあることがわかった場合、そのコンポーネントが1つのジョブだけに固執していると確信しますか？それをいくつかの小さな断片に分割してもらえますか？他のコンポーネントに触れることなく、このコンポーネントを変更できますか？

アジャイルになる

ここに向かっているのは、アジャイルとして知られる働き方です。アジャイルは方法論ではなく、多くのこと（Scrum、XP、Kanbanなど）をすべて取り入れた方法論のファミリーですが、それらに共通しているのは、物事が変化するという考えです。変更を回避または無視するのではなく、変更に適応することを計画する必要があります。その中核となる原則のいくつか-特に、あなたの状況に関連するもの-は次のとおりです。

• 自信を持って予測できるよりも先に計画しないでください
• あなたが行くにつれて物事が変化することを考慮してください
• 一度に大きなものを構築するのではなく、小さなものを構築してから段階的に改善する
• プロセスにエンドユーザーを巻き込み、迅速で定期的なフィードバックを得る
• あなた自身の仕事と進歩を調べ、あなたの過ちから学ぶ

これは正常です。

次の2つの方法のいずれかを使用できます。

1. ようこそ

間違っていると思われる場合は、変更可能なコードベースを作成する必要があります。ほとんどの場合、これはリファクタリングに関する本の最後にあるコードを取得し、最初からコードを構築することを含みます（分解性、良好なテスト範囲など）。

2. 変更を避ける

この場合、BDUF（前もって大きなデザイン）を行う必要があります。たくさんの紙のプロトタイピングを行い、潜在的なユーザーや自分とアイデアをゴム製のダッキングで議論し、プロトタイプやモックアップでさまざまなことを試し、完全な仕様を書き留めてから、解決策を見つけたと感じたら、最後にコーディングを開始できます。実際に予期しない変更を取り除くことなく、それをすべて行うと、最初の1年ほどで、少しだけそれが減ります。したがって、変更しやすいようにコードを作成する必要があります。

だから、基本的に、変化は与えられている。それが起こると仮定します。それに応じてコードをビルドします。実際には、前もって設計するアプローチとコーディングを開始するだけのアプローチの間の中間点を見つけることができます。少し経験が必要です。

ソフトウェア開発は、一連の本質的に「邪悪な」問題として説明されてきました。

Horst RittelとMelvin Webberは、「邪悪な」問題を、それを解決するか、その一部を解決することによってのみ明確に定義できるものと定義しました*。このパラドックスは、本質的に、問題を明確に定義して問題を一度解決してから解決し、有効なソリューションを作成する必要があることを意味します。このプロセスは何十年もの間、ソフトウェア開発における母性とアップルパイでした

これはあなたが直面している問題を完全に説明しています。基本的に、私たちがしていることは難しいです。「ルーチン」と説明できる部分がある場合、時間をかけてそれを分離して自動化します。そのため、残っているのは新しいものか難しいもののいずれかです。

このような問題を克服する方法は他にもあります。事前に問題を検討し、設計に慣れるまでコードを書かない人もいます。他の人は、ペアプログラミングまたはこのようなサイトを介して、このような問題に既に対処している人々からのガイダンスを求めています。

しかし、確かにあなたのアプローチは無能を示唆していません。唯一の問題は、戻って行くときに、最初からこの方法で何かをすることを選択した理由と、リライト。

多くの場合、それがあり、次回に設計プロセスに組み込むことができます。場合によっては、そうではなかった（またはコストが他のアプローチのコストと同じかそれ以上だった）ので、懸念を解消することができます。

1. はい、「コードの大部分を書き換える」部分を除いて、これは一般的です。最初からすべての要件を取得することは決してないため、変更に適切に対処することが重要です。それが、「コードの保守性」という概念のすべてです。もちろん、要件と設計を正しくするためにもう少し時間をかけることも役立ちます。
2. 最初に、過去のプロジェクトでどのような変更が必要であったか、そしてそれらをどのように予見したり、より良く準備したかを考えてください。プロジェクトの開始時に、ユースケースの詳細について考えてください。実装を開始する前に、いくつかの抽象的な設計（コードの主なコンポーネントとその通信方法、APIとは何か）を行います。最も重要なことは、コードをできるだけシンプルで変更しやすいものにし、SOLID、DRY、KISS、YAGNIなどの概念を読み上げることです。

そのような慣行は一般的ですか、またはそれは私が能力がないことを意味しますか？

これらは相互に排他的ではありません。パターンは一般的である可能性がありますが、それでもあなたは無能かもしれません。目標に対するパフォーマンスを測定することにより、能力を判断できます。目標を達成していますか？

このパターンは一般的ですか？残念ながらそうです。多くの人は、自分がどの問題を解決しているか、正しいソリューションをどのように設計するか、どのメトリックスが成功を構成するかについて明確な考えを持たずにプロジェクトに飛び込みます。

この面でどうすれば自分を改善できますか？

どこかに行くことに決めて、歩き始めたばかりで、ケープタウンからニューヨーク市に象を運ぶことが本当に必要だった日を発見した場合、歩いて過ごした時間はすべて無駄になりました。実行を開始する前に、実行していることを把握してください。

一度それを始めたら、次のことを考慮してください：書き換える必要のないコードはどのようなものか そのコード：

• 1つの便利なことを行います。
• 正しくします。
• 十分なパフォーマンスでそれを行います。

そのため、そのコードが1つの有用なことを正しく、適切なパフォーマンスで実行するようにコードを記述するほど、書き直す必要のあるコードが少なくなります。

私は、あなたがより良い働き方からそう遠くない、そしてあなたがこのボートの唯一の人ではない、と言っても安全だと思います。

私はあなたが欠けていると思うことはあなたが決めるが、ということです何をしたい、あなたがのために同じプロセスを行うために停止しませんどのようにあなたがそれをやると。

全体的に問題に取り組む方法を停止して考えるこのステップは設計と呼ばれ、システムの構造またはアーキテクチャの開発に時間を費やすことで、そこから行うすべてが最終的なソリューションに貢献するようになります。エッジを作成したら、ピースをジグソーパズルに合わせます。

多くの人はこのステップを実行しませんが、私がコーディングを始めたとき、それは必須です。違いは開発ツールにあると思います-私はテキストエディタから始めましたが、今では、ジャンプして入力することを可能にするあらゆる種類の機能を備えています。

そのため、コーディングを開始する前に、少しの時間をかけて、広範な領域、コンポーネント、およびそれらの間の相互運用性を把握し、ソリューションを構成するオブジェクトを定義してください。それは非常に詳細である必要はなく、最初は完全にそれを得ることができないことを理解しているので、時間とともに進化しますが、これはするべきではないものを再考する努力を無駄にするのを助けることです大幅に変更する必要があります。

あなたはすでにいくつかの素晴らしい答えを持っていますが、あなたの質問は私が触れようとするだろうと思ったいくつかの事柄を思い起こさせます。

1. 道のりで変更にぶつかったことに気づいたように、物事がプロジェクトに与える影響と、設計/コーディングの選択による影響を最小限に抑えながら、人々が頻繁に遅れて変更する場所のメンタルマップを生成する方法について考えることをお勧めします。経験を積むことで、重要となることがわかっていることをある程度の柔軟性で予測およびコーディングできます。ただし、業界ではこの概念について意見の相違がありますが、それ自体は明確に要求されていない分野に努力を投資していることに反するためです。

2. テストの最前線で、プロジェクトの関係者にプロトタイプを投げることは、要件を改善するための素晴らしい方法です。ただし、開発中に、多くの混乱や複雑さを引き起こすことなく、コードで何が起こっているかを「見る」方法を探すことができます。役立つツールは確かにありますが、必要な場合はツールなしでも多くのことができます。いずれにせよ、批判的な目で何が起こっているかを見るためにコードから出てくることは、さまざまなタイプの洞察を提供します。

3. 一般的なアクティビティを探します。同じ問題を何度も処理していることに気付くでしょう。しばらくして、さまざまな選択肢の不足またはトレードオフを発見し、それらを回避するのに役立つ方法論に集中する必要があります。もちろん、フレームワークで作業している場合、これらの問題のいくつかは、既に使用しているツールにまとめられる可能性があります。

4. フレームワーク内で作業している場合、時間を費やし、余裕があれば、ゼロから物事を行う方法を検討します。たとえば、要求メッセージを簡単に組み立て、ソケットを開き、GETまたはPOST要求を手動で発行できます。必要に応じて、XMLメッセージを手動で解析できます。あなたが何をするにしても、あなたが生成する質問とあなたが見つける答えはあなたのスキルを成長させます。もちろん、あなたはどのタイプの根本的な問題が重要であるか興味があるかを選ぶことができます。私はこの個人的な発展を考慮し、ここで多くの時間を費やすことを期待していません。

5. 特効薬、方法論、バズファクターの高い問題はどこにでもあります。基本的に、情報を扱うことの根底にある現実は、それほど速く変化していません。用意されているフレームワーク、ツールセット、または方法論が、さまざまな状況で助けになるのか邪魔になるのかに注意してください。大企業では、多くの方法論が試みられましたが、それらを効果的に実行することはできませんでした。フレームワークのように、方法論は、たとえ非常に機能的なチームの実践に基づいていても、高レベルで機能するフェイルセーフな方法ではありません。

経験を煮詰めてアクセスしやすくすることは困難です。これをすべて行う簡単な方法は、目を開けて、見ているものについて考え、学習を止めないことです。

いくつかのポインターを追加したい

1）個人的には、ものを視覚化することから始めると非常に便利だと感じました。ボックス、矢印、線を描く...使用するモデリング言語を気にしないでください。そもそもあなたは自分のためにそれをやっています。それはあなたの思考の流れを助けるはずです。

2）スパーリングパートナーを見つける-上からコーヒーとフリップチャート/図などをつかみ、町に着きます。私見では、一致する技術スキルを持っていなければさらに良いです。ユースケースを実装するためのアイデアを行き来します。あなたは行き​​止まりを見つけます-あなたは解決策を見つけます。アジャイルな心で、この段階で費やす時間は、コードを書く場合よりもしばしば少なくなります。

3）あなたが書かれたソフトウェアを改善することは決してないであろうことを理解できる上司を見つけてください。机に捨てられ、ソフトウェアを気にしない新しい機能/要件を常にプラグインすると、バグ、メンテナンスの不便さ、そして数年後の髪の毛であなたに反撃されます。このソフトウェア保守時間/予算を割り当ててください！ラウンドマジック数は、ソフトウェアを開発するのに必要な時間の約20％であり、その有効期間中にソフトウェアを形に保つために必要な年数です。

4）漸進的学習のこのプロセスは決して止まらない（そうすべきではない）！10年後に振り返り、笑顔になります。

これが少しでも幸運に役立つことを願っています！