DAF چیست؟
DAF (Diseño Presicipado al Fallo – طراحی شکست پیش بینی شده) یک روش معتبر نیست و نه یک مقاله دانشگاهی. این یک طرز فکر متولد هرج و مرج ، از اشکال غیر منتظره در تولید ، از سیستمی است که در طول یک نسخه ی نمایشی زنده شکست می خورد.
DAF قبل از وقوع ، فکر کردن در مورد خطاها را پیشنهاد می کند. طراحی برای شکست با لطف ، بدون از دست دادن کنترل. این به معنای اجتناب از خطاها نیست ، بلکه در مورد آغوش آنها از طرح به طوری که سیستم فروپاشیده نشود.
چرا داف؟
از آنجا که ما از ترس از اشکالات خسته شده ایم. از آنجا که شکست طبیعی است ، اما آماده سازی سهل انگاری است.
DAF از لزوم ایجاد نرم افزار انسانی تر ، قوی تر و همدلی تر ناشی می شود. برای درک اینکه خطاها بخشی از روند هستند ، نه از دشمنان جلوگیری می شود.
6 ستون DAF
1. تمرکز خطاها
سیستم باید با صدای بلند فریاد بزند و روشن شود. دیگر سیاهههای پراکنده یا خطاهای خاموش نیست. متمرکز از طراحی.
مثال: DAF به جای گفتن “چیزی در پرداخت ها اشتباه پیش آمد” ، شما می گوید: “ارائه دهنده X به دلیل تعادل کافی پاسخ نداد.” واضح ، عملی.
2 طبقه بندی شکست
همه خطاها یکسان نیستند. DAF ترویج برچسب زدن آنها از طرح.
مثال: آیا این تقصیر کاربر ، شبکه ، سیستم یا ارائه دهنده است؟ طبقه بندی امکان تصمیم گیری خودکار ، بدون درام را فراهم می کند.
3. شفافیت برای همه
داف به همدلی اعتقاد دارد. در صورت عدم موفقیت ، مشتری باید بدون کدهای فنی یا کدهای جادویی ، آنچه را که اتفاق افتاده است درک کند.
مثال: نه “500 خطای داخلی” ، بلکه: “مشکلات احراز هویت خارجی. 5 دقیقه دوباره امتحان کنید.”
4. مقاومت از طراحی
احیای مجدد ، زمان بندی ، برگشتی نباید تکه باشد. آنها بخشی از طراحی هستند. DAF شما را مجبور می کند از ابتدا در مورد آنها فکر کنید.
مثال: اگر اتوبوس پیام پایین بیاید ، باید از قبل مجدداً و منطق هشدار داشته باشید. صبر نکنید تا داده ها را برای اجرای آن از دست بدهید.
5. راه حل هدایت شده
سیستم نه تنها باید فریاد بزند بلکه باید سرنخ های روشن ارائه دهیدبشر
مثال: اگر کاربر یک فیلد را نادرست ارسال می کند ، فقط 400 را برگردانید. بگویید: ” paymentDate قسمت باید از قالب برخوردار باشد yyyy-MM-dd.
6. بهبود مستمر بر اساس خطاها
هر شکست یک درس می گذارد. DAF پیشنهاد می کند که آنها را مستند سازی ، تجزیه و تحلیل آنها و طراحی مجدد آنچه لازم است.
مثال: یک اشکال مکرر در تاریخ منجر به استاندارد سازی اعتبارسنجی از قرارداد شد. خطاهای کمتری ، سرعت بیشتر.
آنچه DAF نیست
دفا TDD نیستبشر این به دنبال آزمایش آنچه شما انتظار دارید نیست ، اما جلوگیری از غیر منتظرهبشر این یک روش بسته نیست. این یک طرز فکر سازگار است.
“در حالی که TDD بر تأیید رفتار مورد انتظار از طریق تست های واحد تمرکز دارد ، DAF بر پیش بینی و رسیدگی به سناریوهای خطای غیر منتظره در سطح طراحی تمرکز دارد.”
DAF برای کیست؟
برای همه افراد درگیر در چرخه عمر نرم افزار: توسعه دهندگان (کمتر اشکالات غافلگیرانه) ، QAS (آزمایش مؤثرتر) ، PMS (محصولات قابل اطمینان تر) و طراحان UX (کاربران کمتر ناامید). از آنجا که وقتی خطاها در طراحی پیش بینی می شود ، کیفیت محصول بهبود می یابد و استرس تیم کاهش می یابد و به همه اجازه می دهد تا با آرامش بیشتری بخوابند.
یک سفارش ساده از هرج و مرج
DAF چرخ را دوباره اختراع نمی کند. این در مورد بهترین ایده های مختلف (مانند مهندسی تاب آوری ، تفکر DevOps و تمرکز روی تجربه کاربر) برای ساختن نرم افزاری از واقعیت کار روزانه: هرج و مرج است. درست همانطور که نظریه هرج و مرج به ما می گوید که حتی در بیشترین سیستم های بی نظم نظم اساسی ظهور می کند ، DAF به دنبال طراحی سیستم هایی است که حتی در صورت عدم موفقیت آنها ، این کار را با روشی واضح و کنترل شده برای همه انجام دهید ، از تیم فنی تا کاربر نهایی.
از خواندن شما متشکرم! امیدوارم این مقدمه برای DAF مفید و الهام بخش باشد. نظر شما در مورد طراحی برای شکست چیست؟ افکار خود را در نظرات به اشتراک بگذارید!
[Hector Jaime – Mapache]
“از آنجا که خطاها پایان نیستند ، آنها آغاز طراحی خوب هستند.”
www.linkedin.com/in/hectorjaimedmz
