コースを完了し、YouTube で一連のビデオを視聴したり、iOS 開発に関する一連の記事を読んだりすると、最初の重要なプロジェクトを作成する準備ができたと感じています。 まず、よくやった！すごいですね。あなたはクールです！ 💪 第二に、ペットプロジェクトはあなたのスキルを大幅に向上させます。指示に従わずに自分で何かを始めるときは、膨大な時間と労力を費やし、Google で検索し、大量の新しい情報を読み、それをフィルタリングして自分のケースに正確に当てはめようとする必要があります。つまり、すでに5倍にパワーアップする本格的なタスクです。 しかし、ほとんどの初心者は重要なことを無視します（自分から進んでではなく、その重要性を理解せずに）。この半年間、私は積極的に活動してきました。 そして、ペットプロジェクトを含め、新人の質問や問題を解決するのに役立ちます。 指導 初心者のあなたが必需品リストに組み入れ、マスターし、理解し、使用すべき上位 3 つのポイントを特定しました。 アクセスレベル 最初は、 修飾子に注目する人はほとんどいません。一方、 夜中に起こせば誰でもすぐに説明できます。さまざまな賢明な記事を読むと、人々は (単一責任) の考えに従ってクラスを大量に作成しようとします。 private SOLID については、 S そして、彼らは明確な良心を持って、 の所有物を から変更し、その逆も同様です。 class A class B class A { var someAValue: Int? } class B { let a = A() func foo() { a.someAValue = 1 } } 一般に、まだ不明な場合は、次の計画を立ててください。 どこでも と書き 削除します 常に private 、コンパイラーが文句を言ったら、このプロパティまたは関数に外部からアクセスしても問題ないかを考えてください。そうであれば、 private 。 考えるときは、現実世界との比較を参考にしてください。たとえば、クラスが店舗の場合、 プロパティには明らかに外部顧客がアクセスできる必要があります。しかし、 変更できるのは明らかに店舗内の従業員だけです。 goods moneyInCashRegister 結局のところ、顧客は、 おろか、 使用してもレジにアクセスすべきではありません。 fetch put 「 修飾子なしでもどのプロパティにアクセスでき、どのプロパティにアクセスできないかを完全に理解している」と主張する人もいるかもしれません。ただし、アクセス レベル修飾子の記述は設計の一部です。 3階に外に通じるドアがある家の設計図は作らないでしょう。 private そして、決して開かないように注意してください。結局のところ、他の人もあなたのコードを使用する可能性があります。 ちなみに、同様の状況が と にも存在します。繰り返しますが、値を変更するかどうかすぐに確信できない限り、常に を使用してください。 var let let アーキテクチャのシンプルさ 初心者は事前にすべてを計画しようとする傾向があることに気づきました。これは賞賛に値しますが、開発者は経験不足のために間違いを犯すことがよくあります。彼らは、過度に複雑なマネージャーを事前に準備します (通常は、 ）多くの複雑なメソッドを使用しますが、最終的には使用されません。その結果、コードの量と複雑さが増大します。 スタックオーバーフロー 便利な既製のサービスのように見えましたが、プログラマーは問題と誤解だけを抱えて終わりました。建築も同様です。 私の主張を伝えるために、プログラミングの歴史を簡単に説明したいと思います。 1960 年代の終わりまでに、プログラミングの人気が高まり始めると、プログラムのサイズも増加しました。ご存知のとおり、プログラムのサイズが大きくなると、コードの行数も増え、複雑さが増し、プログラムを理解することが難しくなります。 この問題に対処するために、プログラムをより小さく管理しやすい部分に分割できる関数と手順である構造化プログラミングが登場しました。コードはモジュール化され、再利用可能になり、より理解しやすくなりました。 構造化の出現により、プログラムはさらに成長し、サイズと複雑さの限界に再び達しました。したがって、1970 年代後半から 1980 年代前半までに、オブジェクト指向プログラミングのアプローチが形成されました。このソリューションにより、柔軟でスケーラブルなシステムの構築が可能になり、ますます複雑化するタスクに対処できるようになりました。 次の 10 年間、私たちはコンピューター ゲームのブームを目の当たりにしました。ユーザーのアクション (クリック、プレス) に対する反応が重要であることが判明し、イベント駆動型プログラミングの出現につながりました。 そして、Web アプリケーションとデスクトップ アプリケーションのコードを整理するために、同じデータをさまざまな観点から再配置する必要がある場合に、MVC パターン (つまり、モデルをその視覚的表現から分離する) が登場しました。 あなたは、問題が発生する -> 解決策が現れるという主なアイデアを理解しました。 問題→解決策。 では、なぜ初心者プログラマーは、問題がまだ発生していない時期にソリューション (アーキテクチャ) の適用を開始するのでしょうか?チュートリアルでは、少なくとも MVP を選択することをすぐに提案します。 1 つまたは 2 つの画面のテスト タスクでは、常に MVC を使用しないように指定します。 面接では、同じ 1 つまたは 2 つの画面を使用していくつかのプロジェクトを作成した人に、VIPER の問題について質問されます。まだ問題に遭遇していないのに、どうやってその問題を知ることができるのでしょうか? 人々はアーキテクチャの文脈でテスト容易性の利便性についてよく話しますが、テストを書いたことはありません。仮にそうしていたとしても、それは何らかのチュートリアルにのみ基づいており、実際のアプリケーションに結び付けずに単体テストのみに焦点を当てています。 彼らは MVP スキームを簡単な言葉で説明できますが、 や などの似た名前のプロトコルになると混乱することがよくあります。心の底では、彼らはすでにこれらすべてをオーバーヘッドとして認識しています 🙄🤯 ViewInput ViewOutput 結論: 自分で問題を引き起こさないでください。 MVC を恥じないでください。コントローラーが大きくなりすぎる場合、または不便な点が発生した場合は、新しいアプローチを探す時期が来たことがわかります。 UIのシンプルさ フロントエンド開発は初心者にとってドーパミンの楽園です。コードを書くとすぐに結果が画面に表示され、報酬 🍭 を受け取ります。それは間違いなくモチベーションになります。ただし、このコインには裏もあります。初心者は、すぐに過度に複雑な UI を作成しようとすることがよくあります。 さらに、複雑な機能は複雑な UI に従う傾向があります。現在、SwiftUI によってタスクが簡素化されていますが、実際の進歩が見られないまま、付加機能の追加に多くの時間を費やす可能性があります。 私はチームを組んで一つのプロジェクトに取り組むコースでiOS開発を学びました。私のチームでは、ダーク モードのフォントと色を選択することからアプリ開発を始めることを提案した人がいました。 全体として、彼はコース全体をそれに費やし、フォントと色が素晴らしいものになったことは注目に値します。しかし、その間、その男は実際のコードをほぼ 0 行しか書きませんでした。 アプリケーションの美しさと機能性が非常に重要であることは間違いありません。最終的には、この点に時間を費やす必要があります。もっと単純なものから始めるのが良いでしょう。 MVP (実用最小限の製品) を開発し、最も重要な機能に焦点を当て、そこから立ち上げます。 逆のアプローチでは、複雑なニュアンスに対処し、壊れ続けるメイン機能に常に対処することになります。 の 80対20ルール ここに適用されます — アプリケーションの基礎を作成してから、追加機能を追加します。 モバイル開発の初心者にとっては、複雑なソリューションを時期尚早に採用してしまうリスクがあります。フロントエンド開発の視覚的な報酬は魅力的ですが、多くの場合、単純な MVP から始める方が賢明です。 歴史的な傾向は、真の課題に対応してソリューションを進化させる必要があることを示唆しています。 基本原則を理解し、現実世界で問題が発生したときにそれに対処することは、効果的な開発にとって重要です。 でも公開されています ここ
