私たちプログラマーは問題を解決するのが大好きです。 頭の中でアイデアが生まれ、指にリダイレクトされ、それによって素晴らしい解決策が生まれるのが大好きです。
しかし、時々、私たちはあまりにも速く飛び込んで、これがもたらす可能性のあるすべての結果を考慮せずにコードをクランクし始めます。 誰かがすでにこの問題を解決している可能性があり、他の誰かが作成、テスト、およびテストしたコードが既に使用可能であることを考慮していません。 入力を開始する前に、停止して考える必要がある場合があります。
たとえば、次の7つのプログラミングタスクのいずれかに直面している場合、ほとんどの場合、自分で何かを実装しようとするよりも、既存のソリューションを探した方が良いでしょう。
1. HTMLまたはXMLの解析
少なくともStackOverflowについて尋ねられた回数に基づいて、複雑さが無視されることが多いタスクは、HTMLまたはXMLの解析です。 任意のHTMLからのデータの取得は一見単純に見えますが、実際には、このタスクはライブラリを使用して解決する必要があります。 次のようなタグからURLを抽出するとします。
<img src="foo.jpg">
これは実際には、パターンに一致する単純な正規表現です。
/<img src="(.+?)">/
文字列「」がテンプレート検索結果に表示され、文字列変数に割り当てることができます。 しかし、このようなコードは、他の属性を持つタグ内の目的の値を見つけますか：
<img id="bar" src="foo.jpg">
そのような場合を処理するようにコードを変更した後、引用符の外観が異なる場合は動作します：
<img src='foo.jpg'>
または、引用符はまったくありません。
<img src=foo.jpg>
タグが複数行にまたがり、自己終了している場合の対処方法：
<img id="bar" src="foo.jpg" />
そして、あなたのコードはコメントされたタグを無視するかどうかを知っています：
<!-- <img src="foo.jpg"> -->
コードを修正およびテストしながら、コードが処理できないケースを探して別のサイクルを実行するときには、すでに適切なライブラリを使用してすべての問題を解決できます。
私はあなたに例を使って明確な話をしました：既存のライブラリを検索して勉強する時間は、自分の自転車を書くよりもはるかに少なくなります。そして、あなたが始めたときに考えさえしなかった場合に機能するように拡張する必要があります書いて。
2. CSVおよびJSONの解析
CSVファイルは一見シンプルですが、何らかの危険が伴います。 コンマで区切られた値を持つファイルは構文解析に簡単ですよね？
＃ID、名前、都市
1、クイーンエリザベス2世、ロンドン
もちろん、二重引用符で囲まれたコンマを処理する必要があるまでは：
2, JR Ewing, "Dallas, Texas"
このような二重引用符を使用して問題を解決した場合、スキップする必要がある文字列に引用符が埋め込まれているとどうなりますか。
3, "Larry \"Bud\" Melman", "New York, New York"
レコードの途中で改行を処理する必要があるまで、これも処理できます。
JSONにはCSVと同じデータ型のハザードがありますが、マルチレベルのデータ構造を格納できるという追加の問題があります。
面倒や不正確さから身を守ります。 コンマ区切りの行で処理できないデータは、ライブラリで処理する必要があります。
構造化されていないデータを構造化されていない方法で読み取ることが悪い慣行であると考えられる場合、所定の場所でデータを変更するという考えはさらに悪くなります。 「そのようなURLを持つすべてのタグを変更して、新しい属性を持たせたい」などとよく言われます。しかし、「このCSV名はSteve on Bobです。上記のように、カンマを正しく読み込めないため、危険が伴います。 すべてを正しくするには、適切なライブラリを使用してデータを内部構造に読み込み、データを変更してから、同じライブラリを使用して変更したデータを書き戻す必要があります。 その構造が期待を満たしていないようなデータの歪みのリスクはありません。
3.メールアドレスの確認
メールアドレスを確認するには2つの方法があります。 「@記号の前にいくつかの文字が必要で、その後にいくつかの文字が必要です」と言って、簡単な方法で確認できます。正規表現はこのアイデアを実装します。
/.+@.+/
もちろん、これは完全ではなく、不正な要素の存在を許容しますが、少なくとも中央に@記号があります。
または、 RFC 822への準拠を確認できます。 これらのルールは、まれではあるが依然として有効なすべてのケースをカバーしています。 単純な正規表現では、このようなスライスは生成されません。 他の人が作成したライブラリを使用する必要があります。
RFC 822への準拠を確認しない場合、行うことはすべて合理的と思われるルールを使用しますが、正しくない可能性があります。 このアプローチは妥協点ですが、最終的にRFCに頼らなかった場合、または他の誰かが作成したライブラリを使用した場合、すべてのケースをカバーしたと考えて惑わされないでください。
（電子メール検証の詳細については、 Stackoverflowを参照してください）
4. URLを操作する
URLはメールアドレスほど厄介ではありませんが、覚えておくべき厄介な小さなルールがまだたくさんあります。 どの文字をエンコードする必要がありますか？ スペースはどのように処理しますか？ +記号はどうですか？ ＃記号の後に続く文字は何ですか？
使用する言語に関係なく、URLをコンポーネントに分割し、適切に設計されたコンポーネントからURLを組み立てるためのコードがあります。
5.日付/時刻を操作する
日付/時刻の操作は主な問題であり、ほとんどの場合、すべての側面を自分でカバーすることはできません。 日付/時間、タイムゾーン、夏時間、うるう年、さらにはうるう秒を処理する際に考慮する必要があります。 米国には4つのタイムゾーンしかなく、1時間離れています。 他の世界では、物事はそれほど単純ではありません。
特定の日付から3日後に来る日付を計算することになる日付による算術、または日付形式に一致する入力文字列の検証のために、既存のライブラリを使用します。
6.テンプレートシステム
それはほとんど通過儀礼です。 ジュニアプログラマーは、大量の定型テキストを作成し、次のような単純な形式を作成する必要があります。
親愛なる＃ユーザー＃、
#product＃に関心をお寄せいただきありがとうございます...
このフォーマットはしばらくは機能しますが、出力フォーマット、数値フォーマット、構造化データのテーブルへの出力などを追加する必要があります。 限りない世話と摂食を必要とするモンスターが現れるまで。
文字列を文字列に置き換えるだけでなく、何か複雑なことをしている場合は、一歩戻って適切なテンプレートライブラリを見つけてください。 PHPで記述するとさらに簡単になりますが、この場合の言語自体はテンプレートシステムです（最近では忘れられがちですが）。
7.ロギングフレームワーク
ロギングツールは、小さなプロジェクトからモンスターに成長するプロジェクトのもう1つの例です。 ファイルへのロギング用に設計された小さな機能から、すぐにいくつかのファイルにログインするか、プロセスの最後に電子メールを送信するか、ロギングレベルなどをサポートする必要があります。 使用する言語に関係なく、長年使用され、上記の問題からあなたを救う、少なくとも3つの既製のロギングパッケージがあります。
図書館は行き過ぎですか？
サードパーティのモジュールを接続するという考えを軽視したり軽したりする前に、抗議や異議に細心の注意を払う必要があります。 通常、最初の異論は次のとおりです。「これを行うためにライブラリ全体が必要なのはなぜですか（この日付を確認し、このHTMLを解析するなど）。」私の答えは次のとおりです。トースター用のマイクロコントローラーコードを書かないでください。コード用にスペースのすべてのバイトを絞る必要があります。
速度に制限がある場合は、ライブラリの使用を避けることが時期尚早な最適化になる可能性があることに注意してください。 日付/時刻を操作するためにライブラリ全体をダウンロードすると、検証がひざまずくソリューションよりも10倍遅くなる可能性がありますが、コードが本当に良いかどうかを確認してください。
私たちプログラマーは私たちのスキルを誇りに思っており、コードを作成するプロセスが好きです。 これは正常です。 プログラマーとしてのあなたの責任は、単にコードを書くことではなく、問題を解決することであり、多くの場合、問題を解決する最善の方法はできるだけ少ないコードを書くことであることを忘れないでください。
翻訳者注：
ところで、最後の段落は、 「プログラミングスタイルを改善する方法」という記事の主要なアイデアと非常に調和しています 。
UPD1。 分類された主要なプログラミング言語ごとのツールのリスト： awesome-awesomeness （コメントでhell0w0rdによって提供されたリンク、彼に感謝します）。