私が開発したいのは、より簡潔なコードを書くことです。少なくとも私の意見では、より簡潔に書くことで、コードにバグを追加する機会は少なくなります。他のコードを読む方が簡単です。
私の質問は、それが経験だけでもたらされるものなのか、それともその品質を開発するために明示的にできるものなのかということです。
私が開発したいのは、より簡潔なコードを書くことです。少なくとも私の意見では、より簡潔に書くことで、コードにバグを追加する機会は少なくなります。他のコードを読む方が簡単です。
私の質問は、それが経験だけでもたらされるものなのか、それともその品質を開発するために明示的にできるものなのかということです。
回答:
全体としては時間と経験が伴うものだと思いますが、より簡潔な言語で作業を行うと、その品質が通常の使用言語に戻ってくることがわかります。
確かに、Rubyで1〜2年働いた後、C#が非常に激しくなっていることがわかりました。関数型プログラミングをよりよく理解するために(進行中の野望)だったら、おそらくそれからもっと多くをとると思います。
また、役立つ2つのガイドラインがあります。たとえば、同じ2行を複数回独自のメソッドに分割して記述する場合です。これは簡単なガイドラインですが、コードの行をすばやくカットし、プログラミングをカットアンドペーストします。これは、私たちのほとんどが時として有罪です。
継承を理解していれば、親クラスに共通の機能を提供することで、異なる場所で同じコードを繰り返すことを節約できます。これは原則として明らかですが、実際に見逃しがちなものです。
より少ないコードを書くことと、アプリケーションでより少ないコードを持つこととの間には違いがあります-時にはコード生成を使用して自分自身を繰り返さなくてもよいので、数行のコードを書くだけで他の多くのコードを生成できます-それはあなたに多くのレバレッジを与えることができます。この点でRailsやEntity Frameworkのようなツールが何をするのかを見て、それがどれほど役立つかを把握してください。ただし、その必要性を明確にして、独自のコード生成をロールバックすることを2回、3回、そして4回考えてみてください。
言語、API、ツールを理解してください。繰り返しますが、これは明らかなようですが、長年にわたって多くのコードを書いてきたので、APIから継承した機能を再現したり、言語機能を使用して単純化したりすることを後で理解し、使用しているAPIのドキュメントは、後でコーディングやデバッグにかかる時間を大幅に節約します。同様に、作業するほとんどのプラットフォームにはきめがあります。期待どおりに機能することを学ぶと、あなたの人生はずっと楽になります。作業しているプラットフォームの最小の抵抗の方向を見つけるのに少し時間を費やしてください。そうすれば、物事がずっと良くなります。
あなたが何かをするためのより良い方法があるかどうか疑問に思っているなら、おそらくあります、そしてそれは常に物事をより良くする方法を見つける価値があります。
少ないコードを記述するための優れた方法の1つは、wheelの再発明を避け、利用可能な場合は既存のソフトウェアコンポーネントを使用することです。
なぜ人々が独自のORM、独自のロギングエンジン、独自のUIコンポーネント、または独自のすべてを実行したのかを尋ねると、よくある答えが1つあります。
しかし、私たちは優れています
この記述はほとんどの場合正しいと思いますが、ほとんどの場合、ROIへの悪影響は非常に大きくなります。あなたのお母さんは最高の料理をしますか?でも、お母さんに家に帰って毎日準備するよう頼むことはできません。
だからこそ、開発者は彼らの選択の経済的影響に関心を持つべきだと思います。それらのいくつかは次のとおりです。
これらのコンポーネントベンダーは、自分で構築、保守、改善するために支払った金額のごく一部で、あなたのために働くあなたの拡張チームだと思うのが好きです。
私たちの自我満足度を最大化することに取り組むよりも、会社全体がROIを最大化する方が良いです;)あなたの会社がより多くのお金を稼ぐほど、あなたの労働条件と給与が増加する可能性が高くなります。
私の意見では、いくつかの方法でより少ないコードを書くことができます:
あなたはそれを必要としません。まだ必要のないものをコーディングしないでください。要件の状態のみをコーディングします。このようにして、書くのに必要なコードを減らします。
自分を繰り返してはいけない。CMS、フレームワーク、またはサードパーティライブラリを使用することは、DRY原則を適用する1つの方法であると考えています。
抽象化。そして最後になりましたが、抽象化プログラミングはコードを非常に減らすことができます。コードを抽象化することにより、重複を減らすため、コードを再利用する機会が増えます。
プログラミング言語の理解を超えて、問題を理解し、優れたソリューションを思い付くことが、それと関係があると思います。ほとんどの問題には多くの解決策がありますが、すべてが最適であるとは限りません。異なる道路を通って都市Aから都市Bに運転できます-1時間は2時間かかり、もう1時間は2倍かかります。プログラミングでも同じです。あなたは言語を非常によく知っているかもしれませんが、例えば2ページのコードを必要とするソリューションを思い付くかもしれませんが、他の誰かがコードサイズの半分の4分の1で実装できるソリューションを見つけます。私はこれを長年見てきました。
問題を十分に理解していることを確認してください。それを分析し、解決策を考え出し、賛否両論を検討します(もちろん「解決策」は問題ごとに大きく異なります-一般的にここで言えば)。次に、選択した解決策の実装があります。言語(およびフレームワーク、該当する場合はフレームワーク)の理解が役立つ場所です。
他のすべての苦痛と同様に、問題があることを認めない場合、解決策を探すことはありません。より少ないコードがどのように見えるかを学んだとき、経験が要因になり始めます。コードを再検討するときは、コードを再利用できるか、より少ないコードにリファクタリングできるかを判断する絶好の機会です。Microsoftは、Windows 2000で2回スプールしないことで印刷速度を向上させることができました(無料デモの1つでMicrosoftの従業員から引用)。