コードをまったくコメントしない会社で働いていますか？
私は、小規模なソフトウェア開発会社（10名以上の開発者、数人の製品マネージャー、数人のサポートスタッフ）で働いており、さまざまな製品やサービスを再販業者を通じて組織に国際的に販売しています。私は7か月前に仕事に着き、3年後に退職した開発者によって開かれた役割に就きました。その会社はおそらく10年前から存在しています。基本的に、それらには約30以上の個別の製品があります（30の個別の.NETソリューションには、これらのソリューション内の10以上のプロジェクトで構成される場合があります）。各プロジェクトまたはソリューションは、中規模から大規模であると推定します。
各プロジェクトには、ソースコードのコメントはまったくありません。また、アプリケーションがどのように設計されているか、コードがぶら下がっている方法についてのアーキテクチャ図やドキュメントもありません。最初に作成されたとき、プログラムがどのように機能するかについてのビジネス分析（ユースケース）タイプのドキュメントがいくつかありますが、それだけです。
会社の新しい人物として、過去7か月間、さまざまなプロジェクトに夢中になり、これらのさまざまな製品のバグを修正する必要がありました。私はITの学位を取得しており、おそらくHTML5/PHP/web開発の中間レベルであり、.NET開発のジュニア中間レベルでもあります。彼らは私のウェブ開発スキルのために私を採用し、私の.NETスキルを向上させたいと考えていました。 PHP）で以前の仕事よりも高額だったので受け入れ、.NET開発の経歴があると私のキャリアとより多くの仕事の選択肢に役立つと思いました。
しかし、毎日、私は深いところで悩んでいて、水を踏んでいるように感じます。手始めに何かを行うには、コードを読んでもほとんど意味がありません。割り当てられたばかりのこの新しいプロジェクトで、バグを開始または発見または修正する場所からのベースラインがないためです。どこから始めればよいのかを知るために、他の上級プログラマーの一人と話をすることになります。シニアとは、彼らが4年間在籍していて、特定のプログラムがどのように機能するかについての一般的な考えを持っているということです。彼らはほとんどのソフトウェアを作成していませんでしたが、その多くは退職して会社を去った数人の年配の人によって書かれました。
私の意見では、コード自体は非常に複雑です。多分それは、私が.NETにそれほど熟練していないからかもしれませんが、複雑な不必要なレイヤーがたくさんあるようです。 MVCの基本的な3つのレイヤーがあるかもしれません。次に、プロジェクトをより多くの層のコードに追加してアプリケーションを作成した人は、おそらくアプリケーションを構造化するためです。たとえば、フロントコントローラーは、アプリケーションをブートストラップするいくつかのクラスを呼び出し、それがコントローラーを呼び出します。次に、モデルを呼び出すメソッド、次にそのモデルがビジネスレイヤーを呼び出し、次にビジネスロジックレイヤーを呼び出し、次にデータを呼び出します。レイヤーの場合、データレイヤーは、ストアドプロシージャを呼び出してデータベースからデータを取得するためのより多くのクラスを持つサービスを呼び出します。これは、PHP=での私の経験とはかけ離れています。複雑なWebアプリでも、モデルを呼び出すコントローラーを呼び出すフロントコントローラーと同じくらい簡単です。モデルはデータベースからデータを取得し、それをビュー/ウェブページにレンダリングします。これらすべての追加レイヤーを追加するとどのようなメリットがあるのですか？
もう1つは、クラスが存在する可能性があり、そのクラスだけのインターフェースを作成する場合です。そのインターフェースを使用したり、それから継承したりするクラスは他にありません。彼らはほとんどすべてのクラスのインターフェイスを作成します。私が見る限り、インターフェースを使用した単体テストもありません。それを書いている上級開発者にはそれが理にかなっているに違いないと私は確信していますが、私には意味が失われています。
彼らがやりたいもう1つのことは、社内に多くの開発者がいないため、必要なシステムの仕様/ドキュメントを作成し、プロジェクトを別の会社に外部委託して開発することです。その後、完成したら、地元の開発者が保守できるように社内に持ち帰ります。彼らがそれを外注したある会社は地元の開発サービス会社でしたが、その会社は今度は開発の努力をある発展途上国に外注しました。今、私は彼らのコードベースを維持してここに戻ってきましたが、コメントもありません。プログラム自体はおそらく例としてPhotoshopのサイズです。文字通り複数の複雑なレイヤーがあり、コードの大部分はチャンクでコメント化されています。なぜコメントアウトされているのですか？彼らは将来そのコードを使用すると思いますか？わからない他の誰も知りません。外注先の会社で働いていた人たちは、その会社を去って姿を消しました。
入社した当初は、複雑なプロジェクトコードを読んでいて、コードにコメントを追加していたので、後でプロジェクトに戻る必要がある場合にそれを理解できます。数日後、上級の開発者の1人が来て、そのプロジェクトについていくつか質問をしました。彼が理解しようとしていたことは、実際、私が先日理解したことであることがわかりました。私はコードにそれが何をするかを説明するコメントを書いていて、私は彼に見せました。それから彼はコメントを読まずにすぐに削除し、コードを上にスクロールして別の質問をしました。次に、削除したばかりの下記のコメントで説明できます。彼は戻って削除を元に戻し、コメントを読みます...そしてついに彼は理解しました。
コードにコメントがない理由を彼に尋ねました。彼の理論的根拠は、コメントが古くなって無意味になるということでした。ええ、コメントはコードと共に維持されることになっています。コードを更新すると同時にコメントを更新します。コメントがないという開発マネージャーの根拠は、良いコードはコメントがなくても理解できるはずだということでした。
そう、彼らにはこれらの非常に複雑なシステムがあり、どのように機能するかについて何らかの考えを持っているのは、最初からそこにいたか、長年それらに取り組んできた人々だけです。基本的に、これらの人々が去った場合、コードベースを理解し、それを維持することができる新しい参入者がいないため、私の意見では会社を実質的に台無しにするでしょう。
システムに新しい機能を追加するなど、そこで何かをするように求められたとき、おそらく数日で問題なくHTML5/jQuery/PHPでそれを打ち消すことができたと思います。この会社では、まずシステムを理解し、次にコードがコメントなしでどのように機能するかを理解してから、コードを配置する場所を特定し、それをコーディングする必要があります。日は週に変わります。干し草の山から針を探すようなものです。
私の哲学は、コードを簡単に保守および理解できるようにしながら、何かを最初に適切に設計し、コードを簡単に実行できるようにすることです。 。しかし、それはこの会社がすることとは非常に反対のようです。
だから私の質問：
- コメントコードはソフトウェア業界では一般的ではありませんか？
- コメントコードにそれほど嫌悪感があるのはなぜですか？
- この環境で自分の仕事をうまく実行するにはどうすればよいですか？
- コードのコメントを開始するか、そのままにしておくことをお勧めしますか？
コメントがない理由はたくさんありますが、それは通常、能力不足、コミュニケーション能力の低下、および/またはアマチュアリズムに帰着すると思います。
コードのコメントはソフトウェア業界では一般的ではありませんか？
業界の悪い領域のみ。良いコードがあまりにも多くのコメントを持っているのと同様に、悪いコードはめったに十分なコメントを持っていません。
コードをコメントすることに対する嫌悪感があるのはなぜですか？
ありません。どちらかと言えば、より良い、より効果的なコメントをサポートするためのツールがますます増えているようです。これは不吉に聞こえるかもしれませんが、仕事のセキュリティのためにコメントを残しておくいくつかの悪い開発者を知っています-彼らは望まない他の人々が自分のコードを理解しています。幸い、最高の開発者は、これは気まぐれで控えると考えています。
この環境でどのようにうまく仕事をすることができますか？コードのコメントを開始するか、そのままにするかをお勧めしますか？
もっと大きな問題だと思います、それは重要ですか？あなたがどういうわけか素晴らしい仕事をしていて、みんながコメントを書いているとしましょう。すばらしい、今何？さて、あなたはスタートラインにいて、誰もがコードを理解できるようになったので、最終的に顧客のためにコードを改善し始めることができます。コメントのような簡単なことでそんなに苦労したなら、ここで成功するでしょうか？
個人的には、プロジェクトで経験する混乱のレベルは、能力のかなり正確な尺度であることがわかりました。もちろん、反比例しています。私は成長しようとしている開発者として、混乱は自分の無能によるものだと考えるのは簡単だと思いますが、これについて考えてください。番号！彼らは新しい男に力を与えるので、彼は好意を返すことができます。
私は同様の状況を直接体験したことがあります。通常、開発者は頭上またはタールピットにいます。コメントの欠如について彼らに尋ねるあなたへの返答は、この場合に最も伝えています：
...コメントが古くなり、無意味になります。
いいえ、コメントとドキュメントのリファクタリングはコードのリファクタリングの一部であるためです！あなたがスポットしています。
...良いコードはコメントがなくても理解できるはずです。
ほとんどが本当ですが、なぜこのダイアログしかなかったのでしょうか。
ここで少し木目に反するつもりです。
あなたは明らかに（あなたが認めたように）C＃開発に不慣れであり、PHPで頻繁に宣伝されている「すべてを1つのファイルに」というアプローチに慣れています。これは、メンテナンスと拡張性に関する長期的な見方を備えたC＃アプリケーションを開発する方法ではありません。
私は、ASP.NET Webページのバックエンドコードで、複数の出口点と散在するデータアクセスを伴う、5000行のメソッドである、非常にコメントの多いコードをたくさん見ました。このようなシナリオでは、問題を修正したり製品を拡張したりするときに、どこに注目すべきかを検討するのに何時間も費やすため、コメントはまったく役に立ちません。
私はほとんどコメントなしで巨大なアプリケーションにも取り組みましたが、メソッドとクラスの名前、アーキテクチャへの標準化されたアプローチを慎重に検討し、開発者とお互いに話し合ってどこを探すべきかを見つけることに満足している問題（または、クラスの名前とUIとの関係によって単純にどこを見ればよいかを理解できる人）。このアプローチにより、アプリケーションがはるかに安定し、テストが改善され、保守が容易になりました。
コメントとアーキテクチャ図は単なるコミュニケーションの一種であり、コミュニケーションは本当に最も重要なことです。他の開発者とのやり取り、賢明で一貫性のある型と変数、またはコメントを介したコミュニケーションの提供方法は、作業している開発者がコードに慣れている限り、関係ありません。
あなたの説明によれば、あなたは十分に分離されたコンポーネントでアプリケーションを構築するかなり賢明な方法を持っている場所で働いています、そしてこのタイプの開発はしばしば開発家の聖杯ですが、迅速なPHP-あなたが好みを述べたスタイルのアプローチは短期的には素晴らしいですが、長期的には無数の問題を引き起こします。
TLDR;あなたは間違った質問をしています。コードにコメントすることは、自分が作業している特定の環境でアプリケーションの設計を伝達するための最良の方法であるとは限りません。私は、一緒に働いているより上級のスタッフからメンターを見つけ、彼らに連絡することをお勧めしますそれらがどのように機能するかをご案内します。それはあなたが仕事に慣れている方法ではないかもしれませんが、それは彼らが間違っていることを意味しません。
実際のコメントに関して：最高のコードはhowを説明するためのコメントを必要とせず、奇妙なコメントのみwhyを説明するためにそれがどのように機能するかを説明します。タイプ名、変数名、および使用されているパターンの既存の理解でどのように機能するかを説明します。
- コメントコードはソフトウェア業界では一般的な慣行ではありませんか？はい、場合によっては、そうでない場合もあります。
- コメントコードにそれほど嫌悪感があるのはなぜですか？これは時間がかかる可能性があり、多くの場合不要です。
- この環境でどうすれば自分の仕事を上手に遂行できますか？メンターを見つけ、彼らから学びます。
- コードのコメントを開始するか、そのままにしておくことをお勧めしますか？彼らが使用しているパターンを理解してから変更を試みます。
- コードのコメントはソフトウェア業界では一般的ではありませんか？
悲しいことに、大部分はそうです。私は、コードにコメントを書くことを重視しないプログラマーの1人でした。同僚の開発者がそれを始めたときにこれに気付き、コードを理解するのに多くの時間を節約できました。今、私は良いコメントを書くプログラマーの一人です。
- コードをコメントすることに対する嫌悪感があるのはなぜですか？
それは彼らの価値をまだ見ていませんし、それが彼らの快適ゾーンの外にあるので懐疑的だからです。証明するためにそれをしなさい。
- この環境でどのようにうまく仕事をすることができますか？
これは非常に広範な質問です。自分でコードにコメントを書き始めることをお勧めします。それらに影響を与えることは、最も効果的な方法の1つです。
- コードのコメントを開始するか、そのままにするかをお勧めしますか？
はい、しかしあなたは努力をリードしなければなりません。それらを待つ必要はありません。はい、技術的なスキルを教えることはできますが、愛すべきものを教えることはできません。
最初の理由：圧力
一定の圧力下で作業する場合、選択肢があります。
アーキテクチャについて考えることなく、ドキュメントを書くことなく、リファクタリングすることなく、コーディングするだけで、最終的には迅速なハックを使用して、物事を迅速に行うことができます。
または、質の高い作業を行うためにより多くの時間を費やします。
あまりにも多くの企業では、同僚が同じことをはるかに速く実行できたはずの仕事をするのに時間がかかりすぎたため、2番目のケースで非難されることになります。しばらくすると、会社はあなたを解雇します。
2番目の理由：指標
重要なのは、実際に測定されるものです。企業が開発者に毎月書くLOCの数で報酬を与え始めると、完全に無用のコード行が増えることになります。
ドキュメントの品質は、会社で考慮される指標ではないため、コードをドキュメント化することに誰も気にしません。経営陣が今すぐ解決策を求めているため、同僚は、彼らが作成している 技術的負債 に関係なく、ビジネス問題の短期的な解決に努力を注ぐだけです。
まず第一に、そのような小さな会社が30の成功した製品を生産および維持できれば、彼らが何をしているかを理解し、持っている可能性が高くなります。働く賢い人。
次に、人の種類はさまざまです。変化を好まない人もいれば、いくつかの概念に強い意見を持つ人もいます。
3番目に、コードにコメントを付けると、機能の作業に数週間かかるのではなく、数日かかると述べました。コメントの力を過大評価していると思います。
あなたの質問に従って：
1。コードのコメントはソフトウェア業界では一般的ではありませんか？このサイトを検索してください。
- "コメントはコードの匂いです"
- 古いコメントは都市の神話ですか？
-要約すると：コードのコメントは便利なツールですが、維持し、できるだけ明確にする必要があります。
2。コードをコメントすることに対する嫌悪感があるのはなぜですか？
-同僚に聞いてください。
3。コードのコメントを開始するか、そのままにするかをお勧めしますか？
-コードのコメントが作業に役立つと思われる場合は、そうです-そうする必要があります。チームメンバーとは常に明確なコミュニケーションが必要です。
そしてそれは信頼を築くための漸進的なプロセスです。
コメントコードはソフトウェア業界では一般的ではありませんか？
適切に記述されたコードではコメントはほとんど必要ありませんが、これは、カウボーイがコードをハッキングするだけの場合、多くの場合、カルテブランチになります。
コメントコードにそれほど嫌悪感があるのはなぜですか？
それは余計な時間であり、あなたには明らかではないコードが他の誰かに明らかであるかもしれません。これは、もっと年上の男性があなたのコメントを取り除いたときにあなたに起こったことだと思います。また、コードが変更されたときに変更する必要があります
この環境で自分の仕事をうまく実行するにはどうすればよいですか？
滞在したくない場合は、終了します。それ以外の場合は、できることをすべて学んでください
コードのコメントを開始するか、そのままにしておくことをお勧めしますか？
これはあなた次第ですが、他の役に立つ魂がそれらを取り除くだけのようです