開発方法は開発者の個人主義を押しつぶすべきか？

私は大学の最終学期にいて、ソフトウェアエンジニアリングのコースを受講しています。クラスでは、さまざまなソフトウェア開発方法について学びます。私たちが重点を置き、プロジェクトの開発に使用したのは、ウォーターフォール法でした。

インストラクターが間違って実装したようです。クラス図では、プライベートプロパティを含むすべてのプロパティとメソッドをリストする必要がありました。私はいくつかの本、つまりClean Codeを読みましたが、これは関数を可能な限り短くし、焦点を絞っていると述べています。他の開発者の助けにならない場合、ダイアグラムにすべての小さな関数をリストするのは面倒です（それらは非公開で、他の誰も使用しません）。さらに、プログラムを設計するときにすべての小さな関数について考えることはないかもしれません。リファクタリングするときにそれらが一緒に来るかもしれません。

インストラクターは、すべての機能をリストするように依頼して、私たちに間違ったことを伝えましたか？そして、これらの設計方法は、開発者の個人主義を押しつぶして、コードを最もよく理解できるようにコードを記述しますか？

すべてのメソッドをリストする必要がある理由を講師に尋ねましたか？

教室環境で求められることの多くと同様に、クラス図を開発者にとってより役立つものにするのではなく、クラスメートがクラスをどのように設計するかについて考える手助けをすることが目的であった可能性があります。生徒が大きな問題を小さな問題に分解する方法を学んでいるとき、おそらく彼らが必要とする可能性のあるプライベートな方法について考えることは彼らにとって役立つでしょう。また、誰かの設計が十分に検討されていない場合に、プロセスの早い段階で介入するために、学生が実装を検討しているメソッドについてよりよく理解することは、おそらくインストラクターにとって役立つでしょう。教室環境でのドキュメントは、実際の環境でのドキュメントよりもはるかに複雑になることがよくあります。

もちろん、インストラクターがこのレベルのドキュメントが実際のプロジェクトに役立つと信じている可能性もあります。その場合、インストラクターはおそらく時代遅れであるか、またはこのレベルの計画と文書化が適切である特定のニッチなバックグラウンドに由来しています。たとえば、スペースシャトル用のナビゲーションシステムを構築している場合や、医療機器を設計している場合は、開発中にコードをリファクタリングするよりも、設計に多くの投資をする方が一般にはるかに適切です。一方、ソーシャルネットワーキングサイトを開発している場合は、より機敏なアプローチがより適切です。

いいえ、ウォーターフォールメソッドを使用している場合、インストラクターはすべてのプロパティとメソッドを事前にリストするように指示しています。 ウィキペディアは滝の批判に言及している：

多くの人は、ウォーターフォールモデルは実際には悪いアイデアであると主張しています。重要なプロジェクトでは、ソフトウェア製品のライフサイクルのフェーズを完全に完了してから次のフェーズに移動して学習することは不可能だと信じています。たとえば、クライアントは、実際のプロトタイプを確認してコメントする前に、必要な要件を正確に把握していない場合があります。彼らは彼らの要求を絶えず変えるかもしれません。デザイナーやプログラマーはこれをほとんど制御できない場合があります。設計の確定後にクライアントが要件を変更した場合、新しい要件に対応するように設計を変更する必要があります。これは事実上、かなりの労働時間を無効にすることを意味します。これは、特にプロジェクトのリソースの大部分がBig Design Up Frontにすでに投資されている場合は、コストの増加を意味します。

これらの設計方法は、解釈する部分があり、構造に独自のタッチを加える方法があるため、設計の個人主義の実装者を押しつぶしません。あなたはその動物をデザインする必要がありましたか？

滝の欠点はありますが、すべてに長所と短所があります。

クラスでは、さまざまなソフトウェア開発方法について学びます。私たちが重点を置き、プロジェクトの開発に使用したのは、ウォーターフォール法でした。

おそらく、古典的なウォーターフォールモデルを学んだことでしょう。これは、ソフトウェア開発の世界に導入したとされた人物が最初から大規模なソフトウェアシステムの開発には不適切であると述べたものです。おそらく、読書に興味がある大規模なソフトウェアシステムのDevelopemtの管理と題したウィンストン・ロイスの論文より多くの人々はウォーターフォールモデルであると考えるものとの問題について学ぶために。

ただし、ウォーターフォールモデルは、ソフトウェア開発ライフサイクルの学習に役立ち、要件エンジニアリング、アーキテクチャ設計、詳細設計、実装、テスト、およびメンテナンスについて、非常に明確で明確なフェーズで学び、実行することに時間を費やすことができます。

クラス図では、プライベートプロパティを含むすべてのプロパティとメソッドをリストする必要がありました。私はいくつかの本、つまりClean Codeを読みましたが、これは関数を可能な限り短くし、焦点を絞っていると述べています。他の開発者の助けにならない場合、ダイアグラムにすべての小さな関数をリストするのは面倒です（それらは非公開で、他の誰も使用しません）。さらに、プログラムを設計するときにすべての小さな関数について考えることはないかもしれません。リファクタリングするときにそれらが一緒に来るかもしれません。

これらはすべて非常に有効なポイントです。

ウォーターフォールを使用している場合でも、設計段階ですべてのプロパティとメソッドを一覧表示することは、おそらくやりすぎです。あなたは間違いなく、公開されているすべてのものと必須プロパティをリストする必要があります。実際には、他のすべては実装の詳細であり、実装を図にリバースエンジニアリングすることで取得できます。

Clean Codeのアドバイス（私は一度も読んだことがない-私はあなたが投稿したものをそのまま読みます）は公平で、Waterfall手法を使用している場合でも適用できるようです。単一の責任の原則、懸念の分離、およびSOLIDの他の原則に関して、クラスとメソッドを設計できます。ウォーターフォールは、必要なときにだけ、デザインの方法を教えてくれません。とはいえ、実装時にそれを行うためのより良い方法を学び、考えると、事前の対応は難しくなります。

これは、設計と実装の間の反復が非常に明確である必要があるという事実を指摘していると思います-従来のウォーターフォールでは考慮されていない問題です。

他の開発者の助けにならない場合、ダイアグラムにすべての小さな関数をリストするのは面倒です（それらは非公開で、他の誰も使用しません）。

これが面倒だと思ったら、本当の仕事のプログラミングができるまで待ってください。しばらくの間、そのソフトウェアはあなたにとって実行可能なキャリアではないかもしれないと考えてください。

さらに、プログラムを設計するときにすべての小さな関数について考えることはないかもしれません。リファクタリングするときにそれらが一緒に来るかもしれません。

そう？

インストラクターは、すべての機能をリストアップするように依頼して、私たちに間違ったことを伝えましたか？

いいえ。これは一般的な要件です。

そして、これらの設計方法は、設計の実装者（開発者）の個人主義を押しつぶして、コードをどのように最も理解できるかをコードに記述しますか？

はい。個人の魂を砕くことは、ソフトウェア開発の重要な部分です。すべての個性は、あらゆる方法で、すべてのプログラマーから常に打ち負かされます。「プログラミングの神のルール」のどこかで、ある山からある預言者に伝えられたと書かれています。

いいえ、あなたは退屈なことを考えているだけです。それを乗り越えて、仕事に戻ります。

プログラミングは、制約の範囲内で作業する技術です。CPUが提供する命令セットは限られています。IOはハードウェアの設計によって制約されます。OS APIは、特定の動作を奨励し、他の動作を制限するために作成されます。高水準言語は、多くの場合、イディオムのセットを他のセットよりも促進するように設計されています...

そして、方法論も制限するように作られています。

開発プロセスのすべての側面でのあなたの課題は、それらの制約内でビジョンを実現することです。ハードウェア、言語、API、方法論によって投げつけられるそれぞれの壁に頭をぶつけますか？それとも、達成したいことと許可され奨励されていることを調和させる方法を見つけますか？

あなたがでください本当にあなたのインストラクターは、特徴点の無限のページを読んですることを希望すると思いますか？次に、その理論をテストします。プログラムを分割し、各アトムを文書化します。彼の机が重みで垂れ下がっているとき、むしろあなたは彼の本当の欲求があなたが期待するものとは多少異なることに気付くのではないかと思います。

または、必要に応じてドキュメントを準備します。明確にし、理解しやすくし、ダシール・ハメットの小説のように読んでください。そして、座って彼と話し、あなたが何をしたかを彼に示し、彼にそのメリットを説得してください。

インストラクターは、あなたにこのプロジェクトをやらせ、ウォーターフォール開発の長所と（ほとんど）短所を教えてくれる素晴らしい人だと思います。

プロジェクト分析の複雑さを測定する簡単な経験則は、「作成したソフトウェアで発生する劇的な事態（一般的には死亡や巨額の損失を含む）が発生した場合、開発者またはその会社が責任を負うことができるか？」です。

私のいくつかのコースでは、あなたと同じ経験をしました。軍需業界でのバックグラウンドを持っていた人々は私たちに分析を教えてくれました。そして、それは完全で徹底的な分析であり、プロジェクトのすべてのコースを計画します。この種のプロジェクトでは多くの反復を行う余裕はありません（爆弾の爆発も大丈夫ですが、予算の爆発もそうではありません）。そのため、ここでは創造性を発揮する場所がないため、計画に従う必要があります。

一方、少し読んだことがあれば、アジャイル手法については確かに読んだことでしょう。一般に、ドキュメントが少なくなり、開発者が直面する問題の解決策を開発する際に、開発者が自分の創造性を使用する余地が増えます。

結論として、あなたがより多くの経験を積むほど、より良くなり、あなたのインストラクターがあなたに示していることは、この業界の一部に当てはまります。プロジェクトを管理および設計する方法は、コーディングする方法と同じくらい確かにあることに注意してください。そして、あなたはそれらのすべてのための擁護者と批評家を見つけるでしょう。あなたが勉強している間にそれらをテストし、あなたが満足しているものを選んでください。

私が持っていたものなど、一部のソフトウェアエンジニアリングクラスは、「失敗は成功」、「失敗は失敗から学ぶ無駄な機会」という奇妙なスタイルで教えられています。これがその1つである場合は、割り当てに固執して、奇妙さを楽しんでください。

あなたのインストラクターは連絡がないと思います。商用ソフトウェアがその範囲で設計または文書化されることはほとんどありません。それは非常に高額であり、結果として得られるドキュメントはさらに多くの費用なしで維持することはできません。IMOのようなプラクティスは、コーディングがアセンブリ言語で行われることが多かった時代の遺産です。テスト主導の開発、ペアプログラミング、継続的なリファクタリングなど、よりアジャイルなプラクティスを試すのに時間を費やす方がよいでしょう。

インストラクターは「間違っていると言った」のですか？

私はそう思う。

退屈な仕事を知的財産労働者に割り当てることは無駄です。学校では、退屈な仕事は、おそらく学生に退屈な仕事をさせない限り、教育的価値はほとんどまたはまったくありません。このような演習は、学生と業界の両方に悪影響を及ぼします。時間を無駄にしているので学生は危害を加えられます。一部の学生はそのような退屈さが必要であり、有用であると結論付けるかもしれないので、業界は害を受けています。どちらでもない。ソフトウェアの30年間で、退屈で便利なのはバックアップテープの交換だけでした。それを行うことができるロボットがありましたが、それらは法外に高価でした。