学校でのプログラミングと業界でのプログラミングの違いは何ですか？
卒業して初めて就職する学生の多くは、大学の優秀なプログラマーであったとしても、プログラミングの方法を本当に知らないように感じます。
アカデミックな設定でのプログラミングと「現実世界」でのプログラミングの違いは何ですか？
伝統的な学部のコンピュータサイエンスプログラムでは、ちょうどプログラミングを学びます。しかし、現実の世界ではjustプログラマーである人々を望んでいません。現実の世界では、実際のソフトウェアエンジニアが必要です。私は多くの職務記述がこの区別を表現していないように見えることを知っています、それは問題を混乱させるだけです。現実の世界では、次のことができる必要があります。
- 要件を収集して分析要件が直接指定されていない場合
- アーキテクチャの設計と分析ほぼ無限の可能性あり
- テスト計画を作成し、それに基づいて行動するシステムの品質を評価および改善するため
- チームで共同作業する異なる背景と経験レベルを持つ人々の
- 作業の見積もりと計画何を構築するかが正確にわからない場合でも
- 利害関係者と効果的にコミュニケーションする必ずしも一致しないさまざまなニーズがある
- スケジュール、予算、品質、機能について交渉する失望する関係者なしで
ええ、そしてあなたもコードを書くことができる必要がありますが、平均するとソフトウェアエンジニアの時間の40〜60％しかかかりません。
したがって、新しく生まれたばかりのコンピューターサイエンスの学部生がプログラミングの方法を知らないというわけではありません（多くの人が実際、非常に優れたプログラマーです）。彼らの多くは他に何をすべきかを知らないということです。
大学で...
あなたの先生はあなたに与えます：
- 明確で孤立した問題。その解決策は、短く明確な期間内に提供できます（その後、破棄されます）
- 割り当ての前に紹介された明確に定義されたツールのセット
- ソリューションの品質について明確に定義された尺度。これにより、ソリューションが十分に優れているかどうかを簡単に判断できます。
現実世界では"...
- 問題はぼやけていて複雑であり、状況に組み込まれています。これは、時間とともに変化する一連の矛盾する要件であり、ソリューションは、許容可能な時間内にそれらの変化に対応するために十分に柔軟で堅牢でなければなりません。
- ツールはあなたが選ぶ必要があります。たぶん、チームの10年前のコードベースで使用できるものがあるかもしれません。オープンソースプロジェクトがあるかもしれませんし、商用ライブラリがあるかもしれません。
- ソフトウェアの現在の反復が改善されているかどうかを判断するには（実際にはソフトウェアプロジェクトではdoneになることはほとんどないため）、回帰テストとユーザビリティテストを行う必要があります。ぼやけた、複雑な、矛盾した、コンテキストに埋め込まれた要件が再びシフトします。
結論
学校でのプログラミングと現実の世界でのプログラミングは、実際にはほとんど重複がない点とは本質的に異なります。 CSは、陸上競技のトレーニングで軍が戦闘に備えるように、「実際の」ソフトウェア開発の準備をします。
彼らは問題の別の側面に直面しています：
アカデミアは主に「プログラミングの科学」に焦点を当てているため、効率的な特定のアルゴリズムを作成する方法や、特定のパラダイムをより表現力豊かにするように調整された言語を開発する方法を研究しています。業界は主に、販売する必要のあるものの生産に焦点を当てています。言語やアルゴリズムだけでなく、ライブラリやフレームワークなどの「ツール」に依存する必要があります。
この「フォーカス」の違いにより、CのアカデミックマスターはWindowsアプリケーションを実際に作成できなくなります（Windows APIはC99標準にないため）。したがって、「プログラムできない」と感じます。しかし、実際には、彼は自分が欠けているものを知るためのすべての能力を持っています。適切な学術的研究なしでは（必ずしもアカデミアで行われる必要はありません）、何かを見つけるのは非常に困難です。
良い答え。付け加えておきますが、アカデミックプログラミングは規模がほとんどおもちゃのようなものになる傾向があります。これは教えるのに適しています。あなたは教師として、アイデアを最も効率的に伝えようとしています。欠点は、現実的なプログラミングが質的に異なるため、ギャップを埋めるのが難しいことです。
違いの1つは、パフォーマンス分析です。私はこれを指摘しようとする多くの投稿を書きました。パフォーマンス分析は、表面的にはアルゴリズムと測定についてのみです。それを本当に効果的に行うには、デバッグのプロセスとしてそれに取り組む必要があります。
もう1つの違いは、保守性です。これには、スタイルからドメイン固有の言語設計まですべてが含まれます。何を最小化しようとしているのか実際に知らない限り、効果的に実行することはできません。
これらのことは教えられておらず、生産性に大きな違いをもたらします。
更新：誰かが私の心を読んでいるかのように： 大学院の期待と現実 ...
私の見解、他の2つの要因：
問題のサイズ：学界では、ほとんどの場合「ゼロから」ソフトウェアを開発する必要があり、ほとんどの場合、私が遭遇した最大のプログラムは私が書いた最大のもの。これにより、相互に作用するソフトウェアのさまざまな部分から生じる複雑さを処理して対処するために必要な機能が重視されなくなります。複雑さを理解するために必要な努力を知っていれば、業界にまったく参加しないことを選択したかもしれません。
Reading VS Writing：問題サイズのもう1つの副作用は、「現実の世界」では、他の人が書いた作品にさらされることが多いことです。メンテナンス目的（私はどこの学界でもメンテナンスをしなかった）、延長、または単に労働の分割のいずれかのために。したがって、コードを読み取ることは、コードを書くことよりも何倍も重要になります。
改善されたプログラミング教育の提案：アカデミアは、後退することなく、現実世界の状況により多くをさらすべきです職業訓練。医者は、彼らが「それのために作られた」かどうかを確認するために、ある時点で死体に直面しなければなりません（この経験の後に人々がコースを落としたという話を聞いたことがあります）。 20代前半に、さまざまなプログラミングスタイルで構成された20K LOCプロジェクトを1日で理解し、3つにバグを修正しなければならなかった場合、他のキャリアオプションを検討したかもしれませんが、おそらくそうではありません。
学問の世界では、ほとんどの人がコンピュータサイエンスまたは関連するコースを勉強しています。ダイクストラはかつて「天文学は望遠鏡のことよりもコンピュータ科学はコンピュータのことである」ことに気付きました。コンピュータサイエンスを学ぶ人は、何よりもまず、科学者になるための学習であり、プログラマではありません。彼はプログラマーとしてアマチュアであり続けるので、プロのプログラマーへの移行はそれに応じて困難です。
アカデミックプログラミングとインダストリアルプログラミングの最大の違いは、堅牢性に関するものです。ほとんどの人は、自分のキャリアの中で「それは私のために働く」というパラドックスを経験しており、これはこの状態の延長です。アカデミアでは、アルゴリズムと機能に重点が置かれ、日常的な条件下でのソフトウェアの使いやすさと安定性はほとんど考慮されていません。
たとえば、私のオフィスには、ソフトウェアを担当するエンジニアがいて、コーナー条件からのクラッシュを引き起こすことに精通しています。何かがクラッシュするまで、できるだけ早くボタンをクリックします。操作に時間がかかりすぎる場合は、画面の周りをランダムにクリックし始めます（欲求不満ですか？IDK ...）。
プログラミングの哲学を変更して、「スティーブプルーフ」にすることで、一般にアプリケーションの安定性が向上しました。
学校でのプログラミングトレーニングの個人的な経験はありません。私は英語を専攻していました。キーツとバイロンについて質問してください！-しかし、私はいくつかの新しい卒業生を受け取り、それらを育てて、専門的なソフトウェア開発の世界で指導しました。だから私はその観点から話すことができます。
私の経験では、彼らが学校から得たものはすべてプログラミングへの関心でした。彼らのスキルはゼロからごくわずかまでさまざまでした。自主管理する彼らの能力は、彼らの最も熟練した人でさえ存在しませんでした。彼らの考えは小規模なだけではありませんでした。彼らは実際にミニチュアで考えました。数十行以上のコードで構成されるシステムでは、完全にばらばらになりました。
しかし、あなたは何を知っていますか？彼らはinterestを取得しましたが、それは大きな問題です。興味はたっぷりです。 仕事興味のある人と一緒にできます。私はそれらを変換する開発者であることができます。地獄、それだけです[〜＃〜] i [〜＃〜]で始まります。それとポストモダンのアメリカ人小説家への感謝。
学界では
ドローバック
- 主にポイントを獲得するための締め切りがあります。
- ほとんどのプロジェクトは実際のアプリケーションでは使用されないため、バグが原因で問題が発生することはありません。
PLUSes
- 研究には十分な時間があります。
- 当初の目的から外れても、それほど問題にはなりません。
業界では、
- 実際に企業が利用するプロジェクトに取り組んでいます。
- 私たちは、絶えず変化するクライアント要件のストレスの下で働いています。
- 締め切りはまれに柔軟であり、ソフトウェア会社とクライアントの両方に多大な経済的損失をもたらす可能性があります。
これをチェックしてください：
http://www.dodgycoder.net/2011/10/how-to-become-better-programmer.html
アカデミックプログラミングとは、自分でコード化することです。これは、それがどのように機能するかを学ぶ上で重要です。コードの品質とリビジョン管理はそれほど重要ではありません。注目すべき例外を除いて、コードには割り当てを超えた存続期間はありません。プロジェクトの範囲はかなり制約されており、忍び寄る可能性は低いです。
現実の世界では、オリジナルのコードはできるだけ少なくする必要があります。多くのコードがチームによって開発されています。自分でコーディングするよりも、ライブラリルーチンを使用する方が適切です。コードの品質とリビジョン管理がより重要になります。コードは本来期待されていたものをはるかに超える寿命を持つ傾向があります。通常、プロジェクトの範囲は非常に広く、管理されていないと大幅に拡大する傾向があります。
実は
学問レベルのプログラミングと実際のプログラミングを完全に区別することは不可能です。
最大の違いはこれだろうと私は思います。実際のプログラミングでは、プログラミング以上のことを知る必要があり、すばやく適応できる必要があります。
あなたが仕事をしているセクターに応じて、あなたはその法律を遵守しなければなりません。
マイケルはプログラミング関連のタスクを説明することで氷山の一角に触れただけで、それは私が簡単なものとして分類します（あなたが生地に価値があるなら、あなたはあなたが支払われています）。
一般に、業界では主題ごとに少なくともいくつかの課題に直面します。
- 準拠法（例：医療に関するクライアントの機密保持）
- 対象のノウハウ（請求書発行税システム、在庫、リソース管理、医療計画、業界標準など）
- 不足している、存在しない、または業界標準/準拠法とは異なるクライアント要件
研究のphdレベルのプログラミングプロジェクトと実際のプロジェクトを比較すると、難易度、入門レベルのノウハウなどが非常に似ている可能性があります。
唯一の本当の違いは、実際のプロジェクト
- クライアントを持っています
- 予算がある（時間、お金、人的資源）
他の誰かがルールを作ったときのそれは異なるボールゲームです:)
スケールとフォーカス
私の経験から、学術的な設定では、一般的に、あなたが取り組んでいるアプリケーションの規模ははるかに小さく、1日または1週間、または学期の1〜2週間で完了することができます。プログラマー-通常、あなたが書くすべてのものは使い捨てのコードであり、その用語の後に破棄されます。現実の世界では、大規模なチームが完全に開発するのに数年ではないにしても数か月かかったアプリケーションに取り組んでいる場合があります。多くの時間を費やして他の人のコードをデバッグし、コードベースの情報構造を理解しようとし、既存のパーツを壊さずに新しい要件や変更された要件を追加します。
要件、統合、顧客
また、要件分析、統合テストなど、コードの開発には、学術プロジェクトではあまり表現されない傾向がある側面があります。公平な採点のために、通常、要件はインストラクターによって既に設定されており、会議で共同で決定されることはありません。あなたは彼らが望んでいたものではない特定のアプローチで「顧客を売る」必要がある傾向はありませんが、彼らの欲求とは異なり実際には技術的な観点から実現可能です。アカデミックな設定では、顧客（グレーダーまたはインストラクター）は、自分が何を望んでいるかについてかなり具体的なアイデアを持っている傾向があります。現実の世界では、自分が何を求めているのか本当にわからず、何を理解するために頭を選ばなければならない顧客に遭遇するかもしれません。構築する必要があります。
メンテナンスとメンテナンス性
学界（少なくとも学部レベル）では、ソフトウェアは短期的な目標を念頭に置いて構築されており、通常は宿題や学期のプロジェクトを完了するために使用されます。割り当てが完了すると、コードは破棄され、再び表示されることはありません。
専門的な設定では、ほとんどのソフトウェアは長期間の使用を念頭に置いて作成されています。ソフトウェアは少なくとも数年間使用することを目的としており、長期間にわたって簡単に保守および更新できるように構築する必要があります。
これに関連してメンテナンスの仕事です。専門的なプログラミング作業の大部分は、既存のソフトウェアの更新または保守を伴います。いわゆる「グリーンフィールド」プロジェクトは、標準ではなく例外です。
アカデミアのITで学習した科目を見ると、数学、科学、選択科目などに費やされた時間の約半分と、コンパイラーの設計、アルゴリズムの理論、コンピューターアーキテクチャ、最適化、オペレーティングシステム、デジタルエレクトロニクス、およびCプログラミングやWebプログラミングなどの業界に関連する他のいくつかのコース。
上記の主題のほとんどは、知っておくとよいものですが、日常のITで必要とされるものについて強力な背景を直接提供することもありません。
Microsoft Webプログラミングの要件（つまり、組織の生産的なチームメンバーになるために誰かが必要とする領域）を取り上げます。
1- C＃.NETまたはVB.NET
2- ASP.NET
3- HTMLとCSS
4- SQL Server（または別のデータベース）
5- OOアプリケーションのプログラミングと設計
6- Javaスクリプト
7- MVCフレームワーク
8-ソース管理ツールへのいくつかの暴露
9-自動テストツールへのある程度の露出
10バグ追跡ツール
11-Eコマースの概念（オプション）
12-ORM
13-一部のビジネス分析スキル
14-コミュニケーション能力
15おそらく、いくつかのクラウドコンピューティングの基礎
ご覧のように、大学/大学では、上記の要件のほとんどがほとんど集中されていません（多くても1つのコースしか取得できない場合があります）。
そのようなテクノロジーのスタックが数多くあり、それらは変化し続けているため、機関を完全に非難することはできません。
上記のMicrosoftのほとんどは、Javaでアプリケーションを開発したい人を助けにはなりません。
本当の問題は、今日のビジネスに必要なテクノロジースタックの1つが完全にカバーされていないことです。
上記は、ビジネス環境でのプログラミングのようなビジネスジョブへの卒業生の適合性の問題をカバーしています。研究室などのニーズはこの回答ではカバーされていません。また、ゲーム開発、組み込み開発、リアルタイムシステム開発など、上記以外のスキルも必要です。