新しい仕事でアプリケーションを継承するとき、元の開発者のコーディング手法に固執する傾向がありますか?それとも独自のコーディング手法を適用し始めますか?
私はガイドラインのない小さな店で働いていて、ここのルールは何だろうといつも思っていました。一部のアプリケーションは非常によく書かれていますが、私が使用する標準 (変数名など) に従っていません。一貫性を保つために少し余分な時間がかかることに気づきました。
他のものは非常に貧弱に書かれており、開発者がキーストロークごとに考えを変えていたようです...
独自のプロジェクトを開始する場合はどうなりますか? そこで、新しいコーディング標準をミックスに導入しました。
コードに明らかな標準がある場合は、それらに固執する必要があります。ない場合は、独自の導入を開始します。
同じモジュールで作業する開発者が複数いる場合は、スタイルを変更しないでください。
近い将来別の開発者に引き渡す場合 (この役割は一時的なものです)、スタイルを変更しないでください。
モジュールの完全で排他的な永続的な所有権を取得する場合は、変更しますが、次の規則に従います。
一度に 1 つの変更。
一度にすべてのインデントを好みに合わせて修正し、その変更をコミットします。
一度にすべてのブレースの配置を好みに合わせて修正し、その変更をコミットします。
他のすべてのフォーマットを好みに合わせて一度に修正し、その変更をコミットします。
一度にすべてのネーミングを好みに合わせて修正し、その変更をコミットします。
それに多くの時間を費やさないでください。
1～2時間以上かかる場合は、短縮してください。
コミットの説明を明確にします。
そのため、変更履歴を分析するときに、これらの変更をすぐに無視できます。
自動ツールを使用する
結果が一貫して完全であることを確認するため、もう一度いじる必要はありません。
テストを実行する
変更が動作に影響を与えてはならないからといって、影響を与えないわけではありません。（トリプルネガティブ、痛い！）
あなたが何をしているかを誰もが知っていることを確認してください
誰かが今すぐコミットしたい変更をぶら下げている可能性があり、変更をマージするのは面倒です。また、誰かに驚かれたり、自分より先に上司に報告したりしたくありません。
二度とやらないで
これは 1 回限りのことです。
ベストプラクティスに従ったスタイルガイドを公開し、それに従うことについてコンセンサスを構築します。維持する必要があるので、古いコードをリファクタリングします。
私はあなたと同じ船に乗っています。最後の男からいくつかのアプリを継承した孤独な開発者。私
私は一貫性を保つために既存のプロジェクトの彼の基準と思われるものに固執し、新しいものには自分の好みを使用しています。
ほとんどの人は、自分より前の人はコードの書き方を知らなかったと思っていることに気付きました。その後、彼らの後に来る人は誰でも同じことを考えます。常識的なこともありますが、ほとんどのことは個人的な好みにすぎません。
コメントを使用する場合とコメントを使用しない場合などの大きな問題については、コードを更新すると、おそらく作業が容易になり、他の人が作業しやすくなります。それでも、大規模なプロジェクトに着手してすべてをリファクタリングする (プロセスに新しい問題を導入する) よりも、コードに遭遇したときにコードを更新することに時間を費やすのがおそらく最善です。
インデント、行間隔、変数名、1 行の if と複数行の if などについて、実際には、あなたのコーディング スタイルは、あなたが思っているのと同じくらい悪いものです。
それはあなたが「コーディング慣行」によって何を意味するかによると思います。コードのフォーマットや命名規則など、私が個人的に「化粧品」と見なすものを意味する場合は、すでにそこにあるものに固執してください。そもそもベストプラクティスのコーディングやコードの記述などを意味する場合は、戻って問題を修正しますが、少なくとも新しいコードをベストプラクティスに従わせます。
私が継承したアプリケーションのほとんどが、最も基本的なコーディング手法さえも適用しなかった「カウボーイコーダー」によって一緒にハッキングされていることを考えると、私の意見は少し偏っています。
コーディング標準がない場合、または存在するものが明らかに間違っているか愚かである場合（たとえば、「すべての変数の長さは4文字以下でなければならない」、「すべてのデータベース列はvarchar（255）null」など）、コーディング標準を導入すると言います。 。）。明らかに、チームがある場合は、実装するプラクティスについて合意する必要がありますが、ソロ開発者の場合は、自由な統治とIMOがあり、混乱に秩序を導入する必要があります。
ある場合は会社の基準に従います。
何もなく、変更が少ない場合は、使用しているコーディングスタイルを採用します。
より大きな変更が必要で、コーダーのスタイルが気に入らない場合は、独自のスタイルを使用します。また、既存のコードが悪い場合は、それも変更します。
特定のケースに大きく依存すると思います。
それがあなただけなら、それのために行きます。チームの場合、特に元の開発者がまだ残っている場合 (またはコンサルティングのために呼び出される可能性が高い場合) は、既存のスタイルと慣行を可能な限り維持してください。彼らをネズミの穴に追い詰めないでください。彼らが何かばかげたことをしていると思うなら、それを変えてください。しかし、それが単に文体的なものであれば、できる限り彼らのスタイルを維持してください。
私がこれまで携わってきたいくつかの仕事では、「既存のファイル/クラスを変更する場合は、新しいコードであっても既存のスタイルを使用する」以外に、コーディング スタイルに関するルールはありませんでした。
明らかにリファクタリングされたことのないコードを継承する場合、それを機会として、独自の構造を課すことになります。
コードに機能を追加するための時間とコストを見積もることを人々が期待する場合、私はそのコードに精通し、それが私の基準を満たしていることを確認する必要があります。
コードがすでに適切に作成されている場合、それは私が台無しにしないという祝福です。しかし、私の経験では、これはそれほど頻繁には起こりませんでした。
標準的なスタイルで既存のコードを更新するより良い機会はありますか? おそらくそうではありません。コードに慣れていない場合は、新機能やバグ修正以外の変更を行うために余分な時間を費やす可能性が最も高くなります。標準の欠如は気が進まないかもしれませんが、最初にコードを継承するときよりも標準化する可能性は低いでしょう。
公式のスタイル ガイドやベスト プラクティスがない状況について話しているように思えます。その場合、ショーンが言ったように、私が率先していくつかを確立します。しかし... 可能であれば、既存の広く使用されている標準を選択してください。受け入れられる可能性が高くなり、すべての議論が終了し、すぐに使用できるツール (エディター、コード レビュー ツールなど) がサポートされる可能性が大幅に高まります。
他の人にそれを採用してもらうことは、多くの場合、ボトムアップから行うのが最も効果的です。つまり、新しい標準に合わせて新しいコードを作成し、作成したことを他の人に伝え、フィードバックを求めます。事前に承認と賛同を得ようとするよりもはるかに簡単です。
既存の見苦しいプロジェクト内で、既存のモジュールを大幅に変更することは避けてください。1 つには、ファイルが突然再インデントされると、差分とバージョン管理が非常に混乱します。
作業中のチャンクが読めないほど悪い場合は、再フォーマットするためだけに最初のチェックインを行います。その後、実際のコード変更を行います。
自分のスタイル基準に DID が一致する場合と同じリファクタリング基準をコードに適用します。つまり、私はそのスタイルを無視して、ただ自分の仕事を続けます。
コードのスタイルに従うのがそれほど難しくなければ、命名規則に関しては、新しいコードにそれらを使用します。
ただし、「タブを使用しないでください」、「すべての行を 2 つのスペースでインデントする必要があります」などのようなことを気にする必要はありません。必要なときにいつでもコードを「きれいに」できるエディターがたくさんあります。最近それ。
Gマン
短い答えは、「場合による」です。古いスタイルを維持するかどうかを決定する際に重要と考えるいくつかの要因を次に示します。
1) 変更の範囲。アプリケーションの完全な書き直しに近い場合、うまく機能すると思われる標準がある場合は、新しい標準を追加する方が理にかなっている可能性があります。
2) 将来の変更の可能性。これは何度も変更されますか？もしそうなら、早い段階で時間をかけることは、最終的にはそれだけの価値があるかもしれません. これには多少の判断と将来の予測が必要ですが、場合によっては、かなり複雑な一部のシステムで何度も何度も変更が行われることを簡単に確認できます。
3) サード・パーティのコードベースのカスタマイズであるコードの割合。たとえば、企業のビジネス・プロセス用の Oracle 製品の特定のカスタマイズと、完全に自家製のアプリケーションとの比較。ここでの影響は、新しいバージョンがリリースされてアップグレードが要求されたときに、カスタマイズが多かったため、どこが壊れたのかにどれほどの苦痛が伴うかということです。
独自のプロジェクトを開始するときは、自分が知っている最高の基準を設定してください。