*先日、プログラマーの悪い習慣について興味深いメモに出会いました。 一部の人にとっては明らかなことかもしれませんが、多くの場合、あなたはそれらに注意を払っていません。
私たちの習慣は常に進化し変化しています。 コーディングスタイルは変化しており、一般的なコードの作成方法です。 通常、これは良いことですが、時々このプロセスはいくつかの悪い習慣を通過し、それらは長い間私たちと一緒にいます。 私は長年にわたって自分自身や他の人々で観察してきた「あまり良くない」習慣についての考えを共有したいと思います。 いくつかは悪いようにさえ見えないかもしれません...
未使用のコードを投げる
時には、動作しないコードの一部を書き直すか、単にそれを少し改善したい場合があります（私たちの多くは完璧主義に努めています）。 古いコードはコメント化され、代わりに新しいコードが記述されます。 これはすばらしいことですが、作業が完了したら、古いコードを削除する必要があります！ これが行われない場合、そのようなコメントされたセクションの数は増加し始め、時間とともに他の重要な部分から注意をそらします。
たとえば、クライアントの1人が、彼の既存のプロジェクトにいくつかの新しい機能を追加するようにというリクエストを一度寄せてくれました。 コードをダウンロードしましたが、実際のコードよりも多くのコメントセクションがあることがわかりました。 これは非常に注意をそらし、コードを読みにくくします。
アプリケーションコードで使用されていない機能は、別の一般的な問題です。 かつて彼らの必要があったが、プロジェクトの開発で彼らは呼ばれることをやめた。 新しい開発者をプロジェクトに引き付けてください。彼はそれらの分析に時間を費やします。
古いコードを保存するためのバージョン管理システムがあります。削除することを恐れないでください！ 今すぐやる！
過度に一般化する
多くのプログラマーは、あなたが彼にフィードするすべてを処理できるコードを書き込もうとし、すべてのプロジェクトにこのアプローチを適用し始めます。 抽象コードの記述について十分に理解するために、多くのコンポーネント、フレームワーク、独自の3Dゲームエンジンを作成しました。 アプリケーションの90％では、このアプローチは不要です。
将来的にはコードを使用すると思いますので、できるだけ一般化して抽象化するようにしています。 コンポーネントを開発していますか？ 現在のアプリケーションで必要な状況が2つだけであっても、10の状況を確実に処理するようにしてください。
悪い知らせがあります。 他のプロジェクトでコードを使用することはほとんどありません。 本当に重要なことに集中するのではなく、プロジェクトで不要なものを作成するために、時間やクライアントの時間（彼が支払う時間）を費やします。 2番目（または3番目）のプロジェクトでクラスを使用する場合は、おそらく別のエンティティに分離する必要があります。 あなたは確かに実際のプロジェクトでこれを確信しています。
OOPに固執している
注意したいのは、私はOOPの大ファンです。このアプローチは大好きで 、理解と保守が簡単だからです。
しかし、分解によって持ち去られすぎて、問題を自分で作成する傾向がある人もいます（これは、過剰な一般化に関する前の段落と同様です）。 プロジェクトは、考えられるクラスの数に比例して増加するべきではありません。 単一の関数で構成されるクラスの作成を開始した場合、停止して考える-これは本当に必要ですか？
過度の一般化とクラスへの分割は、将来非常に悪い結果をもたらす可能性があります。 コードをいくつかのクラスに分類すると、最適化が難しくなります。 新しい関数を追加するのは難しいかもしれません... クラス間の接続について常に考えてください。本当にこのコードを別のクラスに配置する必要がありますか？ たぶんあまり意味がありませんか？
「私はそれをよりよく実現できます。」
私たち一人一人が巨大な自我を持っています。 私たちは何でも書くことができ、おそらく誰よりも良いと思う。 だから、エゴを家に置いてください！
これは、私たちが行うほとんどすべてに当てはまります。 他の人のプロジェクトに取り組む必要がある場合、コードをひと目見れば、 「ひどい！ 最善を尽くすことができます！」 統合のためにいくつかのコンポーネントを分析することにより、 「ゼロから作成する方がはるかに優れている」と判断できます。
繰り返しになりますが、悪い知らせがあります。ほとんどすべてのコードは、他の人にとってはまったくナンセンスに見える可能性があります 。 数か月にわたってプロジェクトに体系的に取り組んできた開発者は、注目に値するものを本当に知っています。 潜在的に、彼のコードを見ただけではそれを理解することはできません。 実際、コードが本当にくだらない例はたくさんありますが、すぐに明らかになります（改善するように依頼された実際のプロジェクトのコード、変数名が変更されました）。
- (void)dealloc { [A release]; [B release]; [A dealloc]; [B dealloc]; A = nil; B = nil; [self release]; [super dealloc]; }
ほとんどの場合、独自のコンポーネントを作成する代わりに、問題を解決するための優れたコンポーネントを見つけることができます。 そして、最初から作成するのではなく、コミュニティによって既にテストされているものを使用する方が常に良いです。
ちょうど見積もり：コードを書くのにどれくらいの時間がかかり、すべてが意図したとおりに機能することを確認し、結局 、 十分に何かをテストしていないことに気付きます 。 スクラッチからの開発は、トレーニングの目的にのみ役立ちますが、2週間で完了する必要のあるプロジェクトでは役立ちません。
そして、あなたが悪いコードを書くことができると信じていないなら、数年前に書いたプロジェクトを開いてください。 私はこのコードがあなたにとって悪いように見えると確信しています。
私たちは補助ツールを恐れています（コードの記述を減らします）
人々は変化に抵抗します。 私たちには正しいと信じる習慣があり、快適ゾーンから抜け出して新しいことを試すにはいくつかの努力が必要です。
私が出会った多くのプログラマーは、Interface Builderの使用が悪いことに気付きました。 率直に言ってIBを初めて知った後、私は2年間、コードを通じてUI要素を作成しました。 しかし、その後、私は自分の快適ゾーンを克服し、彼に二度目のチャンスを与えました。 この間、Interface Builderは大幅に改善され、Storyboardのような素晴らしいものが登場し、ますます便利なツールに変わり始めました。 その結果、IBは単純なインターフェースだけでなく、特定の場合に私にとって有用であることが判明しました-その助けを借りて、非常に高度なことを行うことができます。
実用的で、作業に最適なツールを選択してください 。 インターフェースをコードで実装した方がよい場合があります（たとえば、UITableViewCellを使用して迅速にレンダリングします）が、ほとんどの場合、Interface Builderはタスクを完全に解決します。
そして最後に、記述するコードが少ないほど、キャッチする必要のあるバグが少なくなります 。
おわりに
確かに、あなたが知っている悪い習慣がまだたくさんあります（これについて本を書くことさえできます）。 ここに挙げた例は最も明白ではないかもしれませんが、私は非常に頻繁に出会って、異なる人々と協力しました。 そして最も重要なことは、誰かがミスをしたとしても、それが彼が悪いプログラマーであることを意味するものではありません。なぜなら、私たち一人一人が悪い習慣を持ち、主な仕事はそれらを取り除くことだからです。 3年前に書いたコードを見て、今は気に入っていると言ってください。