ソフトウェアエンジニアリングについて間違った考えがありますか？
私の最近の仕事（むしろインターン）によって提起された質問があります。
状況を説明するだけです-私は21歳で、大学の2年目を終えてから、システム管理/ QAの仕事をするのに約2年の経験がありました。基本的に、どのように違うかを見てきました。 ITセクターが運営。現在を振り返って、英国で最も優れた研究機関の1つにインターンとして就職しました。
私がしなければならないことは、テクノロジーの組み合わせを使用していくつかの内部ツールを作成することです-主にAWS/Java/Bash-画像を取得します。すべては大丈夫です、私は仕事をしていますが、私は幸せではありません。それはなぜですか-私は臨時の問題で働くことが期待されているからです。それは、設計に時間を費やすことなく、物をすばやく作成することです。私のマネージャーは、問題が発生したとき、そして本質的には問題を「突破」することが期待されると明確に述べました。その結果、物事をやり直し、再設計する必要があり、それでも完璧ではないことがわかりました。テストに関する限り-機能しているように見えれば問題ないので、最小限に抑えます。
私はこの仕事のやり方に同意しないのは間違いですか？システム全体を考えてから、さまざまなコンポーネントに焦点を当て、それらがどのように相互運用できるかを確認して、将来問題になる可能性のあるさまざまな「重要なポイント」を特定するのは間違っているでしょうか。 「迅速な仕事」ではなく、良い仕事をしたいのは犯罪ですか？特定の問題セットに応じて最適なものを選択できるように、問題に適用可能なデータ構造を調査するのは間違いですか、それとも間違った態度ですか？私の理解するところによると、「ソフトウェアエンジニアリング」の「エンジニアリング」ビットはこれと正確に関係しています。問題ドメインを調査し、情報に基づいたソリューションを考え出して、必要に応じて調整しますか？
私は英国のArmsのオフィスでのインタビューに行ったところ、彼らはSCRUMルームを見せてくれました、そして彼らは彼らのプロジェクトを管理する方法に関してかなり良い考えを持っていたようです-彼らはバックログを持っていました問題の解決には時間がかかる場合があります-SCRUMの通常のこと-「ここ」での実行方法とは完全に異なります
一般的にソフトウェア業界について間違った考えを作りましたか？その点についてのご意見をお待ちしております。純粋にシンプルなものを作成したいが、質の高いものを作成したいという理由だけで、ソフトウェア開発に「参入」したということです。さまざまなシナリオで使用されているソフトウェアを確認したいのですが、それを完全な証拠として確認したいのです。それが、すべてのソフトウェアエンジニアの原動力ではありませんか？構文を学ぶだけで誰もがプログラマー/コーダーになれると思いますが、私にとって本当の楽しみが始まるのは、実際に実行可能なデザインを実際に考え出さなければならないときです。
以前は大学の課題を見て直接コーディングを始めていたため、75％を超える点数を簡単に得ることができ、「ソフトウェア開発ライフサイクル」モジュールを高く評価することはありませんでした。しかし、現実の世界で、正式なプロセスなしで機能することがいかに悪いか、要件が明日変更されるかどうか分からない状況に固有のフラストレーションを見たとき（ああ、私たちが要件分析が明確に定義されていませんか？）
私は本当に、一部の人々が汚い仕事をするためにコードモンキーを必要とするだけの立場にたどり着いたと信じたいのですが、これはソフトウェアの世界が全体としてどのように動作するのかではありません。
ソフトウェアを再利用可能にし、弾丸を証明することは、ソフトウェア工学の原動力notです。エンジニアリングとは、現実世界の問題を最適に解決することです現実世界の制約内。ほとんどのエンジニアはフェラーリで作業することを好みますが、ステーションワゴンは同じくらい多くのエンジニアリングを必要とします。ステーションワゴンが同様に機能しない理由は、エンジニアリングの悪化ではなく、設計の制約がより難しいためです。 。
「迅速な仕事」ではなく「良い仕事」をしたいと言うとき、ほとんどのエンジニアはそうしますが、良いことを定義するものの一部は、それが完了するまでの速さである場合があります。したがって、「良い」と「速い」を反対の選択と考えるのは正しくありません。または、あなたが悪い仕事をしている、または単に「コードモンキー」であると考えるために、利用可能な時間内で可能な限り最高の仕事をしている。
もちろん、プロセスが最適ではない可能性は十分にあり、設計を少し前もって行うことで、より良い結果が得られます。酸のテストは、それが解決するよりも多くの問題を作成する現在の方法ですかユーザー向け、またはそれはその方法で作業する必要のある開発者を悩ませているだけですか？それが実際にユーザーに問題を引き起こしている場合、あなたの仕事の一部は、これが事実であることを実証しようとすることと、もう少し制御されたプロセスに人々を勝ち取ることを試みることです。
実際、これは私を悩ませます。あなたは専門家で、研究者向けのツールを開発しています。ただし、これらのプログラムをすばやく作成し、最小限の動作をするように指示されます。サプライズサプライズ。これは、実際のプログラマーに見返りを渡すという、研究者の典型的なプログラミング手法です。
ここでの主な懸念は、特にテストの欠如は、ツールに重要な目的がある場合、倫理的に疑わしい場合があるということです。最小限のテスト時間に制限されているためにソフトウェアに欠陥があるかどうかわからない場合、これは、ソフトウェアの動作状態に責任を負う責任を負わないことを意味し、アトラスは肩をすくめます。
少し立ち止まって、これについて少し考えてみましょう。どのようなツールを開発していますか？データをモデル化するソフトウェアを開発している場合、ここに大きな倫理的ジレンマがあります。いくつかの状況では、科学的研究が大規模に多くの人々に影響を与える決定につながる。
とりあえず、人為的な気候変動という物議を醸しているトピックについて考えてみましょう。たとえば、彼らが今日持っている結論に至るために使用しているのと同じ標準をモデリングソフトウェアに適用したとします。このトピックは、私たちが環境を適切に管理する方法と国際政策に大きな影響を与えます。
モデリングソフトウェアの予測に大きな問題がないことを確認することは倫理的ではありませんか？
全体の問題は、温室効果ガスが地球を暖めるということではありません。問題は、フィードバック効果の正味の結果が温度の加速ゲインであるかどうかであり、これはしきい値を超えた後は元に戻せなくなります。
上記のゲインが発生している場合、最終結果の証拠はわずかであり、おそらくerrの範囲内です。
そのため、わずかな誤算や、バックエンドでのデータの保存と取得を含む方法論でも、障害の一端で深刻な環境問題を無視したり、多くの人々に影響を与える国際的な政策（仕事を破壊したり、年金を破壊したりするなど）を引き起こす可能性があります。 ） もう一方の。
だから、はい、あなたは正しいです。研究のペースが気になりません...研究者がソフトウェアツールに依存してデータを管理し、データの計算を実行したい場合は、ソフトウェアが正しく実行されるのを待つ必要があります。さもなければ、このソフトウェアは彼らが責任を負わされていない彼らの理論の脆弱点になり、倫理的な不正行為をもたらします。
ソフトウェアエンジニアリングとは何かについて、間違った考えはありません。ただし、これには非常に重要な側面がありません。これはサービス業界です。私たちの何人かは、何年もの間製品に取り組み、v1になる前に設計を繰り返し、それから多くの反復作業を行います。他のものは3時間で何かを生産しなければなりません。それはあなたがサービスしている人とその目的が何であるかに依存します。
3時間（または数日）で、本来の機能を果たすアプリケーションを作成できる場合、事前に設計するためにより多くの時間を費やす必要があるのはなぜですか。あなたはただお金を無駄にしています。お金を浪費することは一般的には良いアイデアではありません。
他の人がすでに述べたように、ソフトウェアエンジニアリングについての大部分は「外部制約」です。例えば。時間、予算、サービス、サポート、非合理的なばかげた要求を満たすなど。
多くの人（私も含めて）は、プログラミング自体に問題があると考えてプログラミングを始めました。ソフトウェアの美しくエレガントな部分を真空（または少なくとも相対真空）でコーディングします。めったにありません。それに近づくいくつかの珍しい学術的またはR＆Dソフトウェアジョブがあるかもしれませんが、ほとんどの部分で、ソフトウェア開発作業の圧倒的大多数はそのようなものではありません。特に、メンテナンス段階（通常、製品の寿命の90％以上）と、ほとんどの永続的な商用ソフトウェア作業の日常的な作業です。
長い間、私はこれについて内部の葛藤があり、しばしば自分の仕事に不満を感じていました（そしてそれは、最終的には昨年の燃え尽き症候群につながるものの一部です）。美しいコードを作成し、適切にそれを行うために時間をかけることがすべてではないではない場合、仕事は面倒だといつも感じていました。しかし、実際には、これが現実です。実際にサービス指向のワークフローで成功する人もいます。それが実用的で便利だと感じさせるものです。プロジェクトの実際の「純粋なソフトウェアエンジニアリング」の側面が比較的急ぎ、ずさんになったとしても。
とにかく、あなたが今これについて質問しているのは良いことです。これは、彼らが学校で実際に正しく説明することが決してできないことの1つです。また、企業は、従わないとしても、非常に優れたエンジニアリング手法に従うふりをするのが大好きです。ヒント：ほとんどはそうではありません。
とはいえ、状況はさまざまです。特定の企業（主にソフトウェアがコアビジネスである企業や、医療機器などの安全性が非常に重要なソフトウェアに取り組む企業）は、非常に厳密なエンジニアリングプロセスに従っています。しかし、全体として、はい、ほとんどの商用ソフトウェアの作業は比較的だらしがないので、空欄にしましょう。通常、いくつかの正式なプロセスがありますが、それを厳守することは、ほとんどの場合、クライアントの入力やその他の商業的な圧力に反応するために、ほとんど常に後退します。それ自体は実際には「だらしのない」ものではなく、単なる実用的な実用性です。コツは、ニッチを見つけ、「純粋なプログラミング」の側面がどれほどクールであるかではなく、提供するサービスの観点から役割を検討することです。
[〜＃〜] edit [〜＃〜]：最初の評価では、一方的に聞こえすぎたかもしれません。私はそれを頻繁に追加したいと思いますare物事の真の問題tooずさんな、そして良いプロセスの欠如-それがプロジェクトを技術的負債に追い込み、実際にはビジネスに悪いところまで。しかし、これを見るには経験が伴います。最初のポイントは基本的にはまだ残っています。今日のほとんどの商用ソフトウェア作業は、純粋主義者が望むほど厳密なエンジニアリング指向ではありません。
なんて素晴らしい質問でしょう！ fastになることで、何か価値のあるものになることがあります。これは通常、私たちが知らないことをより早く学ぶことができれば、それだけ私たちがよりよくなる研究室でのケースです。あなたが作成するソフトウェアは、質問に答えるためだけに存在します。 「捨てるコード」です。これは、顧客が本当に何を望んでいるかを知らない新興企業にも当てはまります。また、初めて何かを作ったときは、くだらないことになります。 The Mythical Man-Month をお読みください。
goodになることで、何か価値のあるものになることがあります。これは通常、Adobe Photoshopなどのシュリンクラップされたソフトウェアに当てはまります。調査はすでに何年も前に行われており、今問題は、バグを導入しない方法で顧客が望む機能のリストをどのように追加するかです。それはアーキテクチャ、設計、テスト、テスト、テストの問題です。コード自体は貴重なものであり、そこから学んだことではありません。
研究に満足していない場合（最初の何かを作る、誰も知らなかった新しいことを学ぶなど）は、シュリンクラップソフトウェアを試してみてください。実際、あなたの年齢では、できるだけ多くのことを試すべきです。リスクを取ってください！あなたはたくさん学ぶでしょう、そしてあなたは長い目で見ればより良くなるでしょう。
これは私の経験に基づく私のアドバイスです。私は20歳で、現在英国の主要な金融機関で働いています。あなたが数か月前と同じ気持ちを持っていましたが、これはおそらく、あなたがしている仕事.
つまり、あなたが言ったことは、
「私がしなければならないのは、テクノロジーの組み合わせを使用していくつかの内部ツールを作成することです-主にAWS/Java/Bash」
また、特定のプロセスを管理および自動化するのに役立つ内部ツールを作成する必要がありました。実際、ペースの速い環境では、「小さな」ものを迅速に実装する必要があります。 2年目に教えられたソフトウェアエンジニアリングまたはアルゴリズムとデータ構造の原則のほとんどを適用する贅沢はありませんでした。数週間でツールの実用バージョンが必要になったためです。これには非常に不満を感じていましたが、私がより読みやすいコードを書く方法を学んだので、すべてが悪いわけではありません。
私は我慢強くならなくてはならず、最近10K以上のユーザーが使用する社内構築システムの新しいイテレーションに取り組んでいる新しいチームに移り、ソフトウェアエンジニアリングの側面が非常に真剣に受け止められていることを保証できます。要件の取得/分析から実装およびテストまで、ソフトウェアのライフサイクル全体に触れることができると言われています。私は社内ツールではなく、大規模なユーザーベースのフルスケールシステムで作業しているので、この経験を積んでいくと思います。
私がお勧めするのは、あなたが忍耐強く、ツールの作成を終え、それで非常に良い仕事をすることです。これにより、上司はあなたにもっと信頼を得て、ソフトウェアエンジニアリングの原則の使用を必要とするより困難なタスクを割り当てます。いくつかの追加の読書を行うことで追加の知識を獲得し、その知識をあなたが現在行っていることに適用します。私が読んだすべての書籍から、知識をさらに深めるために会社の電子書籍ライブラリ全体を略奪したことを覚えていますJavaは、私を大いに助けてくれた本当に良い本でした。
ただ我慢して、あなた自身の知識に多額の投資をして、可能な限りその知識を適用してください。あなたが非常に良い仕事をしているなら、誰かがすぐに気づくでしょう。
キャリアのごく早い段階で、適切な設計や適切なテストを行わずに物事を迅速に行うと、戻ってくる傾向があることに気付いたと思います。あなたは明らかにこれが好きではなく、あなたがそうしないのには十分な理由があります。 「最初の解決策が正しくないか不完全なときに後で再検討する必要がある場合は特に」、「問題を突破する」と予想されるのはばかげています。問題を完全に理解して初めて、問題の解決策を提供できます。これには、時間と慎重な計画が必要です。
あなたへの私の提案は、これがあなたを悩ませていることを上司に知らせ、あなたの仕事をするためのより良いアプローチを彼らに提案することです。彼らが同意せず、あなたがあなたの仕事を通して「急いで」続けることを望んでいるなら、私は他の場所で仕事を探し始めます。業界が期待するソフトウェア開発品質の標準は言うまでもなく、独自の標準に達していない方法で物事を行う意味はありません。
あなたの現在の作品の運営方法は最適ではないことに同意します。ただし、まったく機能しないと言いたい場合は、さまざまな結果が出ており、機関もまだ残っているので、そうは思いません。
あなたへの私の主な質問は、医療患者に応急処置を施すのと同じように迅速な解決策を必要とする火災にどの程度対処しているのか、またはプロジェクトとして設定され、医療患者と同様に非常に異なるスケールで処理される可能性のあるリクエストです。すぐに実行する必要はないが、短期的にはテストやさまざまな手順をスケジュールする必要があります。
時間をかけてうまく仕事をするかどうかは、組織の成熟度と、何かが上手くいくためにどれだけ重要であるかということによって決まります。
データ構造の調査に関する問題は、これをどのくらいの期間実行したいかです。あなたが数時間を必要とするのとはかなり異なるデータ構造を研究するために10年を取りたい場合。最良の答えを得たいという欲求は高く評価できますが、問題にしばらく時間を費やした後、利益を減らすために言うべきことがあります。 FizzBuzz の解決策を見つけるのに何時間も費やすことができますか？さまざまなハードウェアでさまざまな言語で解決して、実行速度を最適化することができます。
研究することは重要ですが、何かを提供することも重要です。あなたが何かを提供しない場合、あなたは本当にどれくらい良いですか？ Duct Tape Programmer は、ここで物事を行う側のより多くの例になります。
スクラムは、現在の職場で採用しようとする可能性のある特定の方法です。スクラムが特効薬だとは思わないでください。 スクラムとアジャイルでのプロジェクトはどのような状況で失敗する可能性がありますか？ は、その主題に関するブログ記事になる可能性があります。
私の推測では、あなたはあなたの現在の場所のプロセスがいかに非公式であるかを見ていませんし、正式な方法論がある反対側の芝生は非常に緑になっていると思います。そこにいる方が良いかもしれませんが、 cowboy であるという大規模な自由により、今あるものを好む人もいます。
あなたの状況は、まだ品質面に重点を置いていない現実世界の規模にあると思います。あなたの好みは現実世界の反対側にあります。仕様が変わるので乗り越えてください。物事が完了する必要があります。
次の仕事に応募するときに、このようなタイプの会社を識別する方法を検討してください。開発者が設計を永久に分析できるビジネスモデルを備えている場所はほとんどありません（教授でさえ教える必要があります）。作品がドライイレースボードを離れない場合、クライアントはめったに支払いをしません。あなたがキャリアの早い段階で自分を狂わせるのを見るのが嫌いです。