コードを減らし、より考える: コードが増えると問題が増える_PHP チュートリアル

約 1 年前、私は PHP Web プログラミング ガイドライン、つまり MicroPHP マニフェストを書きました。しかし、さまざまな言語に共通のプログラミング/コーディング規則があることがわかりました。これは、さまざまな種類のプログラミング言語に慣れることで得られたものかもしれません。

ここでは私が覚えておきたいルールをいくつか紹介します。

フレームワークではなく言語を学びましょう

私は PHP、Python、JavaScript とそれらを使って何かを作るのが好きです。しかし、私は Symfony、Django、または jQuery の開発者ではありません。

それは大きな違いだと思います。 JavaScript の代わりに jQuery プログラマーになることも可能ですし、Python の代わりに Django プログラマーになることも可能です。実際のアプリケーションには、確かに価値があり非常に実用的なツールやフレームワークがたくさんありますが、フレームワークの使用方法を 1 つしか知らない場合、私が言いたいのは、業務に適したツールのみを使用すると、実際にはタスクにいくつかの制限が生じるということです。 . をチェックして、使用しているツールとフレームワークを確認できます。私の経験から言えば、一部の複雑なフルスタック フレームワークは、特に柔軟性とパフォーマンスの点で、あまり適切なツールではありません。

言語の学習に集中すると、プログラマーはより柔軟になります。フルスタックの複雑なフレームワークは、製品を迅速に構築するのに役立ちますが、フレームワークの範囲外のソリューションが必要な場合は、役に立たなくなります。私は開発に対して「プラグ アンド プレイ」アプローチを採用することが多く、ニーズを満たすライブラリやプラグインを見つけたら、それを製品に実装します。これによりアプリはすぐに公開されるかもしれませんが、その先には多くのハードルが残されます。

さらに、フルスタック フレームワークの学習は、新しい言語の学習と同じくらい複雑です。多くの場合、複雑なアーキテクチャと用語があり、一部の部分は他のフレームワークやツールに適用されません。もちろん、フレームワークにも多くの利点がありますが、言語が実際にどのように機能するかを理解するには、言語を理解する必要があることが前提となっているため、私は言語自体についてさらに学習し、学んだスキルを他の言語に適用することに時間を費やしたいと考えています。図書館で。

小さなモジュールを構築する

コードの一部の小さな単位はプログラマーにとって素晴らしく、喜ばしいものです。単位が小さいほど理解しやすく、混乱しにくいため、長くて複雑なコードの記述を制限することが重要です。

したがって、可能な限り要件に近い小さなモジュールを意図的に構築します。これらは問題の一側面を単に解決するだけの独立したブロックである必要がありますが、組み合わせると多くの大きくて複雑な問題を解決できます。

このような単純なモジュール コードを使用すると、バグを修正するのが非常に簡単になります。これらの個々のブロックは理解しやすいため、一目でその目的がわかります。モジュールが自己完結型であるかどうかをテストするのが簡単です。

コードは少ないほど良い

Biggie Smalls の言葉を言い換えると、「コードが増えれば増えるほど、問題も増えます」です。

誰もが管理の少ないコードを好みます。機能モジュールのコードをレビューするとき、コードが多くて乱雑だと、逆にモジュールのコードが簡潔でわかりやすいと第一印象が悪くなります。とても幸せになるでしょう。より一般的に言えば、コードが増えれば増えるほど管理が難しくなります。コード ベースの検索に時間がかかり、ファイル ナビゲーションの表示にも時間がかかり、ファイルの追跡も難しくなります。処刑など

コード レビューと使用するツールは、主にコードの量を削減するために使用されていることに気づきましたか。それらの巨大なライブラリと長いコードは、人々の脳のバッファから溢れ出ているようです。長いソース コードをトレースしているときや、複数のソース ファイルを飛び越える関数を実行しているときにイライラします。これが、構文を色分けするエディターが大好きな理由であり、一貫した間隔を維持することが非常に役立ちます。

管理するコードが少ないことを好むことに加えて、私はコードを可能な限り単純化しようとする開発者もサポートします。プログラマーは、アプリケーションで使用されるコードに対して責任を負います。自分が作成した部分だけでなく、アプリケーション内のコードのすべての行に対しても責任を負います。これは、これらのアプリケーションに発生するバグやセキュリティの脆弱性に対して責任を負うことも意味します。

理解できないコードをプログラムで使用しますか?これは、他の人のコードを決して使用しないという意味ではありません。率直に言って、世界には優れたプログラマーがたくさんいますが、アプリケーション内のコードのすべての行が重要であるため、他の人のコードを適用する場合は、コードを理解する必要があります。コーディングするときは考えることを忘れないでください 自分自身に不要なトラブルを引き起こさないように、最小限のコードを書く背後にもっと考える必要があります。

シンプルで便利で読みやすいコードを作成します

理解しやすいコードを作成し、コードを減らしてよく考えることで、機能を迅速に完了でき、生産性が向上します。

もちろん、コードが検証可能であることも必要です。そして私は、シンプルなモジュール化されたコードの方がテストしやすいと常に信じてきました。

コードが持つべきもう 1 つの特性は可読性です。コードは明確なセマンティクスを備えた簡潔なものである必要があります。コードを書くとき、他のプログラマがそれを初めて見たときに理解するのにどれくらい時間がかかるかを考えます。それとも、1、2 か月以内に自分で理解できるようになるでしょうか?プログラミングの有名な格言にあるように、どんな愚か者でも機械が理解できるコードを書くことができ、優れたプログラマーだけが人間が理解できるコードを書くことができます。それらがどのように機能するかを理解するのに費やす時間が減れば減るほど、より多くのことを成し遂げることができます。

しかし、これらのルールを守る人はほとんどいませんし、守っていると言ったら嘘になります。時間の制約があっても怠けることがあって、複雑で理解しにくいコードを書いたり、レビューされていないライブラリを使用して特定の機能を実装したりすることがあります。シンプルで明確なコードを書くことは短期的には難しい場合があります。より多くの規律と継続的な技術評価が必要です。特に時間に制約のあるプロジェクトは実装がより困難になります。

しかし、時間と労力を費やすと、それが自分だけでなく、他のチームメンバーにとっても報われることがわかります。

出典: コードが増えれば問題も増える

http://www.bkjia.com/PHPjc/735071.htmlwww.bkjia.comtru​​ehttp://www.bkjia.com/PHPjc/735071.html技術記事約 1 年前、私は PHP Web プログラミング ガイドラインのセットである MicroPHP マニフェストを書きました。しかし、さまざまな言語間に共通のプログラミング/コーディング規則があることがわかりました。これは、私がさまざまなクラスに精通しているためかもしれません...

。