توضح هذه المقالة أهم عشر وصايا يحتاج مطورو Java إلى معرفتها. شاركها مع الجميع للرجوع إليها، التفاصيل كالتالي:
باعتباري أحد مطوري Java، يعد تحسين جودة التعليمات البرمجية الخاصة بك وإمكانية صيانتها موضوعًا ثابتًا، وقد رأيت هذه المقالة عبر الإنترنت واستخدمتها لتشجيع نفسي.
هناك العديد من المعايير وأفضل الممارسات لمطوري Java. تسرد هذه المقالة القواعد العشرة الأساسية التي يجب على كل مطور اتباعها؛ إذا كانت هناك قواعد يمكن اتباعها ولكن لا يمكن اتباعها، فستؤدي إلى نهاية مأساوية للغاية.
1. أضف تعليقات إلى التعليمات البرمجية الخاصة بك
الجميع يعرف هذا ولكن بطريقة ما ينسون متابعته. احسب عدد المرات التي "نسيت" فيها إضافة تعليق توضيحي؟ هذا صحيح: التعليقات لا تقدم أي مساهمة كبيرة في وظائف البرنامج. ومع ذلك، تحتاج إلى العودة إلى الكود الذي كتبته قبل أسبوعين مرارًا وتكرارًا، ربما مدى الحياة، ويجب ألا تتذكر سبب تصرف الكود بهذه الطريقة. إذا كانت هذه الرموز ملكك، فأنت محظوظ. لأنه قد يعيد الذكريات. لكن لسوء الحظ، في كثير من الأحيان، يكون الرمز ملكًا لشخص آخر، وهناك احتمال كبير أنه ترك الشركة.
2. لا تعقد الأمور
لقد فعلت ذلك من قبل، وأنا متأكد من أن الجميع قد فعل ذلك. غالبًا ما يتوصل المطورون إلى حل لمشكلة بسيطة. لقد قدمنا EJBs لتطبيق يضم 5 مستخدمين فقط. نحن نستخدم إطار عمل لتطبيق لا يحتاج إليه. لقد أضفنا ملفات خصائص وحلول موجهة للكائنات وخيوط إلى التطبيق، لكنه لم يكن بحاجة إليها على الإطلاق. لماذا نفعل هذا؟ البعض منا يفعل ذلك لأننا لا نعرف كيفية القيام بذلك بشكل أفضل، ولكن البعض منا يفعل ذلك لتعلم معرفة جديدة وجعل التطبيق أكثر إثارة للاهتمام لأنفسنا.
3. تذكر - "الأقل هو الأكثر" ليس جيدًا دائمًا
تعد كفاءة التعليمات البرمجية أمرًا رائعًا، ولكن في كثير من الحالات، لا تؤدي كتابة عدد أقل من أسطر التعليمات البرمجية إلى جعل هذه التعليمات البرمجية أكثر كفاءة. من فضلك دعني أعرض لك مثالا بسيطا.
if(newStatusCode.equals("SD") && (sellOffDate == null || todayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null && todayDate.compareTo(lastUsedDate)>0)) || (newStatusCode.equals) ("OBS") && (OBSDate == null || todayDate.compareTo(OBSDate)<0))){ newStatusCode = "NYP";} أريد أن أسأل: هل من السهل معرفة ما يريد فعله شرط if في الكود أعلاه؟ الآن، لنفترض أن من كتب هذا الكود فشل في اتباع القاعدة رقم واحد - أضف تعليقات إلى الكود الخاص بك.
ألن يكون الأمر أسهل إذا قسمنا هذا الشرط إلى عبارات if منفصلة؟ الآن، خذ بعين الاعتبار الكود المصحح التالي:
if(newStatusCode.equals("SD") && (sellOffDate == null || todayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null && todayDate.compareTo(lastUsedDate)>0))){ newStatusCode = "NYP ";}else if(newStatusCode.equals("OBS") && (OBSDate == null || todayDate.compareTo(OBSDate)<0)){ newStatusCode = "NYP";}ألن يكون من الأفضل قراءته؟ نعم كررنا شرط البيان. نعم، لدينا "IF" إضافي وزوجين إضافيين من الأقواس. لكن الكود أفضل للقراءة والفهم.
4. من فضلك لا يوجد رمز ثابت
غالبًا ما ينسى المطورون أو يتجاهلون هذه القاعدة عن عمد لأننا كالعادة في عجلة من أمرنا. إذا اتبعنا هذه القاعدة، فقد نتأخر عن الموعد المحدد. قد لا نكون قادرين على إنهاء حالتنا الحالية. ولكن كم من الوقت سيكلفنا كتابة سطر إضافي من التعليمات البرمجية يحدد الثوابت الثابتة؟
هنا مثال.
public class A { public static Final String S_CONSTANT_ABC = "ABC"; public boolean MethodA(String sParam1){ if(A.S_CONSTANT_ABC.equalsIgnoreCase(sParam1)){ return true }}الآن، في كل مرة نحتاج فيها إلى مقارنة السلسلة "ABC" ببعض المتغيرات، نحتاج فقط إلى الإشارة إلى S_CONSTANT_ABC بدلاً من تذكر الرمز الفعلي. كما أن لديها ميزة تسهيل تعديل الثابت في مكان واحد، بدلاً من البحث عنه في جميع التعليمات البرمجية الخاصة بك.
5. لا تخترع الأطر الخاصة بك
تم إطلاق الآلاف من أطر العمل، ومعظمها مفتوحة المصدر. العديد من هذه الأطر هي حلول ممتازة وتستخدم في آلاف التطبيقات. أنت بحاجة إلى مواكبة هذه الأطر الجديدة، على الأقل بشكل سطحي. من بين هذه الأطر الممتازة والمستخدمة على نطاق واسع، أحد أفضل الأمثلة وأكثرها مباشرة هو Struts. من بين جميع الأطر التي يمكنك تخيلها، يعد إطار عمل الويب مفتوح المصدر هذا مرشحًا مثاليًا للتطبيقات المستندة إلى الويب. ولكن عليك أن تتذكر القاعدة الثانية - لا تعقد الأمور. إذا قمت بتطوير تطبيق يتكون من ثلاث صفحات فقط - من فضلك، لا تستخدم Struts لمثل هذا التطبيق، فلا يوجد شيء "للتحكم" في الطلبات.
6. لا تطبع أسطرًا وتضيف سلاسل
أعلم أنه لأغراض تصحيح الأخطاء، يحب المطورون إضافة System.out.println في كل مكان نراه مناسبًا، ونقول لأنفسنا أننا سنحذف هذا الرمز لاحقًا. لكننا غالبًا ما ننسى حذف هذه السطور من التعليمات البرمجية، أو ببساطة لا نريد حذفها. نحن نستخدم System.out.println للاختبار، بعد أن نكمل الاختبار، لماذا لا يزال بإمكاننا الوصول إليها؟ قد نقوم بحذف سطر من التعليمات البرمجية التي نحتاجها بالفعل ببساطة لأنك قللت من تقدير الضرر الذي سببه System.out.println، خذ بعين الاعتبار الكود التالي:
public class BadCode { public static void accountWithPrint(){ double someValue = 0D; for (int i = 0; i < 10000; i++) { System.out.println(someValue = someValue + i } } public static void accountWithOutPrint(); ){ double someValue = 0D for (int i = 0; i < 10000; i++) { someValue = someValue + i } } public static void main(String [] n) { BadCode.calculationWithPrint();في الجدول أدناه، يمكنك أن ترى أن طريقة الحسابWithOutPrint() استغرقت 0.001204 ثانية للتشغيل. بالمقارنة، استغرق تشغيل طريقة الحسابWithPrint() 10.52 ثانية مذهلة.
(إذا كنت لا تعرف كيفية الحصول على جدول مثل هذا، راجع مقالتي "ملف تعريف Java باستخدام WSAD" ملف تعريف Java باستخدام WSAD)
أفضل طريقة لتجنب إهدار وحدة المعالجة المركزية هي تقديم طريقة مجمعة، مثل ما يلي
public class BadCode { public static Final int DEBUG_MODE = 1; public static Final int PRODUCTION_MODE = 2; public static void accountWithPrint(int logMode){ double someValue = 0D; someValue + i; myPrintMethod(logMode, someValue); myPrintMethod(int logMode, double value) { if (logMode > BadCode.DEBUG_MODE) { return } System.out.println(value); }}في الشكل أدناه، سترى أن الطريقة التي تستخدم StringBuffer تستغرق 0.01 ثانية فقط للتنفيذ، بينما تستغرق الطريقة التي تستخدم إضافة السلسلة 0.08 ثانية للتشغيل. الاختيار واضح.
7. اتبع واجهة المستخدم الرسومية
بغض النظر عن مدى سخافة هذا الأمر، سأقوله مرارًا وتكرارًا: واجهة المستخدم الرسومية مهمة لعملاء الأعمال مثل الوظيفة والأداء. تعد واجهة المستخدم الرسومية جزءًا أساسيًا من النظام الناجح. (ومع ذلك)، غالبًا ما تميل مجلات تكنولوجيا المعلومات إلى تجاهل أهمية واجهات المستخدم الرسومية. توفر العديد من المؤسسات المال من خلال عدم توظيف المصممين الذين لديهم خبرة واسعة في تصميم واجهات المستخدم الرسومية "سهلة الاستخدام". يتعين على مطوري Java الاعتماد على معرفتهم الخاصة بـ HTML، لكن معرفتهم في هذا المجال محدودة للغاية. لقد رأيت الكثير من التطبيقات مثل هذه: فهي "صديقة للكمبيوتر"، وليست "سهلة الاستخدام". نادرًا ما أرى مطورين بارعين في تطوير البرامج وتطوير واجهة المستخدم الرسومية. إذا كنت المطور سيئ الحظ المكلف بتطوير واجهة مستخدم، فيجب عليك اتباع هذه المبادئ الثلاثة:
1. لا تعيد اختراع العجلة. ابحث عن الأنظمة الحالية ذات متطلبات واجهة المستخدم المماثلة.
2. قم أولاً بإنشاء نموذج أولي. هذه خطوة مهمة للغاية. يحب العملاء رؤية ما سيحصلون عليه. إنه أمر رائع أيضًا بالنسبة لك لأنك تحصل على تعليقاتهم قبل أن تبذل قصارى جهدك وتنشئ واجهة مستخدم ستثير غضبهم.
3. ارتداء قبعة المستخدم. بمعنى آخر، قم بفحص متطلبات التطبيق من وجهة نظر المستخدم. على سبيل المثال، ما إذا كان يجب ترقيم صفحات صفحة التلخيص. كمطور برامج، فإنك تميل إلى تجاهل ترقيم الصفحات في النظام لأنه يترك لك تعقيدًا أقل في التطوير. ومع ذلك، هذا ليس الحل الأفضل من وجهة نظر المستخدم لأن البيانات الملخصة ستحتوي على مئات أو آلاف الصفوف.
8. قم دائمًا بإعداد المتطلبات الموثقة
يجب توثيق كل متطلبات العمل. قد يكون هذا صحيحا في بعض القصص الخيالية، لكنه غير ممكن في العالم الحقيقي. بغض النظر عن مدى ضيق الوقت اللازم لتطويرك، أو ما إذا كان تاريخ التسليم قريبًا، يجب أن تعلم دائمًا أن كل متطلبات العمل موثقة.
9. اختبار الوحدة، اختبار الوحدة، اختبار الوحدة
لن أخوض في تفاصيل ما هي أفضل طريقة لاختبار وحدة التعليمات البرمجية الخاصة بك. ما سأقوله هو أنه يجب إجراء اختبار الوحدة. هذه هي القاعدة الأساسية للبرمجة. وهذا هو الأهم من بين جميع القوانين المذكورة أعلاه والتي لا يمكن تجاهلها. من الأفضل أن يكون لديك زملاء يمكنهم إنشاء واختبار اختبارات الوحدة للتعليمات البرمجية الخاصة بك. ولكن إذا لم يفعل أحد ذلك نيابةً عنك، فعليك أن تفعل ذلك بنفسك. عند إنشاء خطة اختبار الوحدة الخاصة بك، اتبع القواعد التالية:
1. اكتب اختبارات الوحدة قبل كتابة التعليمات البرمجية.
2. كتابة التعليقات في اختبارات الوحدة.
3. اختبر جميع الطرق العامة التي تؤدي وظائف "مثيرة للاهتمام" ("مثيرة للاهتمام" تعني الأساليب غير المستقرة أو المحصلة، إلا إذا كانت تؤدي أساليب التعيين والحصول على طريقة خاصة).
10. تذكر - الجودة وليس الكمية.
لا تتأخر كثيرًا في المكتب (عندما لا تضطر إلى ذلك). أدرك أنه في بعض الأحيان، يمكن أن تمنعنا مشكلات المنتج والمواعيد النهائية الضيقة والأحداث غير المتوقعة من مغادرة العمل في الوقت المحدد. ومع ذلك، في الظروف العادية، لن يقدر المدير ويكافئ الموظفين الذين يتركون العمل بعد فوات الأوان، بل يقدرهم بسبب جودة المنتجات التي ينتجونها. إذا اتبعت القواعد التي ذكرتها أعلاه، فستجد أن الكود الخاص بك به عدد أقل من الأخطاء وأكثر قابلية للصيانة. وهذا هو الجزء الأكثر أهمية في عملك.
تلخيص
في هذه المقالة، أقدم عشر قواعد مهمة لمطوري Java. من المهم ليس فقط معرفة هذه القواعد، ولكن أيضًا اتباعها أثناء عملية الترميز. نأمل أن تساعدنا هذه القواعد في أن نصبح مبرمجين ومحترفين أفضل.
آمل أن تكون هذه المقالة مفيدة للجميع في برمجة جافا.