最近、私は専門的な仕事をして、他のプログラマーと付き合って、業界で友達を作っています。唯一のことは私が100%独学していることです。それが私のスタイルを、適切に訓練されたスタイルから非常に逸脱させています。異なるのは、私のコードのテクニックと構成です。
それは私がするいくつかのことの混合です。私はいくつかのプログラミングパラダイムをブレンドする傾向があります。ファンクショナルとオブジェクト指向のように。私はOOよりも機能的な側面に傾いていますが、OOの使用は、抽象的なエンティティとしてより意味のある場合に見られます。ゲームオブジェクトのように。次に、対照的に、プロのプログラマーから見たコードは、そのために複雑であるように見えることがあります!私は、多くのクロージャーを使用しています。最後に、私は最高のコメント者ではありません。コメントを読むよりもコードを読んでいます。ほとんどの場合、コメントがあったとしてもコードを読んでしまうだけです。さらに、コードを書くのが簡単なため、コードを読むのは非常に簡単です。
専門的に訓練されたプログラマーがユニットテストのようなものについてどんどん進んでいくのを聞いています。私が今まで使ったことのないものなので、それらが何であるか、またはどのように機能するかについての最も暗い考えすらありません。たくさんのアンダースコア "_"が付いていますが、これは私の好みではありません。私が使用するテクニックのほとんどは、私から直接のもの、または私が読んだいくつかの本です。 MVCについては何も知りません。backbone.jsのようなものを使って、MVCについてよく聞いています。アプリケーションを整理する方法だと思います。でも、今は自分の組織構造を作っているので、混乱します。
少し苦痛です。 UbuntuのQuicklyのような新しいことを学ぶときは、テンプレートアプリケーションをまったく使用できません。訓練を受けた人からのものであると言えるコードを理解するのに問題があります。完全なOOプログラミングは本当に口に悪い味を残しますが、それは他の誰もが厳密に使用しているようです。
私のコードの外観にそれほど自信がないか、会社に入社したり、おそらくオープンソースプロジェクトに貢献したりするとスパークが発生するかどうか疑問に思いました。実際、私は人々が最終的に私のコードをチェックアウトするだろうという事実にかなり怖いです。 これはプログラマーが経験する通常のことですか、それとも本当にテクニックを変更する必要がありますか?
実際、私は人々が最終的に私のコードをチェックアウトするだろうという事実にかなり怖いです。
良い。人々があなたのコードを見るつもりであることを意識することは、あなたをもっと一生懸命にさせるでしょう。
プログラミングは非常に大きな分野になりました。何十ものトピック、ツール、ニッチ、専門分野があり、そのうちのいくつかはそれ自体がキャリア全体です。学ぶことと知ることには膨大な量があり、他のプログラマーと一緒に仕事をするとき、彼らが知らないことを知っているものと、知らないことを知っているものは常に存在します。これは良いことです。
あなたの経験が不完全であると心配している場合、正式な教育と訓練された専門家との協力を通じてそれを修正するために取ることができる多くのステップがあります。しかし数値化可能なマイルストーンがいくつかあるように思われますが、その後「人々はそれを習得したので、私は正式にプログラマーです。」というようなマイルストーンはありません。私はそうです私が何か新しいことを学んだ後、「ええ、今、私はどこかに行く」と思った瞬間は確かにありましたが、プログラマーと呼ぶために知っておかなければならないことの魔法のリストはありません。
私はプログラミングについて多くのことを知っています。多くのプロジェクトで12の言語を使用してきましたが、自分のプログラミング知識のサブセットはごくわずかです。そして私はそれが好きです。 率直に言って、プログラマーはあなたのようなものではありません。プログラマーはあなたが常にあることを学んでいるものです。
あなたのスキル、長所と短所の正直な目録を取ってください。あなたよりも多くの経験を持つ人々からフィードバックをもらいましょう。自分がいると思う場所とかなり一致するポジションを探してください。しかし、現在の習熟から少し外れた仕事に行くことを恐れないでください。あなたがすでにすべてを知っている仕事をとるだけなら、あなたは仕事で学ぶことは決してないでしょう。
他の開発者と協力してアプリケーションの開発を始めると、これらの個人的なスタイルの一部が邪魔になります。
アンダースコアを使用するショップで働き始めると、アンダースコアを使用することになります。誰もが、以前のバックグラウンドに関係なく、コーディングスタイルのショップ標準に従っています。
コーディングスタイルが非常に明白でない限り、他の開発者がコードを理解できるように、コードがどのように機能するかを説明する明確で簡潔なコメントを書くことに慣れる方がよいでしょう。
単体テストについて何も知らない場合は、良い本を購入してください。単体テストに関する優れた本はたくさんあります。 MVCと同じです。
プロのソフトウェア開発者は、サンドボックスを散らかすことなく、他の人とうまく遊ぶ方法を知っています。最高のものは、スタイルに関係なくコードを読み書きする方法を知っています。
プログラミングには、アートコンポーネントとそれに対する分野コンポーネントがあります。アートコンポーネントは、最善のアプローチを考え、実装することです。規律は、あなたが正しくそれを行ったことを確認することであり、他の人があなたのコードを理解し、必要に応じてそれを拡張できることです。
アートコンポーネントは楽しいです。楽しんでいるからこそできます。当然、それはあなたが最初にあなた自身に教える部分です。
しつけのコンポーネントはもっと厄介なものです:あなたは必要以上にそれをします。しかし、それはチームでの作業の重要な要素です。少なくともある程度は、それをやめることはできません。コードがチームメイトのコードと統合されると、「自由自在に変更」できる柔軟性が急降下します。しかし、要件の変化に対応して自信を持ってコードを変更したり、バグに対処したりする機能が必要です。これは、さまざまな「退屈な」テストの出番です。多くのテストが実施されているので、最新の変更によって問題が発生するかどうかを簡単に確認できます。
共通のスタイルに準拠することで、誰にとってもコードが読みやすくなるため、コードスタイルも重要になります。大企業では、コーディング標準への準拠を自動的にテストする夜間ジョブを見つけ、逸脱すると厄介な警告を電子メールで送信します。
質問に戻りますが、アートコンポーネントに集中することは、プログラマの開発の自然な初期段階です。専門分野のコンポーネントを理解し始めるまでには、業界での作業に数年かかる場合があります。ただし、「テクニックの変更」に積極的に目を向ける必要はありません。チームで作業する過程で自然に変化します。
あなたの質問に対して、ええ、あなたはいつもあなたのテクニックを変えて、ユニークなプロジェクトと新しいテクノロジーを受け入れるように探しているべきです。
@率直に言って、「率直に言って、プログラマーはあなたのようなものではありません。プログラマーはあなたが常にあることを学んでいるものです。」本当にすべてであり、コーディングのすべてです。
特に標準であるとわかったときに、他の人とは異なる何かをしている領域に気づいていることは素晴らしいことです。ユニットテストとMVCを見つけました。次は、それらについて学ぶ必要があります。それらがどのように機能するか、それらを実装するために何が必要かを確認し、それらを実装するのに優れた設計であるかを試してみてください。
これは常に新しい分野であり、新しい言語とパターンが次々と登場しています。コーディングの側面に慣れている場合は、設計部分の調査を開始してください。それらが良い点とそれらをいつ使うべきかを学びましょう。
確かにチームに参加することは大きな利点です。急いでいたり、完全な影響を考えなかった領域を見つけるために、コードを他の目で見る必要があります。
あなたはより優れたコメンターである必要はありません。しかし、あなたは優れたコミッターである必要があります(はい、ある種のVCSを使い始めます-私はGitをお勧めします)。
スタイルは常に進化するものです。心配しないでください。再利用可能なコードとそうでないコードを学びます。しかし、あなたは練習し、そのための助けを得なければなりません。
Githubのいくつかのオープンソースプロジェクトに協力してみてください。一部の人々はそこで本当に素敵で、あなたを助けようとします。これは私があなたに与えることができる最高のヒントです。
実際、私は人々が最終的に私のコードをチェックアウトするだろうという事実にかなり怖いです。これは、プログラマーが経験する普通のことですか、それとも本当にテクニックを変更する必要がありますか?
経験豊富なプログラマーからのフィードバックなしに、何を変更すればよいでしょうか?
他の人にあなたの作品をレビューしてもらうことは、特に最初の数回は気が遠くなるかもしれませんが、スキルを向上させるために必要な建設的な批評を得るための最良の方法です。参考になるかもしれない コードレビュー のSEサイトがあります。賢い友達にあなたのコードを見てもらうことは、いくつかのフィードバックを得るためのもう一つの良い方法です。
最も重要なことは、柔軟性を開発することです。基本的な概念に精通すればするほど、あらゆる言語、プログラミングアプローチ、スタイル、環境での応答性が向上します。
習得することは、さまざまな状況で、すべての/ thing /を学ぶことではなく、/ how /を学ぶことで、問題を解決することについて学びます。
そして、そのための最良の処方は実践です。常にプロジェクトが必要です。有料のギグの合間には、個人用のおもちゃを使ってください。週末の空き時間は?これまでに使用したことのない言語やプラットフォームの「Hello World」に取り組みます。一度にたくさん学ぶ方法を探してください。たとえば、Google App Engineで何かを構築すると、Python、BigTable、列指向のデータベースについて一斉に学習できます。 「プロ」のGoogleスタイルも十分に取り入れられます。
優れた将軍は、彼の学んだ戦術と収集した経験をさまざまな地形で適用する方法を知っています。戦術と経験はあるようですが、なじみのない地形に遭遇する必要があります。それがおそらく、あなたが知っていることと次に何を学ぶ必要があるかを確認するための単一の最良の方法です。
そして、「プロフェッショナル」スタイルがあなたの追求しているものであるなら、いくつかの「プロフェッショナル」プロジェクトに取り掛かってください。好きなオープンソースプロジェクトを見つけ、自分に変更を割り当て、それについて設定します。ジャッカスレビュアーの準備をしてください。ただし、この分野の大多数の人々は、スムーズなソーシャルスキルを身に付けるために、自分のいる場所に到達しなかったことを思い出してください。重要なのは、自分がなりたいことのできるだけ多くに自分をさらすことです。そして、あなたは自分でそれを行うために十分に自分自身を構築しなければなりません。どのクラスもあなたを実際に教えることはできません。実際、今日行われているクラス学習はあまりにも多く、実世界での十分な能力は十分ではありません。
大学に行ってソフトウェアエンジニアになってから、私のことを思い出してください。もしあなたがプログラマーになりたいなら、私はポジションをとるでしょう。あなたはあなたのコードにコメントし、ユニットテストを書き、完全にオブジェクト指向のコードを理解する必要があるでしょう。しかし、今のところ、そうする理由はありません。あなただけの個人的な小さなプロジェクトに取り組んでいる限り。自分以外には答える必要がないところ。開発者としてこれ以上成長することはありません。
多くの人が取り組んでいる大規模なプロジェクトに取り組み、「このリリースにはバグはありませんか?それをお客様にリリースするつもりなので、管理者の質問に答える必要があります。」あなたはプログラマー/エンジニアとして成長します。あなたはいくつかのハードノックを取得します。あなたはあなたがあなたが言及したものをより価値があると思うかもしれません、そして、あなたは誰も以前に持っていなかった新しいものを見つけるかもしれません。あなたは成長します。
私の大学でさえ、彼らが試みたにもかかわらず、これらのことを私に教えることができませんでした。
単体テストについては、テスト駆動開発を探してください。
コメントのために、あなたが行った後にあなたが書いたコードを考えてください。そして、他の人々がそれをリバースエンジニアリングするのに費やす時間。
オブジェクト指向言語用。少なくともそれを理解してください。これは、問題をより読みやすい方法で解決するために使用できるツールです。
幸運:D
私のコードの外観にそれほど自信がないか、会社に入社したり、おそらくオープンソースプロジェクトに貢献したりするとスパークが発生するかどうか疑問に思いました。実際、私は人々が最終的に私のコードをチェックアウトするだろうという事実にかなり怖いです。これはプログラマーが経験する普通のことですか、それとも本当にテクニックを変更する必要があるのでしょうか?
私の意見では、コードの品質の客観的な測定に集中すれば、他の人があなたのコードをどう思うか心配する必要はありません。それは...ですか
第一の原則として、他人の意見ではなく、客観的な資質に焦点を合わせることが常にあなたの目標であるべきです。他人の意見に焦点を合わせることが平凡さへの道であり、あなたが経験しているように、不安です。
他人の意見を気にする唯一の理由は、他人の意見と社会的に(または職場環境で)うまく統合できることです。あなたの心の最前線にあなたの仕事の客観的な品質を改善するという目標があるなら、他の人の反応を怖がる必要はありません-それらは学ぶ機会、または最悪の場合、対処するための実用的な詳細です。
自分に正直である!!あなたがしていることを学び、楽しんでください。
私は完全にこの質問に関連しています。私はまったく同じ気持ちで、非常に似た背景があります(ただし、まったく同じではありません)。私は専門的に(または学問的に)トレーニングを受けることになっているので、OOプログラミングなど)について知っているはずです。プログラミングは私の主要なトピックではありませんでしたが、学習しました。OO一部のコースでは理由の説明がまったくわかりませんでした。事実、私が理解したのはOOが商業活動をして強制されたときだけでした2人の偉大なメンターによってそれに。
私の教授も同様に優れていたと思いますが、実際の商用環境では関数型プログラミングよりも実際の利点がわかりますが、数か月以内に実行および指導して終了するように設計されたコースでそれを見る機会はありません。 。私はMVCベースの構造で作業する機会がありませんでしたが、それは同じであると確信しています。つまり、本から機能する概念を拾うことができますが、それが商業環境。そして、私はあなたに完全に同意します。より簡単な方法で問題を解決できる場合は、なぜOOとMVCと他の複雑な構造を使用するのですか?私のアドバイスは、状況が異なり、同じことを別の観点から理解できるようになります。
確かに私は学歴の中で構文と概念を学びましたが、プログラミングを学ぶようになったのは商業の世界です。
短い答え:はい。
自分を教えることはほとんどすべて良いことです。
良い意味でのフィルター、良いアドバイス。
はい、プロのプログラミングを学ぶWRT。
あなたは何を考えていますか?
会議、セミナー、認定、学位?
それぞれにコスト/メリットがあります。
ROIが良好な場合、リソースがあればそれを求めます。
出典を検討することにより、学位に関するアドバイスを比較検討してください。
それぞれ半ダースと話します。
学界は産業界から隔離されていますか?しばしば。
学位は無駄ですか?ドル単位で、議論するのは難しい。
卒業生はほとんど常により多くのお金を稼ぎますが、大学のローンに注意してください。
知識的に?多分。
あなたが学校を憎むなら、あなたが入れた以上のことは得られません。
学位があなたにふさわしい目標であると感じているなら、それはおそらくそうです。
より深く掘り下げて、研究プログラム、費用、環境について調べます。関心、コミットメント、時間、リソースがあることを確認してください。あなたはおそらく13年間学校に通っていたので、次の4つは何ですか?それらは最も高価であり、それらを最も価値のあるものにするためにあなたが信頼する主な人物はあなたです。
費用はかなり恐ろしいかもしれませんが、メリット、ニーズ、その他100の理由から多くの助成金や奨学金があるため、それらは話の一部しか伝えません。
あなたが行くなら、賢い教授と芽を選んでください。
2番目の質問-自分のスタイルを使用できますか?
2つの質問があります。
最初はあなたのタイトルです。私の以前の答えを見てください。
2つ目は、約5つの段落で詳しく説明されています。ここでは、自分のスタイルがプロのスタイルとどのように異なるかを以下の点で特徴付けます。
要約すると、フランク・シナトラのアプローチを使用することは大丈夫かと尋ねていると思います-「私は自分のやり方でやった」他の人のコードの専門家に電話するとき、私はあいまいさを感じますが、あなたはそれに同意していません。スタイルは個人的な問題であり、優れたコードとは何かについての議論は無限であり、多くの場合、時間の無駄です。グループが記述されたコーディング規約を使用している場合、いくつかの問題はより簡単かもしれません。チェックしてください:
http://en.wikipedia.org/wiki/Coding_conventions
他の誰かのコードを殺すためのエチケットがあり、それはあなたがチームと取り組むべきもう一つのことです。あなたの厚い皮膚をつけて、彼らがあまりに残忍ではないことを願ってください、しかし、あなたが何をしても、戦争に出かけないでください。
あなたは自分のコードを見る他の人の不安についてコメントしました。彼らはそれを見るだけでなく、彼らがそれを書き直し、あなたのスタイルの何が悪いかをあなたに言うので、準備をしてください。あなたの同僚は柔軟な場合もあれば、固い場合もあります。どちらにしても、スタイルのコードを書き直したり、スタイルの各ポイントをネゴシエーションにしたりしないことをお勧めします。
統一されたコード(および統一されたトレーニング)を使用する理由は、開発の速度と生産性を向上させることと、何らかの方法でベストプラクティスの学習を制度化することです。 camelCaseやuse_underbarsのような問題は些細で些細なことのように思えるかもしれませんが、一貫性にはメリットがあります。
単体テストとテスト駆動開発に開放してください。あなたが一人でいるとき、給与のためのプロジェクトの一部ではなく、それは趣味のようなものです。あなたの作品は、他の人がやっていることとかみ合う必要はありません。コードがクラッシュしても、大したことはありません。しかし、チームに関与している場合、特に顧客に届く場合は、作成したコードがチーム全体に影響を与える可能性があります。
同様に、チームがMVCを使用している場合は、MVCについて学んでください。プログラムを構造化する方法は、実験で示されているように大きな違いを生む可能性があります。ここでも、チームの例とリーダーシップを取り上げます。
チームがbackbone.jsを使用している場合は、それも使用します。あなたのチームは編隊を飛んでいるアヒルのようなものです。一緒に並んでいると、消費するエネルギーが減り、安全性が高まり、より効率的に目的地に行くことができます。類推は、それを非常にプッシュすると破綻しますが、一般的なツール、手法を使用し、チームの意思決定の背後で調整することには大きな利点があります。
与えられたアドバイスは非常に役に立ちますが、私の主な目標はユーザーに役立つ「実用的なソフトウェア」を作成することであることを覚えておきたいと思います。私の聴衆は通常プログラマーのグループではありません-彼らは自動化されたソリューションにお金を払うことをいとわないビジネスマンです(ユーザーは気にしませんOO方法論、フレームワーク、ユニットテスト、コードコメントなどなので、あまり夢中にならないでください。)
アジャイルマニフェストの理想が私のキャリアに役立った(www.agilemanifesto.org)
要するに、学ぶための最良の方法は、一般的には、あなたが学ぶことができる誰かとハングアウトすることですfrom。自分のスキルが上手くいっていないと感じた場合は、自分よりも上手な人との付き合いがベストです。自分を引き離し、孤立させるよりも確かにはるかに良い。
しかし、あなたは非常に単純化された、誤解を招くような絵を描いていると思います。すべての「専門的に教えられた」プログラマーとは程遠い、本当に優れたプログラマーです。彼らが何かをするからといって、必ずしもそれが正しいことであるとは限らない。
そして、あなたが言っていることの多く(すべてではありません)は、あなたが教えることができる人のように聞こえますthemトリック1つまたは2つ。
私はOOよりも機能的な側に傾いていますが、OOの使用は、何かが抽象的なエンティティとしてより意味がある場合に見ます。
いいですね。最高のコーダーは、仕事に適したツールを使用する人です。私は常に両方のパラダイムを知っている人を選び、宗教的に1つのパラダイムのみを使用する人よりも理にかなっている場所でそれぞれを使用します。
次に、私は何かをするときにも簡単なルートに行きます。それとは対照的に、プロのプログラマーから見たコードは、そのために複雑になる場合があります。
繰り返しますが、単純さはgoodです。複雑になるまでneedsになるまでコードを複雑にしないでください。一部の人々doは、エレガンスの誤った考えから、または「この追加機能が後で必要になる」ため、物事を複雑にする傾向があります。一般に、問題を解決する最も簡単な方法を実行することをお勧めします。
クロージャーをたくさん使っています。良い。それが彼らがそこにいる理由です。彼らは、1990年代とJavaの時代遅れの準OOPモデルに行き詰まった一部の人々を怖がらせますが、実際には、それが彼らの問題です。
そして最後に、私は最高のコメント者ではありません。
コメントすべき内容と方法は非常に主観的です。そこには本当の「正しい」または「間違った」ものはありませんが、チームで作業するときは、コードの作成者だけでなく、チーム全体が理解できるコードを書くことが重要です。そして、時には、チームのコーディングスタイルに準拠するために妥協する必要があります。これは必ずしもコメントを増やす必要があるという意味ではなく、単にあなたとあなたのチームが同意しなければならないものであることを意味します。
専門的に訓練されたプログラマーがユニットテストのようなものについてどんどん進んでいくのを聞いています。私が今まで使ったことのないものなので、それらが何であるか、またはどのように機能するかについての最も暗い考えすらありません。
さて、彼らに尋ねます。 :)コードのテストは不可欠であり、単体テストはこのための一般的で有用なツールです。
たくさんのアンダースコア "_"が付いていますが、これは私の好みではありません。
コメントと同様に、それは主観的であり、言語に依存します。 CおよびC++では、lowercase_with_underscores
はかなり一般的な命名規則です。他の多くの言語では、実質的にアンダースコアは表示されません。しかし結局のところ、それは本当に重要ではありません。関数がwrite_to_log
と呼ばれるか、WriteToLog
と呼ばれるかは、実際には違いはありません。誰かがそれを吸い上げて、チームがそこで合意したことに準拠する必要があります。
MVCについては何も知りません。backbone.jsのようなものを使って、MVCについてよく聞いています。アプリケーションを整理する方法だと思います。でも、今は自分の組織構造を作っているので、混乱します。
単体テストと同様に、学習を停止しないでください。あなたは知らないことを知っていて、自分とは違うバックグラウンドの人と一緒に働きます。お互いから学ぶ。教えることができることは明らかですが、知らないことや聞いたことがないことも教えてくれます。それはあなた(または彼ら)が悪いプログラマであることを意味するものではありません。それは、優れたプログラマーとは、改善を図り、他者から学ぶ努力をするプログラマであることを意味します。
完全なOOプログラミングは本当に口に悪い味を残す
ここでも同じで、私はあなたが「専門的に訓練された」(CS学位)と呼んでいるものです。プログラミングを教えた人は、独学した人と同じくらい違います。いくつかの新しいトリックを本当に学ぶ必要がある人たちと一緒に作業しているようです。
実際、私は人々が最終的に私のコードをチェックアウトするだろうという事実にかなり怖いです。これはプログラマーが経験する普通のことですか、それとも本当にテクニックを変更する必要があるのでしょうか?
両方とも。もちろん、あなたが作ったものを他の人に見て(そして判断して)もらうのは怖いです。しかし、それは非常に教育的でもあります。彼らはそうでなければ何をしていたのかを教えてくれますなぜ彼らはそうでなければそうしたのでしょう彼らはあなたが改善するのを助けることができます、そして彼らは彼ら自身も何かを学ぶかもしれません。彼らの「推奨」ソリューションよりも優れた問題を解決するコードを見せてください。うまくいけば、彼らは「ああ、それはいいことです。どうやってそれを行うことを知ったのですか。これを何と呼びますか?このテクニックを自分で使う必要があります」 」
これは完全な答えではなく、すでにいくつかの良い答えがあります。ただし、少し混乱して対処されていない点がいくつかあります。
それは私がするいくつかのことの混合です。私はいくつかのプログラミングパラダイムをブレンドする傾向があります。ファンクショナルとオブジェクト指向のように。私はOOよりも機能的な側面に傾いていますが、OOの使用は、何かが抽象的なエンティティとしてより理にかなっている場合に見られます。ゲームオブジェクトのようです。
私には、関数型プログラミングとオブジェクト指向プログラミングではなく、 declarative vs imperative プログラミングを混乱させているようです。宣言型プログラミングに頼り、命令型プログラミングから離れることを意味している場合、それは良いことです。 Declarativeは副作用を取り除き、コードを理解しやすくします。
最近のプログラミング言語は、宣言型プログラミングモデルをサポートすることがよくあります。たとえば、C#では、必要なものを取得する方法を言っていないため、Linqを使用すると宣言的なスタイルになります。あなたはあなたが欲しいものを言っているだけです。
完全なOOプログラミングは本当に口に悪い味を残しますが、それは他の誰もが厳密に使用しているようです。
現代の言語はしばしばマルチパラダイム言語です。誰もが「純粋な」言語を使用することはまれです。多くの関数型言語はオブジェクトと副作用をサポートしています。オブジェクト指向と見なされる言語は、多くの場合、すべてがオブジェクトであるという制約を課しません。
完全なOOとはどういう意味ですか?私は「純粋な」コードに取り組んだことがありません。OOコード。おそらく、嫌いなことの詳細をもう少し教えてもらえます。オープンソースプロジェクトのイラストが役立つかもしれません。
オブジェクト指向プログラミングは、データの抽象化、カプセル化、メッセージング、モジュール性、ポリモーフィズム、継承などをサポートする多くの機能を提供します。それを利用しないコードベースを見ると、口に悪い味が残ります。