あなたのコードが混乱していると誰かが言ったら、あなたはどう反応しますか？

私は優れたプログラマーです。私はいつもプログラムが大好きです。そして、私はプログラミングについて多くのことを学び、私をより良いプログラマーにしたいと思っています。私は1年間プログラミングを学び、現在はほぼ2年間プログラマーとして働いています。要するに、私はほぼ3年のプログラミング経験があります。

私たちのチームは5人のプログラマで構成されており、うち4人は新しく、1人は3年以上の経験があります。私たちはもう1年近くプログラムに取り組んでおり、コードをレビューする人は誰もいませんでした。コードのレビューは一度も行ったことがなく、まったく新しいので、きれいなコードがどのようなものかはわかりません。プログラマーは自分で学ぶと思う？

徹底的なテストなしで、プログラムにプログラムを展開しました。現在はタイトであり、コードを変更する前にまず承認とコードレビューが必要です。初めて、誰かが私のコードをレビューし、彼はそれが混乱だと言います。

私はとても悲しくて傷つきます。プログラミングが大好きで、そのようなことを言わせると本当に痛いです。私は本当に自分自身を改善したいです。しかし、私は映画のような天才プログラマーではないようです。もっと良くする方法についてアドバイスをいただけますか？コードを批判する何かを経験したことがありますか？それらのイベントで何をしますか。

真実は、おそらく2年以内に現在のコードを見ると、それが混乱であることに同意するでしょう。プログラミングの学習は終わりのないプロセスであり、あなたよりも優れた人が常に存在します。

あなたのコードが混乱していると言った人が単なる意味ではなく、プログラマーの間で一般的な「私はそれをやる」病気の別のケースではない場合それを改善。

コーディングの良さに誇りを持ってはいけません。どれだけ上手に学べるかに誇りを持ってください。次に、コードの改善が必要であることを学習することで、プログラマーがどれほど悪いかを批判するのではなく、学習がどれだけ優れているかを示す機会を得ることができます。

私が何を話しているのかわからない場合は、http：//www.perlmonks.org/？node_id = 270083を読んでください。

20年以上後、自分のコードの一部がまだ混乱していることを知っています。結局のところ、可能な限り最良のコードを書くことと、仕事を成し遂げるために必要なことを書くこととの間で決定を下すことです。合意された時間内に仕事を完了することは、いつでも技術的な完璧さを求める終わりのない探求に勝ります。

秘trickは、それを受け入れることを学ぶことです。もっと良くできることを受け入れることを学ぶ。欠陥と一緒に暮らすことを学ぶ。今回、そしておそらく次回も完璧にはならないだろうこと、そして代替手段が提供されていないため、それが意図的な選択であることを受け入れることを学んでください。そしてそれはさらに悪いことです。

免責事項：これは「不良コードでも構いません」と読まれるべきではありません。

誰のコードも混乱し、優れたプログラマーはいません。

がある：

• 高速で出荷するプログラマ、
• 常に意味的に正しいコードを出荷するプログラマー、
• 常に最適なソリューションと最速のアルゴリズムを考え出すプログラマー、
• 目に優しいコードのプログラマー。

彼らは、ほとんど同じ人間になることはありません。

そして、成長する必要があるbutthurtプログラマーがいます：

• 何が悪いのか聞いて、
• 人間としての価値の尺度として、個人的にコメントをしない。
• チームには構文のガイドラインがあり、従う必要があり、それらは、意的であるため、最適な解決策も最終的な言葉もないので、彼らは吐き気で議論するつもりはありません。
• コードのコメントが上手くなります。
• コードのコメントが上手くなります。（原文）
• 単純でありふれたタスクのデバッグが簡単で、賢くないソリューションを見つけます。
• SQLでクラスを取る
  （安全のために、この世界の人口の半分をSQLでクラスに参加させます）

それは芸術ではなく、工芸品です。
私たちはあなたが賢いのは当然だと思います：あなたはコンピューターをプログラミングしているのです。
それでもAMD64、x86あなたの散文の力によって強制されていません。物事をシンプルにしてください。

まあ、あなたのコードが混乱していると言う人は、たとえたとえそれが正しいとしても建設的ではありません。彼らはそれが混乱である理由をあなたに与えましたか？同様に、メソッドが長すぎたり、責任が混ざり合ったり、分岐が多すぎたりします。正直に言って、1年前に書いたコードは、それ以来たくさんのことを学んだので、完全にくだらないものです。だからそれについて悪く感じないでください。あなたがずっと前に書いたコードを読むのがまだ好きなら、私はもっと心配するでしょう。

コードベースがクリーンであればあるほど、特定の問題を解決するためにコードベースと戦う時間は短くなります。プロジェクトの初期段階で行った設計上の決定の苦痛を感じることができるので、1年は素晴らしい時点です。

私の現在のプロジェクトでは、テクノロジースタックに慣れてきたため、数回リファクタリングしました。これは奨励されるべきであり、現在のコードベースのために必要以上に時間がかかるタスクに注意する必要があります。

あなたが書いたコードの古い部分のいくつかを調べましたか？たぶん、今とは違うやり方をしたり、リファクタリングしたいことを見ることができるでしょう。

また、テストの欠如に言及するとき、これは常に注目すべきものです。私たちのプロジェクトでは、自動テストが行​​われなかったため、多くの高度に結合されたコードがありました。ユニット/統合/何でも定期的にテストを書かなくても、少しの間それをすることで、コードをよりモジュール化する習慣が得られます（その結果、混乱が少なくなります）。

私はとても悲しくて傷つきます。プログラミングが大好きで、そのようなことを言わせると本当に痛いです。私は本当に自分自身を改善したいです。

それはいいです。つまり多くの「私の校閲者が私を好きではない」と、それらを無視して、単に「私のレビューがあまりにもうるさいです」、「私のレビューは、彼が話しているものは考えていない」などの反応を持つよりも良いです。この態度は良いことです。

しかし、私は映画のような天才プログラマーではないようです。

どのような映画を見ているのかはわかりませんが、映画のプログラマーの90％が偽物なので、シーケンスの終わりまでに涙が出ます。

もっと良くする方法についてアドバイスをいただけますか？

読んで練習します。以下のようなブックチェックアウト完全なコードや実用的なプログラマーを。アマゾンで同様の本を探してください。

コードを批判する何かを経験したことがありますか？これらのイベントで何をしますか。

なぜあなたは怪我をしますか？そもそもそんなバカであることには失望している。私はその動機を使ってコードを整理し、同じ間違いを二度としないようにします。私がやりたい最後のことは、そこから学ぶことではありません。あなたは一度置かれました、同じ理由でそれが再び起こるのを許さないでください。

完璧に生まれたプログラマーはいません。より多くのコードを書くほど、より多くのレビューを取得し、提供するレビューにより、総合的な優れたプログラマーになります。

開発者であることに関して私にとって最高のことの1つは、毎日が学習プロセスであることです。あなたがしていることを知らない誰かが常にそこにいて、あなたが知らないことを知っている誰かが常にいるでしょう。私は入学/後輩レベル以外のどこかに自分がいるとは考えていませんが、正当化され、敬意を払われている限り、私が得ることができるあらゆる批判に感謝します。

当てはまるかもしれない類推は、私が大学でライティングの家庭教師をしていた時期と、創造的なライティングコースに参加した時期に関係しています。すべての意図と目的のためにコードを書くことは、詩、エッセイ、短編小説、または小説を書くことによく似ています。各個人はそれを実行する独自の方法を持っていますが、同時に、最高の作家（またはこの場合は開発者）でさえ間違いを犯したり、物事をすり抜けたりします。私たちは自分自身の声（またはこの場合もコードのスタイル）に慣れているため、これらのことに気付かないことがよくあります。

どの分野でもそうであるように、専門家であると考えられる人々がいます。それらの人々が存在しなければ、私たちは誰からも学ぶことができません。問題のこの個人が本当に専門家であると仮定して、私は彼の言うことに耳を傾け、コードを改善するためにあなたが何をするよう提案するか尋ねます。しかし、彼を助けてくれるのは彼だけではないことを決して忘れないでください。SE / SOなどのリソースが大量に存在するという幸運があります。

混乱はかなり主観的です。あなたができる最善のことは、実際にその人（またはレビューレポート）に尋ねることです：なぜそれは面倒ですか？（彼らの観点から、つまり）

彼らはあなたに答えることにバインドされており、あなたはどちらかをすることができます：

• それに対する議論（もちろんそうする正当な理由がある場合）
• 何か新しいことを学んだばかりで、将来のコードはもっとすごいものになるはずだから、彼らのアドバイスのおかげで、それをもっと面倒くさくする方法を知っているので、とても幸せに感じてください。

あなたが心配しているという事実は良い兆候です。それから始めましょう。あなたはプログラミングが好きだと言いますが、プロのプログラマーであることは好きですか？愛好家とプロの間に大きな違いがあります。専門家として、あなたはあなたの作業成果物に対して絶えず精査されます。

Our team is composed of 5 programmers, and 4 of us are new

対立することなく2年間働いたという事実は、あなたが非常にのんびりした仕事で働いていることを私に教えてくれます。あなたが実際にプロとして前進したいのであれば、あまり良くありません。心に留めておいてください。世界の最高のプログラマーの中には、Linuxの基礎のために働いており、わずかな間違いを犯しても親切に扱われないという安心 感があります。

かなり標準的なコーディングガイドラインを簡単に確認するには、Linux Community Contributors Standardsで、製品に対する熱意のレベルを把握してください。コードの正しい入手方法を参照してください。

その主張をさらに進めるには、ほとんどの優れたソフトウェアが徹底的にレビューされるため、レビューを受け入れることを学ぶ必要があります。これは、Linusの法則をサポートしています...

「十分なレビュアーがいる場合、すべての問題は簡単に解決できます。」

個人的に、私は非常に熟練した、責任感のある、信頼できる開発者がコメントを忘れるのと同じくらい簡単なもののgetを得るのを見ました...だから誰かがあなたのコードを混乱させるとしたら、それはおそらく...それを乗り越えます...リファクタリング。それはギグの一部です。

I feel so sad and hurt. 

悲しみアプリケーションを作成して、自分自身を適用しない場合にどの程度動揺するかを測定します。

問題に答えました...テストしません！

あなたがあなたのJava開発者であると述べたコメントを見た後、私はほとんど動揺しました。あなたとあなたの開発チームがJavaショップで働いており、アプリケーションのテストフレームワークを持っていないというあなたの言い分を正しく理解したら...

そこに嘘

「徹底的なテストなしにプログラムにプログラムを展開しました。」

UMLクリエーターのGrady Boochのクリビング...

アマチュアのソフトウェアエンジニアは常に、魔法、魅力的な方法、またはソフトウェア開発を簡単にするアプリケーションが約束されているツールを探しています。そのような万能薬が存在しないことを知ることは、プロのソフトウェアエンジニアのマークです。

Alistair Cockburnは、アジャイル手法を使用して、あなたとあなたのチームのパフォーマンスと品質を向上させるための豊富な情報を彼のサイトで提供しています。

プログラミング{および人生}の最も重要な側面の1つは、長所と短所を知ることです。あなたの弱点に取り組んでいない場合、あなたはバランスの取れたスキルセットを持っていません。

アウトロ...あなたの元気-ただ泣き言をしないでください。クラフトの開発を進め、プログラミングへの情熱を持ち続けましょう。幸運を ：-）

感情がコードの改善を妨げないようにしてください。コードレビューの目的は問題を見つけることです。そのため、問題があったとしてもあまり驚かないでください。ただし、これらはコーダーバッシングセッションでもないはずです。

また、単に「Ewwww」と言ってそのままにしておくべきではありません。プログラミングで何かが間違っている理由は常にあります。たとえば、コメントアウトされたコードをあちこちに残しておくのは間違っていますが、本の中で誰かがそう言ったからではなく、コードを混乱させて読みにくくするので間違っています。

あなたのコードはあなたではありません。覚えておいてください。

私はここでペニスになり、..まあ、明白に基づいてアドバイスします。明らかに、あなたのコードは混乱しているか、あなたが尋ねる質問は「誰かが私のコードが混乱していると言っているのはなぜですか？」です。しかし、あなたは仮定に挑戦していません。あなたはただ怪我をしているだけで、率直に言って泣いているかもしれませんが、それがプログラミングを正当化することになると感じることはありません。

しかし、本当に、なぜあなたは尋ねているのですか？あなたのコードが下手であることを知っているか、別の質問をしているでしょう。誰かが私のバックエンドWebコードの悪臭を私に言ったら、私は笑って「それで何が悪いの？」と言います。彼らが私のJavaScriptの悪臭を私に言ったら、私は彼らに太った唇に相当するソーシャルプログラマーを与え、私は小さな愚痴が明らかに間違っているので反応する方法についてアドバイスを求めることは決してありません！

あなたが得意なものを所有してください。そして、私は本当にそれに対して責任を取ることを意味します。というのは、あなたの次の推測をするために、いくつかの気まぐれのため​​に1つの間抜けが必要なだけだからです。良いことを許可しないでください。あなたのものだけを知っています。終わり。

これを覚えておいてください：あなたが見るであろう最悪のコードはあなた自身のものです！

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つの異なることがあります。

構造

コードの構造は、言語、業界標準、および企業標準によって管理されています。明らかに他の要因もあります。

これらは、リント、テストツール、および同様の製品が特定するように設計されているタイプのミスです。それらは明確に定義されており、あなたまたはあなたのツールはその有効性/正確性に関して客観的な決定を下すことができます。

スタイル

コードの構造/ルールは標準化されていますが、すべての開発者は、問題やタスクを記述してアプローチする方法に特定のスタイルを持っています。任意のチーム環境でコードのメンテナンスを行うと、時間の経過とともに、スタイルに基づいてコードを書いた人について、経験に基づいた推測を行うことができます。また、独自のスタイルを開発し、経験を積んでクラフトを学習するにつれてスタイルが変化します。

だから誰かがあなたのコードが混乱だと言うときはいつでも、彼らが構造やスタイルについて話しているかどうかを理解する必要があります。それらは2つの非常に異なるものです。構造は客観的であり、スタイルは完全に主観的です。

そうは言っても、他のプログラマーからの建設的なフィードバックはあなたにとって非常に貴重なものです。それはすべてあなた次第であり、あなたがどのように批判を受け入れるかです。時間が経つにつれて、誰が心に抱くべき意見であるか、誰が塩の粒で取るべきかを学びます。

あなたのキャリアが進むにつれて、あなたはあなた自身のコードを振り返り、あなたが異なって、より良く、よりきれいに、より速くできることを見るでしょう。それはすべて学習プロセスの一部であり、あなた自身の過去の過ちを見ることは、あなたがあなたの技術を磨き上げ、改善していることの本当の兆候です。

少しの批判があなたの精神を湿らせないようにしてください。そこからできることを取り出し、それが有意義で価値がある場合は、知識のストアに追加してください。

自分のコードが混乱していることを認識することは重要ですが（特に経験豊富でコードが古くなるにつれて、プログラマーの間で非常に典型的な感覚）、他の人がそう言うときに耳を傾けることはさらに重要です。

現在のプログラミングの知識の制約で作成されたため、独自のコードで認識できる問題は非常に多くあります。

コードのレビューは、学習に不可欠な機会です。なぜなら、コードの作業中に持っていなかった新しい知識にさらされる可能性が高いからです（そうでなければ、コードを使用しても混乱はありません）。

ネガティブフィードバックの処理には2つの部分があると思います。

1.提起された問題の性質と、そこから何を学ぶべきかを決定する

コードをレビューしたり、コードをレビューしたりするときに、コードの問題に関する情報をおおよそそのようなバケットに分類します。

• 厳しい技術要件に違反する
  • 明らかに間違っている（機能しない、または要件を満たしていない）
  • 他の状況では失敗します（環境/構成の変更）
  • 非推奨の機能を使用し、近い将来に機能しなくなる
• 業界のベストプラクティスに違反しており、
  • 特定の問題に対する実証済みのアプローチを使用する
  • 性能
  • 後方互換性
  • メンテナンスの容易さ
  • コーディングスタイル
  • ドキュメンテーション
• 職場のベストプラクティスに違反する
  • 業界と同じですが、会社/同僚により特有であり、詳細が業界と異なる場合があります
• 個人的な専門知識に沿っていない
  • レビューする人の意見で、何らかの方法で改善することができます

これは、非常に客観的なもの（「運用サーバーに展開すると壊れる」）から非常に主観的なもの（「変数の命名方法が気に入らない」）に及ぶことに注意してください。

2.レビューの結果として、コードにどの変更を加えるか（ある場合）を決定する

情報が処理された後、実行可能かどうか、およびコードを変更する必要があるかどうかが決定されます。これは必ずしもあなたの決定ではありません。あなたの意見は、関係者やあなたの状況の詳細（シニアなど）に応じて重要であるかもしれません。しかし、考えられる結果は大まかに次のとおりです。

• 完全に問題に対処する
  • 壊れた修正
  • 必要なコーディングスタイルにフォーマットする
  • 等々
• 問題がまったくまたは部分的に対処される必要がある場合、妥協するようになる
  • リソースなし（時間や予算など）
  • 必要なし（わずかな改善、安定性の低下など）
• 提起された問題が無効であることを理解するようになる
  • フィードバック（特に主観的な意見カテゴリから）は非常によく有害であり、盲目的に行動すべきではありません

ネガティブフィードバックを得るのは苦痛であり、今後も毎回苦痛になる可能性があることを学びました。しかし、あなたはそれがいかに重要な学習機会であるか、そしてそのプロセスがより良いコードベースを達成するために専門的および職場を改善するのにどのように役立つかを学びました。

壊れていると感じないでください。最終的には、間違いから学びます。問題を解決したら、あなたは人と話をすることができます。もっと耳を傾け、あまり議論しないようにしてください。

私はこの状況を経験しており、理解できます。

TL; DR

あなたのコードが混乱していると誰かが言ったら、あなたはどう反応しますか？

私の率直な、「あまりにも長い間読んでいませんでした（すべての答え-謝罪、できれば後で時間を見つけて、必要に応じてこれを編集/修正します）」という答え/ヒント：

• 古き良きピアレビュー。集合的な考え方、専門性レベル、攻撃性のレベルが異なるさまざまな乗組員にコードを確認してもらいます。
• 「異なる」ピアグループの意味を少し詳しく説明すると、StackExchangeのディアスポラは、たとえばRedditに比べて参加するのが比較的難しいため、おそらく最も専門的で尊敬されるグループです。Redditは、より人気のあるサブredditsでは非常に攻撃的である傾向がありますが、奇妙なことに、プログラミングsubredditsは非常に友好的です（私が経験したことから）。

攻撃的なギャングスタタイプのクリークメンタリティの良い、おそらく最高の例は、XDKフォーラムの群衆であり、Androidフォーラム/ IRCチャンネルの人々のためにCyanogenModに手渡す最悪の最悪のトロフィーです。

それは私が意図したよりも少し長かったです。私のポイントは-さまざまなレビューを取得することでしたが、貿易を知っている人々から正直な批評を得ることに焦点を当て、建設的な批判とは何かを知っています。ああ、それはあなたを落胆させずにあらゆる形の批判を取ることができます。経験則：コメントと相互に関連する可能性のある事柄に関する同様のコメントを聞き始めたら、さらに徹底的な内省を行います。