厳しい締め切りに直面したときに他の人のコードをクリーンアップすることはどれほど重要ですか？[閉まっている]

（私は（プログラミング言語ではなく）HTML / CSSコードについて話しているが、プログラマーと同じ問題に直面していると思う。）

私はチームのシニアフロントエンドデザイナーであり、後輩の成果を厳しい締め切りで頻繁に作り直す必要があります。

私は2つの問題に直面しています：

1. それらのコーディングスタイルは少し複雑です。
2. 美学は良くありません。

彼らのコーディングスタイルは、適切な慣習/標準がない混合バッグです。私は、コードをクリーンアップするか、単にコードを処理する（それらがどのように動作するかをコピーする）ことで引き裂かれます。

私は悪い習慣を学ぶかもしれないと思うので、彼らのコーディングスタイルに従うのはイライラします。しかし、その後、それが期限を満たすための最速の方法です。

より多くの経験を持つ人にとって、どれがより効果的ですか？クリーンアップを後で保存する必要がありますか？または、変更の途中でクリーンアップしますか？

（私は慢に聞こえたくはありませんが、それは現実です。より良いコードを書くのに何年もかかるでしょう。

あなたは問題を間違った方法で見ていると思います-あなたは後輩により良いコードを書く方法を教える素晴らしい機会を逃しています。

習慣的にコードを書き直すと、後輩に自分の仕事を評価しない印象を与え、士気を低下させ、次回のコードの改善に役立たない可能性があります。

より良いアプローチは、チームの開発プロセスにコードレビュータスクを追加することだと思います。コミットされたコードのすべての部分である必要はなく、あなただけが実施する必要はありません（私はそうすべきではないと主張します）-チームのメンバーが十分な大きなタスクを完了するたびにチームメイトの1人（またはそれ以上）とペアを組んでコードを説明し、設計、コーディングスタイル、バグやセキュリティ問題などについて建設的な意見や批判を受けます。

コードレビューチームメイトがあなたであるとき、彼らはあなたが単にコードを書き直すとき（彼らはコードが変更されるべき理由を聞く機会を得ます）よりもあなたの専門知識から多くを学び、より少ない攻撃をするかもしれません。

彼らにコードレビューを行う機会を与えることは、彼らの能力をさらに高めます-他の人々がどのようにコードを書くのか、そしてなぜを見る-そして彼らの自尊心を高めます。

また、コードをレビューする機会を与えると、彼らは多くを学びます。あなたも何かを学ぶかもしれません-ショーだけのためにそれをしないでください！

これは以前にも言ったことがありますが、「作業コードはきれいなコードよりも価値があります」ともう一度言います。

コードを変更すると、その動作を変更する可能性が高くなります。これがテスト済みのコードである場合、すべてのテスト作業を無効にしているため、テストを繰り返す必要があります。

後輩にわかりやすいコードを書くように勧めますが、彼らが書いたものをすべて書き直そうとすると、雇用主のお金を数回無駄にします。彼らはあなたの後輩にお金を払わなければなりません、そしてあなたが既にあなたの後輩に支払ったことをするためにあなたに支払い、そして彼らが実際にあなたを雇った仕事をするためにもう一度あなたに支払います。

• 短い答えは：いいえ。困難なときは、頭を下ろして美的な弾丸を撃たなければならないこともあります。;）

• より実用的な答えは、タイムボックス化することです。実行してコードの特定の側面をクリーンアップするために1時間の予算を設定します。次に、チェックインして実際の作業を行います。しかし、それを制約された状態に保つことについて、自分に正直になります。

• ただし、場合によっては、少しクリーンアップすると作業が速くなります。検索と置換のタイプをすばやく変更するだけでも、すべてがより使いやすくなります。

• スタイル戦争に注意してください。特に、締め切りが厳しい状況で、他のプログラマーがやり直すスタイルの設定を元に戻す場合は、それらに対処する方法を実際に解決する時間ができるまで待つのが良いでしょう共同で文体の問題。（これは、ギブアンドテイクを意味します。）

しかし、答えには判断値があります。「適度に」重要だと思います。クリーンなコードは本当に作業を高速化することができ、コードの品質は結局のところ成果物の一部です。クリーンアップに時間を費やすことなく、コード（自分のコードでも）に触れることはできないと思います。しかし、スタイルとフォーマット、スタイルウォーに煩わされることは、コードを本番環境にするよりも重要にならないようにしてください。

コードを修正し、期限を設定する場合、通常2つのルールを使用します。

コードはひどいですが、妥当な時間で問題を見つけて修正することが可能です

私は問題を修正し、残りはそのままにしておきます。

コードは非常に乱雑であるため、そこで問題を見つけるのは非常に困難です。何かを修正すると、すぐに別の何かが壊れます。コードを修正するよりも、最初からコードを記述する方がおそらく高速です。

その後、コードがバグをローカライズして修正するのに十分きれいになるまで、リライト/リファクタリング以外の選択肢はありません。

境界線の場合は、次のとおりです。

コードは乱雑で本当に悪いです。妥当な時間内にバグを修正することはまだ可能ですが、コード構造により保守が非常に難しくなります。新しい機能は、新しいバグを導入したり、パフォーマンスを大幅に低下させたりする可能性が非常に高くなります。

その場合、コードは修正されますが、新しい機能が実装される場合にのみ、アイドル時間中に、期限に直面してバグ修正時間には決してされません！

あなたのプロセスのどの時点でこの問題を見つけているのか知りたいです。

厳密に言えば、誰も住んでいないこの魔法のような理想の世界では、昇格または展開されたすべてのコードは完璧でなければなりません。実用的でなければならないこともあります。

ただし、コードレビュープロセスがある場合は、テストする前にこれを強調する必要があります。常に期限に間に合っている場合、配信の見積もりの​​問題は、開発プロセスの主要なコンポーネント、つまりコードレビューが行き詰まっていることを意味していますか？

時間をかけて開発プロセスの一部にしないと、後輩が座ってより良い方法を吸収することを学ぶことはありません。あなたがそうしていないように聞こえます。

文化全体に依存します。厳しい締め切りが散発的に発生する場合は、後でクリーンアップを行う必要があることを受け入れます。それらが一定である場合、構造的に技術的な負債を積み上げているので、管理で問題を取り上げる必要があります。彼らがあなたの懸念に対処しなければ、企業文化がダーウィンの原則をすぐに満たす可能性が高いので、他の雇用機会を探し始めましょう。

将来的に問題を抑制するのを助けるために、すべての従業員が従わなければならない内部コーディング標準と実践文書を開発します。

現在のバッチでは、コードをリファクタリングするときにS＆Pドキュメントに従ってコードをクリーンアップしますが、リファクタリングするときのみです。

私はかなりプログラミングに不慣れです。しかし、学生として、私はしばしばプロジェクトのピアレビューとパートナーシップを約束します。プロジェクトを完了する十分な時間がある場合は、明快さと読みやすさのために、チームメンバーのコードをクリーンアップします。たいていの場合、最初の100行程度をふるいにかけることすら難しいでしょう。これらの場合、私は仲間のプログラマーにより良い習慣とコーディングを教えるのを支援するために手を差し伸べるだけではありません。時間が足りない場合は、コピー/貼り付けを行い、プロジェクトを貧弱なインターフェイスに対処するために全体像を描きます。その後、コーディング技術に関する多くのアドバイスを提供します。ピアレビューに関して言えば、建設的な批判は（歓迎されないかどうかに関係なく）、長期的には彼と彼女の両方に利益をもたらすだけです。

全体として、時間に余裕がある場合は、新参者に自分の仕事の進め方を教えて、全員が有益になるようにしてください。少し時間をとって、あなたに合ったものとそうでないものを教えてください。時間がない場合は、彼らの仕事にとりかかり、機会があれば彼らに戻ってください。特に将来あなたと一緒に仕事をするなら、物事を行うより良い方法があることを彼らに知らせてください。

全体的な品質を改善することは、一人の人をより大きなグループの「フィルター」として使用するよりもはるかに優れています。そのメモについて：

• ペアプログラミングは、開発方法を理解するための機能強化されたバージョンのコードレビューのように機能します。これは、読むことと行うこと、伝えること、示すことの違いのようなものです。コードの進化を観察し、変更をすばやく議論することは、リファクタリングと優れたコードの方法だけでなく、その理由を理解するのに非常に役立ちます。私の経験では、単独で開発するよりも高速です。アイデアが絶え間なく放り込まれ、全体的に高品質の結果が得られ、コードと他の人の思考の両方をよりよく理解できるからです。
• リンティングツールは、コーディングスタイルが守られていることを確認できます。これは誰にでもコードのフォーマット方法を教えてくれるので、開発者が標準を思い出すとエラーはすぐに消えるはずです。
  • これらをビルドプロセスの一部にして、コミットする前に修正されるようにします。
  • 言語テンプレートを使用して、CSS、HTML、JavaScript、およびサーバー側コードを個別にチェックできるようにします。
• 検証ツールは、生成された出力が正常であることを確認できます。これらもビルドプロセスの一部である必要があります。

ベストプラクティスは、コーディングスタイルガイドを用意し、定期的なレビューを行うことです。これにより、期限に近づいたときに、この問題に直面することはありません。

私の推奨事項は、リーダーシップを発揮し、定期的なコードレビューの先頭に立つことです。定期的なコードレビューを確実に行うために経営陣がトップからプッシュされることはありませんが、私の経験では、プログラマーが定期的なコードレビューのスケジュールを立てて開催すると感銘を受けます。

あなたの人々には多くの利点があります。

• より良いスタイルを学ぶ
• より良い慣行に従う
• 彼らがやっていることを研究することを学ぶ

そして、あなた自身にとってのいくつかの利点は次のとおりです。

• 土壇場のデバッグ時の効率が向上します（常に発生します）
• チームと経営陣の両方から専門家とリーダーの両方として認められている

その理由は、「何が機能しているかを修正しないでください」および「クライアントにとって重要でないものに時間を無駄にしないでください」という回答でわかります。PMはリスクを心配しており、これは問題ありません。

また、私はほとんどの人がこの種の修正をうまく受けていないことを理解しています。私もこれを理解しています。

そうは言っても、ほとんどの締め切りは人為的なものだと思います。実際のシステムは期限を超えて生き続け、今日の悪い設計はあなたを永遠に反撃します。人々は数か月で何かを提供するために走り、この数年後に実稼働で実行されているコードのいくつかの悪い決定を修正します。

技術の負債は言葉です。それはいつか戻ってきて、誰かがそれを支払うでしょう。

ですから、IMO、壊れたデザインを修正するのは正しいと思いますし、専門家であること（特にジュニア向け）は、批判をどのように受け、それから丁寧でなくてもそれを学ぶ方法を知らなければならないことも意味します。実際、人生のほとんどは丁寧ではありません。

どんなストレートな答えも極端になるでしょう。デッドラインが非常に厳しくていコードを使用しなければならない場合があり、コードがsoいためにデッドラインを改善する価値がない場合があります。必要なのは、自分がどちらにいるのかを判断する方法と、おそらくより良いコードを書く時間ができる現実的な期限を設定する方法です。

クリーンアップを保存しないでください。あなたが習慣的にリファクタリング以外のことをしない期間がない限り、現在よりもコードを整理するために何らかの形でより高い優先度になる「後」はありません。ルーチンは「赤、緑、リファクタリング」であり、「赤、緑、2週間完全に異なることをリファクタリングする」ではありません。現実的には、次回何らかの理由でコードを再訪するまでコードを変更することはありません。そのため、おそらく締め切りに間に合うでしょう。実際のオプションは、今すぐ修正するか、そのままにしておくことです。

もちろん、スタイルの良いコードは、スタイルの悪いコードよりも優れています。二度と読みたくない場合は、片付けないでください。テストに合格した最初のものを出荷します。しかし、それは非常にまれなシナリオであり、ほとんどのプログラマーにとってはほとんど発生しません。そのケースを無視すると、実際のケースの詳細を知っているのは、修正にどれくらいの費用がかかるか、それを修正しない場合に（将来のメンテナンスの増加で）どれくらいの費用がかかるかを判断することだけです。

コードのメンテナンスが必要な時点で修正するのは、今すぐ修正するより難しいことはありません。これらは実際に今修正するためにあなたに多くの利益をもたらさない。最も明白なのは修正するのが簡単（ホワイトスペースエラーなど）なので、この質問をする時間はあるが修正するのは時間がないと想像するのは難しいです;-) 、理想的ではないコードもありますが、実用的でなければなりません。それは機能し、あなたは締め切りです。これを使って。

（a）みんなの心にそれほど新鮮ではない場合、後で修正するよりもかなり簡単に修正できる特定のものがあります。（b）それらに依存する、または模倣する他のことが書かれています。これらは今修正するのにより価値があるので、優先順位を付けてください。これらを修正する期限に余裕がない場合は、コードベースに借金を積み上げているため、次回訪問するときにおそらく支払わなければならないので、期限を長くするためにできるだけ強くプッシュする必要がありますコード。

コードを修正する好ましい方法は、レビュープロセスです。あなたがそれについて持っている問題にコメントし、変更するためにそれを後輩に送り返してください。意味の例を挙げて、後輩に任せて、該当するコード内のすべてのケースを見つけてください。しかし、彼らのためにコードを完成させるだけではありません。そうした場合、あなたは彼らに改善する手段を与えません。

一般的な問題は、「これを行わずに、代わりにこれを行う」というスタイルガイドに記述し、その理由を説明する必要があります。最終的には、「コードを美的に一貫させるため」という理由が許されますが、正当な理由でルールを書き留める準備ができていない場合、おそらくそれらを強制するべきではありません。各プログラマーは自由に選択できます。

最後に、無期限に微調整する傾向に注意してください。収益は減少しますが、それらがまだ良い場合は経験を通じて学ぶ必要があります。何が十分であるかの現実的なアイデアを形成することは絶対に不可欠です。さもなければ、納期が「十分な」コードを作成する時間を与えることを確認する交渉をすることはできません。十分ではないことに時間を費やしてください。

多くの人が以前に言ったように、空中に投げたものは常に下に戻ってきます。私はコードベース全体で強力な均一性を信じています。もちろん、それほど重要ではないものもあります。たとえば、プロシージャ内のローカル変数の命名規則。ただし、構造的には、メイントランクへの最終的なマージの前に、すぐに修正する必要があります。個々のプロシージャまたはクラスを見ると、少し見苦しいかもしれませんが、誰もが「少しい」コードをコミットすると、全体として非常に速くなります。

動作するUいコードは、多くの場合、90％の時間で正常に動作しますが、端でばらばらになります。いくつかの単純なルールに従うだけで、通常はそれが十分に単純でないことを確認します。まず、すべてのプログラマーが作成するすべての手順または機能ブロックの正確な制約を定義および文書化することが必須です。

第二に、すべての手順に対して、これらの制約に対するテストが必要です。これは、プログラマーがコミットする前に自分の手順に対してローカルで実行できる（そして実行する必要がある）単純な単体テストでなければなりません。明らかに、これは適切なテストスイートで管理する方が簡単ですが、テストがなくても作成し、場合によってはビルドから除外できる部分クラスにコミットする必要があります。

第三に、事前に構成されたツールを備えた標準化された開発環境は非常に貴重です。これにはTSサーバーが最適です。誰もがまったく同じツール（およびバージョン）、同じ構成、同じ更新を持っています。CodeRushやResharperなどのリファクタリングツールをインストールして、標準に事前に設定し、警告が残っているコミットを拒否するようにプログラマーに指示します。チームのコードレビュー時間を使用して、フィードバックからルールセットを実際に改善することができます。その後、常にクリーンアップすることなく、チームは喜んで自分自身を修正します。また、プログラマーにとっては、標準がarbitrarily意的に定義されているか適切に理解されていない同僚や上司よりも、適切に構成されたツールからコード批判を受ける方がはるかに簡単です。IDEからコードが粗末であると通知された場合、誰もそれについて議論することはなく、修正されるでしょう。コードの品質が劇的に向上し、チーム全体がリファクタリングとクリーンアップにかかる時間を数週間で大幅に短縮できることがわかります。プログラマーもルールに慣れ、がらくたコードの作成を停止します。

最後に、ここでの簡単な修正は、単にプログラマーに改善のインセンティブを与えることです。プログラマーは当然、競争力があります。誰もが最もすてきなまたは最速のコードを持ちたいと思っています。全員の意欲を高め、生産性を向上させ、無能な人を根絶するための良い方法は、全員の週ごとの加重スコアボードを計算することです。毎週のチームミーティングで上位Nを表示します。おそらく、月の平均の最初の人にランチを支払うこともできます。

レビューツールを使用することをお勧めします。Gitベースのリポジトリがある場合は、Gerritレビューツールを使用できます。いくつかのコミットが拒否された後、チームは従うべき標準を学習し、今後のコミットでは追加の作業は必要ありません。

コミットはあなたの受け入れを待っています。書き換える必要のある行があれば、コメントを書くことができ、チームメイトは要件に基づいて自分でコードを修正できます。チームメンバーのコーディング標準を学ぶには本当に良い方法です。