المهام النموذجية لمطور Java في المشروع

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

1. تصميم حلول جديدة

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

2. كتابة وظائف جديدة

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

3. كتابة الاختبارات

المراجع، أي الشخص الذي يتحقق من التعليمات البرمجية الخاصة بك، يحب الوظيفة التي نفذتها، ولكن لديه سؤال لك: أين توجد الاختبارات المرتبطة؟ لذا فهي ترسل المهمة إليك للمراجعة. تعد الاختبارات جزءًا أساسيًا من أي تطبيق Java. ومن خلال إجراء الاختبارات، يمكنك على الفور تحديد الأماكن التي لا يعمل فيها التطبيق بشكل صحيح. على سبيل المثال، يقوم المطور بإجراء بعض التغييرات في جزء واحد من النظام، مما يؤدي إلى تغييرات في السلوك في جزء آخر، لكنه لم يلاحظ ذلك أثناء البرمجة. ومن خلال إجراء الاختبارات، سيكون قادرًا على معرفة أن بعض الاختبارات قد فشلت، مما يعني أنها لم تنتج النتائج المتوقعة. يخبره هذا أن هناك شيئًا ما مكسورًا في مكان آخر في النظام. بمعرفة ذلك، لن يقوم بإجراء التغييرات العاجلة على الخادم، وسيواصل بدلاً من ذلك العمل على تصحيح التعليمات البرمجية الخاصة به. نعم، عدد قليل جدًا من المطورين يحبون كتابة الاختبارات، ولكن لا يمكن إنكار الفوائد التي تجلبها لتطوير البرمجيات. غالبًا ما يشير العملاء أنفسهم إلى مستوى تغطية الاختبار الذي يريدون الحفاظ عليه (على سبيل المثال، 80%). وهذا يعني أنك بحاجة إلى معرفة أنواع الاختبارات المختلفة والقدرة على كتابتها. يقوم مطورو Java بشكل أساسي بكتابة اختبارات الوحدة واختبارات التكامل، بينما يتم التعامل مع الاختبارات الأكثر شمولاً (الشاملة) بواسطة خبراء ضمان الجودة وأتمتة الاختبار.

4. البحث عن الأخطاء وإصلاحها

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

5. مراجعة الكود

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

6. تحليل الكود

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

7. كود إعادة البناء

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

8. كتابة التوثيق

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

9. لقاءات متنوعة

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

10. إجراء/اجتياز المقابلات

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