نصائح للمطورين المبتدئين

لقد عملت كمطور iOS منذ أكثر من ست سنوات. لقد صادفت العمل في العديد من الشركات والفرق المختلفة. عملت في مجال الاستعانة بمصادر خارجية وفي الخارج ، حتى أتيحت لي الفرصة للمشاركة في بدء التشغيل. والآن ، بعد عدة سنوات من التطوير التجاري ، بالإضافة إلى بضع سنوات من البرمجة في الجامعة ، بدأت أفرد بعض المبادئ أو القواعد لمقاربة نوعية لتطوير التطبيقات. في البداية كانت نصيحة لصديقي. إعطائه النصيحة ، اعتقدت أنني افتقرت إلى مثل هذه النصيحة عندما كنت بدأت للتو مسار التطوير الخاص بي. ماذا يمكنني أن أقول ، بعض اللحظات التي أدركتها بنفسي مؤخرًا ، والبعض الآخر موجود بالفعل في مكان عمل جديد. وهكذا ظهرت الفكرة لإعداد قائمة من النصائح التي أود مشاركتها مع نفسي قبل خمس إلى ست سنوات. أنا متأكد من أنه خلال خمس سنوات أخرى سيكون لديّ ما أقوله لنفسي اليوم. ولكن ربما سنترك هذا للمستقبل.

رمزك سيء

وأول شيء أود أن أقوله لنفسي كما كان من قبل هو: "رمزك سيء!". في عامة الناس ، "govnokod". ولزملائي الأجانب في ورشة التطوير "كود القرود".

لا ، هذا ليس ما فكرت به. لا أريد التأكيد على أنني اعتدت أن أكون مبرمجًا سيئًا ، والآن أكمل شفرتي. أريد إعادة صياغة هذه الرسالة ونقل ثلاث نقاط رئيسية بمعنى هذه النصيحة.

"كان رمزك وسيظل سيئًا!"

اللحظة الأولى: لا يوجد كود مثالي ، لا أحد يضع الهيكل المثالي ولا يوجد مثل هذا الرمز الذي لن يكون فيه أي أخطاء. أعتقد أن الكثيرين اشتعلوا أنهم يعتقدون أنهم لا يستطيعون معرفة المكتبة الجديدة أو التكنولوجيا الجديدة. أو ذهب البعض منا إلى أقصى الحدود في محاولة كتابة الميزة بشكل مثالي ، وفقًا لجميع مبادئ OOP ، SOLID. وهذا بدوره أدى إلى الكثير من الوقت وأدى في بعض الأحيان إلى طريق مسدود. في بعض الأحيان ، في محاولة لكتابة الكود المثالي ، وُلدت الوحوش التي تحمل قائمة كاملة من الأنماط التي يعرفها المطور ، أو ربما أكثر من ذلك.

بعباراتي ، أود أن أنقل فكرة أنه لا ينبغي أن تقلق أولاً وقبل كل شيء ، كن متوترًا بشأن جودة الكود. من المستحيل التنبؤ بكل شيء. من الأفضل فقط الاسترخاء ، والكتابة بشكل أسهل ، وكما تعلم ، من المعاناة والقلق دون جدوى. مع الخبرة ، سوف تتخذ القرارات من تلقاء نفسها. في بعض الأحيان يكون من الضروري "nagovodnodit" ، وسوف يواجهون مشاكل أن هذا الرمز الخفيف سوف يسبب ويفهم مرة واحدة وإلى الأبد أنه من الأفضل عدم القيام بذلك.

اللحظة الثانية ، التي ذكرتها سابقًا ، هي أنه يكاد يكون من المستحيل التنبؤ بكل شيء. نعم ، من خلال التجربة تأتي فهم ما تفعله ويمكنك التنبؤ بمسار تطوير المشروع. لكنه يأتي مع الخبرة. وإذا كانت التجربة غير كافية ، فعليك ألا تحاول جعل الشفرة عالمية. هناك حالات متكررة عندما يتم إلغاء الميزة الخاصة بك ، والتي فكرت بها لفترة طويلة وبحرص شديد في البداية ، ثم كتب ، من التطبيق. أيضا ، هناك حالات عندما تتغير التطبيقات فقط لأنه في عقل العميل يبدو كل شيء مختلفًا. وبعد ساعات طويلة من النقل المضني للواجهة من التصميم إلى الرمز ، تظهر 100،500 تغييرات فجأة. هذه ليست سوى البداية ، لأنه بعد إعادة التشغيل الأولى ، ستأتي المزيد والمزيد من التعديلات الجديدة. وفي حالة عدم وجود خبرة كافية لدى المطور ، يمكن أن تستغرق هذه العملية وقتًا طويلًا فحسب ، ولكنها لا تجلب أيضًا أكثر الأحاسيس اللطيفة التي تم تأجيلها بأفكار غير سارة في مكان ما في الزوايا السرية للعقل ، مما يحول عملية التطوير من درس ممتع إلى ألم جهنمي. لذلك ، اعتن بأعصابك ولا تتناسب مع المثالية. في بعض الأحيان يمكنك التحدث قليلا.

النقطة الثالثة: هذه مرة أخرى لحظة نفسية بحتة ، وهي نقد من المطورين الآخرين. كما يعلم الجميع ، فإن جميع المطورين المحليين يفكرون في أي كود كود آخر. حتى إذا تم عرض الكود الخاص به ، وهو أمر لا يتعرف عليه ، فمن المرجح أن يطلق عليه القرف. وغالبًا ما يكون هذا النقد مصحوبًا بالرضا الأخلاقي للناقد نفسه. كما لاحظ المطورين المتمرسين ، فإن الأشخاص الذين يطلقون على رمز شخص آخر هو govnokod على وجه التحديد أولئك الذين قاموا في وقت واحد أكثر من ترميز الماكرة. وكلما صرخ شخص أعلى صوت "govnokod" ، زاد "من الكعك" الذي تركه في طريقه.
بالإضافة إلى ذلك ، يجب على أي عذارى يتذكرن صغارهن بالضرورة أن يعترفا بأنه كان رمزًا مشهورًا.

لذلك ، أنصحك باستخدام تعبير "كان الرمز الخاص بك وسيظل خجلاً" ، كدرع من النقد غير البناء دائمًا. أريد أيضًا أن أشير إلى أن الكود سيكون دائمًا خزيًا لأن التطوير لا يظل ثابتًا. كل عام تتحسن جودة الشفرة الخاصة بك. وبالتالي فإن الكود الحالي سوف يتحول في النهاية إلى govnokod.

فرق تسد

لا أريد أن يبدو أنني أنصح govnokod فقط ، وبالتالي سأبدأ في تقديم المشورة بشأن كيفية تجنب هذا الرمز السيئ. وأود أن أبدأ بالمبدأ الذي وضعته جانباً لنفسي. لا ، هذا ليس الميراث أو تعدد الأشكال ، وليس أحد مبادئ سوليد. أنا أسمي هذا المبدأ "فرق تسد".

نعم ، هناك شيء مثل التحلل.

التحلل - تقسيم الكل إلى أجزاء. أيضًا ، يعد التحلل طريقة علمية تستخدم بنية المشكلة وتتيح لك استبدال حل مشكلة كبيرة بمجموعة من المهام الأصغر ، وإن كانت مترابطة ، ولكن أكثر بساطة.

كما تقول ويكيبيديا. ولكن هذا ليس سوى جزء مما وضعت في معنى مبدئي. بالتأكيد نعم ، تحتاج إلى تقسيم المشروع والمهام إلى أجزاء أصغر. لكنني أعني النهج المفاهيمي لفصل المجموعات المنطقية في المشروع.

وأول شيء أود أن أشير إلى هذا المبدأ هو الفصل بين واجهة المستخدم والمنطق التجاري للتطبيق. يبدو أنني الآن قائد مباشر للأدلة. ولكن! في الممارسة العملية ، غالبًا ما تكون هذه الحدود غير واضحة ويتضح أن ViewController أو النشاط يحتوي على جزء من منطق الأعمال.

أعتقد أن مثال على شاشة "تسجيل الدخول" سيكون بسيطًا ومفهومًا. يبدأ المطور هنا في تنفيذ بنية MVC. يبدو أن هناك وجهة نظر منفصلة ، كما يضيف المراقب المالي مع Model ، كما ينبغي. لكن في مرحلة ما يعتقدون: "لماذا أحتاج إلى إضافة عدة فئات للشاشة بضغطة واحدة؟" وفي هذه اللحظة أوصي بشدة بالتخلي عن مثل هذه الأفكار الشريرة والتقيد الصارم بمبدأ "فرق تسد" لفصل منطق واجهة المستخدم والأعمال. وحتى إذا كانت البنية تتطلب إضافة فئة ViewModel ، حيث سيكون هناك سطرين من التعليمات البرمجية ، فيجب عليك القيام بذلك. لأنه غالبًا ما تكون هناك حالات عندما تنمو الشاشة التي كان يوجد فيها زر واحد في الأصل ، بمرور الوقت ، لتصبح صعوبات لا يمكن تصوره. إذا اتبعت فصل المكونات المنطقية مقدمًا ، فسيؤدي ذلك إلى تسهيل الحياة في المستقبل بشكل كبير.

يمكنك أن تشعر بشكل خاص بجوهر الفصل الصارم بين واجهة المستخدم والمنطق ، في الحالات التي يتعين عليك فيها نقل الشاشات من مشروع إلى آخر. أو في موقف ، وفي ظل ظروف مختلفة ، يتم استخدام خوارزميات مختلفة في منطق الأعمال. على سبيل المثال ، من خلال تقسيم شاشة التفويض إلى مكونات ، يمكننا استبدال أحد المكونات في المستقبل دون التأثير على الآخر. يمكننا إما استبدال طريقة العرض أو النموذج بطرق تفويض جديدة لنفس البيانات.

لا تحد من مبدأ "فرق تسد" فقط على هاتين الطبقتين. إلى الفصل الصارم ، أود أن أضيف فصل الشاشات ومنطق التنقل لتطبيقات الهاتف المحمول. ماذا اقصد بذلك؟

لقد دفعتني ممارستي إلى تسهيل عملية الترميز لشاشة معينة عن طريق إخراج منطق التنقل بشكل منفصل. الشاشة ، وبالأخص عرض ، لـ iOS هي UIViewController ، وأحيانًا UIView ، ولأنشطة Android أو Fragment ، يجب ألا تشارك في وظيفة لعرض نفسها ، وكذلك التبديل إلى شاشات أخرى. يجب أن يهتم كل فصل من هذه الفئات بما يحدث على شاشة معينة ، أو بالأحرى ، فقط لعرض شاشة معينة والتفاعل مع فئة منطق الأعمال (مقدم العرض ، ViewModel وغيرها).
هذان مجرد مثالين من أمثلة كثيرة تحتاج فيها إلى اتباع الفصل بشكل أساسي. اتباع هذا المبدأ سوف يسهل إلى حد كبير العمل الإضافي مع المشروع. حتى لو حصل govnokod في أي من مكونات منفصلة.

نمط واحد

انطلاقًا من النصيحة السابقة بسلاسة ، أريد الانتقال إلى النصيحة التالية ، وهي الالتزام الصارم بأسلوب واحد في المشروع.

ماذا اقصد بذلك؟

بادئ ذي بدء ، الكلمة الأساسية هنا صارمة ، من الكلمة على الإطلاق. في البداية ، نختار طريقة واحدة لتنظيم مشروع ، لإدارة الملفات ، لنمط الكود ، وما إلى ذلك. سيؤدي ذلك إلى تحسين المظهر العام للمشروع إلى حد كبير ويسهل بشكل كبير التنقل في المشروع ، والبحث عن طريق الرمز ، وتسريع عملية إدخال مطور جديد للمشروع. أعتقد أنه لا يجدر التذكير بأنه بعد فترة من الوقت يمكننا أن نصبح هذا الشخص الجديد برمزنا القديم.

اختيار العمارة ومتابعتها

مرة أخرى ، انطلاقًا من النصيحة السابقة ، ننتقل بسلاسة إلى الخطوة التالية ، وهي اختيار الهندسة المعمارية. والفكرة الرئيسية التي أريد أن أنقلها هي عدم الحديث عن أفضل الهياكل أو القول بأنك بحاجة إلى اختيار هذا وليس آخر. لا! بادئ ذي بدء ، لا توجد بنية مثالية تغطي بالكامل جميع الحالات المحتملة في المشروع. سمعت هذه الكلمات ذات مرة: "إذا كان هناك بنية مثالية ، فسوف يتم إطلاقنا نحن المطورين على أنها غير ضرورية واستبدالها بنصوص تولد البنية المثالية".

النقطة الرئيسية ، في اعتقادي ، ليست اختيار أفضل بنية ، ولكن مرة أخرى الالتزام الصارم بالعمارة التي تم اختيارها بالفعل وبدأ تطبيقها. سواء كان ذلك VIPER ، REDUX ، MVP أو MVC. هناك بالطبع إيجابيات وسلبيات لكل من الهياكل المذكورة أعلاه. مع مرور الوقت ، المزيد والمزيد من الأساليب الجديدة لتصميم بنية المشروع.

سأقول بشكل أكثر تحديدا عن فكرتي. إذا كنت قد بدأت بالفعل في استخدام VIPER ، فاتبع مبادئها بدقة. حتى إذا بدا أن هناك شاشة مفردة للعديد من الملفات لإنشاء وحدات من أسطر التعليمات البرمجية ، لا تتجاوز هذه القواعد تحت أي ظرف من الظروف. لأنه في مثل هذه اللحظات ، يولد govnokod ، الذي ينمو وينمو كل شيء ، مثل كرة الثلج.

أنصحك بالتعرف على أكثر البنى شهرة واختيار البنى التي تفضلها أو الأكثر شعبية قبل البدء في مشروع جديد. أوصي بشدة باختيار الخيار الثاني ، أي البدء بالهندسة المعمارية الأكثر شيوعًا سيكون من السهل العثور على إجابات لكثير من الأسئلة. عند اختيار بنية ، يجب إيلاء اهتمام خاص للسلبيات الخاصة بهذه البنية وفي الحالات التي يوصى باستخدامها.

على سبيل المثال ، إذا كان لديك مشروع صغير ، يوجد به مطوران ، فلا يجب أن تأخذ VIPER نظرًا لحقيقة كونه بنية مرهقة إلى حد ما جيدة في المشاريع الكبيرة والفرق الكبيرة. بحيث لا توجد حالات عندما يكون رمز إنشاء VIPER أكثر من عدة مرات من رمز منطق العمل نفسه.

أنا شخصياً أفضل الآن بنية MVVM + Router. إنه يعمل جيدًا في مشروع صغير ، حيث أنني مطور واحد.

خلاصة القول: الشيء الرئيسي هو ليس الهندسة المعمارية التي اخترتها ، ولكن كيف بالضبط متابعتها.

أريد أيضًا أن أضيف ، إذا لم يتم تطوير المشروع من البداية ، فأنت بحاجة أولاً إلى التعرف على البنية الحالية والأسلوب العام للمشروع ، والبدء في متابعته. يجب أن لا تندلع صراخ أن هناك govnokod (العودة إلى النصيحة الأولى) والبدء في إعادة كل شيء. استثناء قد يكون فوضى كاملة في المشروع أو عدم وجود نمط شائع.

إعادة بيع مؤقتا

في الختام ، أود أن أقول إن التوقف عن إعادة بيع المنازل هو نهج جيد. إعادة بيع الأراضي جزء مهم جدًا من تطوير تطبيقات الجودة. نعم ، لا نكتب الشفرة المثالية على الفور ، لكن تركها لأنها ليست جيدة أيضًا. يحدث غالبًا أن التنفيذ الأصلي لا يملك القدرة على التوسع عندما تحتاج إلى تقديم ميزات جديدة. بعد كل شيء ، يكاد يكون من المستحيل التنبؤ بجميع التغييرات المحتملة في الإصدارات المستقبلية من المشروع. أيضا ، لا يضمن العمارة تغطية 100 ٪ من جميع الحالات. لذلك ، من المهم إجراء تغييرات على التعليمات البرمجية الموجودة من أجل تكييفها مع الميزات الجديدة.