独学でコーディングの練習を続けるべきですか、それともプロとしてコーディングする方法を学ぶべきですか？[閉まっている]

最近、私はプロの仕事を得て、他のプログラマーと付き合い、業界で友達を作りました。唯一のことは、私は100％独学です。それは、私のスタイルが適切に訓練されたスタイルから大きく逸脱する原因になりました。異なるのは、私のコードのテクニックと構成です。

それは私がするいくつかのことの混合物です。私はいくつかのプログラミングパラダイムをブレンドする傾向があります。機能的およびオブジェクト指向のように。私はオブジェクト指向よりも機能的な側面に傾いていますが、抽象的なエンティティとして何かがより理にかなっている場合にオブジェクト指向の使用を見ます。ゲームオブジェクトのような。次に、私は何かをするときも簡単なルートに行きます。対照的に、プロのプログラマーから見たコードは、そのために複雑な場合があるようです！私は多くのクロージャーを使用しています。そして最後に、私は最高のコメント者ではありません。コメントを読むよりコードを読むだけの方が簡単だと思います。そしてほとんどの場合、コメントがあったとしてもコードを読んでしまいます。加えて、コードを簡単に書くことができるため、非常に読みやすいと言われました。

専門的な訓練を受けたプログラマーが単体テストのようなことを続けていると聞きます。私が今まで使用したことがないものなので、それらが何であるか、またはどのように機能するかについての微妙な考えすらありません。たくさんのアンダースコア「_」は、本当に私の好みではありません。私が使用する技術のほとんどは、私から直接のもの、または私が読んだ数冊の本です。MVCについては何も知りません。backbone.jsのようなものについてはよく耳にします。アプリケーションを整理する方法だと思います。ただ私を混乱させているのは、今では自分の組織構造を作ったからです。

それは少し苦痛です。UbuntuのQuicklyのような新しいことを学ぶときは、テンプレートアプリケーションをまったく使用できません。訓練を受けた人からだとわかるコードを理解するのに苦労しています。完全なオブジェクト指向プログラミングは本当に私の口に悪い味を残しますが、それは他の誰もが厳密に使用しているもののようです。

自分のコードの見栄えに自信がなかったり、入社時に火花を散らしたり、オープンソースプロジェクトに貢献したりするのではないかと思いました。実際、私は人々が最終的に私のコードをチェックアウトするという事実をかなり恐れています。これはプログラマーが経験する普通のことなのでしょうか、それとも本当に自分のテクニックを変えるべきなのでしょうか？

実際、私は人々が最終的に私のコードをチェックアウトするという事実をかなり恐れています。

良い。人々があなたのコードを見ることを意識することは、あなたがより一生懸命努力するようになります。

プログラミングは非常に大きな分野になりました。多数のトピック、ツール、ニッチ、専門分野があり、そのうちのいくつかはそれ自体のキャリアです。学ぶことと知ることは膨大であり、他のプログラマーと一緒に仕事をするときは、常に彼らが知らないものとそうでないことを知っているものがあります。これは良いことです。

あなたの経験が不完全であると心配している場合、正式な教育と訓練された専門家との協力を通してそれを修正するために取ることができる多くのステップがあります。しかし、定量化可能なマイルストーンがあり、人々が「わかりました。今、私はそれをマスターしたので、私は正式にプログラマーです」と言うのを恐れているようです。そのようなマイルストーンはありません。何か新しいことを学んだ後、「ええ、今はどこかに着いている」と思った瞬間は間違いなくありましたが、プログラマーと呼ばれるために知っておくべきことの魔法のリストはありません。

私はプログラミングについて多くのことを知っています。多くのプロジェクトで多くの言語を使用しましたが、自分のプログラミングの知識のサブセットはごくわずかです。そして、私はそれが好きです。率直に言って、プログラマはあなたのものではありません。プログラマは、あなたが常に学び続けるものです。

あなたのスキル、長所と短所を正直に評価してください。あなたよりも経験のある人からフィードバックを得てください。あなたがいると思う場所とかなりうまく並んでいるポジションを探してください-しかし、あなたの現在のマスタリーから少し離れた仕事に行くことを恐れないでください。すでにすべてのことを知っている仕事に就くだけなら、職場で学ぶことは決してないでしょう。

他の開発者と協力してアプリケーションの開発を開始すると、これらの個人スタイルの脆弱性のいくつかが邪魔になります。

アンダースコアを使用するショップで働き始めたら、アンダースコアを使用します。以前の経歴に関係なく、誰もがコーディングスタイルのショップ標準に従います。

コーディングスタイルが非常に明白でない限り、他の開発者がそれに従うことができるように、コードがどのように機能するかを説明する明確で簡潔なコメントを書くことに慣れる必要があります。

単体テストについて何も知らない場合は、良い本を購入してください。ユニットテストに関する優れた書籍がたくさんあります。MVCと同じです。

プロのソフトウェア開発者は、サンドボックスを散らかすことなく、他の人とうまく遊ぶ方法を知っています。最も優れたものは、スタイルに関係なくコードを読み書きする方法を知っています。

プログラミングにはアートコンポーネントと規律コンポーネントがあります。アートの要素は、最良のアプローチを考えて実装することです。規律は、あなたが正しくそれをしたこと、そして他の人があなたのコードを理解し、必要なときにそれを強化することを確実にすることです。

アートコンポーネントは楽しいです。楽しむためにそれを行います。当然、それはあなたが最初に自分自身を教える部分です。

規律の要素は厄介なものです。あなたは不必要にそれをします。しかし、それはチームで働くための重要な要素です。少なくともある程度は、それをやめることはできません。コードがチームメイトのコードと統合されると、「自由に変更する」柔軟性が急降下します。それでも、要件の変化に応じて自信を持ってコードを変更したり、バグに対処したりする能力が必要です。これは、さまざまな「退屈な」テストの出番です。多くのテストが実施されているので、最新の変更が問題を引き起こすかどうかを簡単に確認できます。

コードスタイルも重要になります。これは、共通のスタイルを順守すると、コードが誰にとっても読みやすくなるためです。大企業では、コーディング標準への準拠を自動的にテストする夜間ジョブを見つけて、逸脱すると厄介な警告を電子メールで送信します。

質問に戻りますが、アートコンポーネントに集中することは、プログラマーの開発の自然な初期段階です。規律コンポーネントの評価を開始するには、業界で数年かかることがあります。ただし、「テクニックの変更」を積極的に検討する必要はありません。チームで作業する過程で自然に変化します。

あなたの質問に、うん、あなたは常にあなたのテクニックを変えて、ユニークなプロジェクトと新しいテクノロジーを受け入れることを探しているべきです。

@assfallowsの「率直に言って、プログラマはあなたのことではありません。プログラマはあなたが常に学び続けるものです。」本当にすべてであり、コーディングのすべてを終了します。

あなたが他の人とは違うことをする領域に気づいているのは素晴らしいことです、特にそれが標準だとわかるとき。ユニットテストとMVCを見つけました。次は、それらについて学ぶ必要があります。それらがどのように機能するか、それらを実装するために必要なものを確認し、それらを実装するのが良いデザインであるときの感覚を試してみてください。

これは絶えず進化している分野であり、新しい言語とパターンが上昇および下降しています。コーディングの側面に慣れている場合は、設計部分の調査を開始します。何が良いのか、いつ使用するのかを学びましょう。

確かにチームに参加することは大きな利点です。コードを見て、急いだり、完全な意味を考えなかった領域を見つけるために、常に他の目が必要です。

あなたはより優れたコメント者である必要はありません。しかし、あなたは良いコミッターでなければなりません（はい、何らかのVCSを使い始めてください-Gitをお勧めします）。

スタイルは常に進化するものです。心配しないでください。再利用可能なコードとそうでないコードについて学習します。しかし、あなたはそれを練習し、助けを得る必要があります。

Githubのオープンソースプロジェクトを支援してみてください。一部の人々はそこに本当に親切で、あなたを助けようとします。これは私があなたに与えることができる最高のヒントです。

実際、私は人々が最終的に私のコードをチェックアウトするという事実をかなり恐れています。これはプログラマーが経験する普通のことですか、それとも本当に自分のテクニックを変更する必要がありますか？

経験豊富なプログラマーからのフィードバックなしで、何を変更するかをどのように知っていますか？

他の人にあなたの作品をレビューさせることは、特に最初の数回は気が遠くなるかもしれませんが、それはあなたのスキルを向上させるために必要な建設的な批判を得るための最良の方法です。役立つと思われるコードレビュー用のSEサイトがあります。賢い友人にコードを見てもらうことは、フィードバックを得るもう1つの良い方法です。

最も重要なことは、柔軟性を高めることです。基本的な概念に精通すればするほど、どの言語、プログラミング手法、スタイル、または環境でも即応することができます。

習得は、あらゆることを学ぶことではなく、さまざまな状況で、学習すること、そして問題を解決する方法を学ぶことです。

そして、そのための最良の処方は実践です。常にプロジェクトが必要です。有料のギグの合間には、個人的なおもちゃを用意してください。週末の空き時間は？これまでに使用したことのない言語またはプラットフォームの「ハローワールド」を操作します。一度に多くを学ぶ方法を探してください。たとえば、Google App Engineで何かを構築すると、Python、BigTable、列指向のデータベースについて一度に学ぶことができます。「プロフェッショナル」なGoogleスタイルも十分に得られます。

優れた将軍は、学んだ戦術を適用し、さまざまな地形で経験を収集する方法を知っています。いくつかの戦術と経験があるようですが、なじみのない地形に遭遇する必要があります。それはおそらく、あなたが知っていることと次に学ぶべきことを確認するための唯一の最良の方法です。

そして、「プロフェッショナル」スタイルがあなたが求めているものであるなら、いくつかの「プロフェッショナル」プロジェクトに挑戦してください。好きなオープンソースプロジェクトを見つけ、自分自身に変更を割り当て、それについて設定します。ジャッキーのレビュアーのために準備してください、しかし、この分野の人々の大部分は、彼らがスムーズな社会的スキルを持っているために彼らがいる場所を得なかったことを思い出してください。重要なのは、できるだけ多くなりたいものに自分自身をさらすことです。そして、あなたは自分自身でそれを行うのに十分な自分自身を構築する必要があります。どのクラスも実際に教えることはできません。実際、今日はあまりにも多くのクラス学習が行われていますが、実世界の能力は十分ではありません。

自分のコードの見栄えに自信がなかったり、入社時に火花を散らしたり、オープンソースプロジェクトに貢献したりするのではないかと思うようになりました。実際、私は人々が最終的に私のコードをチェックアウトするという事実をかなり恐れています。これはプログラマーが経験する普通のことですか、それとも本当に自分のテクニックを変更する必要がありますか？

私の意見では、コードの品質の客観的な測定に焦点を合わせれば、他の人があなたのコードをどう思うか心配する必要はありません。それは...ですか

• 正しい？
• 分かりますか？
• 保守可能ですか？
• 効率的？

最初の原則として、他人の意見ではなく客観的な資質に焦点を合わせることが常にあなたの目標であるべきです。他人の意見に焦点を合わせることが平凡への道であり、あなたが経験しているように、不安です。

他人の意見に関心を持つ唯一の理由は、他の人と社会的に（または職場環境で）うまく統合できるようにすることです。あなたの仕事の客観的品質を改善するという目標を心の最前線に持っているなら、他人の反応を恐れる必要はありません-彼らはただ学ぶ機会、または最悪の場合、対処する実際的な詳細です。

自分に正直である！！あなたがしていることを学び、楽しんでください。

大学に行ってソフトウェアエンジニアになった後、私のことを思い出してください。あなたがプログラマになりたいなら、私はポジションを取ると言うでしょう。コードをコメント化し、単体テストを作成し、オブジェクト指向コードを完全に理解する必要があります。しかし今のところ、そうする本当の理由はありません。あなたが個人的な小さなプロジェクトに取り組んでいる限り。自分以外に答える必要がない場合。開発者としてこれ以上成長することはありません。

多くの人が取り組んでいる大規模なプロジェクトを引き受けて、「このリリースのバグはありますか？お客様にリリースするためです。」などの経営者の質問に答えなければなりません。あなたはプログラマー/エンジニアとして成長します。あなたはいくつかのハードノックを取得します。あなたが言及したものがより価値があると思うかもしれません。あなたは成長します。

私の大学でさえ、これらのことを試みても教えてくれませんでした。

単体テストについては、テスト駆動開発を探してください。

コメントのために、あなたが行った後に書いたコードを考えてください。そして、他の人がリバースエンジニアリングに費やす時間。

オブジェクト指向言語の場合。少なくとも理解してください。より読みやすい方法で問題を解決するために使用できるツールです。

幸運：D

要するに、学習するための最良の方法は、あなたが学ぶことができる誰かとたむろして、一般的であるから、。自分のスキルが一向に上がらないと感じた場合、自分よりも優秀な人と時間を過ごすことが最善です。確かに、自分自身をさらに引き離して隔離するよりもはるかに優れています。

ただし、非常に単純化された誤解を招く絵を描いていると思います。すべての「専門的に教えられた」プログラマーとはほど遠く、本当に良い人です。彼らが何かをするからといって、それが正しいことだとは限らない。

そして、あなたが言っていることの多く（しかしすべてではない）は、本当にあなたが彼らに 1つか2つのトリックを教えることができる人のように聞こえます。

私はオブジェクト指向よりも機能的な側面に傾いていますが、抽象的なエンティティとして何かがより理にかなっている場合にオブジェクト指向の使用を見ます。

それは私には素晴らしいですね。最高のコーダーは、仕事に適切なツールを使用するコーダーです。私は常に両方のパラダイムを知っている人を選び、宗教的に1つのパラダイムのみを使用する人よりも理にかなっているそれぞれを使用します。

次に、私は何かをするときも簡単なルートに行きます。対照的に、プロのプログラマーから見たコードは、そのために複雑な場合があるようです！

繰り返しますが、シンプルさは良いです。複雑になる必要があるまで、コードを複雑にしないでください。一部の人々は、エレガンスに関する誤った考えから、または「後でこの追加機能が必要になる」ために、物事を複雑にする傾向があります。一般的に、あなたの問題を解決する最も簡単なことをする方が良いです。

私は多くのクロージャーを使用しています。良い。それが彼らがそこにいる理由です。彼らは1990年代とJavaの時代遅れの準OOPモデルで立ち往生した一部の人々を怖がらせますが、実際にはそれが彼らの問題です。

そして最後に、私は最高のコメント者ではありません。

何をコメントする必要があり、どのように、非常に主観的です。そこには本当の「正しい」または「間違った」ものはありませんが、チームで作業するときは、コードの作成者だけでなく、チーム全体が理解できるコードを書くことが重要です。また、チームのコーディングスタイルに準拠するために妥協が必要になる場合があります。それは必ずしもあなたがより多くのコメントを書く必要があるという意味ではなく、単にあなたとあなたのチームが同意しなければならないものであることを意味します。

専門的な訓練を受けたプログラマーが単体テストのようなことを続けていると聞きます。これまでに使用したことがないものなので、それらが何であるか、またはどのように機能するのかについても微妙な考えすらありません。

さて、彼らに聞いてください。:)コードのテストは不可欠であり、単体テストはこのための一般的で便利なツールです。

たくさんのアンダースコア「_」は、本当に私の好みではありません。

コメントと同様に、それは主観的であり、言語に依存します。CおよびC ++では、lowercase_with_underscoresかなり一般的な命名規則です。他の多くの言語では、アンダースコアはほとんど表示されません。しかし、結局のところ、それは本当に重要ではありません。関数が呼び出されたかどうwrite_to_logかWriteToLog、実際に違いを作るつもりはありません。誰かがそれを吸い上げて、チームがそこに同意したものに従う必要があります。

MVCについては何も知りません。backbone.jsのようなものについてはよく耳にします。アプリケーションを整理する方法だと思います。ただ私を混乱させているのは、今では自分の組織構造を作ったからです。

単体テストと同様に、学習を止めないでください。あなたは、あなたが知らないことを知っていて、あなたとは異なるバックグラウンドから来た人々と一緒に働きます。お互いから学ぶ。あなたがそれらを教えることができることは明らかにありますが、あなたが知らない、または聞いたことがないこともあります。それはあなた（または彼ら）が悪いプログラマーであることを意味しません。優れたプログラマーとは、改善を図り、他者から学ぶことを目指しているプログラマーを意味します。

完全なオブジェクト指向プログラミングは本当に私の口に悪い味を残します

ここも同じです。私はあなたが「専門的に訓練された」（CS学位）と呼んでいます。プログラミングを教えられた人は、独学した人と同じくらい違います。あなたは本当にいくつかの新しいトリックを学ぶ必要がある人たちと働いているようですね。

実際、私は人々が最終的に私のコードをチェックアウトするという事実をかなり恐れています。これはプログラマーが経験する普通のことですか、それとも本当に自分のテクニックを変更する必要がありますか？

両方。もちろん、あなたが作ったものを他の人に見てもらう（そして判断する）のは怖いです。しかし、それは非常に教育的でもあります。彼らは、彼らがそうしなかった場合に何をしたか、または彼らがそうしなかった理由をあなたに伝えることができます。彼らはあなたが改善するのを助けることができ、彼らは自分自身で何かを学ぶかもしれません。「優先」ソリューションが行うよりも問題を解決するコードを見せてください。うまくいけば「ああ、それはすてきです。どうやってそれを知ったのですか？これを何と呼んでいますか？私はこのテクニックを自分で使うべきです」 」

これは完全な答えではありません。すでにいくつかの良いものがあります。しかし、私には少し混乱しているように見え、対処されていない点がいくつかあります。

それは私が行ういくつかのことの混合物です。私はいくつかのプログラミングパラダイムをブレンドする傾向があります。機能的およびオブジェクト指向のように。私はオブジェクト指向よりも機能的な側面に傾いていますが、抽象的なエンティティとして何かがより理にかなっている場合にオブジェクト指向の使用を見ます。ゲームオブジェクトのような。

あなたが混乱しているように私には見えます、宣言対不可欠ではなく、機能的な対オブジェクト指向プログラミングよりも、プログラミングを。宣言型プログラミングに向かって、命令型から離れることを意味する場合、それは良いことです。宣言型は、コードを理解しやすくする副作用を削除しようとします。

現代のプログラミング言語は、多くの場合、宣言型プログラミングモデルをサポートしています。たとえば、C＃では、Linqを使用すると宣言スタイルになります。これは、必要なものを取得する方法を言っていないためです。あなたが望むものを言っているだけです。

完全なオブジェクト指向プログラミングは本当に私の口に悪い味を残しますが、それは他の誰もが厳密に使用しているもののようです。

現代の言語は、しばしばマルチパラダイム言語です。誰もが「純粋な」言語を使用することはまれです。多くの関数型言語はオブジェクトと副作用をサポートしています。オブジェクト指向と見なされる言語は、多くの場合、すべてがオブジェクトであるという制約を課しません。

完全なオブジェクト指向とはどういう意味ですか？私は「純粋な」OOコードに取り組んだことがありません。おそらく、あなたが私たちにあなたが嫌い​​なもののいくつかの詳細を与えることができます。オープンソースプロジェクトの図が役立つかもしれません。

オブジェクト指向プログラミングは、データの抽象化、カプセル化、メッセージング、モジュール性、多態性、継承などをサポートする多くの機能を提供します。それを利用しないコードベースを見た場合、口に悪い味が残ります。

簡単な答え：はい。

あなた自身を教えることはほとんどすべて良いです。
理にかなった良いアドバイスでフィルターします。

WRT学習プロフェッショナルプログラミング、はい。
何を考えていますか？
会議、セミナー、認定、学位？
それぞれに費用/便益があります。
ROIが良好な場合、リソースがあれば、それを活用してください。

ソースを検討して、学位に関するアドバイスを検討してください。
それぞれ半ダースに話してください。

学界は産業界から隔離されていますか？しばしば。
学位は無価値ですか？議論するのは難しい、ドル単位で。
卒業生はほとんど常により多くのお金を稼ぎますが、大学の融資に注意してください。

知識に関しては？多分。
学校が嫌いなら、入れた以上のことはできません。

学位があなたにとって価値のある目標であると思うなら、おそらくそうです。

深く掘り下げて、学習プログラム、コスト、環境について調べてください。関心、コミットメント、時間、リソースがあることを確認してください。おそらく13年間学校に通っていたので、あと4つは何ですか？彼らは最も高価であり、あなたがそれらを最も価値あるものにするために頼る主な人はあなたです。

費用はかなり恐ろしい場合がありますが、メリット、ニーズ、その他100の理由から多くの助成金や奨学金があるため、物語の一部しか語りません。

行ったら、賢い教授と芽を選んでください。

2番目の質問-自分のスタイルを使用できますか？

2つの質問があります。

最初はタイトルにあります。以前の回答をご覧ください。

2つ目は約5段落で詳しく説明されています。ここでは、スタイルがプロのスタイルとどのように異なるかを以下の点で特徴づけます。

• 100％独学。
• 技術と組織が異なります。
• 機能指向とオブジェクト指向の融合。
• それほど複雑ではありません。
• 多くの閉鎖。
• いくつかのコメント。
• 単体テストはありません。
• アンダースコアはほとんどありません。
• MVCなし。
• Backbone.jsはありません。
• テンプレートアプリケーションはありません。

要約すると、フランクシナトラのアプローチを使用することで問題ないかと尋ねていると思います-「自分のやり方でやった」。あなたが他の人のコードの専門家を呼ぶとき、私はアンビバレンスを感じますが、あなたはそれに参加していません。スタイルは個人的な問題であり、優れたコードが何であるかについての議論は無限であり、多くの場合時間の無駄です。グループで記述されたコーディング規則を使用すると、いくつかの問題がより簡単になる場合があります。チェックしてください：

http://en.wikipedia.org/wiki/Coding_conventions

他の人のコードを殺すためのエチケットがあり、それはあなたのチームと一緒に取り組むべきもう一つのことです。あなたの厚い肌を着て、彼らがあまりにも残忍ではないことを願っていますが、あなたが何をしても、戦争に行かないでください。

あなたはあなたのコードを見ている他人に対する不安についてコメントしました。彼らがそれを見るだけでなく、彼らがそれを書き直してあなたのスタイルの何が悪いのかをあなたに伝えるので、準備をしてください。同僚は柔軟でも硬直でもかまいません。いずれにしても、スタイル用にコードを書き直したり、スタイルの各ポイントをネゴシエーションにしたりしないことをお勧めします。

統一されたコード（および統一されたトレーニング）を持っている理由は、開発の速度と生産性を高め、何らかの形でベストプラクティスの学習を制度化することです。camelCaseやuse_underbarsのような問題は些細でささいなように見えますが、一貫性には利点があります。

単体テストとテスト駆動開発にオープンにしてください。あなたが一人でいるとき、有料のプロジェクトを行うことの一部ではなく、それは趣味のようです。あなたのものは、他の人がやっていることと一致する必要はありません。コードがクラッシュしても大した問題はありません。しかし、チームに関与している場合、特に顧客に届いた場合、作成したコードはチーム全体に影響を与える可能性があります。

同様に、チームがMVCを使用している場合、できれば参照先と同じソースからMVCについて学習してください。実験で示されているように、プログラムを構造化する方法は大きな違いを生む可能性があります。繰り返しますが、あなたのチームからの例とリーダーシップを取ります。

チームがbackbone.jsを使用している場合は、それも使用します。あなたのチームは、編隊飛行するアヒルのようなものです。一緒に並んでいると、消費するエネルギーが減り、安全になり、より効果的に目的地に着くことができます。あなたがそれを非常にプッシュするとアナロジーは崩れますが、一般的なツール、テクニックを使用し、チームの意思決定の背後で調整することには大きな利点があります。

与えられたアドバイスは非常に役立ちますが、私の主な目標は、ユーザーに役立つ「作業ソフトウェア」を作成することであることを忘れないようにしています。私の聴衆は通常プログラマーのグループではありません-彼らは自動化されたソリューションにお金を払ってくれるビジネスマンです（ユーザーはオブジェクト指向の方法論、フレームワーク、ユニットテスト、コードコメントなどを気にしませんハングアップしました。）

アジャイルマニフェストの理想が私のキャリアで役立つことがわかりました（www.agilemanifesto.org）

• プロセスとツールを介した個人と相互作用
• 包括的なドキュメントよりも機能するソフトウェア
• 契約交渉を介した顧客コラボレーション
• 計画に従うことによる変化への対応

私はこの質問に完全に関連しています。私はまったく同じ感情と非常に似た背景を持っています（しかし、まったく同じではありません）。私は専門的に（または学問的に）訓練されることになっているので、オブジェクト指向プログラミングなどについて知っておく必要があります。プログラミングは私の主要なトピックではありませんでしたが、私はそれをやりました。私はいくつかのコースでオブジェクト指向を学びましたが、理由をまったく理解していませんでした。実際、私がOOを理解したのは、私が商業的な仕事をし、2人の偉大なメンターによってそれに強制されたときだけでした。

私の教授も同様に優れていたと思いますが、商業環境での実践の実際の利点と機能プログラミングの違いはわかりますが、数か月以内に実行して教え、終了するように設計されたコースでそれを見ることはできません。私はMVCベースの構造で作業する機会がありませんでしたが、それは同じであると確信しています。つまり、本から機能する概念を取り上げることができると確信していますが、商業環境。そして、あなたがより簡単な方法で問題を解決できるなら、なぜOOとMVCと他の複雑な構造を使用するのか、あなたに完全に同意します。私のアドバイスは仕事を恥ずかしがらないことです。それはあなたを異なる状況にさらし、同じことを異なる観点から理解できるようにするからです。

確かに私は学歴で構文と概念を学びましたが、プログラミングを学ぶようになったのは商業の世界です。