長年一人で働いていた後、他の開発者がようやく私の（バギー）コードを見るようになります。私は何をすべきか？
私は約4年間、一人でシステムに取り組んできました。私は一から作り上げました。それは完璧なシステムではありません。それは非常に複雑で、バグが多く、企業はこれを認識し始めています。
結局のところ、会社の他の開発者はプロジェクトに興味を持ち、彼らはより関与するようになっています。私は問題について彼らが私を責めることを少し心配しています。
私は偏執的ですか？他の人が同様の状況を経験しましたか？バギーコードにスポットライトのまぶしさを和らげるにはどうすればよいですか？
誰もが良いコードを好むBash/WTFセッション
彼らがバグを見つけ、問題のせいにするのではないかと今は心配です。
もちろん、彼らはバグを見つけるでしょう。自分で言った：バギー（すでにバグを見つけた）で複雑（もっとバグがある可能性が高い）。
そして、はい、彼らはあなたを非難します。これは大きなコードベースであり、時間の経過とともに、問題をコードまで追跡する習慣に慣れるでしょう。そして、結局のところ、あなたのコードはisです。
しかし、それはあなたがしたすべてが悪いことを意味するわけではないので、彼らは（if彼らは忍耐強く、十分に親切です）あなたがうまくやったビットを賞賛したり、価値を認めたりするかもしれませんコードの特に巧妙に細工された領域（と仮定してこれらが存在する）。
私は偏執的ですか
いいえですが、公平であるかどうかにかかわらず、少し批判を恐れていると思われます。
またはこれにいくつかのロジックがありますか？
上記のように、それはかなり一般的で正常です。彼らは問題を見つけるでしょう。それらの多くは。あなたはそのことをしました。あなたが結局のところ、コードの責任者であるので、彼らがあなたを非難するのは当然のようです。
ただし、これまでのやり方が必ずしもあなたの責任であるとは限りません：会社は、以前より多くのリソースと注目をプロジェクトに捧げ、より定期的なレビューを実施する必要がありました。しかし、他の開発者の観点から（そして、いまいましい、私たちはうるさくてバッシングしているのでしょうか...）、それはしばしば、「ああ、Xの有名なbad design pattern or practiceのもう1つの例」に変わります。
ミックスに多くの主観性（デザインの決定、コーディングスタイルなど）を追加します。これは、永続的なコードbashの優れたレシピです。
他の誰かが同様の経験をしていますか？
だれかが保守しているコードを書いたことのある人、または誰かが書いたコードを保守している人のほとんど。フェンスの両側にいて良かったです。
引き継ぎの準備に関するアドバイス
デザインの決定を守る。
時間をかけて設計の決定の背後にある理由を説明してください、良い点と悪い点の両方。当時あなたは片道のことをしていましたが、それには理由がありました。多分あなたは今それを違うやり方でやるだろうし、多分あなたはその時すでに別の方法を知っていたかもしれないが、あなたはその方法を選んだ。 WHYと必ず言ってください。ただし、理由が見つからない場合は...
...言い訳をしないでください。
あなたのせいで何かひどいことがあったら、そう言ってください。彼らはあなたをもっと尊敬します。当時あなたが環境に優しかったためにコードの一部がうまくいかない場合は、そう言ってください。その時あなたがより良い方法を知らなかったのでそれが嫌なら、そう言ってください。時間がなかったので嫌だったら、そう言ってください。 どうして時間がなかったのかは気にしません。しかし、あなたがその時に上手くやることができなかったことを知っているのは良いことです。 責務を値する場所と時期にそらさないでください。
ダメージコントロールの第1規則を覚えておいてください
他の誰かがする前に、それを公開してください。
そして、私たちは すべてのおよび非常に早い を意味します。政治家、銀行家、報道機関、マーケティング機関に役立つものは、がらくたコードにも（そして人生のあらゆる面に）働きます。
あなたのねじ込みが出なければならないなら（そしてここで彼らはそうするでしょう）、それは彼らはあなたの条件で出てきて、あなたがコントロールを保つが最善です。
汗をかかないで
あなたは打ちのめされ、あなたのキャリアの期間中、他の開発者を打ちのめします。
必ず気楽な、肯定、開いたにしてください。それは双方向の道なので、派遣には親切にします厳しいが正当化される批判とし、自分の分担を受け入れるには控えめににします。
そして、あなたが何をするにせよ、聖なる戦争から逃れなさい。
個人的体験
個人的に、私は時々同僚にとても不親切だったり、私の時間より前に人々によって書かれたコードについて不親切なことを言ったりしたことがあります。そして、ほとんどの場合、私の批判が少なくともいくらか創設されたことを願っていますが、さまざまな（おそらく悪い）理由で、そうではなかった時期もあったと思います。
私たちはみんながらくたをします。他のふりをしないでください、これで眉をひそめている他の読者は私はあなたにかかっています！
私も数回殴られました、そして私はそれが正しいと思ったとき私は自分の立場に立った（または戦略的に価値がある）。しかし、私はめちゃくちゃであるため、容認された非難も頻繁に行っています。そして、私はまだ毎日やっています。前述のとおり、通常は理由があります。
この結果として、同僚と非公式のコードバッシングセッションを開催することが伝統になっています。悪い種類ではありません（このサイトでは、「良い」種類のコードbashが存在できるかどうかについて、真剣に議論されていますが）。金曜日の午後にキックバックして、コードベースの暗い領域を見てコーヒーを飲み、その週のベストピックを強調するようなものです。次に、それらを修正します。そして、あなたは彼らに責任を割り当てません。あなたは「Xをするなんてばかげたやり方だ」とさえ言わない。それをくすぐり、リファクタリングし、同僚と一緒にレビューして、リファクタリングが吟味され、履歴が繰り返されないようにして、次に進みます。
そして、あなたは何を知っていますか？時々、どこかおかしなコードにぶつかって、それが自分のものであることに気づき、謙虚にバッシングのためにそれを提出するでしょう。あなたが吸ったので、そして公正なものは公正です。そして、あなたがそれを仮想または物理的な壁に固定して、すべての人が見て、将来それを避けることを忘れないようにします。
ちなみに、私の会社では、プロセスに必要な正式なレビューミーティングを行っています。また、他の人に私たちのものを精査してもらいたいと思うときはいつでも、非公式なミーティング（より頻繁に）があります。さらに、非公式のコードバッシングセッションも開催されます。しかし結局のところ、それらはすべて同じ結果をもたらします。私たちはコードを改善し、それが重要なのです。
Jeff AtwoodがThe Daily WTFの何が問題なのか（彼を強調）に入れます：
[The Daily WTF]は治療的であり、教育的です。しかし、問題のコードが壊滅的に愚かであるか、単なる不適切な助言であるかにかかわらず、私たちはそれについて何かをしなければなりません。私たちがそうするまで、私たちは暗黙のうちに、悪質なコーダーが悪質なコードを書くという苦痛で費用のかかるサイクルを無限に永続させています。そして、それは私たち全員を傷つけます。
そして一般的に、あなたがこのようにそれに近づくと、それはかなりポジティブなものとして現れます。 あなたはコードを改善し、人々はより寛容になる傾向があります。私たちは時々、この世の外にある種類のバグ、ハッキング、または明らかに意味のないコードの一部を好意的に覚えていますが、その後、新しいco -workerが現れて、「ちょっと待って、どうしてそんなことをするほどクレイジー/ダムなことができたのだろう！」彼らが私たちのコードbashアーカイブの1つに遭遇したとき、私たちは肩をすくめてと言うだけです。
そして、あなたはあなたが去った後、人々が同じ態度を持っていることを望みます...しかし、あなたはそれをとにかく知ることはありません。
確かに、73個の異なるパッケージ間で複製された 定数乱数ジェネレータ またはisEmpty(String)実装は、まったく愚かなように見えるかもしれません。そして、それは完璧なシナリオです。しかし、おそらく、その男はその完全なおとぎ話のシナリオにはいませんでした。男は当時、理由がありました。多分良いものではないかもしれませんが、それは問題ではありません。たぶんそれは、締め切りが通り過ぎるうっとうしい音だったのかもしれません。
彼に休憩を与えなさい。私がリストしたいよりも多くの理由により、私はいつもおかしなコードを書いています。私たちは皆そうです。あなたの同僚が2セントの価値があり、完全なジャッカスではない場合、彼らはあなたに疑いの同じ利益を与えるでしょう。
誰もくそー！
しかし、その後再び... 誰が気をつけますか？
それはあなたのコードです。それまで所有します。あなたの過ちまで自分のものにしなさい。
補足：オープンソースの場合
これは、オープンソースが優れていると言われている分野の1つです。結局のところ、他の誰かの賢明な言葉で：
十分な眼球があるとすれば、すべてのバグは浅いです。
開発フェーズで目玉が増えると、本番フェーズでバグが発生する可能性が低くなります。監視を恐れる必要はありません。
群衆が大きくなるほど、厳密な監視が必要になると思われます。しかし奇妙なことに、一部の大企業では、精査のレベルはエンジニアリング要員の規模にまったく関係していません。
[GREAT] Googleのような会社は、ほとんどのプロジェクトに単一のコードリポジトリを持っているので、ほとんどすべての人が何でもを表示、レビュー、コメントできます。
[BAD]その他、いくつかの良い理由と悪い理由のために、すべてを区分けし、数人だけがコードをレビューします。その結果、バグと重複が発生します。
オープンソースは精査の採用を奨励します。
はい、誰かが初期の頃に行ったメモリ割り当てを引き起こした、非常に大きな太ったブーブーを引き起こし、深刻な結果を招く愚かなパディングエラーを掘り下げることができます。だから何？誰かがそれを見つけたので、それは今なくなっています。そして、あなたが今でも間違いを犯すとは誰も言っていない。あるいは、おそらく、私たち全員がコーヒーを必要とする日があるからです。それとも、私たちはまだ吸うだけです。しかし、それは問題ではありません。あなたががらくたコードを試して修正しようとする人々の巨大な群れがあります-彼らが使用するために何か価値があるなら。あなたはそれを受け入れる必要があります飛躍の信念：人々は一般的に慈悲深くなり、あなたは生涯傷つくことはありません。そして、あなたはWorld's Worst Developer Ever Everのシールでブランド化されません。かなりの国、これはあなたが時間をかけて改善するのに役立ちます。神秘的な孤独な開発者は良くなるかもしれませんが、チームでの作業中に強力で有用なフィードバックを受け取ることはできません。
精査を恐れているなら、あなたは間違ったゲームにいます。
彼らがバグを見つけ、問題のせいにするのではないかと今は心配です。私は偏執狂的ですか、またはこれにいくつかの論理がありますか？
ソフトウェアが完了しない
それは古いことわざとともに-" 良いソフトウェアは決して完全ではありません "。
すべてのソフトウェアは、安定した段階に到達する前に、進化し、反復を繰り返す必要があります。最終的に欲求不満が高まり、別のプロジェクトを開始して、製品が提供するものと現在のビジネスニーズとの間のギャップを埋めることができます。プロジェクトが開発され、提供され、サポートのために引き渡されるまでに、新しいギャップが生じ、このサイクルは継続します。
したがって、私は心配せずに、現在のプロジェクトを現状のままにして、初期の前提に基づいて構築されたものであり、改善と修正が必要であることを述べます。
透明であること
プロのソフトウェア開発者にとって、チームメンバーと透過的であり、新しいことや提案を受け入れることは常に良いことです。したがって、生産的なチームビルディングをフォローする方法です。そして、スキルと知識の透明性のあるコラボレーションは必須です。
非難されないことを望みます。同社は、大規模で複雑なアプリケーションをできるだけ堅牢にするために必要なリソースを投入できなかったため、JRを使用していました。それに開発。おそらく、そのアプリは当時それほど重要であるとは予想されていなかったのかもしれません。彼らがプロジェクトを続行したいという事実は、おそらくあなたが正しいことをしたことを示しています。これで、いくつかのヘルプを取得し、いくつかのことを学び、多くのコードをリファクタリングできます。このビジネスに新しいものはありません。
ソフトウェア会社を経営していて、中間管理職がエントリープログラマをそのようなプロジェクトの問題のせいにしようとしているといいのですが。 「私たちは彼に5年間コードを任せましたが、何の助けも、サポートも、コードレビューもありませんでしたが、彼はより優れたプログラマーだと思いました。」マネージャーを十分な速さで解雇できますか？これは、マネージャーのふりをして、このプロジェクトへの責任を完全に放棄した人物です。
雰囲気をポジティブに保つ
すべてのプログラマがバグを見つけることを期待していることを確認してください。彼らが問題を解決することで賞賛されることを確認してください。他の興味深い問題に進むために必要な支援を得ていることに感謝します。
防御的であることを避ける
ごめんなさいと言ってはいけません。動揺しないでください。課題がある場合は、それらを解決するための改善されたプロセスを提案します。多分あなたは新しいテスト手順が必要ですか？多分あなたはより良い要件が必要ですか？
それはあなたのコードではありません。それは会社のコードです。
彼らはあなたがコードの深刻な外部検査なしで4年間行くことを許可した人です、彼らは責任を負うべきです。 （とは言え、あなたはそれを書いたので、たわごとの一部は固執します）。
私はこれを、本当に素晴らしい（苦しいのであれば）学習体験に乗り出す機会ととらえます。レビュー担当者よりもコードに難しいことができる場合、否定的な防御要因ではなく、このフェーズの肯定的な推進者と見なされます。 。
私はあなたとまったく同じ状況です。私がいる場所は、過去5年間の経験で、自分の時間の80％をゼロから内部で使用するシステムの構築に費やしてきました。
これは私の最初の仕事です。つまり、それは私が卒業した後に最初に得た仕事です。私も、あなたと同じように、今日とまったく同じシステムで作業を開始した場合、状況が異なることを知っています。しかし、それは経験の美しさです。自分が犯した間違いを特定できる限り、それは良い兆候です。何かを学んだということです。
あなたが自分自身を識別していないが、他の人がおそらくそれを理解するであろうことについては、あなたが得るフィードバックを受け入れ、そこから学ぶ。あなたが得るフィードバックを恐れないでください。あなたがそれを作ったとき、あなたは理由のために物事をしました、そして、物事が特定の方法で作られた理由を説明する限り、それから良い議論の根拠があります。結局のところ、あなたはすべて大人なので、大人と同じようにそれについて話したいと思います。 「責任」の問題は;あなたはシステムを構築した人なので、それについて話すことも無意味です。あなたはそれがあなたの「欠陥」であることを皆知っています。それを改善する方法に焦点を当てる必要があり、あなたは無料で素晴らしい学習の機会を得るでしょう。
私が構築したシステムを他の誰かに見てもらいたいと思います。私はあなたと同じように一人で仕事をしています。何かが足りない場合は、同僚と私の仕事について話し合うことができます。私はあなたが機会を大切にすべきだと思います:-)
他の人が言ったように、これはプロジェクトを学び、改善する絶好の機会です。
さらに、高いアーキテクチャの観点から現在の状態を文書化するも試してみます（まだ行っていない場合）。ここではクラス図について話しているのではなく、パッケージ図やコンポーネント図、あるいはおそらく非常に大まかな（データ）フローチャートについて説明しています。
これは、新しいフェローがプロジェクトの概要を短時間で把握するのに役立ち、最初にクリーンアップしたい場所を自動的に表示します。