間違いなく、多くの読者がより広範な経験を誇ることができますが、スピーチ
他のことについて話します。 私のプロとしての成長は興味深い時期と重なった-
Runetでプログラミングの文化を改善することができます。
専門家は常にそうでしたが、今日では平均的なプログラマーの知識（
とにかく、最高の実践の範囲で）は、それよりも比類のないです。
そして、それ自体は悪いことではなく、恐怖はトレンド自体によって引き起こされ、
同様の結果。 その継続により、私たちは真剣に同じに直面するかもしれません
それがすべて始まった問題-つまり、たわごとが、今回は
高貴なgovnokodomは、多くの抽象化によってカバーされ、時にはこれらによって
抽象化と存在。 はい、はい、今日はオーバーエンジニアリングを再び批判します。
パターンの概念は新しいものではなく、自転車を発明しないという考えは完全です
口が痛い、テストがないため、頭に灰を振りかけ、あたかも悔い改めるのが習慣です
最終判断。 5冊のデザインブックを読むだけで十分です。
現在流行しているものとコードの書き方を理解する。 キャッチは別のものです-読んでも
どのコードを書く必要があるかを理解できない25冊の本。 ある程度、あなたは学ぶことができます
いつ応募するかについてアイデアを出す先輩を見る
これまたはその決定、その決定に再びつながった思考の流れ
画面外に留まります。
その結果、新人は、せいぜい、彼の頭の中に、
何でも適用でき、カードが非常に限られている場合。 そして、新人に悲惨な
それが印象的であることが判明し、結果が優れている場合-人は
お気に入りのパターンが表示されます。 そして、彼はこのパターンを何年も慎重に運び、彫刻することができます
最も奇妙な場所で彼は、それにより誠実な驚きと
同僚に対する真の憎悪。
少数民族の権利への短い遠足
あなたはTDDが好きではありませんか？ 手続き型のコードを書くのが好きですか？ EJBを使用していませんか？
アイアイアイ、あなたの足元の地球が燃えていないのはどうしてでしょう。 どの社会もに分かれています
グループ。1つのグループに参加する準備ができていない場合は、喜んでランク付けされます。
別のもの。 他の場所と同様に、行動の論理は生物学に基づいています
パターン、グループ間で競争があります。 グループの1つ
Possession of the Absolute Truthの名誉賞を受賞、残りは
せいぜい面白い辺境で、人類の敵と宣言されています。
一般的に誰もがこれを理解しているので、ハブの投稿を見てください
オーバーエンジニアリング-それははねかけられますが、コメントであなたが見ることができます
著者がまだ間違っている理由に関する10キロバイトのデマゴジー。 しかし、何もしない
不可能-確立された順序に反したい人は誰でも
無視または笑。 状況は、それらの当局が
あなた自身の名前で抗議をサポートすることができます、原則として、あなたはこれに興味がありません-
彼らはすでにパーフェクトコードのルールが原則である埃っぽいポストに座っています
彼らは、ソフトウェアエンジニアリングの人々の近隣のセグメントにいるという事実を気にしません
彼らは「コードを正しく書く方法」という論争でやりを破る。
「完璧なコードを書く」から「コードを書く」という傾向が逆転するまで、
現在の問題を解決します」、我々はインタビューでテストコードを書く運命にあります
私たちには決して使用されなかったパターンの実装
ひどい夢、そして仕事に応募した後、同じく有名なスタンプテスト、
コードの大事な100％カバレッジを達成するために何もテストしません。
おもしろいことに、このトピックについて真andかつ熱心に議論する準備ができている人がいます。
実際に1つまたは別の名前でパターンを実装する必要があるもの、
彼らが議論している名前が単に慣習であるという事実を省略する
その名前で自分の経験を記録することにした人。 最も
悲しいことは、前の話を聞いて頭をひどく振る人がいるということです
彼らは定義を正しく理解できなかったことを悔い改め、
より良い。 しかし、健全な自己批判は不健康な自己鞭打ちに置き換えることはできません。
彼らは良くなりません。
オリンパスの上
マーティン・ファウラーは私たちの王、父、そして神です。 私たちは皆、彼を人として尊敬しています
初心者プログラマーの無数の大群の手に支配者、そして多くの方法で
全世代のIT従業員の世界観を定義する。 おそらく決して
コードの良さの尺度となる方法と理由を学習します。 おそらく彼の本は一つになった
以前に業界に注いだ低品質のプログラマーの流れのスタブ
ドットコムバブルが破裂するまでの瞬間。 それとも彼は本当に最初のものです
プログラムの設計に関して蓄積されたすべてを体系化した
時間。 これらはすべて過去のことです。
そして今日、私たちは、暗黙の良いルールになった一連の推奨事項を持っています
開発中のトーン。 おそらくこれらのルールは良いでしょう、それらの境界線を概説してみましょう
アプリケーション：
1）静的型付けを使用する言語-主にC ++およびJava。
2）互換性に基づいた大規模なソフトウェア製品
プロジェクトに関与するプログラマ。
3）さらなる開発と長期にわたる設計のソフトウェア製品
護衛。
4）かなり厳しい信頼性要件向けに設計されたソフトウェア-企業
一般的なソリューション。
ソフトウェア市場のかなりのシェアをカバーする通常の状態のようです。 問題は
残りの市場シェアはそのようなタルムードでカバーされていることを...何もない。 はい、彼女だけ
無視されるか、むしろ本で説明されているアプローチは
他の製品には適していません。
ブラックマーケット
一方、よく見ると、非常に多くの小さな
上記の条件に合わない中規模のプロジェクト。 ここと
スクリプト言語の優位性、およびチームリーダーがそれほど容易ではないチーム
残りのジュニアは最低予算を満足させるために採用されたため、あなたはそれを捨てます。
その後、一般的には良いと約束しているアイデアと幽霊のようなオプションのために働いています
奨学金に加えて、プロジェクトの開発に関する不明瞭な予測。
かなりの量の業界ソフトウェアは何年も変わらない-プログラムはシンプル
それらが作成された技術プロセスとそれらに加えられた変更を提供します-
純粋に化粧品。 もちろん、そこにあるコードは、多くの場合、望まれるものを残しています。
最高ですが、設定されている要件のフレームワーク内でかなり拡張可能です。
さらにエレガントに、将来のソフトウェアの不確実性は、
開発するかどうかは、市場に参入できる速さによって決まります。
さらなる開発のための資金を受け取るために投資を返済する。 抽象化は
コードの量は常に大幅に増加しますが、時間は常に増加します
スペル。 確かにおもちゃがあります（最初から巨大な
資金調達）およびそのような余裕があることができる過度に成功したスタートアップ
あらゆる点で慈善コードを書くという贅沢。 そしてそれは素晴らしいです-すべきです
地球のどこかで幸せなプログラマになるために。 しかし、あなたはそのようなことを考慮すべきではありません
パターンとしてのプロジェクト。
耐障害性はむしろ好みの問題です。 私たちは
プログラムは安定して動作するはずです。 問題は安定性です。 そのすべて
私たちによって書かれた、いくつかの問題を解決するために書かれた。 そして、この問題の声明の中で
100％のフォールトトレランスを提供する必要はありません。ほとんどの場合、そうではありません。
それが必要です。 すべてに価格があります-フォールトトレランスの費用を支払わなければなりません。
ラッパー、チェック、バックアップシステムの作成。 そして最終的に私たちの仕事は
完全に破壊不可能なシステムを作成し、増加するコストを確認します
システムの信頼性は、ダウンタイムに起因するコストよりも低いことが判明しました。 音
冒bl的ですが、落ち着いて考えるとそうです。
多くの小規模なプロジェクトは、彼らに届けられることがより重要であるという点で興味深い
品質要件を満たすよりも厳しい期限。 はい、悲しいですはい、それは
間違っていますが、将来的に悲しい結果につながる可能性がありますが、そのような
このモデルは実行可能で広く普及しています。 名誉あるプログラミングの達人、
このgovnokodaを書き換える作業を見越して手をこすり
通常の心、これのためではないことを認識することを拒否
プロジェクトを開始することができたgovnokodの場合、彼らのための仕事はありません。 で
彼らは顧客が今彼らに支払う準備ができているお金を理解していない、
たわごとの動作が不十分な結果として現れました。
ちなみに、この市場セグメントからプロの道をほぼ開始しています
すべてのプログラマ。 そして、ヒントは彼らの頭に注がれています。 でも
現実には、開発のこの段階でこれらのヒントに従って、
そのようなプロジェクトに参加することは、失敗への直接の道です。 状況のパラドックスは
本当にこの市場セグメントで良い慣行に従うことができるかどうか
仕事、または高価格のためにまったく必要ありません。 そしてまだできない人
「良いプログラマー」の役割を効果的に果たし、反対に、あらゆる可能な方法で存在する
このセグメントの労働市場で、コンプライアンス違反のために積極的に分裂しています
新約聖書の完全なコード。
これは、初心者がパターン、テスト、
悪意による拡張可能なアーキテクチャ、いいえ。 これらすべてのアドバイザーは心から彼らを願っています
良い、同時に解決するタスクが多少異なることに気付かないで。
ここでグッドプラクティスを適用しても肯定的なフィードバックは得られず、単に
ここで提示されるタスクを解決するのに適しています。 中小の大釜で調理する
プロジェクトと完璧なコードを書き込もうとすると、初心者は何度も何度も抜く運命にあります
締め切りと誰も必要としないことを行います。
はい、あなたの謙虚な使用人は隠されたなんて罪だ
考えられるすべての期限を超え、また恥をかかずて数ヶ月のフリーランスプロジェクト
生産性が低いため、2つの仕事から追い出されました。 理由は簡単です-私は
賢明にすべてをしようとしました。
業界の蔽
すべての初心者プログラマーは、2つの椅子のジレンマに直面しています。 トレーニング
私たちの宇宙の論理の法則に従って、おそらく2つの方法で-受け入れ
目標を達成するために必要な情報、信仰によって、またはすべてをチェックすることによって
適切なものを見つけることで目標を達成するための可能なオプション。 そして両方のオプション
理想的ではありません。
利用可能な情報の同化は、それがわかっている場合に良い方法です
信頼できる。 そして、それは信頼性があり、信頼性が非常に高いです。私はそれに同意する準備ができています
デザインブックの著者は、彼らに与えられたすべてのアドバイスを使用しました
プロジェクト。 私たちのプログラマが構造的に同一に出会うとは思わない
プロジェクト、および初心者プログラマーが構造的に取り組むことを許可されること
少なくとも彼がどちらを決定するレベルで、同一のプロジェクト
彼にアプローチを適用します...
ところで、そのような本で与えられた情報の正確さをチェックする方法は？ のみ
コードがこのようにまたはそれによって変更されるという仮定の領域にぶつかります。 どれでも
2年生は、本に記載されている例に反例を与えることができます。
同じ問題を解決しながら、より簡潔で効果的になります。
どんな良い習慣も偽造することはほとんど不可能です。
質問に答える間違いのない真実としてそれを受け入れることを考えさせます
プログラムの書き方について。 これらの慣行は、特定の場合に増加します
可能性のあるコード拡張が発生した場合に、一部を回避する可能性
問題。 もうありません。
2番目のオプションは、ソリューションの独立した検索です。 そのような人々への態度
軽度の否定的、そして最も頻繁に-軽emptを置くために。 2つの否定的な理由があります。
第一に、人はそうではないと述べる世論が形成された
ベストプラクティスを使用する-これはまったく人ではなく、次に、
経験は必然的に間違いを犯します。 原則として、これらのエラーは認識されます
彼の経験豊富な同僚、そのような欠陥のために-は本当に赤ん坊の話です。
問題は、プログラミングを教えるプロセスを形式化することはまだです
このプロセスを経た人の頭にも、欠けています。 たとえば、あなたは
プログラマーを抱えて、次のモジュールの設計中に試してみるか、
いくつかの真剣なクラスが、それぞれのアクションに対して「なぜ」と質問するか、
あなたの行動の順序を論理的に正当化しようとするので、
そのため、一方が他方から明確に追従します。
時間を節約するために、成功しないと言います。 可能であれば、
あなたの頑固さはすべての賞賛に値する、あなたが読んだ同じ投稿は価値がない、
それを閉じます。 アーキテクチャを作成するプロセスでは、知識で操作するのではなく、むしろ
経験。 本から建築物を作成することで頭まで飛び越えることはできません
自分でそのような構造の必要性に達するまで。 しかし、できます
反対のステートメントを使用して、インタビュアーをだましてインタビューに導きます。
発見的インポテンス
腎臓で死ぬ乳製品の川とピンクのユニコーンの魔法の土地
他の水分が不足しているために不足している、人々は常にから推測することができます
一般的なプライベート。 残念ながら、彼らはユニコーンと同じ運命を共有しているため、
彼らはあなたと一緒に私たちの世界に行く時間を持ちません。
神聖な知識。 したがって、ほとんどすべての人が知識に基づいて能力があるわけではありません
一般的な、抽象的な、特定のものを引き出すための
シンプルで明確なもの。 ソフトウェア設計はそうではありません。
私は無駄に検索し、4人のギャングを読むことができる人々を長い間探しました。
次に、抽象化を構築し、コードに正常に適用します。 どちらかといえば、それは人々についてです
経験なし。 どちらかといえば、シングルトンはカウントされません。 頭の中の何かは、取ると生成することはできません
画像の部分的な抽象化と読み取りの肖像：人が理解していないか
なぜこれが行われ、結果として、抽象化は解決するよりも多くの問題を作成する、または
正直に言って、彼はそれがどこに行き詰まるのかわからないことを認めている。 おそらく、
私はそのような訓練方法を行うことができますが、彼らに会ったことはありません。 あなたはどうですか？
私の観察によると、特定からの一般の結論は、はるかに実行可能なタスクです。
誰もが対処します。 はい、私は人自身が来るときの場合について話している
熊手で壊れるパターン。 そして、誰が理解するためだけに本を開きますか
一般的に彼が彼の経験から学んだことと呼ばれるもの。 彼が何もしなければ
この本が開かれるまでに学んだので、ここではアプローチが機能しません。
主題の正式な記述のレベルでの知識は、多くの場合、成功するには十分ではありません
そのアプリケーション。 それらは、事実上の論理チェーンに埋め込まれている必要があり、
覚えるだけでなく、感じてください。 通常、そのような理解
練習の過程で来ます（あまり頻繁ではありません-数ヶ月または数年後に
頭の中の何かが落ちたと感じ、それを使用する準備ができました。
そして、プログラマーがパターンについて読んだかどうかに関係なく。 タスクが
彼の現在のアプローチの非効率性を示してから、彼は決断を下し、
うまくいくでしょう。 彼がどのように頭の中で呼んでも。 説明する
別のプログラマーに結果として生じるパターンは、ほんの数分です。 それに加えて
パターンの説明は、これらの例ですべてのプログラマーの脳に形成されます
それで、彼は共通の定義を持ち、二人が彼を使って、
まったく異なることについて話します
ジャンクパターン。
プログラマーが常に
作品でパターンの公式名を使用し、さらに、制限されています
これらの名前のみで、それらに関連付けられたロジックを説明せずに、ほとんどの場合
昨日の生徒か、パターンを使用する熱心なJavaファンのどちらか
言語の制限を回避することがルーチンの本質です。
広大を受け入れる
拡張可能なコードを作成することを目的としたすべてのプラクティスは主題を残します
このコードがサポートされ、拡張されるという仮定の領域への領域。 そして
これがプログラミングと他のエンジニアリングの最大の違いです
アクティビティ-通常、ユニットに十分な電力または機能がない場合、
より適切な別のユニットと交換してください。
プログラミングの暗黙の原則は、作成する代わりに
繰り返しますが、既存のものを拡張または変更することをお勧めします。 技術の利点が可能になります。 に
技術という言葉は、物理デバイスをアップグレードして実現することを可能にします
必要な機能。 それにもかかわらず、何らかの理由でこれは行われません。 きっと理由がある
本質的に純粋に経済的です。
ゼロから書き直し、完成したものを拡張するという2つのアプローチがあり、
2番目のオプションの方が優れており、労働集約的ではありません。 同時にそれを忘れる：
a）曲がって書かれた非拡張コードの場合、
機能を追加する
b）拡張可能なコードを作成する場合、書き換えのコストは既にかかっています
初期コーディング段階中
どちらの場合も労働は問題になりますが、問題はそれ以上の場合です。 そしてまさに
経験豊富なプログラマは、この質問に対する答えを良い方法で知っている必要があります。 経験者
建築家はたわごとを書くタスクを与えることができますが、1つの条件で-誰も
私はそれについて知る必要があります。
応用分野
あなたは場所を見つけることができないという事実のために何年も場所を見つけることができないかもしれません
あなたが読んだプラクティスですが、それはおそらくあなたに何かが間違っているという意味ではありません
そう。 知っていて使用しているパターンの数に関係なく、重要なのはできることです
それらをその場所に適用します。 一般的に、優れたデザイナーの知識の量は
数か月で習得できますが、それらを正しく使用する方法を学ぶために
それには何年もかかります。
少なくとも数十を含むシステムで作業していない場合
関連クラス（およびそのようなシステムがたくさんあります）、どのように気にする必要はありません
さまざまな抽象化から乱交パーティーを作り、すべてが見えるようにする方が良い
軽いエロティシズムが好きです。 あなたは一般的に良いプログラマーになることができます
そのようなプロジェクトに参加し、小さなプロジェクトとシステムの間を移動します
接続性が低い。
誰がなぜそれを使用しているのかをまだ理解したい場合は、コードを調べてください
Java、C＃、C ++の大規模プロジェクト。 特に、以下のプログラマーにとって有用です。
スクリプト言語。これにより、アプローチの違いを明確に確認できます。
JavaやPythonなどでのプログラミングに。 とにかく、見つけても
特定のパターンの実装、それを心に留めてはいけません、
パターンは通常、特定のプロジェクト内で生成または選択されます。 だから何
あなたがそこに見たものはあなたの現在に適用できない可能性があります
プロジェクト。
当局が「正しいコード」を書くことを要求している場合-書いてください！ あなたは本当ですか
あなたはまだあなたの専門レベルで何が悪いのか理解していない、そしてそれはあなたにとって良い
チームリーダーがイデオロギーを持っている場合は、議論しないでください。
彼と一緒に-普通のプログラマは彼の信仰を破壊することはできませんし、キックを取得しないでください
あなたに。
どうする
あなたが理解していない何かを使用する前に考え、よく考えてください。 もし
それはあなたにとって不必要なように思えますが、本当にそうなる可能性があります。 それを見たら
テストは犬のポケットとしてプログラムを必要とします-書いてはいけません、あなたはまだ
それらが役に立つような方法でそれらを書くことはできません。 に精通している場合
パターンのリスト、そして恐怖で最後のカップルのコードでそれを発見しました
何年も、せいぜい3〜4人が避難所を見つけたが、そうでなければあなたはあなたに満足している
コード、およびそれで問題はありませんし、すべてをそのままにしておきます。
そしてもちろん、攻撃的なレトリックに対する人々の能力は常に戻っていることを忘れないでください
それらの証拠ベースに比例。 そして、あなたが品質になるたびに
仮想的な状況にアピールするために何らかのアプローチを使用するための議論、
発生の確率が疑わしいほど小さいので、
祖母は祖父になることができます。