ひどいコードをマスターする9つの方法、高速

古いコードベースに新しい機能を実装するタスクが与えられましたが、コードはひどく見えます。 どのようにできるだけ早くそれを理解することができますか？ ここでは、無関係な詳細で迷子にすることなく、新しいコードの重要な部分を学ぶのに役立ついくつかのショートカットがあります。

プログラマとして、私たちはしばしば新しいプロジェクトに参加しなければならず、コードの品質はあらゆる場所にあります。 組織化されたチームであっても、中規模から大規模のプロジェクト全体でコードの品質を一貫して維持することは困難です。

そのため、貧弱なコードをすばやく理解することは貴重なスキルになります。 それはあなたが短時間で非常に生産的になり、通常は新しい男であり、キャッチアップをプレイすることに伴うストレスを軽減するのに役立ちます。 同僚との会話の中にいて、その人が半分の時間について話していることを知らないことはひどい気持ちです。

一方、これはあなたのクライアントや上司にあなたの価値を示す絶好の機会であり、あなたはすぐにスピードアップし、それらを感動させることがで ほとんどの開発者は、彼らが自分自身を構築しなかったコードベースで本当に生産的になるために数週間から数ヶ月かかります。

ここでは、ひどいコードをすぐにマスターする方法です。

それは最も効率的な戦略です

他の人はすでにコードがどのように機能するかを学んでいるので、なぜそれについて尋ねてみませんか？ あなたはそれがあなたが初心者のように見えると思うかもしれませんが、好奇心を示すことは、従業員としてのあなたのイメージに強い影響を与 あなたの上司の期待があなたが質問をせずに生産的に速くなることであったなら、それは彼女の誤った判断です。

誰もがスピードを上げるのに時間がかかります。 質問をすれば、チームワークのための右の態度がある人々に印象づける。

多くの場合、元の開発者は奇妙な、または予期しない決定を下したでしょう、そしてそれはコードについて話すことがそれを読むよりもはるかに価値 ドキュメントが不足している場合、これはさらに当てはまります。 既存の開発者は、どこにも書かれていない貴重なプロジェクト知識を持っていることを覚えておいてください。

あなたに意味をなさない概念のリストを作る

あなたにとって新しいビジネス概念や過度に複雑なビジネス概念があるかもしれません。 これらの概念を処理するコードで作業する前に、理解に時間がかかる可能性のある誤解を避けるために、それらについて明確にすることが重要です。

これらのアイデアは、データベース内で誤ったラベルが付けられたり、予期しない方法で表現されたりする場合もあります。 だから、あなたの脳をその周りに包むことにストレスを感じないようにして、ソースに行き、同僚にそれについて尋ねてください。

同じように、適切な名前を持たないモジュール、クラス、またはエンティティが存在する可能性があります。 それらのメモを作成します。 名前の付いていない要素は大きな混乱を招く可能性があるため、早期に文書化したり、コードの仕組みを考える能力に悪影響を与える他のものを文書化したりすることができます。

バグの再現を容易に

コードバージョニングとDockerやVagrantなどの仮想マシンを追加することで、バグの再現や新機能のテストにかかる時間を大幅に短縮

コードがどのように機能するかについての誤解は、あなたが構築しているものがすでに存在していて、あなたがそれを見ていないか、物事があなたが思ったように動作しないために、間違ったものを構築する道を導く可能性があります。

この時点で、プロジェクトにGitバージョン管理が必要です。 そうすれば、安定したリリースに戻ったり、必要に応じて破棄できる別々のブランチで作業したりすることができます。

追跡が困難な問題を掘り下げながら、stashを使用してテストやデバッグコードを追加できるため、Gitでより再現性を高めることも可能です。

プロジェクトのアーキテクチャについて学ぶには、早い段階で設定とドキュメントのタスクを取ります。

Vmと再現性についても同じことが言えます。 彼らは現代の開発チームのためにユビキタスになってきましたが、あなたは確かにそれらを使用していないか、一つの中で実行する準備ができてい 新しいチームメンバーとしての最初のステップは、環境を動作させるために行った手順を文書化し、最終的にそれらの手順をVMセットアップスクリプトに

コンポーネントの図を作成する

ビジネスコンセプトのマインドマップ、データベーステーブルのエンティティ関係図（ERD）、コードコンポーネントの簡単な図は、新しいコードを理解する手間を大幅に軽減するのに役立ちます。 何かがいかに働くか覚えていないか。 そのERDを開いたままにしておいてください。

実際には、情報をすばやく消化し、プロジェクトの一万フィートのビューを持つことができます任意のグラフィカルなツールは貴重なものになります。 他のツールの例としては、依存関係グラフ、ログ、およびプロジェクトの技術スタックのマップがあります。

開発における最大の消費者の1つは、システム間の統合ポイントです。 プロジェクトランドスケープのグローバルビューを使用すると、どの統合ポイントを検討するのが興味深いかを特定できます。 それらはそれらに入れられるほとんどの仕事がある点およびほとんどの虫である。

一方、技術は速く動き、コードベースの大部分をより近代的で適切に統合されたソリューションに置き換える機会がある可能性があります。 古いフレームワークは、問題を解決するための新しい公式の方法を開発したかもしれませんし、完全に新しいライブラリは、より良い互換性を念頭に置いて開発されている可能性があります。

視覚化ツールとモデリングツールを使用して全体像を表示します。

自動テストの準備

物事を壊す前に、関連する単体テストを追加することは常に賢明です。 テストと貧弱なコードの問題は、貧弱なコードは通常緊密に結合されており、テストするのが難しい（不可能ではないにしても）ということです。 絡み合って不可分なコンポーネントを分離することはできません。

そのような場合は、一歩下がって遠くからテストしてください。 通常、それは利用可能な多くのツールがある統合テストを行うことを意味します。 Web appsはHTTP要求に対してテストできるため、少なくともシステムが同じ入力に対して同じ方法で応答することを確認することは可能です。

統合テストは、単体テストよりもはるかにパフォーマンスが悪いです。 可能な場合はいつでも単体テストを実装して、コードの変更に関するフィードバックを迅速に行うことができます。 それが不可能な場合は、機能テストまたは統合テストを選択してください。

このステップは、作業が必要なコードの部分にいくつかの光を当てる必要があります。 大量の密結合コードがある場合、それは統合テストが行われた後のリファクタリングのための良いターゲットであり、後で単体テストのためのものです。

異常または不十分なコーディング戦略を特定する

リファクタリングを開始する時が来ましたが、どこから始めますか？

通常、最高の場所は、物事が奇妙に見える場所、または開発のベストプラクティスに従っていない場所です。 Web開発の場合、それは密に結合されたモデルコードを持つfatコントローラを意味する可能性があります。

同じ戦略が他の場所で使用されている可能性があることに注意してください。 したがって、たとえば、fatコントローラが存在することを特定した場合、以前の開発者はthinコントローラを使用しようとしなかった可能性があります。 それは今までの開発プロセスのスタイルや欠点を反映しているので、他のコントローラでも同じ問題を見ることが期待できます。

まず、小さなタスク

概念的に単純な機能に関する小さなバグを修正することは非常に啓発され、最初から生産的に感じるのに役立ちます。

これは、Andy HuntとDave Thomasがプラグマティックプログラマで「トレーサー弾」と呼んでいるものに似た考え方です。 基礎となるロジックは同じです：それが可能であることを自分自身に証明するためにエンドツーエンドの何かに取り組んでから、その最初の作業を

“トレーサー弾”アプローチ。 Credit:The Pragmatic Programmer

あなたが作ることができる単純な改善の良い例は、単純なコードで小さなリファクタリングのステップを取ることです。 フォローされていない一般的なプログラミングの練習を特定し、それを適用します。

このための私のお気に入りの一つは、ネスト解除条件付きブロックです。 したがって、複数のif-if-ifブロックを持つ代わりに、他のブロックの中に最初のブロックを否定して戻り、見つけることができるすべての検証型チェッ これは、”if”チェックを反転してコードを移動するのと同じくらい簡単なので、リスクはほとんど存在せず、フラットコードを読みやすくなります。

変更はリスクが低いにもかかわらず、本番環境に送信する前にコードを検証できることは常に良い考えであるため、テストが容易な機能をリファク

クリティカルコード

に取り組む前に、慣れ親しんだ地面に乗って、常にプロジェクトがどのように設定されているかを最初に学び、その後だけ ビジネスコードと統合コードの最も重要な部分は、理解して変更するのが最も難しいです。 早い段階でトラブルになることは避けてください。

原則として、プロジェクトやビジネス面について現在よりも多くのことを知る必要があるビジネス上の問題は避けてください。 これは、通常、取引、支払い、または数学の重いコードから慣れ親しんだ地面になるまで離れておくことを意味します。

あなたが生産的で、プロジェクトのコーディングスタイルに慣れていて、単純な問題を修正するのに問題がなければ、それは難しいものに取り組む時です—しかし、以前はそうではありません。

支払いの問題を修正するためのいくつかの緊急性がある場合でも、例えば、そのようなタスクは信じられないほど危険なことができます。 そこの間違いはプロジェクトを心から要することができ、それはあなたにまたある。 可能であれば、早期にリスクの高いタスクに取り組むことを絶対に拒否します。

なじみのない技術スタックに対処する方法

最後の点について、私が遭遇した共通の問題は、すべての新しいプロジェクトに通常、私が慣れていない技術が含まれているということです。

それが起こるとき、私は私が速くスピードアップするのに役立つ戦略のカップルを持っています。 学習のための明白な道は、ドキュメントを読んで、新しい技術に慣れることです。 しかし、あなたは構造について多くのことを学ぶでしょうが、その道はあなたが一般的に経験があるコーナーケースを学ぶのを助けません。 （”コーナーケース”は、通常の動作パラメータの外で発生する状況を指す工学用語です。)

経験を積むこのプロセスをスピードアップする1つの方法は、Stack OverflowやQuoraなどの質問ベースのリソースを使用して、本のように読むことです。 学習しているライブラリに関する最も一般的な質問を見つけて、他の人が一般的に遭遇する問題の種類を確認してください。 あなたは必ずしも自分でそれらに遭遇するつもりはありませんが、何が可能かを知ることは、それらの新しいアイデアのマインドマップに明るい光

Stack Overflowの質問を活用して、迅速に経験を積む。 Credit:Stack Overflow

よりターゲットを絞ったアプローチについては、新しいプロジェクトで具体的に使用されているライブラリ機能に関する情報を見つ あなたに新しいものを見て、あなたがそのコードにまったく触れなければならない前に、事前にそれらを学びます。