毎年少なく吸いますか？[閉まっている]

毎年少なくなる-Jeff Atwood

私はこの洞察に満ちた記事に出くわしました。投稿から直接引用

私は、謙虚なプログラマーが改善する方法を毎年吸うことが少ないとしばしば思っていました。1年前に書いたコードに不満があるはずです。そうでない場合は、A）1年間何も学習していない、B）コードを改善できない、またはC）古いコードに再度アクセスしないことを意味します。これらはすべて、ソフトウェア開発者にとって死の接吻です。

1. これはどのくらいの頻度で起こりますか？
2. コーディングが実際に改善されるまでにどのくらいかかりますか？月、年？
3. あなたはあなたの古いコードを再訪しますか？
4. あなたの古いコードはどれくらいの頻度であなたを悩ませますか？または、技術的負債にどのくらいの頻度で対処しなければなりませんか。

古いバグを修正することは間違いなく非常に骨の折れるコードであり、期限とそれらの迅速な修正に迅速に対応するために行った可能性のある汚いコードです。それについての議論はありません。

私が出会った開発者の何人かは、彼らがすでに進化の段階にあり、コーディングを改善する必要がないか、もはや改善することができないと主張しました。

• これは起こりますか？
• もしそうなら、特定の言語でのコーディングに何年かかりますか？

関連：

あなたの古いコードのいくつかを振り返って、苦痛に満ちていますか？

コード内のスターウォーズモーメント 「ルーク！私はあなたのコードです！」「いいえ！不可能！できません！」

  > Sucking Less Every Year ?

いいえ、吸うことは毎年異なります :-)

何年も前に私の最初のレビューをした後、私は命名規則の欠落に苦しみました。

それから私は私のコードが可能な限り一般的であるように（不必要に）実装されていることに苦しみましたが、それはコードを理解し維持することを困難にしました。

次に、私はテスト駆動開発、InversionOfControl、どのドットネットジェネリック、どこに、そしてもっと多くのものをリースしました。

結論

古い悪い習慣の苦しみは減りましたが、私がもっと学んだので、私が得た新しい苦しみによって過剰に補償されました。

興味深いことに、私がこれまでに取り組んだすべての「ロックスター」プログラマーは非常に謙虚で、学ぶことに熱心で、彼らがすべてを知っているわけではないことを認める用意ができていました。ヘック、多くの人は、少なくとも気楽な瞬間に、実際には完全に自己非難していました。

コーディングを「改善できない」と思っている開発者に会ったことはないと思いますが、穏やかな言い方をすれば、これらの人たちはロックスターからできるだけ遠く離れていると私に伝えています。

次のポイントはアドバイスではなく、個人のログです。

• 使用するグローバル変数が少ない
• 変数または関数名に省略形を使用しない
• [いくつかの]テストコードを書く
• ベンチマークなしでコードを遅い（または速い）と判断しない
• アプリの負荷テストの方法を学ぶ
• それが壊れていなければ、それを修正しないでください
• ソースコード管理ツール（git / hg）を使用する
• リファクタリングはクールですが、それがもたらすテストのコストを過小評価しないでください
• セキュリティは難しいので、できるだけ早くこれに注意してください
• いくつかのオープンソースプロジェクトのバグにパッチを適用する
• 何か新しいブログ
• ユーザビリティは機能のリクエストではないかもしれませんが、それは重要です

私は一年以内にすべてを学んだわけではなく、すべてに時間がかかります...

多くの場合、優れたコードは突然発生するだけだと考えられますが、私たちのほとんどにとって、私たちのコードベースでは優れたコードが成長します。つまり、要件が絶えず変化し、完璧なプログラマーでもないため、マネージャーやプログラマーから愚かな決定が絶えず行われるため、最初から完璧なソフトウェアを作成することは非常に困難です。次に、各要件が古いコードの一部をより良いコードにリファクタリングし（そしてその代償を払うことになります！）、技術的な負債の少しを返済する良い機会を変えることがわかります。彼らが言うように、「コードをコミットするたびに、コードリポジトリを少し良くする」。その後、システムはより理想的なシステムに進化します。

私は彼のソフトウェアを誇りに思っているプログラマーはいないことを知っていますが、それは良いことです。Thanは、プログラマーがその過程で学んだことを意味します。

また、「クリーンコード」という本を読んだ場合、独自のコードの「サックファクター」が数回増加します。：D

私は実際にはこれのためにコインの両面を持っています。

一方では、古いコードを見ると、それがバグでいっぱいであり、当時知らなかった手法や言語機能を利用することで簡単に達成できる複雑な方法が行われていることがわかります。

一方で、問題に対する特にエレガントな解決策を見つけ、その当時の巧妙さで独善的なにやにや笑いを解くことは避けられません。

そして、CでGOTOを使用したという事実を、恐怖の中で数行スクロールしてゆがめます。

うーん...私はしばしば、私の古いコードの多くがどれほど優れているかにかなり嬉しく驚いています。

今日それをしていると、私はしばしばそれを違うように書くでしょうが、私が時間の制限に耐えなければならないなら、私はそうするかどうかわかりません。少なくとも数GBのRAMを備えた典型的なマシンを頼りにできる場合、大容量ハードドライブが100メガバイトの場合とは少し異なる方法でコードを書くことができます（多くの場合、そうすべきです）。

1. これはどのくらいの頻度で起こりますか？

2. コーディングが実際に改善されるまでにどのくらいかかりますか？月、年？

3. あなたはあなたの古いコードを再訪しますか？

4. あなたの古いコードはどれくらいの頻度であなたを悩ませますか？または、技術的負債にどのくらいの頻度で対処しなければなりませんか。

1. 私が何か新しいことを学ぶたびに、うまくいけばそれは毎日です。

2. 私が学んだことを実装するようになれば、それを実装したときからすぐに。

3. はい、（1）新機能、（2）バグ修正、（3）ノスタルジア、（4）解決方法を確認する場合にのみ役立ちます。

4. 1.に関連して、何かをより良くする方法を学んだとき、いくつかの古いプロジェクトはより良く「できた」と気づきました。そのままにしておきます。次のプロジェクトがより良い方法で行われることを確認してください。実際のバグでない限り、私は心配しません。

で別の質問は、被験者は自分のコードの品質を評価する方法についてでした。私の提案の1つは、数年後にそれをレビューすることでした。その経験は、コードが書かれたときよりもはるかに高くなっています。この別の質問に対する私の回答の 1つの引用は、直接あなたの質問に関連しています。

「私の場合、寿命は1年です。つまり、6か月前に書いたコードを変更できることを意味しますが、コードが2年前に書かれた場合、スローされて完全に書き直される可能性が高くなります。吸いすぎるだけだ」と語った。

はい、実際には、すべてのコード私が書いたは、1年のうちに私の観点から耐えられなくなります。また、使い捨てコードについてではなく、品質、保守性、読みやすさを念頭に置いて作成したコードについても触れています。現時点では、例外はありませんでした。

寿命についての2番目の質問に答えるには、さまざまです。使い捨てのコードの存続期間は0秒です。コードを書いた直後に吸引されますが、それは問題ではありません。私が書いたコードのいくつかの作品は我慢した2年後のリファクタリングのビット、StyleCopルールなど平均では、私の正確な場合には、寿命が変化するの強制：いくつかの化粧品の変化はなく、必要に応じて8ヶ月と1年の間についてC＃、PHPの場合は2か月から6か月。

以前のコードを再確認しますか？はい、もちろん、すべての開発者として、DRYを気にせず、自分のホイールを何度も再発明しない限り、です。また、多くのプロジェクトで使用する共通のコードベースがある場合、コードを頻繁に確認および改善する可能性もあります。もう1つのポイントは、巨大なプロジェクトに取り組んでいると、数年かかる場合があるため、古いコードを再検討する必要があるということです。

私が出会った開発者の何人かは、彼らがすでに進化の段階にあり、コーディングを改善する必要がないか、もはや改善することができないと主張しました。

自分が完璧で、何も学ぶ必要がないと言うとき、それは彼女がどれほど完全に馬鹿であるかを理解することすらできないことを意味します。

コンピュータ/プログラミングで20年の経験があっても、物事はあまりにも速く変化するため、常に新しいことを学び、コードを改善するための新しいテクニックがあります。たとえば、.NET Framework 3.0がなかったときに書かれたC＃コードは、今日の新しいもの（Linq、コードコントラクトなどを含む）で読みやすく、より良くできます。これは、古いコードであっても最も賢い開発者によって書かれました。

コードを見ていて、「これを書いたとき、私は何を考えていたのですか？」

コードの整理、コードのスタイリングなどの新しいアイデアが思い浮かぶこともあるので、通常は常に改善があり、それは大きな改善ではないかもしれませんが、すべての小さなことは役立つ価値があるかもしれません。

作業環境によっては、同じコードベースで作業を続け、そこに何があり、何を管理するかを十分に理解しているため、数年前のコードが表示される場合があります。

通常、私は既存のシステムを変更するか、システムを置き換えるので、古いコードはほとんどいつも私を悩ませています。どちらの場合でも、既存のシステムの癖を知って、それらが新しいシステムにあることを確認する必要があります。

Jon Skeetのように完璧なコードを考え出せる人もいると思いますが、コードを改善できないと言っているほとんどの人は、魅力的ではないかもしれないエゴの点から言っています。同時に、毎回大きな改善を見つけるという点では、常にそうなるとは限りません。

1.これはどのくらいの頻度で起こりますか？

古いコードに不満を感じる頻度はどれくらいですか？ほとんどいつも。私が本当に誇りに思っているコードがあるというまれな例外があります...しかし、繰り返しになりますが、それらはまれです。数年前に書いたコードは良かったと言われました...私はしがみついて、「あなたが私が書いたゴミよりも悪いものを見たので貧しい貧しい人」と思いました。

2.コーディングが実際に改善されるまでにどのくらいかかりますか？月、年？

それは通常段階にあります...私はスタイルまたは方法論に本当に入ります（たとえば、流暢なインターフェイスを使用します...それは私が巨大なウェットスタイルを持っていた最後のスタイルだったためです）、1か月または4か月間書くすべてを肉屋にします。それからそれはよりよく見え始めます。

3.古いコードを再確認しますか？

私が望むほど頻繁ではありません。私の古いコードのほとんどは、以前の雇用主が所有しています。個人コードは頻繁に白塗りされます。

4.古いコードでどれくらいの頻度で問題が発生しますか？または、技術的負債にどのくらいの頻度で対処しなければなりませんか。

以前の雇用主は私の古いコードのほとんどを持っているので、私はほとんどの個人コードをホワイトウォッシュします...それほど頻繁ではありません。