سازمان‌هایی که تلاش می‌کنند تا واجد صفت «چابک» شوند، اگر از ارزشها و اصول چابکی غفلت کنند یا دانش محدودی درباره نگرش (Mindset) چابک داشته باشند، اغلب به وضعیتی دچار می‌شوند که از چابکی تنها پوسته‌ای بر تن می‌کنند و چون به مغز و هسته‌ی چابکی توجه کافی ندارند، دور از انتظار نیست که همان روش‌های سنتی را با ظاهر چابک اجرا کنند.
علاوه بر این، توجه فعالان این حوزه عموما معطوف به فریم‌ورکهای چابکی و اجرای مقلدانه‌ی پرکتیس‌های پیشنهادی آنهاست. این در حالی است که اگر به ارزشها و اصول چابکی توجه بیشتری شود، می‌توان برای پرکتیس‌ها بنا به ضرورت‌های محلی، جایگزین یافت یا ساخت به نحوی که از ارزشها عدول نکرد.
اما ارزشها و اصول چابکی چیستند؟ و چرا اهمیت آنها را دست‌کم می‌گیریم؟
نکته این است که سادگی این ارزشها باعث شده که آنها را بدیهی، دم‌دستی و سهل‌الوصول بدانیم. در حالی که اینگونه نیست و می‌توان گفت که:
که «چابک» آسان نمود اول، ولی افتاده مشکل‌ها.
اگر مایلید شرحی دقیق و صحیح از ارزشهای چابکی و اصول مربوطه بدانید، پیشنهاد می‌کنم این کتاب جمع و جور را که به تازگی توسط Scott Duncan نوشته شده و مورد تایید بزرگانی چون Ben Linders, Ken Robin, Mike Cohn و Ron Jeffries است را مطالعه کنید.
https://www.infoq.com/minibooks/agile-values-principles
دانلود
دریافت فایل PDF
برای خودکارسازی تست نرم‌افزار می‌توان انواع متفاوتی از تست را به کار گرفت. از تستهای سطح پایین که برای تست قطعه کدهای نرم‌افزار نوشته می‌شوند، (Unit Test)؛ تا تست‌هایی سطح بالا که از واسط کاربری شروع می‌شوند و تست را به شکلی اجرا می‌کنند که گویا یک کاربر واقعی در حال کار با سیستم است. (End-To-End Test).
اما سوال کلیدی این است که وقت گذاشتن برای کدامیک از این انواع تست، نتیجه‌ی بهتری را عاید ما میکند؟ «هرم تست» پاسخی برای همین پرسش است.
همانطور که در شکل پیداست، بهتر این است که حجم تستهای واحد (Unit Test) بسیار بیشتر از تست‌هایی باشد که از سطح UI اجرا می‌شوند.
شاید در وهله اول اینطور به نظر برسد که تستهای UI به دلیل اینکه کل سیستم را تست می‌کنند و دقیقا همان سناریویی را اجرا می‌کنند که کاربر انجام می‌دهد، تستهای مورد اعتماد و دقیقی باشند. شاید در اویل کار، چنین وضعیتی وجود داشته باشد، اما داشتن تعداد زیادی از تستهای UI خیلی زود تیم توسعه را به دردسرهای بزرگی گرفتار می‌کنند. ابزارهای تست UI معمولا گران و با لایسنس محدود ارایه می‌شوند. به دلیل این محدودیت‌ها، تستهای UI را روی یک ماشین اجرا می‌کنند. علاوه بر این تستهای UI به نسبت دیگر انواع تست سرعت اجرای بسیار کندی دارند.
نقطه ضعف دیگر تستهای UI این است که در مقایسه با دیگر انواع تست شکننده‌تر هستند. این تستها معمولا با کوچکترین تغییر در اجزای واسط کاربری، باید دوباره ضبط شوند. به همین دلیل کار نگهداری اسکریپت‌های تست UI می‌تواند گاهی آنقدر دست و پا گیر شود که تیم توسعه از خیر اجرای تستها بگذرد.
نکته دیگری که در مورد تستهای UI باید مورد توجه قرار داد این است که اجرای این تستها معمولا تا رسیدن به یک Build موفق از سیستم به تاخیر می‌افتند و گاهی اوقات توسعه دهندگان برای اطمینان از عملکرد یک کد جدید باید منتظر بمانند تا دیگر اعضای تیم، کارشان را تا حد مناسبی پیش برده باشند. در این شرایط، رایج است که توسعه دهنده Back-End منتظر توسعه دهنده Front-End می‌ماند تا واسط کاربری پیاده‌سازی شود و پس از آن تست های UI اجرا شوند.
علاوه بر همه اینها، وقتی که یک تست UI شکست می‌خورد، تشخیص اینکه علت شکست دقیقا چه بوده است کار آسانی نیست و باید علل مختلفی را بررسی و سیستم را برای پیدا کردن علت شکست، دیباگ کرد.
ببینیم در مورد تستهای واحد (Unit
Test) وضعیت چطور است.
نوشتن تستهای واحد (Unit Test) ارزان است. فریم ورک‌های متنوعی برای نوشتن تست واحد وجود دارند که در عین برخورداری از قابلیت‌های فراوان، رایگان هم هستند.
تستهای واحد، فیدبک سریعتری به توسعه دهنده می‌دهند. توسعه‌دهنده در کمتر از چندثانیه متوجه میشود که کد یا تغییرات جدید درست کار میکند یا نه.
نگهداری تستهای واحد مشروط بر اینکه با رعایت بِه‌رَوشها نوشته شده باشند بسیار راحت‌تر است. اصلی‌ترین علت تغییر در اسکریپت‌های تست واحد زمانی است که کلاس یا کلاسهای مورد تست (Class Under Test) تغییر کنند. معمولا دامنه این تغییرات مربوط به چند کلاس محدود خواهد شد. این را مقایسه کنید با تست UI که حتی تغییر مکان یا نام یک Button می‌تواند کل سناریوی تست را بشکند.
مزیت دیگر تست واحد این است که در صورت شکست تست، تشخیص علت شکست به صورت دقیق و واضح امکان پذیر است. توسعه دهنده به راحتی می‌فهمد که کلاس یا متد خاصی (از بین هزاران کلاس یا متد) درست کار نمی‌کند و به همین دلیل، کمتر درگیر عملیات Debug خواهد شد.
هر چند برای اطمینان از کیفیت محصول و نگهداری کم هزینه‌تر آن، داشتن انواع تست خودکار ضروری است اما سرمایه گذاری و صرف وقت برای نوشتن هر نوع تست خودکار باید با توجه به نوع محصول و مزیت‌های هر کدام از انواع تست انجام شود. «هرم تست»، راهنمای خوبی برای ساخت یک سبد از انواع تست خودکار است. سبدی که مقداری کافی از هر نوع تست در آن جای گرفته است.
این بحث را در وبینار خودکارسازی تست نرم‌افزار دنبال خواهیم کرد و بیشتر با Unit Test آشنا خواهیم شد. برای کسب اطلاعات بیشتر مراجعه کنید به:
وقتی مشتری درخواست جدیدی می‌دهد، دست و دل ما می‌لرزد که نکند انجام این تغییرات، به جاهای دیگر سیستم هم گند بزند! چون سیستم بزرگ و پیچیده‌ای داریم، می‌ترسیم اینجا را تغییر دهیم و جای دیگری خراب شود و نفهمیم که خراب شده! یا وقتی بفهمیم که خیلی دیر شده! تا می‌آییم یک باگ را رفع کنیم، ۱۰ باگ دیگر ایجاد میشود! روحیه و انرژی تیم پایین آمده و جرات تغییر و دست زدن به کدهای قدیمی را نداریم!
همکارم رضا، هر روز باید قابلیت‌های جدید نرم‌افزار را دستی تست کند و مطمن شود که برای قابلیت‌های قبلی نرم افزار مشکلی به وجود نیامده است. کار هر روزش شده از این فرم به آن فرم رفتن، ورود اطلاعات تستی و کلیک پشت کلیک. کاری تکراری، وقت‌گیر و خسته کننده! ما هم باید ساعت‌ها منتظر بمانیم که کارش تمام شود و یک تایید (نه چندان دقیق) بدهد تا نسخه را منتشر کنیم! نرم‌افزار که بزرگتر میشود، تست کردنش هم سخت‌تر و خسته کننده‌تر میشود! از شما چه پنهان، از رضا شنیده‌ام که دنبال یک موقعیت شغلی بهتر می‌گردد.
ما خیلی جدی و مصمم از همان اول شروع کردیم به نوشتن تستهای خودکار. اوایل خیلی راضی بودیم و از نوشتن تست لذت می‌بردیم. الان که شش ماه از شروع پروژه گذشته، حس می‌کنیم تستهای ما دارند به بلای جدیدی تبدیل می‌شوند. خوانا نیستند؛ نگهداری‌شان سخت شده و گاهی باید ربع ساعت فکر کنیم که اصلا چرا این تست را نوشتیم یا این تست برای پاس شدن باید چه تنظیماتی را رعایت می‌کرد. برای همین هم مجبوریم بعضی از آنها را غیرفعال کنیم. و حتی بدتر از این، نمی‌توانیم به نتیجه مثبت تست‌های‌مان خیلی اعتماد داشته باشیم! یاد روزهای اول به خیر!
اپیزودهای چهارم، پنجم و . را می‌توانید حدس بزنید. شرایطی مشابه و آشنا و البته ناخوشایند و طاقت فرسا.
مجموعه وبینارهای «تست خودکار نرم افزار، از آغاز تا انجام» با این هدف ارایه می‌شوند تا موضوع تست خودکار نه تنها به عنوان یک مهارت بلکه به عنوان یک هنر، در تیم‌ها جدی گرفته شود. تست نوشتن با تستِ خوب نوشتن، متفاوت است. در قسمت اول به موضوع Unit Test پرداخته میشود.
تاریخ برگزاری: جمعه، 21 اردیبهشت، ساعت 15
کسب اطلاعات بیشتر و ثبت نام:
https://evand.com/events/softwaretesting
در رویکرد طراحی دامنه‌گرا (Domain Driven Design)، برای کنترل و غلبه بر پیچیدگی‌های فضای مسٔله، مرزهایی بین اجزای متنوع دامنه تعریف میشود که به Bounded Context مشهور است. تشخیص این مرزها و تصمیم گیری درمورد اینکه هر جزء فضای راه حل، در حوزه کدام BC قرار دارد، از جمله تصمیمات مهم و راهبردی طراحی محسوب میشود. برای درک بهتر کارکرد Bounded Context ها به شکل زیر توجه کنید:
هرچند نباید انتظار داشت که تشخیص Bounded Context ها در همان ابتدا بدون اشکال باشد، اما با بکارگیری تکنیک‌هایی می‌توان از خطاهای مهلک طراحی اولیه کم کرد، تا طراحی منطقی و منعطف‌تری داشته باشیم.
در این مطلب، نویسنده به شرح تکنیکی برای تشخیص و مدل کردن بهتر Bounded Context ها می‌پردازد. تکنیکی به نام: "Intentional Naivety First"
▫️حتی اگر با رویکرد Domain Driven Design آشنا نیستید، باز هم این مطلب واجد نکات آموختنی بسیاری است.
https://medium.com/nick-tune-tech-strategy-blog/intentional-naivety-first-bounded-context-modelling-62e6211574ec
برنامه نویسان دات نت برای بکارگیری پترن‌های DDD همواره با چالش ORM ها مواجه بوده‌اند. Entity Framework 6 به سختی از الگوهای DDD پشتیبانی می‌کرد و NHibernate هم با توجه به کاهش فعالیت توسعه دهندگانش، دیگر انتخاب چندان موجهی نیست. اما گویا این چالش با EF Core 2 به فراموشی سپرده میشود.
در این مطلب Julie Lerman توضیح می‌دهد که ORM کاملا بازطراحی شده‌ی EF Core 2 انتخاب مناسبی برای ORM دومین‌هایی است که الگوهای #DDD را به‌کار گرفته‌اند.
https://technet.microsoft.com/en-us/mt842503.aspx
پی نوشت: Julie Lerman اخیرا در کنفرانس DDD Europe 2018 ارایه‌ای داشت با عنوان:
Exploring EF Core Support for DDD Patterns
https://dddeurope.com/2018/speakers/julie-lerman/ #DDDEU
کنفرانس DDD Europe مهمترین رویداد سالانه برای علاقه‌مندان به موضوعاتی مانند Domain Driven Design, Event Sourcing, Event Storming, Microservice, CQRS است. کنفرانسی که به اعتبار سخنرانان و برگزارکنندگانش از سوی بعضی‌ها به عنوان «سوپر کنفرانس» لقب گرفته است.
امسال سومین سالیست که این رویداد جریان ساز و مهم برگزار میشود. شهر آمستردام از سی‌ام ژانویه تا دوم فوریه ۲۰۱۸، میزبان حدود ۷۰۰ نفر از شرکت کنندگانِ این کنفرانس مهم و جریان ساز است. کارگاه‌های این کنفرانس از ۲ روز پیش شروع شده‌اند و از امروز برنامه‌ی سخنرانی‌ها، با سخنرانی درخشان و تامل برانگیز پرفسور Dave Snowden با عنوان (Complex Adaptive Systems) شروع شد. از دیگر سخنرانان کلیدی این کنفرانس می توان به Eric Evans اشاره کرد.
برای پیگیری رویدادهای مرتبط با این کنفرانس می توانید هشتگ #DDDEU و یا #DDD_EU را در توییتر دنبال کنید.
تصور کنید وارد مغازه قصابی شده‌اید و به آقای قصاب سفارش یک شقه ران گوسفندی داده‌اید! حالا به ابتدای جمله برگردید! بله عرض کردم که «تصور» کنید!
جناب قصاب تند و تیز شروع به بریدن و تکه کردن گوشت میکند. شما هم منتظر ایستاده‌اید و در این خیال که به زودی چه خورشت و آبگوشت‌های لذیذی خواهید خورد، فرو رفته‌اید.
همینطور که در خیال خود شناورید، بیایید حرکات تند و تیز جناب قصاب را با سرعت آهسته تماشا کنیم. چاقوی تیزش را در حجم گوشت فرو میکند و بعد از هر دو سه برش، آن را با سوهانی که همیشه دم دستش هست، تیز میکند. این کار را به قدری سریع انجام می‌دهد که گویی جزو مراحل آماده کردن سفارش شماست. او از شما نمی‌پرسد که آیا به من وقت می‌دهید که چاقویم را تیز کنم یا نه؟!
قصاب داستان ما، به دلیل اینکه همیشه حواسش به تیز بودن چاقویش بوده و آن را مرتب تیز کرده است، دیگر نیازی ندارد که برای تیز کردن چاقویش وقت زیادی صرف کند. سه چهار بار که چاقو را به سوهان بکشد، تیز میشود. کاری که چند ثانیه بیشتر وقت نمی‌گیرد!
اگر این کار را به صورت مرتب انجام ندهد، آن‌وقت به مشتری چهارم و پنجم نرسیده، «مجبور» میشود که مشتری را «معطل» کند تا چاقوی جدیدی تهیه کند و یا با چاقوی کند و کهنه شده، با زور و تقلا کارش را پیش ببرد.
این وضعیت برای ما توسعه‌دهندگان نرم‌افزار، وضعیتی آشناست. ما معمولا وقتی برای تیز کردن چاقو نمی‌گذاریم و زمانی به فکرش می‌افتیم که چاقوی ما حسابی کند شده و خسته و فرسوده شده‌ایم.
ریفکتور (Refactor)، بخوانید تیز کردن چاقو باید جزیی از فعالیت‌های روزانه‌ی ما باشد. جوری که هیچ‌وقت نخواهیم که برای تیز کردن چاقوی توسعه، از مشتری فرصت بگیریم و وقتش را تلف کنیم. پس مثل آقای قصاب ریفکتور کنیم، هر روز، روزی چند بار.
راستی آبگوشت‌تان نوش جان!
درباره این سایت