あなたのコードは悪いです
そして、以前のように私が最初に言いたいことは、「あなたのコードは悪いです！」です。 common民では、「govnokod」。 そして、開発ワークショップの私の外国人の同僚は「猿のコード」を持っています。
いいえ、それはあなたが思ったことではありません。 私はかつて悪いコーダーであったことを強調したくありませんが、今では私のコードは完璧です。 このメッセージを言い換え、このアドバイスの意味で3つの重要なポイントを伝えたいと思います。
「あなたのコードはそうだったし、悪いだろう！」
最初の瞬間：完璧なコードはなく、理想的なアーキテクチャーを構築する人はいません。また、バグがないようなコードはありません。 多くの人が、新しいライブラリや新しいテクノロジーを理解できないと考えていたと思います。 または、OOP、SOLIDのすべての原則に従って、機能を完全に記述しようとして極端に進んだ人もいます。 それは多くの時間をもたらし、時には行き止まりをもたらしました。 完全なコードを作成しようとするときに、開発者が知っているパターンの完全なリスト、またはそれ以上を含むモンスターが生まれることがありました。
私の言葉で、私はあなたが最初に心配するべきではないという考えを伝えたいです、あなたのコードの品質に神経質になりなさい。 すべてを予測することは不可能です。 そして、苦労して無駄になることを心配するよりも、ただリラックスして、より簡単に、そしてご存じのように書く方が良いです。 経験があれば、意思決定は自分たちでやってくるでしょう。 時々、このgovnokodが引き起こし理解する問題に直面して、「nagovnodit」が必要になることがあります。
2番目の瞬間は、前述したとおり、すべてを予測することはほとんど不可能です。 はい、経験を積むことで、あなたがしていることを理解することができます。そして、プロジェクトの開発パスを予測することができます。 しかし、これには経験が伴います。 経験が足りない場合は、コードを普遍的にしようとしないでください。 長い間、最初は慎重に考えて作成した機能が、アプリケーションから単純に破棄される場合がよくあります。 また、顧客の頭ではすべてが異なっているように見えるために、アプリケーションが変更される場合が頻繁にあります。 そして、インターフェイスを設計からコードに長時間の骨の折れる転送の後、100,500の変更が突然現れます。 最初のやり直しの後、より多くの編集が行われるため、これはほんの始まりです。 そして、開発者が十分な経験を持っていない場合、このプロセスには多くの時間がかかるだけでなく、心の秘密の隅のどこかで不快な考えによって延期される最も楽しい感覚ももたらさず、開発プロセスを楽しいレッスンから地獄の痛みに変えます。 したがって、あなたの神経の世話をし、理想に合わない。 時々、少し話すことができます。
第三のポイント：これは、純粋に心理的な瞬間、つまり他の開発者からの批判です。 誰もが知っているように、すべての国内の開発者は他のコードを検討します-たわごと。 自分が認識していない自分のコードを見せられたとしても、彼はそれをたわごとと呼ぶでしょう。 多くの場合、そのような批判には、批評家自身の道徳的満足が伴います。 経験豊富な開発者が述べているように、それは最も頻繁に他の誰かのコードをgovnodkodと呼ぶ人です。 そして、誰かが「govnokod」と叫ぶほど、彼の「ケーキ」が彼の道に残った。
さらに、自分自身を若く思い出すバージンは、彼が名声のノボコードであったことを必然的に認めなければなりません。
したがって、「あなたのコードはかつてくだらないコードであった」という表現を、常に建設的な批判ではないことを防ぐために使用することをお勧めします。 また、開発が止まっているわけではないので、コードは常にたわごとになることに注意してください。 毎年、コードの品質が向上するだけです。 したがって、現在のコードは最終的にgovnokodに変わります。
分割して征服する
私はgovnokodだけに助言するように思わせたくないので、その悪いコードを避ける方法についてアドバイスを始めます。 そして、私は自分のために取っておいた原則から始めたいと思います。 いいえ、これは継承やポリモーフィズムではなく、SOLIDの原則の1つでもありません。 私はこの原則を分割統治と呼んでいます。
はい、分解のようなものがあります。
分解-全体を部分に分割します。 また、分解は、問題の構造を使用する科学的な方法であり、1つの大きな問題の解決策を、相互接続ではあるが簡単な一連の小さなタスクに置き換えることができます。
ウィキペディアが言うように。 しかし、これは私が私の原則の意味に入れたものの一部にすぎません。 もちろん、プロジェクトとタスクを小さな部分に分割する必要があります。 しかし、プロジェクト内の論理グループの分離に対する概念的なアプローチを意味します。
そして、私がこの原則に帰した最初のことは、ユーザーインターフェイスとアプリケーションのビジネスロジックの分離です。 私は今、証拠の直接キャプテンであるように思われます。 しかし！ 実際には、これらの境界はしばしばぼやけており、ViewControllerまたはActivityにビジネスロジックが含まれていることがわかります。
「ログイン」画面の例はシンプルでわかりやすいと思います。 ここで、開発者はMVCアーキテクチャの実装を開始します。 必要に応じて、モデル付きコントローラーも追加するように、別のビューがあるようです。 しかし、ある時点で、「1つのボタンで画面に複数のクラスを追加する必要があるのはなぜですか」と考えています。そして、現時点では、UIとビジネスロジックを分離するために「分割統治」の原則を厳守することを強くお勧めします。 そして、アーキテクチャがViewModelクラスの追加を必要とする場合でも、その中に2行のコードがありますが、そうする必要があります。 なぜなら、元々1つのボタンがあった画面が、時間の経過とともに想像を絶する困難に発展するケースがしばしばあるからです。 事前に論理コンポーネントの分離に従うと、これにより将来の生活が大幅に促進されます。
あるプロジェクトから別のプロジェクトに画面を転送する必要がある場合、UIとロジックの厳密な分離の本質を特に感じることができます。 または、異なる条件下で、ビジネスロジックで異なるアルゴリズムが使用される状況。 たとえば、承認画面をコンポーネントに分割すると、将来、コンポーネントの1つを他のコンポーネントに影響を与えずに置き換えることができます。 ビューまたはモデルを、同じデータの新しい認証方法に置き換えることができます。
「分割統治」の原則をこれらの2つの層だけに限定するべきではありません。 厳密な分離に、モバイルアプリケーションの画面とナビゲーションロジックの分離を追加します。 それはどういう意味ですか？
私の練習により、ナビゲーションロジックを個別に取り出すことで、特定の画面のコーディングを簡単にすることができました。 iOSの画面、具体的にはViewはUIViewControllerであり、場合によってはUIViewであり、Androidアクティビティ（フラグメント）の場合、それらは自分自身を表示したり、他の画面に切り替えたりする機能に関与すべきではありません。 これらの各クラスは、特定の画面で何が起こっているかだけを気にするか、特定の画面をレンダリングし、ビジネスロジッククラス（Presenter、ViewModelなど）とやり取りする場合にのみ注意する必要があります。
これらは、基本的に分離に従う必要がある多くの例のうちの2つにすぎません。 この原則に従うことで、プロジェクトのさらなる作業が大幅に促進されます。 govnokodが個別のコンポーネントのいずれかに含まれている場合でも。
シングルスタイル
前のアドバイスから順調に進んで、次のアドバイス、つまりプロジェクトの1つのスタイルを厳守することに進みたいと思います。
それはどういう意味ですか？
そもそも、ここでのキーワードは厳格です。 最初に、プロジェクトの編成、ファイル管理、コードスタイルなどに単一のアプローチを選択します。 これにより、プロジェクトの全体的な外観が大幅に改善され、プロジェクトのナビゲーション、コードによる検索が大幅に容易になり、プロジェクトに新しい開発者を導入するプロセスがスピードアップします。 しばらくすると、私たち自身が古いコードでこの新しい人になることができることを思い出す価値はないと思います。
アーキテクチャの選択とフォロー
繰り返しますが、前のアドバイスから進んで、次のアーキテクチャ、アーキテクチャの選択にスムーズに進みます。 そして私が伝えたい主なアイデアは、最高のアーキテクチャについて話すことではなく、別のアーキテクチャではなくこれを選択する必要があると言うことではありません。 いや！ そもそも、プロジェクトで考えられるすべてのケースを完全にカバーする理想的なアーキテクチャはありません。 「理想的なアーキテクチャがあれば、開発者は不必要に解雇され、理想的なアーキテクチャを生成するスクリプトに置き換えられます」という言葉を一度聞いたことがあります。
主なポイントは、最高のアーキテクチャを選択することではなく、すでに選択され、適用され始めているアーキテクチャを厳守することだと思います。 少なくともVIPER、REDUX、MVP、またはMVCであること。 もちろん、上記の各アーキテクチャには長所と短所があります。 時間が経つにつれて、プロジェクトアーキテクチャの設計に対する新しいアプローチがますます登場しています。
私の考えについてより具体的に言います。 すでにVIPERの使用を開始している場合は、その原則に厳密に従ってください。 ワンボタン画面の場合、コードの行単位を作成するにはファイルが多すぎると思われる場合でも、どのような状況でもこれらのルールをバイパスしないでください。 なぜなら、このような瞬間にgovnokodが生まれ、それが雪だるまのように、すべてが成長し成長するからです。
新しいプロジェクトを開始する前に、最も人気のあるアーキテクチャに精通し、好みのアーキテクチャまたは最も人気のあるアーキテクチャを選択することをお勧めします。 2番目のオプションを選択することを強くお勧めします。つまり、最も人気のあるアーキテクチャから始めます。 多くの質問に対する答えを見つけるのは簡単です。 アーキテクチャを選択するときは、このアーキテクチャのマイナスに特別な注意を払う必要があり、その場合は使用することをお勧めします。
たとえば、2人の開発者がいる小さなプロジェクトの場合、これはかなり面倒なアーキテクチャであり、大規模なプロジェクトと大規模なチームで非常に優れているため、VIPERを使用しないでください。 そのため、VIPERを作成するためのコードがビジネスロジック自体のコードよりも何倍も大きい場合はありません。
個人的には、MVVM +ルーターアーキテクチャを好むようになりました。 私が単一の開発者である小さなプロジェクトでうまく機能します。
要点：主なことは、どのアーキテクチャを選択したかではなく、どのように正確にそれに従うかです。
また、プロジェクトがゼロから開発されていない場合は、まず、現在のアーキテクチャとプロジェクトの一般的なスタイルに精通し、それに従うことを開始する必要があります。 govnokod（最初のアドバイスに戻る）があるという悲鳴を上げて、すべてのやり直しを開始しないでください。 例外は、プロジェクトの完全な無秩序または一般的なスタイルの欠如です。
リファクタリングの一時停止
結論として、リファクタリングのために一時停止することは良いアプローチであると言いたいと思います。 リファクタリングは、品質の高いアプリケーション開発の非常に重要な部分です。 はい、すぐに完璧なコードを書くわけではありませんが、そのままにしておくのも良くありません。 新しい機能を導入する必要がある場合、元の実装には拡張機能がないことがよくあります。 結局のところ、プロジェクトの将来のバージョンで起こりうるすべての変更を予測することはほとんど不可能です。 また、すべてのケースを100％保証するアーキテクチャはありません。 したがって、既存のコードを変更して新しい機能に適合させることが重要です。