私はまだ、ソフトウェア エンジニアが職場で働く準備をするのに十分な適切な CompSci コースを見つけていません。次のようなものを見つけた場合 [CompSci と呼べるかどうかは疑問ですが、まったく別の獣である Real-World Software Design に似ています]。
コンピューター サイエンスは、現実世界に影響を与える、より理論的な主題ですが、学術的な観点からはより有用です。たとえば、アルゴリズムの設計は、ソフトウェア エンジニアにとっては非常に役立ちますが、消費者にとっては直接的に役立つわけではありません。たとえば、クイックソート アルゴリズムの構築方法や、リンクされたリストのトラバーサルを理解することは、実際にはそれほど重要ではありません。今日のソフトウェア エンジニアリング環境で役立ちます。もちろん、理論を理解することは、仕事に適したツールを選択するのに役立ちます。誤解しないでください。開発者として、私たちの多くは開発ツールを発展させるためにコンピューター サイエンスの世界の成果に依存しています。彼らにとって意味のあるソフトウェアと、学術的な知性はバラバラになるでしょう。なぜなら、この 2 つは完全に異なる言語を話すからです。
ソフトウェア エンジニアにとってもっと有益なコースには、私が頭のてっぺんから思いつく次のコンポーネントをできるだけ多く (場合によってはそれ以上) 含めることです。
- プログラミング言語- 基本的なプログラム フロー、パラダイム、構文など。これはたいていかなりよく教えられているので、あまりこれに固執しません。いくつかの完全に異なるクラスのプログラミング言語を教えてもらえると助かりますが、たとえば、私は C、Pascal、VB 3 を学びました(正確なバージョンは覚えていません)。プログラマーが少なくとも 1 つの関数型言語、1 つの命令型言語、1 つの宣言型言語を学べば、はるかに役立つでしょう。
- デバッグ- nTier アプリケーション [多く/ほとんどの現実世界のアプリケーション] を作成する場合、必要に応じてプロトコル レベルに至るまで、どこで問題が発生しているかを把握できると便利です。これには、WireShark などの分析ツールが役立ちます。
- 通信デバイス- XML、XQuery、XPath、XSL、XSD [これらは広く使用されているようです]。
- リレーショナル データベースの設計- これはすでに十分に教えられています。
- リレーショナル データベースのパフォーマンス チューニング- テーブルを設計するだけでは十分ではなく、特定のフィールドにインデックスを付けるのが適切な場合とそうでない場合を知ることも重要であり、多くのコースではカバーされていないようです.
- データの正規化これも、多くの場合、適切に教えられているようです。ほとんどの学生は、教えられた理論を吐き出して現実の世界に出てくるように見えますが、「あなたは常にボイス-コッド正規形を使用しなければならない」など、それらの理論の意味を実際に考えることはありません。現実の世界では、ルールを破る非常に正当な理由がある場合があります。
- クエリの最適化- 基本的なクエリを記述することは、卒業生の快適ゾーンの外側の限界にあるように思われることがよくあります。最適化を教える必要があります。また、学生がアプリケーションのパフォーマンスの問題をデバッグできるように、クエリ プロファイラーなどのツールを教えるべきです。
- ストアド プロシージャ/トリガー- ストアド プロシージャまたはトリガーを記述したり、効果的に使用したりできる学生にまだ出会ったことがありません。選択/結合/ネストされた選択は、クエリの設計に関して教えられることの限界のようです。
- 基本的なアルゴリズム- これは私の経験では十分に教えられていますが、多くの学生は、「これこれのアルゴリズムを使用して、この問題を解決してください」と言われずに、どのアルゴリズムがどの状況に適用されるかを決定する方法を知らないようです。あなたが「この問題を解決してください」と言うことができれば、それは役に立ちます。彼らは、オーケー、この状況で役立つアルゴリズムの艦隊を持っています。x、y、または z のためにこれが最適です。ここでは、ソリューションを提供するために適用する方法を示します。
- 再帰- 再帰を教えることができるアプローチをまだ見つけていません。いつの日か、最も基本的なプログラマーでさえもこれを理解できるような、優れた比喩を見つけることができるでしょう。
- 抽象化- これは、OOP の中心的な原則の 1 つであるにもかかわらず、多くのコースで見過ごされているようです。
- コードのリファクタリング- リファクタリングを行うタイミングと、リファクタリングを行わないタイミングを知ることは、ほぼ同じくらい重要です。
- コードの再利用- 多くのコースが切り貼りサルを吐き出しているようです - これはコードの再利用が意味するものではありません!
- ソース管理- 私は 3 番目または 4 番目のプログラミングの仕事までソース管理について学びませんでした。コースの一環としてソース管理を学んだソフトウェア エンジニアを一人も知りません。
- バックアップと復元- これを教えるコースは聞いたことがありません。何人の初心者プログラマーが、バックアップすることを考えていなかったためにすべての作業を失ったでしょうか? 過去に持っていたことは知っていますが、最近ではありません。バックアップについて無知だったわけではありませんが、「私には決して起こらない」ということわざがあります。それはあなたに起こり、あなたが失ったばかりのものすべてをデモしなければならない直前になることを保証します!
- ファイル システムのメンテナンス- いくつかのコースではこれについて簡単に触れていますが、多くのコースではそうではありません。
- 質の高い設計仕様書の作成- これは常にコースワークの概要として提供されているように見えますが、学生が自分でこれを設計するように求められることはめったにありません。作業範囲を記述し、ドキュメント テンプレートを理解することは、ほとんどのソフトウェア コースの範囲をはるかに超えているようです。
- ユーザー ドキュメンテーション- ユーザーはあなたのように考えていません。「一目瞭然」または「馬鹿でも使えるほど簡単」なソフトウェアをユーザーに渡せば、あなたの顔は爆発します。「今日のプログラミングは、ソフトウェア エンジニアがより大きく、より優れたばかげたプログラムを作成しようと努力し、宇宙がより大きく、より優れたばか者を生み出そうとする競争です。これまでのところ、宇宙は勝利しています」という有名な言葉があります。8 歳児が従うことができるユーザー ドキュメントを作成します。それを作成するのは面倒に思えるかもしれませんが、一度作成すると、いつまでも自分自身に感謝することになります。
- テクニカル ドキュメンテーション- つまり、学生がサンドキャッスル、nDoc、またはその他のドキュメンテーション ツールを使用できると便利です。
- テスト計画- テストを可能にするテストとソフトウェアの設計。nUnit などは、ソフトウェア開発コースで教えるのに最適なツールです。実際、テストフレームワークを教えることは、何も教えないよりも良いでしょう...そうであるように思われます。
- FAT/SAT/UAT テスト- サニティ チェック、工場受け入れテスト、ユーザー受け入れテストなど、現実世界でのさまざまなテスト シナリオを理解しておくと役立ちます。ソフトウェアのサインオフは、開発と同じくらい重要です。クライアントが得ていると思っていたものを提供しなければ、あなたのソリューションが技術面でどれほど素晴らしいものであっても、報酬を得ることはできません。
- ソフトウェア アーキテクチャ- 実際の n 層アプリケーションのさまざまなコンポーネント、それらを使用する利点と欠点を理解します。
- ユーザーとの交流- これは実際にはコンピューター サイエンスではないかもしれませんが、自分とは波長が合わないことが多く、自分と同じように考えていない人と話す方法を学ぶことです。これはコミュニケーションにも関係しますが、実際には開発者が必要としているものです。知っておく必要があります。
- 常識- Ding, Ding, Ding, Ding - これをまったく知らないプログラマーはたくさんいます。コースは、自分で考えることができることを証明するように設計されています。多くの卒業生が、理由や意味を考えずに、教えられたルールを盲目的に適用するだけでよいと考えて、現実の世界に来る理由がわかりません. 前に言ったことを繰り返します。現実の世界では、ルールを破るのに十分な理由が見つかることがあります。私たちはそれらをやみくもに追いかけたり、やみくもに壊したりしません。ソフトウェア開発は芸術であり、すべての芸術と同様に、ルールを破ることができるときとできないとき、そして同様に重要なことに、ルールを破るべきときとすべきでないときを知る必要があります。卒業生として、あなたはルールを学び、それを証明しました。
- 聞く- 開発者が、実際にユーザーの話を聞いて実際のニーズを理解するのではなく、「顧客が何を望んでいるかを知っていると思った」ために書かれたコードを何度も目にすることに驚かれることでしょう。
- 理解- 聞くことと密接に関係しています。
- コミュニケーションスキル
- 技術的に無能な人、つまりユーザーベースの大部分と話す
- プロジェクト調停- 小切手を書いている人にあなたのアイデアを販売する
- 優先順位付け- どの機能が他の機能よりも重要であるかを決定する方法。
- 予算編成- 時間の見積もり
- 時間管理- 周りの人があなたの時間を邪魔し、締め切りを気にしないときに、時間通りに物事を終わらせる方法. 明日の終わりまでにまだ始めていないコースの仕事を持っているときに、すべての友達がパブに行ってパイントまたは10を望んでいるときと同じように.
- スコープ クリープ- いいえ、それは仕様/予算に含まれていません。
そして、コースでこれらすべてをなんとか習得できたとしても、まともな能力を持つソフトウェア開発コンサルタント会社での 3 ~ 4 か月のインターンシップで、コース全体よりも多くのことを学べると思います。学士号を取得してから最初の 6 か月で、3 年間のコース全体よりも多くのことを学びました。確かに、そのコースで学んだことの多くがなければ、私は顔を真っ白にしていたでしょうが、はるかに有用なコンテンツに置き換えることができた、不必要に教えられたことがたくさんありました.