از RFC به ADR: رسیدن به تصمیم و حفظ استدلال
یک RFC معمولاً درباره رسیدن به توافق است؛ یک ADR توافقی را که به آن رسیده شده ثبت میکند — و دلیل اینکه ADRها خراب میشوند این است که بحث در چت و نظرات درخواستهای کشش ادامه دارد در حالی که ثبت آن بعداً، از روی حافظه، توسط یک نفر نوشته میشود. برای اجرای جریان RFC به ADR به گونهای که ثبت از بحث خارج شود: پیشنهاد را به عنوان یک ادعای اصلی بیان کنید (عنوان ADR آینده)؛ زمینه را به عنوان استدلالهای جداگانه اضافه کنید تا هر نیرویی به طور جداگانه به چالش کشیده شود؛ به هر گزینهای که مورد بررسی قرار گرفته، یک گره خواهر با مزایا و معایب خود بدهید — شامل گزینههای رد شده؛ دور نظرات RFC را به صورت زنجیرهای اجرا کنید (زنجیرههای سوال و جواب برای روشنسازی، زنجیرههای بررسی برای اعتراضات — هر کدام یک گفتگوی چهار نوبتی بین بازبینیکننده و نویسنده گزینه است، با N بازبینیکننده به معنای N زنجیره موازی؛ زنجیرههای مصالحه برای آشتی دادن اختلافات، جایی که یک زنجیره کامل تلاش را ثبت میکند چه حل شده باشد چه نه)؛ تصمیمگیرندگان گزینهها را به عنوان شواهدی از وضعیت اتاق ارزیابی کنند — ارزیابی تصمیم نیست، یک انسان نامدار هنوز آن را اعلام میکند؛ پیامدهای پذیرفته شده را به عنوان فرزندان معایب گزینه انتخاب شده ثبت کنید؛ و جانشینی را با پیوند دادن یک تصمیم بعدی به تصمیمی که جایگزین آن میشود مدلسازی کنید، در حالی که نسخه قدیمی قابل خواندن باقی میماند. کاشت از ADRهای موجود در markdown یا متون سنگین تصمیمگیری از طریق استخراج هوش مصنوعی با منبعنگاری انجام میشود. محدودیتهای صادقانه: این جایگزین ADRهای ردیابی شده در مخزن نمیشود (ثبت و تعهد به رکورد)؛ هیچ فیلد وضعیت ADR داخلی وجود ندارد، بنابراین پیشنهاد شده/پذیرفته شده/جایگزین شده یک کنوانسیون است که شما حفظ میکنید؛ یک زنجیره کامل به معنای توافق طرفین نیست — که دقیقاً همان چیزی است که عدم توافق و تعهد را قابل فهم میکند.
یک RFC معمولاً درباره رسیدن به توافق است؛ یک ADR توافق را پس از رسیدن به آن ثبت میکند. ADRها خراب میشوند زیرا فرآیند رسیدن به توافق در چت انجام میشود و ثبت آن بعداً، از روی حافظه، صورت میگیرد. هر دو را در یک ساختار اجرا کنید:
- پیشنهاد یک ادعای اصلی است; نیروهای زمینهای جداگانه، قابل چالش و استدلالهای موافق هستند؛ هر گزینه — از جمله گزینههای رد شده — گره خاص خود را دارد
- دور RFC زنجیرهها: پرسش و پاسخ برای روشنسازی، بررسی برای اعتراض، مصالحه برای آشتی — گفتوگوهای چهارگانه، N بازبینیکننده = N زنجیره موازی
- امتیاز تصمیم نیست: تصمیمگیرندگان به عنوان شواهد امتیاز میدهند؛ یک انسان نامدار آن را مینامد — و مینویسد چرا، بهویژه در برابر اتاق
- ADR درخت است: هیچ چیزی نوشته نمیشود، بنابراین هیچ چیزی در نوشتن از دست نمیرود — اگر سازمان شما نیاز دارد، به مخزن صادر کنید
تصمیمی که هیچکس نتوانست بازسازی کند
رهبر فنی جدید سوال معقولی میپرسد: چرا هر سرویس از طریق آن صف با سیستم صورتحساب ارتباط برقرار میکند؟ یک ADR وجود دارد — ADR-014، چهار جمله، که یازده ماه پیش نوشته شده است. زمینه: "ما به یک یکپارچگی قابل اعتماد در صورتحساب نیاز داشتیم." تصمیم: "از صف استفاده کنید." عواقب: "برخی تأخیرهای اضافی." از نظر فنی یک رکورد است. هیچ چیزی را پاسخ نمیدهد.
شما آنجا بودید، بنابراین میدانید که ADR-014 چه چیزی نمیگوید: بحث سههفتهای در دو کانال Slack و یک رشته PR داغ؛ گزینه API همزمان که به دلیل محدودیت نرخ شکست خورد و از آن زمان افزایش یافته است؛ اعتراض مهندس ارشد که با یک معیار پاسخ داده شد که حالا هیچکس نمیتواند آن را پیدا کند. این بحث انجام شد. رکورد بعداً، از روی حافظه، توسط یک نفر، در یک جمعه نوشته شد.
این حالت شکست مستند و تقریباً جهانی یک روش واقعاً خوب است. راهنماییهای تجویزی AWS و مستندات Well-Architected مایکروسافت هر دو ADRها را توصیه میکنند — و هر دو به دردسر اشاره میکنند: بهروز نگهداشتن آنها زمان میبرد و مدیریت آنها با افزایش تیمها و انتخابها پیچیده میشود. علت اصلی ساختاری است: بحث و سوابق در مکانهای مختلف وجود دارند، بنابراین سوابق همیشه یک رونویسی با افت کیفیت هستند. راه حل این است که آنها را در یک مکان قرار دهیم. همچنین این روش خاص مهندسی یا حتی خاص ADR نیست. گوگل یک مدرک طراحی را الزامی میداند — مشکل، رویکرد پیشنهادی، گزینههای در نظر گرفته شده، و تعادلها — که باید قبل از شروع کار فنی قابل توجه نوشته و بررسی شود، روشی که در مهندسی نرمافزار در گوگل خود شرکت بیان شده است. این همان انضباطی است که در یک ADR وجود دارد، که یک مرحله زودتر اعمال میشود: ADR انتخابی را ثبت میکند که مدرک طراحی به آن استدلال کرده است. هر دو به یک دلیل به یک شکل شکست میخورند و هر دو با یک حرکت یکسان اصلاح میشوند — بحث را در جایی که سوابق وجود دارد نگه دارید، به جای اینکه یکی را بعداً به دیگری رونویسی کنید. هر مرحله زیر را بهعنوان پوششدهنده هر دو اثر در نظر بگیرید.
چرا ADRها خراب میشوند
یک جمله از مطالب خود جامعه ADR تمام تشخیص را به همراه دارد: یک RFC معمولاً درباره رسیدن به توافق است؛ یک ADR توافق را پس از رسیدن به آن ثبت میکند. دو اثر، دو لحظه — و هر چیزی که بین آنهاست نشت میکند. گزینههایی که "به وضوح" اشتباه بودند ثبت نمیشوند (تا زمانی که دیگر واضح نباشند). اعتراضی که طراحی نهایی را شکل داد تنها به عنوان یک نظر PR در یک موضوع بسته باقی میماند. بخش زمینه آخرین چیزی است که نوشته میشود، بدترین، توسط هر کسی که در بازی "نه آن" باخت. جلساتی که باید تصمیمات را تولید میکردند به جای آن خلاصههایی تولید میکنند و استدلالی که یک تصمیم را پایدار میکند — چیزی که کل زنجیره کیفیت تصمیم به آن وابسته است — دقیقاً همان چیزی است که در رونویسی از دست میرود.
آنچه شما نیاز دارید
یک بحث Argumentree برای هر RFC. اگر مجموعهای از ADRهای markdown موجود دارید یا متن جلسهای با تصمیمات زیاد دارید، آن را بارگذاری کنید — استخراج هوش مصنوعی آن را به استدلالهای ساختاریافته pro/con تبدیل میکند با بخشهای منبع پیوست شده، که به عنوان استخراج شده علامتگذاری شدهاند تا ادعاهای وارد شده هرگز با ادعاهای زنده اشتباه گرفته نشوند (نحوه کار استخراج).
مرحله ۱–۳: پیشنهاد، زمینه، گزینهها
- 1پیشنهاد را به عنوان ادعای اصلی بیان کنید — تصمیم پیشنهادی، نه یک سوال: "ما تمام نوشتنهای صورتحساب را از طریق یک صف پایدار هدایت خواهیم کرد." این جمله عنوان آینده ADR است. نقطه بررسی: ریشه وجود دارد، یک جمله، نوشته شده توسط پیشنهاد دهنده.
- 2زمینه به عنوان استدلالهای جداگانه. هر نیرویی که تصمیمگیری را ضروری میسازد — نیاز به قابلیت اطمینان، محدودیت نرخ سیستم صورتحساب، الزام حسابرسی — استدلال خود را تحت ریشه دارد. یک پاراگراف "زمینه" یکپارچه نمیتواند به چالش کشیده شود؛ سه ادعای زمینه جداگانه میتوانند به طور جداگانه مورد سوال، تأیید یا رد قرار گیرند. نقطه بازرسی: ≥2 استدلال زمینه، هر کدام یک نیرو.
- 3هر گزینه یک نود مخصوص به خود دارد. صف، API همزمان، کار دستهای — آرگومانهای خواهر و برادر، هر کدام با مزایا و معایب خود. مزایا/معایب نسبت به والد است، بنابراین معایب یک گزینه به آن گزینه مربوط میشود، نه به تصمیم. گزینههایی که انتظار دارید رد کنید را شامل کنید: خواهر و برادر رد شده همان چیزی است که به سوال "چرا فقط… نکردیم" سال آینده پاسخ میدهد. نقطه عطف: هر گزینهای که یک خواننده ممکن است دربارهاش سوال کند وجود دارد.
مرحله ۴–۶: دور RFC که یک رکورد به جا میگذارد
حالا نوبت بررسی — معمولاً بخشی که در چت، نظرات و راهروها پخش میشود. در اینجا به صورت سه نوع تبادل ساختاریافته اجرا میشود، هر کدام یک گفتگوی چهار نوبتی بین یک بازبین و نویسنده گزینه:
زنجیره پرسش و پاسخ — توضیح دهید
"برای مشتریان همزمان موجود چه اتفاقی میافتد؟" نویسنده گزینه پاسخ میدهد، بازبین پیگیری میکند، نویسنده دوباره پاسخ میدهد — کامل. هیچ گزینهای نباید سوال بیپاسخی را به تصمیم منتقل کند.
زنجیره بررسی — شیء
یک داور یک گزینه را نامناسب ارزیابی میکند؛ نویسنده پاسخ میدهد؛ پیگیری؛ پاسخ. N داور = N زنجیره موازی بر روی همان گزینه — هر اعتراضی یک تبادل قابل انتساب خود را دارد، نه یک نظر گمشده در یک رشته مشترک.
زنجیره مصالحه — آشتی
دو اردوگاه تقسیم میشوند؟ یکی گزینه میانه را به نویسنده دیگر پیشنهاد میدهد. اگر حل شود، شما یک گره گزینه جدید دارید. اگر حل نشود، زنجیره کامل شده، رکوردی است که نشان میدهد تلاش شده است — که تقریباً به همان اندازه ارزش دارد.
تکمیل شده ≠ توافق شده
یک زنجیره که به تکمیل شده میرسد به این معنی است که تبادل به پایان رسیده است — سوالی پرسیده و دو بار پاسخ داده شده — نه اینکه طرفین توافق کردهاند. این تمایز را حفظ کنید؛ به زودی اهمیت خواهد داشت.
مرحله ۷: تصمیمگیری — و اینکه ارزیابی چیست و چیست نیست
تصمیمگیرندگان گزینهها را ارزیابی میکنند: هر کدام با برچسبی مشخص. توزیع شواهد واقعی است — جایی که اتاق ایستاده بود، بهطور رسمی، قبل از تماس. اما ارزیابی تصمیم نیست. یک انسان مشخص هنوز تصمیم میگیرد و اگر تماس بر خلاف توزیع باشد، گره تصمیم جایی است که این موضوع توضیح داده میشود. (اینکه آن انسان مشخص چه کسی باید باشد و چگونه باید نقش را قبل از بحث به او واگذار کرد نه بعد، یک رشته مستقل است — به آموزش حقوق تصمیمگیری مراجعه کنید.)
سوال برای تیم شما
چه کسی آخرین تصمیم معماری شما را گرفت — و آیا میتوانید آن را ثابت کنید؟ نه کسی که در جلسه بود: چه کسی مالک تصمیم بود و استدلال آن کجا نوشته شده است؟
مرحله ۸–۹: ADR که نیازی به نوشتن آن نداشتید
این نتیجه است. رکورد مدرکی نیست که بعداً بنویسید — این گره گزینه انتخاب شده به علاوه همه چیزهایی است که قبلاً به آن متصل شدهاند: استدلالهای زمینهای (Context)، خواهر و برادرهای رد شده (Options Considered)، زنجیرههای کامل شده (بحث، با نویسندگان)، ارزیابیها (جایی که اتاق ایستاده بود) و استدلال تصمیم با دلایل آن (Decision). هیچ چیزی رونویسی نمیشود، بنابراین هیچ چیزی در رونویسی از دست نمیرود.
- 1عواقبی را که میپذیرید ثبت کنید. معایب شناخته شده — تأخیر اضافی، بار عملیاتی صف — به عنوان فرزندان انتخاب شده، توسط تصمیمگیرنده تأیید میشوند. نوشتن آنها است که این را به یک تصمیم تبدیل میکند نه یک ترجیح. نقطه بازرسی: ≥1 عواقب پذیرفته شده در سوابق.
- 2صادرات اگر سازمان شما به ADRهای ردیابی شده در مخزن نیاز دارد. بسیاری از آنها به درستی این کار را انجام میدهند — ADR مارکداون در کنار کد، اثر تطابق باقی میماند. خلاصه چهار بخشی را از درخت بنویسید (پنج دقیقه، نه یک جمعه)، به بحث برای مناظره کامل لینک دهید. نقطه بازرسی: ADR مخزن به درخت اشاره میکند؛ درخت دلیلتراشی را در خود دارد.
اختلاف نظر داشته باشید و متعهد شوید، به صورت رسمی
الگوی که آمازون مشهور کرد — اختلاف نظر و تعهد — یک مشکل خوانایی دارد: چگونه کسی بعداً میفهمد که اختلاف واقعی، شنیده و پاسخ داده شده است، نه اینکه نادیده گرفته شده باشد؟ مکانیکهای زنجیرهای به این سوال پاسخ میدهند. یک زنجیره بررسی که چهار دور کامل خود را طی کرده و بدون توافق به پایان رسیده است، دقیقاً رسیدی است: اعتراض مطرح شده، پاسخ داده شده، فشار آورده شده و دوباره پاسخ داده شده، در سوابق، قبل از اینکه مخالف تعهد کند. مخالف به عنوان کسی که شنیده شده است مستند شده — که این همان چیزی است که تعهد بعدی را منطقی میسازد و نه صرفاً اطاعت.
نتیجهگیری را به عنوان توافق نخوانید
تکمیل به معنای این است که تبادل به پایان رسیده است، نه اینکه کسی نظرش را تغییر داده باشد. اگر شما تکمیل زنجیره را به عنوان توافق گزارش کنید، اجماع کاذب تولید خواهید کرد و اعتمادی را که این مکانیزم برای ساخت آن وجود دارد، از بین خواهید برد. خوانش صادقانه: مشاوره شده، پاسخ داده شده، هنوز مخالف، با این حال متعهد — همه چهار واقعیت قابل مشاهده است.
مرحله ۱۰: جانشینی بدون حذف
سن تصمیمات. زمانی که محدودیت نرخ که گزینه همزمان را از بین برده افزایش یابد، حرکت درست یک تصمیم جدید است که به تصمیمی که جایگزین آن میشود اشاره میکند — یک استدلال جدید مرتبط با گره ADR-014 که بیان میکند چه چیزی تغییر کرده است. تصمیم قدیمی قابل خواندن باقی میماند؛ استدلال آن دقیقاً دلیلی است که تصمیم جدید میداند چه چیزی را نقض میکند.
یک شکاف صادقانه برای مدیریت بهطور صریح: هیچ فیلد وضعیت ADR داخلی وجود ندارد. پیشنهادی / پذیرفته شده / جایگزین شده یک وضعیت درجه یک در یک استدلال نیست — جایگزینی با پیوند زدن مدلسازی میشود و این کنوانسیون به عهده شماست که حفظ کنید. آن را در توافقنامه کاری تیم خود بیان کنید به جای اینکه فرض کنید محصول آن را تحمیل میکند.
محدودیتهای صادقانه
- ✗این جایگزین ADRها در مخزن شما نمیشود اگر سازمان شما نیاز دارد که آنها در کنار کد نسخهگذاری شوند. خلاصه را صادر و ثبت کنید؛ از درخت برای بخشی که Markdown در آن ضعیف است — بحث — استفاده کنید.
- ✗فیلد وضعیت ADR وجود ندارد. پیشنهاد شده/پذیرفته شده/جایگزین شده یک کنوانسیون پیوندی است که شما حفظ میکنید، نه چیزی که محصول آن را تحمیل کند.
- ✗یک زنجیره چهار دور است. اختلاف عمیق معماری نیاز به یک تماس خواهد داشت؛ زنجیره سوابق آنچه قبلاً امتحان شده است را ثبت میکند.
- ✗امتیازها یک مقدار برچسبگذاری شده واحد هستند، نه نمرهدهی چندمعیاره وزنی.
- ✗این باعث نمیشود که کسی متن خوبی بنویسد. ساختار هزینه یک رکورد خوب را کاهش میدهد؛ اما قضاوت را تأمین نمیکند.
درسهای عملی
- ✓یک RFC، یک بحث. در برابر درخت بزرگ که کل معماری منطقه را پوشش میدهد مقاومت کنید — لینکهای جانشینی تصمیمات را بهتر از تو در تویی متصل میکنند.
- ✓بذر از آنچه وجود دارد. یک متن پر از تصمیمات یا پوشه قدیمی ADR شما، استخراج شده، به بحث یک شروع قوی میدهد — برچسبگذاری شده به عنوان وارد شده، تا استدلالهای زنده قابل تشخیص بمانند.
- ✓نامهای داوران را بر روی زنجیرهایشان بگذارید و آنها را همانجا بگذارید. نسبتدادن مسئولیت است؛ اعتراضات معماری ناشناس به افسانهها تبدیل میشوند.
- ✓بخش پیامدها متعلق به تصمیمگیرنده است، نه هیچ کس دیگری. معایب پذیرفته شده توسط شخصی که آنها را پذیرفته است، وزن متفاوتی نسبت به هشدارهای یک بازبین دارند.
ADR-014، نسخهای که پاسخ میدهد
برگردیم به سوال رهبر فنی جدید. در نسخه بازسازی شده، ADR-014 یک گره است: تصمیم صف با دلایل آن، سه نیروی زمینهای (یکی اکنون منقضی — به وضوح)، یک همخانواده API همزمان رد شده که نام مرگبار آن محدودیت نرخ قدیمی است، چهار زنجیره بررسی کامل شده شامل زنجیره مهندس ارشد، و معیار پیوست شده به عنوان مدرک. رهبر فنی به مدت ده دقیقه میخواند، میبیند که محدودیت نرخ تغییر کرده و یک پیشنهاد جایگزین مرتبط با گره قدیمی را باز میکند. هیچکس به سراغ Slack نمیرود. این تمام وعده است: زنجیرهها به توافق میرسند، درخت آن را ثبت میکند — و ثبت به سوالاتی پاسخ میدهد که نمیدانستید از آن پرسیده خواهد شد.
منابع و مطالعه بیشتر
- نیگارد، م. (۲۰۱۱). مستندسازی تصمیمات معماری. وبلاگ کگنیتکت.مقالهای که ADRها را محبوب کرد: زمینه، تصمیم، عواقب، با کد همراه بود.
- راهنماییهای تجویزی AWS — سوابق تصمیمگیری معماری.چارچوب RFC در مقابل ADR و مشکلات مستند نگهداری که این آموزش برای رفع آن وجود دارد.
- چارچوب بهخوبی طراحیشده مایکروسافت آژور — سوابق تصمیمگیری معماری.عملکرد ADR در زمینه بررسی Well-Architected.
- سازمان ADR در گیتهاب (adr.github.io).قالبها، ابزارها و کنوانسیونهای انباشته شده جامعه — از جمله شیوهی وضعیتمیدان که این آموزش با پیوند زدن مدل میکند.
سوالات متداول
تفاوت بین RFC و ADR چیست؟
یک RFC (درخواست برای نظرات) فرآیند رسیدن به توافق است: یک پیشنهاد منتشر میشود، گزینههای جایگزین مورد بحث قرار میگیرند، اعتراضات مطرح و پاسخ داده میشود. یک ADR (سند تصمیمگیری معماری) توافقی را که به آن رسیده شده ثبت میکند: زمینه، گزینههای مورد بررسی، تصمیم، پیامدها، وضعیت. حالت شکست اجرای آنها به عنوان آثار جداگانه این است که همه چیز بین آنها نشت میکند — بحث در چت و نظرات PR ادامه دارد در حالی که سند بعداً از روی حافظه نوشته میشود. اجرای RFC به عنوان یک درخت استدلال ساختاری باعث میشود که ADR از خود بحث خارج شود: هیچ چیزی نوشته نمیشود، بنابراین هیچ چیزی در نوشتن از دست نمیرود.
چرا ADRها کهنه میشوند یا دیگر نوشته نمیشوند؟
زیرا نوشتن آنها یک کار رونویسی است. استدلال واقعی در گفتگوهای اسلک، نظرات بازبینی و جلسات اتفاق میافتد؛ بعد از آن یک نفر بخش زمینه را از حافظه بازسازی میکند، معمولاً بهطور مختصر و در آخر. راهنماییهای خود AWS و مایکروسافت درد را یادآوری میکند: نوشتن و بهروزرسانی ADRها زمانبر است و مدیریت پیچیده میشود زیرا تصمیمات افزایش مییابند. تیمها به اعتقاد به ADRها ادامه میدهند — آنها از پرداخت مالیات رونویسی دست میکشند. یکسان کردن ساختار بحث و سوابق، مالیات را حذف میکند.
چگونه یک دور بازبینی RFC با یک رکورد اجرا میکنید؟
سه حرکت ساختاریافته، هر کدام یک گفتگوی چهار نوبتی با نویسنده گزینه. زنجیرههای پرسش و پاسخ برای روشنسازی: سوال، پاسخ، پیگیری، پاسخ. زنجیرههای بررسی برای اعتراضات: ارزیابی، پاسخ، پیگیری، پاسخ — با N بررسیکننده که N زنجیره موازی را بر روی همان گزینه باز میکنند به جای یک رشته مشترک، بنابراین هر اعتراضی قابل انتساب و پاسخ داده شده باقی میماند. زنجیرههای مصالحه برای تقسیمات: یک طرف موقعیت میانه را به طرف دیگر پیشنهاد میدهد و چه این موضوع حل شود یا نه، زنجیره کامل شده ثبت میکند که این تلاش انجام شده است. نقطه بازرسی قبل از تصمیمگیری: هیچ گزینهای سوال بیپاسخی ندارد و هر اعتراض معنادار به عنوان یک زنجیره کامل شده وجود دارد.
چگونه "عدم توافق و تعهد" با سوابق تصمیمگیری کار میکند؟
مکانیک زنجیرهای آن را قابل خواندن میکند. یک زنجیره بررسی که تمام مراحل خود را طی میکند — اعتراض، پاسخ، پیگیری، پاسخ — و بدون توافق به پایان میرسد، رسیدی است که نشان میدهد اختلاف واقعی، شنیده و پاسخ داده شده است قبل از اینکه مخالف متعهد شود. به طور انتقادی، کامل شدن به معنای توافق نیست: به این معناست که تبادل به پایان رسیده است. گزارش کامل شدن به عنوان اجماع، توافق کاذب تولید میکند و ارزش مکانیزم را از بین میبرد. ثبت صادقانه چهار واقعیت را به طور همزمان نشان میدهد: مشاوره شده، پاسخ داده شده، هنوز مخالف، با این حال متعهد — که دقیقاً همان چیزی است که تعهد پس از اختلاف را معقول میسازد.
آیا سوابق تصمیمگیری باید جایگزین ADRها در مخزن کد شوند؟
نه — و این آموزش به وضوح این را بیان میکند. اگر سازمان شما به ADRهای تحت کنترل نسخه در کنار کد نیاز دارد (بسیاری از سازمانها به درستی برای رعایت قوانین و دسترسی آفلاین این کار را میکنند)، آنها را نگه دارید: خلاصه چهار بخشی markdown را از درخت در پنج دقیقه بنویسید و آن را به بحث مرتبط کنید. تقسیم کار واضح است: ADR در مخزن، اثر پایدار رعایت قوانین است؛ درخت آنچه را که markdown در آن ضعیف است نگه میدارد — بحث زنده، گزینههای رد شده با دلایلشان، اعتراضات و پاسخهایشان، و ارزیابیها.
چگونه یک ADR را به عنوان منسوخ شده علامتگذاری میکنید؟
به طور قراردادی، نه بر اساس یک حوزه — و شایسته است که صادق باشیم که هیچ وضعیت پیشنهادی/پذیرفته شده/جایگزین شدهای به طور داخلی برای یک استدلال وجود ندارد. جایگزینی مدل را با ایجاد تصمیم جدید به عنوان استدلالی مستقل که به استدلالی که جایگزین میکند مرتبط است، انجام دهید و بیان کنید که چه چیزی تغییر کرده است (حد بالای نرخ افزایش یافته، الزامات جدید). تصمیم قدیمی همچنان قابل خواندن باقی میماند — حذف آن دقیقاً استدلالی را که تصمیم جدید نیاز دارد به آن ارجاع دهد، از بین میبرد. قرارداد را در توافق کاری تیم خود بیان کنید تا به طور عمدی حفظ شود.
نوشتن تصمیمات را متوقف کنید. شروع به نگهداری از آنها کنید.
RFC بعدی خود را به صورت درختی اجرا کنید: گزینهها با دلایلشان، اعتراضات به عنوان زنجیرههای پاسخ داده شده و یک ADR که خود به خود نوشته میشود.
آغاز آزمایش رایگان ۱۴ روزه