コードがごちゃごちゃだと誰かに言われたらどうしますか？
私は良いプログラマーなので、以前は考えていました。私はいつもプログラミングが大好きです。そして、私はより良いプログラマーになるためにプログラミングについて多くのことを学びたいです。私は1年間プログラミングを学び、現在はプログラマーとして約2年間働いています。つまり、私はプログラミングの経験が3年近くあります。
私たちのチームは5人のプログラマーで構成され、うち4人は初心者、1人は3年以上の経験があります。私たちは、ほぼ1年間プログラムに取り組んできましたが、誰も私のコードを確認したことがなく、操作するページが与えられました。コードレビューを行ったことがなく、すべてが新しいので、クリーンなコードがどのように見えるのかわかりません。プログラマは自分で学ぶと思いますか？
徹底的なテストを行わずにプログラムをプログラムに展開しました。現在は厳しく、コードに変更を加える前に、まず承認とコードレビューが必要です。初めて、誰かが私のコードをレビューし、彼はそれが混乱していると言います。
とても悲しくて痛いです。私はプログラミングが大好きで、そのようなことを彼らに言わせると本当に痛いです。本当に上達したいです。しかし、私は映画のような天才プログラマーではないようです。より良い方法についてアドバイスをいただけますか？コードを批判する何かを経験したことがあり、本当に傷ついたことがありますか？それらのイベントで何をしますか。
真実はおそらくあなたがあなたの現在のコードを見る2年以内にあなたはそれが混乱であったことに同意するであろうということです。プログラミングの学習は終わりのないプロセスであり、常にあなたよりも上手な人がいます。
だから、あなたのコードが混乱していると言った人が単に卑劣ではなく、それがプログラマーの間で一般的な「私はそれをより良くする」病気の別のケースではない場合、あなたは彼/彼女にあなたのコードの正確な何が間違っているのか、そしてどのようにあなたはどうすればいいのか尋ねる必要がありますそれを改善。
コーディングの良さに誇りを持たないでください。どれだけ上手に学べるかを誇りに思ってください。次に、コードの改善が必要であることを学習すると、プログラマーの悪さを非難するのではなく、学習の腕前を示す機会が得られます。
http://www.perlmonks.org/?node_id=27008 私が何について話しているのか分からない場合は、読んでください。
20年以上後、私は自分のコードの一部がまだ混乱していることを知っています。結局のところ、可能な限り最高のコードを書くことと、仕事を成し遂げるために必要なものを書くこととの間で決定を下すことです。合意された時間枠内で仕事を成し遂げることは、いつでも技術的な完璧を求める終わりのない探求に勝るものです。
トリックはそれを受け入れることを学ぶことです。あなたがもっと上手くできることを受け入れることを学ぶ。欠点と共存することを学ぶ。今回、そしておそらく次回も完璧にするつもりはないこと、そして代替案が提供していないため、それは意図的な選択であることを受け入れることを学んでください。そして、それはさらに悪いことです。
免責事項：これは「不正なコードは問題ありません」と読むべきではありません。
誰のコードもごちゃごちゃしていて、良いプログラマはいない。
がある：
- 速く出荷するプログラマー
- 意味的に正しいコードを常に出荷するプログラマー
- 常に最適なソリューションと最速のアルゴリズムを思いつくプログラマー
- 目に優しいコードを持つプログラマー。
彼らは、たとえあったとしても、同じ人になることはほとんどありません。
そして、成長する必要のあるお尻のプログラマーがいます：
- 何が悪いのか尋ねてください
- 人間としての価値の尺度として、個人的にはコメントしないでください。
- チームには構文のガイドラインがあることを理解してください、そしてそれらは従わなければなりません、そしてそれらはある任意なので、それらは議論されることを意味していませんad nauseam、最適なソリューションも最終的なWordもないため。
- 彼らのコードをコメントするのが上手になります。
- 彼らのコードをコメントするのが上手になります。 （sic）
- デバッグがより簡単で、賢くなく、シンプルで平凡なタスクのソリューションを見つける。
- sQLでクラスを取る
（安全のために、この世界の人口の半分をSQLのクラスに送ります）
アートではなく、クラフトです
当然のことながら、あなたは賢いです。コンピュータをプログラミングしているのです。
まだAMD64およびx86は、あなたの散文の力に強いられません。物事をシンプルに保つ。
まあ、あなたのコードが混乱していると言う人は、たとえそれが正しいとしても、建設的ではありません。彼らはそれが混乱している理由をあなたに与えましたか？同様に、メソッドが長すぎる、責任が混在している、分岐が多すぎるなどです。正直なところ、1年前に書いたコードは、それ以来、たくさんのことを学んできたので、まったくがらくたです。だから、気分を害しないでください。あなたがずっと前に書いたコードを読むのが好きなら、もっと心配になるでしょう。
コードベースがきれいであればあるほど、特定の問題を解決するためにコードベースと戦うために費やす時間が少なくなります。プロジェクトの早い段階で行った設計上の決定の苦痛を感じることができるので、1年は今あるべき素晴らしいポイントです。
私の現在のプロジェクトでは、テクノロジースタックに慣れてきたら、何度かリファクタリングを行いました。これは奨励されるべきであり、現在のコードベースのために、彼らが必要とするよりも長くかかるタスクを書き留めるべきです。
あなたが書いたコードの古い部分のいくつかを見てきましたか？おそらく、今は別の方法で実行したり、リファクタリングしたりすることを確認できます。
また、テストの欠如について言及する場合、これは常に注目すべき点です。私たちのプロジェクトでは、自動テストが行われなかったため、多くの高度に結合されたコードがありました。ユニット/統合/テストを定期的に記述しなくても、少しの間それを行うことで、コードをよりモジュール化する（その結果、混乱を減らす）習慣を身に付けることができます。
とても悲しくて痛いです。私はプログラミングが大好きで、そのようなことを彼らに言わせると本当に痛いです。本当に上達したいです。
それはいいです。それはたくさん「私のレビュアーは彼が何を話しているのかわからない」、「私のレビュアーはうるさい」、または単に「私のレビュアーはしません私のように」それらを無視します。この態度はいいことです。
しかし、私は映画のような天才プログラマーではないようです。
どのような映画を見ているのかはわかりませんが、映画のプログラマーの90％は偽物なので、シーケンスの終わりまでに涙が出ます。
より良い方法についてアドバイスをいただけますか？
読んで練習してください。 Code Complete または The Pragmatic Programmer のような本をチェックしてください。アマゾンで同様の本を探してください。
コードを批判する何かを経験したことがあり、本当に傷ついたことがありますか？あなたはそれらのイベントで何をしますか？.
なぜ怪我をするのですか？そもそもこんなバカな自分に失望している。私はその動機を使ってコードをクリーンアップし、同じ間違いを繰り返さないようにします。最後に[〜＃〜] i [〜＃〜]はそれから学ばないようにしたいです。あなたは一度沈黙しました、同じ理由でそれを再び起こさせないでください。
完璧である、または身近なプログラマさえ生まれません。あなたが書くコードが多いほど、あなたが得るレビューとあなたがレビューするprovideは、オールラウンドでより良いプログラマーになります。
開発者であることについて私にとって最高のことの1つは、毎日が学習プロセスであるということです。あなたがしていることを知らない誰かがいつもそこにいるでしょうし、あなたがしていないことを知っている誰かがいつもいるでしょう。私は確かに自分がどこにいるとは思わないでしょうが、エントリー/ジュニアレベルではありませんが、正当化され、尊敬の対象である限り、どんな批判も受けることができます。
似ていると思われる類推は、私が大学で執筆講師を務めていた期間、および創造的な執筆コースに参加した時期に関連しています。コードを書くことは、すべての意図と目的のために、詩、エッセイ、短編小説、または小説を書くのとよく似ています。個人はそれぞれ独自の方法でそれを実行しますが、同時に、優れた作家（この場合は開発者）でさえ、ミスを犯したり、亀裂をすり抜けたりします。自分の声（またはこの場合も、コードのスタイル）に慣れているため、これらのことに気付かないことがよくあります。
どの分野でもそうであるように、専門家と見なされている人もいます。それらの人々が存在しなかったとしたら、誰からも学ぶことはできません。問題のこの個人が本当に専門家であると仮定して、私は彼が言うことを聞いて、彼があなたのコードを改善するためにあなたに何を提案するかを尋ねます。しかし、彼を助けることができるのは彼だけではないことを忘れないでください。 SE/SOなどのリソースが豊富にあるという幸運があります。
混乱はかなり主観的です。あなたができる最善のことは、その人（またはレビューレポート）に実際に尋ねることです：なぜそれが厄介なのですか？（彼らの観点から、つまり）
彼らはあなたに答えるはずです、そしてあなたはどちらかができるでしょう：
- それに対する議論（もちろん、そうする正当な理由がある場合）
- あなたは新しいことを学んだだけでとても幸せな気分になります。彼らのアドバイスのおかげで乱雑さを減らす方法がわかったので、将来のコードはもっと素晴らしいものになるはずです。
あなたが心配しているという事実は良い兆候です。それから始めましょう。プログラミングが好きだとおっしゃっていますが、プロのプログラマーであることは好きですか？愛好家とプロの間には大きな違いがあります。専門家として、あなたはあなたの仕事の成果を常に監視されます。
Our team is composed of 5 programmers, and 4 of us are new
あなたが対立することなく2年間働いたという事実は、あなたが非常にのんびりした仕事で働いていることを教えてくれます。あなたが実際にプロとして前進したいと思っているなら、それはあまり良くありません。心に留めておいてください。世界で最高のプログラマーの一部はLinux財団で働いており、彼らがマージナルミスを行っても優しく扱われないので安心してください...コード'。
かなり標準的なコーディングガイドラインを簡単に確認するには、 Linux Community Contributors Standards を使用して、製品を目指す責任のレベルを把握してください。適切なコードの入手を参照してください。
その主張をさらに進めるには、ほとんどの優れたソフトウェアが徹底的にレビューされるため、レビューを受け入れることを学ぶ必要があります。これは Linus 'Law をサポートしています...
「レビュアーが十分であれば、すべての問題を簡単に解決できます。」
個人的には、非常に熟練し、責任があり、信頼できる開発者が、コメントを残すのを忘れるような単純なことのために斧を手に入れているのを見てきました...リファクタリング。それはギグの一部です。
I feel so sad and hurt.
悲しみのアプリケーションを作成して、自分を適用しない場合の怒りの程度を測定します。
あなたはあなたの問題に答えました...あなたはテストしません！
あなたがa Java=開発者であることに、私はほとんど動揺しているとコメントしました。そのため、あなたとあなたの開発チームがJava購入して、アプリケーションのテストフレームワークがありません...
そこで嘘をつきます
「テストを行わずにプログラムをプログラムに展開しました。」
UMLクリエーターのクリビング Grady Booch ...
アマチュアソフトウェアエンジニアは常に、魔法、いくつかのセンセーショナルな方法またはツールを探しています。そのアプリケーションは、ソフトウェア開発を簡単にすることを約束します。そのような万能薬が存在しないことを知っていることは、専門のソフトウェアエンジニアの印です。
Alistair Cockburn アジャイル手法を使用して、あなたとあなたのチームのパフォーマンスと品質を向上させることについて、彼のサイトに豊富な情報を提供しています。
プログラミング（および人生）の最も重要な側面の1つは、あなたの長所と短所を知ることです。自分の弱点に取り組んでいないと、バランスの取れたスキルセットが得られません。
アウトロ...あなたは元気です-ただ駄々を言ってはいけません。クラフトの開発を進め、プログラミングへの情熱があなたを動かし続けます。幸運を ：-）
あなたの感情がコードを改善する邪魔にならないようにしてください。コードレビューの目的は問題を見つけることですので、問題があっても驚かないでください。そうは言っても、それらはコーダーバッシングセッションではありません。
彼らはまた、単に「Ewwww」と言ってそれをそのままにすべきではありません。プログラミングに問題がある理由は常にあります。たとえば、たくさんのコメントアウトされたコードをあちこちに残しておくのは間違っていますが、誰かが本でそう言ったのではなく、コードが乱雑になって読みにくくなるので間違っています。
あなたのコードはあなたではありません。覚えておいてください。
私はここでディックになり、それに基づいてアドバイスをします。明らかに、あなたのコードIS混乱またはあなたが尋ねるであろう質問は、「なぜ誰かが私のコードが混乱していると誰かが言っているのですか？」ですが、あなたは仮定に挑戦していません。演技は傷つき、率直に言って泣くかもしれませんが、プログラミングを正当化することになるとは感じません。
しかし、本当に、なぜあなたは尋ねているのですか？あなたはあなたのコードが悪いことを知っているか、あなたは別の質問をしているでしょう。誰かが私のバックエンドWebコードスタンクを私に言ったら、私は笑って「それで何が問題なのですか？」彼らが私のJavaScriptの悪臭を私に言った場合、私は彼らにファットリップに相当するソーシャルプログラマーを与えます。小さな愚痴は明らかに間違っているので、私はどのように反応するかについてアドバイスを求めることはありません！@＃$ ing間違っています。
あなたが得意なことを自分のものにします。そして私は本当にそれに責任を取ることを意味します。それはあなたが二番目に推測するのに少しのひねりのためにたった一回で済むからです。善であるように許可を求めないでください。ちょうどあなたのことを知っています。終わり。
これを覚えておいてください：あなたが見る最悪のコードはあなた自身のものです！
Codinghorror.comのJeff Atwoodがこのトピックについて多くのことを書いたので、ここから始めたいと思うかもしれません： http://www.codinghorror.com/blog/2009/07/nobody-hates-software-more-than-software -developers.html
改善したい場合は、コーディングスタイル、パターン、ワークフローなど、基本的にすべてを手に入れることができるすべてのものを読み始めてください。また、より多くのプログラミング言語を学び、それらがどのように機能するかを見てください。 OOPを実行している場合は、次をお読みください： http://en.wikipedia.org/wiki/Design_Patterns
また、他のプログラマーと話し合ったり、ペアプログラミングを行ったり、他のコードを監視したりしてください。
間違いを犯すことは避けられません。
ほとんどの場合、これを言った人に「ありがとう」と言うべきです。
おそらく、彼らは自分の職業を重視し、仕事を重視し、チームを重視し、あなたを重視しています。
批判を受けるのは難しいかもしれません。それについて怒らないでください。彼らがあなたに伝えようとしていることについて考え、あなたの感情があなたをより良くさせないようにしてください。
私は長い間（30年）プログラミングをしてきましたが、私のスタイルとコードは常に改善されています（私はそう思います）。私がその改善を知る唯一の方法は、他の人が私に言ったとき、または私が戻って自分のコードをレビューしたときです。
キャリアの初めに書いたコードを見てみてください。今、あなたはどうですか？あなたが書いたときに思ったのと同じくらいよく見えますか;）
まず第一に、プログラミングは、記事や本を書くのと同じように、反復プロセスであることを理解する必要があります。まず、プログラムを機能させるために、プログラムの「ラフドラフト」を記述します。この段階では、コードは混乱します。したがって、コードをクリーンにするためにリファクタリングします。次に、プロファイルを作成し、高速化するために最適化する必要があるものを確認します。トリックは継続的にリファクタリングすることです。さもなければ、混乱が大きくなります。家の掃除と同じように、定期的にコードを掃除する必要があります。
コードレビューは絶対に不可欠です。少なくとも1つの目でコードを見る必要があります。コードを無数に見て何時間も費やすと、そのコードに慣れ、同僚がすぐに気づくバグやコードの匂いを見逃してしまいます。
また、コードを誰かに説明することは、何かを見落としていないかどうかを確認するための優れた方法です。これは、大声で書いている紙を読むようなものです。脳はさまざまな方法で音声情報と視覚情報を処理し、モダリティを切り替えることで推論の欠陥を見つけることができます。また、コードを同僚に説明し、彼女にとって何かが意味をなさない場合は、コードをリファクタリングする必要があることを示しています。
コードレビューを行う場合、作成者とレビュー担当者の両方がドアでエゴをチェックすることが非常に重要です。目標は、コードを改善することです。そのため、査読者は敬意を払う必要があり、著者は心を開いておく必要があります。覚えておいてください、あなたの同僚はあなたのコードを維持しなければならないでしょう、それで彼らにはそれが明確でなければなりません。レビュー担当者が変数の機能を理解していない場合は、名前を変更します。レビュー担当者がコードブロックの機能を理解できない場合は、説明的な名前を付けて関数にリファクタリングします。何を考えていても、同僚が自分のコードを理解できないのはよくありません。
リファクタリングと言えば、絶対に単体テストフレームワークが必要です。それがないと、リファクタリングができないからです。
最後に、Robert C. Martinの「Clean Code」を読むことを強くお勧めします。それはあなたのコードが混乱している理由とそれをきれいにするために何ができるかを教えてくれます。
より良い方法についてアドバイスをいただけますか？
本を勧めるジェイの答えは良いですが、あなたはすでに仕事の転換点にいるようです。
過去：
私たちのチームは5人のプログラマーで構成され、うち4人は初心者、1人は3年以上の経験があります。私たちはプログラムに1年近く取り組んでいますが、誰も私のコードを確認したことがなく、作業するページが与えられました。
現在：
現在は厳しく、コードに変更を加える前に、まず承認とコードレビューが必要です。
あなたの会社/チーム/部門は、プロジェクトとチームの管理およびプログラミングの面で全体的に学習しているようです。コードのレビューを始めることは、適切な注意が払われれば、ほとんどすべての領域で改善する絶好の機会です。
これを機会として使用してください。ピアレビュー（チームの他の開発者と共に）を行っているとすると、このプロセスは重要であり、誰もがそこから学ぶことができると彼らに提案します。
ベースラインで、それは「ええ、大丈夫です」という結果を伴う簡単なレビューになります。もう少し焦点を絞った努力で、アイデアを互いに跳ね返すことができます。「うん、うまくいきますが、このようにしてアプローチすることで、目標がより明確になります...」コードのデプロイに問題がないと思われる場合でも、将来のためにメモを取ってください。
これが成功する場合は、チームとマネージャーを側に置く必要があります。これは、多くの場合、チームとマネージャーにメリットを説明することを意味します。他の開発者にとって、これは学ぶ機会です。上司にとって、これは少ないコストでチームをスキルアップする機会であり、したがって、a）より価値のある、またはb）より速いc）より少ないメンテナンスコストで（通常は大きな問題です）出力を作成します。
これは文化の変化であり、自分で強制することはできませんが、正しい方向にナッジするのに役立ちます。
忘れないでください。これは一種の文化の変化であり、組織にとって非常に有益です。優れたマネージャーは、あなたがチーム全体をより良くするために努力していることを認めるでしょう。
より良い方法についてアドバイスをいただけますか？コードを批判する何かを経験したことがあり、本当に傷ついたことがありますか？それらのイベントで何をしますか。
これに対する答えは新世代の企業にあります。私はGoogleやFaceBookなどの企業に行ったことがありますが、アジャイル/スクラムのプロセスに忠実に従っている場合は、より優れたコードを記述し、すべてのスプリントを改善できることがわかります。
How to be better?
答えは継続的なリファクタリングです。 Visual Studioのような最新の開発ツールには、このプロセスを支援する多くのツールがあります。スクラムソフトウェア開発プロセスに従っている場合、たとえば、スプリントサイクル1で不良コードを記述し、レビュー中に誰かが不良であると指摘した場合、スプリント2でコードをリファクタリングする機会があります。
これらの問題は、適切なプロセスの欠如のためにそもそも発生しています。したがって、解決策は、チームのための優れたソフトウェア開発プロセスを考え出し、継続的なリファクタリングを実践することです。
まず、あなたのコードが混乱であると誰かが言っているのは非常に曖昧で主観的です。人によって意味が異なる場合があります。これが理由です。考慮しなければならないことが2つあります。
構造
コードの構造は、いくつか例を挙げれば、言語、業界標準、企業標準によって管理されています。明らかに他の要因もあります。
これらは、糸くず、テストツール、および類似の製品が特定するように設計されているタイプのミスです。それらは明確に定義されており、あなたまたはあなたのツールは、それらの有効性/正確性に関して客観的な決定を下すことができます。
スタイル
コードの標準化された構造/ルールにもかかわらず、すべての開発者は、問題やタスクを記述してそれに取り組む方法に特定のスタイルを持っています。任意のチーム環境でコードのメンテナンスを行うと、時間の経過とともに、スタイルに基づいてコードを書いた人について知識に基づいた推測をすることができます。また、独自のスタイルを開発し、経験を積んでクラフトを習得すると、スタイルが変化します。
したがって、誰かがあなたのコードがmessであると言うときはいつでも、構造について話しているかどうかを理解する必要がありますまたはstyle。これらは2つの非常に異なるものです。 構造は客観的ですが、スタイルは完全に主観的です。
そうは言っても、他のプログラマーからの建設的なフィードバックはあなたにとって非常に価値があります。それはあなた次第であり、あなたがどのように批判を受け入れるかはあなた次第です。時間が経つにつれ、誰が真剣に考えるべきか、誰が塩の粒を持って考えるべきかがわかります。
キャリアが進むにつれ、自分のコードを振り返り、さまざまな方法で、より良く、よりクリーンに、より速くできることを確認できます。それはすべて学習プロセスの一部であり、自分自身の過去の過ちを確認することは、あなたが自分の技術を磨き、改善しているという真の兆候です。
少しの批判があなたの精神を弱めさせてはいけません。そこからできることを取り出し、それが意味があり価値がある場合は、知識のストアに追加してください。
フィードバックに感謝し、何が悪いのか、どのように改善する必要があるのか説明してもらいます。
フィードバックを提供する人が理にかなっていることに同意する場合は、将来変更することを検討してください。しかし、誰かが言ったからといって、それが真実であるとは限らないことを覚えておいてください。
「混乱」と呼ばれるものの具体的な例を挙げていただけますか？
自分のコードが混乱していることを認識することは重要ですが（プログラマーの間の非常に典型的な感覚、特に経験を積むようになり、コードが古くなるにつれて）、それはさらに重要ですmore他の人が言うときに聞くことが重要ですあなたはそう。
現在のプログラミング知識の制約で作成されたため、独自のコードで認識できる問題はそれほど多くありません。
コードのレビューは、学習に欠かせない学習機会です。コードの作業中にあなたが持っていなかったnew知識にさらされる可能性が高いからです（そうしないと、コードを使用して混乱することはありません）。
否定的なフィードバックの処理には2つの部分があると思います。
1。提起された問題の性質と、そこから何を学ぶべきかを決定する
コードを確認するか、コードを確認してもらうと、コードの問題に関する情報を大まかにそのようなバケットに分類します。
- 厳しい技術要件に違反している
- 明らかに間違っている（機能しないか、要件に適合しない）
- 他の状況では失敗します（環境/構成の変更）
- 廃止予定の機能を使用しており、近い将来に機能しなくなります
- 業界のベストプラクティスに違反しており、などに欠けている
- 特定の問題に対して実績のあるアプローチを使用する
- パフォーマンス
- 後方互換性
- メンテナンスが簡単
- コーディングスタイル
- ドキュメンテーション
- 職場のベストプラクティスに違反している
- 業界と同じですが、会社/同僚に固有であり、詳細は業界と異なる場合があります
- 個人の専門知識と一致していない
- 見直している人の意見では、何らかの方法で改善することができます
これは非常に客観的なもの（「これは本番サーバーにデプロイすると壊れる」）から非常に主観的なもの（「変数に名前を付ける方法が好きではない」）までさまざまです。
2。（もしあれば）コードのどの変更がレビューの結果として行われるかを決定します
情報が処理された後、それが実行可能かどうか、およびコードを変更する必要があるかどうかが決定されます。これは必ずしもあなたの決定であるとは限りません。関係者やあなたの状況の詳細（年功序列など）に応じて、あなたの意見が重要な場合と重要でない場合があります。しかし、可能な結果はおおよそ次のとおりです。
- 問題を完全に解決する
- 壊れた修正
- 必要なコーディングスタイルにフォーマット
- 等々
- が存在する可能性があるため、問題のすべてまたは一部に対処する必要がある場合は、妥協する必要があります。
- リソースなし（時間や予算など）
- 必要なし（取るに足らない改善、安定性の妥協などのみを達成します）
- 提起された問題が無効であることを理解するようになる
- フィードバック（特に主観的な意見のカテゴリーからのフィードバック）は非常に有害である可能性が非常に高いため、盲目的に行動すべきではありません
否定的なフィードバックを得ることは苦痛であり、将来的には毎回苦痛になる可能性が非常に高いことを学びました。しかし、それは重要な学習機会である方法と、プロセスがどのように専門家と職場を改善してより良いコードベースを達成するのに役立つかを学んだままです。
まあ壊れた感じはありません。結局、あなたは間違いから学ぶでしょう。あなたが問題を終えたら、あなたは彼にあなたが改善したいのだと感じさせるように話しかけることができます。もっと耳を傾け、論争を減らしましょう。
私はこの状況を経験しており、理解することができます。
TL; DR
コードがごちゃごちゃだと誰かに言われたらどうしますか？
私の率直な「長すぎて読みませんでした（すべての回答-謝罪、後でうまくいけば時間を見つけて、必要に応じてこれを編集/修正します）」回答/ヒント：
- 古き良きピアレビュー。さまざまな集団的メンタリティ、専門知識レベル、および/またはaggressivenessのレベルを持つさまざまなスタッフにコードをレビューしてもらいます。
- 「異なる」ピアグループの意味を少し詳しく説明します。Stackdのディアスポラは、Redditなどと比べて、その一部になるのが比較的難しいため、おそらく最も緊密で専門的で尊敬されているグループです。 Redditは人気のあるサブredditsで非常に攻撃的になる傾向がありますが、奇妙なことに、プログラミングサブredditは非常に友好的です（私が経験したものから）。
アグレッシブなギャングスタタイプのクリークメンタリティーの良い、おそらく最良の例は、XDKフォーラムの群衆であり、最悪のトロフィーのうち最悪のものはAndroid forums/IRCチャネルでCyanogenModに渡します民衆。
それは私が意図したよりも少し長かった。私のポイントは-さまざまなレビューを得ることでしたが、彼らの貿易を知っている人々から正直な批評を得ることに焦点を当て、そして建設的批評とは何かを知っています。ああ、それはあなたを落胆させることなく、どんな形の批判も受けることができる。経験則：コメントと相互に関連する可能性のある事柄について同様の解説を聞くようになったら、さらに徹底的に内省してください。