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

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

1. تطوير حلول جديدة

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

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

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

3. كتابة الاختبارات الوظيفية

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

4. العثور على الخلل وإصلاحه

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

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

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

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

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

7. إعادة هيكلة التعليمات البرمجية

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

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

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

9. المشاركة في المسيرات المختلفة

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

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

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