良いコードを書いていることをどのようにして知っていますか？
プログラミングが大好きです。私は子供の頃からコードをいじっています。私はプロの道を行ったことはありませんが、銀行の内部取引管理/報告システムを構築したところにロープを張ったプロジェクトを含め、さまざまな雇用主向けにいくつかの社内アプリケーションをコーディングしました。私はすぐに物を手に入れ、多くの概念を理解し、コーディングのプロセス全体に安心しています。
とはいえ、自分のプログラムが優れているかどうかはわかりません。確かに、それらは機能しますが、コードはクリーンでタイトでよく書かれたものですか、それとも別のコーダーがそれを見て頭を叩きますか？ Stack Overflowで気が狂い、コーディングの試みが完全に微妙に見えるようなものをいくつか目にしました。私の雇用者は私がやったことに満足していますが、査読なしでは、それ以外の場合は暗いです。
私はピアコードレビューを調査しましたが、 NDAs または機密性の問題のため、多くの項目を投稿できません。あなたの専門家の多くは、肩越しに物事を見たり、アイデアを跳ねたりするチームメイトを持っているかもしれませんが、私のような独立したソロの人はどうですか？どのようにしてベストプラクティスを学び、コードが適切に機能するようにしますか？
それとも、期待どおりに実行され、優れたユーザーエクスペリエンスを提供する限り、「最高」であるかどうかは問題ではありませんか？
私にとって最大の手がかりは：
戻って機能を追加/変更する必要がある場合、難しいですか？変更を加えるとき、既存の機能を常に壊していますか？
上記の答えが「はい」の場合、おそらく全体的なデザインが悪いです。
変更に対応する必要があるまで、デザインを判断するのは（少なくとも私にとっては）少し難しいです（当然のことですが、一部のコードはただ不良であり、すぐにわかりますが、それでも経験が伴います）。
これは確かに私が働いているかなり標準的な方法です。
コードを表すドアはどれですか？あなたのチームまたはあなたの会社を表すドアはどれですか？なぜ私たちはその部屋にいるのですか？これは単なる通常のコードレビューですか、それともライブ開始直後に恐ろしい問題のストリームを見つけましたか？私たちはパニックに陥ってデバッグを行っているのでしょうか？大勢の人が立ち去る顧客やマネージャーは私たちの首を呼吸していますか？.
（Robert C Martin、 クリーンコード -上記の画像で開く本）
良いコードを書いているのは、次の場合です。
- 物事は賢いが、あまり賢くない
- アルゴリズムは、速度と可読性の両方において最適です
- クラス、変数、関数には適切な名前が付けられており、あまり考えずに理解できる
- 週末の休暇後に戻ってきて、まっすぐにジャンプできます
- 再利用されるものは再利用可能です
- 単体テストは簡単に作成できます
これを行う他のプログラマーはいないと言っていましたが、他の人のためにこれを含めます。
コード品質テスト：コードを見たことのない別のプログラマに、コードを読んでもらい、肩越しに各モジュールが何をするか説明してもらいます。ジャンプして何かを説明したいという強い衝動は、コードが悪化している可能性が高いです。口を閉じた状態で静かに座ることができ、多くの質問をする必要がない場合は、おそらく問題ありません。
参考までに、ピアが手元にない場合の一般的なガイドラインをいくつか示します。それらは絶対的なものではなく、単に「におい」です。
良い兆候
- メソッドは非常に短くなる傾向があり、理想的には単一のタスクを実行します。
- メソッドの本体を確認せずにメソッドを呼び出すのに十分な情報があります。
- 単体テストは簡単に作成できます。
悪い兆候
- 他のメソッドに分割されない2〜3つのサブタスクで構成される長いメソッド。
- メソッドは、インターフェース以外の方法でデータを共有します。
- 1つのメソッドの実装を変更する場合（インターフェースは変更しない）、他のメソッドの実装を変更する必要があります。
- たくさんのコメント、特に長々としたコメント。
- 「将来の柔軟性」を提供するために、アプリケーションで実行されないコードがあります
- 大きなtry/catchブロック
- 適切なメソッド名を思い付くのに苦労している、またはそれらに「OR」と「AND」という単語が含まれている（例：GetInvoiceOrCustomer）
- 同一またはほぼ同一のコードブロック。
コードのにおい のより長いリストを次に示します。これも役立つはずです。
個人的には、コードを忘れたときだと思います。言い換えると：
- バグはほとんど発生しません
- それらが発生した場合、他の人々は私に何も尋ねることなくそれらを解決します
- さらに重要なのは、誰もever自分のコードについて何も尋ねないことです
- 人々はそれを読むときに高いWTF /分の割合を持っていません
- システムの多くの新しいクラスが私のクラスを使用し始めます（high fan-in、Steve McConnellが呼び出します）
- コードは、私を呪うことなく、必要に応じて/必要に応じて簡単に変更および/またはリファクタリングできます（たとえ私であっても、自分を呪います！）
- チームの全員に合っているように見える適切な抽象化の量を推測するときも、私はそれを愛しています
1年前に作成したファイルを開いて、クラスへのすべてのニースの追加を見ると、それはいい感じですが、modifications、and-非常に高いファンイン！ :)
もちろん、これらはmeが私が良いコードを書いているように感じさせるものですが、実際にはそれを知るのは本当に難しいです。私の推測では、人々があなたのコードをからかう以上にあなたのコードをからかい始めるなら、それは心配する時です。
私には3つの黄金律があります。
- コードのブロックをコピー/貼り付けせざるを得ない場合、私は何か間違っています
- コード全体を頭の中に入れられない場合、何か問題があります
- 誰かが飛び込んで私のコードで迷子になった場合、私は何か間違ったことをしています
これらのルールは私にいくつかの本当のアーキテクチャの改善をするように導き、最終的には小さくてクリーンでメンテナンス可能なクラス/メソッドになりました。
これはすばらしい質問です。質問をしてもらったことを感謝します。
まず、ときどき心を吹き飛ばされるのはいいことです。謙虚さを保ち、あなたが知らないすべてを知っていること、これよりもあなたに優れた人がいること、そしてあなたにより良い何かを与えることをあなたに認識させ続けます努力する。
さて、良いコードを書いていることをどのようにして知っていますか？
- クラスがそれぞれ、単一の非常に明確に定義された目的を果たし、他の明確に定義された目的を持つ他のクラスから分離されている場合。
- メソッドが短い場合-理想的には50行以下、確かに100行以下-とその名前は、それらが何をするかを明確に定義します。メソッドは、その名前が意味すること以外は何もすべきではありません。 100行を超えている場合、またはタブが非常に遠い場合は、おそらく独自の関数に何かを引き出すことができます。
- コードが何かを行うための1つの方法を提供する場合-ジグまたはザグのオプションを提供せず、代わりに、ユーザーが送信する可能性があるアクションの各コースに対して単一の線形パスを提供する場合。
- クラス間の結合を減らすために合理的にできるすべてのことを実行したら、そのため、クラスAがクラスBに依存し、クラスBが削除され、その場所にクラスCが配置されている場合、クラスAに変更を加える必要はほとんどありません。クラスAは、外の世界。
- クラス、メソッド、変数の名前が読み取られ、コードに出くわした人なら誰でもすぐに理解できる場合-'packetSize'がはるかに簡単に読み取れる場合は、 'pktSize'は必要ありません。
他の人が言ったように、基本的に、オブジェクト指向プログラミングを行っていて、糸のもつれをほどいて巻き戻しようとするような何かを変えるときが来た場合、コードはオブジェクト指向の原則に従っていない。
これについてもう少し詳しく知りたい場合は、本 "Clean Code"、 を強くお勧めします。初心者にもエキスパートにもお読みいただけます。
私の主なポイントは次のようになると思います：
- 読みやすさ（あなたとあなたのコードを調べた人のために）
- 保守性（変更が簡単）
- Simplicity（それが必要ない場合は複雑ではありません）
- 効率（もちろん、コードは高速に実行する必要があります）
- Clarity（コードが自明である場合、ほとんどの場合、コメントの必要はなく、メソッド/プロパティに名前を付けるなど、慎重に、コードダウン、コードのブロックをコピーして貼り付けないでください）
Designをこのリストに入れていません。プロジェクト内で一貫している限り、デザインパターンに固執することなく、優れたコードを書くことができると思います。 。
このトピックに関する優れたMSDN記事： 優れたコードが優れている理由
お気に入りの言語で優れたオープンソースプロジェクトを探して、それらが何をしているかを確認してください。
たとえば、 sendmail は、 spaghetti code と書いたかどうかを確認する場所です。 sendmailのせいではありません。たった20年しか経っていないので、そこにはたくさんのくずがあります。したがって、コードがsendmailコードのように見える場合、おそらく間違った方向に進んでいます。
私は最近は Postfix を見ていませんが、おそらく非常によく設計されています。したがって、もしあなたのものがpostfixのように見えるなら、あなたは正しい軌道に乗っています。
私が子供の頃にプログラミングを始めたとき、インターネットはなく、あなたは何も比較することができませんでした。しかし、比較のために表示できる膨大な数のコード行が用意されたので、正しく実行しているかどうかを理解する必要があります。
LinuxカーネルがLinuxカーネルであるからといって、それが適切に記述されているとは限りません。心に留めておきます。
これは、過去5か月間に大学のプログラミングの世界から業界に移行してからの私の経験です。
- 使いやすさは非常に重要なので、ユーザーインターフェイスを設計するためだけに人々にお金を払っています。プログラマーは、UIの設計をよく理解しません。
- 機能させるだけでは十分ではないことがわかります
- 最適化は、実際のシナリオではより重要になります。
- 問題に取り組む方法は千通りあります。ただし、多くの場合、データベース認証、トランザクション、ファイル I/O 、リフレクションなど、アプローチのパフォーマンスに悪影響を与える可能性のある、あまり知られていないわずかな要素をアプローチが考慮していませんランダムな少数。
- 保守性はコーディングの非常に重要な側面です。コードが非常に最適化され、非常に密集しているからといって...それがセクシーであるという意味ではありません。時々それは単に「ヒーローコーディング」とラベル付けされています。
- 設計スキルは、固有のものではなく、学習されます。きっと頭の中に子供がいると思いますが、一般的に言えば、現実の問題に関する堅実な設計は、時間、調査、そして最も重要なこととして、上司からの知識の提供を通じて練られています= P
- ドキュメントは便利なものではなく、必要なものです。
- 同じことが 単体テスト にも当てはまります（これは確かに会社によって異なります）。
ぜひオープンソースプロジェクトをご利用ください。他のプログラマーの利益と一緒に作業する場合、実際にどれだけ知っているかを確認する機会が得られます。オープンソースプロジェクトは、おそらくあなたのバックグラウンドに基づいて調べる最良の方法です。
良いコードを読んで、なぜそれが良いのかを理解してください。悪いコードを読み、なぜそれが悪いのかを理解してください。平凡なコードを読んで、どの部分が良いか、どこが悪いか、どこが良いかを理解してください。独自のコードを読んで、同じようにしてください。特に例を見て、なぜ彼らが彼らのやり方でそれらを書いたのかを理解する目的で、いくつかの（評判の良い）教科書を取り上げます。ほとんどの場合、悪い部分と良い部分の違いがわかるまでコードを読み、独自の「Wtf？」を実行できます。テスト。
一般的に優れたコードを認識できるようになるまで、優れたコードを記述しているかどうかはわかりません。頭に何かがあったからといって、それがうまく書かれているとは限らない...
（「他の人のコードを読む」はこのスレッドのいくつかのコメントでポップアップしましたが、私はそれが独自の投稿に値すると思いました）
コードと設計の観点から、保守性について他の人がすでに言っていることが好きです。
また、安定性も見てみます。生産サポート統計を見てください。基本的な機能のように思われるが、多くの人がソフトウェアの使用方法を理解できない、またはニーズを満たしていないことに気づいているサポート対応の高いインスタンスを取得している場合は、何か問題があります。
もちろん、本当に無知なユーザーもいますが、時間の経過とともに、破損、混乱、または重大な機能変更要求のレポートが引き続き表示される場合は、次の1つまたはすべてが当てはまることを示しています。
- 要件が破られました
- コードが壊れている
- アプリケーションは直感的ではありません
- 開発者はユーザーのニーズを理解していませんでした
- 誰かが品質より納期を強く要求した
- 誰かがうまくテストできなかったか、何をテストすべきかを知りませんでした
他の誰かに1日仕事を引き継ぐよう依頼し、その日の終わりに彼または彼女がどれほどストレスを感じているかを確認してください;-)
ドキュメント化とクリーンアップが苦手です-だから私はそれをチェックする方法です。
散文のように読めるとき。
特定のコードについて：
それが機能し、保守可能である場合（優れたプラクティスを選択）、それは優れたコードです。
時間をかけて開発者として：
良いとは、言語ドメイン、問題ドメイン、現在のトレンド、そして最も重要なのはあなたの経験に対して、相対的で動的な用語です。この連続体の「良い」酸テストは単にあなたの前の仕事を振り返っているかもしれません、そしてあなたが「ため息と言ったら私は本当にそのようにそれを解決しましたか？」その後、あなたはまだ成長していて、良いコードを書き続ける可能性が高いです。
振り返って完璧なコードを見ると、どちらか-完璧であり、停滞しているリスクがあり、すぐに優れたコードの作成をやめる可能性があります。
良いコードは人にとって主観的です。たくさんの本を読んだり、セミナーに行ったり、さまざまなコーディング技術を使用したプロのコーダーは、おそらくコードを細断処理するでしょう...しかし、コードは、コーダーの経験レベルがどこにあるかを本当に示していることがわかりました。私にはそれは歴史書や自伝のように読みます。それは、コーダーが当時知っていたこと、または彼/彼女が制限されていたツールです。
自問してみてください...マイクロソフトが何かを正しくするために3つのバージョンのソフトウェアを採用するのはなぜですか？彼らは以前のバージョンで犯した間違いを常に修正しているからです。私のコードは改訂後は常に良くなることを知っています。確かに、私は初めて完璧なコードを書く人がいるでしょう。あなたがそれを信じるなら、私にはあなたを売るための沼地があります...
概念を理解すると、物事が簡単になります。私にとって、何か新しいことを学ぶことの始まりは「私はそれを働かせることができますか？」、そして次のステップは「私はこのようにそれを行うことができるのだろうか...」です。 「どうすれば速くできるか」...
もしあなたがプログラマーになりたいなら、あなたはそれに飛び込んで、ただそれをしなければなりません。それは多くの仕事を必要とし、正直に言うとそれは決して完成できない芸術作品のようです。ただし、カジュアルな趣味になりたい場合は、問題なく機能します。あなたはあなたの環境に適応する必要があります。コードレビューを行う方法がない場合、無知は至福です=）
しかし、何があっても...誰もが自分の意見を持つことになります。確かに、物事を行う正しい方法と間違った方法があります...しかし、ほとんどの場合、間違った方法よりも、より良い方法がほとんどあることがわかりました...
とはいえ、自分のプログラムが優れているかどうかは決してわかりません。確かに、それらは機能しますが、コードはクリーンでタイトでよく書かれたものですか、それとも別のコーダーがそれを見て頭を叩きますか？
質問別のコーダーがあなたのコードについてどう思うか考えましたか？
一部の場所では、コードリポジトリに受け入れられる前に、コードmustが別のコーダーに受け入れられる「ピアレビュー」を使用しています。
私見、それ自体「良いコード」はありませんが、「良いソフトウェア」はあります。
私たちが何かに取り組んでいるとき、私たちの仕事には多くの制約があり、他のプログラマーの「良いコード」の標準から外れるコードを生成することがよくあります。
「良いコード」は維持しやすいコードであると言う人もいるかもしれません。私にとってのこの発言に対する反論は、どれほど簡単ですか？ 「良いコード」の標準のために、コードを200％程度維持する必要があるのでしょうか。それをそれほど維持する必要がないことがわかっているとしても、申し訳ありませんが、そうは思いません。
実際、私は私のチームで「良いコード」を本当に宣伝している人です。私は彼らのコードを見るたびに、彼らが完璧なコードを書いていることに気づかなかった。しかし、私は彼らが本当に仕事を成し遂げたことを認めなければならず、また私たちの会社のニーズのためにそれを適切に維持することができなければなりません。もちろん、このアプリケーションにはバグがある場合がありますが、私たちは間に合っただけで、顧客とユーザーを満足させ、競合他社よりはるかに前の位置にいる会社を確保しています。
したがって、「良いコード」は、必要なものを生成するコードであると言えます。本当に必要なものを考え、それを使用してコードを評価するだけです。
決して。
「良いコード」とは、まだ改善の余地がないコードだけです。 Jeff Atwoodによる ：
世界には、見事で完璧なコードを作成できるプログラマーが少数います。私たちの残りのすべてができることは、時間の経過とともにソフトウェアの不快感を減らし続けることです-継続的な改善のプロセス
ちなみに、「 十分な設計は不十分な設計を意味する 」となる場合があるため、完璧に到達する必要はありません。
誰かがあなたのコードを見て経験するのに勝るものはありませんが、自分でコードを評価して改善するのに役立つリソースがいくつかあります。 Martin Fowlerの Refactoring （または website ）を見てください。 SutterとAlexandrescuの C++ Coding Standards は、C++で記述している場合に適しています。そこにある推奨事項の多くは言語にとらわれませんが、他の言語では他の同様の本を推奨できるかもしれません。テスト駆動型開発は、開発者がいくらかの品質チェックを提供し、テストの作成が困難になると、コードがおそらく再構築を使用する可能性があることを知っているため、ソロ開発者にとって非常に役立ちます。
他のいくつかの兆候は、よりプロセス指向です。それらは通常、より良いコードにつながりますが、直接にはつながりません。これには、ソース管理の使用、ライブサーバーで直接開発しない自動ビルドプロセス、バグ追跡ソフトウェアの使用などが含まれます。
うまくコーディングするために、プログラムが非常に機能的で迅速であることを確認することを目指しています。ファイル、データ、機能、抽象化がかなり明白になるように、すべてが適切な場所にあることを確認してください。
この後、私はそれをテストにかけました。一般的にコンピュータにかなり精通していない人を見つけ、主要なコードパターンのいくつかを説明してみてください。彼らがちょっとそれを読むことができるならば、すごい。よくやった。
ほとんどの場合 [〜＃〜] kiss [〜＃〜] だけで、何もクラッシュせずに革新的になるようにしてください。また、コードに戻って、コードの改善とメンテナンスを行う時間についても詳しく説明しますが、それはかなりうまくカバーされています。
FindBugs 、 [〜＃〜] pmd [〜＃〜] などのコード分析ツールを使用できます。これにより、コードの品質に関する情報が提供されます。
あなたのコードをリリースし、何人かがそれをいじって、それがいつも想定されていることを確実に実行するようにします。または、必要に応じて、仕様を設計し、それらの仕様をすべて満たしていることを確認してください。これらのテストの1つまたは両方に合格した場合、コードは「今のところ適切」です。ほとんどの人にとって、あなたのコードは素晴らしいものにはなりません。なぜなら、あなたは1年後に戻ってきて、「なぜ私はやったのかと思うでしょう」 これのようにうまく機能しましたか？」
より多くの経験があれば、より良いコードが得られます。しかし、同じ習慣を続けていると、同じ落とし穴に陥ってしまいます。これは、「慣行はpermanent。あなたが継続的に正しい方法で物事を行う場合（コードをテストして、それが想定されているように機能することを常に確認するなど）、その後は改善されます。あなたが継続的に間違った方法で物事を行う場合（たとえば、特定の状況でコードをテストしない、またはバグが発生する可能性のある場所を認識できないなど）は、コードに頑固になるだけです。