たまたま私は開発者でありマネージャーでもあるため、コードを2つの反対の観点から見ることを余儀なくされています。 開発者として、私はすべてが美しく、速く動作することを望んでいますが、マネージャーとして、私は本当にリリースが時間通りであることを望んでいます。 つまり、この2人は少し違うことを望んでいるので、私は少し分裂した性格に苦しんでいます。 そして、これが私が気づいたことです。 マネージャーのリードに従う戦略は、中期的には非常にうまく機能し、長期的には継ぎ目で亀裂が入り始めます。 数ヶ月、さらには数年前に私が敷設した時限爆弾の鉱山に出くわすのは十分に痛かったので、私はすぐに行わなければならないことの短いリストを書き留めることにしました。
私の熊手の上を歩きたくない場合は、猫にようこそ。
データベース
これは、変更するのが最も苦痛になる場所です。 アプリケーションの成長に伴い、ある程度のデータを蓄積します。 また、データベース設計のエラーは、すべてのデータを保存する必要があるため、最も高価になります。 最初に注意する必要があるのは、データベースレイヤーをスケーリングする機能です。 Webサーバーを追加しても問題はありません。クラウドと仮想化があらゆる場所にあります。 データベースを使用すると、すべてがより複雑になります。 まず、根本的に異なる2つの戦略の選択：レプリケーションまたはシャーディング。 クラスターを完全に背後に置きます。 つまり、データベースサーバーをそのまま使用することはできません。 そのため、大量のデータだけでなく大量のデータがある可能性がある場合は、これらすべての問題を事前に検討することをお勧めします。インデックスと制約
従来、インデックスと定数を付加することは忘れられていました。 特に忘れがちな鍵も忘れてしまいます。 したがって、dbの不整合領域から奇妙なエラーが発生します。 定数がないため、データベースを一貫性のない状態、つまり開発者が予期していなかった状態にすることができます。 このようなエラーをキャッチして修正するのは長くて面倒です。ビューをレイヤーにすばやく転送するために、JSONまたはXMLをデータベースに貼り付けることが必要になる場合があります。 アイデアはそれ自体が良い方法ですが、この方法では、従来のSQLソリューションの主な強みは失われます。 遅かれ早かれ、問題をソートするように求められ、それは不快になります。 JSONが欲しい-簡単に。 mongaまたは他のno-sql'eを使用して、データの整合性またはアクセス速度を重視するものを選択します。
さらに、データベースはパフォーマンスの点で伝統的にボトルネックです。 これをどのように解決しますか？ データベースをわずかに非正規化するか、CQRSを固定するだけで十分ですか、それともすべてを正常にキャッシュできますか？ 銀の弾丸、いつものように、いいえ。 それはすべて、アプリケーションの詳細に依存します。 これらの質問はすべて、事前に自問するのが最善です。 私は大砲からスズメを撃つことをお勧めしません。 最初の段階では、これはすべてひどいオーバーヘッドのように思えるかもしれませんが、すぐにスーパーアーキテクチャを実現する必要はありません。 この段階で十分なコードを記述する方がはるかに合理的ですが 、後で痛みを与えないように、数ステップ先のアプリケーション開発計画を実行する必要があることに留意してください。
アプリケーション層と単体テスト
これは私が決して変更しない場所です...だから私は一度、アプリケーションの基本的なロジックを変更する必要がなくなるまで考えました。 ソフトウェアはチケットを販売しており、一般的に、ある日、同じチケットの機関の論理を変更しなければなりませんでした。 リファクタリングに2週間かかりましたが、その間にアプリケーションのビジネスロジックの新しいレイヤーを構築しました。以前のレイヤーを統合テストのレベルでのみテストし、データベースをロックすることは不可能だったからです。 DTOとエンティティレイヤーが混在していました。 テストできないことは、強力な接続の最大の頭痛の種ではありません。アプリケーション層の順序の欠如は、開発者の頭の順序の欠如を示しています。 新しい機能要求はそれぞれ、最も予想外の場所で別のハックを表し始め、アプリケーションのビジネスロジックはコード全体に均等に分散されます。 このようなコードを変更することは、常に予想外であり、最も都合の悪い瞬間に、副作用を発生させずに変更することは不可能です。 そのため、私は長い間、テストなしで単一の深刻なアプリケーションを作成していません。 ユニットを使用すると、アプリケーション層を混在させることはまったく不可能です。 テストを書くことはできません。これにより、現在のアーキテクチャを批判的に再考することができます。
ヌル参照または防御プログラミング
長い間、私はヌルリンクを渡さなかったので、「落とす」と思っていました。 そしてそれは私のために働いた。 時間が経つにつれて、この方法でNULLをチェックするコードがプロセスチーズのようにアプリケーション全体に広がり始めることに気付きました。 さらに、私が作業したすべての開発者がNULLの値をチェックしたわけではありません。 そして、ここに私が気づいたものがあります：防御的な構造の記述は退屈な作業であるため、これらのチェックの数を最小限にするような方法で自動的にコードを記述し始めました。 これは、システム全体の設計にプラスの効果をもたらしました。 コードが小さくなり、コードの構造が改善されました。 NULLチェックを宣言的にするためのAOPの機能を調べますが、これまでのところは良いと感じています。アプリケーションステッチとSRP
データベースと同様に、アプリケーション層は1つの目的にしか役立ちません。将来、システムの一部を迅速かつ簡単に置き換えることができます。 単一のSimpleFileStorage実装を使用してIFileStorageを作成する方が、クラウドに移行することにしたため、ファイルシステム内のレコードをアプリケーション全体で検索するよりもはるかに簡単です。 経験を積むと、変化する可能性が最も高い場所の内臓（または身体の他の部分）をすでに感じ始めています。 SRPに違反するたびに、数分または数時間の時間を節約できます。これにより、数日および数週間後になります。 すぐにそうです、マネージャーは幸せです...今。 その後、なぜこの小さな変更をそれほど長くするのかという疑問が生じます。Webサーバーのスケーリング
サーバーの容量を常に増やすことはできません。 遅かれ早かれ、チャネル機能に遭遇します。 そしてここで、直接使用したすべての静的変数が突然表示されます。 一般に、すべてのレベルでのシステムの水平スケーリングは、事前に考慮する必要があるものです。 ここでも、別のサーバーを挿入するまで、スチームバスを使用して静的変数に正確に書き込むことはできません。 与えられたものが。 IDataProvierまたはIProblemResolver内でこれらすべてのダーティなことを行います。 その後、1つのクラスのみを変更する必要があり、コード全体で変更を収集する必要はありません。DevOps
そして、どのように展開しますか？ まあ、私はすべて展開されていますが、コンピューターを変更したり、OSを再インストールしたり、その他のナンセンスを行うことはしません。 新しい開発者はどうですか？ まあ、彼らはプログラマーです、それは彼らの仕事です、彼らはそれを理解しなければなりません。 これを文書化する必要はありません。さらに、展開を容易にするために追加の作業は必要ありません。顧客のシステムをサーバーに2日間展開したら、 すべてが使用されました。タンバリン、Tuvanの民俗歌、そして最も重要なのはConfig Toolです。 まったく同じ設定ツールがなければ、誰もアプリケーションを動作させることができませんでした。 そして、このツールがインストーラーであれば幸いです。 残念なことに、Config Toolは厳密に定義された条件下で実行する必要のあるコンソールアプリケーションでした。その後、アーカイブをアップロードし、すべてを手動でサーバーに展開しました。 ただし、構成ツールがなければ、誰もアプリケーションのバンドル全体を構成できませんでした。 Softinaは、問題の本質を完全には反映していないエラーで大幅に失敗しました。たとえば、問題は承認にありましたが、証明書に呪われていました。
Ruby on RailsとASP.NETは、長年にわたり、アプリケーションをデプロイするためのシンプルでクールな方法を提供してきました。 環境が提供するチップを使用してください。 提供しない場合は、いつでも展開プロセスを少し簡単にすることができます。 これは、アプリケーションレベルだけでなく適用されます。 コードの最初の行を書く前に、これを覚えておくと便利です。 データベースに構成を配置する場合は、午前2:00に運用環境でデータベースを編集しないように移行を追加します（古い構成があるため）。 あなたのチームの他の開発者も、VCSからの次の更新後、タンバリン、Tuvanのフォークの歌と香水を使用して事前に設定する必要があるメガスーパーの新しいものでアプリケーションが動作するという事実から何も落ちない場合、感謝します。
マルチスレッドプログラミング
マルチスレッドコードを書くことができると確信していますか？ 本当に必要ですか？ マルチスレッドコードを記述できない場合は、記述しないでください。 面白いですね。 そしておそらく、 あなたのマシン上のいくつかのデータセットでさえ、それは正しく動作します。 マルチスレッドプログラミングは完全に独立した知識分野であり、マルチスレッドアプリケーションの作成はシングルスレッドアプリケーションよりもはるかに困難です。 正確にデバッグする方法。 あなた自身とあなたの同僚をあなたの神経を救ってください。物事は簡単に思えます。 彼らはこれについてすべて話しました。 しかし、これは私に日々の仕事で最も問題を与えるものです。