نوشته های امید آرام - توسعه دهنده نرم افزار

۰۳ - معرفی نسخه SAP R/3

امید آرام - توسعه دهنده نرم افزار — Thu, 03 Jul 2025 14:53:30 +0330

اولین محصول شرکت SAP یک سیستم حسابداری مالی (Financial Accounting) بود که در سال 1972 با نام R/1 منتشر شد. روی mainframe اجرا میشد و معماری تک-لایه ای داشت. هدف شون توسعه یک سیستم استاندارد بود برای پردازش بلادرنگ داده ها (Real-time data processing). حرف R در این نامگذاری هم به همین خاطر بود. سال 1979 نسخه دوم رو بنام R/2 منتشر کردن که همچنان روی mainframe بود ولی معماریش دو-لایه بود و امکانات بیشتری داشت مثل فروش (Sale) و مدیریت مواد (Material Management). تا اینکه در سال 1992، یعنی حدوداً بیست سال بعد از اولین نسخه، SAP نسخه R/3 رو منتشر کرد که یک تحول بزرگ به حساب میومد. دیگه خبری از mainframe نبود و روی چند پلتفرم قابل اجرا بود. یک معماری کلاینت-سروری (client-server) داشت و امکانات سیستم در قالب ماژول ها بودند که مشتری میتونست بسته به نیازش هر ماژول رو بخره.فلش فوروارد: انقلاب بعدی SAP بعد از R/3 حدوداً بیست سال طول میکشه و در سال 2015 نسخه S/4HANA معرفی میشه.SAP R/3 یک ساختار چند لایه داره که از 3 لایه اصلی تشکیل شده:لایه ارائه (Presentation Layer): این لایه در بالاترین سطح هستش و کاربر باهاش سر و کار داره. همون UI که کاربران میبینن و توش دیتا وارد میکنن و گزارش میگیرن. عنصر اصلیش SAP-GUI (Graphical User Interface) هست و گویا روی همه سیستم عامل هایی که از جاوا پشتیبانی کنن نصب میشه؛ مثل لینوکسی ها و همچنین ویندوز. خیلی ها بهش میگن «سَپ گویی». انصافاً به زمان خودش هم کاربر پسند (user-friendly) بوده. یه SAP Logon هم داریم که این در واقع هم میشه باهاش تنظیمات سیستم رو انجام داد و هم SAPgui مربوطه رو باهاش اجرا کرد.لایه کاربردی برنامه (Application Layer): این لایه در وسط هستش و منطق برنامه و فرآیندها توش نوشته شده. درخواست های کاربر رو پردازش میکنه و هر کاری لازم باشه انجام میده. اپلیکیشن سرورها (Application servers) ارتباط بین لایه Presentation و Database رو برقرار میکنن.لایه پایگاه داده (Database Layer): این لایه در پایین ترین سطح قرار داره و داده های سیستم رو ذخیره و مدیریت میکنه. همه دیتابیس های رابطه ای (RDBMS) مثل Microsoft SQL Server و Oracle و همچنین SAP HANA میتونن توی این لایه استفاده بشن.ویژگی های معماری SAP R/3مقیاس پذیری (Scalability): معماری چند لایه به سازمان ها این امکان رو میده که هر لایه رو به طور مستقل، بسته به نیازشون مقیاس بندی کنند. یعنی مثلاً میتونن فشار کاری لایه Application رو روی چند سرور تقسیم کنن. اینجوری کاربران زیادی میتونن بدون هیچ مشکلی همزمان از سیستم استفاده کنن.کارایی (Performance): جدا بودن لایه ها منجر به بالا رفتن کارایی و بهبود عملکرد سیستم میشه. چون لایه ها میتونن مستقل عمل کنند و حجم بار سیستم بین این سه لایه تقسیم میشه.قابلیت اطمینان (Reliability): ماژولار بودن این معماری باعث میشه که خرابی در یک لایه، لزوماً لایه دیگه ای رو تحت تاثیر قرار نده و سیستم قابل اطمینان تر خواهد بود.امنیت (Security): اقدامات امنیتی رو میشه توی هر لایه پیاده سازی کرد که این منجر به حفاظت بهتر از داده ها میشه و کنترل دسترسی سیستم رو تقویت میکنه.سفارشی سازی (Customization): به لطف معماری منعطفی که R/3 داره، سازمان ها میتونن سیستم رو بر اساس نیازهای خودشون تنظیم کنن.داستان معماری SAP R/3ما توی این نوشته نمیخوایم خیلی وارد جزئیات بشیم، چون هم خیلی گسترده ست و هم میتونه پیچیده باشه. فقط خیلی خلاصه اگه بخوایم نحوه کار این معماری رو توضیح بدیم اینجوری میشه:وقتی کاربر یه درخواستی (request) رو از طریق SAP GUI ارسال میکنه، Message Server اون درخواست رو دریافت میکنه و با توجه به ملاحظاتی که خودش میدونه (از جمله load balancing) اون رو به یکی از Application Serverها ارسال میکنه. داخل اپلیکیشن سرور، Dispatcher اون درخواست رو میگیره و با توجه به نوعش به یکی از Work Processهای آزاد الصاق میکنه (همینجا اگه work processی آزاد نباشه اونو میذاره توی یه صف که بهش میگن Dispatcher Queue تا نوبتش بشه). Work Process کار اون درخواست رو انجام میده (اینجا احتمالاً لازم میشه که بره سمت دیتابیس و یه کاری بکنه) و بعد نتیجه رو به Dispatcher برمیگردونه. و از اونجا هم نتیجه به SAP GUI برمیگرده و به کاربر نشون داده میشه.(ادامه دارد...)لینک ها:۰۱ - آشنایی با SAP۰۲ - مزایا و معایب SAP۰۳ - معرفی نسخه SAP R/3

۰۲ - مزایا و معایب SAP

امید آرام - توسعه دهنده نرم افزار — Mon, 30 Jun 2025 16:46:03 +0330

همانطور که گفتیم SAP ERP یک مجموعه نرم افزاری جامع هست که برای ساده سازی (!!!) و یکپارچه سازی فرآیندهای کاری در بخش های مختلف یک سازمان طراحی شده. از یک دیتابیس متمرکز استفاده میکنه و ماژول های مختلفی داره که یکپارچگی سیستم رو تضمین میکنند. به عنوان مثال، یک سفارش فروش توی سیستم میتونه در همون لحظه موجودی انبار رو اصلاح کنه، کارهای مربوط به تأمین و امور مالی و هر تغییری که توی هر ماژول دیگه ای نیاز باشه رو انجام بده. این باعث میشه که اطلاعات سیستم همیشه به روز باشند و سازمان چابکتری داشته باشیم.همچنین کار مهمی که SAP انجام داده اینه که در صنایع مختلف گشته و بهترین روش ها (Best Practices) رو متناسب با هر صنعتی در خودش جا داده و فرآیندها و گردش کارها رو استاندارد کرده. این فرآیندهای از پیش تعریف شده، باعث میشن که تراکنش ها و فعالیت ها به نحو صحیحی در سیستم گردش پیدا کنند و در صورت لزوم بخش های مربوطه و ذینفعان را درگیر کنند. هر چند که ممکنه لازم باشه این فرآیندها تغییر کنند و به اصطلاح «سفارشی سازی» بشن که این امکان رو هم SAP فراهم کرده.مزایای SAP ERP:یکپارچه سازی (Integration): ماژول های این سیستم به شدت یکپارچه هستند. هیچ جای شکی تو این موضوع نیست!مقیاس پذیری (Scalability): چه یه شرکت استارتاپی کوچیک باشین یا یه شرکت بزرگ، این سیستم مقیاس پذیر بوده و یه راه حل ایده آل برای کسب و کارهایی هست که در حال رشد و توسعه هستند. (ولی در عمل به خاطر هزینه های بسیار بالا، فقط شرکت های خیلی بزرگ احتمالاً میتونن برن سراغ SAP)سفارشی سازی (Customization): اگرچه فرآیندها استاندارد هستند ولی سازمان ها میتونن مطابق با نیازهای منحصر به فردشون سیستم رو تطبیق بدن و تجربه کاربری موثرتری داشته باشن!هوش تجاری (Business Intelligence یا BI): SAP ERP ابزارهایی برای BI ارائه میده که سازمان ها میتونن برای آنالیز و نمایش داده ها ازش استفاده کنند و تصمیمات استراتژیک بهتری اتخاذ کنند.دسترسی جهانی (Global Reach): با توجه به اینکه بسیاری از کسب و کارها در سطح جهانی فعالیت میکنند، SAP ERP از چندین زبان، ارز و سایر الزامات قانونی پشتیبانی میکند.معایب SAP ERP:هزینه بسیار بالا (Cost): مخصوصاً در ایران! پیاده سازی و نگهداری این سیستم گرونه. سخت افزار قدرتمند میخواد، لایسنس با قیمت های نجومی باید خریداری بشه (تازه اگه بشه) و هزینه پرسنل حرفه ای توی این سیستم هم میتونه قابل توجه باشه. همچنین در طول زمان، هزینه های مداوم آپدیت و پشتیبانی و آموزش هم داره!پیچیدگی (Complexity): استاندارده ولی پیچیده است آقا، پیچیده! حالا نه به این غلظت ولی به هر حال پیاده سازیش چالش های خودش رو داره و راه اندازیش قطعاً دانش تخصصی میخواد که کار هر کسی نیست و میتونه زمانبر باشه.چالش های سفارشی سازی (Customization Challenges): با وجود اینکه خودش امکان هر گونه سفارشی سازی رو داده، ولی اصلاحات گسترده میتونه باعث افزایش پیچیدگی بشه و هزینه بر باشه. همچنین ممکنه توی بروزرسانی های آتی سیستم به مشکل برخورد کنیم و نتونیم از امکانات جدید سیستم استفاده کنیم. (در کل تا جایی که میشه نباید فرآیندهای اصلی رو تغییر بدیم.)مقاومت کاربر (User Resistance): به خاطر همون پیچیدگی و نیاز به آموزش گسترده، کاربران این سیستم ممکنه مقاومت کنند. (که میکنند و نمیذارن سیستم اجرایی بشه!)همه میگن نمیشه! ولی اگه بشه چی میشه!(ادامه دارد...)لینک ها:۰۱ - آشنایی با SAP۰۲ - مزایا و معایب SAP۰۳ - معرفی نسخه SAP R/3

۰۱ - آشنایی با SAP

امید آرام - توسعه دهنده نرم افزار — Mon, 30 Jun 2025 11:52:43 +0330

توی این مجموعه نوشته می خوایم با SAP آشنا بشیم. ببینیم اصلاً چیه و برای چی ایجاد شده!قبل از هر چیز باید بگیم که اون چیزی که توی ایران بهش میگیم SAP، در واقع سیستم ERP شرکت SAP هستش. یعنی یه شرکت بزرگ آلمانی داریم به اسم SAP که تو سال 1972 توسط پنج تا از مهندس های IBM تاسیس شده و یه سیستم جامع ERP داره که میشه توی خیلی از شرکت و صنایع مختلف نصب بشه و ازش استفاده کنن.سیستم های ERP هم که در واقع سیستم های یکپارچه ای هستند برای مدیریت و برنامه ریزی کلیه فرآیندهای یک سازمان. واژه ERP مخفف «Enterprise Resource Planning» هست که میشه «برنامه ریزی منابع سازمانی». این سیستم ها نوشته میشن تا دیتای مورد نیاز برای فعالیت شرکت رو توی یک سیستم واحد، متمرکز کنند و خیال شرکت ها رو از بابت گردش اطلاعات و کلیه فرآیندهای نرم افزاری راحت کنند. بخوایم بیشتر توضیح بدیم یعنی یه سیستم یکپارچه ای که از برنامه ریزی تامین و تولید یک شرکت گرفته تا فرآیندهای فروش و توزیع، امور مالی، منابع انسانی و غیره، همه رو در بر میگیره و کلیه نیازهای نرم افزاری یک سازمان رو در خودش جا میده. یک دیتابیس متمرکز داره که میشه توش همه چیز رو به همه چیز وصل کرد و از پیدایش سیستم های جزیره ای توی سازمان جلوگیری میکنه.توی پرانتز هم بگیم که خود واژه SAP هم مخفف عبارت «Systems, Applications and Products in Data Processing» هست و بهتره به صورت حروف جداگانه تلفظ بشه: "S-A-P" و نگیم «سَپ»؛ گرچه خیلی ها میگن و اتفاقی هم نمی افته!اجزای کلیدی سیستم SAP ERP (همون سَپ خودمون):حسابداری مالی (Financial Accounting یا FI): هسته اصلی این سیستم، ماژول FI هستش که به شرکت این قدرت رو میده که همه تراکنش های مالی خودش رو به صورت یکپارچه مدیریت کنه. موارد مهمی از جمله حساب های دریافتنی، پرداختنی و حسابداری دفتر کل توی این ماژول هستند.ماژول کنترلینگ (Controlling یا CO): ماژول CO در واقع مکملی برای ماژول FI هست که ابزارهایی برای تصمیم گیری و گزارشگری داخلی ارائه میده. همچنین شامل حسابداری مراکز هزینه، مراکز سود و سفارشات داخلی هست.مدیریت مواد (Material Managment یا MM): ماژول MM که برای شرکت های تولیدی خیلی مهمه، کلیه فرآیندهای تامین و تهیه مواد، دریافت کالا، مدیریت موجودی و انبارداری رو پوشش میده.برنامه ریزی تولید (Production Planning یا PP): ماژول PP به برنامه ریزی و کنترل فعالیت های تولیدی کمک میکنه. مواردی مثل مدیریت تقاضا، برنامه ریزی عملیاتی تولید و کنترل کف کارخانه از جمله امکانات این ماژول هست.فروش و توزیع (Sales and Distribution یا SD): ماژول SD برای شرکت هایی که محصولی برای فروش دارند، ضروریه و شامل مواردی مثل سفارشات فروش، قیمت گذاری، فاکتور و تحویل هسمدیریت کیفیت (Quality Management یا QM): در هر صنعتی، کیفیت در اولویت اول باید باشه. ماژول QM که شامل رویه های کنترل کیفیت، اعلان ها و بازرسی هاست، کمک میکنه شرکت ها کیفیت محصول خودشون رو حفظ کنن و ارتقا بدن.مدیریت سرمایه انسانی (Human Capital Management یا HCM): ماژول HCM، که قبلاً بنام HR شناخته میشد، بر مدیریت منابع انسانی شرکت تمرکز داره و شامل فرآیندهای مدیریت پرسنل، مدیریت سازمانی، مدیریت زمان و حقوق و دستمزد میشه.(ادامه دارد...)لینک ها:۰۱ - آشنایی با SAP۰۲ - مزایا و معایب SAP۰۳ - معرفی نسخه SAP R/3

نه به Horizontal Scroll!

امید آرام - توسعه دهنده نرم افزار — Mon, 26 May 2025 14:12:30 +0330

روی یه پروژه ای کار میکردم که توش یه جدول داشتیم با کلی ستون!کد حساب و شرحشکد سرفصل حساب و شرحشکدهای معین و تفصیلی هر کدوم با شرحشونمبالغ تراز آزمایشی، اسناد کاربرگی، طبقه بندی و … هر کدوم بدهکار و بستانکارخلاصه دنبال یه راهی بودم که هم اسکرول افقی نخوره، هم شکل ظاهریش رو حفظ کنه و خواناییش رو از دست نده.💡 اولین کاری که کردم این بود که همه کد و شرح ها رو بردم زیر هم توی یک ستون. یعنی به جای اینکه یه ستون بذارم برای کد حساب و یه ستون دیگه بذارم برای شرحش، یه ستون گذاشتم به اسم حساب و کد رو بالا نوشتم و شرحش رو پایین. درسته که ۲ خطی میشد هر ردیفم ولی خواناییش حفظ میشد و قشنگ هم بود. چون تو حالت قبلی هم wrap میشدن و بیشتر ردیف ها چند خطی بودن. همینطور «بدهکار» و «بستانکار» رو هم بردم زیر هم توی یه ستون. اونم عمدتاً یکیش مقدار داره و اون یکی صفره. اینجوری از فضای خالی بیشتر استفاده کردیم.💡 اما باز هم اسکرول میخورد (مخصوصاً توی مانیتورهای کاربراش که بیشتر کوچیک بودن). اومدم یه سیستم zoom جاوا اسکریپتی درست کردم که موقع نمایش تصمیم میگیره که با توجه به اندازه صفحه، فونت رو تا اندازه ای کوچیک کنه که دیگه اسکرول نخوره! قطعاً توی صفحه های خیلی کوچیک مثل موبایل جواب نمیده ولی کاربرای این سیستم توی شرکت یه مانیتور معمولی دارن و با یکم کوچیک کردن اندازه فونت مشکل حل شد:var zoomToFitWidth = function (containerSelector) { if (!containerSelector) containerSelector = window.activeTabId || 'body'; const $container = document.querySelector(containerSelector); const containerClientWidth = $container.clientWidth; let lastClientWidth = $container.getAttribute('last-client-width'); if (!lastClientWidth) { $container.setAttribute('last-client-width', containerClientWidth); lastClientWidth = containerClientWidth; } $container.setAttribute('last-client-width', containerClientWidth); const $tables = $container.querySelectorAll('.fit-width-table'); //اگه کوچیک بوده و بزرگش کرده دوباره توی اندازه فونتش تجدید نظر کنه if (containerClientWidth > lastClientWidth) { for (let t = 0; t < $tables.length; t++) { const $table = $tables[t]; $table.style.fontSize = "1em" $table.setAttribute('zoom', 100); const $ths = $table.querySelectorAll('th'); for (let i = 0; i < $ths.length; i++) { $ths[i].style.minWidth = $ths[i].getAttribute('mWidth') + 'px'; } } return setTimeout(() => { zoomToFitWidth(containerSelector); }, 100); } for (let t = 0; t < $tables.length; t++) { const $table = $tables[t]; const zoomRatio = (containerClientWidth / $table.clientWidth) * parseFloat($table.getAttribute('zoom') || 100) / 100; if (!(zoomRatio > 0)) { setTimeout(() => { zoomToFitWidth(containerSelector); }, 100); return; } if (zoomRatio >= 0.99) return; const $ths = $table.querySelectorAll('th'); for (let i = 0; i < $ths.length; i++) { let _width = parseInt($ths[i].getAttribute('mWidth') || ''); if (!_width) { _width = parseInt(getComputedStyle($ths[i]).minWidth); $ths[i].setAttribute('mWidth', _width); } $ths[i].style.minWidth = (_width * zoomRatio) + 'px'; } $table.style.fontSize = zoomRatio + 'em'; $table.setAttribute('zoom', zoomRatio * 100); if ($table.clientWidth > containerClientWidth) { setTimeout(() => { zoomToFitWidth(containerSelector); }, 100); return; } } } document.addEventListener('DOMContentLoaded', function () { zoomToFitWidth('.my-container'); }); window.addEventListener('resize', function (event) { zoomToFitWidth('.my-container'); });Try it Yourselfدیدیگه فقط کافیه به جدولمون کلاس “fit-width-table” رو اضافه کنیم و بگیم تابع zoomToFitWidth رو بعد از پر شدن جدول صدا بزنه. همین. خیلی هم خوشگل 😉راستی من خودم برای اینکه نسبت اندازه ی ستون ها حفظ بشه، به ها min-width میدم 🤞https://omidaram.ir/blog/no-horizontal-scroll/

افزایش سرعت برنامه با استفاده از Cache در کدنویسی

امید آرام - توسعه دهنده نرم افزار — Thu, 19 Dec 2024 14:08:01 +0330

آیا از کُندی اجرای صفحه ی خود رنج می برید؟ ما به شما پکیج افزایش سرعت Cache رو پیشنهاد میکنیم ;)caching in software developmentخیلی وقتا توی اجرای برنامه ما مجبوریم یه سری کارهای تکراری رو انجام بدیم. یا ممکنه لازم باشه کاربر یه کاری رو هی انجام بده. مثلاً مشکلی که توی سیستم خودم داشتم این بود که یه درخت از لیست حساب های شرکت رو نشون میدادم که آبشاری میومد پایین و کاربرش دونه دونه میزد تا برسه به اون نودی که میخواست و بعدش هم احتمالاً میرفت یه نود بالاتر و میومد توی نود بعدی و همینجوری این درخت من هی میرفت از دیتابیس اون نودی که کاربر میخواست رو میاورد! اولش که این فرم رو نوشته بودم سرعتش قابل قبول بود ولی به مرور چیزای بیشتری رو بهش اضافه کردم و از دید خودم کُند شده بود. مثلاً یک و نیم ثانیه طول میکشید تا هر حساب رو لود کنه! (شاید بگی یک ثانیه چیزی نیست ولی وقتی یوزر میخواد دائم ازش استفاده بکنه یک ثانیه هم براش زیاده) اینم در نظر بگیرین که کل حساب های شرکت 7-8 هزار تاست که عدد بزرگی نیست ولی به خاطرش هی میرفتیم دیتابیس و برمیگشتیم.خلاصه، اومدم براش یه کَش درست کردم که توی اولین فراخوانی دیتا میره همه حساب ها رو میاره و توی RAM نگهش میداره و توی مراجعه های بعدی از همون کش استفاده میکنه. public static class Cache { private class CacheItem { public DateTime CreateDateTime { get; set; } public int Key { get; set; } public List Values { get; set; } } private static List CacheItems = new List(); public static bool TryGet(int key, out List values) { values = default; CacheItems.RemoveAll(x => x.CreateDateTime < DateTime.Now.AddDays(-1)); var cacheItem = CacheItems.FirstOrDefault(x => x.Key == key); if (cacheItem != null) { values = cacheItem.Values; return true; } return false; } public static void Set(int key, List values) { if (values == null) return; var cacheItem = CacheItems.FirstOrDefault(x => x.Key == key); if (cacheItem == null) { CacheItems.Add(new CacheItem { CreateDateTime = DateTime.Now, Key = key, Values = values, }); } else { cacheItem.Values = values; cacheItem.CreateDateTime = DateTime.Now; }; } public static void Delete(int key) { CacheItems.RemoveAll(x => x.Key == key); } public static bool TryGetObject(int key, out T obj) { obj = default; if (TryGet(key, out List values)) { obj = values.FirstOrDefault(); return true; } return false; } public static void SetObject(int key, T obj) { if (obj == null) return; Set(key, new List { obj }); } }اول اینو بگم که توی پروژه های تحت وب (مثل این) با هر فراخوانی API همه اطلاعات قبلی از بین میره ولی ما اینجا اومدیم این کلاس رو static تعریف کردیم که باعث میشه بره بچسبه به اصل برنامه و دیگه تا وقتی IIS رو restart نکنیم از بین نمیره.کلاسی که نوشتیم هم خیلی ساده ست؛ اول اینکه Generic تعریف شده تا بتونه برای هر تایپی استفاده بشه. بعدش هم یه «کلید - Key» داره که دیتا باهم قاطی نشه و یه «لیست - Values» که دقیقاً همون چیزیه که میخوایم کش کنیم و یه «زمان ایجاد - CreateDateTime» هم داره که بیشتر از یک روز چیزی رو توش نگه نداریم.استراتژی های مختلفی برای cache داریم که ما اینجا از متداول ترینش یعنی Cache-Aside استفاده کردیم که اینجوریه که توی هر فراخوانی دیتا، برنامه اول cache رو چک میکنه اگه دیتا داشت (Cache Hit) که همون رو برمیگردونه و اگه نداشت (Cache Miss)، برنامه میره از دیتابیس میخونه و به کاربر نشون میده و توی کش هم ذخیره ش میکنه. اینجوری مثلاً: if (!Cache.TryGet(periodId, out result)) { result = FetchAccountsFromDB(periodId); Cache.Set(periodId, result); }به همین سادگی! ولی به قدری توی سرعت برنامه تأثیر مثبت داشت که کاربرش کلی حال کرده بود.البته اینم بگم که توی استفاده از cache باید مراقب باشیم و حواسمون به تغییرات کاربر باشه. چون اگه مثلاً یه چیزی رو تغییر بده که ما قبلاً کش کردیم دیگه تغییراتش رو نمیبینه و شاکی میشه. من کلاً گفتم هرجا توی این جدول تغییر داد cacheش رو پاک کنه که خیالم راحت باشه.چند تا استراتژی Cache که میشناسم هم خلاصه وار اینجا بگم:استراتژی Cache-Aside:که همین حالت بالاست؛ یعنی کش در کنار دیتابیس هست؛ برنامه اول کش رو چک میکنه اگه نبود میره سراغ دیتابیس و بعدش کش رو آپدیت میکنه.استراتژی Read-Through:تو این حالت کش در مسیر دیتابیس قرار میگیره و اگه دیتا نداشته باشه میره از دیتابیس میخونه و اول خودش آپدیت میشه و بعد دیتا رو برمیگردونه.استراتژی Write-Through:این استراتژی میگه هر چیزی قراره بره توی دیتابیس ذخیره بشه اول باید توی کش نوشته بشه. (که به نظرم خیلی کارا نیست چون هم حجم بالایی میگیره هم خیلی به درد نمیخوره!)استراتژی Write-Around:این روش انگار اینجوریه که همه ی دیتا رو توی کش نمینویسه. فقط اونایی که درخواست Read براشون میاد رو مینویسه! (خودم درست نفهمیدم چجوریه!)استراتژی Write-Back / Write-Behind:این روش باحالیه که Cache به برنامه میگه آقا دیتابیس منم. هر چی رو بخوایم Insert کنیم در واقع توی Cache نوشته میشه و خیلی سریع از نظر کاربر انجام میشه؛ بعد خود این Cache میاد مثلاً با یکم تأخیر و جوری که کاربر اصلاً بهش کاری نداره دیتا رو میریزه توی دیتابیس.برای Cache کلی کتابخونه و روش استاندارد هم هست که توی برنامه میتونین ازش استفاده کنین ولی من ترجیح دادم خودم بنویسم. در کل خیلی چیز خوبیه ولی نباید زیاده روی کرد توش. چون همونقدر که سرعت رو بالا میبره، مصرف حافظه رو هم زیاد میکنه. امیدوارم که درست و به جا ازش استفاده کنین.

حل مشکل مرتب سازی حروف فارسی در کدنویسی

امید آرام - توسعه دهنده نرم افزار — Sun, 17 Nov 2024 15:45:57 +0330

شاید براتون پیش اومده باشه که وقتی یه لیستی (مثلاً اسامی مشتریان) رو میخواین مرتب کنین، اونی که با حرف «پ» شروع شده اومده باشه اول لیست!مشکل کجاست؟ ترتیب حروف فارسی در دیتابیس ها ممکنه درست نباشند و حروف «گچپژ» سر جای خودشون نباشند. البته که بیشتر دیتابیس ها راه اصولی خودشون رو دارن برای حل این مشکل؛ ولی ممکنه شما به تنظیمات دیتابیس دسترسی نداشته باشین یا به هر دلیلی تغییر اون تنظیمات براتون مقدور نباشه.راه حل پیشنهادی من چیه؟ اینه که بیایم فقط توی Order By کوئری مون این حروف رو با یه عبارت دیگه جایگزین کنیم. در واقع هر حرفی رو که میخوایم بعد از یه حرف دیگه قرار بگیره، کافیه همون حرف رو بذاریم قبلش به علاوه یه کاراکتری که مطمئن بشیم میبرتش آخر لیست! یعنی مثلاً حرف «پ» رو میخوام بذارم بعد از «ب»؛ باید هرچی «پ» هست رو با عبارت «بîپ» جایگزین کنیم. اون کاراکتر وسطش هم تضمین میکنه که همه ی «پ»ها میرن بعد از آخرین «ب».qList.OrderBy(x => x.Customer.Name .Replace('پ', 'بîپ') .Replace('ژ', 'زîژ') .Replace('چ', 'جîچ') .Replace('گ', 'کîگ') .Replace('ک', 'كîک'));فقط اشتباه نشه اینجا توی نمایش (و احتمالاً محیطی که شما کد مینویسین) جای حروف رو جابجا نشون میده!نتیجه:مرتب سازی صحیح کلمات فارسی به روش ویژهامیدوارم مفید باشه براتون.

حل مشکل جستجوی حروف فارسی در کدنویسی

امید آرام - توسعه دهنده نرم افزار — Sun, 10 Nov 2024 12:09:11 +0330

جستجوی حروف فارسی در کدنویسیفرض کنید توی برنامه میخواین یه جستجو روی لیست مشتریان بنویسین. دو تا مشکل هست؛ اول اینکه بعضی از حروف فارسی در دیتابیس ها کدهای متفاوتی دارن. به طور مشخص حروف «ک» و «ی» ممکنه به شکل های عربی شون ذخیره شده باشن و کیبورد کاربر فارسی باشه یا برعکس. مشکل دوم اینه که بعضی از کلمه ها توی فارسی ممکنه به شکل های مختلفی نوشته بشن! مثلاً فامیلی های «کربلایی» و «مشکات» و «آرام»، ممکنه اینجوری نوشته شده باشن: «کربلائی» و «مشکاة» و «ارام». در این حالت ها جستجوی شما اونجوری که انتظار دارین کار نمیکنه.حالا راهش اینه که بیایم این حروف رو با حروف معادلشون جایگزین کنیم. هم توی مقدار ورودی کاربر و هم توی دیتایی که از جدول میگیریم. به همین سادگی!تابع هایی که خودم دارم رو اینجا میذارم میتونین خودتون کامل ترش کنین. فقط اینکه این جایگزینی باید فقط توی سرچ باشه و نمایش باید به همون شکل اصلی باشه.توی #C - معمولاً برای استاندارد سازی ورودی کاربر public static string FaSearchHelper(this string x) { if (string.IsNullOrEmpty(x)) { return x; } x = x.Trim(); var exDic = new Dictionary(21) { { '۱', '1' }, { '۲', '2' }, { '۳', '3' }, { '۴', '4' }, { '۵', '5' }, { '۶', '6' }, { '۷', '7' }, { '۸', '8' }, { '۹', '9' }, { '۰', '0' }, { 'ؠ', 'ی' },//1568 'ؠ' { 'ء', 'ی' },//1569 'ء' { 'ئ', 'ی' },//1574 'ئ' { 'ى', 'ی' },//1609 'ى' { 'ي', 'ی' },//1610 'ي' { 'آ', 'ا' },//1570 'آ' { 'أ', 'ا' },//1571 'أ' { 'إ', 'ا' },//1573 'إ' { 'ؤ', 'و' },//1572 'ؤ' { 'ة', 'ت' },//1577 'ة' { 'ك', 'ک' },//1603 'ك' }; char exChar; var res = new StringBuilder(x.Length); for (var i = 0; i < x.Length; i++) { res.Append(exDic.TryGetValue(x[i], out exChar) ? exChar : x[i]); } return res.ToString(); }توی جاوا اسکریپت - معمولاً برای استاندارد سازی ورودی کاربرvar FaSearchHelper = function (x) { if (!x || x == null) { return x; } x = x.toString().trim(); var exDic = { '۱': '1', '۲': '2', '۳': '3', '۴': '4', '۵': '5', '۶': '6', '۷': '7', '۸': '8', '۹': '9', '۰': '0', 'ؠ': 'ی', 'ء': 'ی', 'ئ': 'ی', 'ى': 'ی', 'ي': 'ی', 'آ': 'ا', 'أ': 'ا', 'إ': 'ا', 'ؤ': 'و', 'ة': 'ت', 'ك': 'ک', }; var res = []; for (var i = 0; i < x.length; i++) { res.push(exDic[x[i]] || x[i]); } return res.toString(); }توی اوراکل - معمولاً برای استاندارد سازی دیتای جدولTrim(Translate({s}, 'ؠ ء آ أ ؤ إ ئ ة ك ى ي ', 'ی ی ا ا و ا ی ت ک ی ی '))من توی #C و Javascript اعداد فارسی رو هم تبدیل به معادل های انگلیسی شون میکنم. چون پیش میاد گاهی کاربر یه عددی رو از جایی که فارسی نشونش میده کپی کرده باشه. نکته ی بعدی اینه که از Dictionary استفاده کردم که به مراتب سریعتر از List هستش و اینکه برای جایگزینی هم از تابع Replace استفاده نکردم و به جاش یه for نوشتم که کل قضیه با هزینه O(n) انجام میشه، در حالیکه اگه replace مینوشتم به ازای هر کدومش یه O(n) داشتیم که خوب نبود.برای دیتابیس اوراکل هم از تابع Translate استفاده کردم که خیلی باحاله. اینجوریه که سه تا رشته میگیره و روی رشته اول کاراکتر به کاراکتر حرکت میکنه و اگه اون کاراکتر توی رشته دوم باشه با کاراکتر معادلش از رشته سوم جایگزین میکنه. یعنی مثلاً این:Translate('OMID ARAM', 'MOD', 'XYZ') = 'YXIZ ARAX'امیدوارم مفید باشه.سرچ مهمه برای کاربر. بهش اهمیت بدین. وقت بذارین براش. به کیفیت سیستم تون کمک میکنه. تا جایی که میشه باید راحت باشه. مثلاً اگه میتونین به جای ده تا باکس سرچ که روی ده تا فیلد هست، یه دونه بذارین و خودتون پشت صحنه هندل کنین. یا مثلاً اگه کاربر فاصله گذاشته توی سرچش، بیاین کلمه ها رو تک تک بگردین توی متن که جابجایی کلمه ها تاثیری رو نتیجه جستجو تون نداشته باشه (البته اگه واقعا ترتیب مهم نیست). همینطور به جای مساوی بهتره بیشتر از «'%...%' like» استفاده کنین برای کلمه ها. یا حتی میتونین از الگوریتم های پیچیده تری استفاده کنین که اشتباهات کاربر رو هم اصلاح کنه و بهش بگه «منظورت اینه؟» خلاصه که هر کاری بلدین بکنین که جستجوی کاربر بی جواب نباشه و سیستم تون مرتبط ترین جواب رو بهش بده.

انواع تست نرم افزار - قسمت ۱۰ (سخن پایانی)

امید آرام - توسعه دهنده نرم افزار — Mon, 08 Jul 2024 17:02:06 +0330

قسمت های قبلی:انواع تست نرم افزار - قسمت ۱ (مقدمه)انواع تست نرم افزار - قسمت ۲ (Manual vs. Automated vs. Continuous)انواع تست نرم افزار - قسمت ۳ (Functional vs. non-functional testing)انواع تست نرم افزار - قسمت ۴ (Unit testing)انواع تست نرم افزار - قسمت ۵ (Integration testing)انواع تست نرم افزار - قسمت ۶ (System testing)انواع تست نرم افزار - قسمت ۷ (User Acceptance testing)انواع تست نرم افزار - قسمت ۸ (Performance testing)انواع تست نرم افزار - قسمت ۹ (Security, Usability and Compatibility testing)Six golden rules of good software testingWe already know all the major types of software testing. How do we put this knowledge into practice?There are many good practices that experienced software developers follow when conducting tests within their projects. Let’s summarize them into six golden rules of good software testing.شش قانون طلایی تست نرم افزار خوبتا اینجا با انواع اصلی تست نرم افزار آشنا شده ایم. چگونه این دانش را عملی کنیم؟قواعد بسیاری در انجام تست های پروژه‌ها وجود دارد که توسعه‌دهندگان با تجربه از آنها پیروی می‌کنند. بیایید آنها را در شش قانون طلایی تست نرم افزار خوب خلاصه کنیم.1. Start earlyNo matter what your primary goal is, if you want to produce a high-quality software product, you should always cover your code with tests from the very beginning of the software development lifecycle. This approach will minimize the risk of having to do a major architecture rebuild in the future, when some problems will inevitably surface.۱. از همون اول شروع کنمهم نیست که هدف اصلی شما چیست، اگر می خواهید یک محصول نرم افزاری با کیفیت بالا تولید کنید، همیشه باید کد خود را از همان ابتدای چرخه توسعه نرم افزار با تست هایی پوشش دهید. این رویکرد، خطر نیاز به کوبیدن و از نو ساختن برنامه را در آینده به حداقل می رساند، چون مشکلات همیشه بعداً خودشون رو نشون میدن.2. Be precise and comprehensivePrecision ensures that tests are executed precisely, leaving no room for ambiguity or misinterpretation. This helps to catch even the most subtle defects and ensure the highest level of software quality. In addition, comprehensive testing ensures that all critical functionality and scenarios are covered, reducing the risk of potential issues or bugs slipping through the cracks.۲. دقیق و جامع باشددقت تضمین می‌کند که تست ها دقیقاً اجرا می‌شوند و جایی برای ابهام یا تفسیر نادرست باقی نمی‌گذارند. این کمک می کند تا حتی ظریف ترین نقص ها را پیدا کنید و از بالاترین سطح کیفیت نرم افزار اطمینان حاصل کنید. علاوه بر این، جامع بودن تست ها تضمین می‌کند که همه عملکردها و سناریوهای حیاتی پوشش داده شده‌اند و خطر مشکلات احتمالی یا باگ‌هایی که ممکن است نمایان شوند را کاهش می‌دهد.3. Avoid the pesticide paradoxRepeating the same tests with the same inputs can lead to the same defects being found over and over again. Testers must constantly update and modify their test cases to find new defects.۳. از پارادوکس آفت کش ها اجتناب کنیدتکرار تست‌های مشابه با ورودی‌های یکسان فقط باعث میشود که همان ایرادهای قبلی را بارها و بارها ببینید. تست کنندگان باید به طور مداوم موارد تستی خود را برای یافتن نقص های جدید به روز کرده و اصلاح کنند.4. Automate as much as possibleTime is arguably the most precious resource in software development.By using automated performance testing, you can test virtually all aspects of your code faster. However, some human intervention in the performance engineering process is still necessary, especially when setting up sophisticated testing tools on assembled applications.۴. تا حد امکان تست ها را خودکار کنیدزمان مسلماً با ارزش ترین منبع در توسعه نرم افزار است.با استفاده از روش های تست خودکار، می توانید تقریباً تمام جنبه های کد خود را سریعتر تست کنید. با این حال، گاهی اوقات هنوز مداخلات انسانی ضروری است، به خصوص در هنگام راه‌اندازی ابزارهای تستی پیچیده بر روی برنامه‌ها.5. Properly simulate the production environmentIn order for software tests to produce tangible and usable results, it is important to run them on data sets, hardware, and conditions that closely resemble the production environment.Information about the “shape and size” of the data the system will handle in production is incredibly important, so remember to discuss this with stakeholders before setting up the test environment.۵. محیط نهایی محصول را به درستی شبیه سازی کنیدبرای اینکه تست های نرم‌افزاری نتایج ملموس و قابل استفاده تولید کنند، مهم است که آن‌ها را روی مجموعه‌ داده ها، سخت‌افزار و شرایطی که شباهت زیادی به محیط نهایی محصول دارند، اجرا کنیم.اطلاعات مربوط به «شکل و اندازه» داده‌هایی که سیستم در نهایت باید آن را مدیریت می‌کند، بسیار مهم است، بنابراین به یاد داشته باشید که قبل از تنظیم محیط تستی، در رابطه با این موضوع با ذینفعان و صاحبان آن کسب و کار گفتگو کنید.6. Make your software testing a continuous processAs your codebase changes and evolves, so does your test environment. If you leave your test unchanged for a long period of time, the absence of bugs will lead you to believe that there are no defects in a software application. This will only be an illusion due to insufficient test coverage. Therefore, software testing should always be a comprehensive and continuous process.۶. تست نرم افزار خود را به یک فرآیند مداوم تبدیل کنیدهمانطور که کد شما تغییر می کند و تکامل می یابد، محیط تست شما نیز باید تغییر کند. اگر تست خود را برای مدت طولانی بدون تغییر رها کنید، عدم وجود اشکالات شما را به این باور می رساند که هیچ نقصی در نرم افزار وجود ندارد. این فقط یک توهم به دلیل پوشش ناکافی تست خواهد بود. بنابراین، تست نرم افزار باید همیشه یک فرآیند جامع و مستمر باشد.ConclusionIn the ever-evolving landscape of software development, implementing a comprehensive set of testing methodologies is paramount to achieving better results. By understanding and leveraging the key types of software testing, engineers can uncover defects, improve performance, ensure security, and deliver a seamless user experience.نتیجه گیریدر چشم انداز همیشه در حال تحول توسعه نرم افزار، اجرای مجموعه ای جامع از روش های تست برای دستیابی به نتایج بهتر بسیار مهم است. با درک و استفاده از انواع کلیدی تست نرم افزار، مهندسان می توانند نقص ها را کشف کنند، عملکرد را بهبود بخشند، امنیت را تضمین کنند و یک تجربه کاربری یکپارچه ارائه دهند.لینک مطلب اصلی:https://stratoflow.com/types-of-software-testing

انواع تست نرم افزار - قسمت ۹ (Security, Usability & Compatibility testing)

امید آرام - توسعه دهنده نرم افزار — Mon, 08 Jul 2024 16:58:04 +0330

قسمت های قبلی:انواع تست نرم افزار - قسمت ۱ (مقدمه)انواع تست نرم افزار - قسمت ۲ (Manual vs. Automated vs. Continuous)انواع تست نرم افزار - قسمت ۳ (Functional vs. non-functional testing)انواع تست نرم افزار - قسمت ۴ (Unit testing)انواع تست نرم افزار - قسمت ۵ (Integration testing)انواع تست نرم افزار - قسمت ۶ (System testing)انواع تست نرم افزار - قسمت ۷ (User Acceptance testing)انواع تست نرم افزار - قسمت ۸ (Performance testing)انواع تست غیرعملکردی نرم افزارSecurity testingSecurity testing focuses on evaluating a software system’s ability to protect data, maintain confidentiality, and defend against potential threats and vulnerabilities.This type of testing is typically performed by a team of experienced cybersecurity professionals. Security testing itself involves identifying security weaknesses and vulnerabilities in the application’s design, implementation, and infrastructure. By evaluating the system’s defenses, security testing helps ensure that sensitive data remains protected and the system remains resilient to security breaches. There are three main types of security testing:تست امنیتتست امنیت بر ارزیابی توانایی سیستم نرم افزاری برای محافظت از داده ها، حفظ محرمانه بودن و دفاع در برابر تهدیدات و آسیب پذیری های احتمالی، تمرکز دارد.این نوع تست معمولا توسط تیمی از متخصصان باتجربه امنیت سایبری انجام می شود. تست امنیت شامل شناسایی نقاط ضعف و آسیب پذیری امنیتی در طراحی، پیاده سازی و زیرساخت برنامه است. با ارزیابی سیستم دفاعی، تست امنیت کمک می‌کند تا اطمینان حاصل شود که داده‌های حساس محافظت می‌شوند و سیستم در برابر نقض‌های امنیتی مقاوم می‌ماند. سه نوع اصلی تست امنیت وجود دارد:1. Penetration TestingPenetration testing, commonly known as “ethical hacking,” involves simulating real-world attacks on the software system to identify potential security vulnerabilities. The goal is to uncover vulnerabilities that could be exploited by attackers, provide insight into the security robustness of the system, and recommend mitigation measures.۱. تست نفوذتست نفوذ، که معمولا به عنوان "هک اخلاقی" شناخته می شود، شامل شبیه سازی حملات دنیای واقعی به سیستم نرم افزاری برای شناسایی آسیب پذیری های امنیتی بالقوه است. هدف، کشف آسیب‌پذیری‌هایی است که می‌توانند توسط مهاجمان مورد سوء استفاده قرار گیرند، بینشی در مورد استحکام امنیتی سیستم و توصیه‌های اقدامات کاهشی ارائه می‌شود.2. Vulnerability TestingThis type of testing is designed to identify vulnerabilities and weaknesses in the software application, network, or infrastructure. It involves performing continuous testing and auditing to verify that the code base is being developed according to the latest security best practices.۲. تست آسیب پذیریاین نوع تست برای شناسایی آسیب‌پذیری‌ها و نقاط ضعف در نرم‌افزار، شبکه یا زیرساخت طراحی شده است. این شامل انجام تست و ممیزی مداوم برای تأیید این است که کد، مطابق با آخرین و بهترین شیوه های امنیتی در حال توسعه است.3. Security Configuration TestingSecurity configuration testing evaluates the security configurations of the software application, servers, and network infrastructure. The goal is to ensure that the system is securely configured with proper access controls, encryption settings, and other security measures.۳. تست تنظیمات امنیتیتست تنظیمات امنیتی، پیکربندی های امنیتی نرم افزار، سرورها و زیرساخت شبکه را ارزیابی می کند. هدف این است که اطمینان حاصل شود که سیستم به طور ایمن با کنترل دسترسی های مناسب، تنظیمات رمزگذاری (encryption) و سایر اقدامات امنیتی پیکربندی شده است.Usability testingUsability testing is another type of non-functional testing that evaluates the usability, intuitiveness, and overall user experience of software products.Usability testing, a critical element of user-centered interaction design, focuses on evaluating the ease of use and usability of a software product. Conducting usability testing requires a thorough understanding of the application because it involves extensive testing. In essence, usability testing serves as a distinct technique to identify flaws in the end-user interaction of a software product, earning it the alternative term of user experience (UX) testing. There are two types of usability testing that are worth mentioning here:تست قابلیت استفادهتست قابلیت استفاده، نوع دیگری از تست های غیرعملکردی است که قابلیت استفاده، شهودی بودن و تجربه کلی کاربر محصول را ارزیابی می کند.این تست (که یک عنصر حیاتی در طراحی تعاملی کاربر-محور هست)، بر ارزیابی سهولت و قابلیت استفاده یک محصول نرم افزاری تمرکز دارد. انجام این تست نیاز به درک کامل برنامه دارد زیرا مستلزم یک تست گسترده است. در اصل، تست قابلیت استفاده به عنوان یک تکنیک متمایز برای شناسایی نقص‌ها در تعامل کاربر نهایی یک نرم‌افزار عمل می‌کند و به نوعی جایگزین تست تجربه کاربر (UX testing) هست. دو نوع تست قابلیت استفاده وجود دارد که در اینجا قابل ذکر است:1. Cross-browser TestingCross-browser testing, as the name suggests, tests an application on different browsers, operating systems, and mobile devices to see how it looks, feels, and performs.Why do we need cross-browser testing?The answer is quite simple. Different users use different operating systems, browsers, and mobile devices. The goal of any company developing digital products is to ensure a great user experience regardless of the device.۱. تست بین مرورگرهاهمانطور که از نام آن پیداست، تست بین مرورگرها، یک برنامه را روی مرورگرها، سیستم عامل‌ها و موبایل های مختلف تست می‌کند تا ببیند ظاهر، احساس و عملکرد آن چگونه است.چرا به تست بین مرورگر نیاز داریم؟پاسخ کاملا ساده است. کاربران مختلف از سیستم عامل ها، مرورگرها و موبایل های مختلف استفاده می کنند. هدف هر شرکتی که محصولات دیجیتالی را توسعه می دهد، اطمینان از عالی بودن تجربه کاربری، بدون توجه به دستگاه است.2. Exploratory testingExploratory testing in software development is a dynamic and unscripted approach to testing that focuses on simultaneous learning, test design, and test execution. Unlike traditional scripted testing where test cases are predefined, exploratory testing encourages testers to actively explore the software application while designing and executing test cases on the fly.Exploratory testing is particularly valuable for uncovering unexpected behavior, validating assumptions, and providing real-time feedback on software functionality, usability, and overall quality.۲. تست اکتشافیتست اکتشافی در توسعه نرم افزار یک رویکرد پویا و نانوشته برای تست است که بر یادگیری همزمان، طراحی تست و اجرای تست تمرکز دارد. بر خلاف تست های سنتی که در آن موارد تست از پیش تعریف شده اند، تست اکتشافی تست کنندگان را تشویق می‌کند تا در حین طراحی و اجرای موارد تست، به طور فعال برنامه و نقاط ضعف احتمالی آن را کشف کنند.تست اکتشافی به ویژه برای کشف رفتار غیرمنتظره، اعتبارسنجی مفروضات و ارائه فیدبک واقعی در مورد عملکرد نرم افزار، قابلیت استفاده و کیفیت کلی سیستم بسیار ارزشمند است.Compatibility testingCompatibility testing is a type of testing that verifies the behavior and performance of software in different environments, such as different Web servers, hardware setups, and network configurations. Its primary goal is to ensure that the software will function correctly across different configurations, databases, browsers, and their respective versions.تست سازگاریتست سازگاری نوعی تست است که رفتار و عملکرد نرم‌افزار را در محیط‌های مختلف، مانند سرورهای وب مختلف، تنظیمات سخت‌افزار و پیکربندی‌های شبکه تأیید می‌کند. هدف اصلی آن اطمینان از عملکرد صحیح نرم افزار در پیکربندی های مختلف، پایگاه داده ها، مرورگرها و نسخه های مربوطه است.قسمت بعدی:انواع تست نرم افزار - قسمت ۱۰ (سخن پایانی)لینک مطلب اصلی:https://stratoflow.com/types-of-software-testing

انواع تست نرم افزار - قسمت ۸ (Performance testing)

امید آرام - توسعه دهنده نرم افزار — Mon, 08 Jul 2024 16:55:06 +0330

قسمت های قبلی:انواع تست نرم افزار - قسمت ۱ (مقدمه)انواع تست نرم افزار - قسمت ۲ (Manual vs. Automated vs. Continuous)انواع تست نرم افزار - قسمت ۳ (Functional vs. non-functional testing)انواع تست نرم افزار - قسمت ۴ (Unit testing)انواع تست نرم افزار - قسمت ۵ (Integration testing)انواع تست نرم افزار - قسمت ۶ (System testing)انواع تست نرم افزار - قسمت ۷ (User Acceptance testing)پس از آشنایی با انواع تست عملکردی حال بیایید با انواع تست غیرعملکردی آشنا شویم. در حالیکه گروه قبلی تست ها ویژگی‌هایی از نرم افزار را بررسی میکرد که کاربران نهایی با آن تعامل دارند، تست های غیرعملکردی کمی عمیق‌تر به درون عملکرد فنی یک نرم‌افزار می‌پردازند.انواع تست غیرعملکردی نرم افزارPerformance testingPerformance testing is an incredibly complex topic. So complex, in fact, that we’ve dedicated an entire blog post to the importance of performance testing in modern custom development projects. That said, let’s take a quick look at the main types of performance testing and the factors that make this aspect of non-functional testing so incredibly important.In a nutshell, performance testing aims to assess the responsiveness, speed, scalability, and stability of a software system under various workload conditions. It ensures that the application performs optimally and meets performance expectations.تست کارایی عملکرد (Performance Testing)تست کارایی یک موضوع فوق العاده پیچیده است. در واقع آنقدر پیچیده است که باید در یک پست جداگانه در مورد اهمیت این تست صحبت شود. با این حال، بیایید نگاهی گذرا به انواع اصلی تست کارایی و عواملی که این جنبه از تست غیرعملکردی را بسیار مهم می‌کنند بیاندازیم.به طور خلاصه، هدف تست پرفورمنس، ارزیابی پاسخگویی، سرعت، مقیاس پذیری و پایداری یک سیستم نرم افزاری تحت شرایط کاری مختلف است. این تست تضمین می کند که برنامه بهینه عمل می کند و انتظارات کارایی عملکرد را برآورده می کند.Why is software performance testing important?Simply put, it ensures that the software application meets the performance expectations of users and stakeholders. It enables organizations to identify and resolve issues related to response times, low latency, throughput, resource usage, and stability. By proactively addressing performance issues, organizations can increase user satisfaction, reduce downtime, improve customer retention and protect brand reputation. Whether it is a robust enterprise software accounting system, a metasearch travel engine, or a social media platform, software performance is critical to all of these projects.چرا تست کارایی مهم است؟به عبارت ساده، این تست تضمین می کند که انتظارات کاربران و ذینفعان از کارایی نرم افزار برآورده می شود. این تست سازمان ها را قادر می سازد تا مسائل مربوط به زمان پاسخ، تاخیر کم، توان عملیاتی، استفاده از منابع و پایداری را شناسایی و حل کنند. با پرداختن فعالانه به مسائل کارایی، سازمان ها می توانند رضایت کاربر را افزایش دهند، زمان خرابی را کاهش دهند، حفظ مشتری را بهبود بخشند و از آبروی برندشان محافظت کنند. مهم نیست پروژه شما چه باشد؛ چه یک سیستم حسابداری سازمانی قوی، چه یک موتور جستجوی مسافرتی یا یک پلتفرم رسانه های اجتماعی، همه پروژه ها باید از کارایی بالایی برخوردار باشند و انجام این تست برای همه این پروژه ها حیاتی است.انواع تست کارایی نرم افزار (Performance Testing)Load TestingLoad testing is a type of software testing that evaluates the performance and behavior of a system under specific user loads and concurrent user activity. It helps identify the system’s capacity limits, potential bottlenecks, and performance degradation to ensure that it can handle the expected workload without compromising functionality or responsiveness.تست بارتست بار (Load Testing) نوعی تست است که عملکرد و رفتار یک سیستم را تحت بارهای خاص کاربر و فعالیت همزمان کاربران ارزیابی می کند. به کمک این تست محدودیت‌های ظرفیت و تنگناهای بالقوه (potential bottlenecks) شناسایی شده و اطمینان حاصل میشود که پروژه می‌تواند حجم کاری مورد انتظار را بدون به خطر انداختن عملکرد یا زمان پاسخگویی، مدیریت کند.Stress TestingStress testing is a type of software testing that evaluates the robustness and stability of a system under extreme or abnormal conditions. By subjecting the system to exceptionally high user loads, excessive data volumes, or limited system resources, stress testing aims to identify the system’s breaking points, potential failures, or performance degradation.تست استرستست استرس نوعی تست نرم افزار است که استحکام و پایداری یک سیستم را در شرایط شدید یا غیرعادی ارزیابی می کند؛ با قرار دادن سیستم در معرض بارهای بسیار بالای کاربر، حجم داده های بیش از حد، یا منابع محدود سیستم. هدف تست استرس شناسایی نقاط شکست، خرابی های احتمالی یا کاهش عملکرد سیستم است.Spike TestingIn spike testing, the application is subjected to a significant increase or decrease in load to evaluate its ability to handle abrupt changes and determine the impact on the user experience. The primary objective is to assess how effectively the software handles sudden load changes and whether it affects the overall user experience.تست اسپایکدر تست اسپایک، برنامه در معرض افزایش یا کاهش قابل توجهی در بار قرار می‌گیرد تا توانایی آن در کنترل تغییرات ناگهانی و تاثیر آن بر تجربه کاربر را ارزیابی کند. هدف اصلی این تست ارزیابی توانایی نرم افزار است که تا چه اندازه با تغییرات بارگذاری ناگهانی موثر برخورد می کند و آیا بر تجربه کلی کاربر تأثیر می گذارد یا خیر.Endurance TestingEndurance testing is another form of performance testing that aims to determine whether an application can withstand a significant load, this time over an extended period of time. The focus of endurance testing is primarily on assessing the application’s performance in terms of memory usage and its ability to endure prolonged use without degradation.تست استقامتتست استقامت شکل دیگری از تست کارایی است که با هدف تعیین اینکه آیا یک برنامه می تواند بار قابل توجهی را در یک دوره زمانی طولانی تحمل کند؟ تمرکز تست استقامت در درجه اول بر ارزیابی عملکرد برنامه از نظر استفاده از حافظه و توانایی آن در تحمل استفاده طولانی مدت بدون تخریب است.Scalability testingScalability tests are specifically designed to evaluate the system’s capacity to handle increasing amounts of data as more hardware resources are allocated to it. These tests aim to assess the system’s ability to efficiently process larger workloads, ensuring that the performance scales in proportion to the additional hardware resources dedicated to it.تست مقیاس پذیریتست‌های مقیاس‌پذیری به‌طور خاص برای ارزیابی ظرفیت سیستم در مواجهه با افزایش حجم داده‌ با تخصیص منابع سخت‌افزاری بیشتر به آن طراحی شده‌اند. هدف این تست ها ارزیابی توانایی سیستم در پردازش کارآمد حجم بالای بار است و اطمینان حاصل می‌کند که با اختصاص منابع سخت افزاری بیشتر، کارایی سیستم هم متناسب با آن افزایش می یابد.قسمت های بعدی:انواع تست نرم افزار - قسمت ۹ (Security, Usability and Compatibility testing)انواع تست نرم افزار - قسمت ۱۰ (سخن پایانی)لینک مطلب اصلی:https://stratoflow.com/types-of-software-testing

انواع تست نرم افزار - قسمت ۷ (User Acceptance testing)

امید آرام - توسعه دهنده نرم افزار — Mon, 08 Jul 2024 16:48:51 +0330

انواع تست نرم افزار - قسمت ۶ (System testing)

امید آرام - توسعه دهنده نرم افزار — Mon, 08 Jul 2024 16:44:02 +0330

انواع تست نرم افزار - قسمت ۵ (Integration testing)

امید آرام - توسعه دهنده نرم افزار — Mon, 08 Jul 2024 16:40:14 +0330

قسمت های قبلی:انواع تست نرم افزار - قسمت ۱ (مقدمه)انواع تست نرم افزار - قسمت ۲ (Manual vs. Automated vs. Continuous)انواع تست نرم افزار - قسمت ۳ (Functional vs. non-functional testing)انواع تست نرم افزار - قسمت ۴ (Unit testing)انواع تست عملکردی نرم افزارIntegration testingNext on the list is integration testing, which is a key software testing type that evaluates how well the system communicates between different components or modules.It validates that these components integrate and work together smoothly. Bottom up integration testing verifies that data flows correctly between modules, dependencies are accurately managed, and overall system functionality is not compromised.It identifies problems such as incorrect data transfer, inconsistent interfaces, or faulty interactions that may occur during the integration process. Integration testing plays a critical role in ensuring that each part of the software system works in tandem to achieve the desired functionality. There are two main subtypes of integration testing:تست یکپارچه سازیمورد بعدی در لیست تست های عملکردی نرم افزار، تست یکپارچه سازی است که یک نوع تست کلیدی است که میزان ارتباط بین اجزا یا ماژول های مختلف را ارزیابی می کند.این تست تأیید می کند که کامپوننت ها به درستی یکپارچه شده و با هم کار می کنند؛ یعنی جریان داده ها از پایین به بالا صحیح است و وابستگی ها به طور دقیق مدیریت شده اند و عملکرد کلی سیستم به خطر نمی افتد.این تست مشکلاتی مانند انتقال نادرست داده، رابط های ناسازگار، یا تعاملات معیوب را که ممکن است در طول فرآیند یکپارچه سازی رخ دهد، شناسایی می کند. همچنین اطمینان حاصل میکند از اینکه هر بخش از سیستم نرم افزاری پشت سر هم کار می کند تا به عملکرد مورد نظر دست یابد. دو نوع اصلی تست یکپارچه سازی وجود دارد:1. Incremental TestingThis approach works best when there’s a clear relationship between software modules. Developers take two modules and verify the flow of data between them. If the integration between them works well, they can add another module and test again. In other words, we can say that developers incrementally add modules and test the data flow in the integration between them.There are also two types of incremental testing, called top-down and bottom-up approaches, which are based on the parent-child relationship within the system. The incremental method allows early detection and resolution of integration problems and reduces the complexity of testing.۱. تست افزایشیاین روش زمانی بهتر کار می کند که یک رابطه واضح بین ماژول های نرم افزار وجود داشته باشد. توسعه دهندگان دو ماژول را در نظر می گیرند و جریان داده ها بین آنها را تأیید می کنند. اگر یکپارچه سازی آنها به خوبی انجام شود، می توانند ماژول دیگری اضافه کنند و دوباره تست کنند. به عبارت دیگر، می توان گفت که توسعه دهندگان به صورت تدریجی ماژول ها را اضافه می کنند و جریان داده ها را در یکپارچگی بین آنها تست می کنند.همچنین دو نوع تست افزایشی به نام رویکردهای بالا به پایین (top-down) و پایین به بالا (bottom-up) وجود دارد که بر اساس رابطه والد-فرزند درون سیستم است. تست افزایشی امکان تشخیص و حل زودهنگام مشکلات یکپارچه سازی را فراهم می کند و پیچیدگی تست را کاهش می دهد.2. Non-incremental testingIf the data flow is complex and there are difficulties in classifying parent-child relationships, developers can choose the non-incremental integration testing approach, also known as the big bang method. This method may be appropriate for smaller software projects or when all components are readily available and stable.Example of integration testing process:A team of developers is working on a software application that consists of a web-based front-end, a middleware data processing layer, and a back-end database. They are setting up integration tests to verify that data submitted to the front-end is properly processed by the middleware and then stored in the underlying database.۲. تست غیر افزایشیاگر جریان داده پیچیده باشد و در طبقه‌بندی روابط والدین و فرزند مشکلاتی وجود داشته باشد، توسعه‌دهندگان می‌توانند رویکرد تست یکپارچه‌سازی غیرافزایشی را انتخاب کنند که به عنوان روش «بیگ بنگ» نیز شناخته می‌شود. این روش ممکن است برای پروژه های نرم افزاری کوچکتر یا زمانی که همه اجزا به راحتی در دسترس و پایدار هستند مناسب باشد.نمونه ای از فرآیند تست یکپارچه سازی:تیمی از توسعه دهندگان در حال کار بر روی یک نرم افزار هستند که شامل یک فرانت اند مبتنی بر وب، یک لایه پردازش میانی و یک پایگاه داده است. آنها تست‌های یکپارچه‌سازی را انجام میدهند تا تأیید کنند که داده‌های ارسال شده به فرانت‌اند به‌درستی توسط لایه میانی پردازش شده و سپس در پایگاه داده ذخیره می‌شوند.قسمت های بعدی:انواع تست نرم افزار - قسمت ۶ (System testing)انواع تست نرم افزار - قسمت ۷ (User Acceptance testing)انواع تست نرم افزار - قسمت ۸ (Performance testing)انواع تست نرم افزار - قسمت ۹ (Security, Usability and Compatibility testing)انواع تست نرم افزار - قسمت ۱۰ (سخن پایانی)لینک مطلب اصلی:https://stratoflow.com/types-of-software-testing

انواع تست نرم افزار - قسمت ۴ (Unit testing)

امید آرام - توسعه دهنده نرم افزار — Mon, 08 Jul 2024 16:36:23 +0330

قسمت های قبلی:انواع تست نرم افزار - قسمت ۱ (مقدمه)انواع تست نرم افزار - قسمت ۲ (Manual vs. Automated vs. Continuous)انواع تست نرم افزار - قسمت ۳ (Functional vs. non-functional testing)انواع تست عملکردی نرم افزارUnit testingLet’s start with the most basic type of software testing – unit testing. Sometimes called component testing, unit testing focuses on verifying the individual units or components of a given software system.It involves testing small, independent units of code to ensure that they work as intended. Unit testing is typically performed manually by developers, using white-box testing techniques that delve into the internal logic and structure of the code itself. By testing individual units in isolation, developers can identify defects early in the development cycle and promote code reusability and maintainability. Unit testing can be seen as the foundation for building robust and reliable software systems.تست واحدبیایید با ابتدایی ترین نوع تست نرم افزار یعنی تست واحد (Unit testing) شروع کنیم. گاهی اوقات تست کامپوننت (Component testing) هم نامیده می شود. تست واحد بر صحه گذاری روی واحدها یا اجزای سیستم تمرکز می کند.این شامل تست کوچک ترین واحدهای کد است تا اطمینان حاصل شود که آنها عملکردی مطابق آنچه انتظار میرود دارند. تست واحد معمولاً به صورت دستی توسط توسعه دهندگان انجام می شود و از تکنیک های تست جعبه سفید (white-box) استفاده میکنند که به منطق داخلی و ساختار خود کد می پردازد. با تست واحدهای مجزا، توسعه‌دهندگان می‌توانند نقص‌ها را سریعتر شناسایی کرده و قابلیت استفاده مجدد و نگهداری کد را ارتقا دهند. تست واحد را می توان پایه و اساس ایجاد یک سیستم نرم افزاری قوی و قابل اعتماد دانست.Unit TestsCommon unit tests may include: * Data flow testing, * Branch coverage testing, * Control flow testing, * Statement Coverage Testing,Example of a unit test:A developer has created a password input text field with a validation value that must contain at least 8 characters and special characters. He then sets up a unit test to verify this one specific text field by entering a password that has fewer characters, no special characters, an empty field, etc.تست های واحد رایج ممکن است شامل موارد زیر باشد:تست جریان داده (Data Flow)تست پوشش دهی شاخه ها (Branch Coverage)تست جریان کنترل (Control Flow)تست پوشش دهی دستورات (Statement Coverage)نمونه ای از تست واحد:برنامه‌نویس یک فیلد ورودی رمز عبور با این شرط ایجاد کرده است که باید طول آن حداقل 8 و شامل کاراکترهای خاص باشد. سپس برای اینکه مطمئن شود که این شرط رعایت میشود، یک تست واحد مینویسد که این فیلد را در برابر وارد کردن رمز عبوری با کاراکترهای کمتر، بدون کاراکترهای خاص، یک فیلد خالی و غیره کنترل کند.قسمت های بعدی:انواع تست نرم افزار - قسمت ۵ (Integration testing)انواع تست نرم افزار - قسمت ۶ (System testing)انواع تست نرم افزار - قسمت ۷ (User Acceptance testing)انواع تست نرم افزار - قسمت ۸ (Performance testing)انواع تست نرم افزار - قسمت ۹ (Security, Usability and Compatibility testing)انواع تست نرم افزار - قسمت ۱۰ (سخن پایانی)لینک مطلب اصلی:https://stratoflow.com/types-of-software-testing

انواع تست نرم افزار - قسمت ۳ (Functional vs. non-functional testing)

امید آرام - توسعه دهنده نرم افزار — Mon, 08 Jul 2024 16:25:36 +0330

قسمت های قبلی:انواع تست نرم افزار - قسمت ۱ (مقدمه)انواع تست نرم افزار - قسمت ۲ (Manual vs. Automated vs. Continuous)Functional vs. non-functional testingNow let’s move to the next level of our diagram and look at functional and non-functional testing.These are the categories that really divide software testing into two distinct groups, each performed with different goals in mind.Functional testing revolves around evaluating whether the application works as intended, performs the desired actions, and produces accurate results. Functional testing evaluates the behavior of the software in various scenarios to ensure that it works properly and delivers the expected results. Testers simulate user interactions, input various data sets, and examine the software’s responses.If we compare software testing to a construction supervisor making a final check of the building before the project is completed, functional testing would be equivalent to verifying that all the basic requirements from the architect’s blueprint are met. It checks that the rooms have the right dimensions, and that all the doors and windows are in the right places.تست عملکردی در مقابل تست غیر عملکردیحالا بیایید به سطح بعدی نمودار خود برویم و به تست عملکردی و غیر عملکردی نگاه کنیم.اینها دسته بندی هایی هستند که واقعاً تست نرم افزار را به دو گروه مجزا تقسیم می کنند که هر کدام با اهداف متفاوتی انجام می شوند.تست عملکردی این را ارزیابی میکند که آیا برنامه مطابق آنچه مورد انتظار هست کار می کند؟ و اینکه اقدامات مورد نظر را به درستی انجام می دهد یا نه؟ تست عملکردی رفتار نرم افزار را در سناریوهای مختلف ارزیابی می کند تا اطمینان حاصل شود که به درستی کار می کند و نتایج مورد انتظار را ارائه می دهد. تسترها رفتارهای کاربر را شبیه سازی می کنند و مجموعه داده های مختلفی را وارد می کنند و پاسخ های نرم افزار را مورد بررسی قرار می دهند.اگر تست نرم‌افزار را با یک مهندس ناظر ساختمان مقایسه کنیم، تست عملکردی معادل تأیید این است که تمام الزامات اولیه از طرح معمار برآورده شده است. یعنی بررسی می‌کند که اتاق‌ها ابعاد درستی داشته باشند و همه درها و پنجره‌ها در مکان‌های مناسب قرار داشته باشند.Non-functional testing, on the other hand, shifts the focus beyond functional requirements to examine other critical aspects of software quality.Non-functional testing evaluates how the software performs in terms of attributes such as scalability, reliability, usability, performance, and security. It evaluates the software’s response time, its ability to handle concurrent users or heavy loads, its resilience under stress, and its adherence to security protocols. Non-functional testing ensures that the software is not only functionally sound, but also provides a superior user experience and meets performance expectations.Going back to our construction manager example, non-functional testing would go a bit deeper. It would include things like verifying that the ceiling can support the load we want, that the walls are keeping the heat in, and that the site is prepared for future expansion of our building.Now that we’ve covered the basics, we can move to the next level of our diagram and cover all the different types of functional and non-functional testing.از سوی دیگر، تست غیرعملکردی، تمرکز را فراتر از الزامات تست عملکردی میبرد و سایر جنبه‌های حیاتی کیفیت نرم‌افزار بررسی میکند.تست غیرعملکردی نحوه عملکرد نرم افزار را از نظر ویژگی هایی مانند مقیاس پذیری، قابلیت اطمینان، قابلیت استفاده، عملکرد و امنیت ارزیابی می کند. همچنین زمان پاسخ‌دهی نرم‌افزار، توانایی آن در مدیریت همزمان کاربران یا بارهای سنگین، انعطاف‌پذیری آن در برابر استرس، و پایبندی آن به پروتکل‌های امنیتی را مورد بررسی قرار می‌دهد. تست غیرعملکردی تضمین می‌کند که نرم‌افزار نه تنها از نظر عملکردی سالم است، بلکه تجربه‌ای عالی برای کاربر فراهم می‌کند و الزامات بهره وری نرم افزار را نیز رعایت کرده است.اگر به مثال مهندس ناظر ساختمان برگردیم، تست غیرعملکردی کمی عمیق تر خواهد بود. این شامل مواردی مانند تأیید این است که سقف می تواند بار مورد نظر ما را تحمل کند، دیوارها گرما را در خود نگه می دارند و اینکه سازه برای ادامه ساخت و ساز آماده شده است.اکنون که اصول اولیه را بیان کردیم، می‌توانیم به سطح بعدی نمودار خود برویم و در مورد انواع مختلف تست‌های عملکردی و غیرعملکردی را صحبت کنیم.نمونه هایی از تست عملکردی نرم افزارExamples of functional software testing نمونه هایی از تست غیرعملکردی نرم افزارExamples of non-functional testing قسمت های بعدی:انواع تست نرم افزار - قسمت ۴ (Unit testing)انواع تست نرم افزار - قسمت ۵ (Integration testing)انواع تست نرم افزار - قسمت ۶ (System testing)انواع تست نرم افزار - قسمت ۷ (User Acceptance testing)انواع تست نرم افزار - قسمت ۸ (Performance testing)انواع تست نرم افزار - قسمت ۹ (Security, Usability and Compatibility testing)انواع تست نرم افزار - قسمت ۱۰ (سخن پایانی)لینک مطلب اصلی:https://stratoflow.com/types-of-software-testing

انواع تست نرم افزار - قسمت ۲ (Manual vs. Automated vs. Continuous)

امید آرام - توسعه دهنده نرم افزار — Mon, 08 Jul 2024 16:05:11 +0330

قسمت قبلی:انواع تست نرم افزار - قسمت ۱ (مقدمه)Manual vs. Automated vs. Continuous TestingLet’s start our journey from the roots of your tree by comparing the three main primary approaches to software testing that dominate the landscape: manual testing, automated testing, and continuous testing.You may also notice that this level of our diagram is somewhat intertwined with the categories on the level below it. What does this mean?It’s hard to categorize which software tests can be automated and which can’t. In some circumstances, it is both, while in others the manual approach is the only possible choice. So, for simplicity’s sake, we’ve put this categorization at the bottom, so that our graph doesn’t look like a complex Penrose diagram. Just keep in mind that.So, with that clarification out of the way, let’s move on to the first categorization based on how the testing process is performed.تست دستی، تست خودکار و تست مداومبیایید از مقایسه سه رویکرد اصلی تست نرم‌افزار شروع کنیم: تست دستی (Manual)، تست خودکار (Automated) و تست مداوم (Continuous).در ابتدا توجه داشته باشید که بسیار سخت است که بگوییم کدام تست میتواند خودکار انجام شود و کدام یک نمیشود. در برخی شرایط، یک تست میتواند هم دستی انجام شود هم خودکار؛ و در برخی موارد، رویکرد دستی تنها انتخاب ممکن است. بنابراین، برای سادگی، ما اینگونه دسته بندی کرده ایم تا نمودار ما شبیه یک نمودار Penrose پیچیده نباشد. حال بیایید به اولین دسته‌بندی بر اساس نحوه انجام فرآیند تست بپردازیم.Manual testingManual testing involves human testers meticulously executing test cases, simulating user interactions, and observing software behavior. It requires human intuition, expertise, and attention to detail. Manual testing excels in situations where subjective evaluation, exploratory testing, and ad hoc testing are required. It is especially useful when:* Testing user interfaces, usability, and user experience,* Assessing software behavior in unpredictable scenarios,* Evaluating the aesthetics and overall feel of the application.تست دستیتست دستی اینگونه است که افرادی (تِسترها) با دقت، موارد تست را اجرا می‌کنند، تعاملات کاربر را شبیه‌سازی می‌کنند و رفتار نرم‌افزار را مشاهده می‌کنند. اینکار بصیرت انسانی را میطلبد و همچنین نیاز به تخصص و توجه به جزئیات دارد. تست دستی در شرایطی که ارزیابی ذهنی، تست اکتشافی (exploratory testing) و تست موقت (ad hoc testing) مورد نیاز است، برتری دارد. به ویژه زمانی مفید است که:در حال تست رابط کاربری (UI)، قابلیت استفاده (Usability) و تجربه کاربری (UX) هستید،در حال ارزیابی رفتار نرم افزار در سناریوهای غیر قابل پیش بینی هستید،در حال ارزیابی زیبایی شناسی و احساس کلی برنامه هستید.Automated testingAutomation testing uses specialized software tools to execute predefined test cases and compare actual results with expected results. It accelerates the testing process, increases efficiency, and enables test iteration. Automated testing is ideal for scenarios such as:* Regression testing to ensure that modifications don’t introduce new defects.* Performance testing to evaluate system response times and resource utilization.* Load testing to measure software stability under high user volumes.Automation testing requires an initial investment to set up the test environment, create test scripts, and select appropriate tools. It requires technical expertise to develop and maintain automated test suites. While automated testing reduces the effort required for repetitive tasks, it may lack the human element to detect certain nuances that manual testing excels at.تست خودکارتست خودکار از ابزارهایی استفاده میکند تا موارد تست از پیش تعریف شده را اجرا کند و نتایج آن را با نتایج مورد انتظار مقایسه کند. این فرآیند تست را تسریع می کند، کارایی را افزایش می دهد و تکرار تست را امکان پذیر می سازد. تست خودکار برای سناریوهایی مانند موارد زیر ایده آل است:تست رگرسیون، برای اطمینان از عدم ایجاد خطای جدید در اصلاحات کد.تست عملکرد، برای ارزیابی زمان پاسخ سیستم و استفاده از منابع.تست بار، برای اندازه گیری پایداری نرم افزار در حجم بالای کاربر.تست اتوماسیون نیاز به سرمایه گذاری اولیه برای راه اندازی محیط تست، ایجاد اسکریپت های تست و انتخاب ابزار مناسب دارد. توسعه و نگهداری این تست های خودکار، نیازمند داشتن تخصص فنی است. با وجود اینکه تست خودکار کارهای تکراری را کاهش می دهد، اما ممکن است فاقد عنصر انسانی برای تشخیص ظرایف خاصی باشد که تست دستی در آنها برتری دارد.Continuous testingContinuous testing integrates testing activities throughout the entire software development process, ensuring quick feedback and rapid defect resolution. It combines manual and automated testing approaches and leverages test automation frameworks and tools. Continuous testing is particularly valuable in scenarios like:* Agile and DevOps environments where continuous integration and deployment are key.* Projects that require frequent software updates and iterative development.* Complex systems that demand constant quality assurance.Continuous testing requires a robust test automation infrastructure, comprehensive test suites, and a well-defined feedback loop. It requires collaboration between development and testing teams to enable a streamlined process for identifying and fixing defects early in the development cycle.تست مداومتست مداوم، فعالیت‌های تست را در کل فرآیند توسعه نرم‌افزار، یکپارچه می‌کند و اطمینان میدهد که فیدبک ها را سریع دریافت و رفع نمایید. این روش‌های تست دستی و خودکار را ترکیب می‌کند و از فریم ورک ها و ابزارهای اتوماسیون تست استفاده می‌کند. تست مداوم به ویژه در سناریوهایی مانند موارد زیر ارزشمند است:محیط‌های Agile و DevOps که در آن یکپارچه‌سازی مداوم (CI) و استقرار مداوم (CD) کلیدی است.پروژه هایی که نیاز به آپدیت مکرر نرم افزار و توسعه تکراری دارند.سیستم های پیچیده ای که نیاز به تضمین کیفیت ثابت دارند.آزمایش مداوم نیاز به زیرساخت اتوماسیون تست قوی، مجموعه های جامع تست و یک حلقه دریافت فیدبک دارد. این امر نیازمند همکاری بین تیم‌های تست و توسعه هست تا فرآیندی سریع و ساده برای شناسایی و رفع نقص‌ها ایجاد کنند.قسمت های بعدی:انواع تست نرم افزار - قسمت ۳ (Functional vs. non-functional testing)انواع تست نرم افزار - قسمت ۴ (Unit testing)انواع تست نرم افزار - قسمت ۵ (Integration testing)انواع تست نرم افزار - قسمت ۶ (System testing)انواع تست نرم افزار - قسمت ۷ (User Acceptance testing)انواع تست نرم افزار - قسمت ۸ (Performance testing)انواع تست نرم افزار - قسمت ۹ (Security, Usability and Compatibility testing)انواع تست نرم افزار - قسمت ۱۰ (سخن پایانی)لینک مطلب اصلی:https://stratoflow.com/types-of-software-testing

انواع تست نرم افزار - قسمت ۱ (مقدمه)

امید آرام - توسعه دهنده نرم افزار — Tue, 02 Jul 2024 18:28:38 +0330

Software developers, just like other engineers, always strive to make their results as clean and flawless as possible. But how do you achieve this when many software development projects involve tens of thousands of lines of code and countless tools, integrations, and frameworks? The answer is comprehensive software testing.In this article, we will explore the essential types of software testing that every engineer should be familiar with in order to achieve better results. From functional and non-functional testing to automated and continuous approaches, we will explore the most common testing methodologies and their unique characteristics.By understanding and applying these testing approaches, engineers can improve the quality of their software, increase user satisfaction, and pave the way for the success of their projects.توسعه دهندگان نرم افزار، درست مانند سایر مهندسان، همیشه در تلاش هستند تا نتایج خود را تا حد امکان تمیز و بی عیب و نقص ارائه دهند. اما وقتی بسیاری از پروژه‌های توسعه نرم‌افزار شامل ده‌ها هزار خط کد هستند و از ابزارها، فریم ورک های بی‌شماری استفاده کرده اند، چگونه می‌توان به این امر دست یافت؟ پاسخ تست جامع نرم افزار است.در این مقاله به بررسی انواع ضروری تست نرم افزار می پردازیم که هر مهندسی برای دستیابی به نتایج بهتر باید با آنها آشنا باشد. از تست عملکردی (functional) و غیر عملکردی (non-functional) گرفته تا رویکردهای خودکار (automated) و مداوم (continuous)، رایج‌ترین روش‌های تست و ویژگی‌های منحصر به فرد آن‌ها را بررسی خواهیم کرد.مهندسان با درک و بکارگیری این رویکردهای تست، می توانند کیفیت نرم افزار خود را بهبود بخشند، رضایت کاربران را افزایش دهند و راه را برای موفقیت پروژه های خود هموار کنند.Why software testing is so important?In the ever-evolving world of software development, the importance of software testing cannot be overstated. As technology plays an increasingly integral role in our lives, the demand for high-quality software applications and systems has skyrocketed. Gone are the days when end users tolerated long load times, minor bugs, or unintuitive user interfaces.Now, if something is not up to the highest standards, they will simply go to the competition.This is where software testing emerges as a critical process that ensures the reliability, functionality, and overall performance of software products. Software testing serves as a safeguard against potential bugs and defects that may interfere with the smooth operation of an application.The primary goal of software testing is to mitigate risk and provide confidence that the software will perform as expected. By conducting comprehensive testing throughout the software development life cycle, engineers can validate that the software meets the specified requirements, functions seamlessly in different environments, and is robust under varying conditions.Software testing also helps improve the user experience. By thoroughly evaluating usability, interface design, and performance, engineers can ensure that the software meets the needs and expectations of its intended users.And of course, there’s another, far more trivial factor that software developers understand perfectly – doing all the necessary software testing upfront saves you from having to put out dumpster fires in production. The more time you spend properly testing your code, the fewer problems you will encounter later – simple as that.چرا تست نرم افزار اینقدر مهم است؟در دنیای همیشه در حال توسعه نرم افزار، اهمیت تست نرم افزار را نمی توان نادیده گرفت. از آنجایی که فناوری نقش مهمی را در زندگی ما ایفا می کند، تقاضا برای برنامه ها و سیستم های نرم افزاری با کیفیت بالا به شدت افزایش یافته است. روزهایی که کاربران، لودهای طولانی، تعدادی باگ و UIهای نامناسب را تحمل می کردند، گذشته است.حالا اگر چیزی مطابق با بالاترین استانداردها نباشد، آنها به سادگی از رقابت جا می مانند.اینجاست که تست نرم افزار به عنوان یک فرآیند حیاتی ظاهر می شود که قابلیت اطمینان، عملکرد و عملکرد کلی محصولات نرم افزاری را تضمین می کند. تست نرم افزار به عنوان محافظی در برابر باگ ها و نقص های احتمالی که ممکن است در عملکرد روان برنامه اختلال ایجاد کند، عمل می کند.هدف اولیه تست نرم افزار، کاهش ریسک و ایجاد اطمینان از اینکه نرم افزار مطابق انتظار عمل خواهد کرد، است. با انجام آزمایشات جامع در طول چرخه عمر توسعه نرم افزار (SDLC)، مهندسان می توانند تأیید کنند که نرم افزار نیازمندی های مشخص شده را برآورده می کند، به طور یکپارچه در محیط های مختلف کار می کند و در شرایط مختلف قابل اتکا است.تست نرم افزار همچنین به بهبود تجربه کاربر (UX) کمک می کند. مهندسان با ارزیابی کامل قابلیت استفاده (usability)، طراحی رابط (interface design) و عملکرد (performance)، می توانند اطمینان حاصل کنند که نرم افزار، نیازها و انتظارات کاربران مورد نظر خود را برآورده می کند.و البته، یک عامل بسیار پیش پاافتاده دیگر وجود دارد که توسعه دهندگان نرم افزار کاملاً آن را درک می کنند: انجام به موقع تست های ضروری نرم افزار، شما را از خاموش کردن آتش ایجاد شده در اثر باگ های آتی نجات می دهد (پیشگیری بهتر از درمان است). هرچه زمان بیشتری را صرف آزمایش صحیح کد خود کنید، بعداً با مشکلات کمتری روبرو خواهید شد - به همین سادگی.Main Types of software testingSoftware testing is an extremely robust field where each key category branches out into different sub-fields that are just as important. Below, we gave our best shot to visualize this whole ecosystem of software tests in one, single graph just like an upside-down tree.انواع اصلی تست نرم افزارتست نرم افزار یک فیلد بسیار قوی است که در آن هر دسته کلیدی، به زیرفیلدهای مختلفی تقسیم می شود که به همان اندازه مهم هستند. در زیر، ما بهترین عکس خود را برای تجسم کل این اکوسیستم ‌در یک نمودار واحد، درست مانند یک درخت وارونه ارائه کردیم.It looks rather complicated, doesn’t it?As you can see, we’ve broken it down into four levels – each covering more specialized categories that go into more detail about testing specific parts of software products. At the lowest level, we’ve got 21 different types of software testing – hence the title of this article. These are the main types that most software developers will encounter in one way or another during their projects.Keep in mind that not every software development project requires the use of every single type of software tests. Some projects, such as search engines for travel agencies, may require top-notch performance and incredible responsiveness to meet user expectations. Others, such as an internal application for processing company documents, may be less concerned with software performance and more focused on software security issues. The key takeaway is that each custom software development project will utilize different types of software testing based on it’s specific requirements.نسبتاً پیچیده به نظر می رسد، اینطور نیست؟همانطور که می بینید، ما آن را به چهار سطح تقسیم کرده ایم - هر کدام دسته های تخصصی تری را پوشش می دهد که به جزئیات بیشتری در مورد تست بخش های خاص محصولات نرم افزاری می پردازد. در پایین‌ترین سطح، ما 21 نوع مختلف تست نرم‌افزاری را داریم. اینها انواع اصلی هستند که اکثر توسعه دهندگان نرم افزار به نوعی در طول پروژه های خود با آنها مواجه می شوند.به خاطر داشته باشید که همه پروژه های توسعه نرم افزار، نیازی به استفاده از همه انواع تست ندارند. برخی از پروژه‌ها، مانند موتورهای جستجو برای آژانس‌های مسافرتی، ممکن است برای برآورده کردن انتظارات کاربر، به عملکرد عالی و پاسخ‌گویی باورنکردنی نیاز داشته باشند. برخی دیگر، مانند یک برنامه داخلی برای پردازش اسناد شرکت، ممکن است کمتر به پرفورمنس نرم افزار توجه داشته باشند و بیشتر بر مسائل امنیتی نرم افزار متمرکز شوند. نکته کلیدی این است که هر پروژه توسعه نرم افزار سفارشی، از انواع مختلف تست نرم افزار بر اساس نیازهای خاص خود استفاده می کند.قسمت های بعدی:انواع تست نرم افزار - قسمت ۲ (Manual vs. Automated vs. Continuous)انواع تست نرم افزار - قسمت ۳ (Functional vs. non-functional testing)انواع تست نرم افزار - قسمت ۴ (Unit testing)انواع تست نرم افزار - قسمت ۵ (Integration testing)انواع تست نرم افزار - قسمت ۶ (System testing)انواع تست نرم افزار - قسمت ۷ (User Acceptance testing)انواع تست نرم افزار - قسمت ۸ (Performance testing)انواع تست نرم افزار - قسمت ۹ (Security, Usability and Compatibility testing)انواع تست نرم افزار - قسمت ۱۰ (سخن پایانی)لینک مطلب اصلی:https://stratoflow.com/types-of-software-testing

اصطلاحات Tightly Coupled و Loosely Coupled در کدنویسی

امید آرام - توسعه دهنده نرم افزار — Mon, 01 Jul 2024 15:13:13 +0330

In software development, the terms "tightly coupled" and "loosely coupled" refer to the degree to which components of a system depends on each other.در توسعه نرم‌افزار، اصطلاحات «tightly coupled» و «loosely coupled» به میزان وابستگی اجزای یک سیستم به یکدیگر اشاره دارد.Tightly Coupled Code: Tightly coupled code is when a group of classes are highly dependent on one another. This isn't necessarily a bad thing, but it can make the code harder to test because of the dependent classes are so intertwined. They can't be used independently or substituted easily.In tightly coupled systems, each component or class in the system knows details about many other components or classes. They are interdependent, meaning that if one component changes, it can have a ripple effect on all other components that depend on it. This can make the system as a whole more difficult to maintain, because changes in one place can require changes in many other places.Tightly coupled systems can also be more difficult to test, because each component might rely on many other components to function correctly. This means that to test just one component, you might need to also set up and manage many other components.Here's an example of tightly coupled code in C#:کد Tightly Coupled: کدی است که در آن گروهی از کلاس ها به شدت به یکدیگر وابسته هستند. این لزوماً چیز بدی نیست، اما می‌تواند تست کد را سخت‌تر کند زیرا کلاس‌های وابسته بسیار در هم تنیده شده‌اند. آنها را نمی توان به طور مستقل استفاده کرد یا به راحتی جایگزین کرد.در سیستم‌های tightly coupled، هر جزء یا کلاسی در سیستم، جزئیات بسیاری از اجزا یا کلاس‌های دیگر را می‌داند. آنها به یکدیگر وابسته هستند، به این معنی که اگر یک جزء تغییر کند، موجی از تغییرات بر سایر اجزای وابسته به آن خواهید داشت. این می تواند حفظ سیستم را به طور کلی دشوارتر کند، زیرا تغییرات در یک مکان منجر به تغییرات در بسیاری از مکان های دیگر میشود.تست کردن سیستم‌های tightly coupled نیز دشوارتر است، زیرا هر جزء ممکن است برای عملکرد صحیح به بسیاری از اجزای دیگر متکی باشد. این بدان معنی است که برای تست فقط یک کامپوننت، ممکن است لازم باشد بسیاری از کامپوننت های دیگر را نیز تنظیم و مدیریت کنید.در اینجا یک مثال از کدهای tightly coupled در #C آمده است:public class Customer { public int Id {get; set; } public string Name {get; set; } } public class CustomerBusinessLogic { public CustomerBusinessLogic() { _customerDataAccess = new CustomerDataAccess(); } private CustomerDataAccess _customerDataAccess; }ExplainIn this example, CustomerBusinessLogic is tightly coupled to CustomerDataAccess. It directly instantiates CustomerDataAccess, making it difficult to substitute a different implementation of mock it for testing.در این مثال، CustomerBusinessLogic به شدت با CustomerDataAccess وابستگی دارد چرا که مستقیماً یک آبجکت از آن ساخته است، و باعث شده است که جایگزینی آن با یک کلاس mock برای تست، دشوار (یا عملاً غیرممکن) شود.Loosely Coupled Code: Loosely coupled code is when the components are made independent as much as possible. This is generally considered a good practice as it makes the code more flexible, easier to reuse, and easier to test because components can be tested independently and substituted easily.In loosely coupled systems, components or classes are designed to interact with each other as little as possible. They still communicate and interact, but they do so through well-defined interfaces, without needing to know the details of how other components are implemented.1. Easier Maintenance: Because each component is independent, changes in one component don't require changes in other components. This makes the system as a whole easier to maintain.2. Improved Testability: Components can be tested independently, without needing to set up and manage other components. This makes it easier to write unit tests, and makes the tests more reliable, because they're less likely to be affected by changes in other parts of the system.3. Greater Flexibility and Reusability: Because components don't depend on each other, they can be more easily reused in different parts of the system, or even in different systems. They can also be replaced or upgraded without affecting other components.Here's an example of loosely coupled code in C#:کد Loosely Coupled: کدی است که اجزا آن تا حد امکان مستقل ساخته شوند. این به طور کلی یک ویژگی خوب به حساب می آید، زیرا کد را انعطاف‌پذیرتر میکند و استفاده مجدد از آن را آسان‌تر می‌کند. همچنین تست آن کد را آسان‌تر می‌کند، چرا که اجزا را می‌توان به‌طور مستقل تست کرد و به راحتی جایگزین کرد.در سیستم‌های loosely coupled، اجزا یا کلاس‌ها طوری طراحی می‌شوند که تا حد امکان کمتر با یکدیگر تعامل داشته باشند. آنها هنوز هم ارتباط و تعامل دارند، اما این کار را از طریق Interfaceها (رابط ها) انجام می دهند، بدون اینکه نیاز داشته باشند جزئیات نحوه پیاده سازی سایر اجزا را بدانند.ویژگی های کد Loosely Coupled:نگهداری آسان تر: از آنجایی که هر جزء مستقل است، تغییر در یک جزء نیازی به تغییر در سایر اجزا ندارد. این امر نگهداری سیستم را در کل آسان تر می کند.افزایش قابلیت تست پذیری: کامپوننت ها را می توان به طور مستقل، بدون نیاز به راه اندازی و مدیریت اجزای دیگر، تست کرد. این کار نوشتن Unit Testها را آسان‌تر می‌کند و تست‌ها را قابل اعتمادتر می‌کند، زیرا احتمال کمتری دارد که تحت تأثیر تغییرات سایر بخش‌های سیستم قرار بگیرند.انعطاف پذیری (Flexibility) و قابلیت استفاده مجدد (Reusability) بیشتر : از آنجایی که اجزا به یکدیگر وابسته نیستند، می توان آنها را به راحتی در بخش های مختلف سیستم یا حتی در سیستم های مختلف مجدداً استفاده کرد. همچنین می‌توان آن‌ها را بدون تأثیرگذاری بر سایر اجزای آن جایگزین یا ارتقا داد.در اینجا مثالی از کدهای loosely coupled در #C آمده است:public interface ICustomerDataAccess { void Save(ICustomerDataAccess customer); } public class CustomerBusinessLogic { private ICustomerDataAccess _dataAccess; public CustomerBusinessLogic(ICustomerDataAccess dataAccess) { _dataAccess = dataAccess; } public void Save(CustomerBusinessLogic customer) { _dataAccess.Save(customer); } }ExplainHow to Achieve Loose Coupling:There are several techniques that can help achieve loose coupling:1. Dependency Injection: Instead of having components create the objects they depend on, those objects are created elsewhere and passed in (injected) to the component that needs them.2. Programming to Interfaces: Instead of having components interact with concrete classes, they interact with interfaces. This means that any class that implements the interface can be substituted in, without the component knowing or caring about the details of how that class is implemented.3. Event-Driven Programming: Instead of components calling each other directly, they emit events that other components can listen for and respond to. This allows components to communicate and interact without needing to know about each other.By using these techniques, you can create systems that are easier to maintain, test, and extend.Happy Coding...چندین تکنیک وجود دارد که می تواند به loosely coupled کمک کند:تزریق وابستگی (Dependency Injection): به جای اینکه کامپوننت ها اشیایی را که به آنها وابسته هستند ایجاد کنند، آن اشیا در جای دیگری ایجاد می شوند و به کامپوننتی که به آنها نیاز دارد پاس داده می شوند (تزریق می شوند).برنامه نویسی با Interfaceها: به جای اینکه کامپوننت ها مستقیم با متن کلاس ها تعامل داشته باشند، با Interfaceها تعامل دارند. این بدان معناست که هر کلاسی که آن Interface را پیاده‌سازی می‌کند، می‌تواند جایگزین شود، بدون اینکه کامپوننت بداند یا به جزئیات نحوه پیاده‌سازی آن کلاس اهمیت دهد.برنامه نویسی رویداد محور (Event-Driven): به جای اینکه کامپوننت ها مستقیماً یکدیگر را فراخوانی کنند، Eventهایی را منتشر می کنند که سایر کامپوننت ها می توانند به آنها گوش دهند و به آنها پاسخ دهند. این به کامپوننت ها اجازه می دهد تا بدون نیاز به دانستن در مورد یکدیگر، با یکدیگر ارتباط برقرار کرده و تعامل داشته باشند.با استفاده از این تکنیک‌ها، می‌توانید سیستم‌هایی ایجاد کنید که نگهداری، تست و توسعه آن‌ها آسان‌تر باشد.شاد باشید...(لینک مطلب اصلی: در اولین کامنت)

درک اصول SOLID

امید آرام - توسعه دهنده نرم افزار — Sat, 29 Jun 2024 15:27:30 +0330

اصول SOLIDSOLID principles make it easy for a developer to write easily extendable code and avoid common coding errors.These principles were introduced by Robert C. Martin, and they have become a fundamental part of object-oriented programming.In the context of .NET development, adhering to SOLID principles can lead to more modular, flexible, and maintainable code. In this article, we’ll delve into each SOLID principle with practical coding examples in C#.Following are the five SOLID Design Principles:رعایت اصول SOLID در کدنویسی، توسعه کد را برای توسعه‌دهندگان آسان تر می‌کند و از خطاهای رایج کدنویسی جلوگیری می‌کند.این اصول توسط رابرت سی. مارتین (عمو باب) معرفی شده اند و یکی از اساسی ترین بخش های برنامه نویسی شی گرا هستند.در زمینه توسعه دات نت، رعایت اصول SOLID می تواند باعث میشود کدهایی ماژولارتر، انعطاف پذیرتر و با قابلیت نگهداری بالاتر بنویسیم. در این مقاله، با ارائه مثال‌های کاربردی، به بررسی هر یک از اصول SOLID می‌پردازیم.در ادامه پنج اصل طراحی SOLID آمده است:1. Single Responsibility Principle (SRP)The SRP states that a class should have only one reason to change, meaning it should have only one responsibility. This promotes modularization and makes the code easier to understand and maintain.Key Idea: A class should do only one thing, and it should do it well.Real-Time Example: Think of a chef who only focuses on cooking, not managing the restaurant or delivering food.۱. اصل تک مسئولیتی (SRP)اصل SRP بیان می کند که یک کلاس باید تنها یک دلیل برای تغییر داشته باشد، به این معنی که باید فقط یک مسئولیت داشته باشد. رعایت این اصل، ماژولارسازی را ارتقا می‌دهد و درک و نگهداری کد را آسان‌تر می‌کند.ایده اصلی: یک کلاس باید فقط یک کار را انجام دهد و آن را به خوبی انجام دهد.مثال در دنیای واقعی: سرآشپزی را در نظر بگیرید که فقط روی آشپزی تمرکز می کند، نه مدیریت رستوران یا تحویل غذا.مثال کاربردی در #C:قبل از اعمالSRP:public class Report { public void GenerateReport() { } public void SaveToFile() { } }In this scenario, the Report class has two responsibilities: generating a report and saving it to a file. This violates the SRP.در این سناریو، کلاس Report دو وظیفه دارد: ایجاد گزارش و ذخیره آن در فایل. این SRP را نقض می کند.بعد از اعمال SRP:public class Report { public void GenerateReport() { } } public class ReportSaver { public void SaveToFile() { } }Now, the Report class is responsible only for generating reports, while the ReportSaver class is responsible for saving reports. Each class has a single responsibility. Explanation: According to SRP, one class should take one responsibility hence to overcome this problem we should write another class to save the report functionality. If you make any changes to the Report class will not affect the ReportSaver class.اکنون کلاس Report فقط مسئول ایجاد گزارش است در حالی که کلاس ReportSaver وظیفه ذخیره گزارش ها را بر عهده دارد. هر کلاس یک مسئولیت دارد.توضیح: طبق SRP، هر کلاس باید فقط یک مسئولیت داشته باشد، بنابراین برای غلبه بر این مشکل باید کلاس دیگری را برای ذخیره گزارش بنویسیم. اگر تغییری در کلاس Report ایجاد کنیم روی کلاس ReportSaver تاثیری نخواهد داشت.2. Open/Closed Principle (OCP)The Open/Closed Principle suggests that a class should be open for extension but closed for modification. This means you can add new features without altering existing code.Key Idea: Once a class is written, it should be closed for modifications but open for extensions.Real-Time Example: Your smartphone — you don’t open it up to add features; you just download apps to extend its capabilities.۲. اصل باز/بسته (OCP)اصل Open/Closed پیشنهاد می کند که یک کلاس باید برای توسعه باز باشد اما برای اصلاح بسته شود. این بدان معنی است که شما می توانید ویژگی های جدیدی را بدون تغییر کد موجود اضافه کنید.ایده اصلی: هنگامی که یک کلاس نوشته می شود، باید برای تغییرات بسته شود اما برای توسعه باز باشد.مثال در دنیای واقعی: گوشی هوشمند شما — آن را برای افزودن ویژگی‌ها باز نمی‌کنید. شما فقط برنامه ها را دانلود میکنید تا قابلیت های آن را افزایش دهید.مثال کاربردی در #C:قبل از اعمال OCP:public class Rectangle { public double Width { get; set; } public double Height { get; set; } } public class AreaCalculator { public double CalculateArea(Rectangle rectangle) { return rectangle.Width * rectangle.Height; } }This design may become problematic when adding new shapes. Modifying the AreaCalculator for each new shape violates the OCP.این طراحی ممکن است هنگام اضافه کردن یک شکل جدید مشکل ساز شود. اصلاح AreaCalculator برای هر شکل جدید، OCP را نقض می کند.بعد از اعمال OCP:public interface IShape { double CalculateArea(); } public class Rectangle : IShape { // implementation } public class Circle : IShape { // implementation }By introducing an interface (IShape), new shapes like Circle can be added without modifying existing code, adhering to the OCP.Explanation: According to OCP, the class should be open for extension but closed for modification. So, When you introduce a new shape, then just implement it from the interface IShape. So IShape is open for extension but closed for further modification.با معرفی یک Interface به اسم IShape، ضمن رعایت OCP می توان شکل های جدیدی مانند Circle بدون تغییر در کد موجود، اضافه کرد.توضیح: طبق OCP، کلاس باید برای توسعه باز باشد اما برای اصلاح بسته باشد. بنابراین، هنگام معرفی یک شکل جدید، فقط کافی است آن را در قالب IShape پیاده سازی کنید. بنابراین IShape برای گسترش باز است اما برای اصلاح بیشتر بسته است.3. Liskov Substitution Principle (LSP)The Liskov Substitution Principle states that objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program.Key Idea: You should be able to use any subclass where you use its parent class.Real-Time Example: You have a remote control that works for all types of TVs, regardless of the brand.۳. اصل جایگزینی لیسکوف (LSP)اصل جایگزینی لیسکوف بیان می کند که اشیاء یک سوپرکلاس، باید بدون تأثیر بر صحت برنامه، با اشیاء یک زیرکلاس قابل تعویض باشند.ایده اصلی: شما هر جا از یک کلاس والد استفاده کرده اید، باید بتوانید از هر زیرکلاس آن نیز استفاده کنید.مثال در دنیای واقعی: شما یک ریموت کنترل دارید که برای همه انواع تلویزیون، کار می کند؛ بدون در نظر گرفتن برند آن.مثال کاربردی در #C:قبل از اعمال LSP:public class Bird { public virtual void Fly() { /* implementation */ } } public class Penguin : Bird { public override void Fly() { throw new NotImplementedException("Penguins can't fly!"); } }Here, the Penguin class violates the LSP by throwing an exception for the Fly method.در اینجا، کلاس Penguin با ایجاد یک Exception برای متد Fly، اصل LSP را نقض می کند.بعد از اعمال LSP:public interface IFlyable { void Fly(); } public class Bird : IFlyable { public void Fly() { // implementation specific to Bird } } public class Penguin : IFlyable { public void Fly() { // implementation specific to Penguins throw new NotImplementedException("Penguins can't fly!"); } }By introducing the IFlyable interface, both Bird and Penguin adhere to the Liskov Substitution Principle.Explanation: According to LSP, a derived class should not break the base class’s type definition and behavior which means objects of a base class shall be replaceable with objects of its derived classes without breaking the application. This needs the objects of derived classes to behave in the same way as the objects of your base class.با تعریف اینترفیس IFlyable، هر دو کلاس Bird و Penguin به اصل جایگزینی Liskov پایبند هستند. (نظر خودم: در واقع اینجا دیگه کلاس Penguin از کلاس Bird مشتق نشده که بخواد جایگزینی اتفاق بیفته! یه جورایی صورت مسئله رو پاک کرده. در کل مثال هایی که آورده خیلی جالب نیست D:)توضیح: طبق LSP، یک کلاس مشتق شده نباید تعریف و رفتار کلاس پایه را نقض کند، به این معنی که اشیاء یک کلاس پایه باید با اشیاء کلاس های مشتق شده آن (بدون خراب شدن برنامه) قابل تعویض باشند. برای این کار نیاز است که اشیاء کلاس های مشتق شده مانند اشیاء کلاس پایه شما رفتار کنند.4. Interface Segregation Principle (ISP)The Interface Segregation Principle states that a class should not be forced to implement interfaces it does not use. This principle encourages the creation of small, client-specific interfaces.Key Idea: A class should not be forced to implement interfaces it doesn’t use.Real-Time Example: You sign up for a music streaming service and only choose the genres you like, not all available genres.۴. اصل جداسازی اینترفیس (ISP)اصل جداسازی اینترفیس (Interface) بیان می کند که یک کلاس نباید مجبور به پیاده سازی اینترفیس هایی شود که از آنها استفاده نمی کند. این اصل ما را تشویق میکند که اینترفیس هایی کوچک و سفارشی ایجاد کنیم.ایده اصلی: یک کلاس نباید مجبور به پیاده سازی اینترفیس هایی شود که از آنها استفاده نمی کند.مثال در دنیای واقعی: شما برای یک سرویس پخش موسیقی ثبت نام می کنید و فقط ژانرهای مورد علاقه خود را انتخاب می کنید، نه همه ژانرهای موجود را.مثال کاربردی در #C:قبل از اعمال ISP:public interface IWorker { void Work(); void Eat(); } public class Manager : IWorker { // implementation } public class Robot : IWorker { // implementation }The Robot class is forced to implement the Eat method, violating ISP.کلاس Robotمجبور به پیاده سازی متد Eat شده است که ISP را نقض می کند.بعد از اعمال ISP:public interface IWorkable { void Work(); } public interface IEatable { void Eat(); } public class Manager : IWorkable, IEatable { // implementation } public class Robot : IWorkable { // implementation }By splitting the IWorker interface into smaller interfaces (IWorkable and IEatable), classes can implement only what they need, adhering to ISP.Explanation: According to ISP, any client should not be forced to use an interface that is irrelevant to it. In other words, clients should not be forced to depend on methods that they do not use.با تقسیم اینترفیس IWorker به اینترفیس های کوچکتر (IWorkable و IEatable)، کلاس‌ها می‌توانند تنها آنچه را که نیاز دارند، با رعایت ISP پیاده‌سازی کنند.توضیح: طبق ISP، هیچ کلاسی نباید مجبور شود اینترفیسی را پیاده سازی کند که به آن مربوط نیست و از آنها استفاده نمی کند.5. Dependency Inversion Principle (DIP)The Dependency Inversion Principle suggests that high-level modules should not depend on low-level modules, but both should depend on abstractions. Additionally, abstractions should not depend on details; details should depend on abstractions.Key Idea: High-level modules should not depend on low-level modules; both should depend on abstractions.Real-Time Example: Building a LEGO tower — the bricks (high and low-level modules) connect through smaller bricks (abstractions).۵. اصل وارونگی وابستگی (DIP)اصل وارونگی وابستگی نشان می‌دهد که ماژول‌های سطح بالا نباید به ماژول‌های سطح پایین وابسته باشند، اما هر دو باید به انتزاع‌ها (Abstractions) وابسته باشند. علاوه بر این، انتزاع ها نباید به جزئیات بستگی داشته باشند؛ بلکه جزئیات باید به انتزاعات بستگی داشته باشد.ایده اصلی: ماژول های سطح بالا نباید به ماژول های سطح پایین وابسته باشند. هر دو باید به انتزاعات وابستگی داشته باشند.مثال در دنیای واقعی: ساخت برج لگو - آجرها (ماژول های سطح بالا و پایین) از طریق آجرهای کوچکتر (abstractions) به هم متصل می شوند.مثال کاربردی در #C:قبل از اعمال DIP:public class LightBulb { public void TurnOn() { /* implementation */ } public void TurnOff() { /* implementation */ } } public class Switch { private LightBulb bulb; public Switch(LightBulb bulb) { this.bulb = bulb; } public void Toggle() { if (bulb.IsOn) bulb.TurnOff(); else bulb.TurnOn(); } }The Switch class directly depends on the concrete LightBulb class, violating DIP.کلاس Switch مستقیماً از متدهای کلاس LightBulb استفاده کرده است و به آن وابستگی دارد؛ که این موضوع DIP را نقض می کند.بعد از اعمال DIP:public interface ISwitchable { void TurnOn(); void TurnOff(); } public class LightBulb : ISwitchable { // implementation } public class Switch { private ISwitchable device; public Switch(ISwitchable device) { this.device = device; } public void Toggle() { if (device.IsOn) device.TurnOff(); else device.TurnOn(); } }By introducing an interface (ISwitchable), the Switch class now depends on an abstraction, adhering to the Dependency Inversion Principle.Explanation: According to DIP, do not write any tightly coupled code because that is a nightmare to maintain when the application is growing bigger and bigger. If a class depends on another class, then we need to change one class if something changes in that dependent class. We should always try to write loosely coupled classes.با معرفی اینترفیس ISwitchable، کلاس Switch اکنون به یک انتزاع وابسته است که به اصل Dependency Inversion پایبند است.توضیح: با توجه به DIP، کد Tightly Coupled (یعنی کدی که با تغییر در ساختار یک کلاس مجبور میشوید کلاس های دیگری را نیز تغییر دهید) ننویسید، چرا که نگهداری آن یک کابوس است وقتی که برنامه بزرگتر و بزرگتر می شود. اگر کلاس A به کلاس B وابستگی داشته باشد، در صورت تغییر کلاس B باید کلاس A را نیز تغییر دهیم. ما باید همیشه سعی کنیم کلاس های Loosly Coupled بنویسیم که کمترین وابستگی به یکدیگر را داشته باشند.ConclusionRemember, by understanding and applying these SOLID principles, .NET developers can create more robust, flexible, and maintainable software. It’s important to note that these principles work together and complement each other, contributing to the overall design philosophy of object-oriented programming.نتیجهبه یاد داشته باشید، با درک و به کارگیری اصول SOLID، توسعه دهندگان دات نت می توانند نرم افزاری قوی تر، انعطاف پذیرتر و با قابلیت نگهداری بالاتری ایجاد کنند. توجه به این نکته مهم است که این اصول با هم کار می کنند و مکمل یکدیگر هستند و به فلسفه طراحی کلی برنامه نویسی شی گرا کمک می کنند.(لینک مطلب اصلی: ذکر شده در اولین کامنت)

۱۳ راه برای بهبود Maintainability (قابلیت نگهداری) در کدنویسی

امید آرام - توسعه دهنده نرم افزار — Sat, 29 Jun 2024 14:46:56 +0330

At a high level, maintainability defines the ease with which changes can be made correctly. Correctness in this sense means that the intended changes are made without introducing unexpected side effects. Code should be structured so as to be easily modifiable. Tests should be in place to prevent regression, ensuring that existing functionality is unaffected by changes. Additional tests should be developed to verify new functionality. By developing tests concurrently with code changes, you are both validating that the change being made is the one intended to be made, and providing regression protection for future changes. Further, automated processes should be in place to continuously verify the correctness of the code base and to identify any issues as early in the process as possible.قابلیت نگهداری (Maintainability) در کد نویسی، در واقع رعایت یک سری قوانین است که باعث میشود تغییرات کد در آینده راحت تر و بدون ایجاد عوارض جانبی غیر منتظره انجام شود. کد باید به گونه ای ساختار یافته باشد که به راحتی قابل تغییر باشد. تست هایی باید برای جلوگیری از تغییرات ناخواسته در سایر قسمت های برنامه وجود داشته باشد و اطمینان حاصل شود که عملکرد موجود تحت تأثیر تغییرات قرار نمی‌گیرد. همچنین تست هایی هم باید برای تأیید عملکرد جدید برنامه ایجاد شود. با نوشتن تست ها همزمان با تغییرات کد، هم تأیید می‌کنید که تغییر ایجاد شده همان تغییری است که باید انجام شود و هم کد را در برابر تغییرات آینده محافظت می‌کنید (Regression Testing). علاوه بر این، فرآیندهای خودکار (automated processes) باید برای تأیید مداوم صحت کد وجود داشته باشند و بتوانند هر گونه مشکل را خیلی سریع پیدا کنند.Maintainable code is clear, readable, testable, understandable, well-organized, consistent, and highly cohesive. It eases ongoing enhancements, bug fixes, and modifications; quickens the ability to onboard new team members, transfer responsibility, and overall increases confidence in changes. It is enabled by high quality code, verified by a mature automated test and scan process, and facilitated by a close relationship between the business, designers, developers, and testers.کدی قابل نگهداری است که واضح، خوانا، قابل تست، قابل درک، به خوبی سازماندهی شده، سازگار و بسیار منسجم باشد. چنین کدی بهبودهای مداوم، رفع اشکال ها و تغییرات را آسان می کند؛ توانایی حضور اعضای جدید در تیم، انتقال مسئولیت و به طور کلی افزایش اعتماد به نفس در تغییرات را افزایش می دهد. این مهم وقتی میسر میشود که یک رابطه نزدیک بین متولیان کسب و کار، طراحان، توسعه دهندگان و تست کنندگان شکل گرفته باشد و یک کد با کیفیت بالا نوشته شده باشد، و آن کد توسط یک فرآیند اسکن و تست خودکار تأیید شود.From a development standpoint, there are a number of aspects that can be followed to increase maintainability. This blog will briefly go over some of those qualities, focusing on how developers can structure code. Not discussed in detail are the multitude of ways and tools that can be employed to verify and enforce code quality, both during local development and as part of an automated continuous integration process.به عنوان یک توسعه دهنده نرم افزار، مواردی هست که می توان برای افزایش قابلیت نگهداری رعایت کرد. این مطلب به برخی از این ویژگی ها می پردازد و بر چگونگی ساختار کد توسعه دهندگان تمرکز می کند؛ در اینجا به طور مختصر بسیاری از راه‌ها و ابزارهایی را معرفی میکنیم که می‌توانید برای نوشتن یک کد با کیفیت، هم در طول توسعه اولیه و هم به عنوان بخشی از فرآیند یکپارچه‌سازی مداوم خودکار (automated continuous integration) از آنها استفاده کنید.1. Follow a clean and consistent coding standardThere should be a formalized coding standard followed by all developers. This enables an application with many contributors to have a single consistent standard, which increases the ability to make modifications. There are many tools that can verify, enforce, and automatically correct code style based on customizable rules, including: ESLint (JavaScript), TSLint (TypeScript), Prettier (multiple languages), RuboCop (Ruby), and Checkstyle (Java). These tools can be both incorporated into a developer’s IDE for scanning during development, and into a continuous integration (CI) process. Where feasible, use a community-maintained ruleset. This enables the application not only to be internally consistent but to be externally consistent with best practices.۱. از یک استاندارد کدنویسی تمیز و سازگار پیروی کنیدباید یک استاندارد کدنویسی رسمی وجود داشته باشد که همه توسعه دهندگان آن را رعایت کنند. این امر باعث میشود توانایی ایجاد تغییرات توسط برنامه نویسان افزایش یابد. ابزارهای زیادی وجود دارند که می توانند کدهای نوشته شده را بررسی و یا به طور خودکار تصحیح کنند (که البته قوانین این ابزار ها قابل تنظیم هستند)؛ از جمله: ESLint (جاوا اسکریپت)، TSLint (تایپ اسکریپت)، Prettier (تعدادی از زبان ها)، RuboCop (روبی) و Checkstyle (جاوا). این ابزارها می توانند هم در IDE شما برای اسکن در حین توسعه و هم در یک فرآیند یکپارچه سازی مداوم (CI) گنجانده شوند. در صورت امکان، از یک مجموعه قوانین شناخته شده توسط جامعه استفاده کنید. در این صورت برنامه شما نه تنها در مجموعه داخلی خودتان سازگار هست، بلکه با بهترین روش های برنامه نویسی سازگار می باشد.2. Use human readable and sensible namesVariable, method, and class names should both follow a defined structure, and be human readable and descriptive of their intended purpose. Camel case (e.g. camelCase) and snake case (e.g. snake_case) are two examples of how to structure variable names. It is recommended that different types of components (e.g. classes and objects) follow different standards. For example, the standard in many languages is that classes should be upper camel case (or pascal case) while objects should be lower camel case. This standardization can easily be enforced by the tools discussed in the previous section. Not only should variable names be similarly structured, but they should also be sufficiently descriptive. The variable `firstName` is much more descriptive than the variable `aString`, and its intended purpose is easily understood.۲. از اسامی خوانا و معقول استفاده کنیدنام متغیرها، متدها و کلاس ها باید برای انسان قابل خواندن و توصیف کننده هدف مورد نظر خود باشند؛ همچنین باید از ساختارهای استاندارد نامگذاری استفاده کنند. camelCase و snake_case دو نمونه از ساختار نامگذاری متغیرها هستند. توصیه می شود که انواع مختلف مؤلفه ها (مانند کلاس ها و آبجکت ها) از استانداردهای متفاوتی پیروی کنند. به عنوان مثال، استاندارد در بسیاری از زبان‌ها این است که نام کلاس‌ها باید PascalCase باشند، در حالی که آبجکت ها باید camelCase باشند. این استانداردسازی را می توان به راحتی با ابزارهای مورد بحث در بخش قبل اجرا کرد. نام متغیرها نه تنها باید ساختاری مشابه داشته باشند، بلکه باید به اندازه کافی گویا نیز باشند. متغیر "firstName" بسیار خواناتر از متغیر "aString" است و هدف مورد نظر آن به راحتی قابل درک است.3. Be clear and conciseWhile it may be tempting to develop applications with the minimal amount of lines possible, there is a risk of making the code overly complex. Clever and complicated logic should be minimized, with a preference for verbosity and ease of understanding over complexity. Code should focus more on what is being done rather than how it is being done. Code comments should not be required to explain the logic and flow.۳. واضح و مختصر باشیددر حالی که ممکن است وسوسه انگیز باشد که برنامه ها را با حداقل تعداد خطوط ممکن بنویسید، اما ممکن است کد شما بیش از حد پیچیده شود. در کدنویسی ترجیح دهید پرحرفی کنید و روش های هوشمندانه و پیچیده را به حداقل برسد تا فهم آن کد راحت تر شود. کد باید بیشتر بر آنچه انجام می شود تمرکز کند تا اینکه چگونه انجام می شود. کد باید به گونه ای نوشته شود که برای توضیح منطق و جریان آن، نیازی به نوشتن کامنت (Comment) نباشد.4. Minimize complex conditional and nested logicNested code should be minimized as it is more difficult to follow the possible paths and logic flow of deeply nested code blocks. It is preferable to extract conditional logic to methods or variables so it is easier to understand what is being evaluated. Early method returns are preferable to large blocks of code contained within a conditional. Exceptions should be thrown as applicable.۴. کدهای پیچیده شرطی و تودرتو را به حداقل برسانیدکد تودرتو (Nested Code) باید به حداقل برسد چرا که دنبال کردن مسیرهای احتمالی کد و جریان منطقی بلوک‌های کد عمیق تودرتو دشوارتر است. بهتر است کدهای شرطی را با متدها یا متغیرها تفکیک کنیم تا درک آنچه اتفاق میافتد آسان‌تر شود. توصیه میشود در یک متد، هر جا میتوانید از return و Throw Exception استفاده کنید، به جای آنکه بلوک های شرطی (if) بزرگ داشته باشید.5. Methods should be small and singularly focusedMethods should do one thing and do it well. This will naturally lead to reasonably sized methods. To improve readability, and if methods are becoming overly complex or large, look for opportunities to pull out logic into separate methods. It is preferable to have methods that do not require external dependencies and do not mutate external state. While code line length is very subjective, and it is a mistake to put in place a strict limit, it is reasonable that a sufficiently focused method would be 25 lines or fewer.۵. متدها باید کوچک و متمرکز باشندمتدها باید فقط یک کار را انجام دهند و آن را به خوبی انجام دهند. طبیعتاً این هدف باعث میشود متدها اندازه معقولی داشته باشند. اگر متدها بیش از حد پیچیده یا بزرگ شده اند، برای خوانایی بیشتر آنها را به متدهای کوچکتری بشکنید. ترجیحاً متدهایی داشته باشید که وابستگی خارجی (External Dependency) نداشته باشند و Stateهای خارجی را نیز تغییر ندهند. هر چند که تعداد خط یک متد خیلی مهم نیست، و نمیشود محدودیت دقیقی برای آن تعریف کرد، اما بهتر است تعداد خطوط، ۲۵ یا کمتر باشد.6. Classes should be focusedSimilar to methods, classes should also be focused. All class methods and parameters should be related to solving a specific need, having a cohesive responsibility. Again, code line length is very subjective, but it is reasonable that a sufficiently focused class would be 1000 lines or fewer. If all other points are followed, class size will inherently be minimized while still maintaining readability.۶. کلاس ها باید متمرکز باشندمشابه متدها، کلاس ها نیز باید بر یک موضوع خاص تمرکز داشته باشند. تمام متدها و پارامترهای یک کلاس باید مرتبط با رفع یک نیاز خاص باشند و همچنین انسجام لازم در جهت انجام یک مسئولیت را دارا باشند. باز هم، تعداد خطوط یک کلاس خیلی ملاک نیست، اما منطقی است که یک کلاس به اندازه کافی متمرکز، 1000 خط یا کمتر باشد. اگر تمام نکات دیگر رعایت شود، اندازه کلاس ذاتاً به حداقل می رسد و در عین حال خوانایی حفظ می شود.7. Decouple and organizeThe code should be decoupled and organized. This can be manifested in a Model-View-Controller (MVC) organization, or by using a similarly enforced architecture. Concerns should be separated. Two common ways of organizing files is either by type or by subject. For example, organizing files by type would be grouping all models together, while organizing files by subject would be grouping all User-related files together. Dependency injection is preferred to increase decoupling and improve testability.۷. جداسازی و سازماندهیکد باید جداشده (Decoupled) و سازماندهی شده (Organized) باشد. این می تواند با معماری Model-View-Controller (MVC) یا با استفاده از یک معماری مشابه اعمال شود. موضوعات مهم را باید از هم جدا کرد (Seperation of Concerns). دو روش متداول برای سازماندهی فایل ها بر اساس نوع یا موضوع وجود دارد. برای مثال، در سازمان‌دهی فایل‌ها بر اساس نوع، همه مدل‌ها را کنار هم قرار میدهیم، در حالی که در سازمان‌دهی فایل‌ها بر اساس موضوع، همه فایل‌های مرتبط با یک موضوع در کنار هم قرار میگیرند. برای افزایش جداسازی و بهبود تست پذیری ترجیحاً از تزریق وابستگی (Dependency Injection) استفاده کنید.8. Minimize redundancyCommon code should be extracted to shared methods and utility libraries. When code changes are inevitably required, they only need to be made in a single location. This aspect is focused on the Don’t repeat yourself (DRY) principle. Using well-designed frameworks can help reduce redundant boilerplate code.۸. افزونگی (Redundancy) را به حداقل برسانیدکدهای مشترک (Common Code) باید از کد اصلی جدا شوند و در متدهای مشترک (Shared Methods) و یا کتابخانه های ابزار (Utility Libraries) نوشته شوند. در این صورت هنگامی که نیاز به تغییر آنها باشد، فقط کافی است یک جا را تغییر دهید. این جنبه بر اصل "خودت را تکرار نکن" (DRY) دلالت دارد. استفاده از فریم ورک های خوب می تواند به کاهش کد اضافی تکراری کمک کند.9. Leverage existing libraries and frameworksIt is better to leverage existing libraries and frameworks than it is to recreate the wheel. Ensure that the libraries chosen are actively maintained and from reputable sources. Using third-party libraries lowers the amount of code needed to be tested and maintained.۹. از کتابخانه ها و فریم ورک های موجود استفاده کنیدبهتر است از کتابخانه ها و فریم ورک های موجود استفاده کنید تا اینکه چرخ را دوباره اختراع کنید. البته منظور کتابخانه های معتبری است که به طور فعال پشتیبانی میشوند. استفاده از این کتابخانه ها (third-party libraries)، مقدار کد مورد نیاز برای تست و نگهداری را کاهش می دهد.10. Clearly track dependenciesAll dependencies should be explicitly declared and used. There should be no dependence on implicit or system level packages. A manifest file should be used to track all dependencies (and the exact versions), along with a process in place to ensure these dependencies are downloaded and used. This allows developers and the CI process to remain in sync, and quickens the ability of a new developer to begin contributing. Dependencies that are no longer used should be removed from the manifest file.۱۰. وابستگی ها (Dependencies) را به وضوح دنبال کنیدهمه وابستگی ها باید به صراحت اعلام و استفاده شوند. هیچ وابستگی به پکیج های ضمنی (implicit packages) یا پکیج های سطح سیستم (system level packages) نباید وجود داشته باشد. از یک فایل بیانیه (Manifest File) باید برای مشخص کردن همه وابستگی‌ها (و نسخه‌های دقیق آنها) استفاده کنید؛ همچنین فرآیندی تعریف کنید که مطمئن شوید آن وابستگی ها دانلود میشوند و قابل استفاده هستند. این به توسعه‌دهندگان و فرآیند CI امکان می‌دهد تا به روز بمانند و همچنین کار یک توسعه‌دهنده جدید را تسریع می‌کند. وابستگی هایی که دیگر استفاده نمی شوند باید از فایل مانیفست حذف شوند.11. Remove unused codeUnused and orphaned code should be removed. Removing unused functionality makes clear what code needs to be maintained and tested, increasing its readability. It is insufficient to simply comment out the unused code for possible use in the future. With modern version control systems, old code can be easily retrieved if it is determined that it is once more needed. If developing an externally used API or library, a deprecation strategy should be employed. Related to this topic is to avoid TODO or similar comments. Missing features or changes should be tracked externally, and not littered throughout the code.۱۱. کدهای استفاده نشده را حذف کنیدکدهای استفاده نشده (unused) و یتیم (orphaned) باید حذف شوند. حذف توابع استفاده نشده باعث میشود که کدهای اضافه را تست و نگهداری نکنیم و خوانایی کد افزایش می یابد. این خوب نیست که کدها را کامنت کنیم که شاید در آینده بخواهیم از آنها استفاده کنیم؛ با سیستم های کنترل نسخه مدرن (مثل git)، به راحتی میتوان آنها را بازیابی کنیم. اگر در حال نوشتن یک کتابخانه یا API با استفاده خارجی هستید، حتما از یک استراتژی منسوخ شدن (Deprecation Strategy) استفاده کنید؛ همچنین از کامنت های TODO یا مشابه آن اجتناب کنید. کدهای نوشته نشده نباید در سراسر کد پخش شده باشند.12. Create API and method-level documentation/contractsIt is far better to write self-documenting code and to not rely on inline comments to explain logic. However, this does not mean that there should be zero documentation. This is especially true when working with multiple teams or when developing a consumable library or extensible application. The public API should be accurately documented, describing the inputs, outputs, and functionality. This enables API consumers to understand and use the available functionality.۱۲. داکیومنت های API و در سطح متد ایجاد کنیدبه مراتب بهتر است کدی بنویسید که خود گویای همه چیز باشد (self-documenting code) و برای فهم منطق آن نیازی به کامنت های درون کد نداشته باشد. با این حال، این بدان معنا نیست که هیچ داکیومنتی برای کد وجود نداشته باشند. این امر به ویژه هنگام کار با چندین تیم یا هنگام توسعه یک کتابخانه یا برنامه قابل توسعه صادق است. API عمومی باید به طور دقیق مستند شده و ورودی ها، خروجی ها و عملکردها را توصیف کند. این به مصرف کنندگان آن API امکان می دهد تا عملکرد موجود را درک کرده و از آن استفاده کنند.13. Separate configuration from codeConfiguration should be clear, consistent, and separate from the source code. It should be organized and defined in a central location. All available options should be described with how they are used and any applicable default values. It is preferable to use environment variables. In this way, the source code can remain unchanged, and how those environment variables are defined can change based on use case or environment. Anything that can vary between environments or deployments should not be located within the code itself. Organizing and sufficiently describing the available configuration options makes it much easier to deploy to new environments and for new team members to begin contributing.۱۳. پیکربندی (Configuration) را از کد جدا کنیدپیکربندی (Configuration) باید واضح، سازگار و جدا از کد اصلی باشد. باید در یک مکان مرکزی سازماندهی و تعریف شود. تمام گزینه های موجود باید با نحوه استفاده از آنها و مقادیر پیش فرض قابل اعمال توضیح داده شود. استفاده از متغیرهای محیطی (Environment Variables) ترجیح داده می شود. به این ترتیب، کد اصلی می تواند بدون تغییر باقی بماند، و نحوه تعریف آن متغیرهای محیطی می تواند بر اساس موارد استفاده یا محیط تغییر کند. هر چیزی که می تواند بین محیط ها یا استقرارها متفاوت باشد نباید در خود کد قرار گیرد. سازماندهی و توصیف کافی گزینه های پیکربندی موجود، استقرار در محیط های جدید و شروع مشارکت اعضای تیم جدید را بسیار آسان تر می کند.(لینک منبع: ذکر شده در اولین کامنت)