1.私たちは正しい
システムの構築方法を正確に知っていると思うときはいつでも正しいです。 多くの場合、既製のソリューションはどのような状況にも完全には適合しないためです。 そして、利用可能なソリューション、たとえば膨大な数のパターンなどは、私たちによって書かれました。 プログラマ。 したがって、はい！ そうです。 まあ、お互いに耳を傾ける必要性に関しては、それはむしろコミュニケーションの問題です。
2.壊れる可能性のあるすべてが壊れているわけではありません
理論的には、すべてが壊れる可能性があります。 原子的なものでさえ、失敗のオプションは単純に除外されます。 しかし、なぜ壊れないのですか？ 発生する場合と発生しない場合がある適切な条件が必要であるため。 システムの再設計時に、システムをクラッシュさせる可能性のあるエラーが検出された場合があります。 しかし、システムの運用の長年にわたって、関連する条件は発生していません。
3.すべてのコードが「がらくた」ではない
その見出しでごめんね。 同じステートメントのセットが3回繰り返されるコードは、ステートメントのセットがループで囲まれている同様のコードよりも安定している場合があります。 これは、このように書くための呼び出しではなく、タスクが解決されるオプションのパレットに読者の注意を引き付けようとする試みであり、システムは長時間、耐障害性で動作します。
一般的に、コードの「がらくた」は純粋に主観的な概念です。 結局のところ、経験豊富なプログラマーなら誰でも、どのように多才/効率的/高速/より美しく書くことができるかを評価することができます。 したがって、「govnokoda」などのサイトやネットワーク上の他の愚かなリソースがあります。
4.プログラムに常にバグがあるとは限らない
まだ書かれていないプログラムにはバグはありません:-)。
しかし、私は大学の2年目のケースを思い出します。 16進エディタで、彼は何もしないcomプログラムを書きました。 nopとretの2つのオペコードを記述する必要がありました。 彼らは混乱していた。 怖くないが、バグ。
5.最も重要なことは、幸福と卓越性の追求です。
私はこれらのことをいかなるクライアントの野心とも交換しません。 私はささいなことを中断します。最初は、私たちが望むほどの収入を得られません。 オプションを探します。 しかし、主なことは、開発をやめることではなく、成長中のプログラマとしてあなたにとって本当に重要であることを忘れないことです。
6.紙プログラム...
これは、大学の最初のコースで実験室の仕事に合格した後の習慣です。 特に熱心な生徒は、プログラムを電子ソースに転送する前に、紙に数回書き留めることさえできます。 一部の非常に勤勉な教師は、エディターでプログラムをスケッチし、デバッグ後にレポートに印刷し、手で書き直さないため、あまり勤勉でない生徒をoldりました。 私が言いたいこと：紙にプログラムを書くことは完全にナンセンスだ。
7.少ないほど良い、多いほどさらに良い。
質問はかなり哲学的です。 それは、何がより多く何がより少ないかに依存します。 私の意見では、小さなものがたくさんあり、この小さなものが相互に作用する場合が理想的です。 しかし、準備ができたレシピでも完璧な問題を解決できないことを忘れないでください。 したがって、質問は哲学的な地位を保持します。
8.エンコードには20％の時間がかかります。
「コーディング」と「プログラミング」の概念を区別する場合、その逆も同様です-コーディングには80％の時間がかかり、実際のプログラミングには20％しかかかりません。
これらの概念を区別しないと、パレートの法則が常に完全に機能するとは限らないことが経験からわかります。 そして、それはシステムのサイズに依存します。 多くの場合、システムはシンプルですが、実装に関しては膨大です。 その後、計画など など 少し時間を割いてください。 逆に、システムは小さくても実装は困難です。 同時に、1週間の計画、モデル化ができます。 そして、一晩で200行のコードを記述し、数時間で正常にデバッグします。
9.顧客は自分が何を望んでいるかを知っている
彼は自分が何を望んでいるか知っています。
-いくつかの解決策
-自動化
-代表的なサイト
-制御システム
-節約
それがどのように実装されるか、どのツールと手段、どのような詳細がプロジェクトに含まれるか、何人がそれをPythonまたはphpで書くか-これは顧客には必要ありません。 彼は完全に完全にビジネスに携わっており、ビジネスの文脈で必要なものを知っています。
10.興味深いタスク-ソリューションの成功の半分
日常業務には、日常的な障壁を克服するための完全なコミットメントが必要です。
誰かがすでに行っている場合、それは確かに一見の価値があります。 ただし、上記の点から、特に本質的に不要な場合は、重いヒープフレームワークを作成するよりも、「bydlokod」を作成した方がよい場合があることは明らかです。