開発方法は開発者の個人主義を押しつぶすべきですか？
私は大学の最終学期にあり、ソフトウェアエンジニアリングコースを受講しています。クラスでは、さまざまなソフトウェア開発方法について学びます。私たちが焦点を当て、プロジェクトの開発に使用したのは、ウォーターフォール方式でした。
インストラクターが間違って実装したようです。クラス図では、プライベートのものを含むすべてのプロパティとメソッドをリストする必要がありました。私は、関数をできるだけ短く、集中させるようにと言っている数冊の本、すなわちCleanCodeを読みました。他の開発者の助けにならない場合、ダイアグラムにすべての小さな関数をリストするのは退屈なようです（それらは非公開であり、他の誰も使用しません）。さらに、プログラムを設計するときにすべての小さな関数を考えるとは限らないかもしれません。リファクタリングするときに一緒に来るかもしれません。
インストラクターは、すべての機能をリストするように依頼して、間違ったことを教えてくれましたか？そして、これらの設計方法は、開発者の個人主義を押しつぶして、コードを最もよく理解できるようにコードを記述しますか？
なぜすべての方法をリストしなければならなかったのか、インストラクターに尋ねましたか？
教室環境で求められる多くのことと同様に、クラス図を開発者にとってより役立つものにするのではなく、クラス図を開発者にとってより役立つものにするのではなく、クラス図をどのように設計するかについて考えるのを助けることを目的としていた可能性があります。学生が大きな問題を小さな問題に分解する方法を学んでいるとき、彼らがおそらく必要とするであろう私的な方法について考えることはおそらく彼らにとって役立つでしょう。また、誰かの設計が十分に検討されていない場合に、プロセスの早い段階で介入するために、生徒が実装を検討しているメソッドについてよりよく理解することは、おそらくインストラクターにとって役立つでしょう。教室環境でのドキュメントは、実際の環境でのドキュメントよりもはるかに複雑になることがよくあります。これは、ドキュメントを作成することで、学生が自分のコードだけに集中している場合は、経験が浅すぎて考えられないことを考えるようになるためです。
もちろん、インストラクターがこのレベルのドキュメントが実際のプロジェクトに役立つと信じている可能性もあります。その場合、インストラクターはおそらく時代遅れであるか、このレベルの計画と文書化が適切である特定のニッチなバックグラウンドから来ています。たとえば、スペースシャトル用のナビゲーションシステムを構築している場合や、医療機器を設計している場合は、開発中にコードをリファクタリングするよりも、事前の設計に多額の投資をする方が一般にはるかに適切です。一方、ソーシャルネットワーキングサイトを開発している場合は、より機敏なアプローチがより適切です。
いいえ、ウォーターフォール方式を使用している場合、インストラクターはすべてのプロパティとメソッドを事前にリストするように指示します。 ウィキペディア 滝への批判に注意：
多くの人が、ウォーターフォールモデルは実際には悪い考えだと主張しています。重要なプロジェクトでは、ソフトウェア製品のライフサイクルのフェーズを完全に終了してから次のフェーズに進み、そこから学ぶことは不可能だと考えています。たとえば、クライアントは、動作中のプロトタイプを確認してコメントする前に、必要な要件を正確に把握していない場合があります。彼らは絶えず彼らの要件を変えるかもしれません。設計者とプログラマーはこれをほとんど制御できないかもしれません。設計が完成した後にクライアントが要件を変更した場合は、新しい要件に対応するように設計を変更する必要があります。これは事実上、かなりの労働時間を無効にすることを意味します。これは、特にプロジェクトのリソースの大部分がすでにBig Design Up Frontに投資されている場合、コストの増加を意味します。
これらの設計方法は、解釈する部分や構造に独自のタッチを加える方法がまだあるため、設計の個人主義の実装者を押しつぶすことはありません。骨格を与えられ、筋肉や他の組織を追加して動物を作成する写真は、その動物を設計するためにどれだけの自由が必要だったのか疑問に思っていますか？
はい、滝の欠点を見つけましたが、すべてに長所と短所があります。
クラスでは、さまざまなソフトウェア開発方法について学びます。私たちが重点的に取り組み、プロジェクトの開発に使用したのは、ウォーターフォール法でした。
あなたはおそらく、最初からソフトウェア開発の世界にそれを導入したと考えられている人が大規模なソフトウェアシステムの開発には不適切であると述べた古典的なウォーターフォールモデルを学んだでしょう。多くの人がウォーターフォールモデルと見なしている問題の詳細については、 Winston Royceの「大規模ソフトウェアシステムの開発の管理」というタイトルの論文 を読むことに興味があるでしょう。
ただし、ウォーターフォールモデルは、ソフトウェア開発ライフサイクルを学習する際に役立ち、要件エンジニアリング、アーキテクチャ設計、詳細設計、実装、テスト、および保守について、非常に明確で明確なフェーズで学習および実行するために時間を費やすことができます。
クラス図では、プライベートプロパティを含むすべてのプロパティとメソッドをリストする必要がありました。私は、関数をできるだけ短く、集中させるようにと言っている数冊の本、すなわちCleanCodeを読みました。他の開発者を助けない場合は、図にすべての小さな関数をリストするのは面倒なようです（それらはプライベートであり、他の誰もそれらを使用しません）。さらに、プログラムを設計するときにすべての小さな機能を考えるとは限らないかもしれません。リファクタリングするときにそれらが出てくるかもしれません。
これらはすべて非常に有効なポイントです。
Waterfallを使用している場合でも、設計段階ですべてのプロパティとメソッドを一覧表示するのは、おそらくやり過ぎです。公開されているすべてのものと、必須プロパティを必ずリストする必要があります。実際には、他のすべては、実装をダイアグラムにリバースエンジニアリングすることで取得できる実装の詳細です。
Clean Codeのアドバイス（私は一度も読んだことがない-私はあなたが投稿したものをそのまま読みます）は公平で、Waterfall手法を使用している場合でも適用できるようです。 単一責任の原則 、 関心の分離 、および [〜＃〜] solid [〜＃）の他の原則に関してクラスとメソッドを設計できます。 〜] 。ウォーターフォールは、必要なときにだけ、デザインの方法を教えてくれません。とは言うものの、実装中にそれを行うためのより良い方法を学び、考えるにつれて、事前に困難になります。
これは、設計と実装の間に反復が非常に明確に必要であるという事実を示していると思います。これは、従来のウォーターフォールでは説明できない問題です。
他の開発者を助けない場合は、図にすべての小さな関数をリストするのは面倒なようです（それらはプライベートであり、他の誰もそれらを使用しません）。
これが面倒だと思ったら、本当の仕事のプログラミングができるまで待ってください。しばらくの間、そのソフトウェアはあなたにとって実行可能なキャリアではないかもしれないと考えてください。
さらに、プログラムを設計するときにすべての小さな機能を考えるとは限らないかもしれません。リファクタリングするときにそれらが出てくるかもしれません。
そう？
インストラクターは、すべての機能をリストするように依頼して、私たちに間違ったことを伝えましたか？
いいえ。これは一般的な要件です。
そして、これらの設計方法は、設計の実装者（開発者）の個人主義を押しつぶして、コードをどのように最も理解できるかをコードに記述しますか？
はい。個人の魂を砕くのは、ソフトウェア開発の重要な部分です。すべての個性は、すべての可能な方法で常にすべてのプログラマーから打ち負かされます。 「神のプログラミングのルール」のどこかで、ある山からある預言者に受け継がれたと書かれています。
いいえ。退屈なことをしているだけです。それを乗り越えて、仕事に戻ります。
プログラミングは、制約の範囲内で作業する技術です。 CPUは限られた命令セットを提供します。 IOは、ハードウェアの設計によって制約されます。OSAPIは、特定の動作を促進し、他の動作を制限するために作成されます。高水準言語は、多くの場合、1つのイディオムセットを他のものよりも促進するように設計されています...
そして、方法論も制限するように作られています。
開発プロセスのすべての側面でのあなたの課題は、あなたのビジョンを実現することです内これらの制約。ハードウェア、言語、API、および方法論によって投げ出された各壁に頭をぶつけますか？それとも、達成したいことを許可され奨励されていることと調和させる方法を見つけますか？
あなたは本当に先生が細部の無限のページを読みたいと思っていると思いますか？次に、その理論をテストします。プログラムを分割し、各アトムを文書化します。彼の机が重荷の下で垂れ下がっているとき、私はむしろあなたが彼の本当の欲求があなたが期待するものと多少異なることに気付くのではないかと思います。
または、ドキュメントをyo seefitとして準備します。明確にし、理解しやすくし、ダシール・ハメットの小説のように読んでください。そして、座って彼と話し、あなたがしたことを彼に示し、彼にそのメリットを納得させます。
プロジェクト分析の複雑さを評価するための簡単な経験則は、「開発者または彼が働いている会社は、作成されたソフトウェアで発生する十分に劇的な何か（一般に死や莫大な金額の損失を含む）に対して責任を負うことができますか？」です。
私のいくつかのコースでは、あなたと同じ経験をしました。軍事業界のバックグラウンドを持っている人は私たちに分析を教えてくれるでしょう。そして、それは完全かつ徹底的な分析であり、プロジェクトのすべてのコースを計画します。この種のプロジェクトでは多くの反復を行う余裕はありません（爆弾の爆発は問題ありませんが、予算の爆発は問題ありません）。したがって、ここには創造性の場所がないため、計画を実行する必要があります。
一方、少し読んだことがあれば、確かにアジャイル手法について読んだことでしょう。一般に、ドキュメントは少なく、開発者が遭遇した問題の解決策を開発する際に創造性を活用する余地があります。
結論として、あなたが得る経験が多ければ多いほど、より良く、そしてあなたのインストラクターがあなたに示していることは、業界のある部分に当てはまります。確かに、プロジェクトを管理および設計するには、コーディングする方法と同じくらい多くの方法があることに注意してください。そして、あなたはそれらすべてのための擁護者と批評家を見つけるでしょう。あなたが勉強している間にそれらをテストし、あなたが満足しているものを選んでください。
インストラクターは、このプロジェクトを実行させて、ウォーターフォール開発の長所と（ほとんど）短所を教えてくれる素晴らしい人だと思います。
あなたのインストラクターは連絡が取れていないと思います。商用ソフトウェアがその程度まで設計または文書化されることはめったにありません。それは非常に高価であり、結果として得られるドキュメントは、さらに多くの費用をかけずに維持することはできません。 IMOのような慣行は、コーディングがアセンブリ言語で行われることが多かった時代からの遺産です。テスト駆動開発、ペアプログラミング、継続的なリファクタリングなど、よりアジャイルなプラクティスを試すことに時間を費やしたほうがよいでしょう。
インストラクターは「あなたに間違ったことを言った」のですか？
私はそう思う。
退屈な仕事を知的財産労働者に割り当てることは無駄です。学校では、退屈な仕事は、おそらく学生に退屈な仕事をさせない限り、教育的価値はほとんどないかまったくありません。このような演習は、学生と業界の両方に悪影響を及ぼします。時間が無駄になっているため、生徒たちは危害を加えられています。一部の学生はそのような退屈が必要であり、有用であると結論付けるかもしれないので、業界は害を受けています。どちらでもありません。ソフトウェアでの30年間、私が考えることができる唯一の作業は、退屈で便利なものでしたが、バックアップテープを交換することでした。それを行うことができるロボットがありましたが、それらは法外に高価でした。
私が持っていたようないくつかのソフトウェアエンジニアリングクラスは、「失敗は成功である」、成功は失敗から学ぶための無駄な機会であり、より多くはより少なく、より少なくなるという奇妙なスタイルで教えられています。これがそれらの1つである場合は、割り当てに固執して、奇妙さを楽しんでください。