ソフトウェア開発-業界と一般的な傾向/悪い慣行
私はWeb開発者であり、豊富なプロジェクトに取り組んでいる小さなチームの一員です。これは、コンピュータサイエンスの学位を取得してから初めての「実際の」実在の会社であり、Asp、SQLなどの経験を2年ほど持っています。
私はここのポイントにまっすぐに行くことを試みるつもりです。まず、いくつかのことを行います。
1）コードにはコメントを付けません。 「コードのコメントは弱い人のためのもの」は正確な言葉であり、ここにコメントを挿入するのに費やした時間を、コードを追加するために使うことができます。
2）文書化は行いません。 「私たちはIT担当者です。」ドキュメントを作成する必要はありません。自動的に覚えています。（私の言葉ではありません）
3）コードのレビューや会議はありません。したがって、誰でもSVNリポジトリに何でもコミットできます。私たちはそのようなたくさんのプロジェクトを抱えており、他の開発者があなたのコードを目にする可能性はほとんどありません。
4）いかなる種類の単体テストも行いません。専用のテスターではなく、プロジェクト管理などを担当するあいまいな部門である「テスター」がいます。彼らはシステムをよく理解しているため、フロントエンドテストを実行できます（通常は迅速に実行されます）。
5）私達は「それが造られればそれを出荷するという考え方」を持っています。私は誰かがこれについて言及するたびに悪寒を感じます。 （基本的に、コードの品質は気にしません）。
6）メンターシップではなく、上級開発者に助けを求めることはできません。私たちは機械のように働きます。あなたがコードを作り出し続ける限り、大丈夫です。
7）だれもそれを維持できないほどコードを動的にするものもあります。いいえ、本当に。動的SQL内部の動的SQL ... 5000行のSQLクエリ。それは文字通り、それを書いた「天才」以外の誰もそれを維持することができない、または維持したくないというところまで来ています。コードをできる限り動的にしたいが、それでもなお保守可能であるべきでしょうか？それともここで間違っていますか？
8）仕様はありません。しかし、「バグ」を修正したり、以前に見たことのないコードの一部に何かを行うのにかかる時間を予測して推定するように求められた場合は、「そのときは」推定を行うことが期待されます。 「その場で。 2週間、1日と3時間半...いいね。
私たちはバグを紙に書き出すために急いでいるので、それを急いで、テストされていない悪いコードをコミットし、不十分なことを行い、それを維持しなければならない次の貧しい魂のために穴を掘ります。
例えば。ユーザー機能の権限を追加するいくつかの機能強化を行いました。数か月後、別の誰かに割り当てられた別の拡張機能が登場しました。彼は実際に私がすでにそれを実行していることを確認し、コードを「トリガー」した別の関数を作成しました。したがって、2つの完全に同一の関数で、表現が異なります。それを修正するバグがやってきて、コードを整理する必要がありました。
別のシナリオ。 MVCでプロジェクトのやり直しを開始しました。開発者は、MVCを適切に調査して時間をかけて代わりに、HTMLヘルパーを使用する代わりに、SESSIONSやハードコードされたコントロールなどを使用してコーディングを開始しました。レイアウトページ、BundleConfigs、およびその他すべての必須および基本的なパーツを見落としました。なぜ私たちは物事を適切に行わなかったのですか？
私の質問：
この業界標準は急いでいますか？それでも、修正にさらに時間がかかるバグや問題をいくつか作成することを意味しますか？最初に1、2時間余分に費やして適切に何かをする代わりに、結局、バグが次々と発生するため、10時間の作業時間を費やす必要があります（確かにバグは必ず存在します）。物事を少し遅くしてしっかりとした土台を置く人のための場所はほとんどありません。
さらに、テスト、コメントコード、ドキュメントの作成などを行わないことは業界標準ですか。
この時点で、私は少し不満を感じています。どこを見ればいいのかよくわかりません。
コメントやご意見をいただければ幸いです。
編集：
私の質問は間接的に回答されたと思います。一般産業や他の企業について知りたいのですが？すべての会社がこのように連動していますか？マイクロソフトやグーグルのような大きなプレーヤーのために仕事に行くとすれば、トンネルには明かりがありますか？単体テスト、コードレビュー、その他のパフォーマンスレビュー、またはコード品質の実践に問題がある企業はありますか？他の記事からの答えは悲しいことにノーのようです。それで、私の質問を他の既存の質問とどのように区別したいですか、私は反対側の芝生がどのように見えるか知りたいですか？他の会社？
これはラッシュの業界標準ですか？
ある程度。企業はお金を稼ぐためにビジネスを営んでおり、ビジネスパーソンは（ほとんどの場合）物事をより速く望んでいます。
さらに、テスト、コメントコード、ドキュメントの作成などを行わないことは業界標準ですか。
私の現在の会社では、QA部門がありません。最近、そうでない他のいくつかのことを聞いたことがあります。いくつかの引数があります。 QA部門があると、開発者は「自分の仕事ではない」ので、品質を見落とす可能性が高くなります。 QA部門を設けることは、彼らが発見したバグの数に対して非常にコストがかかります。専任のQA担当者はほとんどひどいので、なぜわざわざ？
それが良い考えであるかどうかは明らかに議論の余地があります。それは確かに標準ではありません。
「コードのコメントは弱い人のためのもの」は正確な言葉であり、ここにコメントを挿入するのに費やした時間を、コードを追加するために使うことができます。
どのようなコメントを期待していますか？確かにいくつかの適切に配置されたコメントは良いですが、javadocスタイルのコメントはますます珍しくなっています。クラス/関数/変数の名前が不適切な場合、コメントは役に立ちません。あなたが良い名前を持っているなら、コメントは重複した努力です。あなたが悪い名前を持っているなら、コメントはあなたの名前を修正するためによりよく費やされた時間を無駄にするだけです。
「私たちはIT担当者です。」ドキュメントを作成する必要はありません。自動的に覚えています。
私はその理由には同意しませんが、多くの業界では、正当な理由により、ドキュメントが明らかに一般的ではありません。作成にはコストがかかります。 invariablyが古いか正しくありません。そして、多くの場合、さまざまな対象者のためにそれを複製する必要があります。
コードのレビューや会議はありません。
ほとんどすべての業界でいくつかの会議が開催されます。コードレビューはあまり一般的ではありませんが、想像するほど必要ではないかもしれません。私はコードレビューを必要とするいくつかの場所で働いてきました。おそらく75％の確率で、それらは完全に価値がありません。プロセスのためのプロセス。そして、それはコードレビューをうまく行う場所にあります。コードのレビューを行うためのスキル/忍耐力/コミュニケーションがない場合は、役に立たないものをくすぐったり、順番にお互いを批評したりするのではなく...
私たちは「それが造るならそれを出荷するという考え方」を持っています
驚くばかり。ゲートチェックインと自動テストスイートは、ビルドコードが機能しているコードであるという高い信頼を提供できるため、これは最近ではかなり一般的です。 ...そのようなインフラストラクチャがあるとは思えませんが。
仕様はありません。
悲しいことに、これも一般的です。アジャイルをうまくやっているのであれば、仕様はコードであり、ステークホルダーと密接に連携しながら、日ごと、週ごとに作成します。多くの場合、それはビジネスマンが仕事をしない言い訳です。
とはいえ、見積もりについてのあなたの主張はうさんくさいです。仕様があなたの見積もりを良くすると何があなたを考えさせるのですか？彼らはとにかく変わる可能性があります...
つまり、あなたが説明するものは、ひどい、標準的ではない、機能不全の環境が一緒になっているように聞こえます-長期的な見解なしで人々がくだらないコードを汲み上げることを期待するものです。しかし、それとは別に、問題を抱えているもののいくつかは、うまくいっていればそれほど問題ではないか、見た悪い原因ではありません。そして、この種の短期的なコーディングの見方でさえ、コードが破棄されるビジネスや、市場投入までの時間が実際に問題となるビジネスでは実現可能です（ビジネスの人々が考えるよりもはるかに少ないです）。
ビジネスの目で見てください。この方法は間違っています。遅かれ早かれ、会社が開発者を見つけることができなくなったり、保守できないコードをすべて修正するのに十分な人を雇うことができなくなります。または、コードはまだ会社が存続するのに十分なお金を生成します。したがって、何も問題はありません。