学校でのプログラミングと業界でのプログラミングの違いは？[閉まっている]

多くの学生は、卒業して最初の仕事に就くと、たとえ大学で優秀なプログラマーだったとしても、実際にプログラミングの方法を知らないように感じます。

アカデミックな環境でのプログラミングと「現実の世界」でのプログラミングの違いは何ですか？

従来の学部のコンピューターサイエンスプログラムでは、プログラミングだけを学びます。しかし、現実の世界では、単なるプログラマーである人々は必要ありません。現実の世界では、実際のソフトウェアエンジニアが必要です。多くの職務記述書がこの区別を表していないようで、問題を混乱させるだけです。現実の世界では、次のことができる必要があります。

• 要件が直接与えられていない場合に要件を収集して分析する
• 無限の可能性を秘めたアーキテクチャの設計と分析
• テスト計画を作成し、それに基づいてシステムの品質を評価および改善します
• さまざまなバックグラウンドと経験レベルを持つ人々のチームで共同作業する
• 構築するものが正確にわからない場合でも、作業を見積もり、計画する
• 必ずしも一致しないさまざまなニーズを持つ利害関係者と効果的にコミュニケーションする
• 関係者を失望させることなく、スケジュール、予算、品質、機能を交渉する

そうそう、そしてあなたもコードを書くことができなければなりませんが、それは平均してソフトウェアエンジニアの時間のたった40-60％しかかかりません。

ですから、新たに作成されたコンピューターサイエンスの学部生がプログラミングの方法を知らないわけではありません（実際、多くの人が非常に優秀なプログラマーです）。それは彼らの多くが他に何かをする方法を知らないということです。

大学で...

先生が教えてくれます：

• 明確に定義された孤立した問題。その解決策は、短く明確に定義された期間内に提供できます（後で破棄されます）
• 割り当て前に紹介された、明確に定義されたツールのセット
• ソリューションの品質を明確に定義した尺度。ソリューションが十分かどうかを簡単に判断できます。

現実世界では"...

• 問題はぼやけており、複雑で、コンテキストに埋め込まれています。時間の経過とともに変化する一連の矛盾した要件であり、許容できる時間内にこれらの変更に対応できるように、ソリューションは柔軟で堅牢でなければなりません。
• ツールはあなたが選ぶ必要があります。チームの10年前のコードベースには既に何か使えるものがあるかもしれませんし、オープンソースプロジェクトや商用ライブラリがあるかもしれませんし、自分で作成する必要があるかもしれません。
• ソフトウェアの現在の反復が改善されているかどうかを判断するには（実際にソフトウェアプロジェクトをほとんど実行したことがないため）、回帰テストとユーザビリティテストを行う必要があります。後者は通常、ぼやけ、複雑、矛盾、コンテキストに埋め込まれた要件が再び変わります。

結論

学校でのプログラミングと現実の世界でのプログラミングは、実際にはほとんど重複しない点とは本質的に異なります。CSは、陸上競技のトレーニングが戦闘に向けて軍隊を準備するような「現実世界」のソフトウェア開発の準備をします。

彼らは問題の異なる側面に直面しています：

アカデミアは主に「プログラミングの科学」に焦点を当てているため、効率的な特定のアルゴリズムを作成する方法を研究したり、特定のパラダイムをより表現力豊かにする言語を開発したりしています。業界は主に、販売する必要のあるものの生産に焦点を当てています。言語とアルゴリズムだけでなく、ライブラリ、フレームワークなどでもある「ツール」に依存する必要があります。

この「フォーカス」の違いが、CのアカデミックマスターがWindowsアプリケーションを実際に作成できないようにしている（Windows APIがC99標準にないためです！）ため、「プログラミングできない」と感じています。しかし、実際には、彼は自分が何が欠けているかを自分自身で学習する能力をすべて持っています。適切な学術的研究（必ずしもアカデミアで行われたものではない）がなければ、それを見つけるのは非常に困難です。

良い答え。アカデミックプログラミングは、ほとんどおもちゃのような規模になる傾向があります。これは教育に適しています。教師として、あなたはアイデアを最も効率的に伝えようとしています。欠点は、現実的なプログラミングが質的に異なるため、ギャップを埋めることが難しいことです。

違いの1つの領域は、パフォーマンス分析です。これを指摘しようと、多くの投稿を書いています。パフォーマンス分析は、表面的にアルゴリズムと測定についてのみです。本当に効果的に行うには、デバッグのプロセスとしてアプローチする必要があります。

違いのもう1つの領域は、保守性です。これには、スタイルからドメイン固有の言語設計まですべてが含まれます。最小化しようとしているものが実際にわからない限り、効果的に行うことはできません。

これらのことは教えられておらず、生産性に大きな違いをもたらします。

学術の世界では、ほとんどの人がコンピューターサイエンスまたは関連するコースを勉強しています。ダイクストラはかつて、「コンピューター科学はコンピューターに関するものではなく、天文学は望遠鏡に関するものである」と述べました。コンピュータサイエンスを勉強している人は、何よりもまず、プログラマではなく科学者になることを学んでいます。プログラマーとして、彼はアマチュアのままであり、プロのプログラマーへの移行はそれに応じて困難です。

更新：誰かが私の心を読んでいるかのように：卒業予想と現実 ...

私の見解、他の2つの要因：

問題の規模：学界では、ほとんどの場合、「ゼロから」ソフトウェアを開発する必要がありました。つまり、ほとんどの場合、遭遇した最大のプログラムは私が書いた最大のプログラムでした。これは、互いに対話するソフトウェアのさまざまな部分から生じる複雑さを処理し、対処するために必要な機能を重視しません。複雑さを理解するために必要な努力を知っていたなら、私は業界に全くいないことを選んだかもしれません。

読み取りVS書き込み：問題の大きさのもう1つの副作用は、「実世界」では、メンテナンスの目的（どこでもアカデミアのメンテナンスを行っていない）、拡張、または単に、分業。したがって、コードを読むことは、書くことよりも何倍も重要になります。

プログラミング教育を改善するための提案：アカデミアは、職業訓練に回帰することなく、現実世界の状況により多くさらされるべきです。医師はある時点で死体に立ち向かわなければならないので、「自分のために作られた」かどうかを確認する必要があります（この経験後に人々がコースを落とすという話を聞きました）。20代前半に、異なるプログラミングスタイルで構成される20K LOCプロジェクトを見て、それを1日で理解し、3つのバグを修正しなければならなかった場合、おそらくそうではないにしても、他のキャリアオプションを検討したかもしれません。

アカデミックプログラミングと産業用プログラミングの最大の違いは、堅牢性に関するものです。ほとんどの人は自分のキャリアの中で「それは私のために働く」というパラドックスを経験しており、これはこの条件の延長です。学界では、アルゴリズムと機能に重点が置かれており、日常の条件下でのソフトウェアの使いやすさと安定性はほとんど考慮されていません。

たとえば、私のオフィスには、ソフトウェアを使用するエンジニアがいて、コーナーコンディションからクラッシュを引き起こすことをマスターしています。彼は何かがクラッシュするまでできるだけ早くボタンをクリックします...操作に時間がかかりすぎる場合は、画面上でランダムにクリックを開始します（フラストレーションからですか？IDK ....）

「Steve proof」を作成するようにプログラミング哲学を変更すると、一般にアプリケーションの安定性が向上しました。

学校でのプログラミングトレーニングの個人的な経験はありません。英語専攻でした。キーツとバイロンについて聞いてみてください！-しかし、私はいくつかの新しい卒業生を受け取り、それらを育て、プロのソフトウェア開発の世界で指導しました。だから私はその観点から話すことができます。

私の経験では、彼らが学校で得たものはすべてプログラミングに興味があったということです。彼らのスキルはゼロからごくわずかまで変化しました。彼らが自己指示する能力は、彼らの最も熟練した人でさえ存在しませんでした。彼らの考えは単なる小規模ではありませんでした。彼らは実際にミニチュアで考えました。数十行以上のコードで構成されるシステムは、それらを完全にバラバラにしました。

しかし、あなたは何を知っていますか？彼らは興味を持ちました、そしてそれは大したことです。興味はたくさんあります。興味のある人と仕事ができます。彼らが開発者であることに興味を持って来れば、それらを開発者に変えることができます。地獄、それが私が始めたすべてです。それとポストモダンなアメリカの小説家への感謝。

学界では、

ドローバック

• 主にポイントを獲得するための締め切りがあります。
• ほとんどのプロジェクトは実際のアプリケーションでは使用されないため、バグが実際に問題を引き起こすことはありません。

プラス

• 研究のための十分な時間が得られます。
• 最初の目標から揺らぐことは、多くのトラブルを引き起こしません。

業界では、

• 実際に企業が使用するプロジェクトに取り組んでいます。
• 私たちは、常に変化するクライアント要件のストレスの下で働いています。
• ソフトウェア会社とクライアントの両方に多大な金銭的損失をもたらす可能性があるため、締め切りはめったに柔軟ではありません。

これをチェックしてください：

http://www.dodgycoder.net/2011/10/how-to-become-better-programmer.html

アカデミックプログラミングは、自分でコーディングすることです。これは、それがどのように機能するかを学ぶ上で重要です。コードの品質とリビジョン管理はそれほど重要ではありません。注目すべき例外を除き、コードには割り当てを超えた有効期間はありません。プロジェクトの範囲は非常に制約される傾向があり、忍び寄ることはほとんどありません。

現実の世界では、元のコードはできるだけ少なくする必要があります。多くのコードがチームによって開発されています。自分でコーディングするよりも、ライブラリルーチンを使用する方が適切です。コードの品質と改訂管理がより重要になります。コードは、元々予想されていたよりもはるかに長い寿命を持つ傾向があります。通常、プロジェクトの範囲は非常に広く、管理されない場合は大きく変化する傾向があります。

実際、

アカデミックレベルのプログラミングと実際のプログラミングを完全に区別することは不可能です。

最大の違いはこれかもしれません。実世界のプログラミングでは、プログラミング以上の知識が必要であり、迅速に適応できるはずです。

仕事をしているセクターに応じて、その法律を順守する必要があります。

マイケルは、プログラミング関連のタスクを述べることによって氷山の一角に触れただけで、それを簡単なものとして分類します（もしあなたが払っている生地に値するなら）。

一般に、業界の主題ごとに少なくとも2つの課題に直面します。

• 準拠法（例：医療に対するクライアントの機密保持）
• 主題のノウハウ（例：請求書発行税システム、在庫、リソース管理、医療スキーム、業界標準）
• 業界標準/準拠法に欠けている、存在しない、または異なるクライアント要件

研究のphdレベルのプログラミングプロジェクトと実際のプロジェクトを比較すると、難易度、入門レベルのノウハウなどが非常に似ている可能性があります。

唯一の本当の違いは、実世界のプロジェクト

• クライアントがいます
• 予算（時間、お金、人的資源）がある

他の誰かがルールを作成するときは、別のボールゲームです:)

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コースしか取得できない場合があります）。

そのような技術の積み重ねが数多くあり、変化し続けるため、機関を完全に非難することはできません。

マイクロソフトの上記のほとんどは、Javaでアプリケーションを開発したい人には役立ちません。

本当の問題は、今日のビジネスに必要な技術スタックのどれもが完全に網羅されていないことです。

上記は、ビジネス環境でのプログラミングのようなビジネスの仕事に対する卒業生の適合性の問題をカバーしています。研究室などのニーズは、この回答ではカバーされていません。また、ゲーム開発、組み込み開発、リアルタイムシステム開発など、他の分野では上記よりも多くのスキルが必要です。

規模と焦点
私の経験から、アカデミックな環境では、通常、作業中のアプリケーションの規模ははるかに小さく、1日または1週間で、またはおそらく1つか2人のプロガマーによって学期までに完了することができます。 -通常、作成するすべてのコードは、用語の後に破棄される使い捨てのコードになります。現実の世界では、大規模なチームが完全に開発するのに数年ではないとしても数か月かかったアプリケーションで作業していることに気付くかもしれません。もっと多くの時間を費やし、他の人のコードをデバッグし、コードベースのインフラストラクチャを理解しようとして、既存のパーツを壊さずに新規または変更された要件を追加します。

要件、統合、顧客
また、要件分析、統合テストなど、アカデミックプロジェクトではあまり表現されない傾向があるコード開発の側面もあります。公正なグレーディングのために、通常、要件はインストラクターによってすでに設定されており、会議で共同で決定されることはありません。顧客が望んでいたものとは異なる特定のアプローチで「顧客を売る」必要はありませんが、彼らの欲求とは異なり、技術的な観点からは実際に実行可能です。アカデミックな環境では、顧客（グレーダーまたはインストラクター）は自分が望むものをかなり具体的なアイデアを持つ傾向があります。構築する必要があります。

メンテナンスとメンテナンス性

（少なくとも学部レベルの）学界では、ソフトウェアは短期宿題を念頭に置いて構築され、通常は宿題や学期プロジェクトを完了します。割り当てが完了すると、コードは破棄され、再び表示されることはありません。

プロの設定では、ほとんどのソフトウェアは長期使用を念頭に置いて書かれています。ソフトウェアは少なくとも数年間使用することを目的としており、長期にわたって容易に保守および更新できるように構築する必要があります。

これに関連するのは、メンテナンス作業です。プロのプログラミング作業の大部分は、既存のソフトウェアの更新または保守を伴います。いわゆる「グリーンフィールド」プロジェクトは、通常ではなく例外です。