告白1
私は開発者です。 私は雇用主から絶えず仕事をしていると聞き、しばしば理由もなく物事を複雑にします。 そして、私はそれについて何かしなければなりません。 避けるために。
私のプログラミングの経験はすべて、大学での仕事とさまざまな企業での数年間の経験から成り立っています。 私を批判する人は、一般的に私はこのトピックを理解していると繰り返し言ってきたので、あなたが思うかもしれないように、私は臨床例からは程遠い。 しかし、明らかに、私はまったく間違ったプログラミング習慣を開発しました（少なくとも、雇用主の意見では）、私は緊急にそれらを変更する必要があります。 どこでも、どこで働いても、行動の委任を伴う小さなクラスの階層を使用する私の決定は、悪いものとして認識されました。 彼らは書く必要があると言っていますが、そうではありません。 これはすべて「ありのまま」であるため、作業コストがかかるからです。
私は本を読み始めました。 それらの中で私はすべて同じものを見て、そこから脱出しようとしました。 たとえば、ある単一の作業では、別のプロジェクトの類似のコードを使用し、それを共通のインターフェースに持ち込みました。 私の同僚は、エラーを分析し、このコードにつまずいて、なぜ私が一度きりの作業のためにすべてをそんなに難しくしたのかと私に尋ねました。 しかし、私にとってこれは一度きりの仕事ではありません！ 両方のプロジェクトは非常によく似ており、同じ抽象コードをさらにいくつか使用できます。
私を批判した人たちはいつも私よりもずっと経験が豊富だったことに注意してください。 したがって、2つの選択肢があります。経験豊富な開発者すべてにとって何かが間違っているか、私にとって何かが間違っています。
人気のある英語のリソースの1つにこのメッセージを残した男性が助けを求めました。 問題を認識することは解決策の半分です。 男は心から彼らが彼に何を望んでいるかを理解しておらず、彼は魂を尽くして改善したいと思っています。
世界コミュニティの決定は、4つのグループに分けられました。
1.「スコア」、なぜなら 経験豊富なプログラマーはばかです。 そして、彼らが長い間働いていたとしても、これは彼らが経験を積んでいるという意味ではありません（多くの票）。
2.批評家に、彼らがどのようにコードを構成するかを尋ねる（何票も）
3.プログラミングをカップルで依頼する/コースに行く（数票）。
4.「まあ、簡単に書け！」-新しいプロジェクトの要件が、慎重に設計されたインターフェイスにうまくいくという保証はありません（1票）。
これらのすべてのヒントは、問題が定式化されている領域を超えていないため、主な問題を解決することはできません-「プログラミングスタイルを改善するにはどうすればよいですか？」 問題はより深い。
どうする
ロールプレイングゲーム。 パート1
あなたとあなたのダブルは、何かを自動化するビジネスを開始しました。 具体的には、あなたの二人-ディレクター。
ダブルウォッチアワーレートはいくらですか？ 計算機を使用して、雇用契約に示されている数を160で割ります。これらのアクションを就業時間中に実行する場合、結果をさらに60で割ります。半分はPFR税から相殺できます）= +最低23.2％）ここで私と一緒に楽しんでいる間、あなたは雇用主を温めました。 百万ルーブルがどのように見えるか知っていますか？ 過去1年間に書いたボリューム（特に品質）を思い出してください-これは100万です。 労働力を買う価値はありますか？ すでに監督として購入しますか？
遅かれ早かれ、あなたは簡単な質問「いつ準備ができますか？」、合理的な文「あなたは私に多大な費用をかけたからです」、そして賢明なアドバイス「簡単にする」であなた自身に近づきます。 あなたが監督になる前に、あなた自身がまったく同じ方法で「支払い」をし、その背後にあるものを知っているので、あなたは締め切りが引き出されている理由の二重の説明に面白がっています。
今、あなたのダブルは、最初の自白の人と同じ状況にあります。 問題は、あなたの2番目の自己が問題の一部として自分自身を認識するのか、それともすべてを上司やその他の外部環境に帰するのかということです。
そして今、注意、大きな秘密。 あなたにとって、監督として、それはもはや秘密ではありませんが、明白な考えはプログラマーを必要としないということです 。 問題を解決する必要があります。 別の場所でプログラムを注文するか、既製のモジュールを購入するか、何も自動化せずに低賃金で人を雇う価値があるかもしれません。 現時点では、すでに60万を費やしており、適切な結果を受け取っていません。
ビッグシークレットもう一度 ： 誰もプログラマを必要としません 。 そして、プログラムも。 それは完全にです。 人々は自分自身、問題、そして他の人々に興味を持っています。 たまたま、コードを書くことでいくつかの問題を解決できるようになりました。 同じ問題が木製の厚板を平らにし、それらを緑に塗ることによって解決された場合、それは安くなるでしょう。
記事全体から1つの考えだけを思い出す準備ができている場合は、これを覚えておいてください。プログラミングは価値がなく、プログラマはメンテナンススタッフです。
この考えはあなたを傷つけることができます-すべては大丈夫です。 早くそれを受け入れるほど、あなたはより価値のあるものになります。 私たちの文化では、使用人よりもマスターになる方が良いと信じられています。 しかし、あなたがそれについて考えるなら、社会とあなたはいくつかの点であります。 これらの関係では、「自発的な使用人」の役割を担うことができ、社会（雇用主と満足した顧客によって表される）はあなたのケアに対してforしみなく報いるでしょう。
ロールプレイングゲーム。 パート2
反対に行きましょう。あなたのダブルがディレクターであり、あなたが開発者です。
ディレクターが立ち寄ろうとしており、抽象オートマトンの工場はまだ完成しておらず、SQLクエリはデバッグされておらず、一般に半年の間、すべてが間違っているはずだと理解するようになりました。
ジレンマ：一生懸命働きたいと思う人はいません。 誰もが自分の仕事を誇りに思っています。 したがって：（論理的トラップ）はい、私はゆっくりと、しかし正しくやっています。
「遅い」ことですべてが明確な場合、「正しい」ことはまったく明らかではありません。 実際、すべてがシンプルです。 「正しい」とは、割り当てられた時間内に使用可能なプログラムまたはサービスが表示される場合（±）です。 あなたの「正しい」という他の概念が妥当な時間内に使用可能な製品の外観につながらない場合、あなたの「正しい」は良くありません。 操縦の余地はありません。 プログラミングは価値がないことを思い出してください。
割り当てられた作業には常に時間がかかります。 開発者に3倍の時間が与えられた場合、開発者は3倍の文章を書くことはできません。 彼は、通常生成するのと同じ品質のコードを3倍作成します。 したがって、何かを機能させるために最善を尽くしてください。 すべてのコストで。 あなたの目標は、どのように書かれていても動作するプログラムです。 いわゆる 「汚い問題」と呼ばれる-これらはあなたがそれを解決しようとするまで解決する方法が不明である問題です。 例：テストマシンのクラッシュ。 汚れた問題は最初のパスで発生し、仕上げ作業中に考慮することができます。 間違った手で、それは望ましいです。
2番目の大きな秘密： コードは常に悪いです。 「美しい」コードはありません。 コードが少ないほど良い。 コードには、バグ、トレードオフ、パフォーマンスの問題が含まれます。
- クラス、機能、ボタン、リンクが少なくなり、一般的にも少なくなります。
- 機能が異なる場所で少なくとも3回満たされない場合、一般化された関数を作成しないでください。
- ユーザーがいる前にクラス関数とメソッドを作成しないでください。 つまり 最初に、どこかでメソッド呼び出しが表示され、その後にメソッド自体が表示されました。
- 中間のテンプレートクラスでは、3つのレベルの継承は必要ありません。
- 標準モジュールは問題を解決する能力が非常に高いため、ドキュメントをもう一度お読みください。
- SQLは世界で唯一のリポジトリではありません。 JSONのファイルに多くのものを簡単に直接保存できます。
- 「成長」システムについて考えないでください。 その他の要件-別のシステム。 村に超高層ビルを建設しようとしないでください-これは建築です
- このアルゴリズムでは、O（n ^ 2）はO（n logn）に最適化できません。この場所ではnは5を超えないため、手の指の数を意味するからです。
- テーブルジェネレータを作成する代わりに、HTMLで1回作成できます。6か月ごとにわずかに変更されます。
- SVNは優れたバージョン管理システムです。 特に、同じプロジェクトであなたと一緒に作業する非プログラマがあなたと一緒にそれを使用する場合。
- 数学モデルの視覚化にピクセル単位の照明が本当に必要ですか、それとも標準のGL_SMOOTHで十分ですか？ ちなみに、展示会では、グラフィックスが統合された7歳のラップトップで展示します。
- 特に最初と2番目をディスクへのアクセス時間と比較する場合、イテレータのサイクルはインデックスよりも速く動作すると本当に思いますか？
- 2つのプロジェクトの類似したクラスは、互いに接続する理由ではありません。 これは偶然だと考えてください。 一般的なクラスを作成する場合、今後は変更を加えて、2つのプロジェクトについて同時に考える必要があります。 それは価値がある？ ほとんどない。
- マーカー付きホワイトボード+カメラ付き携帯電話は、UMLダイアグラムとほとんどのインターフェイスプロトタイピングプログラムを完全に置き換えます
彼の決定の商業的結果を考慮に入れるプログラマーは、金の重さの価値があります。 スティーブマッコネル
告白2
みなさんこんにちは。 私は開発チームのリーダーです。 私の開発者から、彼らには時間がないといつも聞いています。 開発者が正当な理由なしに物事を複雑にせず、ドキュメントをよく見れば、開発者はより高速に（さらには著しく高速に）作業できることを理解しています。 そして、私はそれについて何かしなければなりません。 避けるために。
私のプログラミングの経験はすべて、学校の「ペンのサンプル」、オリンピック、大学での仕事、追加教育、教育、家庭プロジェクト、および中小企業での8年間の成功した仕事で構成されています。 一般的に、私はこのトピックを理解しています。 明らかに、（少なくとも雇用主の意見では）「これらの」プログラミング習慣を開発しており、それらを共有する必要があると考えています。 どこでも、どこで働いていても、私の決定は「再利用」マニアに悩まされたことはありません。 彼らはそのように書くのは良くないと言いますが、そうではありません。 これはすべて「あるべき」であるため、私だけでなく仕事に値するからです。
私は本を読んで読み続けています。 本はそれをすべて持っています。 私はほぼ毎日コードを書きます（週末を含む：私はコードを書くのが好きです）そしてほぼ毎日ドキュメントを読みます。 一度に成功しませんでした。 しかし、忍耐が最短の方法であることは確かです。 急いでいるのではなく、毎日ゆっくりです。 私は言語、パラダイム、テクノロジー、その他の技術フェチから解放されています。 人々のために役立つプログラムを作りたいだけです。 問題を解決します。
私は、同じような立場の人々（そして最も生産性の高い開発者）が同じ考えを固守していることに注目します。 したがって、2つのオプションがあります：経験豊富な開発者全員に何か問題があるか、...
PS
第三の秘密。 書き込みを開始すると、追加されたコードのユーザー値がコミットされます。 「2つのメソッドを追加」するのではなく、「ユーザーの処理速度が速く/簡単/小さくなりました...」または「機能が現れた/反応が変わった」。 書くことは何もありませんか？ あなたは一日で何もしていません。