一歩下がって、新鮮な目でコードを見る方法は？
私は昨年、1人のチームでリッチクライアントアプリケーション（35,000以上のLoC、それだけの価値がある）を開発してきました。それは現在安定しており、生産中です。ただし、プロジェクトの最初は自分のスキルが錆びていたので、コードに大きな問題があることは間違いありません。この時点で、ほとんどの問題はアーキテクチャ、構造、および相互作用にあります。簡単な問題は、アーキテクチャ/設計の問題でさえ、すでに取り除かれています。
残念ながら、私はこのプロジェクトに多くの時間を費やしているため、プロジェクトの外側で考えるのに苦労しています。設計に深く埋め込まれた、または本質的に存在する欠陥を確認するために、新しい視点からアプローチするのです。
どうすれば頭の外に出てコードの外に出て、新鮮な外観にしてより良くすることができますか？
これにアプローチする方法：
- テクノロジーとビジネスの問題に精通している人を見つけ、それについて話し合います。これは一人のチームでは難しいかもしれませんが、一般的には最良のオプションです。
- しばらく別のプロジェクトに取り組んでください。これも難しいかもしれませんが、1週間の休憩を取っても、新鮮な視点を得ることができます。
- オープンソース製品など、類似のプロジェクトまたは製品を探します。コードをコピーしないように注意してください。ただし、まったく異なる方法でアプローチした可能性があります。
- 新しい言語、ライブラリ、フレームワークを学びましょう。関係するテクニックは、同じ問題に異なる方法でアプローチする方法についての洞察を与えるかもしれません。
- デザインや言語/フレームワークについての良い本/ブログ/雑誌を読んでください。どのレベルのスキルかはわかりませんが、このサイトの他の回答には多くの選択肢があります。
対処したい具体的な例がある場合は、ここに投稿してください。
ラバーダックのデバッグ ： コード、モジュール、または機能に腰を下ろして、大声で説明します。何かが間違っている、愚かである、または単に明白ではないように聞こえる何かを自分で見つけたら、調査する問題としてそれを書き留めます。
学習を続け、スキルを伸ばしてください。知らないことを知るのは難しいですが、それを見ると、「あは」の瞬間があなたを襲います。他の言語やデザインパターンを学ぶことから来るかもしれません。
変更を求められます。コードの一部がそれほど柔軟ではなく、多くの再作業が必要になる場合があります。最初はすべてを考えることができないため、これは必ずしも失敗ではありません。
ユーザーは不平を言うようになります。すべてが素晴らしいと思ったとき...
短いメモリが役立ちます。 1週間前に何かが変わった「馬鹿」について不平を言うことは知られていますが、ソース管理からそれが私であることがわかりました。
最初の良いステップは、改善できるコードを特定することです。ソースコントロールで、最も頻繁に変更されるファイルを探します。どのコードが最も扱いにくいですか？最もバグが多いコードはどれですか？どのような変更がコード全体に波及効果を引き起こしますか？この段階では、あなたは知る必要はありませんなぜコードは面倒ですそれそれは面倒です。
作業する領域を特定したら、問題が実際に何であるかを理解してください。設計上の問題を分類するために体系的なアプローチを取る本があります。マーティンファウラーのリファクタリング、ハーブサッターのC++コーディング基準、ロバートマーティンのクリーンコードなどを見てください。あなたは客観的な方法であなたのコードを見ます。
問題が何であるかを特定したら、それを修正するためのさまざまな方法を試してください。たとえば、違反したルールが「継承よりも構成を優先する」である場合は、構成を構成に変更して、どのように感じるかを確認します。
明らかに、他の誰かにコードを見てもらうことは役立つかもしれませんが、あなたが大いに他の誰よりもコードが引き起こす種類の問題に精通しているので、あなたが考えるほど必ずしも役立つとは限りません、そしてデザインの背後にある理由。自分のデザインを客観的に評価するいくつかの方法を学ぶことは、大きな利益をもたらします。
別の人にあなたのコードを見てもらいます。他の人がそれを見ることができない場合は、他の人に見せるように、インタラクションの完全な説明を書きます。自分の決定を他の人に説明しようとするプロセス（たとえそれが単なる練習であっても）は、なぜあなたが特定の方法で物事を行っているのかを考え、ロジックのあらゆる穴を見つけるのに役立ちます。
私はこの状況をよく知っています。私がそのように動けなくなったとき、私はプロジェクトについて別の視点をとろうと試みます。
1.）ユーザー/顧客の視点-フィードバックを使用する
残念ながら、コード化された方法でアプリケーションを使用しているため、独自の欠陥を確認できない方法でコードに巻き込まれています。人々がそれをどのように使用するかを見て、最も直感的なユーザーガイダンスがどうなるかを考えてみてください。 UIプロトタイプをいじってみましょう。これは楽しいように見えますが、使用ロジックを変更するだけでコードの大部分を再コーディングする必要があることがわかった場合は、再設計サイクルを開始するときではありません。
2.）コードの機能分析を行い、コードを視覚化する
一部のIDEとフレームワークは、たとえばUIとバックエンドコードの混在。これを起こさせれば、いつかは依存関係が曖昧で壊れにくいため、コードベースを維持することが困難になるという状況に直面するでしょう。特に、UIコードを他のコードと混在させると、スパゲッティコードや冗長機能が発生する可能性があります。コードを次のような機能ブロックに分割します。データベースクラス、通信クラス、UIクラス、コアクラスなどを使用して、機能ブロックに名前を話します。次に、グラフィカルツール（マインドマッピングツールを使用）で機能を視覚化して、さまざまなプロジェクトで巨大なコードブロックを再利用でき、それらを新しいバージョンに置き換えずに、構造が論理的かつモジュール式であるかどうかを確認します。大きな痛み。
私の経験でこれを行うための最良の方法は、クラス間のすべての依存関係とコードからの呼び出しを視覚化するドキュメントを作成することです。その結果、インターフェース設計が視覚化されます。このコードマップが完全なclusterf ***のように見える場合は、実行するときではありません。まだ発生していない場合は、コード構造を表す適切な命名規則を検討する必要があります。これは、コード構造を呼び出す方法や機能について考える必要がないようにしています。
3.）品質保証への一般的なアプローチを使用する
私のお気に入りはFMEAです。コーディングに関しては、これは過去に何が問題であったかを分析するだけでなく、何が問題になる可能性があるかについて考えることも意味します。かなり一般的な例は、突然切断されたネットワーク接続です。これを行った後、データ損失、クラッシュ、誤った計算などの結果によってエラー条件を分類し、ユーザーへの影響を判断できます。まだ完了していない場合は、合理化されたエラーと例外のクラスとルーチンを定義することで、コードをクリーンでまっすぐに保つことができます。最善の方法は、他の何かを書き始める前に、コードのすべての新しい平和にそれらを実装することです。 （まあ、私はいつも自分自身でこのアドバイスに従うことは有罪ではありません。）
さらに、自分のコードの「改善提案リスト」を生成して頻繁に更新するのにも役立ちました。 （正直に言うと、私のプロジェクトにはまだまだ誇りに思っていないコードがたくさんあります。）また、APIドキュメント、開発者会議、または開発者雑誌からベストプラクティスコードを収集して確認するように時間をかけます。
この時点まで、コードに触れる必要はありません。何が問題なのかを認識し、コードを改善する方法を定義する方法を見つけるだけです。
最後に、古いおならから毎日の仕事のためのいくつかのヒント。食べられる量を超えて噛まないようにしてください。これは、きれいなコーディングのためにあまりにも多くのプレッシャーにつながります。あなたはめったにそれを正しく行う時間が取れませんが、後で欠陥を修正するために時間をかける必要があります。
暫定的なソリューションほど長続きするものはありませんが、壊れた場合、時間内に修正するのが遅くなることがよくあります。例としては、私が何かを動作させるために使用した厄介なハックや奇妙な例外があります。基盤となるフレームワークまたはOSの欠陥。そして、欠陥が修正されるか、新しいバージョンは単にAPIを削除します…
行き詰まって回避策を見つけざるを得ない場合は、コメントを作成し、時々確認する必要があるメモを取ってください。通常、何か新しいことを学ぶことで、どんどん良くなっていきます。より良い方法を見つけたら、できるだけ早く実装してください。それ以外の場合は、回避策の回避策と例外の例外をいつかコーディングする可能性があります。 （あなたの中で罪のない人、彼に私に最初のバイトを投げさせてください。）
細かいことを気にしないでください。
誰もがより良いコードを書くことができました。私たちは物事を迅速に行い、それから数週間後に、それがより効率的に行われたかもしれないことに気付きました。ポイントは、コードの90％がおそらく十分であるということです。
バグログを調べて、問題を引き起こしている可能性のあるルーチンを見つけます。バグを見つけたら、コードを確認して、コードをより効率的にする方法について考えることもできます。ほとんどの場合、バグ自体を修正する以外に、目立った改善を行うことができないことに気付くでしょうが、時には、何かを行うためのより良い方法があることに気付くでしょう。
ユーザーと話し合い、UXまたは速度の問題など、問題のどこに気付いているかを確認します。これらの問題を修正し、コードの改善を試みます。
ある時点で、コードがもろくなりすぎて、必要な変更を加える方法がないことに気付くでしょう。次に、APIまたはテスト駆動開発を使用して、システムをより柔軟にする方法について考えます。多くの場合、大きな変更を加えることなく、これらのAPIをコードに挿入し始めることができることがわかります。他の場合では、コードを改善する努力はそれだけの価値がないことに気付くでしょう。
段階的な変更は難しい場合があります。目標は、必要がない場合にコードベースを完全に書き直すことではないことです。確かに、あなたは今1年前よりも優れたプログラマーですが、今持っているものは今働いているはずです。今から5年後、ジュニアプログラマーがレガシーコードについて不満を言うとき、彼らは修正しようとする必要があります。ただ笑ってうなずき、あなたがそれを書いたことを認めないでください。
あなたがチームに加わることができる会社を去り、見つけることを考えましたか？孤立したチームや停滞したチームの中で、開発者は専門職が提供しなければならない多くのことを見逃していることを非常に強く感じています。
ピアレビューにより、すでに頭の外にいる誰かがアドバイスを与えることができます。 Stack Exchange Code Reviewは、自社に特に固有のものではないコードをレビューのために公開するのに適した場所です。おそらく巨大なブロックを処理することはできませんが、多くのプログラムは多くの単純なコードと単純ではない他のいくつかのコードで構成されており、多くの問題を引き起こします。典型的であるが、多くの場所で繰り返され変更されたコードの例がある場合、それはまた良いレビュー候補になるかもしれません。たとえば、メッセージをフォーマットする場合は、通過するすべてのメッセージを確認するように依頼せず、かなり複雑なメッセージの例を1つだけ送信します。
自分のコードをもっと客観的にしたい場合は、それをコーディング標準と比較し、静的または動的なコードチェッカーを実行するか、まばらに文書化されている場合は、コメントを追加すると役立つでしょう。
あなた自身のコードをテストすることを困難にするテストの心理学がありますが、私たちは確かにユニットテスト中にそうするために最善を尽くします。独自のコードを読み取ることは、同様の、またはさらに悪い問題になる可能性があります。多くの分野でメンター、競争力のある審査、コーチなどが使用されています。建築家、システムエンジニア、テスターを含めれば、私たちもそうです。バグ報告ツールまたはカスタマーサポート部門にアクセスできる顧客は、製品が配備されると、頭の外からフィードバックを受け取ります。これは、早期かつ頻繁にリリースするアジャイルのアプローチのもう1つの大きな理由です。あなたはあなたの会社の唯一の開発者かもしれませんが、ある角度からそれについてあなたにフィードバックを与えることができるあなたのコードによって影響を受ける人々がいます。
他の回答に加えて、私は開発者会議に行くことをお勧めします。
これは、あなたにあなた自身のアプリと職場について考えさせる多くのトピックと人々にあなたを公開します。特に彼らが何のために機能し何がうまくいかないのか、そして浮かび上がってくる問題について話します。アプリと重複している可能性が高いです。
できれば、この作業には3日かかります。自分の作品に必要な精神的な距離を確保し、自分の作品ではなく、より大きなコミュニティ（いわば）の目を通してそれを見るのに十分な長さであることがわかりました。
ちなみに、グループ思考はどこでも発生する可能性があるため、これは人々のチームにも当てはまります。
最後に、これが承認されない場合は、たとえば年に1回、転職してください。
「これは私が思っているよりも小さな問題ですか、それとも他の人が経験した問題ですか？」
シーッシュ。もういい。コードが本番環境にあり、バグがなく、想定されていることを実行している場合、アーキテクチャは重要ではありません。少なくとも今のところ。
うまくいけば私たち全員が学びます。自分が書いたときに誇りに思っていたコードをたくさん書いてきましたが、1年か2年後にはひどいものだったと判断しました。現在、私は信じられないほど粗末なコードで満たされた複数年のプロジェクトに取り組んでいますが、コードは機能します。私はそれに触れることに非常に保守的なアプローチを取っています。
そして、そうする必要があります。大きな建築上の問題が今見られない場合は、1年の作業を経て、今のところ、重要な問題はないと考えるのは安全だと思います。これは悪い職人技ではありません。前進しています。