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

إذا أن متجر غوغل بلاي يتطور يوماً بعد يوم، وهو يدعم خاصية فلترة رهيبة تكون فعلياً بالتعاون مع مطوري التطبيقات..

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

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

في البداية عندما يقوم أي مطور تطبيقات بكتابة الكود الخاص بتطبيقه فعليه أن يقوم بالتصريح عن الميزات ونوع العتاد الذي يحتاجه تطبيقه ليعمل بشكل سلس ويقوم بذلك عن طريق Android Package Manager أو الحزمة الإدارية الخاصة بأندرويد والتي تحوي على العديد من التوابع والثوابت التي بإمكاننا استخدامها كمطوري تطبيقات لتعريف الميزات التي يحتاجها التطبيق مثل:

استدعاء ميزة البلوتوث: android.hardware.bluetooth

والتي تستخدم للدلالة على أن التطبيق يحتاج لميزة البلوتوث على الجهاز كي يعمل

استدعاء ميزة البصمة: android.hardware.fingerprint

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

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

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

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

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

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

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

أخبروني رأيكم، هل صادفتم هذه الحادثة من قبل؟ وهل ترغبون بالمزيد من المقالات حول تطوير تطبيقات الأندرويد بشكل مختصر ومبسط؟

أخبروني رأيكم في التعليقات..    

التدوينة تعرف على سبب عدم ظهور جميع التطبيقات لك في متجر غوغل بلاي تم نشرها أولًا في أردرويد.

بدأت سامسونج في وقت سابق من شهر أيار/مايو الحالي إطلاق تحديث أندرويد 8.0 أوريو لهواتف Galaxy S7.

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

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

ونظرًا لذلك، قررت شركة سامسونج إيقاف هذا التحديث مؤقتًا، كما أكد المشرفون على منتديات سامسونج، وقالت الشركة في بيانها: “بعد الإبلاغ عن عدد محدود من الحالات التي تم فيها إعادة تشغيل أجهزة Galaxy S7 على نحو غير متوقع باستخدام أندرويد 8.0 أوريو، توقفنا مؤقتًا عن طرح التحديث”.

وأضافت الشركة: “نحن نحقق في المشكلة داخليًا لضمان أن التأثير على الأجهزة المتأثرة في الحد الأدنى ويمكن استئناف عملية التحديث بأسرع وقت ممكن”.

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

هل تملك أحد هاتفي Galaxy S7 وحدثت معك المشكلة؟ شاركنا تجربتك لها بالتعليقات.

المصدر

The post سامسونج توقف إصدار أندرويد 8.0 إلى هواتف Galaxy S7 بعد حدوث مشكلات appeared first on أردرويد.

تساهم أداة App Bundle بتقليص حجم ملفات التطبيقات بنسبة تصل إلى 50%.

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

لحل هذه المشكلة، أعلنت جوجل خلال مؤتمرها السنوي للمطورين Google I/O 2018 عن أداة جديدة لمطوري التطبيقات تساعدهم في خفض أحجام تطبيقاتهم بشكل جذري اعتمادًا على الأجهزة، والتي تطلق عليها جوجل اسم Android App Bundle.

لفهم طريقة عمل هذه التقنية، علينا أولًا فهم طريقة عمل ملفات APK المُستخدمة حاليًا: كي يدعم التطبيق مختلف أنواع الأجهزة من حيث دقة وحجم الشاشة، لغة الهاتف، أو معمارية المعالج، يحتاج المطوّر إلى توفير جميع الموارد المتناسبة مع مختلف أنواع الأجهزة ضمن تطبيقه. على سبيل المثال، لو كان التطبيق يحتوي على خمس أيقونات، يتوجب على المطوّر تزويد التطبيق بما قد يصل إلى خمس نسخ مُختلفة من كل أيقونة، كل نسخة منها تختلف من حيث الحجم والدقة وذلك لضمان ظهورها بالدقة الصحيحة على جميع الهواتف والحواسب اللوحية. هذا يعني أن ملف الـ APK الواحد سيحتوي على 25 صورة للأيقونات، لكن ما سيظهر للمُستخدم منها فعلًا هو خمس فقط، وهي الخمس المُناسبة لدقة وقياس شاشته. ولو كان التطبيق يدعم لغاتٍ متعددة سيحتاج المطوّر أيضًا إلى توفير الملفات الخاصة بالعبارات الخاصة بالتطبيق بجميع اللغات.

لهذا تعمل Android App Bundle بطريقة مختلفة، حيث سيقوم المطورون الآن برفع الشيفرة المُجمَّعة compiled code والملفات المصدرية (كالصور وملفات اللغات مثلًا) إلى متجر جوجل بلاي، وسيقوم المتجر لدى قيام المُستخدم بتحميل التطبيق باختيار الملفات المصدرية المُناسبة لجهاز المُستخدم ثم توليد ملف APK يحتوي فقط على ما يُناسب الجهاز، وذلك بدل قيام المطورين بتوليد ملف APK (الذي يحتوي على كل شيء!) على حاسبهم الشخصي ثم رفعه إلى متجر جوجل بلاي.

ولإثبات أهميتها فقد أوضحت جوجل أن الأداة المتوفرة من خلال منصة التطوير Android Studio 3.2 قادرة على تقليل أحجام التطبيقات بنسبة تصل إلى 50 في المئة، حيث تم اختبارها على بعض تطبيقات جوجل الأصلية بالإضافة إلى تطبيقات الشركاء مثل تطبيق شبكة LinkedIn التابعة لمايكروسوفت، حيث انخفض حجم التطبيق بنسبة 23 في المئة، وقل حجم تطبيق تويتر بنسبة 35 في المئة.

في الصورة التالية تعرض جوجل مثالًا للطريقة الحالية (القديمة) على اليسار، والطريقة الديناميكية الجديدة لتنزيل ملفات APK.

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

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

المصدر

The post جوجل تُطلق أداة App Bundle لتقليص حجم التطبيقات بشكلٍ كبير appeared first on أردرويد.

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

لم يتبقَّ الكثير على بدء مؤتمر Google I/O 2018، الذي ينتظره بفارغ الصبر ويُتابعه باهتمام شديد كل من مطوّري البرمجيات أو هواة التقنية على حدٍ سواء.

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

تُعتبر الجلسة الافتتاحية التي تمتد لساعتين من الزمن الحدث الأهم خلال المؤتمر. لم تضع جوجل بعد رابط البث المباشر للجلسة لكنها ستقوم بنقل الجلسة عبر موقع المؤتمر. وسنقوم نحن بتحديث هذه الصفحة لإضافة رابط اليوتيوب المُباشر فور توفره. المهم أن تكون مستعدًا للمُتابعة يوم الثلاثاء 8 أيار/مايو في الأوقات التالية:

• 5 مساءً بتوقيت غرينتش
• 5 مساءً بتوقيت الدار البيضاء
• 6 مساءً بتوقيت وسط أوروبا
• 7 مساءً بتوقيت الرياض
• 7 مساءً بتوقيت اسطنبول

بالتأكيد، سنقدم تغطية كاملة لأبرز أحداث المؤتمر عبر صفحات موقعنا.

ما أبرز ما تنتظره من جوجل في مؤتمرها؟ دعنا نعرف ضمن التعليقات.

The post كيف تُتابع مؤتمر Google I/O 2018 appeared first on أردرويد.

هذا هو الجزء الخامس من سلسلة (التعامل بفاعلية مع الكود الموروث) والتي نقوم فيها بتلخيص الكتاب الذي يحمل نفس الاسم. يمكنك الاطلاع على كامل مقالات السلسلة من هنا.

مازلنا نتحدث في فضاء تغيير الكود والدلالات التي يجب أن ننتبه إليها كمبرمجين عند القيام بهذه التغييرات. و اتفقنا مسبقا أن أحد أهم الأدوات المساعدة في تغيير الكود هي الـ Tests إذا أنها تعطينا إجابةً feedback فيما إذا كنا نقوم بتغيير الكود بالطريقة الصحيحة أم لا. و اتفقنا أيضا أنه من الحكمة عند البدء بتغيير الكود أن نقوم بتغطيته بمجموعة من الـ Tests والتي تعمل كشبكة أمان.

في هذه المقالة سأقدم من كتاب Working effectively with legacy code  مثال عملي على ما سبق و نخطوا خطوة بعيدا عن الكلام النظري لنرى كيف نستطيع تغطية الكود بالـ tests.

لنأخذ المثال التالي: مجموعة من الـ classes يبدو أنها جزء من نظام يعمل على تخزين الفواتير في قاعدة بيانات ويقوم بتحديثها.
في هذا المثال, نريد إجراء تعديل على كل من الـ methods التالية  :

• ()getResponseText ضمن InvoiceUpdateResponder
• ()getValue  ضمن Invoice class

ولكي نتمكن من إجراء التعديل باحترافيه، يجب أن نحيط هذه ال classes ب tests لضمان أن الكود مازال يعمل كما هو متوقع بعد إجراء التعديل.

ولكتابة test لـ class معين نحن بحاجة لإنشاء instance من هذا الJ class.

• في حالة ال Invoice class يبدو الأمر غير معقد إذ إن الـ constructor لا يتطلب أي parameters.
• ولكن في حالة ال InvoiceUpdateResponder نرى أن الـ constructor يتطلب DBConnection اي اتصال بقاعدة البيانات، ويتطلب أيضا InvoiceUpdateServlet مما يصعب علينا مهمة كتابة ال test. لماذا ؟

إذا تتبعنا محتوى المقالة السابقة التي تتحدث عن ال unit test نلاحظ أنه لا يمكن لـ test أن يتخاطب مع قاعدة بيانات حقيقية. هل من المعقول ان ننشئ قاعدة بيانات مخصصة لل test؟ سيكلفنا هذا الكثير من العمل و نحن الآن لسنا بصدد الاهتمام بقاعدة البيانات، كل ما نريد عمله هو كتابة tests حول getResponseText و getValue.

الـ constructor بحاجة أيضا لـ InvoiceUpdateServlet, و بالترجمة يكون هذا ال Invoice UpdateServlet عبارة عن بريمج صغير لتحديث الفاتورة. وهذا أيضا خارج اهتمامنا.

إذاً طريقة تصميم ال InvoiceUpdateResponder class لا تساعد المبرمج على كتابة tests، إذ أنه مصمم بحيث أنه يعتمد بشكل مباشر و صريح على classes أُخرى.

وللأسف يبدو أننا بحاجة لكسر هذه الاعتماديات dependencies لنتمكن من كتابة الـ tests. مثل أن نعدل على الكود بحيث نمرر المعلومات التي يحتاج أن يعرفها الـ InvoiceUpdateResponder عن هذا الـ InvoiceUpdateServlet عوضا عن تمريره كـ object كامل أو غيرها من الحلول.

وهنا نقع في دائرة مفرغة, لتغيير الكود نحن بحاجة كتابة  tests و لكتابة ال tests نحن بحاجة لتغيير الكود. هذه هي معضلة الكود الموروث.

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

إذا.. ما الحل الآن؟ كيف نقوم بالخروج من هذه الدائرة؟ كيف نقوم بكتابة الـ tests بدون تغيير الكود؟

في مثالنا الحالي يمكننا كما قلنا سابقا، أن نقوم بتمرير المعلومات التي يحتاج أن يعرفها الـ InvoiceUpdateResponder عن الـ InvoiceUpdateServlet عوضا عن تمريره كـ object كامل. مثلا ربما يحتاج الـ InvoiceUpdateResponder فقط أن يعرف قائمة ال ID الخاصة بالفواتير التي نريد أن نجري عليها عمليات ما ولاشيء غير ذلك من المعلومات التي يمررها الـ Responder.

ومن الممكن أيضا أن نستعيض عن تمرير الـ DBConnection بـ interface ونقوم باستخدام هذه الـ interface في الـ tests عوضا عن استخدام الـ DBConnection، كما في الشكل التالي:

هذه التقنية في مفهوم كسر الاعتمادية dependency breaking تسمى بالـ primitive parameter و Extract interface. سنخوض لاحقا بتفاصيل أكثر عن هذه التقنيات.

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

لننظر للموضوع من وجهة نظر أخرى: مالفائدة من هذه الـ interface المضافة هنا؟ لاشيء إلا أنها تسهل كتابة الـ tests. لربما يرى بعض المبرمجين أن هذه التغيرات الجديدة على بنية الكود غريبة أحياناً .نعم، عملية الـ dependency breaking هي خطوة حرجة يتصاحب معها تغيرات في بنية الـ classes والـ code structure ولكن للضرورة أحكام.

الحال هنا تماما مثل اجراء عملية جراحية والندوب التي تتركها العملية غير جميلة و غير محببة ولكنها حتما ساعدتنا على الشفاء من المرض.

الخلاصة

عند كل عملية تعديل على كود، سواء نحن من قام بكتابته أو كان كودًا قديمًا، نحن بحاجة لإحاطة منطقة التغيير بقدر من الـ tests تضمن أن تعطينا feedback ودلالات. ولكن لكتابة هذه الـ tests نفسها نحن أحيانا بحاجة للتعديل على الكود. يوجد تقنيات عديدة للقيام بهذا التغيير الاخير بهدف كتابة الـ tests ويرافقه حذر و صرامة من قبل المبرمج للقيام بأقل التغييرات الممكنة.

المصدر: التعامل بفعالية مع الكود الموروث 5 – Test Covering

هذا هو الجزء الثالث من سلسلة (التعامل بفاعلية مع الكود الموروث) والتي نقوم فيها بتلخيص الكتاب الذي يحمل نفس الاسم. يمكنك الاطلاع على كامل مقالات السلسلة من هنا.

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

تحدثنا أيضا في المقالة السابقة تحديدًا عن الفرق بين ال regression tests و ال unit tests. أما مقالتنا اليوم ستتناول بشكل أعمق ال Unit tests.

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

Unit tests

الفكرة وراء الـ unit tests أنها تقوم بفحص الكود ليس ككل إنما كأجزاء components محددة معزولة عن بعضها، أي تكون هذه الـ components في حالة عزل isolation. نعني بهذه ال components – من وجه نظر ال unit tests – أنها عبارة عن أصغر جزء من أجزاء برنامج أو نظام ما.

أي أننا نحتاج لفهم سلوك البرنامج و الطريقة التي يعمل بها، وتقسيمها على أساس سلوكيات مستقلة عن بعضها البعض و صغيرة قدر الإمكان حتى نستطيع كتابة unit test لكل منها على حِدة.

بالنهاية فإن هذه الـ components هي عبارة عن كود. في الشيفرة غرضية التوجه Object oriented code تكون هذه الوحدات units عبارة عن classes. أما في الـشيفرة الإجرائية procedural code تكون عبارة عن الـ functions.

السؤال هنا: هي يمكننا فعلا اختبار function أو class بمعزل عن باقي الكود؟

في ال procedural systems، إختبار function بمعزل عن باقي الكود غالبا صعب. لأن طريقة تسلسل الكود تكون بأن يقوم function باستدعاء function اخر و هكذا حتى أبسط function في ال system.

أما في ال Object oriented systems فإن اختبار ال classes بمعزل عن باقي ال classes ضمن الكود يكون أسهل نوعا ما، لكن الحقيقة المرة أن ال classes لا تعيش بمعزل عن بعضها البعض. كم مرة قمت/ي بكتابة class لا يعتمد على أي class آخر؟

مفهوم ال isolation و أن يكون ال code في هذه ال components صغير قدر الإمكان هي أساسيات في مفهوم ال Unit testing.

نعم, ال tests التي تغطي أجزاء كبيرة من الكود هي مهمة ولكنها تحمل أيضا بعض السلبيات مثل:

1- Error localization:

يصعب تحديد مصدر الخطأ عندما يغطي ال test مساحة كبيرة من ال code. يجب فحص ال variables والعمليات التي تجري عليها على طول تنفيذ الكود و كل الاحتمالات الواردة حتى يتم تحديد مصدر الخطأ. إذًا، كل ما كان الكود الذي يغطيه ال test أكبر كلما تشعبت الاحتمالات و كبرت. نعم، سنقوم بنفس العملية في الـ unit tests لتحديد مصدر أي خطأ ولكن الجهد المبذول حتما أقل لأننا اتفقنا أن ال unit tests تغطي components صغيرة قدر الإمكان.

2- Execution Time

ال tests الكبيرة تحتاج لوقت أطول حتى تتم عملية الاختبار. وربما سيتفادى المبرمج إجراء هذه ال tests الكبيرة التي تستغرق وقتًا طويلًا بعد كل تعديل صغير في الكود تجنبًا لإهدار الوقت. ولكن في حالة ال unit tests، فإن الفحص سيقتصر على ال tests الصغيرة التي تغطي ال component الذي قمنا بالتعديل عليه فقط.

ال Unit test الجيد هو السريع في تنفيذه والذي يساعد في تحديد مصدر المشكلة.

خصائص يجب عدم توافرها في الـ Unit tests

بكل وضوح, ال Unit test يجب أن تحترم مايلي:

١-  يجب أن تكون سريعة في تنفيذها، و إلا لا يمكن إعتبارها unit tests.

٢-   لا يجب أن تتخاطب أو تتواصل مع قاعدة البيانات database.

٣-   لا يجب أن تجري أي عمليات على أي شبكة network.

٤- لا يجب أن تجري أي تخاطب مع ال file system.

٥- لا يمكن اعتبارها unit tests في حال كان عليك كمبرمج أن تجري تغيرات محددة على النظام  لجعلها تعمل، مثل تعديل configuration file.

ال test المخالفة للقواعد السابقة ليست سيئة بالطبع,، ولكن لا يمكن اعتبارها unit tests إذا أنها لا تساعد على تحقيق الهدف المرجو من كتابة هذا النوع من الاختبارات.

الخلاصة:

أي test جيد هو test مفيد. ولكن ال unit tests تحديدًا تساعدنا في حماية التفاصيل الصغيرة في البرنامج و التأكد من أنها تعمل كما هو متوقع.

ونتذكر دائما: الـ unit test الجيد يجب أن يكون سريعًا ويساعدنا في تحديد مصدر المشكلة bug بسهولة.

المصدر: التعامل بفعالية مع الكود الموروث 4 – Unit tests

هذا هو الجزء الثالث من سلسلة (التعامل بفاعلية مع الكود الموروث). يمكنك الاطلاع على الجزء الأول من هنا، والثاني من هنا.

نحاول في هذه السلسلة تلخيص كتاب “التعامل بفعالية مع الكود الموروث”. نحن الآن في الوحدة الثانية التي تتحدث عن  working with feedback بمعنى الإشارات والدلالات التي يجب أن ننتبه لها عندما نقوم بالتعديل على الكود لتساعدنا على فهم فيما إذا كنا نمشي في الطريق الصحيح أم لا.

تختلف أساليب التعديل على أي نظام برمجي بإختلاف المبرمج, بشكل عام هناك نوعين:  

• Edit and pray
• Cover and modify

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

Edit and pray

عند البدء بتغيير كود ما,  تبدأ بقراءته ومحاولة فهمه , ثم تبدأ بإجراء التغيير, وعند الانتهاء تختبر الميزات الجديدة التي قمت بإضافتها، تتأكد أن البرنامج مازال يعمل. تتوسع تقوم بتجريب أشياء أخرى ضمن البرنامج تتأكد أنه مازال يعمل كما هو متوقع منه. إذا كان هذا أُسلوبك كمبرمج, يجب أن تعلم أنك تعمل بإسلوب Edit and pray.

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

لا أعتقد أن أحدا من يختار لإجراء عمل جراحي معقد, طبيب جراح يعمل بسكين المطبخ، فقط لان هذا الجراح سيجري العملية بحذر شديد. تغيير الكود بطريقة إحترافية يشبه لحد ما إجراء عملية جراحية , يتطلب الأمر كلٌ من المهارات والأدوات الكافية.

العمل بحذر جيد ولكن غير كافي أبدا في حال غياب الأدوات و التقنيات الصحيحة

 

Cover and modify

أسلوب التعديل على الكود هنا مختلف تماما. الفكرة الأساسية هنا هي تغطية الكود شبكة أمان safety net قبل التعديل عليه.

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

في الحالة المثلى في حياة المبرمج، يكون ال code مغطى بعدد كافي من ال tests التي تساعد على التأكد من أن التغييرات الجديدة جيدة و تؤدي الهدف منها أم لا.

الهدف من وجود هذه ال Tests هو إعطاء feedback فيما إذا كانت التغييرات الجديدة تجعل نظامنا البرمجي يعمل كما هو متوقع أم أنها تعقد الكود و تجعله مليء بال Bugs.

Tests لكشف التغييرات في الكود

هناك أنواع عديدة من ال tests تختلف باختلاف الهدف من كتابتها:

Regression test

ال Regression tests يكتب حتى يتم التأكد من أن البرنامج يعمل بالطريقة المتوقعة .يعتبر هذا النوع من ال tests مثل وجود Software Vise. ال Vise هي نفس الأداة في الصورة التالية.

تبقي هذه ال Software vise الكود ثابت لا يتغير و تجعلنا نتأكد من أن التغييرات لم تؤثر في عمل البرنامج.

هذا النوع من ال tests فعال ولكنه غالبا ما يتم على مستوى واجهة المُستخدم user interface. كما أن نتائجه تكون عامة مثل أن “الكود لم يعد يعمل بالطريقة المتوقعة” دون تفاصيل دقيقة عن السبب الذي أدى إلى فشل ال test أو الجزء من الكود المسؤول عن هذا الفشل.

تخيل أن الكود الذي نريد تعديله كبير و معقد, في هذه الحالة نحن بحاجة لمعلومات أدق في حالة فشل ال test، ما يساعد في تقليل احتمالات أماكن الخطأ في الكود. في هذه الحالة يجب أن نستخدم نوع أخر من ال Testing هو ال Unit Tests.

Unit Tests

لنتخيل السيناريو التالي: لدينا كود نريد التعديل عليه. لحسن الحظ قام المبرمجون بكتابة unit tests له. نجري هذه الإختبارات و نرى أن جميعها تتم بنجاح. نبدأ بمحاولة فهم الكود عن طريق قراءته و قراءة ال tests. نشعر بالرغبة في تغيير الكود لجعله سهل القراءة readable. نقوم ببعض التعديلات، و نقوم بإجراء ال tests ونرى أن جميعها يتم بنجاح. إذًا نحن الآن متأكدون أنه رغم التغييرات الجديدة ما زال الكود يعمل بالطريقة المطلوبة. نكمل بإجراء ال test بعد كل تعديل، ونرى أحيانًا أن بعض هذه ال tests يفشل. في هذه الحالة لدينا feedback وهو أن التعديلات التي جرت في هذا الجزء من الكود الذي يغطيه هذا ال test هي المسؤولة عن الخطأ، أي أنها غيرت من الطريقة التصرف المتوقعة والمطلوبة من البرنامج. هنا تحديداً نرى أهمية ال unit tests و الفرق بينها و بين ال regression test.

ال Unit tests هي واحدة من أهم مكونات العمل مع الكود الموروث

الخلاصة

• ال tests بكل أنواعها مهمة لأنها تعطي feedback عن حالة الكود عند كل تعديل.
• وجود ال Regression test ضروري و مهم و لكن وجود unit tests صغيرة ومسؤولة عن أجزاء محددة من الكود أكثر أهمية بسبب وضوح ال feedback التي يعطينا إياها عن سبب المشكلة، ما يوفر علينا وقت لإصلاح المشاكل بأمان أكثر.

المصدر: التعامل بفعالية مع الكود الموروث 3-دلالات عند تغيير الكود

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

Changing Software تغيير الكود

في بداية تعلمنا للبرمجة، نبدأ بكتابة برامج قصيرة ينتهي العمل عليها بانتهاء الهدف من كتابتها، مثل تعلم الأساسيات أو تطبيق فكرة لإثبات أنها تعمل – proof of concept. ويمكننا القول بأن الوضع الطبيعي اليومي في حياة أي مبرمج أنه يقوم بالتعديل على الكود، أكثر من الاستمرار في كتابة كود جديد دون تغيير القديم.

هذه المقالة هي الثانية في سلسلة تلخيص كتاب التعامل بفعالية مع الكود الموروث . سنتحدث عن مصطلحات و أسباب تغيير الكود وما الدلالات التي يجلبها تغيير الكود.

أسباب تغيير الكود

يمكننا أن نلخصها بأربع نقاط :

1. إضافة ميزات جديدة للبرنامج – Adding features
2. إصلاح مشكلة –  Fixing bugs
3. تطوير تصميم الكود – Design improvement
4. تحسين في استخدام الموارد – Optimizing resources usage

Adding features – إضافة ميزة جديدة

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

Design improvement – تطوير تصميم الكود

من ميزات تطوير تصميم الكود :

• لا يجب أن تتغير الطريقة التي يعمل بها البرنامج
• والنتائج قبل تطوير تصميم الكود و بعده يجب أن تبقى كما هي.

و في حال التغير في عمل البرنامج يعتبر هذا التغير Bug. لذا يعتبر ال Design improvement حالة حرجة التي يحاول أكثر المبرمجون تجنبها لأنها غالبا ما تنتهي بقائمة من ال Bugs إذا كان تصميم الكود ضعيف. 

عملية تطوير تصميم الكود من دون تغيير الطريقة التي يعمل بها البرنامج تسمى بال Refactoring. إذ يكمننا جعل التصميم أسهل للتطوير في المستقبل .

ال refactoring ليس عملية تنظيف للكود، هو تغييرات في تصميم الكود – structure modifications- ولكن كيف نضمن أن الطريقة التي يعمل بها البرنامج  لن تتغير عندما ننتهي من عملية ال Refactoring؟

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

عملية ال Refactoring بدون كتابة Tests هو تصرف يجلب عواقب. وتذكر دائما تسلق الجبال بدون حبال نجاة وبدون حظ ربما يجلب نتائج خطيرة. الأمر ليس سهل بسهولة سرده في هذه المقالة، لكنه يحمي المبرمج من الوقوع في مشاكل لا مفر منها.

ال Refactoring  هي عملية تطوير تصميم الكود من دون تغيير ال behaviour. 

Optimizing – التحسينات على الكود

تشبه لحد ما عملية Refactoring مع اختلاف الهدف من العملية. إذ أن كلاهما يبقيان البرنامج يعمل بالطريقة نفسها قبل هذه الخطوة. ولكن :

• يتحسن تصميم الكود في الـ Refactoring
• ويتحسن استخدام الموارد في ال optimization كأن يستهلك البرنامج ذاكرة وبطارية أقل.

الصورة العامة

تغيير الكود يجب أن يكون الهدف منه أحد مما يلي : بنية الكود – structure , الطريقة التي يعمل بها الكود – functionality , أو الموارد – resources changes.

ما الهدف مما سبق ؟

الهدف من كل ما سبق هو معرفة أين يجب أن يتجه تركيزنا عند البدء بتغيير الكود. والأهم هو معرفة ما هو الخط الأحمر أي ما الذي يجب أن لا يتغير أبدا, وهذه ليست بالمهمة السهلة.

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

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

برأيي الشخصي, كتابة الكود ليس بالأمر الصعب. المهمة الأصعب و الأمتع هي تطوير البرمجيات واحترافها. وهذه  المصطلحات هي أدوات مساعدة.

المصدر: التعامل بفعالية مع الكود الموروث 2 – تغيير الكود

محاكي أندرويد يُقدم أخيرًا ميزة انتظرها مطوّرو أندرويد طويلًا.

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

لحسن حظ مطوّري أندرويد، أعلنت جوجل اليوم أن ميزة Quick Boot والتي تم طرحها بشكلٍ تجريبي مع Android Studio 3.0 قد أصبحت متوفرة الآن رسميًا ضمن المحاكي، حيث تتيح هذه الميزة تشغيل المُحاكي بأقل من 6 ثوانٍ.

وأوضحت جوجل أن تشغيل المحاكي للمرة الأولى سيستغرق وقتًا أطول، لكن بعد ذلك سيتم التشغيل السريع وسيجد المطوّر أن نظام التشغيل ضمن المحاكي ما زال مُحتفظًا بحالته الأخيرة، ما يُسهل عمل المطورين بشكلٍ كبير.

يُذكر أن الميزة تأتي بشكلٍ افتراضي مع الإصدار رقم 27.0.2 من المحاكي والتي سيطلب Android Studio تحديثها تلقائيًا لدى تشغيله.

المصدر: جوجل تُطلق ميزة Quick Boot لتشغيل محاكي أندرويد في 6 ثوانٍ

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

لمصطلح الكود الموروث legacy code أكثر من تعريف وردّة فعل واحدة من أي مبرمج بمجرد ذكر الكلمة أمامه:

يمكننا أن نُعرّفه على أنه الكود المكتوب من قبل مبرمج أو مجموعة مبرمجين، و فجأة  تنضم أنت إلى الفريق أو تكون الشخص الوحيد الذي تُرِكَ في الساحة ليفهمه ويصلحه ويطوره، وللأسف يكون الكود غير قابل للفهم أو الإصلاح.

كما يمكننا تعريفه على أنه الكود الذي قمنا نحن أنفسنا بكتابته و بدأ بالتحول لوحش خارج عن السيطرة غير قابل للإصلاح أو للتطوير، تماما ذاك الشعور عندما تبدأ بكتابة برنامج من نقطة الصفر, نكون حريصين على أن كل سطر يجب ان يكون صحيح منطقيا وبرمجيا، و في نقطة ما يصبح الكود مُعقّدًا أكثر وأكثر. و إصلاح المشاكل bugs يصبح أصعب و يأخذ وقتا أطول. والأسوأ هو أن تصل لنقطة تشعر معها أن هذا الكود لا فائدة من إصلاحه أبدا. يمكن أن يكون البرنامج يعمل بوجود أخطاء معروفة. يحدث أن نقوم بكتابة كود وبعد عدة أشهر نحتاج لإعادة قراءة جزء معين منه ويظهر السؤال : “هل حقا أنا من قام بكتابة هذا الكود ؟؟” .  كل ما سبق هو تعريف لمعنى الكود الموروث.

أي بإختصار:

 مصطلح ال legacy code يشير إلى الكود الصعب التغيير، صعب الفهم.

ولو تمكنا من العودة بالزمن للوراء، هل يمكننا أن نجيب على السؤال: ما الخطأ الذي أدى بالكود لهذا الجدار المسدود؟ مالذي حصل؟  لماذا تفسد هذه البرمجيات و لماذا من الصعب ان يبقى الكود نظيفًا مع الزمن؟ ماذا أفعل في حال أنني انضممت لفريق يعمل على كود موروث وواجهتنا صعوبات في تغييره؟ ماذا لوكان الكود رديئًا أو ما يُعرف اصطلاحًا باسم spaghetti code؟ ماهو أصلا تعريف الكود الرديء ؟

في سلسلة العمل مع الكود الموروث سأقوم بتلخيص ما قرأت في كتاب Working effectively with legacy code للرائع Michael C. Feathers .

هدفي من هذه السلسلة أن نتعرف معًا على زاوية جديدة في عالم البرمجة،  وتقديم مفاهيم جديدة لم ندرسها في الجامعات و المعاهد، بل هي خلاصة تجارب كبار المبرمجين على فترات طويلة.

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

ال Tests هم أصدقاؤك الحقيقيون

كما أشرنا مسبقا إلى أن مصطلح ال legacy code يدل على الكود الصعب التغيير وصعب الفهم. يقول الكاتب أنه وحسب خبرته في مساعدة الكثير من الفرق على تجاوز مشاكل متعلقة بال legacy code، إن التعريف الصحيح بالنسبة له هو أن ال legacy code هو الكود بدون Tests.

كما يمكننا القول بأن الكود بدون Tests هو كود سيء، لا يهم مدى إتقان كتابة الكود، ولا يهم كم أحسنت استخدام مفاهيم البرمجة غرضية التوجّه Object-oriented.

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

مهمتنا كمبرمجين أن نقوم بتصميم برمجيات يمكنها ان تتأقلم مع أي تغيير بسهولة و بسرعة نسبية قدر المستطاع. وحتى يكون من السهل التعديل على الكود يجب حتما أن يتم دعمه دائما و أبدا بال tests.

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

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

الخلاصة :

كتابة كود نظيف شئ جيد ولكن ليس كاف. ال Tests هم أصدقاؤك الحقيقيون.

المصدر: التعامل بفاعلية مع الكود الموروث [برمجة]