بوابة وتطوير فريق (لالدمى)

شارك في تأليف المقال: ريكاردو ميلوس

مقدمة

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

بوابة

بالتأكيد أنت على دراية بهذا الموقف:



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

وهنا تدرك أنك لم تقم بحفظ خيار العمل ، وكسر الزر Z على لوحة المفاتيح ، لذلك لا يمكنك حتى البريد المزعج ctrl + z. في نوبة من الغضب ، يمكنك اختراق الشاشة مع يمينك المضخة. في المساء ، تبكي ، ملفوفة في بطانية ، والتفكير في محنة المبرمجين.

موقف محزن ... ولمنع حدوث ذلك ، تحتاج إلى حفظ إصدارات من التعليمات البرمجية الخاصة بك.

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

وهنا يمكننا رسم تشابه مع الألعاب. تقريبا جميع مشاريع AAA لديها نظام حفظ. كمثال جيد ، لعبة Papers Please.



حول نفسه ، تعمل جميع أنظمة التحكم في الإصدار.

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

تصنيف SLE:

1. المحلية
2. مركزي
3. وزعت

لقد اكتشفنا بالفعل العملة الصعبة المحلية (هذه هي نفس أكوام الملفات نفسها)

العملة الصعبة المركزية

• الخادم المركزي
  جميع الملفات تحت سيطرة الإصدار
• عدد من العملاء
  تلقي نسخ من الملفات

أمثلة:

• CVS
• التخريب
• قوة

العملة الصعبة الموزعة

1. عملاء نسخ كامل مستودع بالكامل
2. الخادم المركزي مسؤول عن توفير النسخة الرئيسية
3. قد تكون المزامنة
   
   • مع الخادم
   • مع أي عميل
   
   

أمثلة:

• بوابة
• زئبقي
• بازار

لماذا أحتاج SLE

1. تخزين جميع التغييرات المشروع
2. القدرة على التبديل "إلى أي مرحلة من مراحل المشروع"
3. القدرة على إجراء تطوير فريق في وقت واحد
4. القدرة على حل المشاكل مثل التالية

بوابة

بوابة - نظام التحكم في الإصدار الموزع
أرسلت بواسطة لينوس تورفالدس
2005 - الإصدار الأول

التثبيت:
Linux: sudo apt install git
ويندوز / ماك: الارتباط

استخدام المطورين:

• جنو / لينكس
• أندرويد
• النبيذ
• جوجل
• الكروم
• مسج
• فب
• ميدياويكي
• كيو تي

المفاهيم الأساسية

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

تكوين GIT

إعداد اسم المستخدم

git config --global user.name "Your Name" git config --global user.email you@abc.net 

يتم حفظ الإعدادات في ملف gitconfig مخفي (في الدليل الرئيسي للمستخدم)

 [user] name = John Doe email = jdoe@example.com 

إنشاء مستودع

 mkdir first_git_repo cd first_git_repo git init 

حالات ملف المشروع

1. ثابت
   الملف موجود بالفعل في المستودع
2. تعديل
   الملف مختلف في المحتوى عن حالته الملتزمة
3. أعدت
   ملف معدل سيصبح ملتزمًا بعد إنشاء مراجعة جديدة (سينقسم هذا الملف إلى هذه المراجعة)

العمل مع رمز

• مستودع التهيئة
  
  

   git init 

• أو التحول إلى مراجعة محددة
  

   git checkout _ 

1. تغيير في رمز المشروع: إنشاء / حذف / تحرير الملفات
   في أي بيئة تطوير متكاملة
2. عرض الحالة
   git status
3. إضافة ملفات معدلة إلى الفهرس
   (الانتقال إلى حالة المرحلتين)
   git add ___
4. إنشاء مراجعة (من مراحل إلى ريبو)
   git commit -m ""

تلخيص

العمل مع العملة الصعبة

ما لتخزين؟

[+] جميع ملفات التعليمات البرمجية المصدر
[+] جميع الموارد اللازمة لتجميع
[+] إعدادات تجميع المشروع
[-] إعدادات المشروع في IDE
[-] ملفات مجمعة من المصدر
[-] الملفات القابلة للتنفيذ

حذف من الفهرس

git rm _

قد يحتوي الالتزام على تغييرات في ملفات متعددة

متى نرتكب؟

• عندما أكملت مهمة صغيرة
• إذا كانت المشكلة كبيرة - قسّمها إلى أجزاء فرعية منطقية
• يجب أن يكون رمز التشغيل!

عرض التاريخ

 git log git log --graph 

رقم المراجعة = SHA-1 Change Hash

التبديل إلى التدقيق

 git checkout sha1_hash git checkout _8__sha1 

الفروع

الفرع هو سلسلة من الالتزامات التي يتم فيها تطوير الوظيفة بشكل متوازٍ

الفرع الرئيسي - سيد

الفروع في GIT

عرض جميع الفروع الموجودة في المستودع

git branch

إنشاء فرع

git branch

التبديل إلى الفرع

git checkout
يجب ألا تكون هناك تغييرات غير محفوظة في هذا الوقت.

إنشاء فرع والتبديل إليها

git checkout -b

دمج الفروع

دمج الفروع - عملية دمج التغييرات (commits) من فرع إلى آخر:

b1 - الفرع الذي نضيف إليه التغييرات
b2 - الفرع الذي نضيف منه التغييرات

 git checkout b1 git merge b2 

عرض التاريخ

نافذة المرافق:

• gitg
• gitk
• جيتكس
• gitKraken

حذف الفروع

حذف الفرع

git branch –d _

حذف فرع

git branch –D _

أو بدلاً من ذلك ، احذف الفرع دون انتظار انتقال الالتزامات لإتقانها

التغيير غير المحفوظة العازلة

أو "ماذا تفعل إذا كنت بحاجة إلى التبديل إلى فرع آخر ، والالتزام في وقت مبكر؟"

اكتب التغييرات على المخزن المؤقت المؤقت

git stash

استخراج هذه التغييرات من المخزن المؤقت

git stash pop

روابط مفيدة:

git-scm.com/book/en/v2
githowto.com/ru
en.wikipedia.org/wiki/version_system

تطوير الفريق

لذا ، إذا وصلت إلى هذا الخط ، فهذا يعني أن لديك على الأقل صفقة صغيرة (آمل حقًا ذلك). ولكن ماذا عن تطوير الفريق؟ لنلقِ نظرة على هذه المشكلة بمزيد من التفصيل.

لغز مضحك قليلا:

معطى:

• N المطورين
• أماكن العمل
• الشروط المرجعية
• الانترنت

سؤال:

• كيفية تنفيذ مشروع دون جذب انتباه المنظمين؟

الجواب هو:

• فريق جيد التنسيق والعمل الجاد

حسنًا ، ما هو الفريق على الإطلاق؟ ما هي تحب؟

الفريق هو عدد صغير من الناس:

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

ملاحظة مهمة للغاية: في الفريق يجب أن تشعر بالراحة التامة ومحاولة التواصل مع الفريق بأكمله ، وإلا فقد يحدث كل شيء.

إذن ، أنت الآن تفهم ماهية الفريق. لكن السؤال التالي الذي يطرح نفسه في رأسك (نعم ، نعم ، يمكن لمؤلفي هذا المقال قراءة العقول): "ومن المسؤول عن ماذا في الفريق؟ هل لكل شخص مكانه الخاص؟ أم أن الجميع يفعلون ما يريدون؟ "

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

1. قائد الفريق:
   
   قائد الفريق هو التقاطع بين مدير المشروع والمطور المؤهل.
   
   هناك أدوار قيادية في المشاريع: مدير تنفيذي - فني - مهندس نظام. يؤدي Timlid جزئيًا كلا الدورين ، لكن تركيز مسؤولياته هو على الإدارة (التركيز على الجزء التقني هو الريادة التقنية).
   
   "قيادة الفريق رقم 1: رعاية فريقك. يجب أن يشعر الفريق بالراحة في بيئة العمل وأن يكون لديه دوافع جيدة. بالإضافة إلى ذلك ، يوفر قائد الفريق أيضًا النمو المهني والوظيفي لأطفاله ، ويقوم بانتظام بإجراء مناقشات حول الموضوع الذي يهتم فيه الناس بالتطور ، ويساعدهم في ذلك. "
   
   يشمل الدور الإداري لقائد الفريق مسؤوليات مثل الإدارة الفعلية والتوزيع وتفويض المهام وجميع أنواع التقييمات والجدولة ومراقبة حالة المشروع وكذلك الاجتماعات والتواصل مع العميل والإدارة وجميع أعضاء الفريق (المطورين والمختبرين والمديرين).
   
   تحت الدور الفني: المشاركة في كتابة الوثائق التقنية ، واختيار التقنيات للمشروع ، وتطوير الهندسة المعمارية ، والبحث والتطوير ، ومراجعة الكود ، وتوجيه الصغار ، وإجراء المقابلات الفنية ، والمشاركة المختصة لأعضاء الفريق الجدد في عملية العمل ، والمسؤولية عن الجزء الفني من المشروع.
   
   يتضمن يوم العمل في Timlid النموذجي ما يلي:
   
   
   • النظر في المهام الجديدة وتوزيعها
   • الوقوف مع فريق
   • المسيرات
   • البرمجة
   • القضايا المعمارية
   • مراجعة الكود
2. مدير المشروع:
   
   مدير المشروع هو أخصائي مهمته الرئيسية هي إدارة المشروع ككل: تصميم وتحديد أولويات المهام وجدولة المهام ، والرصد ، والاتصالات ، وحل المشكلات بسرعة.
   
   تتمثل مسؤولية PM ومسؤوليتها الأساسية في تحقيق فكرة العميل في الوقت المحدد باستخدام الموارد الحالية. في إطار هذه المهمة ، يحتاج مدير البرنامج إلى بناء خطة تطوير وتنظيم فريق وإعداد سير عمل للمشروع وتقديم التغذية الراجعة بين الفرق والعميل والقضاء على تدخل الفرق والتحكم في جودة المنتج وتسليمه في الوقت المحدد.
   
   يمكن تصنيف مهام PM على أنها تكتيكية واستراتيجية. التكتيكية - هذا هو الحل للمشاكل اليومية للمشروع ، وإزالة العقبات من الفريق. وتتمثل الأهداف الإستراتيجية في تنسيق الهدف العام للمشروع ، والطريق إليه ، وكذلك سرعة الحركة.
   
   "بيان الهدف الرئيسي لـ PM هو:" نحن بحاجة إلى هذا للعمل "، مما يعني أن الفريق سوف يوفر النتيجة في فترة زمنية معقولة بمستوى معقول من الجودة."
3. اختبار:
   
   المختبر هو متخصص يشارك في اختبار منتج برنامج من أجل تحديد الأخطاء في عمله وتصحيحه اللاحق.
   
   المهام الرئيسية للاختبار:
   
   
   • مراقبة جودة المنتجات المتقدمة.
   • تحديد وتحليل الأخطاء والمشكلات التي يواجهها المستخدمون عند العمل مع منتجات البرمجيات.
   • تطوير autotests وتشغيلها العادية.
   • اختبار تطوير البرنامج النصي.
   • توثيق العيوب الموجودة.
4. المطورين:
   
   
   • جونيور:
     جونيور هو مطور مبتدئ.
     
     بعد الانتهاء من التدريب ، يتحول الشخص إلى يونيو كامل. الشرط الرئيسي لذلك هو القدرة على أداء المهام الفنية بشكل مستقل. إذا تم بناء مشروع في الهندسة المعمارية ، فيجب أن يقوم على الفور بتنفيذ جزء آخر من منطق التطبيق النموذجي. على الرغم من أن جونيور قد يرتكب أخطاء من وقت لآخر ، لا تفهم الفروق الدقيقة أو ناقش خطط التنفيذ مع قائد الفريق أو راجع الكود النهائي معه.
     
     يجب أن تفهم أنه بالنسبة للمهام التي سيحلها Signor خلال عشر دقائق ، فقد يحتاج يونيو إلى ثلاث طرق كل ساعة ، وفي هذه العملية ، سيتعين إعادة كتابة التعليمات البرمجية بالكامل ، مع إنفاق الكثير من الطاقة الإضافية. من المهم ألا تخاف من ذلك وتشعر بالتوازن: متى تضغط ، تحاول حل المشكلة بنفسك ، وعندما تتوقف ، على العكس من ذلك ، عن ضرب جبهتك بالحائط ، تحرق وقت المشروع ، وتطلب المساعدة. يعد تبرير افتقارك إلى الأداء بعبارة "ما زلت في يونيو" فكرة سيئة.
   • الأوسط:
     
     الأوسط - مطور متوسط ​​المستوى.
     
     الشرط الرئيسي للمطور الأوسط هو القدرة على أداء المهام المسندة إليه بشكل مستقل. تشبه الى حد بعيد ما كتب في الفقرة السابقة ، أليس كذلك؟ ومع ذلك ، هناك تحذير هام - كلمة "التقنية" مفقودة هنا. هذا ، على مستوى جديد ، تحتاج إلى فهم متطلبات العمل وتكون قادرًا على ترجمتها إلى حلول تقنية.
     
     بهذه الطريقة:
     
     
     1. يفهم المطور الأوسط ما يقوم به التطبيق. يتيح لك ذلك فهم المهمة بشكل أفضل ، وبالتالي تقييمها بدقة أكبر وتنفيذها بشكل أفضل. إذا كانت المتطلبات لا تغطي سيناريو بالكامل ، فإن المطور الجيد سوف ينتبه إلى ذلك في مرحلة التخطيط. وليس عندما يبدأ التطبيق في التعطل في أي إجراء مستخدم غير قياسي.
     2. المطور المتوسط ​​على دراية بالقوالب والحلول القياسية عند إنشاء تطبيق في مجاله ، ويفهم سبب الحاجة إليه ، ويعرف كيفية تطبيقه. توحيد القرارات له أهمية كبيرة في التطوير الجماعي للرمز ، لأنه يسمح لشخص جديد بسرعة معرفة ما هو ما وتقليل عدد الأخطاء. إن فهم بنية التطبيق النموذجي يجعل مهمة بنائه من الصفر تافهة للغاية ، ويسمح لك بالتحدث عن مبادئ التنفيذ السليم وتمييز الكود الجيد عن السيئ.
     3. مطور الأوسط يفهم أن لا يعمل واحد. إنه يعرف كيفية التفاعل مع أعضاء الفريق الآخرين: يمكنه مناقشة لحظة صعبة مع مصمم أو توضيح المتطلبات غير المكتملة مع محلل أعمال أو تنسيق بعض الحلول التقنية الهامة مع مهندس المشروع (إن وجد) ، وبالطبع يمتلك الأدوات المناسبة لتطوير الفريق.
   • كبار:
     
     Senior هو مطور رفيع المستوى شهد الكثير من التعليمات البرمجية ، وحصل على مجموعة من المخاريط وتمكن من استخلاص الاستنتاجات الصحيحة من هذا. تتمثل مهمة Signor الرئيسية في اتخاذ القرارات التكنولوجية الصحيحة في المشروع. "الحقوق الصحيحة" هي تلك التي تزيد من الفوائد التجارية وتقلل من التكاليف. مؤشر جيد لا يفهم فقط ما يقوم الفريق بتطويره ، لكنه يفكر في المهام التي يجب أن يحلها التطبيق النهائي. عند تطوير موقع للمزاد ، يتساءل المؤيد دائمًا عن ذروة الحمل ويحاول التنبؤ بمحاولات الكتابة التنافسية إلى جداول قاعدة البيانات. إنه يفكر مقدمًا في اختناقات النظام ، وإمكانية توسيع نطاقه ، ويتذكر مواطن الضعف والمشاكل الناجمة عن الاستخدام غير الصحيح للأدوات.
     
     يقوم هذا المتخصص بعمل رائع - يحل المشكلات حتى قبل ظهورها. من الخارج ، يشبه هدية التبصر. ولكن إذا كان مشروعك يعيش من نيران إلى نيران ، وكان عليك دائمًا التخلص من أجزاء التعليمات البرمجية وإعادة كتابتها - فهذه هي الأعراض التي يحظى بها المشروع دون اهتمام كافٍ بالتوقيع.
5. المصمم:
   
   المصمم هو الشخص الذي يصمم. منطقيا ، أليس كذلك؟
   
   يبدأ عمل المصمم قبل وقت طويل من ظهور البيكسل الأول ، وينتهي بعد ذلك بكثير من الأخير.
   
   اعتاد معظم الناس على الاعتقاد بأن التصميم هو في الواقع مجموعة من الصور والألوان والخطوط التي يتم تمريرها إلى مصممي البرمجة والمبرمجين لصنع منتج. في بعض الأحيان ، يعمل هذا النهج ، ولكن في كثير من الأحيان يتحول إلى مشروع ، ومن ثم يصبح من المحرج إضافته إلى المجموعة.
   
   الحقيقة هي أن حل المشكلة لا يكفي لرسم صورة. في هذه العملية ، يمر المصمم الجيد بأربع خطوات. ها هم:
   
   • فهم المشكلة:
     
     يبدأ العمل بفهم المشكلة ، مثل المسرح مع شماعات: حتى تتخلى عن ملابسك الخارجية ، فلن تذهب أبعد من ذلك. إذا لم تتعمق في المشكلة ، فستحصل على منتج غير قابل للتطبيق.
   • ابحث عن حل:
     
     عندما تكون المشكلة واضحة ، فقد حان الوقت للبحث عن حل. من الناحية الثابتة ، هذه كلها أنواع من الرسومات الأولية والنماذج الأولية التي تساعد على بناء رؤية أولية للمنتج النهائي.
   • التصميم:
     
     هذا هو مجرد رسم الصور واختيار الخطوط. يبدأ العديد من المصممين من هنا وينهون العمل فورًا ، ويمكن رؤية نتائج عمل هؤلاء المصممين بأعداد كبيرة في Dribble أو Behans.
   • الموافقة:
     
     حتى إذا كان لديك حل رفيع وأنيق في رأسك وعلى الورق ، فإن هذا لا يعني أنه بالنسبة للعميل سيبدو كما هو. إذا حذفت هذه المرحلة وأعطت العميل أفضل الممارسات ، فسيتم إعادة بنائها وفقًا لفهمك. ما سيبقى في النهاية بعد تعديلات العميل سيكون مثل عملك.
   
   

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

الخاتمة

حسنًا ، إذا قرأت هذه النقطة - تهانينا ، فأنت رائع. لا ، حسنًا ، حقًا ، عقلك لم يغلي بعد بالكثير من المعلومات؟ لا آمل ذلك.

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

شكرا لاهتمامكم!

PS

تم إعداد المقال من قبل طلاب MSHP (مدرسة موسكو للمبرمجين) ، بناءً على محاضرات من دورة البرمجة الصناعية.