プログラムされたトピックに関する知識なしでクリーンなコードを書く
文書化が不十分でまったく新しいものを扱うときに、クリーンなコードを作成するのに役立つヒントはありますか？
2回目に何かを書いているときに、クリーンなコードを書くのは簡単です。しかし、通常、私たちが取り組んでいる問題は私たちにとって新しいものです。
十分に文書化されていないライブラリを使用しているとしましょう。最初に適切に設計された実装を作成しましたが、コンパイルした後、機能しないようです。フォーラムで簡単な修正を見つけて貼り付けます。それでも機能しないため、貼り付ける別のコードスニペットをすばやく検索しています。クリーンなコードがインターネットから取得した迅速な解決策でいっぱいになったしばらく後。
最終的に、プログラムが機能し始めます。コードをもう一度見てみると、それは不愉快に見えます。これを機能させるために適用した「一時的な」ソリューションでいっぱいの大きな手順の1つです。 2つの選択肢があります。リファクタリングされたコードが機能することを期待して、すべてを最初から書き直すか、機能しているのでそのままにしておきます。ほとんどの企業では、少なくともライブラリのチュートリアルがリリースされるまで、2番目のアプローチを採用しています。
追加するすべての行をデバッグする可能性がない場合があります。また、適切にドキュメント化されていないライブラリを使用している場合、通常、コードのどの部分がプログラムを機能させたかを推測する必要があります。実際のデバイスでプログラムを起動する必要があるため、デバッグに非常に時間がかかるエンジニアリングソリューションを提供する場合、最大の問題が発生します。
ライブラリがどのように機能するかわからない場合は、製品コードをいじらないで、コードが機能するようになるまで、コードスニペットの大まかな推測を投げてください。これは専門外のカウボーイコーディングです。
代わりに、exploration testsと書いて、libが実際にどのように機能するかを調べ、十分な自信があるときに何が起こるかを理解したら、本番用コードを記述します。これにより、テストで「一時的な」ソリューションを維持することが強制され、製品コードをクリーンに保つのに役立ちます。さらに、テストメソッドに適切な名前とテスト対象の説明を付けてください。そうすると、テストは例として不足しているドキュメントになります。
それ以外にも、@ DaveGauerの回答にはたくさんの良いアドバイスが含まれていると思います。彼らはあなたのコントロールを使い果たす前に、物事をすぐにクリーンアップする態度を開発しようとする必要があります。 「実験的コード」を本番コードから分離すると、これが役立つ場合があります。
まず、あなたが行くにつれて常に書き直します。大きなリファクタリングを待つ必要はありません。 すぐに次の問題に移らないでください理解できたら。一時停止して、ソリューション全体の全体像を振り返ります。
次に、コピーアンドペーストをあまり使用しないことを検討してください。確かに、他の人の例を使用してください。しかし自分で入力。変数名とコード構造を変更して、プロジェクトのスタイルに合わせます。変数の名前を変更するのを忘れたため、あなたはコードを壊します。それは少しかかります。しかし、入力した内容を理解すれば、プロジェクトによりよく適合し、コードの所有感が大幅に向上します。
2つの選択肢があります。リファクタリングされたコードが機能することを期待して、すべてを最初から書き直すか、機能しているのでそのままにしておきます。
3つ目の選択肢があります。あなたが書いている小説の章のように、新しいコードの塊を上から下に読んでください。フィクションエディターのように考えてください。わかりやすくするために変更を加え、間違いがないか確認します。関数は十分小さく、1回で適切にリファクタリングして全体を理解できるようにする必要があります。
技術的負債はひどく意気消沈するものです。知っている。
また、誰もあなたに正しいことをする時間を与えません。自分で主導権を握らなければなりません。必要に応じて、コードを読みやすく修正する時間を確保するまで、問題が解決したことを誰かに知らせないでください。それはテストにも当てはまります。