一歩下がって、新鮮な目でコードを見る方法は？[閉まっている]

私は昨年、1人のチームとしてリッチクライアントアプリケーション（35,000以上のLoC、価値あるもの）を開発しました。現在は安定しており、運用中です。しかし、プロジェクトの最初の段階では私のスキルが錆びていたことを知っているので、間違いなくコードに大きな問題があります。この時点で、ほとんどの問題はアーキテクチャ、構造、および相互作用にあります。簡単な問題は、アーキテクチャ/設計の問題でさえ、すでに取り除かれています。

残念ながら、私はこのプロジェクトに多くの時間を費やしているため、その外側を考えるのに苦労しています。新しい視点からアプローチして、設計に深く埋め込まれている、または固有の欠陥を確認します。

どうすれば頭の外やコードの外に出て、見た目を新しくしてより良くすることができますか？

これにアプローチする方法：

• 技術とビジネスの問題に精通している人を見つけて、それを話し合ってください。これは、一人のチームでは難しいかもしれませんが、一般的には最良の選択肢です。
• しばらくの間、別のプロジェクトに取り組みます。これも難しいかもしれませんが、1週間の休憩をとっても新鮮な視点が得られます。
• 存在する場合は、オープンソース製品など、類似のプロジェクトまたは製品を見てください。コードをコピーしないように注意してください。ただし、アイデアにまったく異なるアプローチを取っている可能性があります。
• 新しい言語、ライブラリ、またはフレームワークを学びます。関係する手法により、異なる問題にどのように対処するかを知ることができます。
• デザインや言語/フレームワークに関する優れた本/ブログ/雑誌を読んでください。あなたのスキルのレベルはわかりませんが、このサイトの他の回答には多くの選択肢があります。

対処したい具体的な例がある場合は、おそらくここに投稿してください。

ゴム製のアヒルのデバッグ：コード、モジュール、または機能を使って座り、大声で説明します。間違っている、馬鹿げている、または単純に聞こえない何かを言っていることに気付いたときは、調査する問題としてそれを正しく書き留めないでください。

あなたのスキルを学び、拡大してください。あなたが知らないことを知るのは難しいですが、あなたがそれを見るとき、その「あは」の瞬間があなたを襲います。別の言語やデザインパターンを学ぶことから来る可能性があります。

変更を行うように求められます。コードの中でそれほど柔軟性がなく、多くの手直しが必要な部分を見つける場合があります。最初はすべてを考えることができないため、これは必ずしも失敗ではありません。

ユーザーは不平を言い始めます。すべてが素晴らしいと思うとき...

短いメモリが役立ちます。私は1週間前に何かを変えた「ばか」について文句を言うことが知られていましたが、ソース管理からそれを見つけるのは私でした。

良い最初のステップは、改善できるコードを特定することです。最も頻繁に変更されるファイルのソース管理を確認してください。どのコードが最も扱いにくいですか？どのコードが最もバグを生成しますか どのような変更がコード全体に波及効果をもたらしますか？この段階では、なぜコードが面倒なのかを知る必要はなく、面倒だというだけです。

作業する領域を特定したら、実際に問題が何であるかを把握してください。設計上の問題を分類するために体系的なアプローチを取る本があります。Martin Fowlerのリファクタリング、Herb SutterのC ++コーディング標準、Robert MartinのClean Codeなどを見てください。これらには、客観的な方法でコードを見ることができる「ルール」がたくさんあります。

問題が何であるかを特定したら、それを修正するさまざまな方法を試してください。たとえば、破ったルールが「継承よりも合成を優先する」である場合、それを合成に変更して、どのように感じられるかを確認します。

もちろん、コードを他の誰かを見ていることが役に立つことができますが、あなたがしているので、それは、常にあなたが想像するほど便利ではありません多くのより身近な問題の種類の他の誰よりもコードの原因、および設計の背後にある理由と。独自の設計を客観的に評価するいくつかの方法を学ぶことは、大きな利益をもたらします。

他の人にコードを見てもらいます。他の人がそれを見ることができない場合、他の人に見せようとするように、相互作用の完全な説明を書きます。自分の決定を他の人に説明しようとするプロセスは（たとえそれが単なる練習であっても）、物事を特定の方法で行っている理由を本当に考え、ロジックの穴を見つけるのに役立ちます。

私はこの状況をよく知っています。そのように動けなくなったら、プロジェクトについてさまざまな視点をとろうとします。

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つの大きな理由です。あなたはあなたの会社で唯一の開発者かもしれませんが、あなたのコードに影響を受け、それについて何らかの角度からフィードバックを与えることができる人々がいます。

「これは私が思っているよりも小さな問題ですか、それとも他の人も経験している問題ですか？」

シーシュ。もう十分です。コードが本番稼働で、バグがなく、想定どおりに機能している場合、アーキテクチャは重要ではありません。少なくとも今のところ。

うまくいけば、私たち全員が学習します。私はそれを書いた時に誇りに思っていた多くのコードを書きましたが、それは1年か2年後にひどいものだと判断するだけでした。現在、私は信じられないほど無愛想なコードで満たされた複数年のプロジェクトに取り組んでいますが、コードは動作します。私はそれに触れることに対して非常に保守的なアプローチを取っています。

そして、あなたもそうすべきです。主要なアーキテクチャ上の問題が1年も経っていない場合は、現時点では重要な問題はないと想定しても安全だと思います。これは悪い職人技ではありません。前進しています。

他の答えに加えて、開発者会議に行くことをお勧めします。

これにより、自分のアプリや職場について考えさせる多くのトピックや人々にさらされます。特に、彼らが何のために働いて、それについてはうまくいかないか、そして出てくる問題について話します。アプリと一部重複している可能性があります。

できれば、これには3日かかります。私は、自分の作品に必要な精神的な距離を確保し、自分の作品ではなく、より大きなコミュニティ（いわば）の目を通してそれを見るのに十分な長さであることがわかりました。

ちなみに、グループ思考はどこでも発生する可能性があるため、これは人々のチームにも適用されます。

最後に、これについて承認を得られない場合、たとえば年に1回、転職します。

• 設計パターンとベストプラクティスを実践する
• アプリの要件とニーズに基づいてフレームワーク、ツール、パッケージなどを選択します-このためには、多くのエッチブログを読み、個々の技術的な問題の解決策を見つける必要があります
• 設計/アーキテクチャのドラフトを作成し、技術的/建築的なものが得意な人と話し合います。フィードバックとコメントを使用して、このドラフトを改善してください。安定状態になるまでこれを続けてください。

• アプリが必要とするすべてのものが構成可能および保守可能になるようにコードを実装する

  プロジェクトの再構築と再実装により、アプリの一貫性、パフォーマンスなどが確実に向上します。

少数の賢い人々との懸念を「蹴り飛ばす」ことが役立つと信じています。特定の情報が必要です。24時間365日のWebサイトですか？LoBアプリ？どこで実行またはホストされていますか？

コアの目的と望ましい結果に到達したら、他の人があなたの注意を集中し、導くのを助けることができます。あなたのコードは、特定のタスクのために書かれた最高のコードかもしれませんし、最悪のコードかもしれません。それは本当に重要ではありません-それが望ましい目標にどのように影響しますか？