ソフトウェアエンジニアリングについて間違った考えを持っていますか？[閉まっている]

私の最新の仕事（むしろインターン）によって提起された質問があります。

状況を整理するために-私は21歳で、大学の2年目を終えてから、システム管理/ QAの仕事を2年ほど経験しましたが、基本的には、 ITセクターが運営されています。現在にさかのぼり、ここに私が英国の主要な研究機関の1つで実習生を募集しています。

私がしなければならないのは、さまざまなテクノロジー（主にAWS / Java / Bash）を使用して内部ツールを作成することです。すべては大丈夫です、私は仕事をしていますが、私は幸せではありません。なぜですか-アドホックな問題で働くことが期待されているからです。それは、設計に時間を費やすことなく、ものをすばやく作成することです。私のマネージャーは、問題が発生するとすぐに問題を「急ぐ」ことが予想されると明示的に述べました。結果として、物事をやり直し、再設計する必要があり、それらはまだ完全ではないことが判明しました。テストに関する限り-最小限に抑えてください。動作しているようであれば、問題ありません。

この仕事のやり方に反対するのは間違いですか？システム全体を考え、さまざまなコンポーネントに焦点を合わせ、それらがどのように相互作用するかを見て、将来問題になる可能性のあるさまざまな「キーポイント」に焦点を合わせたいと思うのは間違っていますか？「迅速な仕事」ではなく、良い仕事をしたいのは犯罪ですか？特定の問題セットに応じて最適なものを選択できるように、問題に適用可能なデータ構造を調査するのは間違いですか、それとも間違った態度ですか？私の理解の限りでは、「ソフトウェアエンジニアリング」の「エンジニアリング」ビットはこれと正確に関係しています。問題の領域を調査し、情報に基づいたソリューションを考え出し、必要に応じて改良しますか。

私は英国のArm'sオフィスでインタビューに行ってきましたが、彼らは彼らのSCRUMルームを見せてくれました。問題の解決には時間がかかる場合があります-SCRUMの通常のこと-「ここ」での実行方法とはまったく異なります

ソフトウェア業界全般について間違った考えを構築しましたか？そのことについてあなたの意見を聞きたいです。純粋でシンプルなものを作りたいからといって、純粋にソフトウェア開発を「始めた」のですが、質の高いものを作りたいのです。さまざまなシナリオでソフトウェアが使用されていることを確認したいのですが、完全な証拠を見たいと思います。それがすべてのソフトウェアエンジニアの原動力ではないでしょうか。構文を学ぶだけで誰もがプログラマー/コーダーになることができると思いますが、私にとって本当の楽しみは、現実世界で実行可能な設計を実際に考えなければならないときに始まります。

私は大学の課題を見て、コーディングを直接開始していたため、75％を超えるマークを簡単に取得でき、「ソフトウェア開発ライフサイクル」モジュールを高く評価することはありませんでした。しかし今、現実の世界で、正式なプロセスや、要件が明日変更されるかどうかわからない状況に内在するフラストレーションなしで作業するのがどれほど悪いかを見たとき、 「要件分析を明確に定義していない？）

私は、一部の人々が汚い仕事をするのにコードモンキーを必要とするだけの地位に着いたと信じているのが本当に好きです。これは、ソフトウェアの世界がどのように動作するかということではありません。

ソフトウェアを再利用可能にして防弾にすることは、ソフトウェアエンジニアリングの原動力ではありません。エンジニアリングとは、現実世界の制約内で現実世界の問題を最適に解決することです。ほとんどのエンジニアはフェラーリで作業することを好むでしょうが、ステーションワゴンは同じくらい多くのエンジニアリングを必要とします。 。

「迅速な仕事」ではなく「良い仕事」をしたいという場合、ほとんどのエンジニアはそうしますが、良いことを定義するものの一部は、完了までの時間の速さです。ですから、「良い」と「速い」を対立する選択と考えるのは正しくありません。または、あなたが悪い仕事をしていると思うか、利用可能な時間内に可能な限り最高の仕事をするための単なる「コード猿」です。

もちろん、プロセスが最適ではない可能性が非常に高く、前もって設計を少しすればより良くなります。酸テストは、ユーザーのために解決するよりも多くの問題を作成する現在の方法ですか、それともそのように作業しなければならない開発者を盗聴するだけですか？それが実際にユーザーに問題を引き起こしている場合、あなたの仕事の一部は、これが事実であることを実証しようとすることであり、人々をやや制御されたプロセスに引き込もうとすることです。

実際、これは私を悩ます。あなたは、研究科学者向けのツールを開発する職業にいます。ただし、これらのプログラムを迅速に実行し、最小限の動作であるように見せるように指示されます。サプライズサプライズ。これは、研究者のプログラミングに対する典型的なアプローチであり、実際のプログラマーに渡されます。

ここでの主な懸念は、ツールに重要な目的がある場合、特にテストの欠如は倫理的に疑わしいことです。最小限のテスト時間に制限されているためにソフトウェアに欠陥があるかどうかわからない場合、これはソフトウェアの動作状態に対する責任を負わないことを意味し、アトラスは肩をすくめます。

停止して、これについて少し考えてみましょう。どのようなツールを開発していますか？データをモデル化するソフトウェアを開発している場合、ここには大きな倫理的ジレンマがあります。状況によっては、科学的研究は多くの人々に大きな影響を与える決定につながります。

人工気候変動の論争の的となっているトピックを一瞬で考えてみましょう。彼らが今日持っている結論に到達するために使用するのと同じ標準をモデリングソフトウェアに置いたとしましょう。このトピックは、環境と国際政策を正しく管理する方法に大きな影響を与えます。

モデリングソフトウェアにその予測に関する大きな問題がないことを保証することは倫理的ではありませんか？

全体の問題は、温室効果ガスが地球を暖めることではありません。問題は、フィードバック効果の最終的な結果が温度の加速ゲインであるかどうかであり、これはしきい値を超えた後は可逆的ではなくなります。

上記のゲインが発生していた場合、最終結果の証拠はわずかであり、おそらくエラー範囲内です。

そのため、わずかな誤計算は、バックエンドでのデータの保存と取得を含む方法論でさえ、障害の一端で深刻な環境問題を無視したり、多くの人々に影響を与える国際的な政策（仕事を破壊したり、年金を破壊したりするなど）につながる可能性があります） もう一方の。

だから、はい、あなたは正しいです。研究のペースがどうであっても構いません...データを管理し、計算を実行するために研究者がソフトウェアツールに依存したい場合、ソフトウェアが正しく実行されるのを待つ必要があります。さもなければ、このソフトウェアは、彼らが説明責任を負わないという彼らの理論の脆弱点となり、倫理的な不正行為をもたらします。

あなたはソフトウェアエンジニアリングとは何かについて間違った考えを持っていません。ただし、非常に重要な側面が欠落しています。これはサービス業界です。私たちの中には、何年も製品に取り組み、設計を経て、それがv1になる前に何度も反復するものがあります。他の人は3時間で何かを生み出さなければなりません。それはあなたが誰にサービスを提供しているか、そして何が目的かによって異なります。

本来の目的を果たすアプリケーションを3時間（または数日）で作成できる場合、前もって設計するためにより多くの時間を費やすのはなぜですか？あなたはお金を無駄にしているだけです。お金を無駄にすることは、Good Idea™ではありません。

他の人がすでに言ったように、ソフトウェアエンジニアリングの大部分は「外因性制約」です。例えば。時間、予算、サービス、サポート、不合理なばかげた要求の充足など

私たちの多く（私自身も含めて）は、プログラミング自体がすべてであると考えてプログラミングを始めました。美しく洗練されたソフトウェアを真空（または少なくとも相対真空）でコーディングします。めったにありません。珍しいアカデミックまたはR＆Dソフトウェアの仕事がそれに近づくかもしれませんが、ほとんどの場合、ソフトウェア開発作業の圧倒的多数はそのようなものではありません。特にメンテナンス段階（通常は製品の寿命の90％以上）と、ほとんどの恒久的な商用ソフトウェア作業の日常業務です。

長い間、私はこれについて内部の葛藤を抱いていたので、しばしば自分の仕事に不満を抱いていました（そして、それは最終的に昨年の燃え尽き症候群の原因の一部です）。そうでないと仕事はつまらないといつも感じていた美しいコードの作成とそれを適切に行うための時間をかけるすべて。しかし、実際には、これが現実です。実際、非常にサービス指向のワークフローで成功している人もいます。それが彼らを実用的で有用だと感じさせるものです。プロジェクトの実際の「純粋なソフトウェアエンジニアリング」の側面が比較的急ぎすぎてずさんなものになったとしても。

とにかく、今これに疑問を抱いているのは良いことです。これは、彼らが学校で本当に適切に説明することのないものの一つです。そして、企業は、たとえ従わなくても、非常に優れたエンジニアリング慣行に従うように見せかけるのが大好きです。ヒント：ほとんどありません。

とはいえ、状況はさまざまです。特定の企業（主にソフトウェアがコアビジネスである企業、および医療機器などの安全性が非常に重要なソフトウェアに取り組んでいる企業）は、非常に厳しいエンジニアリングプロセスに従います。しかし、全体的には、はい、ほとんどの商用ソフトウェアの作業は比較的ずさんなので、空白を指摘しておきます。通常、何らかの正式なプロセスがありますが、それに固執することは、ほとんど常に、クライアントの入力や他の商業的な圧力に対応するために後部座席を取ります。それは実際には「ずさん」ではなく、単なる実用的な実用性です。秘Theは、自分のニッチを見つけて、その「純粋なプログラミング」の面がいかにクールであるかではなく、提供するサービスの観点から役割を見ることです。

編集：私は私の最初の評価であまりにも一方的に聞こえたかもしれないと思う。私は、多くの場合、そこにいることを追加したいと思います物事があることと、本物の問題も、あまりにもずさんで、かつ良好なプロセスの欠如-それは技術的負債にプロジェクトを駆動し、ビジネスのために実際に悪いですポイントに。しかし、これを見るには経験が必要です。当初のポイントは依然として基本的なものです。今日のほとんどの商用ソフトウェアの仕事は、純粋主義者が好むほど厳格なエンジニアリング指向ではありません。

なんて素晴らしい質問でしょう！时々速くすることで価値あるものを作ることができます。これは通常、わからないことを早く学べるほど、より良い結果が得られる研究室の場合です。作成するソフトウェアは、質問に答えるためだけに存在します。「使い捨てコード」です。これは、顧客が本当に望んでいることを知らないスタートアップにも当てはまります。また、最初に何かを作るとき、それは安っぽいでしょう。The Mythical Man-Monthを読んでください。

時にはあなたは良いことによって価値あるものを作ることができます。これは通常、Adobe Photoshopのようなシュリンクラップされたソフトウェアの場合です。調査はすでに数年前に行われましたが、今では、顧客が必要とする機能のリストをバグを導入しない方法で追加する方法が問題です。それは、アーキテクチャ、設計、およびテスト、テスト、テストの問題です。コード自体は価値があるものであり、あなたがそれから学ぶものではありません。

研究に満足できない場合（何かを最初に作成し、誰も知らなかった新しいことを学ぶ）、シュリンクラップされたソフトウェアを試してみてください。実際、あなたの年齢では、できるだけ多くのことを試してください。リスクを冒してください！あなたは多くを学び、長期的にはより良くなるでしょう。

適切な設計や適切なテストなしに物事を迅速に行うと、戻ってくる傾向があることに気づいたと思います。あなたは明らかにこれが好きではなく、あなたにはそうしない正当な理由があります。特に最初の解決策が不正確または不完全な場合に後でそれらを再検討する必要がある場合は、「問題を急ぐ」ことが期待されるのはばかげています。問題を完全に理解している場合のみ、問題の解決策を提供できますが、それには時間と慎重な計画が必要です。

あなたへの私の提案は、これがあなたを悩ませていることをあなたの上司に知らせ、あなたの仕事をするためのより良いアプローチを彼らに提案することです。もし彼らが同意せず、あなたがあなたの仕事を「急いで」続けて欲しいなら、私は他の場所で仕事を探し始めます。業界が期待するソフ​​トウェア開発品質の基準は言うまでもなく、独自の基準に達しない方法で物事を行うことに意味はありません。

私の経験に基づいたアドバイスは次のとおりです。私は20歳で、現在イギリスの主要な金融機関で就職活動を行っています。数か月前と同じ気持ちでしたが、これはおそらくあなたがしている仕事。

それが私が意味することはあなたが言ったことです：

「私がしなければならないことは、テクノロジーの混合を使用していくつかの内部ツールを作成することです-主にAWS / Java / Bash」

また、特定のプロセスの管理と自動化に役立つ内部ツールを作成する必要がありました。実際、ペースの速い環境では、「小さな」ものを迅速に実装する必要があります。数週間でツールの作業バージョンが必要になったため、2年目に教えられたソフトウェアエンジニアリングまたはアルゴリズムとデータ構造の原則のほとんどを適用する余裕がありませんでした。より読みやすいコードを書く方法を学んだので、すべてが悪いわけではありません。

私は辛抱しなければならなかったので、最近、10K以上のユーザーが使用する社内構築システムの新しい反復に取り組んでいる新しいチームに交代しました。ソフトウェアエンジニアリングの側面が非常に真剣に受け止められていることを保証できます。要件のキャプチャ/分析から実装およびテストに至るまで、ソフトウェアのライフサイクル全体に触れることができると言われました。私は内部ツールに取り組んでいないが、大規模なユーザーベースでフルスケールのシステムに取り組んでいるので、この経験を得ると信じています。

私がお勧めするのは、忍耐強く、ツールの作成を終了し、非常に良い仕事をして、スーパーバイザーがあなたに対する信頼を高め、ソフトウェア工学の原則を使用する必要があるより難しいタスクを割り当てることです。余分な読書をすることから余分な知識を得て、その知識を現在あなたがしていることに適用します。私が読んだすべての本から私の知識をさらに高めるために、会社の電子書籍ライブラリ全体を略奪しました。本当に良い本でした

忍耐強く、あなた自身の知識に多額の投資をし、可能であればその知識を適用してください。あなたが非常に良い仕事をしているなら、誰かはすぐに気づくでしょう。

はい、あなたの現在の仕事のやり方が次善であることに同意します。しかし、それがまったく機能しないと言いたい場合は、さまざまな結果があり、機関はまだ存在しているので、私はあなたに反対します。

私の主な質問は、医療患者に応急処置をするのと同じように、すぐに解決が必要な火災にどの程度対処するのかということです。すぐに行う必要はありませんが、短期的にはテストやさまざまな手順をスケジュールする必要があります。

時間をかけて仕事をうまくやるには、組織の成熟度と、何かを成し遂げるという主張に対して、成し遂げることがいかに重要であるかに少し依存します。

データ構造の調査に関する問題は、これをどのくらい続けたいかです。数時間かかるのとはまったく異なるデータ構造を10年かけて調査したい場合。私は最高の答えを得るために意欲を鑑賞することができますが、問題にいくつかの時間を過ごした後、収穫逓減のために言うことに何かを、例えば、そこにあるあなたは解決策見つける時間を過ごすことができFizzBu​​zzをあなたは上のさまざまな言語でそれを解決しようとすることができてさまざまなハードウェアを使用して、実行速度を最適化します。

研究することは重要ですが、何かを提供することも重要です。あなたが何かを届けないなら、あなたは本当にどれくらい良いですか？ ダクトテーププログラマーは、ここで物事を成し遂げるより多くの例です。

スクラムは、現在の職場で採用できる可能性のある特定の方法論です。ただし、スクラムが特効薬だとは思わないでください。 スクラムとアジャイルのプロジェクトはどのような状況で失敗しますか？興味があるかもしれないその主題に関するブログ投稿になります。

私の推測では、あなたはあなたの現在の場所のプロセスがどれほど非公式であるかを見ておらず、正式な方法論がある反対側では草が非常に環境に優しいと考えています。そこにいる方が良いかもしれませんが、カウボーイになるという大きな自由を持っているあなたが今持っているものを好む人もいるかもしれません。

あなたの状況は、質の面にあまり重点を置いていない現実世界の規模にあると思います。あなたの好みは現実世界の反対側にあります。仕様は変更されます。物事を成し遂げる必要があります。

次の仕事に応募するときに、これらのタイプの企業を識別する方法を検討してください。開発者に設計を永久に分析させるビジネスモデルがある場所はほとんどありません（教授でさえ教える必要があります）。作業がドライイレーズボードを離れない場合、クライアントはほとんど支払いません。キャリアの早い段階であなたが自分を狂わせるのを見るのは嫌いです。