اسمي أندري بولياكوف ، وأنا رئيس مجموعة وثائق API و SDK في Yandex. أود اليوم أن أشاطركم تقريرًا قرأته أنا وزميلي ، كبيرة مطوري الوثائق جوليا بيفوفاروفا ، قبل بضعة أسابيع في معرض هايبرباتون السادس.
سفيتلانا كايوشينا ، رئيس قسم التوثيق والتعريب:
- نمت أحجام كود البرنامج في العالم في السنوات الأخيرة بشكل كبير ، واستمرت في النمو ، وهذا يؤثر على عمل الكتاب الفنيين ، الذين يواجهون المزيد والمزيد من المهام في تطوير وثائق البرنامج وتوثيق التعليمات البرمجية. لم نتمكن من تجاهل هذا الموضوع ، فقد خصصنا قسمًا كاملاً له. هذه هي ثلاثة تقارير ذات صلة بتوحيد تطوير البرمجيات. أدعو المتخصصين لدينا في توثيق واجهات البرامج والمكتبات إلى أندريه بولياكوف وجوليا بيفوفاروفا. أعطيهم الكلمة.
- مرحبا بالجميع! اليوم ، سأخبرك جوليا وأنا كيف حصلنا في Yandex على نظرة جديدة على توثيق API و SDK. سيتألف التقرير من أربعة أجزاء ، تقرير المراقبة ، سنناقش ، سنتحدث.
دعونا نتحدث عن توحيد API و SDK ، وكيف وصلنا إليها ، وماذا فعلنا هناك. سوف نشارك تجربة استخدام مولد عالمي ، واحد لجميع اللغات ، ونخبرك لماذا لم يكن مناسبًا لنا ، وما هي المزالق ، ولماذا تحولنا إلى توليد الوثائق بواسطة المولدات الأصلية.
في النهاية ، سنصف كيف تم بناء عملياتنا.
لنبدأ بالوحدة. يفكر الجميع في التوحيد عندما يكون هناك أكثر من شخصين في الفريق: الكل يكتب بشكل مختلف ، كل شخص لديه مقارباته الخاصة ، وهذا منطقي. من الأفضل مناقشة جميع القواعد على الشاطئ قبل البدء في كتابة الوثائق ، ولكن لا يمكن للجميع القيام بذلك.
لقد جمعنا مجموعة من الخبراء لتحليل وثائقنا. فعلنا هذا لتنظيم مناهجنا. يكتب الجميع بطرق مختلفة ، ودعونا نوافق على الكتابة بنفس الأسلوب. هذه هي النقطة الثانية ، التي سنحاول أن نجعلها موحدة للوثائق ، بحيث يكون لدى المستخدم تجربة مستخدم واحدة في جميع وثائق Yandex ، وهي التقنية.
تم تقسيم العمل إلى ثلاث مراحل. لقد قمنا بتجميع وصف للتقنيات التي نستخدمها في Yandex ، حاولنا تحديد تلك التي يمكننا توحيدها بطريقة أو بأخرى. كما تشكل الهيكل العام للوثائق والقوالب القياسية.
دعنا ننتقل إلى وصف التقنيات. بدأنا في دراسة التقنيات المستخدمة في Yandex. هناك الكثير منهم لدرجة أننا سئمنا من كتابتها في نوع ما من أجهزة الكمبيوتر المحمولة ، ونتيجة لذلك ، اخترنا فقط أبسطها التي يتم استخدامها في أغلب الأحيان ، والتي غالباً ما يواجهها الكتاب التقنيون ، وبدأنا في وصفها.
ما المقصود بوصف التكنولوجيا؟ لقد حددنا النقاط الرئيسية والجوهرية لكل تقنية. إذا تحدثنا عن لغات البرمجة ، فهذا وصف لوحدات مثل فئة ، خاصية ، واجهات ، وما إلى ذلك. إذا تحدثنا عن البروتوكولات ، فإننا نصف طرق HTTP ، نتحدث عن تنسيق رمز الخطأ ، رمز الاستجابة ، إلخ. مسرد يحتوي على الأشياء التالية: مصطلحات باللغة الروسية ، مصطلحات باللغة الإنجليزية ، فروق دقيقة في الاستخدام. على سبيل المثال ، نحن لا نتحدث عن أي طريقة SDK ، والتي تسمح لك بعمل شيء ما. يفعل شيئا ، إذا كان المبرمج يسحب بعض القلم ، فإنه يعطي بعض الجواب.
بالإضافة إلى الفروق الدقيقة ، احتوى الوصف أيضًا على الهياكل القياسية ، ومنعطفات الكلام القياسية ، التي نستخدمها في الوثائق بحيث يمكن للكاتب التقني أن يأخذ صياغة محددة ويستخدمها بشكل أكبر.
بالإضافة إلى ذلك ، غالبًا ما يكتب الكتّاب الفنيون أجزاء من التعليمات البرمجية والمقتطفات والعينات ، ولهذا وصفنا أيضًا دليل الأسلوب الخاص بنا لكل تقنية. لجأنا إلى أدلة المطور الموجودة في Yandex. لقد انتبهنا إلى رمز التصميم ووصف التعليقات والمسافة البادئة وكل ذلك. نفعل ذلك حتى عندما يأتي كاتب تقني مع قطعة من التعليمات البرمجية أو عينة مكتوبة للمبرمج ، فإن المبرمج ينظر في الجوهر ، وليس في كيفية تصميمه ، وهذا يقلل من الوقت. وعندما يتمكن كاتب تقني من الكتابة على أدلة نمط Yandex ، فهذا رائع جدًا ، ربما سيرغب في أن يصبح مبرمجًا لاحقًا. كان التقرير السابق حول امتحانات مختلفة. على سبيل المثال ، يمكنك الانتقال إلى المبرمجين.
قمنا أيضًا بتطوير بداية سريعة لكُتَّاب التكنولوجيا: كيفية إعداد بيئة تطوير عندما يصبح على دراية بالتكنولوجيا الجديدة. على سبيل المثال ، إذا كان الكاتب التقني SDK مكتوبًا بلغة C # ، فإنه يأتي ويهيئ بيئة التطوير ويقرأ الكتيبات ويتعرف على المصطلحات. تركنا أيضًا روابط للوثائق الرسمية و RFC ، إن وجدت. لقد أنشأنا نقطة دخول للكُتَّاب الفنيين ، ويبدو الأمر مثل هذا.
عندما يصل كاتب تقني ، يتعلم تقنية جديدة ويبدأ في توثيقها.
بعد وصف التقنيات ، تابعنا وصف هيكل واجهة برمجة تطبيقات HTTP.
لدينا العديد من واجهات برمجة تطبيقات HTTP المختلفة ، وجميعها موصوفة بشكل مختلف. دعونا نتفق ونفعل نفس الشيء!
لقد حددنا الأقسام الرئيسية التي ستكون في كل HTTP API:
"نظرة عامة" أو "مقدمة": لماذا تحتاج واجهة برمجة التطبيقات هذه ، وما الذي تسمح لك بالقيام به ، والمضيف الذي يجب الوصول إليه للحصول على نوع من الإجابة.
"بداية سريعة" عندما يمر الشخص ببعض الخطوات ويحصل على نتيجة ناجحة في النهاية لفهم كيفية عمل واجهة برمجة التطبيقات هذه.
"التوصيل / التفويض". تتطلب العديد من واجهات برمجة التطبيقات رمزًا مميزًا للتفويض أو مفتاحًا لواجهة برمجة التطبيقات. هذه نقطة مهمة ، لذلك قررنا أن هذا جزء إلزامي من جميع واجهات برمجة التطبيقات.
"قيود / حدود" عندما نتحدث عن قيود على عدد الطلبات أو على حجم نص الطلب ، إلخ.
"مرجع" ، مرجع. جزء كبير جدًا ، يحتوي على جميع مقابض HTTP التي يمكن للمستخدم سحبها والحصول على نوع من النتائج.
ونتيجة لذلك ، كان لدينا العديد من واجهات برمجة التطبيقات المختلفة ، وقد تم وصفها بشكل مختلف ، والآن نحاول كتابة كل شيء بنفس الطريقة. مثل هذا الربح.
بالتعمق في الدلائل ، أدركنا أن مقبض HTTP دائمًا ما يكون هو نفسه. أنت تسحبه ، أي تقدم طلبًا ، ويعيد الخادم إجابة - voila. دعونا نحاول توحيدها. كتبنا نموذجًا حاول تغطية جميع الحالات. يأخذ الكاتب الفني النموذج ، وإذا كان لديه طلب PUT ، فإنه يترك الأجزاء الضرورية في القالب. إذا كان لديه طلب GET ، فإنه يستخدم فقط الأجزاء المطلوبة لطلب GET. نموذج مشترك لجميع الطلبات التي يمكن إعادة استخدامها. الآن لا تحتاج إلى إنشاء هيكل مستند من البداية ، ولكن يمكنك فقط أخذ قالب جاهز.
يصف كل قلم الغرض منه ، وماذا يفعل. هناك قسم "تنسيق الطلب" ، والذي يحتوي على معلمات المسار ، معلمات الاستعلام ، كل ما يأتي في نص الطلب إذا تم إرساله. كما أبرزنا قسم "تنسيق الاستجابة": نكتبه إذا كان هناك نص استجابة. كقسم منفصل ، سلطنا الضوء على "رموز الاستجابة" ، لأن استجابة الخادم تأتي بشكل مستقل عن الجسم. وترك قسم "المثال". إذا قدمنا نوعًا ما من SDK باستخدام واجهة برمجة التطبيقات هذه ، فإننا نقول أن استخدام SDK مثل هذا ، اسحب مثل هذا المقبض ، اتصل بهذه الطريقة. عادة نترك نوعًا من مثال cURL حيث يقوم المستخدم ببساطة بإدراج رمزه المميز. وإذا كان لدينا مقعد اختبار ، فإنه يأخذ فقط الطلب وينفذه. ويحصل على نوع من النتيجة.
اتضح أنه كان هناك العديد من الأقلام ، تم وصفها بطرق مختلفة ، والآن نريد أن نجعلها كلها في شكل واحد.
بعد أن انتهينا من HTTP API ، انتقلنا إلى SDK للجوال.
هناك هيكل عام للوثيقة ، وهو مطابق تقريبًا:
- "مقدمة" ، حيث نقول أنه هنا ، يتم استخدام SDK لهذه الأغراض ، ودمجها لنفسك لهذه الأغراض ، وهي مناسبة لأنظمة التشغيل هذه ، ولدينا مثل هذه الإصدارات ، وما إلى ذلك.
- "اتصال". على عكس HTTP API ، نحن لا نتحدث فقط عن كيفية الحصول على المفتاح لاستخدام SDK ، إذا كنت بحاجة إليه ، نحن نتحدث عن كيفية دمج المكتبة في مشروعنا.
- "أمثلة على الاستخدام". أكبر قسم حجم. في أغلب الأحيان ، يرغب المطورون في القدوم إلى الوثائق وعدم قراءة الكثير من المعلومات ، فهم يريدون نسخ قطعة ولصقها لأنفسهم ، وسيعمل كل شيء من أجلهم. لذلك ، اعتبرنا هذا الجزء مهمًا جدًا وخصصناه للقسم الإلزامي.
- مرجع "الدليل" ، ولكن بخلاف مرجع HTTP API ، لا يمكننا توحيد كل شيء هنا ، حيث إننا ننشئ الدلائل بشكل أساسي وسنتحدث عن هذا لاحقًا في التقرير.
- "الإصدارات" ، أو سجل التغييرات ، سجل التغيير. عادةً ما يكون لحزمة SDK للجوّال دورة إصدار قصيرة ، ويتم إصدار إصدار جديد كل أسبوعين. وسيكون من الأفضل للمستخدم التحدث عما تغير ، هل يستحق الأمر التحديث أم لا.
في الوقت نفسه ، تحتوي واجهة برمجة التطبيقات على كل من الأقسام المطلوبة التي نراها والأقسام التي نوصي باستخدامها. إذا تم تحديث واجهة برمجة التطبيقات بشكل متكرر ، فإننا نقول ذلك ، ثم أدخل بنفسك سجل التغييرات أيضًا ، والذي تغير في واجهة برمجة التطبيقات. وغالبًا ما يتم تحديث واجهات برمجة التطبيقات الخاصة بنا ، ومن غير المجدي الإشارة إلى ذلك على أنه قسم مطلوب.
لذلك ، كان لدينا الكثير من حزم SDK التي تم وصفها بطرق مختلفة ، حاولنا تحويلها إلى نفس النمط تقريبًا. بطبيعة الحال ، هناك اختلافات إضافية متأصلة فقط في SDK أو HTTP API هذا. هنا لدينا حرية الاختيار. نحن لا نقول أنه باستثناء هذه الأقسام ، لا يمكن عمل أي شخص. بالطبع ، من الممكن ، نحن نحاول ببساطة إجراء الأقسام المدرجة في كل مكان بحيث يكون من الواضح أنه إذا قام المستخدم بالتبديل إلى SDK آخر في الوثائق ، فإنه يعرف ما سيتم وصفه في قسم "الاتصال".
لذلك ، توصلنا إلى قوالب ، وأدلة مختصرة ، ما هي خطة عملنا الآن؟ قررنا أنه في حالة توسيع واجهة برمجة التطبيقات أو تغيير الأقلام أو تغيير SDK ، فإننا نأخذ نماذج جديدة ونأخذ بنية جديدة ونبدأ العمل عليها.
إذا كتبنا وثائق من البداية ، فإننا بالطبع نأخذ مرة أخرى هيكلًا جديدًا ونأخذ قوالب جديدة ونعمل عليها.
وإذا كانت واجهة برمجة التطبيقات قديمة أو نادرا ما يتم تحديثها أو لا يدعمها أحد ، لكنها موجودة ، ثم أعدها بشكل مكثف من الموارد. لقد قررنا فقط أن نتركها حتى كانت كذلك ، ولكن عندما تظهر الموارد ، سنعود إليها بالتأكيد ، وسنفعل كل هذا بشكل جيد وجميل.
ما هي فوائد التوحيد؟ يجب أن تكون واضحة للجميع:
"UX" ، نفكر في جعل المستخدم يشعر بأنه في المنزل في وثائقنا. جاء ، ويعرف ما هو موصوف في الأقسام حيث يمكنه العثور على التفويض ، وأمثلة على الاستخدام ، ووصف القلم. هذا رائع.
بالنسبة لكتاب التكنولوجيا ، يسمح لك وصف التكنولوجيا بتحديد نقطة دخول معينة حيث يأتي ، ويبدأ في التعرف على هذه التكنولوجيا ، إذا لم يكن يعرفها ، يبدأ في فهم المصطلحات ، والانغماس فيها.
النقطة التالية هي التبادلية. إذا ذهب كاتب التكنولوجيا في إجازة أو توقف عن الكتابة ، فإن كاتبًا تقنيًا آخر ، عند دخول المستند ، يعرف كيف يعمل في الداخل. يتضح على الفور ما هو موصوف في الاتصال ، أين تبحث عن معلومات حول تكامل SDK. يصبح فهم وإجراء مراجعة صغيرة للمستند أسهل. من الواضح أن كل مشروع له تفاصيله الخاصة ، لا يمكنك فقط أن تأتي وتوثق بعض المشاريع دون معرفته تمامًا. ولكن في نفس الوقت ، ستكون البنية ، أي التنقل بين الملفات ، متشابهة تقريبًا.
وبالطبع ، المصطلحات العامة. تلك المصطلحات التي قمنا بتجميعها للغات ، اتفقنا مع المطورين والمترجمين. نقول أن لدينا C # ، هناك مثل هذا المصطلح ، نستخدمه بهذه الطريقة. سألنا المطورين عن المصطلحات التي استخدموها وأرادوا تحقيق التزامن في هذا المكان. لدينا اتفاقيات ، وفي المرة التالية التي نأتي فيها بالوثائق ، يعرف المطورون أننا اتفقنا على الشروط والأدلة معهم ، ونستخدم هذه النماذج ، ونأخذ في الاعتبار الفروق الدقيقة في استخدامها. والمترجمون بدورهم يعرفون أننا نصف SDK في C # أو Objective-C ، لذا فإن هذه المصطلحات تتوافق مع ما هو موضح في الدليل.
تمت كتابة الأدلة في صفحات wiki ، لذلك إذا تم تحديث اللغات والتقنيات والبروتوكولات ، فسيتم إضافة كل ذلك بسهولة إلى مستند موجود. ايديل.
كلما بدأت في التوحد والموافقة ، كان ذلك أفضل. من الأفضل أن لا يكون هناك إرث من الوثائق ، والتي تتم كتابتها بأسلوب مختلف ، مما يكسر تدفق المستخدم في الوثائق. من الأفضل أن تفعل كل ذلك في وقت سابق.
جذب المطورين. هؤلاء هم الأشخاص الذين تكتب لهم وثائق. إذا كتبت بنفسك نوعًا من الأدلة ، فربما لن يعجبها. من الأفضل الاتفاق معهم حتى يكون لديك فهم مشترك للمصطلحات: ما تكتبه في الوثائق ، وكيف تكتبه.
والتفاوض أيضًا مع المترجمين ، يجب عليهم جميعًا ترجمته. إذا كانوا يترجمون بشكل مختلف عما اعتاد عليه المطورون ، فستكون هناك تضاربات مرة أخرى. (
إليك رابط إلى مقطع فيديو يحتوي على أسئلة وأجوبة - محرر تقريبًا).
جوليا:
- مرحبًا ، اسمي جوليا ، أعمل في Yandex منذ خمس سنوات وأوثق واجهة برمجة التطبيقات و SDK في مجموعة Andrey. عادة الجميع يتحدث عن تجربة جيدة ، كم هي رائعة. سأخبرك كيف اخترنا استراتيجية غير ناجحة تمامًا. في ذلك الوقت ، بدا الأمر ناجحًا ، ولكن بعد ذلك جاء واقع قاسي ، وكنا محظوظين قليلاً.
كان لدينا في البداية العديد من حزم SDK المحمولة ، وتمت كتابتها بشكل رئيسي بلغتين: Objective-C و Java. كتبنا لهم وثائق يدوياً. مع مرور الوقت ، نمت الطبقات والبروتوكولات والواجهات. كان هناك المزيد والمزيد منهم ، وأدركنا أننا بحاجة لأتمتة هذا العمل ، نظرنا إلى التقنيات.
في ذلك الوقت ، أحببنا Doxygen ، فقد لبت احتياجاتنا ، كما بدا لنا ، واخترناها كمولد واحد. وقد رسمنا مثل هذا المخطط ، الذي كنا نتوقعه ، وأردنا العمل عليه بطريقة أو بأخرى.
ماذا لدينا؟ جاء الكاتب التقني إلى العمل ، وتلقى رمز المصدر من المطور ، وبدأ في كتابة تعليقاته ، وتحريراته ، وبعد ذلك كان يجب إرسال الوثائق إلى devserver لدينا ، حيث قمنا بتشغيل Doxygen ، وتلقى تنسيق XML ، ولكنه لم يتناسب مع معيار DITA XML. كتبنا محولًا معينًا عرفناه مسبقًا.
بعد أن حصلنا على الإخراج من Doxygen ، مررنا كل شيء من خلال المحول ، وحصلنا بالفعل على تنسيقنا. ثم تم توصيل جامع الوثائق ، وقمنا بنشر كل هذا على مجال خارجي. لقد كنا محظوظين حتى بضع مرات ، كل شيء نجح بالنسبة لنا ، كنا سعداء. ولكن بعد ذلك حدث خطأ ما. ذهب الكاتب التقني أيضًا إلى العمل ، وتلقى المهام ورموز المصدر من المطور ، وأدخل تصحيحاته هناك. بعد ذلك ، ذهب إلى المتسلط ، وأطلق Doxygen ، وكان هناك حريق.
قررنا معرفة ما هو الأمر. ثم أدركنا أن Doxygen لا يناسب جميع اللغات تمامًا. كان علينا أن نحلل الشفرة ، التي تعثرت عليها ، وجدنا بنيات لم تدعمها Doxygen ولم تخطط لدعمها.
قررنا ، بما أننا نعمل في هذا المخطط ، سنكتب نصًا أوليًا للمعالجة ، وسنستبدل هذه التركيبات بطريقة أو بأخرى بما يقبله Doxygen ، أو نتجاهلها بطريقة أو بأخرى.
بدأت دورتنا تبدو هكذا. تلقينا المصادر ، وأرفقناها على devserver ، ثم قمنا بتوصيل النص البرمجي للمعالجة المسبقة ، وقام بقص كل الفائض من الكود ، ثم دخل Doxygen العمل ، وتلقى تنسيق إخراج Doxygen ، وأطلقنا المحول أيضًا ، واستلمنا ملفاتنا النهائية من DITA XML ، ثم تم توصيل جامع الوثائق ، و نشرنا وثائقنا على مجال خارجي. يبدو أن كل شيء يبدو على ما يرام. تمت إضافة برنامج نصي ، ما هو هناك؟ في البداية ، لم يكن هناك شيء. كان هناك ثلاثة أسطر في النص ، ثم خمسة ، عشرة أسطر ، وكلها نمت إلى مئات الأسطر. أدركنا أننا بدأنا في قضاء معظم وقتنا في عدم كتابة الوثائق ، ولكن تحليل الشفرة ، والبحث عن ما لا يزحف إلى أين ، وإضافة النص البرمجي إلى النظاميين اللامتناهيين ، والجلوس إلى حد الجنون والتفكير في الأمر.
أدركنا أننا بحاجة إلى تغيير شيء ما ، والتوقف بطريقة ما ، قبل فوات الأوان ، وحتى انقضاء دورة الإصدار الخاصة بنا حتى النهاية.
على سبيل المثال ، بدا النص الأولي للمعالجة شيئًا مثل هذا في البداية ، ولم يكن ضارًا.
لماذا اخترنا هذا المسار في البداية؟ لماذا بدا جيدا؟
مولد واحد رائع ، أخذه ، وصله مرة واحدة ، قم بإعداده ويعمل. يبدو أنه نهج جيد. بالإضافة إلى ذلك ، يمكنك استخدام بنية تعليق واحد لجميع اللغات في وقت واحد. لقد كتبت نوعًا من الدليل ، واستخدمه مرة واحدة ، وأدخل على الفور جميع هذه الإنشاءات في التعليمات البرمجية وقم بعملك ، وقم بكتابة التعليقات ، ولا تحدد بطريقة ما بناء الجملة.
لكن تبين أن هذا هو أحد السلبيات الكبيرة. لم يدعم المطورون بناء الجملة المشترك لدينا ، فهم معتادون على استخدام IDEs الخاصة بهم ، وهناك بالفعل مولدات أصلية هناك ، ولا يتوافق بناء الجملة الخاص بهم مع تركيبتنا. كان هذا حجر عثرة.
تدعم Doxygen أيضًا الميزات الجديدة السيئة في اللغات. لديه نهج انتقائي ، حيث أنه هو نفسه مكتوب بلغة C ++ ، فهو يدعم بشكل أساسي اللغات المشابهة لـ C ، والباقي وفقًا للمبدأ المتبقي. ويتم تحسين اللغات ، لا تتوافق Doxygen معها تمامًا ، وقد أصبح الأمر غير مريح بالنسبة لنا.
ثم حدثت مصيبة. جاء إلينا فريق جديد وقال إننا نكتب على Swift ، وأن Doxygen ليسوا أصدقاء معه على الإطلاق. أدركنا أن كل شيء قد حان للتوقف والتوصل إلى شيء جديد. ثم جاء فريقان آخران ، وأدركنا أنه لا يمكن تطوير مخططنا على الإطلاق. ونضيف شيئًا باستمرار ، ولدينا العديد من هذه النصوص ، وهم يعيشون في فروع مختلفة وهذا كل شيء. أدركنا أننا بحاجة إلى قبول ما كنا محظوظين ، وتجربة طرق وحلول جديدة لإيجادها. سيخبرك أندري عنهم.
"لقد أدركنا أنه في حالتنا ، ظهر في مكان ما مولد عالمي ، ولكن في الغالب ، عندما بدأنا في توسيع نطاق كل شيء ، لم تنجح الخطة. لقد أتوا ببرود ، واتفقوا مع كل من دعنا نفعل ذلك ، لكن ذلك لم ينجح.
ونتيجة لذلك ، بدأنا في وضع مخطط جديد. كانت مع مولدات أصلية. ماذا لدينا في الدائرة الآن؟ ( , ), , Objective-C Java, , .
, DITA XML, , , , XML. HTML, . — JavaDoc, AppleDoc, Jazzy. HTML, . HTML, , . , HTML . , , , HTML, . XML , . .
.
— . Doxygen , , . Objective-C, , Java . . , , IDE , IntelliSense, , , , SDK, , . .
, , SDK , , , , HTML, . , , , , , .
. , - , . XML , XML . Doxygen , XML . HTML, XML . . — .
, , . 1500 , : HTML, CSS, .
, , .
. (
— . .)
, , .
— . , . -, . , . ? .
? -, , , , .
- , - , . .
? -, , , , .
. , , , , , , , .
, . , , , , , , .
? — , , , , , . . Bitbucket, - . , .
, . . - , - , , , , , , . , , , , .
, , .
, SDK , - , , . -, , , , .
, . . — , , .
, . . .
, , , , , , .
, .
. - , . .
, , , , . . , , , - . , . , , .
, .
. , . , , .
, , , — . , , , .
dev , (fork-dev) , . , doc-dev-en, . , , - , , .
(fork-dev) (doc-dev-ru) . , - . . , , doc-dev-ru, . , , - , .
, . (doc-dev-en). , , (doc-dev-en), , . , (fork-dev). , , , , . , , . , dev . , , , .
(fork-dev), , . (fork-dev), , (doc-dev-en), . , , , . , .
, , . dev, (fork-dev) , (doc-dev-ru) (doc-dev-en) . (doc-dev-en), (doc-dev-ru) . , .
. dev , , (branch-dev). (branch-dev-ru), (branch-dev). , . , . — , — - , , , , .
, , . , , (branch-dev) . , , .
dev. , , , , . .
(branch-dev-ru), , (branch-dev-ru), . .
. (branch-dev), . , , , , , , , , . , , . , , .
, , , , . .
, ? , , . . . , - , . . , .
, , , , , .
, . . . . , , .
— — . — .
. . , . , , , , , , . .
, . . . . , . , . - , . — . .
يجب أن تكون العمليات مناسبة بالتساوي للجميع. لذلك ، ليس لدينا ديكتاتورية ، نأتي إلى المطورين ونقول: دعونا نعمل خلال الغداء. ويقولون أنهم يعملون من خلال الشوكات. نقول: حسنًا ، لكن دعنا نتفق على أننا نعمل أيضًا من خلال الشوكات. من الضروري الموافقة بحيث يكون لكل شخص مشارك في هذه العملية - في التوطين وكتابة التعليمات البرمجية والوثائق في التعليمات البرمجية - موقف متفق عليه. إنه مناسب عندما يفهم الجميع مجال مسؤوليتهم - وليس ذلك حتى يعمل الكاتب التقني بعينيه مغلقتين ولا يرى الرمز أو لا يستطيع الوصول إلى المستودع. هذا كل شيء.