https://virgool.io/feed/@kiarashazarnia یادگیرنده و مهندس نرم‌افزار fa 2026-06-16 18:00:12 https://files.virgool.io/upload/users/16986/avatar/ToHz8J.jpg?height=120&width=120 https://virgool.io/@kiarashazarnia https://virgool.io/@kiarashazarnia/software-artifact-active-on-boarding-guide-wjkeueffxspb چگونه خیلی خوب و سریع روی یک سرویس، آنبورد (Onboard) شویم؟آنبوردینگ همیشه و همه‌جابازار نرم‌افزار سیال و پر رفتامد است درست مثل خود نرم‌افزار! جابجایی نیروها در بین تیم‌ها و شرکت‌ها پربسامد است. امروز وارد یک تیم می‌شوید. ماه بعد تیم شما با تیم دیگری ادغام می‌شود. ماه بعدی عضو کلیدی از تیم جدا می‌شود. پررنگ‌ترین حالت این چالش، جدایی اعضای ارشد (Senior) سازمان است که در روزها و سال‌های اخیر خصوصا در بازار نرم‌افزار ایران بسیار رایج است؛ به امید روزهای بهتر برای این آب و خاک. در این نوشته می‌خواهم به یکی از مهم‌ترین مهارت‌هایی که یک مهندس نرم‌افزار به آن احتیاج حیاتی دارد اشاره کنم: مهارت تحویل گرفتن یک سرویس (Artifact).من با مسامحه از لغت آشنای سرویس بجای آرتیفکت (Artifact) استفاده کردم. منظورم هر محصول نرم‌افزاری است که در یک تیم فنی طراحی، نگهداری و توسعه داده می‌شود. راستش استفاده از معادل‌های فارسی‌اش برایم آسان نبود: دست‌ساز، مصنوع، پردازش‌ماند. بعضی از دوستان از کلمه‌ی بانمک «جنس» به عنوان معادل آرتیفکت استفاده می‌کنند!آرتیفکت شامل هر چیزی است که برای توسعه‌ی محصول تولید شده است: کد، داکیومنت‌ها، اسکریپت‌ها، سرورهای پروداکشن و ساختار استقرار فعلی (Deployment Setup) و البته مقدار زیادی دانش که به شکل نامرئی در بین اعضای تیم وجود دارد.نکته‌ی صفر! درک موقعیتدرک دقیق شرایط تیم، سازمان و جایگاه سرویس مورد نظر در این بافت، راهگشاست. از همه مهم‌تر درک شرایط صاحب (owner) قبلی سرویس است. باید درک کنیم که احتمالا در آستانه‌ی جدایی این همکار ما، دغدغه‌های بسیار متفاوتی نسبت به روزهای معمول حضورش در تیم دارد. مثلا در حال مصاحبه برای شغل جدید است، در حال مهیا شدن برای مهاجرت است، بعد از یک دوره پرفشار نیاز به استراحت دارد و در کل: ریتم عملکرد معمولش را ندارد. درک این واقعیت خیلی می‌تواند شما را در نتظیم رفتارهایتان یاری کند.نکته‌ی یک: تحویل گرفتن زودهنگامبه قول شاعر خداحافظ همین حالا، همین حالا که من تنهام!همین امروز سرویس را تحویل بگیرید حتی اگر تحویل‌دهنده‌ی عزیز قرار است یک ماه همراه تیم باشد. غفلت در این کار بسیار پرهزینه خواهد بود. اتفاقی که می‌افتد: درخواست‌های پشتیبانی و اضطراری (Emergency) یکی در پی دیگری سر می‌رسد؛ تحویل‌دهنده عملکرد پربازده (Productive) سابقش را ندارد. مثلا اگر قبلا ده واحد در روز کار تحویل می‌داد، حالا با توجه به شرایط شخصی و دغدغه‌هایش هفت واحد انرژی کاری دارد. در نتیجه بیشتر این انرژی، صرف این پشتیبانی‌ها شده و اصلا چیزی برای آنبوردینگ شما و تحویل سرویس نمی‌ماند. از همان روز اول فعالانه در جبهه‌ی اول نگهداری سرویس قرار بگیرید. هر درخواست، تیکت و فیچری باید توسط شما پیاده‌سازی شود. با این کار البته یکباره استرس زیادی به شما وارد می‌شود؛ ناگهان ریتم توسعه‌ی آن سرویس افت خواهد کرد و حتی ممکن است از همکارانتان فیدبک منفی دریافت کنید، اما این کار لازم است تا بیشترین دیتای ممکن به شما منتقل شود و هر چیزی را که نمی‌دانستید، خودتان از تحویل‌دهنده‌ی عزیز بپرسید. هر قدر ارتباط موثرتری با تحویل‌دهنده داشته باشید، هزینه‌های این دوره کاهش می‌یابد.باورم کنید؛ برگزاری یک سلسله جلسات تحویل سرویس اصلا کافی نیست بلکه پس از یکی دو جلسه، ممکن است به کل بی‌فایده باشد. بهترین ترکیب به تجربه‌ی من این است؛ جلساتی برای آشنایی اولیه و کلی با معماری سرویس، هر قدر مختصرتر بهتر؛ با پرداختن به ستاپ فعلی آن. سپس بلافاصله قرار گرفتن در جبهه اول پیشبرد سرویس و در کنار آن ادامه‌ی جلسات به درخواست و اعلام نیاز شما و نه لزوما طبق یک برنامه مشخص.شاهد ادعایم آن جاست که در نوع اول جلسات تحویل‌گیرنده نهایتا دچار توهم مسلط شدن روی همه‌ی جزئیات سرویس می‌شود، تحویل‌دهنده هم احساس می‌کند همه چیز را گفته و خدا را شکر می‌کند که این بار گران به زمین نهاده است. قول می‌دهم فردای روز خداحافظی تحویل‌دهنده فاجعه رخ خواهد داد. اما در نوع دوم به خوبی نکات مبهم برایتان روشن می‌شود و هر جلسه را با یک خروار سوال و مشورت موثر و کلیدی پیش خواهید برد.نکته‌ی دو: مستندسازیدر این شرایط به دنبال کامل‌ترین یا زیباترین روش مستندسازی نباشید. به «راحت‌ترین» روش فکر کنید. مثلا اگر قرار است دپلویمنت سرویسی را مستندسازی کنید که تماما اتومیت نیست، به راحتی با یک Screen Recorder کل فرایند را ضبط کنید. نه زحمتی برای شما ایجاد می‌کند نه برای تحویل‌دهنده. انتظار نداشته باشید با شرایطی که عرض کردم تحویل‌دهنده بنشیند و مستند کامل و جامعی برای شما بنویسد. از سویی اگر شما نیز به این کار بپردازید شاید درگیر جزئیات حاشیه‌ای شده و از متن اصلی باز بمانید. در تیم‌های چابک (Agile) معمولا ارتباط (Communication) را به مستندسازی‌های رسمی (Documentation) ترجیح می‌دهند، در نتیجه چندان نمی‌توان روی مستنداتی که تا این لحظه آماده شده است مطمئن بود و خوب است در بازه‌ی تحویل به فکر تکمیل مستندات باشید. اگر بتوانید بیشتر صدا و تصویر ضبط کنید و بعدا سر فرصت به تدوین و مکتوب کردن آن‌ها بپردازید سریع‌تر و روان‌تر پیش می‌روید.نکته‌ی سه:‌ انتقاد نه، آینده‌نگری آری!به خاطر بسپارید؛ الان وقت انتقاد از تصمیمات فنی و سازمانی تحویل‌دهنده نیست. به این مثال توجه کنید.«ای بابا... نباید از پایتون استفاده می‌کردی، بدیهیه این زبان استاتیک تایپینگ نداره و با بزرگ شدن کد بیس هزینه‌ی نگهداری رو در دراز مدت بالا می‌بره.»این جمله می‌تواند فاتحه‌ی کل داستان تحویل سرویس را بخواند. شاید با خود می‌گویید که اگر تحویل‌دهنده حرفه‌ای باشد، این را یک فیدبک فنی خواهد دید. بله قطعا! اگر تحویل‌دهنده حرفه‌ای و اخلاقمند نباشد که از ابتدا فاتحه‌ی پروژه‌ی تحویل خوانده است. مساله اصلا برخورد شخصی نیست بلکه فضایی است که این نوع نگاه می‌سازد. این نوع نگاه به مساله ناخودآگاه فضای دفاعی ایجاد می‌کند که بسیار مضر است و جلوی انتقال خالص اطلاعات را می‌گیرد و همه‌ی این اتفاقات کاملا ناخودآگاه و مستقل از اخلاق حرفه‌ای دو طرف ممکن است رخ دهد. الان وقت «ارزیابی گذشته‌» نیست، الان وقت «آینده‌نگری» است؛ به جای آن می‌توان گفت:«بسیار خوب، علت استفاده از پایتون در شروع توسعه‌ی محصول احتمالا سرعت پیاده‌سازی و رسوندن فیچر‌های ارزشمند بوده، درسته؟ لطف می‌کنی یکم بیشتر درباره‌ی فضای اتخاذ این تصمیم در آن زمان برام بگی. با توجه به مسیر طی شده، به نظرت خوبه در آینده با استفاده از ابزارهایی مثل mypy برای تایپ-سیف کردن کد-بیس برنامه‌ریزی کنیم تا هزینه‌ی نگهداری کاهش پیدا کنه؟»نوع دوم نگاه فضای ذهنی‌ای در گفتگو حاکم می‌کند که به هیچ وجه به سمت دفاعی شدن نمی‌رود بلکه اتفاقا ذهن تحویل‌دهنده ناخودآگاه سعی می‌کند درس‌هایی را که در مسیر توسعه‌ی محصول گرفته است یادآوری کند. صمیمانه چالش‌ها را بیان خواهد کرد و احیانا راهکارهای آن را نیز مطرح می‌کند. نباید فراموش کرد که هر تصمیمی در زمان خودش ممکن است کاملا بجا و درست بوده باشد و نباید با اطلاعات امروز، درباره‌ی تصمیم‌گیرندگان دیروز بدون در نظر گرفتن شرایطشان قضاوت نمود.نکته‌ی چهار: سرتان را از برف بیرون بیاورید.همه‌ی ماجرا فنی و تکنولوژی نیست. حتما جویای «تاریخچه‌ی سرویس» شوید. به لحاظ تیمی و سازمانی، بپرسید داستان این سرویس چه بوده؟ چه آدم‌هایی با چه سلیقه‌هایی چه گام‌هایی برای آن برداشته‌اند؟ سخت‌ترین پیچ‌های مسیری که تا امروز طی شده چه بوده؟ تایخچه‌ی سرویس چه به لحاظ تصمیمات معماری فنی و چه به لحاظ تصمیمات سازمانی و بین‌تیمی، به طرز حیاتی شما را در تنظیم روابطتان با تیم‌های همکار یاری خواهد کرد. مثلا فرض کنید سرویسی دارید که پس از مدت‌ها بحث و بررسی فنی، تصمیم این شده که در آن از یک ابزار ارکستریتور مثلا داکر سوارم (Docker Swarm) استفاده شود؛ اما به دلیلی شما کوبرنتیز (Kubernetes) را مناسب‌تر می‌دانید اما این مهاجرت چندان حیاتی نیست. اطلاع شما از این تاریخچه؛ این راهنمایی را به شما می‌کند که صرفه‌جویی در ظرفیت روانی تیم و نپرداختن به این موضوع در آینده‌ی میان‌مدت و بجای آن تمرکز روی بهبودهای دیگری که چنین تاریخچه‌ای ندارند، بسیار ثمربخش‌تر از اصل این تغییر خواهد بود.نکته‌ی پنج: ایجاد آگاهی راجع به مدیریت دانشهم گفتگو با تحویل‌دهنده‌ی گرامی و هم در فضای تیم و سازمان؛ راجع به مدیریت دانش و اهمیت آن در یک تیم توسعه‌ی نرم‌افزار آگاهی ایجاد کنید. متاسفانه به رغم اهمیت حیاتی این موضوع، در ادبیات فنی و دانشگاهی معمول، کمتر به آن توجه شده است. یک نقطه‌ی شروع خوب می‌تواند گفتگو راجع به مفهوم دانش درونی‌شده (Knowledge Crunching) باشد که اریک اونس در کتاب معروف توسعه‌ی دامنه‌محور (Domain Driven Design) به آن می‌پردازد: تیمی می‌تواند با ریتم خوب به توسعه‌ی دامنه‌ی مساله بپردازد که به ادبیات صحیح و مشترک و غنی از مدل و دامنه‌ی مساله رسیده باشد. اما پرداختن به اهمیت این موضوع چه مزیتی هنگام تحویل گرفتن یک سرویس ایجاد می‌کند؟ با این کار از سویی این انگیزه را در تحویل‌دهنده تقویت می‌کنید که به عنوان یک مهندس نرم‌افزار از فرصت پیش‌آمده برای ایفای این نقش و پرورش این مهارت در خودش استفاده کند و از طرفی در اعضای دیگر تیم و سازمان نیز این نگاه و آمادگی را ایجاد می‌کنید که فعالانه در دریافت و ثبت دانش مربوط به سرویس بالخصوص دانش دامنه‌ی آن مشارکت کنند.نکته‌ی پایانیخوشبختی من این بوده که همکاران حرفه‌ای داشته‌ام و همیشه در کارهای مختلف از آن‌ها درس آموخته‌ام. به هر روی این نوشته درس‌هایی است که از همه‌ی عزیزانی که روزی سرویسی را از آن‌ها تحویل گرفته‌ام، نوشتم. البته این حرف‌ها گزاره‌های علمی نیست بلکه حاصل تجربه و نگاه شخصی من است که بنا به اصل آزادی بیان آن را نوشتم. اگر با هر نکته‌ای در آن مخالفید؛ محبت می‌کنید نگاه متفاوت خود را بیان بفرمایید بلکه با گفتگوی حاصل، مخاطب به نگاه درست‌تری برسد. نوشته را با این یک شعر زیبا به پایان می‌برم چرا که احتمالا حین خداحافظی با یک همکار باتجربه، از حرف‌های من بیشتر به کارتان بیاید!خداحافظ به شرطی که بفهمی تر شده چشمامخداحافظ کمی غمگین به یاد اون همه تردیدبه یاد آسمونی که منو از چشم تو می دید- از آهنگ خداحافظ همین حالا محمد علیزاده، شعر از فرزاد حسنی کیارش آذرنیا کیارش آذرنیا Sun, 14 Aug 2022 21:00:16 +0430 https://virgool.io/@kiarashazarnia/software-performance-continuous-improvement-bgry7mvwcxxy مقدمهدر مطلب قبلی به این سوال پاسخ دادیم که «چگونه معماری نرم‌افزار را بهبود دهیم؟». در این مطلب روی یکی از جنبه‌های معماری تمرکز کرده‌ایم: کارایی (Performance). می‌خواهیم ببینیم با رویکردی که توضیح دادیم چطور می‌توان این نیازمندی کیفی مهم را بهبود داد.چطور می‌توان کارایی را اندازه گرفت؟ یک سناریوی کارایی چه شکلی است؟ در ادامه باز سراغ کتاب معماری نرم‌افزار در عمل (Software Architecture in Practice) می‌رویم و ترجمه‌ی قسمتی از آن را می‌خوانیم.کارایی از دیدگاه معماری نرم‌افزارکارایی حکایت از زمان دارد و همچنین توانایی سیستم برای ارضا نیازمندی‌های زمان‌بندی. در بیشتر تاریخ مهندسی نرم‌افزار، کارایی عامل پیشران معماری سیستم بوده است. چنان که، بارها شده است که عدم کارایی یک سامانه، سایر توانمندی‌های کیفی آن را به محاق برده است. هر قدر که نسبت «قیمت به کارایی» در سخت‌افزارها نزول کرده و هزینه‌ی توسعه‌ی یک نرم‌افزار افزایش یافته؛ شاخصه‌های کیفی دیگر در برابر شاخصه‌ی کارایی، به رقابت برخاسته‌اند. کارایی گاهی با مقیاس‌پذیری (Scalability) گره می‌خورد که بیانگر افزایش ظرفیت کاری سیستم به گونه‌ای که همچنان به خوبی عمل کند، است.باری، همه‌ی سیستم‌ها نیازمندی‌های کارایی دارند، هرچند آشکار نباشد. مانند یک ویرایشگر متنی که باید در کسر مشخصی از ثانیه تغییر را نمایش دهد وگرنه باعث آزار کاربر خواهد شد. کارایی همچنان یک شاخصه‌ی کیفیت اساسی است برای همه‌ی نرم‌افزارها.شمای مفهومی یک سناریوی کارایی برگرفته از کتاب معماری نرم‌افزار در عملالگوهای یک سناریوی کارایییک سناریوی کارایی با ورود یک رویداد به سیستم آغاز می‌شود. پاسخدهی صحیح به این رویداد نیازمند مصرف منابعی، شامل زمان، خواهد بود. همزمان با این روند،‌ سیستم ممکن است در حال سرویس دادن به رویدادهای دیگری نیز باشد.رویدادها می‌توانند با الگویی قابل پیشبینی یا یک توضیع ریاضی و یا با به شکلی غیرقابل پیشبینی وارد آیند. الگوی رویدادها می‌تواند به سه دسته‌ی متناوب، آماری و کاتوره‌ای تقسیم شود؛الگوی متناوب (Periodic): به طور منظم با یک فاصله‌ی زمانی ثابت رخ می‌دهد. الگوی متناوب بیش از همه در سامانه‌های بی‌درنگ اتفاق می‌افتد.الگوی آماری (Stochastic): بیانگر رویدادهایی است که با یک توزیع احتمالاتی مشخص رخ می‌دهند.الگوی کاتوره‌ای (Sporadic): نشانگر رویدادهایی است که نه متناوب‌اند و نه با یک توزیع احتمالاتی قابل مدل‌سازی هستند. البته گاه می‌توان قواعدی برای آن‌ها تعریف نمود؛ مثلا این که هیچ دو رویداد متوالی کمتر از صد میلی ثانیه اختلاف نخواهد داشت، هر چند چنین قواعدی مفید هستند، همچنان پیشبینی دقیقی از رویدادها به دست نمی‌‌دهند.توضیح مترجم: این تقسیم‌بندی امروز شاید کمی کلی باشد. ابزارهای جدید آزمون کارایی مثل k6 این قابلیت را دارند که با تعریف سطوح (stages) مختلف، الگوهای متنوعی (مثلا به شکل پله‌کانی) از بار کاری تولید کنند که با نگاه این کتاب همه زیرمجموعه‌ی الگوی آماری خواهد بود. ارزش این نوشته، بیشتر نگاه آن به مساله است نه لزوما راهکارهای آن.سنجه‌ی پاسخ کاراییپاسخی که سیستم به یک محرک در همبافت کارایی می‌دهد با سنجه‌های زیر قابل بیان است:تاخیر (Delay):‌ زمان ما بین ورود محرک به سیستم و تولید پاسخ آن.ضرب‌العجل‌ها (Deadline) در پردازش.گذرداد سیستم (Throughput): تعداد ترکانش‌ها در یک بازه‌ی زمانی معین.جیتر (Jitter): بازه‌ی قابل تحمل تغییرات در تاخیر.نرخ خطا (Error Rate):‌ تعداد رویدادهایی که به علت شلوغی سیستم پردازش نشدند.جمع‌بندی سناریوی کلی کاراییدر ادامه‌ی این بحث، کتاب سناریو کلی کارایی را به این نحو صورت‌بندی می‌کند:منبع تحریک: تحریک از منابع یا منابعی خارجی وارد سیستم می‌شود.محرک: رسیدن هر رویداد محرک محسوب می‌شود. الگوی محرک‌ها بر حسب زمان می‌تواند متناوب، آماری یا کاتوره‌ای باشد.سازه (Artifact):‌ کل سیستم یا بخشی است که می‌خواهیم کارایی آن را بسنجیم.محیط: سیستم می‌تواند در شرایط عملیاتی گونه‌گونی باشد؛ مانند شرایط معمولی، اورژانسی، حداکثر بار یا اضافه بار.پاسخ: سیستم باید رویداد وارد شده را پردازش کند. این پردازش ممکن است سبب تغییر در محیط شود (برای مثال ممکن است محیط از حالت بار معمولی وارد حالت اضافه‌بار شود).سنجه‌ی پاسخ: سنجه‌ی پاسخ می‌تواند زمانی باشد که صرف پردازش یک محرک می‌شود (تاخیر)، همچنین؛ تغییراتی که در تاخیر رخ می‌دهد (جیتر)، تعداد رویدادهایی که در بازه‌ی مشخصی از زمان پردازش می‌شوند (گذرداد) و در نهایت تعداد رویدادهایی که پردازش نمی‌شوند (نرخ خطا).در جدول زیر یک سناریوی عمومی کارایی تلخیص شده است:خلاصه‌ی عناصر سناریوی عمومی سنجش کارایی امیدوارم در مطالب بعدی یک مثال عملی از این رویکرد پیاده‌سازی کرده و با جزئیات بیشتر آن را توضیح دهم. کیارش آذرنیا کیارش آذرنیا Sat, 01 May 2021 20:40:20 +0430 https://virgool.io/javacup/%DA%86%DA%AF%D9%88%D9%86%D9%87-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%B1%D8%A7-%D8%A8%D9%87%D8%A8%D9%88%D8%AF-%D8%AF%D9%87%DB%8C%D9%85-paoon6ie466v چکیدهکتاب «معماری نرم‌افزار در عمل» نگاه کاربردی و جالبی به معماری دارد. این کتاب به طور خلاصه می‌گوید همه نیازمندی‌های کیفی یک نرم‌افزار مثل نگهداری‌پذیری (Maintainability) و کارایی (Performance) قابل اندازه‌گیری و بهبود است. در نگاه اول کمی دور از ذهن است، مثلا چطور می‌توان نگهداری‌پذیری را اندازه‌گیری کرد؟ کتاب پاسخ می‌دهد: کافی است با دقت به سناریوی این نیازمندی کیفی توجه کنید و با هوشمندی شاخصه‌ی‌ کیفی مورد نظر را شناسایی نمایید. نگاه این کتاب من را به یاد این جمله از لورد کلیون انداخت: «اگر نتوانی اندازه‌گیری‌اش کنی، نمی‌توانی بهبودش دهی». تصویر جمله‌ی لورد کلیوندر ادامه ترجمه‌ی قسمتی از کتاب معرفی‌شده را با هم می‌خوانیم.معماری نرم‌افزاردر چرخه‌ی تولید نرم‌افزار عوامل زیادی، نیازمندی‌های کیفی یک سیستم را تحت تاثیر می‌گذارد. این نیازمندی‌های کیفی، فراتر از نیازمندی‌های کارکردی هستند که حداقل انتظاری است که از یک نرم‌افزار می‌رود. از طرفی نیازمندی‌های کارکردی و کیفی ارتباط تنگاتنگی با هم دارند. هنگام توسعه، معمولا کارکردها در اولویت قرار می‌گیرند اما می‌دانیم این ترجیح، در حقیقت کوته‌نظرانه است. چنان که می‌بینیم سیستم‌ها بازطراحی و بازسازی می‌شوند نه به خاطر نقصان در کارکردهایی که ارائه می‌دهند، چه آن که معمولا از لحاظ کارکرد با سیستم قبلی یکسان هستند، بلکه فقط به خاطر نیازمندی‌های کیفی که به اندازه‌ی کافی ارضا نمی‌شود. برای مثال قابلیت نگهداری و تغییر کافی را ندارند، به اندازه‌ی کافی قابل انتقال (portable) نیستند یا خیلی کند هستند و کارایی کافی را ندارند و یا از امنیت (Security) لازم برخوردار نیستند.به اعتقاد ما معماری اولین جایی است که در توسعه‌ی نرم‌افزار باید نیازمندی‌های کیفی را هدف قرار دهیم. معماری نگاشت نیازمندی‌های کارکردی و کیفی است به ساختارهای نرم‌افزاری لذا تاثیر قطعی در میزان حمایت نرم‌افزار مورد نظر از نیازمندی‌های کیفی مانند کارایی خواهد داشت.حال می‌خواهیم مفهوم شاخصه‌ی کیفی را دقیق‌تر واکاوی کنیم. یک شاخصه‌ی کیفی یک ویژگی قابل اندازه‌گیری و قابل آزمون (Testable) است که نشان می‌دهد نرم‌افزار مورد نظر چقدر پاسخگوی نیازهای ذی‌نفعان است. می‌توان شاخصه‌ی کیفی را شاخصه‌ای در نظر گرفت که نشان‌دهنده‌ی میزان رضایت ذی‌نفعان از نرم‌افزار را در ابعاد گوناگون منافعشان نشان می‌دهد.شاخصه‌ی کیفی (Quality Attribute)یک شاخصه‌ی کیفی باید خوش‌تعریف و قابل آزمون باشد. کتاب «معماری نرم‌افزار در عمل» از یک فرم یکسان برای بیان همه‌ی شاخصه‌های کیفی استفاده می‌کند. مزیت این انتخاب تاکید آن بر ویژگی‌های مشترک همه‌ی شاخصه‌های کیفی است هرچند گاهی ممکن است یک جنبه‌ی کیفی کاملا در فرم مورد استفاده نگنجد و این امر سبب ایجاد اندکی دشواری در بیان آن جنبه شود. این فرم مشترک به شرح ذیل قابل بیان است:یک سناریو برای تعریف یک شاخصه‌ی کیفی۱. محرک (Stimulus)بیانگر رویدادی است که وارد سیستم می‌شود. این محرک می‌تواند در همبافت کارایی یک درخواست باشد، در همبافت کاربردپذیری یک عملکرد کاربر باشد و در همبافت امنیت یک حمله‌ی امنیتی. همچنین است وقتی در همبافت نگهداری‌پذیری صحبت می‌کنیم؛ دقیقا همین لغت برای تعریف یک انگیزه‌ی تغییر در کد به کار می‌بریم. همچنین در تغییرپذیری (Modifiability)؛ درخواستی برای تغییر در سیستم یک محرک محسوب می‌شود. محرک آزمون‌پذیری همچنین، اتمام یک مرحله از توسعه است، که نیاز به آزمون آن را ایجاد می‌کند.۲. منبع تحریک (Source of Stimulus)یک محرک حتما یک منبع تحریک دارد. منبع تحریک در نحوه‌ی برخورد بار محرک تعیین‌کننده است. مثلا وقتی یک کاربر غیرمطمئن درخواستی ارسال می‌کند پاسخ به آن متفاوت است با زمانی که منبع این تحریک یک کاربر احراز هویت شده چنین درخواستی را ارسال نموده است.۳. پاسخ (Response)هر محرکی مستلزم یک پاسخ از طرف سامانه است. پاسخ هنگامی که سخن از سامانه‌ی در حال اجراست، شامل مسئولیت‌هایی است که سیستم در قبال یک محرک بر عهده دارد. هنگامی که سخن از کد در حال توسعه است اما، پاسخ به عملی گفته می‌شود که توسعه‌دهندگان قصد انجام آن را روی آرتیفکت در حال توسعه دارند. برای مثال در آزمون کارایی، با ورود یک درخواست به مثابه اعمال محرک به سیستم، انتظار می‌رود که در زمان مناسبی درخواست پردازش شده و نتیجه‌ی آن به مثابه یک پاسخ ارسال شود. همچنین است در همبافت تغییرپذیری؛ وقتی نیازی به تغییر در کد به وجود می‌آید، به انجام رسیدن تغییر مورد نیاز در کد برنامه پاسخی است که در خور این محرک است.۴. سنجه‌ی پاسخ (Response Measure) مشخص می‌کند که آیا یک نیازمندی کیفی راضی کننده هست یا خیر. برای مثال برای کارایی اندازه تاخیر و گذرداد می‌تواند به عنوان یک سنجه‌ی پاسخ مورد توجه قرار گیرد.این چهار عنصر، قلب تعریف یک شاخصه‌ی کیفی است. اما دو تعریف مهم دیگر نیز وجود دارند:۵. محیط (Environment)مجموعه‌ای است از شرایطی که سناریو نیازمندی کیفی در آن اتفاق می‌افتد. محیط نیز در پاسخی که به یک محرک داده می‌شود تعیین‌کننده است.۶. سازه (Artifact) قسمتی از سامانه‌ است که نیازمندی مربوط به آن است. ای بسا کل سامانه سازه‌ی مدنظر ما باشد، اما گاه تنها قسمتی از سامانه به عنوان سازه مورد تمرکز قرار می‌گیرد.کتاب در ادامه شاخصه‌های کیفی عمومی را متمایز می‌کند؛ شاخصه‌های کیفی که مستقلا برای سیستمی قابل تعریف هستند در مقابل شاخص‌های کیفی اختصاصی که در یک سناریو خاص برای یک سیستم خاص تعریف می‌شوند.می‌توان شاخصه‌های کیفی را به عنوان مجموعه‌ای از سناریوهای کلی تعریف کرد. البته، برای ترجمه‌ی این سناریوهای کلی به نیازمندی‌های یک سیستم، سناریوی کلی باید خاص منظوره شود.کتاب معماری نرم‌افزار در عملدر نوشته‌های بعدی سعی خواهم کرد با چند مثال واقعی کاربست این روش را با توضیح بیشتر در عمل نشان دهم. کیارش آذرنیا کیارش آذرنیا Fri, 30 Apr 2021 12:44:43 +0430 https://virgool.io/@kiarashazarnia/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%DB%8C%DA%A9-%D8%B1%D8%A7%D9%87%DA%A9%D8%A7%D8%B1-%D8%A2%D8%B2%D9%85%D9%88%D9%86-%DA%A9%D8%A7%D8%B1%D8%A7%DB%8C%DB%8C-dpicsv3sgiij مقدمهمعمولا وقتی می‌خواهیم یک راهکار آزمون کارایی (Performance Testing) راه‌اندازی کنیم، سراغ چارچوب‌های آماده مثل JMeter و k6 می‌رویم. اگر نرم‌افزار تحت آزمون یک RESTful API باشد، همین ابزارها به خوبی پاسخ‌گوی نیاز ما خواهد بود اما گاهی مساله سخت‌تر می‌شود؛ مثلا هنگامی که سامانه‌ی شما نیازمندی کارایی خاصی دارد که ابزارهای آماده‌ی آزمون کارایی به کلی یا در نسخه‌ی رایگان خود، آن را پشتیبانی نمی‌کند. برای مثال شرایط زیر را در نظر بگیرید.نیاز دارید محصول خود را تحت بار کاری بسیار بالا (High Workload) در مقیاس چند میلیون تراکنش در ثانیه بیازمایید، نسخه‌ی رایگان k6 در زمان نوشتن این متن این امکان را پشتیبانی نمی‌کند. البته با خرید لایسنس ابری می‌توانید آن را همزمان روی چند ماشین استقرار داده و چنین باری را تولید کنید.تاخیر صدکی ۹۹٪ دقت کافی را ندارد و شما می‌خواهید با دقت ۹۹.۹٪ زمان پاسخ (Response Time) را اندازه‌گیری کنید که چارچوب‌های یادشده هیچ‌کدام چنین دقتی ندارد. در مورد JMeter که وجود باگ چشم‌پوشی هم‌دستانه (Coordinated Omission) به طریق اولی آن را از گزینه‌های مناسب حذف می‌کند.در شرایطی که ابزارهای آماده پاسخ‌گوی نیاز ما نیست، ناچاریم یک راهکار آزمون کارایی را از پایه پیاده‌سازی کنیم. در این صورت آشنایی با معماری یک ابزار آزمون کارایی نقطه‌ی شروع خوبی محسوب می‌شود. برای این کار قسمتی از کتاب «هنر آزمون کارایی اپلیکیشن» در ادامه آمده است.تصویر جلد کتاب هنر آزمون کارایی اپلیکیشنمعماری یک راهکار آزمون کاراییمعماری یک ابزار آزمون کارایی به طور معمول دارای این سازه‌هاست: مولفه‌ی اسکریپت‌نویسی (Scripting Module)مولفه‌ی مدیریت آزمون (Test Management Module)مولفه‌ی تزریق بار (Load Injector Module)مولفه‌ی تحلیل (Analysis Module)مولفه‌های اختیاری (Optional Modules)شمای مفهومی یک چهارچوب آزمون کارایی ۱. مولفه‌ی اسکریپت‌نویسی (Scripting Module)هدف این مولفه شبیه‌سازی رفتار کاربر نهایی با استفاده از کد است، حال ممکن است این شبیه‌سازی به شکل ضبط کردن فعالیت واقعی انجام گیرد یا با برنامه‌نویسی پیاده‌سازی شود. بنابراین این مولفه امکان ضبط کردن فعالیت کاربر نهایی را فراهم می‌آورد و بنا به نیاز ممکن است از پروتکل‌های میان‌افزارهای گونه‌گونی پشتیبانی کند. اجازه می‌دهد تا کد را تغییر دهیم تا مثلا با داده‌های دلخواه اجرا شود، همچنین امکان تنظیم مقیاس اندازه‌گیری زمان پاسخ را فراهم می‌آورد.توضیح این که عبارت میان‌افزار به پروتکلی اشاره دارد که اپلیکیشن از آن برای ارتباط میان کلاینت و سرور استفاده می‌کند. مثلا برای اپلیکیشن‌های تحت وب پروتکل HTTPS به عنوان میان‌افزار مفروض است.۲. مولفه‌ی مدیریت آزمون (Test Management Module)امکان ایجاد و اجرای نشست‌ها (Session) و سناریوهای مختلف را که بیانگر ترکیب‌های گوناگون رفتارهای کاربران است برای آزمون کارایی فراهم می‌آورد. این نشست‌ها هر کدام یکی از اسکریپت‌های برگزیده‌ی آزمون را انتخاب کرده و بنا به پیکربندی آزمون و استفاده از مولفه‌ی تزریق بار، بار مناسب را به سرور تحت آزمون تزریق می‌کنند.۳. مولفه‌ی تزریق بار (Load Injector Module)بار لازم را تولید می‌کنند. این کار بنا به بار مورد نیاز، معمولا از یک یا چند ایستگاه کاری (Workstation) یا سرور تولید می‌شود. هر تزریق‌کننده‌ی بار چندین کاربر مجازی تولید می‌کند تا بتواند رفتار تعداد بسیار زیادی از کاربران را تنها با استفاده از یک یا چند ماشین مجازی یا فیزیکی شبیه‌سازی نماید. طبیعتا ظرفیت‌های ماشین‌های میزبانی‌کننده از مولفه‌ی تزریق بار مثل حافظه و پردازنده‌های آن تاثیر مستقیمی روی حداکثر باری که قابل تولید است یا حداکثر تعداد کابران مجازی همزمان که قابل شبیه‌سازی باشد، دارد.۴. مولفه‌ی تحلیل (Analysis Module)این مولفه نتایج جمع‌آوری شده هر بار اجرای آزمون را تحلیل می‌کند. نتیجه‌ی این تحلیل معمولا ترکیبی است از گزارش‌هایی که به نحو خودکار تولید می‌شود و نمودارهای گرافیکی قابل تنظیم و داشبوردهای مصور دسته‌بندی‌شده. همچنین ممکن است یک سطح تحلیل تخصصی‌تر نیز پیاده شود به نحوی که نتایج را دقیق‌تر بررسی کرده و موارد نگران کننده را پررنگ کند.۵. مولفه‌های اختیاری (Optional Modules)این مولفه‌ها بنا به نیاز برای پایش (Monitoring) سرورهای دخیل در فرایند آزمون، نظارت کردن بر شبکه و یکپارچه‌سازی با نرم‌افزارهای کمکی دیگر ممکن است استفاده شوند. کیارش آذرنیا کیارش آذرنیا Sun, 25 Apr 2021 16:41:54 +0430 https://virgool.io/@kiarashazarnia/%D8%AA%D8%B9%D8%B1%DB%8C%D9%81-%D8%A7%D8%B5%D8%B7%D9%84%D8%A7%D8%AD%D8%A7%D8%AA-%D9%81%D9%86%DB%8C-%D8%A2%D8%B2%D9%85%D9%88%D9%86-%DA%A9%D8%A7%D8%B1%D8%A7%DB%8C%DB%8C-yvdfkog4zbfg اصطلاحات فنی مربوط به آزمون کاراییمقدمهیکی از مسائلی که پیرامون آزمون کارایی احساس می‌شود، تفاوت در استفاده از عبارات فنی در منابع و مقالات مختلف است. در این نوشتار با استفاده از کتاب «راهنمای آزمون کارایی نرم‌افزارهای وب» میکروسافت مروری خواهیم داشت بر مهم‌ترین تعاریف مربوط به آزمون کارایی. هرچند راهکارهای ارائه شده در این کتاب چندان بروز نیست، سعی آن در دقت و جامعیت تعاریف مفید است. اگرچه دانستن این تعاریف بیشتر برای کسانی مفید است که قصد دارند در همین باره بنویسند، در مصاحبه‌های فنی نیز بی‌کاربرد نیست! پس اگر مصاحبه‌کننده از شما پرسید «تفاوت تست استرس با تست لود چیست؟» بعد از آن که تفاوت را بر اساس یک تعریف رایج توضیح دادید، می‌توانید به این نکته اشاره کنید که این اصطلاحات باید در همبافت هر پروژه‌ای بازتعریف شود چرا که تحت تاثیر فضای سیال نرم‌افزار قرار دارد.تصویری از کتاب راهنمای آزمون کارایی اپلیکیشن‌های وببه عقیده‌ی نویسندگان این کتاب، آزمون کارایی ما را یاری می‌کند تا گلوگاه‌های سیستم را شناسایی کنیم و یک خط‌مشی برای آزمون‌های پیشرو طراحی نماییم، همچنین به تلاش‌های بهبود کارایی جهت می‌دهد و در نهایت وضعیت ما را در قبال اهداف و نیازمندی‌های طراحی‌شده برای کارایی [به عنوان معماری سامانه] نشان می‌دهد. گنجاندن آزمون کارایی در چرخه‌ی توسعه‌ی نرم‌افزار از همان مراحل آغازین، ارزش قابل‌توجهی برای پروژه ایجاد خواهد کرد. برای موفقیت یک پروژه‌ی آزمون کارایی، آزمون باید با همبافت (Context) پروژه به خوبی سازگار شده باشد تا تمرکز توسعه به مواردی که واقعا ارزش ایجاد می‌کنند هدایت شود. اگر عملکرد سیستم در شاخصه‌های کارایی قابل پذیرش نبود، طبیعتا تمرکز تیم باید به بهینه‌سازی کارایی اپلیکیشن هدایت شود تا زمانی که عملکرد سیستم به سطح قابل قبولی ارتقا یابد. همچنین برای کاهش منابع مورد نیاز اجرای نرم‌افزار نیز علاقمندیم تمرکز تیم را به بهینه‌سازی انتقال دهیم.تعاریفآزمون کارایی (Performance Testing): آزمون کارایی نوعی آزمون است که هدف آن آزمودن پاسخ‌دهی (Responsiveness)، گذرداد (Throughput)، اتکاپذیری (Reliability) و یا مقیاس‌پذیری (Scalability) یک سیستم در بار کاری (Workload) مشخص است.ظرفیت (Capacity): ظرفیت یک سیستم مقدار مجموع بار کاری‌ای که می‌تواند تحمل کند بدون آن که ملاک‌های اساسی پذیرش کارایی (Key Performance Acceptance Criteria) را نقض کرده باشد.آزمون ظرفیت (Capacity Test): آزمونی است که با اعمال بارکاری بالا روی سیستم نقطه‌ی شکست (Failure Point) آن را مشخص می‌کند. این آزمون تیم توسعه را در جهت برنامه‌ریزی برای افزایش منابع سخت‌افزاری و شبکه‌ای لازم در هنگام افزایش تعداد کاربران یاری می‌کند.آزمون سازه (Component Test): هر آزموی کارایی که یکی از سازه‌های معماری سامانه را هدف قرار داده است. مانند: سرورها، پایگاه‌داده‌ها و ...آزمون تاب‌آوری (Endurance Test): نوعی از آزمون بار است که رفتار سیستم را در بار کاری مشخص در یک بازه‌ی زمانی طولانی می‌سنجد.کاوش (Investigation): فعالیتی است بر پایه‌ی بررسی نتایج و داده‌های آزمون کارایی برای افزایش کیفیت سیستم. معمولا با اثبات یا رد یک فرضیه پیرامون یک مساله‌ی کارایی همراه است.تاخیر (Latency): معیاری است برای سنجش پاسخ‌دهی سیستم که برابر است با زمان انجام شدن یک درخواست.سنجه (Metric): مقادیری که انتظار می‌رود از یک آزمون کارایی حاصل آید مانند تاخیر، نرخ بهره‌برداری از پردازنده و حافظه.کارایی: به اطلاعاتی پیرامون زمان پاسخ، گذرداد و نرخ بهره‌برداری از منابع در یک سیستم اشاره دارد.بودجه‌ی کارایی (Performance Budget or Performance Allocation): محدودیت‌هایی که توسعه‌دهندگان در استفاده از منابع برای اجرای سیستم با آن روبرو هستند.اهداف کارایی (Performance Goal): معیارهایی کارایی که تیم توسعه‌دهندگان قصد دارند سیستم آن‌ها را ارضا کند. معمولا برای انتشار(Release) یک نسخه از نرم‌افزار تعیین می‌شوند و قابل مسامحه هستند.نیازمندی‌های کارایی (Performance Requirements): معیارهایی که به شکل مطلق و غیرقابل مذاکره و معمولا به شکل یک قرارداد یا توافق در سطح سرویس (Service Level Agreement) تعیین شده و از تیم توسعه انتظار می‌رود آن را براورده کند.بهره‌برداری از منابع (Resource Utilization): هزینه‌ای است که برای تامین منابع سیستم در پروژه مورد نیاز است. منابع اولیه در این تعریف شامل پردازنده، حافظه، دیسک، ورودی و خروجی (I/O) و شبکه است.زمان پاسخ (Response Time): سنجه‌ای است که نشان‌دهنده‌ی میزان پاسخ‌دهی اپلیکیشن در برابر درخواست‌هاست.اشباع (Saturation): به نقطه‌ای اشاره دارد که منابع به بهره‌برداری حداکثری می‌رسند.مقیاس‌پذیری (Scalability): به توانایی یک سیستم برای پاسخ دادن به بار کاری اضافه گفته می‌شود به گونه‌ای که همچنان کیفیت مناسب حفظ شود. این کار با افزایش منابع سخت‌افزاری تخصیص یافته همراه است.سناریو (Scenario): در همبافت آزمون کارایی، سناریو ترتیبی از گام‌هایی است که در اپلیکیشن اتفاق می‌افتد. یک سناریو می‌تواند از یک مورد کاربرد استخراج شود.آزمون دود (Smoke Test): اجرای اولیه‌ی آزمون کارایی است به گونه‌ای که از عملکرد صحیح سیستم اطمینان حاصل شود.آزمون تیر (Spike Test): نوعی از آزمون تنش است که با افزایش ناگهانی بار کاری سیستم در بازه‌ی زمانی کوتاه انجام می‌گیرد.پایایی (Stability): در همبافت آزمون کارایی، پایایی به اتکاپذیری کلی، استحکام، یکپارچگی کارکردی و داده‌ای، فراهمی، انسجام و یا پاسخ‌دهی سیستم در تنوعی از شرایط اشاره دارد.آزمون تنش (Stress Test): نوعی از آزمون کارایی است که قصد آن آزمودن رفتار سیستم است هنگامی که بار کاری از مقدار معمولی و مقدار شلوغی نیز بالاتر رود. هدف آزمون تنش آشکار کردن خطاهاییست که در بار کاری بالا نمایان می‌شوند. مسائلی مانند همگام سازی، شرایط مسابقه و از نشتی حافظه. در این نوع آزمون می‌خواهیم نقطه‌ضعف‌های اپلیکیشن را در بارکاری بسیار زیاد پیدا کنیم.گذرداد (Throughput): تعداد کاری که در یک واحد زمان انجام می‌شود. برای مثال: تعداد درخواست‌ها در ثانیه، تعداد فراخوانی در ثانیه، تعداد تراکنش در ثانیه.آزمون واحد (Unit Test): در همبافت آزمون کارایی، یک آزمون واحد یک واحد که زیرمجموعه‌ای معین از کد سیستم است را مورد هدف قرار می‌دهد تا سنجه‌های کارایی آن را صحت‌سنجی کند. این واحد به طور معمول از این قرار است: تابع، پردازه، روتین، متد و کلاس. به طور معمول توسط همان توسعه‌دهندگان کد پیاده‌سازی می‌شود.بهره‌برداری (Utilization): در همبافت کارایی، بهره‌برداری درصدی از زمان است که منبع مورد نظر مشغول سرویس دادن به یک درخواست است. باقی زمان به عنوان زمان بیکاری در نظر گرفته می‌شود.آزمون صحت‌سنجی (Validation Test): یک آزمون صحت‌سنجی محصول مورد نظر را تحت شرایط مشخص‌شده می‌آزماید تا از برآورده شدن انتظاراتی که از محصول مورد نظر می‌رود، اطمینان حاصل کند.بار کاری (Workload): بار کاری محرکی است که به سیستم، اپلیکیشن یا سازه‌ی مورد نظر وارد می‌آید تا مطابق الگوی استفاده، از لحاظ همروندی و یا داده‌های ورودی، مورد آزمایش قرار گیرد. بار کاری شامل این موارد است: تعداد کل کاربران، تعداد کاربران همزمان فعال، حجم داده و حجم تراکنش‌ها (Transactions) در یک ترکیب تراکنشی. در مدلسازی کارایی، باید توصیف بار کاری با یک سناریو مشخص همراه شود. کیارش آذرنیا کیارش آذرنیا Sun, 25 Apr 2021 13:30:58 +0430 https://virgool.io/@kiarashazarnia/%D9%BE%D8%A7%DB%8C%D8%B4-%D8%AF%D8%B1-%D8%A2%D8%B2%D9%85%D9%88%D9%86-%DA%A9%D8%A7%D8%B1%D8%A7%DB%8C%DB%8C-c8udlpdxvggx Importance of Monitoring in Performance Testingفرض کنید یک آزمون تنش (Stress Test) انجام داده‌اید و بر خلاف پیشبینی سامانه نتوانست بار هزار کاربر همزمان را تحمل کند. مشکل از کجاست؟ برای پیدا کردن مشکل از وارسی شرایط سامانه حین آزمون شروع می‌کنیم. مثلا به دنبال پاسخ این سوال می‌رویم: آیا پردازنده اشباع شده بود یا حافظه؟ برای پاسخ به این گونه سوالات و ریشه‌یابی علت شکست آزمون (Root Cause Analysis) باید حتما سنجه‌های مهم سامانه، حین آزمون پایش شود. برای بیان اهمیت این موضوع گوشه‌ای از کتاب خواندنی «مهندسی اتکاپذیری سامانه؛ چگونه گوگل سیستم‌های پروداکشن خود را اجرا می‌کند» را در ادامه آورده‌ام. هرچند این کتاب به مساله‌ی پایش حین اجرا به شکل عمومی پرداخته است، مطالب آن حین اجرای آزمون کارایی نیز به طریق اولی صادق است.تصویری از کتاب مهندسی اتکاپذیری سامانهدلایل بسیاری وجود دارد که پایش سیستم را ایجاب می‌کند:۱- تحلیل روندهای طولانی‌مدت حجم پایگاه داده‌ی من چقدر است و با چه سرعتی در حال رشد است؟ روزانه چند کاربر فعال داریم و نرخ رشد آن چقدر است؟۲- مقایسه در طول زمان یا بین گروه‌های آزمایشیآیا با تغییر ایجاد شده در تنظیم دیتابیس کوئری‌های پایگاه‌داده سریع‌تر شده‌اند؟ با افزودن یک گره خارجی به کش (Cache) نرخ موفقیت کش افزایش یافته است؟ آیا سامانه نسبت به هفته‌ی پیش کندتر شده است؟۳- هشداردهیما به سطوح مختلفی از هشدار احتیاج داریم. چیزی از کار افتاده است، یک نفر باید همین الان درستش کند! یا چیزی در حال خرابی است، یک نفر باید هر چه سریع‌تر به آن بپردازد.۴- ساختن داشبوردهاداشبوردها ابزاری هستند که اطلاعات پایه‌ای را راجع به سرویس ما نمایش می‌دهند.۵- خطایابی یا انجام تحلیل‌های گه‌گاهی عمیقتاخیر ما همین الان بسیار زیاد شد؛ چه چیز دیگری در همین زمان رخ داده و ممکن است مربوط به آن باشد؟با نگاهی که از مهندسان گوگل وام گرفتیم، اهمیت پایش سامانه تحت آزمون کارایی مشخص شد. حال اگر این پایش به شکل یکپارچه با راهکار آزمون کارایی باشد، چه بهتر! اما حتی اگر این امکان وجود نداشت، همچنان نباید از خیر راه‌اندازی یک راهکار پایش برای ثبت و دیداری‌سازی سنجه‌های کلیدی سامانه بگذریم وگرنه در تحلیل نتایج آزمون کارایی بینش کاملی از رفتار سامانه نخواهیم داشت. کیارش آذرنیا کیارش آذرنیا Sat, 24 Apr 2021 14:04:53 +0430 https://virgool.io/javacup/httpsvirgooliokiarashazarniaperformance-driven-development-rud4tmrofrzl مقدمهفرایندهای متنوعی برای توسعه‌ی نرم‌افزار موجود است. بعضی‌ را احتمالا بیشتر شنیده‌ایم مثل توسعه‌ی آزمون‌گرا (Test Driven Development)، بعضی‌ را کمتر مثل توسعه‌ی ویژگی‌گرا (Feature Driven Development). توسعه‌ی کارایی‌گرا نیز یک فرایند برای توسعه‌ی نرم‌افزارهایی است که کارایی (Performance) در آن‌ها اولویت اول است. پس اگر در تیم توسعه‌ی یک پیام‌رسان، یک هسته‌ی بانکی با تراکنش بالا یا هر نرم‌افزار دیگری هستید که کارایی در آن مهم‌ترین گلوگاه موفقیت محصول است، حتما مخاطب این نوشته هستید. برای شناخت این فرایند، ابتدا ترجمه‌ی قسمتی از کتاب آموزنده‌ی هنر آزمون کارایی اپلیکیشن (The Art of Application Performance Testing)، نوشته‌ی یان مالینو را آورده‌ام و سپس نکاتی را که مفید می‌دانستم، افزوده‌ام.شما از نظر بلوغ آزمون کارایی در چه سطحی هستید؟مالینو در فصل اول کتاب از مفهوم «بلوغ آزمون کارایی» و تاثیر آن در کیفیت عملکرد نرم‌افزار سخن به میان می‌آورد. او با استناد به تحقیقی که در سال ۲۰۰۶ توسط فارستر انجام شده است به این مساله می‌پردازد. در این مطالعه از ملاک عددی «درصد مشکلات کارایی که در محیط پروداکشن نمایان می‌شوند نسبت به تعداد کل مشکلات کارایی» برای سنجش کیفیت استفاده شده است. همچنین سه سطح در آزمون کارایی تعریف می‌شود: آتش‌نشانی، صحت‌سنجی کارایی و توسعه کارایی‌گرا.سطوح بلوغ آزمون کاراییسطح اول: آتش‌نشانیآنچنان که می‌بینید سه سطح بلوغ آزمون کارایی تعریف شده است. اولی آتش‌نشانی است؛ وقتی اتفاق می‌افتد که هیچ آزمون کارایی‌ای قبل از استقرار (Deployment) اپلیکیشن انجام نگیرد یا به حد کافی نباشد، بنابراین همه مشکلات کارایی در محیط زنده‌ی پروداکشن نمایان می‌شوند. این رویکرد بدترین گزینه است اما به طرزی شگفت‌آور، همچنان نسبتا رایج است. شرکت‌های این چنین، خود را در معرض ریسک جدی قرار می‌دهند. البته با توجه به هزینه‌ای که آزمون کارایی در ابتدای کار برای تیم به بار می‌آورد، برخی مواقع این انتخاب اقتصادی است؛ مخصوصا اگر در ابتدای راه، کارایی گلوگاه سامانه نیست.سطح دوم: صحت‌سنجی کاراییسطح دوم، صحت‌سنجی کارایی شرکت‌هایی را شامل می‌شود که برای آزمون کارایی وقت کنار می‌گذارند اما نه تا آخرین مراحل چرخه‌ی عمر اپلیکیشن؛ بنابراین، همچنان تعداد قابل توجهی از مشکلات در پروداکشن رخ می‌دهد. این رویکرد در حال حاضر رایج‌ترین رویکرد سازمان‌هاست. اگر در تیم شما هم قبل از یک استقرار مهم که شامل تغییرات زیادی در سیستم می‌شود، محیط پروداکشن را شبیه‌سازی نموده و برای اطمینان از اوضاع یک آزمون کارایی اجرا می‌کنید، در سطح دوم بلوغ آزمون کارایی قرار دارید. خبر خوش آنکه احتمالا از ۷۰٪ مشکلات کارایی قبل از استقرار اطلاع می‌یابید اما همچنان ۳۰٪ مشکلات کارایی شما را در پروداکشن غافل‌گیر خواهد کرد.سطح سوم: کارایی‌گرابالاترین سطح بلوغ آزمون کارایی، توسعه‌ی کارایی‌گراست به این معنا که مسئولیت نیازمندی‌های کارایی در هر مرحله از چرخه‌ی حیات نرم‌افزار به رسمیت شناخته شده باشد. در نتیجه، تنها تعداد اندکی از مشکلات کارایی در محیط استقرار کشف خواهد شد. این رویکردی است که شرکت‌ها باید روش آزمون کارایی خود با آن سازگار نمایند مخصوصا اگر کارایی مهم‌ترین گلوگاه فنی سیستم آن‌هاست. جدول نتایج: مالینو ادعا می‌کند که برای انتشار ویرایش جدید کتابش، شخصا مطالعه مشابهی را در سال ۲۰۰۹ انجام داده است اما نتایج تغییر چندانی نکرده است. توسعه‌ی کارایی‌گراحال که از مرور کتاب فارغ شدیم، قدری با فراغ بال بیشتر ادامه می‌دهیم. البته ادعا نمی‌کنم پیشینه‌ی عبارت توسعه‌ی کارایی‌گرا به همین مقدار محدود می‌شود. به نظر می‌رسد بیشتر ادبیات حول موضوع آزمون کارایی توسط توسعه‌دهندگان و در فضای صنعت رشد یافته است نه توسط محققین دانشگاهی. به هر حال، مالینو سعی کرد با طرح کردن مفهوم بلوغ آزمون کارایی، کارایی‌گرایی را چنین توضیح دهد:باید اهمیت نیازمندی‌های کارایی در هر مرحله از چرخه‌ی حیات نرم‌افزار به رسمیت شناخته شود.با مرور این جمله می‌توانیم بگوییم توسعه‌ی کارایی‌گرا همان توسعه‌ی آزمون‌گرا (TDD) است، فقط این بار اختصاصی‌تر شده و اهمیت «آزمون کارایی» در آن پررنگ‌تر شده است. این نگاه البته خلاقیت من نیست و دیگران نیز راجع به آن صحبت کرده‌اند، برای مثال می‌توانید این نوشته‌ی خواندنی را ببینید.شمای مفهومی مراحل چرخه‌ی توسعه‌ی کارایی‌گرابه عنوان جمع‌بندی اگر چالش‌های کارایی برای نرم‌افزاری که در حال توسعه‌ی آن هستید حیاتی است، یعنی چالش‌هایی از این جنس:آیا سیستم می‌تواند به صد هزار درخواست در ثانیه پاسخ دهد؟ (Throughput)آیا می‌تواند تضمین کند ۹۹٪ درخواست‌ها در کمتر از ۱ ثانیه پاسخ می‌گیرند؟ (Latency)آیا با افزایش کاربران می‌تواند مقیاس یابد؟ (Scalability)و هر سوال دیگری که با کارایی سر و کار دارد.در این صورت شما با یک سیستم با اولویت نیازمندی کارایی روبرو هستید و خوب است به رویکرد توسعه‌ی کارایی‌گرا نگاهی داشته باشید. البته این فرایند بسیار پرچالش است اما قطعا این چالش‌ها برای یک تیم متخصص و با انگیزه، جذاب، هیجان‌انگیز و مملو از یادگیری است. در پایان به تعدادی از چالش‌های این فرایند اشاره می‌کنم تا فرصتی باشد برای جستجوها، مطالعه‌ها و شاید نوشته‌های بعدی.سنجه‌های اصلی کارایی سیستم ما چیست؟ گذردهی برای ما مهم‌تر است یا تاخیر؟چطور این سنجه‌ها را اندازه‌گیری کنیم و از دقت اندازه‌گیری خود مطمئن شویم؟چطور آزمون کارایی را در خط لوله‌ی یک‌پارچه‌سازی (CI Pipeline) خودکار سازی کنیم؟چطور نتایج آزمون را به نحوی ذخیره‌سازی کنیم تا با آزمون‌های قبلی قابل مقایسه باشد؟کدام رویکرد آزمون کارایی مناسب نیاز ماست؟ Load Test یا Stress Test یا رویکردهای دیگر؟پی‌نوشتبرای ترجمه‌ی Performance Driven Development به «توسعه‌ی کارایی‌گرا» گزینه‌های دیگری هم مطرح بود. مثلا در ویکیپدیا از عبارت «توسعه‌ی آزمون‌محور» برای Test Driven Development استفاده شده است که به نظر من مناسب نیست، عبارت «محور» چون «دوران حول یک محور» را تداعی می‌کند اندکی رهزن است؛ در این صورت «کیفیت» و «ارزش» محور است و نه روش. «کارایی‌گرا» را ترجیح دادم؛ کوتاه است و ساده. اما همچنان پذیرای پیشنهادهای بهتر هستم چرا که به نظرم فرایند ترجمه، مستلزم حوصله و دقت است و به مرور بهینه‌ می‌شود؛ مثل صیقل خوردن سنگ‌های رودخانه! کیارش آذرنیا کیارش آذرنیا Mon, 05 Apr 2021 13:52:10 +0430 https://virgool.io/@kiarashazarnia/%DA%86%D9%87-%DA%A9%D8%B3%DB%8C-%D8%A8%D9%87-%DB%8C%DA%A9-%D9%85%D8%B9%D9%85%D8%A7%D8%B1-%D9%86%DB%8C%D8%A7%D8%B2-%D8%AF%D8%A7%D8%B1%D8%AF-acggncgrbwsk عنوان مقاله‌ی فاولر که در سال ۲۰۰۳ منتشر شده است.مقدمه‌ی ترجمه در این نوشتار فاولر سعی دارد به تعریف دقیقی از معماری نرم‌افزار برسد و ویژگی‌های یک معمار خوب را بر این اساس بیان کند. علی رغم تغییرات زیاد فضای نرم‌افزار از زمان نگارش مقاله تا امروز، مطلب همچنان خواندنی است و نکات مهمی برای آموختن دارد. هر جا که ممکن بود معادل فارسی گویا نباشد عبارت انگلیسی را هم آورده‌ام. برای ترجمه صحیح عنوان مقاله خیلی فکر کردم و نهایتا به این نتیجه رسیدم که عنوان حاضر از ترجمه‌ی کلمه به کلمه‌ی «چه کسی به یک معمار نیاز دارد؟» مناسب‌تر است. علت ترجمه، اشتراک دغدغه‌ی شخصی‌ام درباره‌ی درک جایگاه معمار در تیم توسعه بود.چندی پیش در حالی که داشتم با سرخوشی از راه‌رو پایین می‌رفتم، همکارم دیو رایس را با پریشان‌حالی خاصی دیدم. سوال کوتاهم جواب دندان‌شکنی گرفت؛ دیگر نباید با هیچ‌کس با عنوان معمار در رزومه مصاحبه کنیم!در برخورد اول،‌ این حرف سابقه‌داری بود،‌ چون ما همیشه دیو را به عنوان یکی از معماران رهبری‌کننده‌ی خود می‌شناختیم، اما در ورای این جمله، حقایق بسیار مهمی نهفته بود.علت این لقب هراسی، این واقعیت بود که با وجود استانداردهای صنعت ما، عناوین معمار و معماری به طرز وحشت‌ناکی دست‌مالی شده‌اند. برای بسیاری عنوان معمار نرم‌افزار کاملا با تصویر کاراکتر مغرور و کنترل‌کننده‌ی پایان فیلم ماتریکس (Matrix Reloaded) تطابق دارد. حتی در شرکت‌هایی که بیشتر از همه این نقش را مسخره می‌کنند، یک جایگاه حیاتی برای رهبری فنی وجود دارد که بر عهده‌ی یک معمار مانند دیو است.شخصیت معمار در فیلم ماتریکسمعماری چیست؟وقتی داشتم روی عنوان Patterns of Enterprise Application Architecture – کتابی از نویسنده همین مقاله – با خودم کلنجار می‌رفتم،‌ هرکسی آن را بررسی می‌کرد تایید می‌کرد که عبارت معماری برای عنوان آن مناسب است. اما همچنان من در تعریف این عبارت احساس عدم اعتماد به نفس می‌کردم. از آن‌جایی که بحث کتابم در میان بود، خودم را وادار کردم تا برای تعریف آن اقدام جدی کنم.در اولین حرکت با کنار گذاشتن شکاکیتم از نگاه فازی صرف نظر کردم. از یک نظر معماری را لغتی تعریف کردم که وقتی می‌خواهیم از طراحی حرف بزنیم از آن استفاده می‌کنیم فقط با این تفاوت که می‌خواهیم آن را باد کنیم تا مهم‌تر به نظر برسد. (بله، حق دارید همین پدیده را مشابها برای عنوان ‌معمار‌ متصور شوید). به هر حال،‌ همیشه در زنگار شکاکیت پرتوی حقیقت نهفته است. بالاخره وقتی داشتم نوشته‌ی رالف جانسون (Ralph Johnson) را در گروه ایمیلی Extreme Programming می‌خواندم، فهم برایم حاصل شد. خوب است که همه‌ی آن را نقل قول کنم:گروه RUP که در حال کار روی تعاریف IEEE هستند، معماری را این گونه تعریف می‌کند: «بالاترین سطح مفهوم یک سیستم در محیط (environment) آن. معماری یک سیستم نرم‌افزاری (در یک نقطه زمانی مشخص) سازمان‌دهی یا ساختار مهم‌ترین اجزای سازنده‌ی (components) آن است که از طریق رابط‌هایی (interfaces) با هم در ارتباط هستند، این اجزای سازنده به نوبه‌ی خود از اجزا و رابط‌های کوچک‌تری تشکیل شده‌اند».جانسون ادامه می‌دهد:من یکی از ناظران استاندارد IEEE بودم که از آن استفاده می‌کرد و مشاجره‌ی بی‌نتیجه‌ای کردم که به وضوح این تعریف قلابی است. هیچ بالاترین سطح مفهومی از سیستم وجود ندارد. کاربران و توسعه‌دهندگان سیستم فهم کاملا متفاوتی از آن دارند. کاربران به هیج وجه اهمیتی به ساختار اجزای سازنده‌ی اساسی سیستم نمی‌دهند. پس شاید یک معماری بالاترین سطح مفهوم سیستم از نگاه توسعه‌دهندگان در محیط آن باشد. حال بیایید توسعه‌دهندگانی که تنها بخش کوچک خودشان را متوجه می‌شوند کنار بگذاریم. معماری می‌شود بالاترین سطح مفهوم سیستم از نگاه توسعه‌دهندگان متخصص. چه چیزی باعث می‌شود یک بخش سازنده‌ی سیستم مهم باشد؟ مهم است چون توسعه‌دهندگان متخصص این طور می‌گویند.بنابراین یک تعریف بهتر می‌تواند این باشد: «در بیشتر پروژه‌های موفق نرم‌افزاری، توسعه‌دهندگان متخصص که در حال پیشبرد آن پروژه هستند، یک فهم مشترک از طراحی سیستم دارند. این فهم مشترک معماری نامیده می‌شود. این فهم شامل اجزای سازنده‌ی سیستم و نحوه‌ی تعامل آن با واسط‌ها می‌شود. این اجزای سازنده معمولا از اجزای کوچکتری ساخته شده‌اند، با این توضیح که معماری تنها شامل اجزایی می‌شود که توسط توسعه‌دهندگان تایید شود».این تعریف بهتری است زیرا روشنگر این واقعیت است که معماری یک برساخت اجتماعی است (خوب، نرم‌افزار هم این‌گونه است، اما معماری حتی بیشتر) چون فقط به نرم‌افزار وابسته نیست، بلکه به آن بخش نرم‌افزار که گروه متخصصان روی اهمیت آن اجماع دارند وابسته است.یک شیوه‌ی دیگر هم برای تعریف معماری وجود دارد که می‌گوید «معماری مجموعه‌ای از تصمیمات طراحی است که باید در ابتدا پروژه انجام شوند». من با این تعریف هم مخالفت کردم. معماری تصمیماتی است که تو آرزو داری کاش می‌توانستی به درستی در ابتدای پروژه اتخاذ کنی، اما لزوما به نظر نمی‌رسد که چنین اتفاقی بیافتد.بگذریم. در این تعریف دوم، انتخاب زبان برنامه‌نویسی باید یکی از تصمیمات معماری بیشتر پروژه‌ها باشد در حالی که در تعریف اول چنین نیست.این که چیزی یک تصمیم معماری محسوب شود بستگی به نظر توسعه‌دهندگان آن دارد. برای مثال آدم‌هایی که اپلیکیشن سازمانی‌ (Enterprise Application) می‌سازند معتقدند که مانایی (persistance) یکی از بخش‌های حیاتی است. وقتی آن‌ها شروع به کشیدن نمودار سیستم خود می‌کنند با یک مدل سه لایه آغاز کرده و توضیح می‌دهند «و ما برای لایه داده‌ها (persistance) از دیتابیس اوراکل استفاده خواهیم کرد و تصمیم داریم لایه تناظر اشیای دامنه و جداول را (object mapping) خودمان پیاده‌سازی کنیم». اما یک نرم‌افزار تصویربرداری پزشکی که ممکن است از دیتابیس اوراکل استفاده کرده باشد بدون این که آن را بخشی از معماری آن بدانیم. چرا؟‌ چون پیچیدگی اصلی این اپلیکیشن پردازش تصویر است نه ذخیره‌سازی آن. در چنین سیستمی خواندن و نوشتن تصاویر توسط بخش کوچکی از اپلیکیشن انجام خواهد شد به همین خاطر بیشتر توسعه‌دهندگان از آن صرف نظر می‌کنند.با این اوصاف این که از آدم‌ها بخواهیم که معماری خود را توضیح بدهند کار سختی‌ست. «به ما بگو چه مهم است؟» معماری یعنی چیزهای مهم، هر چه که باشد!نقش معمارحال که روی این تعریف که معماری یعنی چیزهای مهم توافق کردیم، پس معمار کسی است که نگران چیزهای مهم است. اینجاست که به تفاوت ماهیت معمار از نوع فیلم ماتریکس و معماری که دیو رایس نماد آن است پی می‌بریم.معمار ریلودوس (Architectus Reloadus) کسی است که همه‌ی تصمیمات مهم را می‌گیرد. معمار این کار را می‌کند چرا که ظاهرا یک آدم عاقل باید حواسش به حفظ شدن یکپارجگی مفهومی سیستم باشد و البته احتمالا به خاطر این که معمار اعضای تیم را دارای مهارت کافی برای اتخاذ تصمیمات مهم نمی‌داند. بعضا اول باید این تصمیمات گرفته شوند تا هر کسی نقشه‌ی راهی داشته باشد [مترجم: ریلودوس را فاولر از نام فیلم ماتریکس ریلودد برداشته است].معمار اوریزوس (Archetectus Oryzus) گونه‌ی دیگری از جانوران است (اگر نمی‌توانید حدس بزنید این لینک را ببینید). [مترجم: اینجا فاولر لینک یک دیکشنری آنلاین لاتین را گذاشته. اریزوس در لاتین به معنای برنج است که فاولر به طنز آن را از نام دوست معمار خود دیو رایس Rice اقتباس کرده است.] این گونه‌‌ی معمار باید خیلی از این که پروژه در چه حال است آگاه باشد، مراقب مساله‌های مهم باشد و با آن‌ها دست و پنجه نرم کند تا تبدیل به مشکلات جدی نشوند. وقتی چنین معماری دیدم،‌ جالب توجه‌ترین فعالیتش همکاری کردن بسیار زیاد با دیگران بود. صبح که او را میدیدم مشغول کدزنی با یک برنامه‌نویس بود که طبق معمول سعی داشت یک کد قفل‌شده را به نتیجه برساند. بعد از ظهر که او را می‌دیدم که داشت در یک جلسه‌ی نیازسنجی مشارکت می‌کرد، سعی داشت تبعات فنی ایده‌های آن‌ها را با زبانی ساده و غیرتخصصی روشن کند – مثلا این که توسعه هزینه دارد.از بسیاری از جهات، مهم‌ترین فعالیت معمار اوریزوس در واقع مربی‌گری تیم توسعه است تا رشد کنند و بتوانند مساله‌های پیچیده‌تری را حل کنند. بهبود توانایی تیم توسعه تکیه‌گاه بسیار بهتری به معمار می‌دهد در مقایسه با این که معمار تک‌روی‌کننده همه‌ی تصمیمات را خودش بگیرد و خودش به یک گلوگاه معماری (architectural bottleneck) تبدیل شود. این واقعیت ما را به یک قاعده‌ی سرانگشتی راضی‌کننده می‌رساند:ارزش معمار با تعداد تصمیماتی که شخصا اتخاذ می‌کند نسبت معکوس دارد.اخیرا در جلسه‌‌ای‌ که در ThoughtWorks داشتیم با تعدادی از همکاران راجع به چالش‌های معمارها گفتگو می‌کردیم. جالب بود که سریع روی این که طبیعت شغل معمار باید شبیه معمار اوریزوس باشد به توافق رسیدیم اما نتوانستیم یک اسم رویش بگذاریم. معمار ریلودوس خیلی برایمان آشناتر بود. مایک تو (Mike Two) بهترین نامی که تا به حال شنیدم را مطرح کرد: راهنما، مثل راهنمای کوه‌پیمایی. یک راهنما یک هم‌تیمی باتجربه‌تر و ماهرتر است که به بقیه‌ی هم‌تیمی ها یاد می‌دهد چطور بهتر از پس کارها بربیایند و همیشه برای مسایل خاص حاضر است.خلاص شدن از شر معماری نرم‌افزارمن عاشق شروع با یک عنوان درخشانم عالی‌تر می‌شود وقتی منظور مهمی هم از آن داشته باشم، مثل همین مقاله که هنوز آشکار نشده است. تعریف دوم جانسون را در نظر بگیرید: «معماری تصمیماتی است که آرزو می‌کردی کاش می‌شد همان اول پروژه به درستی اتخاذ کنی». چرا مردم می‌خواهند چیزی را همان اول پروژه به درستی به انجام برسانند؟‌ پاسخ البته این است: چون درک می‌کنند که تغییر دادن آن‌چیزها در ادامه بسیار سخت است. احتمالا حالا به این نتیجه رسیدید که معماری را این‌گونه تعریف کنید: «چیزهایی که آدم‌ها تغییر دادنشان را سخت می‌دانند».باور رایج بر این است که اگر دارید یک اپلیکیشن سازمانی را پیاده‌سازی می‌کنید باید همان اول شمای پایگاه داده را طراحی کنید چون بعدا تغییر دادن آن سخت است – مخصوصا اگر نرم‌افزار تحت استفاده‌ی کاربران قرار گرفته باشد. در یکی از پروژه‌های ما، مدیر دیتابیس (database administrator)، پارمد سالژ (Pramod Sadlage)، سیستمی ابداع کرده بود که ما را قادر می‌ساخت به آسانی شمای پایگاه داده را تغییر بدهیم (و داده‌های قبلی را نیز به شمای جدید انتقال بدهیم). با این کار، او باعث شده بود دیگر شمای دیتابیس برای ما بخشی از معماری نباشد. من این عمل را عالی می‌دانم چون به ما این امکان را می‌داد که بهتر تغییر را مدیریت کنیم.در یک سخنرانی جذاب در کنفرانس XP 2002، Enrico Zaninotto، یک اقتصاددان، ایده‌های زیربنایی چابکی در تولید و در توسعه نرم‌افزار را تحلیل کرد. جنبه‌ای که برای من واقعا جالب بود این دیدگاه او بود که برگشت‌ناپذیری (Irreversibility) یکی از منابع اصلی ایجاد پیچیدگی است. او روش های چابک (agile methods) را رویکردی در محدود کردن پیچیدگی می‌بیند که سعی دارد با کاهش برگشت‌ناپذیری با منابع ایجاد پیچیدگی بجنگد. از این رو من معتقدم یکی از مهم‌ترین وظایف یک معمار، حذف معماری است. او باید راهی بیابد تا با کوچک کردن معماری برگشت‌ناپذیری را در طراحی نرم‌افزار کاهش دهد.باز به سراغ جانسون می‌رویم، این بار در جواب ایمیلی که برای او فرستادم:یکی از تفاوت‌های معماری ساختمان و معماری نرم‌افزار این است که بسیاری از تصمیمات مربوط به ساختمان به سختی قابل تغییرند. بسیار سخت است که برگردی و زیربنای خود را تغییر دهی، هرچند ممکن است.هیچ دلیل نظری (theoretical) برای سخت بودن تغییرات در نرم‌افزار وجود ندارد. اگر هر یک از جنبه‌های نرم‌افزار را به تنهایی در نظر بگیری، به راحتی قابل تغییر است، اما بلد نیستیم همه‌چیز را قابل‌تغییر پیاده‌سازی کنیم. ایجاد سهولت تغییر در یک بخش سیستم باعث افزودن اندکی پیچیدگی به کل سیستم می‌شود و در نتیجه این که بخواهی همه‌چیز را قابل تغییر طراحی کنی کلیت سیستم بسیار پیچیده می‌شود. پیچیدگی چیزی است که تغییر نرم‌افزار را دشوار می‌کند. این جاست که دور (duplication) رخ می‌دهد.ایده‌ی برنامه‌نویسی جنبه‌گرا (Aspect-Oriented Programming) اینجاست که اهمیت می‌یابد. ما تکنیک‌های قدرتمندی برای جدا کردن جنبه‌های مختلف یک برنامه داریم در حالی که از آن استفاده نمی‌کنیم. گمان نمی‌کنم مشکل اصلی ما با یافتن تکنیک‌های بهتر برای جداسازی جنبه‌ها حل شود. ما نمی‌دانیم کدام جنبه‌هاست که باید از یکدیگر جدا شود و ما نمی‌دانیم کی این جداسازی می‌ارزد و کی نمی‌ارزد.نرم‌افزار مثل ساختمان محدودیت فیزیکی ندارد. محدودیت‌های نرم‌افزار قوه‌ی تخیل، طراحی، و سازمان‌دهی ماست. خلاصه‌ی کلام، نرم‌افزار با ویژگی‌های آدم‌ها محدود شده است نه با ویژگی‌های جهان. «ما دشمن را شناسایی کردیم، او خود ماییم.»لینک وبلاگ مارتین فاولر در ادامه موجود است. اصل مقاله را می‌توانید اینجا ببینید. https://martinfowler.com/ کیارش آذرنیا کیارش آذرنیا Sun, 12 Apr 2020 07:57:57 +0430