يقول مؤلف المادة ، التي ننشر ترجمتها اليوم ، أن معظم المبرمجين يعملون في فرق. ومع ذلك ، في مرحلة ما من المهنة ، قد يحتاج المطور إلى العمل بمفرده. تم تصميم النطاق الرئيسي لمناهج تنظيم العمل على منتجات البرمجيات خصيصًا للاستخدام في فرق العمل. يتم التعبير عن هذه النهج في القواعد التي تعتمدها المنظمات. تعمل مثل هذه القواعد على تبسيط العمل ، ومساعدة المبرمجين على القيام بعملهم بسرعة وكفاءة. شيء مشابه سيكون مفيدًا جدًا لهؤلاء المبرمجين الذين يعملون بمفردهم.
ماذا عن الشخص الذي يعمل بمفرده؟ ما الذي يجب التركيز عليه ، والسعي لبناء سير عمل واضح وفعال؟ ما المبادئ والقواعد الواجب اتباعها؟ نقترح البحث عن إجابات لهذه الأسئلة معًا.
حول المبرمجين الوحيدين
هنا ، أتحدث عن "المبرمجين الوحيدين" ، أعني كل أولئك الذين يعملون في بيئة غير رسمية وغير منظمة. يمكن أن يكون هذا إما مبرمجًا واحدًا أو مجموعة صغيرة من الأشخاص الذين يشاركون ، مثلاً ، في أوقات فراغهم ، في نوع من المشروع. فيما يلي بعض الأمثلة:
- تطوير مشروع مفتوح المصدر ، مثل حزمة أو نوع من المكتبة.
- مشروع شخص ما ، والذي يمكن أن يكون إما تجاريًا أو مجانًا.
- لحسابهم الخاص.
يتم توحيد كل هذه الأمثلة من خلال حقيقة أن عمل المبرمجين المشاركين في شيء مشابه لا يتم تنظيمه عادةً بواسطة مجموعة معينة من القواعد ، مثل تلك الموجودة عادةً في الشركات.
لماذا يجب أن يهتم مبرمج واحد بالقواعد؟
تعتبر القواعد ، عند تطبيقها على العمل المستقل للمبرمجين في بعض المشاريع ، مهمة لعدة أسباب. النظر فيها.
▍ القواعد الشخصية والعمل الجماعي المحتمل
يمكن للمبرمج الذي ينظم عمله المستقل تنظيمًا جيدًا الانضمام إلى فريق معين. في هذه الحالة ، هناك احتمالات جيدة في أن يصبح عضوًا ذا قيمة في مثل هذا الفريق. وهي نتحدث عن ما يلي:
- إذا انضم إلى فريق يتبع نفس القواعد التي يتبعها ، فلن يضطر إلى إضاعة الوقت في محاولة الخوض في القضايا التنظيمية. هو ، حرفيًا من اليوم الأول ، سيكون جاهزًا للعمل المثمر.
- إذا أصبح جزءًا من فريق ، القواعد المعتمدة والتي تختلف عن ما اعتاد عليه ، فلن يستغرق الأمر الكثير من الوقت لتعلم هذه القواعد الجديدة. بعد كل شيء ، فهو معتاد على تنظيم أعماله بطريقة عقلانية ، ويسترشد ببعض الأفكار العامة ، والتي ، بالتأكيد ، تشبه تلك التي تكمن وراء قواعد الفريق. نتيجة لذلك ، يمكنه الوصول بسرعة إلى مستوى عالٍ من إنتاجية العمل.
- إذا انضم إلى فريق لا توجد فيه قواعد على الإطلاق ، وبناءً عليه ، وفقًا للفريق ، يمكن أن يقدم لها رؤيته لتنظيم عمل المبرمجين ، مما قد يحسن عمل هذا الفريق. إذا رفض أعضاء فريق ضعيف التنظيم تغيير شيء ما ، فهذه مناسبة للتفكير في ترك مثل هذا الفريق.
نتيجة لذلك ، فإن المبرمج الوحيد الذي ينظم عمله بطريقة عقلانية هو الفائز.
▍ القواعد والمستوى المهني للمبرمج
تطوير البرمجيات ليست مجرد عملية كتابة التعليمات البرمجية. هناك العديد من التفاصيل المسؤولة عن تحويل الفكرة إلى مشروع مكتمل ، ثم الاحتفاظ بها في حالة صالحة للعمل. إن إدخال تقنيات تطوير البرمجيات المتقدمة في سير العمل الشخصي سيساعد مبرمجًا واحدًا على اتباع الهدف الذي يتم إنشاء المشروع من أجله وتجنب المواقف التي يبدو أن كل شيء فيها مربكًا إلى درجة أنه من غير الواضح أين يمكن المضي قدمًا.
إذا كنت مثلي تحب البرنامج ، فسوف تغري دائمًا أن تبدأ مشروعًا جديدًا وعلى الفور ، دون أن تنظر إلى الوراء ، تندفع إلى هاوية كود الكتابة. لكن التجربة تخبرني أنه إذا كان لدي خطة عمل رفيعة المستوى ، فمن دون الإضرار بالمرونة التي تختلف بها التنمية الفردية ، فهي تساعد على تجنب الكثير من متاعب النطاقات المختلفة.
تحدث عن أفضل الممارسات لتطوير البرمجيات.
اتبع القواعد التي تصف سير عملك.
"سير العمل" عبارة عن سلسلة من الخطوات التي تحتاج إلى القيام بها أثناء عملية تحويل الفكرة إلى منتج نهائي. فيما يلي بعض الأسئلة التي يجب الإجابة عليها من خلال القواعد التي تحكم عملية العمل على منتج برنامج:
- عندما تقرر إجراء تغيير في المنتج - ما هو ترتيب تنفيذه؟
- كيف يتم نقل الإصدارات الجديدة من المنتج إلى المستخدمين؟
- كيف يتم تتبع تغييرات المنتج؟
- كيف يتم مراقبة رسائل الخطأ والمشاكل التي يواجهها المستخدمون؟
- ما هي عملية تخطيط ميزات المنتج الجديد؟
لماذا تنظيم كل هذا ، ودفعه إلى نوع من الإطار ، إذا قد يبدو أن العمل في المشاريع سوف أسرع بكثير دون بعض سير العمل المحدد؟ أليس من السهل تخيل "سير العمل" بأكمله في هذا النموذج: "فقط اكتب الكود وأرسله إلى الفرع الرئيسي"؟ في الواقع ، مع تزايد تعقيد المشروع ، اتضح أن وجود قواعد واضحة يبسط تعريف ما يجب القيام به في العمل في هذا المشروع ، وبالتالي ، دون مزيد من التفكير ، يسمح لك بالتركيز على هذه الأمور. عند العمل في فريق ، يتحول سير العمل إلى شيء يشبه حزام ناقل يعمل على تحسين كفاءة كل عضو في الفريق.
الآن دعنا نتحدث عن كيفية تنظيم عملية العمل على منتج البرنامج.
ers استخدام بتتبع المهام
ستجد هنا آليات الأنظمة الأساسية التي تضع فيها الشفرة مفيدة - GitHub و Gitlab و BitBucket وغيرها. تساعد المهام في تتبع رسائل الخطأ وطلبات إضافة وظائف جديدة إلى المنتج وتنظيم معلومات حول التغييرات المهمة للمشروع. تجدر الإشارة إلى أنه عند إدخال عنوان ووصف المهمة ، فإنه يفرض عليك صياغة الأفكار بوضوح ووصف المشكلة بوضوح والطرق الممكنة لحلها. يمكن تطوير فكرة استخدام المهام من خلال تقديم أداة لإدارة المهام مثل Trello أو GitHub Projects في سير عملك.
التحديrequests استخدم طلبات السحب
يفضل العديد من المطورين إرسال التغييرات ، باستخدام طلبات الدفع ، مباشرةً إلى الفرع الرئيسي لمشروعهم ، والذي يُسمى master. ومع ذلك ، فإن النهج لإجراء تغييرات على رمز المشروع باستخدام طلبات السحب له بعض المزايا المهمة. أولاً ، تسهل هذه الاستعلامات تحليل التغييرات المتعلقة بإدخال ميزة جديدة أو إصلاح الخلل في المشروع ، وكيف ستؤثر عليه بعد الدمج مع قاعدة الشفرة الرئيسية. بالإضافة إلى ذلك ، إذا كانت طلبات السحب مرتبطة بمهام من تعقب المهام ، فإن استخدامها يسهل فهم كيفية تطوير المشروع ، مما يلغي الحاجة إلى معرفة ذلك عند قراءة الكود.
سحب تفاصيل الطلبreviews إجراء مراجعات رمز مخصص
قد تبدو التوصية بمراجعة الكود الأصلي غريبة ، ولكن على الرغم من ذلك ، يجب على المطورين تحليل الكود الخاص بهم كما لو كان شخص آخر كتبه. ينصح بعض المبرمجين بإجراء طلب سحب ، وتشتيت انتباههم لفترة من الوقت ، ثم التحقق من ذلك قبل تضمينه في الكود. يتيح لك إجراء عمليات التحقق من الشفرة التي تتم خارج البيئة المعتادة للمبرمج في شكل IDE الخاص به إلقاء نظرة جديدة على التعليمات البرمجية. يساعد ذلك في العثور على الأخطاء والكشف في التعليمات البرمجية عن شيء يمكن تجاهله في الظروف العادية. مراجعة الكود ، بالإضافة إلى ذلك ، أجبر المطور على طرح أسئلة مختلفة على نفسه: "لماذا تم تنفيذ هذه الفرصة بهذه الطريقة؟ ما الذي يمكن فعله خطأ هنا؟ هل هناك طريقة أكثر فعالية لحل هذه المشكلة؟ "
▍ احتفظ بتاريخ ذي مغزى للمشروع في المستودع
حاول القيام بالتعهدات كما لو كنت تعمل في فريق. وهي - تجنب الإلتزامات الكبيرة جدًا ، حاول التأكد من أن رسائل الإلتزامات تصف معناها بوضوح وبوضوح. تمامًا كما في حالة مراجعة التعليمات البرمجية ، فإن كتابة رسائل التزام عالية الجودة تجبر المطور على التفكير مليا في تصرفاته ، ويسأل نفسه أسئلة مثل ما يلي: "ما الذي أحاول تحقيقه باستخدام هذا الالتزام؟ كيف أحاول تحقيق ذلك؟ "
قد تكون هناك مواقف يمكنك فيها السماح لنفسك بالانحراف عن القواعد. على سبيل المثال ، قد تقرر أنه ، من أجل عدم إبطاء العمل بسبب تفاهات ، يمكنك ، عند إجراء تغييرات طفيفة على الكود (مثل إصلاح الأخطاء المطبعية) ، يمكنك ، دون حركات غير ضرورية ، إرسال طلب دفع مباشرة إلى الفرع الرئيسي.
بغض النظر عن القواعد التي تكمن وراء سير عملك ، فإن الشيء الأكثر أهمية هو أن كل ما تفعله يتم عن قصد ، وليس عن طريق الصدفة. المشاريع الناجحة لا تنشأ من تلقاء نفسها: فهي تنشأ مع الحب والرعاية. تتضمن الإجراءات المنفذة عمدا فترات معينة من تحليل الموقف ، وتحليل الحالات المعقدة والتفكير في كيفية ، على سبيل المثال ، بمساعدة الأدوات التي يمكنك التعامل معها.
بناء مكونات قابلة لإعادة الاستخدام والوحدات
تنفيذ مبادئ
DRY ،
SOLID والأولى . قم ببناء برامج من مكونات ذرية صغيرة مغلفة مناسبة لإعادة الاستخدام. حافظ على تحديث هذه المكونات وتجميعها في مجموعات باستخدام الأنظمة الأساسية المناسبة مثل
Bit . كل هذا سيساعدك على زيادة سرعة وجودة العمل.
اكتب الوثائق
الوثائق ... بالنسبة للكثيرين ، هذه نقطة حساسة. يعرف الكثير من الناس أن مشاريع البرامج تحتاج إلى وثائق. أولئك الذين يكتبون وثائق جيدة بالفعل أقل بكثير ، وحتى أقل من الذين يحبون القيام بذلك. بعد الانتهاء من المرحلة الرائعة التالية من كتابة التعليمات البرمجية ، تصبح الحاجة إلى توثيقها في كثير من الأحيان مهمة تريد فقط نسيانها. كيف ، في شكل نصوص واضحة ، للتعبير عن جميع تعقيدات رمز البرنامج؟
وبالمناسبة ، من المناسب طرح سؤال حول سبب كل هذا. الحقيقة هي أن الناس يميلون إلى ارتكاب الأخطاء. يمكننا أن ننسى شيئا. لدينا أيام سيئة. أو ، بالعمل على مشروع معين ، يمكننا ببساطة المضي قدمًا في العمل على شيء آخر. تسمح لك الوثائق بالتعرف على الكود ، والذي ، خلاف ذلك ، سيتم ربطه بشخص معين. يساعد توثيق الكود أيضًا المطورين على رؤية الكود بعبارات أكثر عمومية مما هو متاح عند كتابته ، وفهم أهداف المشروعات بشكل أكثر وضوحًا.
الأفكار التالية سوف تساعدك على كتابة وثائق جيدة.
- نفهم أن الوثائق الخاصة بك ليست مثل كتاب. يجب ألا تشكل الوثائق مثالاً على الفن الأدبي العالي. لا أحد سيقيمها من حيث جدارة فنية. لا تحاول شرح كل شيء فيه. نسعى جاهدين ليكون واضحا ومفهوما. في بعض الأحيان فقط بضع جمل كافية لوصف شيء ما.
- كتابة الوثائق قبل كتابة الكود. توثيق واجهات الوحدات النمطية الخاصة بك ، ووصف ترتيب عملها من وجهة نظر مراقب خارجي. ستلعب هذه الوثائق دور مواصفات المنتج وستساعدك في عملية التطوير.
- كتابة الوثائق بعد كتابة التعليمات البرمجية. هنا ، مرة أخرى ، يجدر التمسك بموقف "مراقب خارجي". ما هو المهم في جزء الكود الموصوف؟ ما تحتاج إلى معرفته حول استخدامه (أو المساهمة في تطويره؟). المواصفات المحددة بواسطة الوثائق التي تم إنشاؤها قبل كتابة التعليمات البرمجية أثناء التطوير قابلة للتغيير. لذلك ، من المهم التحقق من هذه الوثائق للتأكد من مطابقتها للوضع الحقيقي بعد اكتمال العمل.
- كتابة الوثائق في عملية كتابة التعليمات البرمجية. ينطبق هذا النهج على الوثائق بشكل أساسي على شيء مثل التعليقات المضافة إلى الكود أثناء التطوير. هناك العديد من المواد حول هذا الموضوع ، لذلك لن أخوض في التفاصيل هنا.
- الوثائق و "الوحدات". جميع المبادئ المذكورة أعلاه تنطبق على وحدات. هنا يتم استخدام مفهوم "الوحدة النمطية" بمعنى واسع إلى حد ما. يمكن أن تكون هذه وظيفة أو فئة أو فرصة جديدة أو تغييرًا في سلوك البرنامج أو في الواقع وحدة نمطية معينة أو المشروع بأكمله. إذا بدا أن توثيق مثل هذه "الوحدات النمطية" يمثل تحديًا كبيرًا ، فحاول تقسيمها إلى أجزاء أصغر. أو إذا كان من الأسهل بالنسبة لك التفكير في فئات عامة ، ففكر في كتابة الوثائق للمجموعات الأكبر من المشروع.
التواصل مع العملاء وأولئك الذين يشاركون في تطوير المنتج معك
هنا ، ما نسميه "التواصل" ينطبق بشكل أساسي على الحالات التي يتم فيها تطوير مشروع من قبل فريق صغير أو بناءً على الطلب.
لماذا هذا مطلوب؟ الحقيقة هي أن شفافية العمل تؤدي إلى زيادة في مسؤولية فنانيها. عندما تعلم أنه يجب عليك إخبار شخص ما (عضو في فريق أو ممثل عميل) بشيء ما ، فهذا يساعدك على أن تكون أكثر حذراً فيما تفعله. لهذا السبب تمارس العديد من الشركات عقد اجتماعات قصيرة يقوم خلالها الموظفون بالإبلاغ عن أعمالهم.
بالإضافة إلى ذلك ، غالبًا ما يواجه أحد أعضاء الفريق مشكلة صعبة بالنسبة له ، والتي يمكن حلها بسهولة بمجرد مناقشتها مع عميل أو مع عضو آخر في الفريق. لقد فقدت عدد الأصوات بالفعل ، وأذكر الحالات عندما أسقطت يدي حقًا ، وأحاول أن أفهم لماذا لا يعمل ما كتبته. والسبب في ذلك هو قيام عضو آخر في الفريق بإجراء تغييرات على المشروع الذي تداخل مع الكود الخاص بي. من أجل فهم هذا الأمر ، كان يكفي عرض المشكلة على المناقشة العامة.
فيما يلي بعض الإرشادات للتواصل مع العملاء ومع أعضاء فريق المبرمجين.
- إذا واجهت مشكلة غير متوقعة - فأخبر أعضاء الفريق أو ممثل العميل عنها.
- أخبر العميل بانتظام عن تقدم المشروع. في الوقت نفسه ، حاول أن لا يتم ربط هذه المعلومات فقط بالمسائل الفنية.
- يخطر الفريق بتغييرات الخطة.
- حاول تنظيم بيئة ملائمة للاتصال ، والتي تتيح ، على سبيل المثال ، لأي عضو في الفريق اكتشاف ما يقوم به شخص آخر بسرعة. يمكنك القيام بذلك عن طريق استخدام مجموعة متنوعة من الأدوات ، دعنا نقول - يمكن أن يكون WhatsApp أو البريد الإلكتروني أو Slack أو أي شيء آخر يناسب وضعك.
بشكل عام ، تجدر الإشارة إلى أنه يجب عليك محاولة ضمان تنظيم التفاعل بين جميع الأطراف المعنية بشكل مريح وبسيط ، بحيث ، إذا جاز التعبير ، تعمل "حلقة التعليق" دون تأخير. هذا يساعد على تنظيم بيئة عمل صحية ومنتجة.
تنظيم نظام المراقبة
المراقبة في مجال تطوير البرمجيات هي قضية مهمة للغاية. أجهزة الكمبيوتر عرضة للحوادث. أثناء نشر المشروع ، تحدث أخطاء. تؤدي إشراف المطورين إلى حقيقة أن البرامج التي يبدو أنها اجتازت جميع عمليات الفحص الممكنة ونجحت في تشغيلها مع استثناءات. لهذا السبب يحتاج المطور إلى الاهتمام بنظام مراقبة البرنامج. سيؤدي ذلك إلى تسهيل حل المشكلات التي قد تنشأ في مراحل مختلفة من دورة حياة المنتج. تُعد بيانات مراقبة البرنامج جزءًا من حلقة التغذية المرتدة المذكورة أعلاه. تعطي المراقبة للمبرمج صلة بالواقع ، مع البيئة التي تعمل فيها برامجه.
فيما يلي بعض الاقتراحات لمراقبة كيفية تصرف البرامج:
- حفظ السجلات ونتائج تحليل الشفرة التلقائي. لا تتردد في استخدام console.log () أينما كنت في حاجة إليه. من الأفضل إيداع الكثير من المعلومات بدلاً من القليل. ومع ذلك ، حاول العثور على "أرضية متوسطة" حتى لا تحتوي سجلات البرامج الخاصة بك على تفاصيل غير ضرورية عن عملهم. هذا سيجعل من السهل العثور على معلومات مهمة في السجلات.
- تعرف على المكان الذي تذهب إليه سجلات تطبيقاتك ، وتكوين الآليات التي تجعل العمل معها مناسبًا. يمكن أن يكون دور "الآليات" المذكورة أعلاه أي شيء - من تسجيل الدخول إلى الخادم باستخدام SSH وعرض آخر الأحداث المسجلة في السجل ، إلى شيء مثل استخدام مكدس ELK. الشيء الأكثر أهمية هو معرفة مكان إنشاء سجلات التطبيق بواسطة console.log () أو أي وسيلة أخرى.
- لا تتجاهل الاستثناءات. على الرغم من أن أي مطور يجب أن يسعى جاهداً لضمان استقرار تطبيقه ، أي أنه يستطيع استعادة القدرة على العمل في حالة حدوث خطأ ، "التخلص" من الاستثناءات غير المتوقعة ، ببساطة "إغلاقها" في كتلة catch catch سيكون خطأ. سيكون من الأفضل تسجيل معلومات حول استثناءات غير متوقعة. على سبيل المثال ، إذا كنت تستخدم نوعًا من واجهات برمجة التطبيقات لتحميل بعض البيانات التي أنشأها المستخدم (مثل التغريدات ، فيجب أن تكون مستعدًا للتعامل مع الخطأ 404. ولكن هذه الأخطاء التي لا تقوم بمعالجتها ، تحتاج إلى تسجيل الدخول. كنت في موقف ، من دون تسجيل معلومات حول أخطاء غير متوقعة ، لم أكن أعرف ببساطة أنني قد استنفدت حد المكالمات لنظام واحد. أدى هذا إلى حقيقة أن الوصول إلى واجهة برمجة التطبيقات المقابلة لبرنامجي قد تم إغلاقه.
- تحقق من السجلات. يمكن تنظيم التحقق من السجلات الناتجة عن نتائج التطبيقات إما يدويًا أو باستخدام بعض الوسائل لتحليلها التلقائي. بمجرد أن أعمل ، لا أهتم بشكل خاص بالتحكم في السجل ، على إصلاح مشكلة صغيرة في البرنامج واستمرت في متابعة عملي بهدوء. كما اتضح فيما بعد ، كان تصحيحي غير فعال. منذ ذلك الحين ، كنت حريصًا على التحقق من سجلات التطبيق بعد نشرها ، مما يسمح لي بالتحقق من صحة عملهم.
يمكن أن تأخذ مراقبة نشاط التطبيق وتتبع مؤشرات الأداء أشكالًا متعددة. في أبسط أشكاله ، يمكن أن يؤدي ذلك إلى إخراج بيانات حول البرنامج باستخدام الأمر console.log () ، وحفظ هذه المعلومات في ملفات نصية ، وتحليل هذه الملفات يدويًا. يمكن أن تكون المراقبة أيضًا نظامًا متطورًا إلى حد ما ، والذي يتضمن أدوات متخصصة مثل Sentry و Bugsnag و Elastic APM. الشيء الرئيسي هو اختيار ما يناسبك واستخدامه باستمرار.
مراقبة المشروع ، واستخلاص النتائج من نتائج الملاحظات ، وتحسينه
أنت تنظر ، ولكن لا تلاحظ ، وهذا فرق كبير.
آرثر كونان دويل ، "فضيحة بوهيميا"إن ما سيتم مناقشته في هذا القسم يمكن اعتباره توصية مستقلة ونهجًا لاستخدام التوصيات الأخرى المقدمة هنا. الحقيقة هي أنه لا توجد صيغة عالمية لتنظيم العمل على منتج البرنامج. يشارك أشخاص مختلفون في تطوير البرامج بطرق مختلفة ، ويستخدمون طرق مراقبة مختلفة ، ورمز المستند بشكل مختلف ، وهكذا. لهذا السبب ، بغض النظر عن قواعد العمل الخاصة بالبرامج التي اخترتها ، من المهم أن نسعى دائمًا لضمان مراقبة المشروع ، واستخلاص النتائج من نتائج المراقبة ، وأن كل هذا يؤدي في النهاية إلى تحسين البرنامج.
تتضمن مراقبة البرنامج تحليلًا نقديًا لسلوكه ، أو ، على سبيل المثال ، مؤشرات أداءه. بمراقبة البرنامج ، فأنت تقوم ببناء صلة بين ما تراه وما تعرفه عن النظام ، وتوصل في النهاية إلى استنتاجات منطقية حول ما يحدث. عادة ما يُحرم الشخص الذي يعمل بمفرده من القدرة على تحليل البرامج المستخدمة في المنظمات (مثل اختبارات A / B أو دراسات الجمهور المستهدف). نتيجة لذلك ، عليه أن يجمع أدلة حول حياة برنامجه من مصادر "غير رسمية" - مثل تعليقات المستخدمين وتقارير المشكلات في متتبعات المهام وسجلات التطبيق.
بعد الانتهاء من المرحلة التالية من مراقبة البرنامج ، حان الوقت لاستخلاص النتائج وتحسينها بناءً على هذه النتائج. ثم يلي ذلك المرحلة التالية من الملاحظات ، تليها التكرار التالي لتحليل البيانات التي تم جمعها وتحسين البرنامج. لكن العمل على برنامج ما هو أكثر من "مراقبة - تحليل - تحسين".
النظر في مثال مشروط. , , . , UTC-. , .
, UTC. , , , 5:30 pm, 5:30 pm UTC. , . , . ? , . .
, , , — , . , , , . «5 » «2 ». , , , .
. , . , , , , , . , , .
ملخص
, , — , . ( ), , , . , , ( , ), , . , , . , , , , .
أعزائي القراء! , «-»?
