コーディング前の構想と設計：これはどのくらい本当ですか？
私は学校で学んだだけでなく、適切なコーディングを行う前に、優れた開発方法論には概念と設計が必要であることを他の場所でも読んでいました。
初心者プログラマにとっても、それは新しい情報ではありません。しかし、いくつかのプログラミング言語で開発を始めて以来、最初からすべてを設計し、想像することはできなかったので、これは良いアドバイスなのでしょうか。
つまり、私は常にデザイン、コンセプト、プログラミングを溶け込ませていました。私は世界で最悪の開発者ですか、それとも私たちが学校で学ぶアイデアは古い意味のないものですか宗教的ドグマですか？
これまでに経験したことも、プログラムしたこともないものを、どのように考え出して設計することができますか？ばかげていませんか？代わりにプログラミングが概念と設計をリードしていませんか？
答えは次のとおりである必要があると思います。できるだけ多くの計画を立ててください。
計画の美徳に反対する人はほとんどいませんが、議論の大部分は重要な側面を見落としています。計画は、優れた計画を立てるスキルがある場合にのみ機能します。そのスキルには経験が伴う傾向があります。経験が少ない場合は、作成した計画にかなりの問題が発生する可能性があります。これは、完全な災害ではない製品を作るために、開発中に計画を大幅に修正する必要があることを意味します。計画が詳細である場合、これは多くの詳細を無効にする可能性が高く、さらに悪いことに、計画に従うことができるように調整を最小限に保つように努めます。
いくつかのことは間違いなく計画を必要とし、必要なレベルの計画を立てるスキルがない場合、プロトタイプを作成する唯一の方法は、適切な計画を立てるために必要なタスクの経験を得るためにコードを書くことです。 。
量産コードを作成する準備ができているかどうかに関係なく、計画の最大レベルに達したら、コーディング以外に何もすることがありません。多分それは災害になるでしょうが、それらは良い学習経験であり、あなたは改訂された計画を立てるのにはるかによく備えられるでしょう。
それは絶対に本当です。要件が大きく複雑になるほど、これは真実になります。
小さなコンソールアプリがフィボナッチ数列を計算するためには、アルゴリズムとUI（はい、単純にstdinとstdoutにすることができます）を構築する方法について数分以上考える必要はないかもしれません。
しかし、毎秒数百万のトランザクションを実行し、グローバルに分散されることが予想され、99.9999のアップタイムと100％の正確性を必要とするリアルタイムトレーディングプラットフォームはどうでしょうか。あなたはそれをコーディングに飛び込みますか？
これら2つの極端な方法の間には、他にも多くのオプションがあります。
project Euler を見てください。提示された順序でいくつかの問題を解決します。妥当な時間内にいくつかの問題を解決するには、コードに飛び込む前に実際に考える必要があることがわかります。
コードを書き始める前に時間をかけてプログラムを考えて設計する必要がない場合は、ささいなことに取り組んでいるか、もっと大きなものを見落としているかのどちらかです。
私は最初からすべてを設計し、想像することに成功したことはありません
最も些細な問題以外は何もしません。繰り返しになりますが、プロジェクトが大きくて複雑なほど、これは本当です-設計には間違いがあり、見落とされていることなどがあります...
芸術は、最初に高レベルで設計し、大きな部分が収まるかどうかを確認することです。次に、優先順位のリストを取得します-最初に最も重要な/インフラストラクチャに取り組み始めます。次に、大きなピースを小さなピースに分解して、大きなピースがそれぞれ意味のあるピースで構成されていることを確認します。
これには時間と労力がかかり、最初は完全ではないか、完全に正しくない場合があります。
しかし、これがsoft-wareと呼ばれ、hard-と呼ばれない理由です。ウェア。それは順応性があり、変更することができます。
私は学校で学んだだけでなく、適切なコーディングを行う前に、優れた開発方法論には概念と設計が必要であることを他の場所でも読んでいました。
これは本当です。
しかし、私がいくつかのプログラミング言語で開発を始めて以来、私は設計と想像に失敗したことがないので、これは良いアドバイスなのかどうか疑問に思いますeverything =開始以来。
そして、あなたの問題があります。
自明ではないほとんどの問題では、物事がどのように機能するか、物事がどのように組み合わされるかを理解するために、いくつかの考えを行う必要があります。逆説的に、ほとんどの重要な問題については、計画を立てる方法はありませんすべて。不明な点が多すぎて説明できず、開発中に発生する変更が多すぎます。アジャイルは、この契約の後半を受け入れることで、勢力を獲得しました。人々は全知ではなく、変化は一定です。
したがって、事前に設計を行う必要があることは確かに当てはまりますが、設計を事前にのみにすることが不可能であることも当てはまります。
コーディングする前に、必ずsome designが必要です。
その理由は非常に簡単です。デザインがない場合は自分が何を作っているのかわからないです。
設計が最終的になる前に、必ずsome codeが必要です。
その理由は非常に簡単です。設計が変更され、設計の一部を開発することで、ソリューションに取り掛かるまで予測が困難な質問、機会、課題が明らかになります。
開発は反復的です。
計画的かどうかにかかわらず、チームがそれを実現するかどうかにかかわらず、すべてのソフトウェアプロジェクトは反復的に行われます。作業の一部が完了し、評価されます。評価により、残りの作業の実行方法が変わります。
複数のアプローチを試してください。
事前設計とコード作成のバランスをとる最良の方法を知るには、実践と経験が必要です。それはほとんど誰も習得していないスキルであり、各プロジェクトには異なる理想があります（自分用に小さなツールを設計することと、メジャーなビデオゲームのような大規模なシングルリリース製品を作成するチームを検討してください）。
私は他の人が過去に複数のシステムを設計したり、それを妨害したりしましたが、プロセスがさまざまな方法で展開するのを見てきましたが、私が共通しているのは、少なくとも存在を計画する必要があるということですほとんどの主要な機能の。
たとえば、建物、床、部屋などの概念が何もないHVAC制御システムがそれらに組み込まれるのを見たことがあり、その結果は、それらが来るのと同じくらい醜いものでした。または、（スマートでない）懐中時計に適したコンポーネントから構築されたモバイル音楽デバイス。言うまでもなく、どちらの場合も最終製品は顧客のお気に入りではありませんでした。
「アイデア」から一歩上がった「概念」と言うと、コンセプトは非常にあいまいになる可能性があります。ビジネスは通常、概念を気にします。顧客は通常UXに関心を持っています。これは、使いやすく快適な方法で現実にもたらされ、その使用を通じていくらかの価値をもたらす概念です。
プログラミングの前に "概念"を実行する必要があります。ビジュアルスタジオ（またはIDE選択））を開いてランダムにコードを記述し、どこに行くかを想像することはできません。
コーディングの前に完全な設計を行うことはできません（すべきではありません）が、ユーザーのワークフローがどのようになるかを大まかにスケッチする必要があります。
UXの設計とコーディングはお互いにうまくやり取りすることがよくあります。この事実を仕事への取り組み方に組み込む方法として、最小のプロジェクト以外にはアジャイルアプローチを使用せざるを得ないでしょう。だから、一度にすべてを見ることができなかったとしても、あなたがプログラマーの最悪だとは思わないでください。誰もできず、それを理解できる人は、問題を十分に無視して完全なものだと主張できる人です。画像。
サイズを何か大きなものにする例。コンセプト：「企業がソフトウェアプラットフォームを統合できるようにするビジュアルクラウドベースのツールを作成する」。これは素晴らしいことだと思われ、マーケティング資料を書き始めて、そこに来る前に販売することができます。コーディングする前にこれが必要です。
事前設計：「Visioのような形と矢印でロジックを記述します。さまざまなプラットフォーム（SAP、SF、データベースなど）への接続を可能にするプラグイン機能を備えています。システム;データを視覚的に記述し、1つの形式を別の形式に変換する方法があります。」もう一つの素晴らしいマーケティングブロブ。それはまた何が重要であるかについてのいくつかのアイデアを提供します。
設計/コード：「このような機能を備えたブラウザーでホストされたHTMLデザイナーを用意します。バックエンドをJavaでコーディングして、既存のサーバーで実行できるようにします。データ構造とそれらをクエリまたは変更するためのUXを定義します。必要に応じて、災害復旧、エラー報告、監査ログの計画、バージョン管理の計画、アクセス制御の計画などを行います。」-リストが細かいほど、すべてを予測することは現実的ではありません。
...しかし、少なくとも何かを意識している必要があります可能性があります大体のように見えるか、最終製品が本当に役に立たない実装になってしまい、そうでなければ素晴らしいサウンドのコンセプトが失われる可能性があります-言うビジュアルデザイナーは、実際のワークフローを表示するために40インチの画面が必要です。または、ログ内の20のフィールドの1つなどに制限された文字列の完全一致以外にログを検索する方法はありません。これを防ぐための良い方法はありません。あなたの実装を実行する以外に起こることから-一部は成功し、他は失敗します。
私は常に次のように時間を割り当てます：
- 1/3デザイン
- 1/3開発
- 1/3テスト
デザイン：ビジュアルだけでなく、コンセプチュアル。視覚的にも論理的にも、パーツに分割します。再利用され、それ自体がデザインパターンである共通点を探します。
開発：部品を理解したら、それらをコーディングします。次に、それらを統合します。
テスト：コードが適切に統合され、記述されていることをテストするだけでなく、常に洞察が得られ、教訓が得られ、対話する新しい方法が作成され、新しい機能が考案され、望まれます。スコープのクリープに注意してください。
これらの側面に加えて、プロジェクトにはこれらのフェーズに加えて3つのフェーズがあることに注意してください。
- 十分に設計されていない最初の試み
- 最初の試みから学んだ教訓からの、過度に設計された2番目の試み。
- 適切に設計された3回目の試行。
設計段階をよりよく実行すれば、追加の試行が最小限に抑えられることがわかりました。すべてをやり直す代わりに、やり直しのサブシステムを用意することもできます。
私はソフトウェア開発者であり、社内、外部委託、およびオフショア開発プロジェクトのソフトウェア開発マネージャーです。