نوشته های مصطفی حسینخانی

تنها چیز ثابت، تغییر است (the only constant is change)

مصطفی حسینخانی — Wed, 09 Oct 2024 19:56:55 +0330

در کتاب «The Software Architect Elevator» نوشته Gregor Hohpe به طور مفصل اشاره به این دارد که یکی از مهم‌ترین وظایف معماران نرم‌افزار، پذیرش تغییرات سریع در سازمان‌های دیجیتال است. او با استفاده از استعاره «آسانسور معمار»، به نقش معماران در اتصال سطوح مختلف یک سازمان، از استراتژی کسب‌وکار در "پنت‌هاوس" تا اجراهای فنی در "اتاق موتور(Engine Room)"، تأکید می‌کند.چرا پذیرش تغییر برای معماران و سازمان‌ها حیاتی است؟در دنیای پرسرعت امروز، معماران نرم‌افزار نه تنها باید با تکنولوژی‌های جدید سازگار شوند، بلکه باید توانایی ایجاد ارتباط بین کسب‌وکار و فناوری را داشته باشند. Hohpe توضیح می‌دهد که معماری سازمان‌ها باید به گونه‌ای طراحی شود که توانایی جذب تغییرات مداوم را داشته باشد.سه دلیل کلیدی برای اهمیت پذیرش تغییر:نوآوری و خلاقیت:همان‌طور که Hohpe در کتاب خود بیان می‌کند، معماران باید در جایی کار کنند که تغییرات سریع فناوری را پذیرا باشد. بدون تغییر و انعطاف‌پذیری، نوآوری غیرممکن است. شرکت‌هایی مانند نتفلیکس با پذیرش تغییر، به جای مقاومت، به رهبران بازار تبدیل شدند. نتفلیکس توانست از یک سرویس اجاره DVD به یک پلتفرم جهانی استریم آنلاین تبدیل شود.سازگاری و انعطاف‌پذیری:Hohpe تأکید دارد که یکی از ویژگی‌های مهم معماران موفق، توانایی حرکت بین سطوح مختلف سازمان است. آن‌ها باید بتوانند تغییرات را در هر سطح سازمانی تطبیق دهند. برای مثال، آمازون با استفاده از فناوری‌های ابری و بهینه‌سازی زنجیره تأمین، توانست خود را با شرایط متغیر بازار و بحران‌های جهانی مانند همه‌گیری COVID-19 سازگار کند.یادگیری و رشد مداوم:هر تغییر یک فرصت برای یادگیری است. همان‌طور که Hohpe بیان می‌کند، معماری که خود را با تغییرات سریع صنعت وفق نمی‌دهد، به زودی از رقابت خارج می‌شود. شرکت‌هایی که فرهنگ یادگیری مداوم دارند، عملکرد بهتری نسبت به رقبای خود دارند.اما اگر در برابر تغییر مقاومت کنیم چه می‌شود؟متاسفانه شرکت نوکیا با مقاومت در برابر سیستم‌عامل‌های جدید، بازار را به اپل و سامسونگ واگذار کرد و به دلیل مقاومت در برابر تغییرات سریع فناوری، شکست خورد. مقاومت در برابر تغییر تنها به کاهش کارایی و رقابت‌پذیری منجر می‌شود.سازمان‌هایی که خود را از جریان سریع تغییرات جدا می‌کنند، مانند کشتی‌ای هستند که در مسیر برخورد با یخچال حرکت می‌کند؛ در نهایت، زمانی که متوجه شوند، ممکن است برای جلوگیری از فاجعه خیلی دیر باشد.شما یا سازمانتان چگونه با تغییرات سریع صنعت‌تان سازگار می‌شوید؟

سایتی خوب برای مطالعه مقاله های محدود شده مثل Medium

مصطفی حسینخانی — Sun, 06 Aug 2023 15:35:13 +0330

سلام و وقت بخیرامروز میخوام براتون سرویسی(https://12ft.io/) که خودم استفاده میکنم برای خوندن مقالات محدود شده سایت Medium رو معرفی کنم واقعا عالی هستش و اکثر سایتهای دارای محدودیت رو هم بدون مشکل براتون باز میکنه.کافیه شما لینک مطلب رو داخل آدرس بار کپی کنین تا براتون اون مطلب رو باز کنه.توی آدرس بار مثلا لینک زیر رو که محدود هست رو وارد میکنیم و بدون مشکل مطلب رو برامون میاره. ساده و شیک. https://medium.com/bytebytego-system-design-alliance/system-design-blueprint-the-ultimate-guide-e27b914bf8f1 دوست داشتین منتشر کنین همه دوستانی که مشتاق هستند بتونن استفاده کننآدرس سایت https://12ft.io/

Architectural Pattern vs Design Pattern

مصطفی حسینخانی — Tue, 30 May 2023 10:20:19 +0330

تفاوت بین الگوی معماری و الگوی طراحیدر مورد اینکه تفاوت بین الگوی معماری و الگوی طراحی چیست، سردرگمی زیادی وجود دارد، چرا که ارتباط نزدیکی با هم دارند.برخی از سؤالات رایجی که با آنها روبرو می شویم عبارتند از: آیا این دو مفهوم یکسان هستند یا متفاوت؟ و اگر متفاوت هستند، این تفاوت چقدر است؟ همچنین سؤالات دیگری مطرح می شود مانند اینکه هر دو چگونه در یک پروژه قرار می گیرند و سپس معماری کلی برنامه چیست؟بیایید در مورد اینها صحبت کنیم و شباهت ها و تفاوت ها را درک کنیم:الگوهای معماری از نظر دامنه گسترده تر از الگوهای طراحی هستند. الگوهای طراحی وظایف نرم افزاری بسیار خاصی را ارائه می دهند که به عنوان الگوی معماری راه حلی برای مشکلات تجاری است.به عبارت دیگر الگوی معماری بیشتر بر نمای انتزاعی و نگاه از بالا بر ایده تمرکز می‌کند در حالی که الگوی طراحی بر نمای اجرایی و خرد تمرکز می‌کند.پیاده سازی الگوهای طراحی در سطح واحد های خرد تعریف می شوند، در حالی که الگوهای معماری در سطح بالایی تعریف می شوند.برای مثال، پیاده‌سازی‌های مختلف الگوی Factory یا Builder ممکن است در پروژه‌های مختلف بسیار شبیه به هم به نظر برسند. اما همان الگوی معماری می تواند در پروژه های مختلف بسیار متفاوت باشد.یک الگوی معماری را می توان با استفاده از بسیاری از الگوهای طراحی پیاده سازی کرد. بین الگوی معماری و الگوی طراحی یک تا چند رابطه وجود دارد.برای مثال، پیاده‌سازی MVP را می‌توان به روش زیر انجام داد: مدل‌ها را می‌توان با استفاده از الگوی Factory و Builder ساخت. ارائه دهنده را می توان با استفاده از Observer و الگوی نما ساخت. نماها را می توان با استفاده از Factory و Singleton ساخت.الگوی معماری، معماری اپلیکیشن نیست. الگوی معماری دستورالعمل‌ها و قوانینی را ارائه می‌کند تا برنامه را در سطح پروژه/راه‌حل قابل نگهداری‌تر، اتصال ضعیف و توسعه‌پذیرتر کند.الگوهای طراحی نیز تا حدودی انجام می شوند، اما بیشتر در سطح ماژول یا جزء انجام می شوند. جایی که به عنوان Application Architecture معماری کامل اپلیکیشن است که از الگوی معماری در کنار سایر الگوها و رابط های طراحی استفاده خواهد کرد.برخی از الگوهای معماری محبوب عبارتند از:MVCMVPMVVMVIPERThree-tier/Multi-tierDependency Injection Architectural pattern23 الگوی طراحی محبوب وجود دارد که با نام Gang of Four (GOF) نیز شناخته می شوند و به سه دسته تقسیم می شوند: الگوی ایجادی، الگوی ساختاری و الگوی رفتاری.نتیجهبه طور خلاصه می توان گفت که الگوی معماری سطح بالاتری از انتزاع طراحی نرم افزار است و الگوی طراحی راه حلی برای مشکلات سطح ماژول خاص ارائه می دهد.

دوازده اصل روش Agile

مصطفی حسینخانی — Wed, 23 Jun 2021 20:15:26 +0430

این روزها همه این اسم ها رو زیاد میشنویم:"تیم ما با متدولوژی اجایل کار میکنه""ما از اجایل و اسکرام برای تولید محصولاتمون استفاده میکنیم""لازمه پیوستن به تیم ما دانستن مفاهیم اجایل هست!"همه کم یا بیش باهاش آشنایت داریم و در کل میدونیم که چی هست اما چیزی که میبینیم اینه که کمتر کسی رفته تا کامل بخونه و از اون بصورت جدی استفاده کنه حتی اون شرکت هایی که شرط ورودشون رو اجایلی بودن گذاشتن.تصمیم گرفتم خیلی خلاصه وار 12 اصل اجایل رو اینجا براتون قرار بدم، شاید خیلی کوتاه و مختصر با اصولش آشنا شیم.مرجع اصلی رو که همه میدونیم اما اینجا قرارش میدم برای دسترسی(Agile Manifest)12 اصول بیانیه چابک 1- رضایت مشتری: بالاترین اولویت ما، راضی نگه داشتن مشتری‌ها از طریق تحویل زود به زود ،با کیفیت و پیوسته بخش‌های کوچک شده پروژه اصلی است. میزان موفقیت تیم به تهیه محصولی بستگی دارد که بتواند ارزشمند و تاثیرگذار باشد. در یک تیم چابک باید سندی از نیازمندی‌های مشتری تنظیم شده و بر اساس ارزش‌های تجاری او، اولویت بندی شود. به این سند اصطلاحا بک‌لاگ (backlog) گفته می‌شود و تیم توسعه بر اساس اولویت‌های از بالا به پائین بک‌لاگ کار خواهد کرد. می‌دانیم که امروزه بر خلاف دوران گذشته، مشتری‌ها برای خرید محصولات مورد نیازشان، امکان انتخاب میان فروشندگان مختلف دارند؛ در نتیجه رقابت سختی در جریان است و تنها راه برای موفقیت سازمان این است که همیشه رضایت مشتری را جلب کنیم.2- استقبال از تغییر نیازمندی ها و تغییرات: استقبال از تغییراتی که مشتری مطرح می‌کند بر اساس این اصل ضروری است، این مورد حتی در مراحل پایانی پروژه نیز الزامی محسوب می‌شود؛ اعمال چنین تغییراتی در نهایت منجر به رضایت بیشتر مشتری خواهد شد و این نگاه مثبت به تغییرات مزیت رقابتی تیم‌های چابک به شمار می‌رود.3- تحویل زود به زود: تیم‌های چابک باید محصول درخواستی مشتری را به تناوب در چندین بخش قابل استفاده حاضر کرده و تحویل دهند. هرچه این بازه‌های زمانی کوچک‌تر باشند، بهتر است؛ البته این بازه‌ها می‌توانند از چندین هفته تا چندین ماه متغیر باشند.دو نمونه از متدولوژی های نرم افزار4- تعامل زیاد با مشتری: تیم‌های چابک به طور متناوب و پیوسته باید از مشتری بازخورد دریافت کنند تا محصول نهایی تولیدی را با بیشترین میزان نزدیکی به درخواست مشتری تحویل دهند. در این حالت مشتری نیز دسترسی زود به زود به سفارش در حال تکامل خود را دارد و به خوبی در جریان روند پیشرفت کار قرار می‌گیرد. امروزه کمپانی‌های مدرن فراوانی هستند که مشتری را به طور روزانه و یا حتی چندین بار در طی روز، در جریان پیشرفت توسعه محصول قرار می‌دهند.5- تیمی از افراد با انگیزه: تیم چابک باید از افراد با انگیزه تشکیل شود، از ایده‌های آن‌ها حمایت شود و فضای لازم برای پیشرفت در اختیارشان قرار بگیرد. به اعضای تیمتان اعتماد کنید تا در نهایت کارها را به بهترین شکل به انجام برسانند.6 -مکالمات رو در رو: کارآمدترین و موثرترین روش انتقال اطلاعات به تیم توسعه و نیز بهترین روش انتقال اطلاعات در میان اعضای تیم ، گفتگوی چهره به چهره است.7- نرم افزار قابل استفاده: تحویل یک نرم افزار قابل استفاده، اصلی‌ترین معیار سنجش پیشرفت پروژه است.8- توسعه پایدار: تیم‌های چابک مروج توسعه پایدار هستند. لازم است که حامیان مالی، مشتری‌ها، توسعه دهندگان و کاربران نرم‌افزار شاهد سرعت پیشرفت ثابتی در طول زمان باشند.9- حرکت دائمی در لبه تکنولوژی: اگر به چابکی تیم خود اهمیت می‌دهید باید به طور مداوم به برتری فنی و نیز طراحی بهتر محصولات خود توجه داشته باشید.10- سادگی: هنر تیم‌های چابک از اجتناب از هرگونه پیچیدگی در طراحی و توسعه محصولات است.11- تیم‌های خودسازمان‌ده: این تیم‌ها بهترین ایده‌ها، نیازمندی‌ها، معماری‌ها و طراحی ها را پدید می‌آورند.12- بحث و تبادل نظر: لازم است اعضای تیم‌های چابک در بازه‌های زمانی مشخص و منظم، در مورد روش‌های بهتر شدن با همدیگر بحث و تبادل نظر داشته باشند و در نهایت رفتار تیمی بر اساس برایند این تفکرات و تصمیمات تیمی، جهت‌دهی شود.

آمار بازدید پست‌های من در سال ۹۹

مصطفی حسینخانی — Fri, 26 Mar 2021 13:42:59 +0430

در طول تاریخ از اعداد استفاده کردیم تا اغلب داد و ستد کنیم و آن‌چیزی که شمردنی است را بشماریم. برای هر عدد واحد درست کردیم تا عددهای زندگی قاطی نشوند و از اعداد، شفاف‌تر استفاده کنیم؛ مثلا وقتی می‌گوییم ده هزار تومان به پول اشاره داریم و وقتی می‌گوییم ده هزار بلیط به بلیط!روز به روز که در زندگی جلو‌تر رفتیم عددها فرقی نکردند ولی این واحدها بودند که زیاد شدند. واحد کریپتو، واحد اصله درخت، واحد فاصله و …«واحد» یک توافق عمومی است برای شمردن؛ تا همانطور که گفتم شمردن‌ها قاطی نشود. مشاهده افراد دارای ثروت (اجتماعی یا مالی) به من ثابت کرده اینکه چه چیزی را بشماریم از اینکه چطور بشماریم مهم‌تر است. هرکس با واحد خاصی مسائل زندگی را می‌شمارد. اینطور به نظرم آمده که مشخص کردن واحد یعنی مشخص کردن اینکه من در زندگی برای چه چیزهایی ارزش قائلم و می‌خواهم چه چیزهایی را در زندگی بشمارم. https://cdn.virgool.io/annual-report/1399/aufsjlrnaldw-EdzCb.mp4 اعدادی که بدون واحد ثبت کردمبه ویدیویی که ویرگول برایم ساخته که نگاه می‌کنم میبینم که در سال ۹۹، من در مجموع ۴,۵۵۳ کلمه در ویرگول نوشتم و منتشر کردم و مخاطبین، پست‌های من را ۲۳ مرتبه پسندیدند و ۵ بار هم نظر خود را روی پست‌های من به اشتراک گذاشتند. در سال ۹۹، ۱۰ نفر در ویرگول من را دنبال کردند تا پست‌های بعدیم را بخوانند. این اعداد نشان میدهند من کاری کرده‌ام. هرکدام به واحدی وصل هستند. از خودم می‌پرسم من کدام واحد را شمارش کرده‌ام؟ کدامیک از واحدهای بالا از همه برای من مهم‌تر است؟ ادامه ویدیو را می‌بینم.آمار از اثر بیرونی می‌گویندطبق آمار پست‌های من ۵۲۰ بار خوانده شدند و ۴۱۴,۸۹۶ ثانیه صرف مطالعه آنها شده است، که با توجه به جمعیتی که در ایران به اینترنت دسترسی دارند، ویرگول به من می‌گوید که توانستم ۰/۰۰۵۶۸۸۱۸۲ ثانیه، سرانه مطالعه دیجیتال کشور را بالا ببرم.از طرف دیگر ویرگول به من می‌گوید که اگر قرار بود پست‌هایم را چاپ و به دست تک تک خوانندگان برسانم باید ۲,۸۰۷ کاغذ مصرف می‌کردم.آن عددهای کوچک ابتدای ویدیو حالا تبدیل شده‌اند به عددهای بزرگ به اینکه من جلوی مصرف این تعداد کاغذ را گرفتم یا به اینکه من ۰/۰۰۵۶۸۸۱۸۲ ثانیه، سرانه مطالعه دیجیتال کشور را جابه جا کرده‌ام. واحد این عددها برای من ملموس‌تر است.واحد نوشتن چیست؟همه عددهای بالا و همینطور اثر بیرونی که روی خوانندگان و همینطور در مقیاس بزرگتر طبیعت و جامعه اطرافم گذاشتم اعدادی هستند که من دوستشان دارم و به آنها افتخار می‌کنم. اگر چنین ویدیویی دست شما نیز رسید به شما بابت تک تک اعداد تبریک می‌گویم.اثر هر نوشته تا حدودی معلوم است، اگر بنویسید جلوی قطع درخت را می‌گیرید، به سرانه مطالعه کشور اضافه می‌کنید و خوانندگانی جذب می‌کنید که شما را از طریق نوشته‌هایتان می‌شناسند و …به نظرم می‌رسد که نوشته‌های من و شما واحد ندارند ولی اثر بیرونی دارند.

بررسی انواع Flow های گیت

مصطفی حسینخانی — Sun, 02 Aug 2020 15:42:05 +0430

در مقالات قبلی ابتدا گیت رو توضیح دادیم و سپس مدیریت برنچ ها که لینک های آن در زیر قرار داده شده است:گیت به زبان سادهمدل موفق در برنچینگ گیت (Git Branching)در این مقاله ما میخواییم پرطرفدارترین flow های رایج گیت رو برای کابران گیت توضیح بدیم تا هرکدام که موردنظر خودتون هست استفاده کنین.Git Flowرایج ترین Flow می باشد که در سال 2010 توسط وینسنت ارائه گردید، طبق نظر ایشون ما دو برنچ اصلی داریم که همیشه در مسیر نرم افزار هستند و حذف نمیگردند.Master : برنچ محصول نهایی در این برنچ قرار میگیرد و نسخه مطمئن و قابل اجرا را ما در هر لحظه در این برنچ داریم.Develop : برنچی که تمامی توسعه ها از این منشعب شده و به قولی نسخه pre-production در این برنچ موجود می باشد و تمامی feature از این برنچ منشعب و ادغام میشونددر طول مسیر برنچ های پشتیبانی (supporting branch) ها به شکل زیر می باشند:feature-* : برنچ هایی که ویژگی های جدید به پروژه ما اضافه خواهند کرد، که از برنچ develop منشعب و دوباره با همین برنچ ادغام میشوند.hotfix-* : برنچ هایی که برای باگ های حیاتی (critical) ساخته میشوند و همیشه از master منشعب شده و با برنچ های master , develop ادغام میشوند.release-* : برنچ هایی که برای ایجاد نسخه اجرایی با تعریف نسخه نرم افزاری جدید ساخته میشوند .مزایاهمیشه و در هر لحظه ساختاری مرتب و تمیزی از ساختار برنچ ها داریمالگوهای نام گذاری موجود باعث ایجاد برنچ های با معنی میشوداین الگو های در اکثر ابزارهای گیت پشتیبانی می شوداگر ما نیاز داشته باشیم چند نسخه از محصول داشته باشیم این روش ایده آل استمعایبتاریخچه گیت در این روش خیلی سخت خواهد بودبرنچ های master / developer بخاطر تکرارهایی که دارد در مباحث CI/DI کار را دشوار میکندبرای محصول هایی که تک نسخه می باشند این روش توصیه نمی شودGitHub Flowاین Flow به سبک بودن معروف می باشد که در سال 2011 ایجاد شد و داری 6 قانون زیاد می باشد:هر چیزی در برنچ master قابل استقرار می باشدهمه برنچ ها از master منشعب شده و با نام های توضیفی مشخص میشوند( به فرض می خواهیم پرداخت الکترونیک بانک ملت را اضافه کنیم : mellat-payment)کامیت های روی سیستم خود را مرتب به بالا(سرور) پوش میکنیمدرخواست pull request رو وقتی میزنیم که برنچ تکمیل شده باشه، نیاز به کمک یا فیدبک داشته باشیمبعد از اینکه تغییرات بررسی و تایید شد میتونیم با برنچ master ادغام کنیمبعد از ادغام و بالا فرستادن master میتونید استقرار داشته باشیدمزایابرای مباحث CI/DI خیلی عالی هستن و بدون مشکلی پیش میرهیک جایگزین ساده برای Git Flow می باشدبرای مواقعی که فقط ی نسخه داریم روش ایده آلی می باشدمعایببرنج master (کلا کدمون) خیلی پیش میاد که قابل اطمینان نباشهبرای مباحث Release جالب نیست و عملا طرحی برای اون ندارهدر رابطه با release,deploy,issue,environment راه حلی نداردبرای مواقعی که چندین نسخه داریم مناسب نمی باشندGitLab Flowاین flow توسط GitLab در سال 2014 ایجاد شده است. که بر مبنای feature-driven-development و برنچ های feature با دنبال کردن issue ها می باشد.بیشترین تفاوت بین GitLab Flow و GitHub Flow در مبحث Environment برنچ هاست که در GitLab Flow وجود دارند(مانند stage , production).این Flow دارای 11 قانون می باشد :برنچ های feature مستقیم در master کامیت(ثبت) نمی شوند.تنها برنچ مستر تست نمی شود و تمامی کامیت ها تست می شود همه تست ها بعد از هر کامیت اجرا می شوندقبل از ادغام بررسی کدها انجام می شوند نه بعد از ادغام شدن.استقرار ها خودکار می باشند مبتنی بر ببرنچ یا tags.کاربر tag ها را تنظیم میکند نه CI(Continues Delivery)نسخه ها براساس tag ها می باشدکامیت هایی که بالا پوش می شوند هرگز rebase نمی شوندهمه از master شروع کرده و به master ختم می شوندهمیشه اول باگ های master حل شده سپس release انجام می شوندپیام های هر کامیت باید با معنی باشندمزایا در این روش نحوه ایجاد CI/DI تعریف شده است تاریخچه گیت خیلی خوانا می باشد و فاقد بی نظمی می باشدبرای تک نسخه ای ها ایده آل می باشدمعایببه مراتب خیلی پیچیده تر از GitHub Flow می باشددر مواقعی که برای نگه داری چندین نسخه در محصول بخواهیم استفاده کنیم پیچیدگی های رو بوجود میارهOne Flowاین مدل روش جایگزینی است که در مقاله GitFlow considered harmful by Adam Ruka در سال 2015 مطرح شد. شرط اصلی که این مدل را راضی نگه میداره اینه همیشه انتشار های جدیدی که در سیستم شروع میشوند بر پایه انتشار های قبلی شروع می شوند. عملا در این مدل ما برنچ Develop رو نداریم و اصلی ترین تفارتش با Git flow می باشد.مزایاتاریخچه گیت خیلی خوانا می باشد و فاقد بی نظمی می باشدمنعطف با تصمیمات تیم می باشدبرای تک نسخه ای ها ایده آل می باشدمعایببرای پروژه هایی که CI/DI دارند اصلا پیشنهاد نمیشودبرنچ های که برای ویژگی های جدید ایجاد میشوند در واقع CI را سخت تر میکندنتیجهاینها موارد مطرحی بودند که برای flow های گیت استفاده میشود. هر چند ممکن است تیم هایی با توجه به نیاز خودشون flow اختصاصی خودشون رو ایجاد کرده باشند. اگر از روش های بهتری استفاده کنید شما چه چیزی پیشنهاد میکنین؟منابع“A successful Git branching model” by Vincent Driessen“GitHub Flow” by Scott Chacon“GitFlow considered harmful” by Adam Ruka“A succesful Git branching model considered harmful” by Jussi Judin“Introduction to GitLab Flow” by GitLab“OneFlow — a Git branching model and workflow” by Adam Ruka“The 11 Rules of GitLab Flow” by GitLab

مدل موفق در برنچینگ گیت (Git Branching)

مصطفی حسینخانی — Sun, 02 Aug 2020 12:09:57 +0430

در پست قبلی مم سعی کردم گیت رو به زبان ساده توضیح بدم و راه اندازی و استفاده اش رو هم ساده بیان کنیم.در این پست الگوی توسعه ای را ارائه می دهم که من حدود یک سال پیش برای برخی از پروژه های خود (اعم از محل کار و خصوصی) معرفی کرده ام ، و بسیار موفق است. فقط در مورد جزئیات پروژه ها صحبت نخواهم کرد و در مورد استراتژی برنچ و مدیریت انتشار ها (Release) صحبت خواهم کرد.چرا گیت؟برای رسیدن به پاسخ این سوال بحث های زیادی در بستر نت شده است و میتوان با یک جستجو به همه این ها رسید، پس ما هزینه ای برای توضیح این مورد نکرده و به گام بعدی میرویم.برنچ های اصلیما همیشه دو برنچ داریم که عمر آنها نامتناهی است و هیچوقت پاک نمیشود.MasterDevelopبرنچ Master که برای همه برنامه نویسان که با گیت کار میکنن آشناست، برنچی که همیشه محصول آماده برای انتشار در آن قرار میگیرد و به قولی مطمئن ترین نسخه و همچنین تست شده ترین از سیستم در حال توسعه در این برنچ قرار داد، برنچ Develop هم همتراز با برنچ Master پیش میره و همه توسعه ما و آخرین تغییرات تحویل داده شده توسط برنامه نویسان روی این برنچ می باشد.وقتی که کد در برنچ Develop به یک نقطه پایدار میرسه و آماده انتشار میشه، باید تمام تغییرات را به نوعی در Master ادغام کرده و با شماره انتشار برچسب گذاری کنید. در مورد چگونگی انجام این کار به تفصیل در ادامه بحث خواهد شد.برنچ های پشتیباندر کنار برنچ های Master و Develop ، مدل توسعه ما از انواع مختلفی از برنچ ها برای کمک به توسعه موازی بین اعضای تیم حمایت میکند،که برای ردیابی ویژگی‌ها، آماده‌سازی برای انتشار نسخه و کمک به حل سریع مشکلات لحظه ای استفاده می شود. بر خلاف شاخه‌ Master، این برنچ ها همیشه زمان محدودی دارند، چون در نهایت حذف خواهند شد.انواع مختلفی که ما استفاده میکنیم عبارتند از:Feature branchesRelease branchesHotfix branchesهرکدام از این برنچ ها برای هدف خاصی ایجاد میشوند و همینطور مشخص میشود که از کدام برنچ انشعاب گرفته میشوند و کدام برنچ برای Merge شدن با آنها است.به هیچ وجه این برنچ ها خاص نیستند و فقط ما برای هدف های خاصی این دسته بندی ها را ایجاد کرده ایم.Feature branchesهمینطور که از نام این دسته مشخص هست برای اضافه کردن ویژگی های جدید به سورس از این نوع برنچ ها استفاده میکنیم که برنچ ها از Develop منشعب شده و دوباره با همین برنچ ادغام (Merge) خواهند شد.هرگز برای نام گذاری برنچ های منشعب شده از اسامی زیر استفاده ننمایید:master, develop, release-*, hotfix-*برنچ های feature برای توسعه ویژگی های جدید برای نسخه آینده یا آینده دور استفاده می شوند. هنگام شروع یک ویژگی جدید، تاریخ لانچ این ویژگی ممکن است در لحظه شروع ناشناخته باشد. ماهیت یک شاخه ویژگی این است که تا زمانی که این ویژگی در حال توسعه است ، وجود دارد ، اما در نهایت دوباره با develop ادغام می شود (قطعاً ویژگی جدید را به نسخه بعدی اضافه می کنیم) یا حذف(دور ریخته) می شود (در صورتی که تست ناامید کننده ای داشته باشد).این برنچ ها فقط در برنچ های برنامه نویس موجود هستیند و در origin وجود ندارند.Release branchesاز این نوع برنچ برای تهیه نسخه های بیلد استفاده میکنیم در واقع وقتی میخواهیم نسخه ای استیبل از سیستم با ویژگی های جدید خروجی گرفته شود از این نوع استفاده میکنیم.وقتی به نقطه ای میرسیم که میتوانیم یک release از سورس داشته باشیم به این معنی هست که تمامی feature برنچ های که ادغام شده اند عملا حذف گردید و برنچ develop برای ایجاد feature های جدید آماده شده است.Hotfix branchesبرای هدف رفع باگ های بهرانی(critical) سیستم استفاده میشود و همیشه از برنچ master انشعاب شده و با برنچ های master یا develop میتواند ادغام شود.از نظر عملکردی شبیه به نوع برنچ های Release می باشد و بعد از پایان هر برنچ یک نسخه production به نسخه اصلی اضافه میشود.این برنچ به این گونه است که سایر برنچ ها منتظر اتمام این برنچ نمی مانند و همه به مسیر خودشان ادامه میدهند، فقط بعد از پایان و مرج با master , develop سایر برنچ ها میتوانند از برنچ های اصلی pull گرفته تا تغییرات hotfix ها را داشته باشند.سخن آخرحالا که همه اینها رو متوجه شدیم تصویر اولی برای ما تصویر مبهمی نیست و یک توصیر کلی (big picture) از روند کار می باشد.

گیت به زبان ساده

مصطفی حسینخانی — Sat, 01 Aug 2020 12:18:06 +0430

این مقاله رو برای این مینویسم که خیلی جاها از من سوال میشه که گیت رو براشون توضیح بدم، و یاد حرف جدی میوفتم که میگه اگر ی سوال رو بیشتر از دوبار پرسیدن باید تبدیل به مقاله بشه و همیشه رفرنس بدی بهشون، پس منم تصمیم گرفتم همه آنچه که نیازه بیام و اینجا بنویسم.گیت (Git) چیستمطابق توضیحی ویکی پدیا، گیت یک نرم‌افزار کنترل نسخه و متن‌باز می باشد که برای مدیریت منبع کد است و برای دنبال کردن تغییر فایلهای کامپیوتری و دنبال کردن کردن کارهای انجام شده روی آنها توسط افراد مختلف است. هدف اولیه این نرم‌افزار برای استفاده در پروژه‌های نرم‌افزاری بوده است ولی می‌توان از آن تنها برای دنبال کردن تغییر فایل‌ها هم استفاده کرد.برای یک تیم حرفه ای مهمه که همه اعضای(Developer های) اون بتونن با ابزارهای معین شده در تیم کار کنند. یا حداقل آشنایی استفاده از این ابزارها را داشته باشند. دلیلشم اینه که گیت یه کپی از پروژه رو به دست هر کدوم از اعضای تیم میرسونه و به تیم این قدرت رو میده که بتونن همزمان به تکمیل بخش های مختلف بپردازن و توسعه خودشون رو تکمیل کنند.منظور از آشنایی اعضای تیم این است که بتونن با 4 کامند اصلی (Pull,Push,Commit,Add) این ابزار کار کنند.خوب بریم برای استفاده ابزار تا بهتر بتونیم درک کنیم.برای شروع ابتدا باید Git رو روی سیستم خودتون نصب کنین، که بعد از نصب یک Bash به ما میده که میتونیم دستوراتش رو اجرا کنیم(ی چیزی شبیه به CMD). محیط git Bashابزارهای گرافیکی قوی هم هستند که برای دوستانی که با کامند راحت نیستند میتونند استفاده کنند که چند نمونه اش رو لیست میکنمSourceTreeTortoiseGitGit Extensionsمشاهده همه ابزار هاشروع گیتما برای شروع دو حالت داریم یا میخواییم یک ریپازیتوری جدید بسازیم یا میخواییم ریپازیتوری موجود رو بگیریم و کار کنیم.در حالت اول ما با استفاده از دستور init میتونیم ی پپوشه رو به گیت بدیم و برامون مدیریت کنه.برای این کار به اون مسیری که میخواییم میریم و دستور $ git initاجرای دستور git initکه با این کار شما، گیت یک فایلی که پنهان هست به نام .git میسازید که اطلاعات فایلتون رو اون تو مدیریت میکنه .حالا اولین گام برای تست گیت رو برمیدارم یک فایل داخل مسیر میسازیم ( با هر روشی ) تا ببینیم گیت چ رفتاری برای این حالت داره.من یکی فایل متنی با نام one.txt میسازم و بعد از اون دستور زیر رو میزنم ببینم گیت چ واکنشی به فایل جدید من داره$ git statusاجرای دستور git statusهمینطور که در تصویر بالا میبینیم بهمون میگه که دوست خوب من شما یه فایلی داری که هنوز بهم نگفتی که مدیریتش کنم ( دستور git status یه دستور هست برای اینکه شما ببینید فایل هاتون تو چه شرایطی هستن هنوز به مدیریت گیت اضافه شدن یا نه ؟ یا مثلا این فایل ها نهایی شدن یا نه ؟ )حالا برای الینکه به گیت بگیم مدیریتش با شما از دستور زیر استفاده میکنیم$git add one.txtبعد از دستور بالا دوباره دستور git status رو اجرا میکنیم تا رفتار گیت رو ببینیمبعد از اجرای دستور git addهمینطور که میبینیم گیت مسئولیت فایل رو بر عهده گرفت حالا بریم ببینیم در برابر تغییرات چ رفتاری داره، برای این کار من محتویات فایل one.txt رو تغییر میدم دوباره وضعیت رو چک میکنمبعد از تغییرات فایلبله همینطور که میبینیم داره بهم میگه که تو فایلتو تغییرش دادی پس با گیت میتونیم اینطوری ببینیم و بهمون کمک میکنه که با دقت تر کد بزنیم!خوب بعد از تغییرات ما باید این تغییرات رو ثبت کنیم که برای اینکار از دستور commit استفاده میکنیم$git commit -m [message]احرای دستور git commitخوب گیت این تغییرات رو ثبت کرد و از این به بعد به تغییرات جدید گوش میده.گیت توی دولایه دیتا رو برای ما نگه میداره یکی که میشه لوکال خودمون که با دستور کامیت فقط روی لوکال ما ثبت میشه اگر ما بخواهیم داده ها رو روی سرور منتقل کنیم از دستور Push استفاده میکنیم.کار با ریپازیتوری های گیت سروراگر ما بخواهیم تغییرات رو روی سرور منتقل کنیم تا همه همکاران هم بهش دسترسی داشته باشند هم برای کارهای Merge , ... که بهش خواهیم رسید باید به سرور یا به اصطلاح بالا ارسال بشوند.ما فرض بر این میگیریم که سرور ما بالا آماده است (GitHub,GitLab,Azure Git , ای سرور شخصی)در اینجا با استفاده از دستور push ما تغییرات Commit شده خودمون رو میتونیم به بالا منتقل کنیم.$git push origin [branchName]حالا اگر ما بخواهیم آخرین تغییرات بالا رو بیاریم روی لوکال خودمون از دستور Pull استفاده میکنیمgit pull [] [ […]]تا اینجا موارد پایه کار با ابزار بود حالا بریم سراغ مواردی که باید بدونیم.مبحث اول Branchزمانی که با استفاده از گیت یک ریپازیتوری جدید می‌سازیم، به صورت خودکار یک برنچ (شاخه) تحت عنوان master ساخته می‌شود که نقش شاخهٔ اصلی ریپازیتوری مذکور را بازی خواهد کرد و هر کامیتی که انجام دهیم نیز روی این شاخه اِعمال خواهد شد و این در حالی است که معمولاً‌ تیم‌های نرم‌افزاری از این شاخه به عنوان نسخه‌ای از نرم‌افزار استفاده می‌کنند که قرار است روی سرورهای اصلی دیپلوی(Deploy) گردد. با این تفاسیر، منطقی به نظر می‌رسه که این بِرَنچ به عنوان فضای آزمون و خطا در حین کدنویسی قملداد نشده بلکه فضاها یا بهتر بگوییم شاخه‌های فرعی دیگری ساخته و در آن‌ها اقدام به توسعهٔ فیچرهای جدید نموده سپس آن‌ها را با شاخهٔ مَستر ادغام نمود.یکی از مزایای وجود شاخه‌ها در سیستم گیت این است که می‌توان به تعداد توسعه‌دهندگانی که در تیم حضور دارند برنچ‌های اختصاصی ساخته و در آنِ واحد تمامی اعضای تیم بتوانند اقدام به توسعهٔ نرم‌افزار کنند. برای درک بهتر این موضوع، فرض کنیم برنامه نویسی داریم به نام بهزاد قرار است قابلیت درگاه پرداخت را به پروژه بیفزاید و دولوپر دیگری به نام سهند قرار است تا رابط کاربری را تکمیل کند؛ در چنین شرایطی، می‌توان دو شاخهٔ‌ فرعی از شاخهٔ مَستر تحت عناوین دلخواهی همچون behzad-branch-gateway و sahand-branch-ui ایجاد کرده و هر کدام از ایشان با سهولت هرچه تمام‌تر شروع به کدنویسی کرده و چنانچه در نهایت کدهای نوشته‌شده مورد تأیید مدیر فنی بود،‌ با شاخهٔ اصلی (مَستر) ادغام خواهند شد.همان‌طور که در تصویر فوق ملاحظه می‌شود، خط عمودی که در سراسر نمودار ملاحظه می‌شود به عنوان بِرَنچ اصلی یا مَستر است که فرض می‌کنیم توسط توسعه‌دهندهٔ اصلی پروژه کامیت‌هایی تحت عناوین C1 و C2 انجام شده است. سپس یک شاخه از شاخهٔ اصلی جدا شده و نامی دلخواه همچون Branch1 برای آن در نظر گرفته‌ایم که فرضاً توسط یکی از اعضای تیم هَندل می‌گردد به طوری که وی سه کامیت داخل این شاخه انجام داده است. در آنِ واحد،‌ برای یکی دیگر از اعضای تیم شاخه‌ای به نام Branch2 ساخته شده و او نیز یک کامیت انجام داده است. در نهایت، دولوپر اصلی این پروژه کلیهٔ تغییرات اِعمال‌شده در دو بِرَنچ فوق را با بِرَنچ اصلی (مَستر) ادغام کرده و کلیهٔ‌ این تغییرات را تحت عنوان C7 کامیت کرده است.با این توضیحات تئوریک،‌ در ادامهٔ‌ این آموزش خواهیم دید که به چه شکل به صورت عملی می‌توانیم اقدام به ساخت بِرَنچ‌های مختلف کرده سپس آن‌ها را با یکدیگر ادغام نمود. ادامه این بخش رو میتونیم از منبع اصلی این بخش یعنی سکان آکادمی استفاده کنیم.و همینطور برای این قسمت من مقاله هایی در خود ویرگول دیدم که لینک هاش رو قرار میدم تا استفاده کنینچگونه از Branch ها برای مدیریت کدها در گیت استفاده کنیممکمل قدرتمند گیت git flowو همچنین نکات مفیدی که در گیت میتونیم استفاده کنیم تا به اصطلاح Best Practice کار کرده باشیم هم در لینک زیر دوست خوبمون زحمتش رو کشیدنBest Practice های گیت

تست نرم افزار چرا انقدر مهمه و بهش پرداخته میشه؟!

مصطفی حسینخانی — Fri, 10 Apr 2020 22:07:50 +0430

تست نرم افزار چرا انقدر مهمه و بهش پرداخته میشه؟!واژه های TDD, BDD, Unit Testing, Integration Testing,... زیاد میشنویم. اینها چیزهایی جدیدی نیستن و از خیلی سالها در اختیار برنامه نویسان بوده و ازش استفاده میکردن اما به مرور به اهمیت اون پی بردن(بیشتر کشور خودمون منظورمه).چرا اینهمه اصرار برای تست وجود داره؟آیا واقعا تست نوشتن باعث بهتر شدن برنامه و ما میشه!؟آیا تست نوشتن هزینه است و هیچ فایده ای ندارد؟!و کلی سوالاتی که همه ما یا باهاش آشناییم یا وقتی پیشنهاد به کارفرما دادیم باهاش مواجهه شدیم.-اجازه بدین با چند نمونه از اتفاقاتی که همه تجربه کرده ایم شروع کنیم (با روضه شروع کنم و دلاتونو آماده کنم). نرم افزار مون لانچ شده و داره کار میکنه سیستم توی فشار خوب کار نمیکنه، دستور از بالا میاد که ند تغییر کوچیک یا اصلاح انجام بدین تا سربار سیستم بیاد پایین. سریع دست به کار شدیم و نیم ساعت انجام داده و سریعا تلفن رو برداشته و به مدیر خود با خوشحالی گزارش میدهیم که کار انجام شد و لانچ شد و قطعا انتظار اینو داریم مدیر هم تشکر کرده یا از داشتن همچین نیروی فرض و چابکی خوشحال بشه. اما اتفاقی که میوفته اینه که فاجعه پیش میاد و مهمترین وظیفه (بیزینس) سیستم از کار میوفته و همه چی برعکس میشه و کلی تماس و حجمه و ... به ما وارد میشه و بماند برای ادامه که توبیخ و شاید اخراج منجر بشه.نسخه جدید سامانه رو بعد از مدت ها تلاش و فشار کاری و فورس بودن توی تاریخ مقرر بالاخره آخر وقت لانچ کرده و خوشحال از اینکه از فشاری کاری خارج شدی و میتونی چند روز مرخصی بگیری و بری استراحت درست و حسابی و مسافرت داشته باشی، اما تا پاتو از شرکت میزاری بیرون از نفر بالاسریت تا مدیر شرکت باهات تماس میگیرن که این چرا بدون تست کردن برنامه، کار رو بالا گذاشتی و دوباره کلی توبیخ و اتمام حجت و ...و قس علی هذااما بعد از این همه اتفاقات و جلسه ای که بابت این قبیل اتفاقات گرفته میشه جز اینکه دنبال مقصر گشتن و یکی رو نشونه گرفتن و همه خوشحال از اینکه قربانی برای معرفی به هر مقام بالایی جور شد. غافل از اینکه نباید اینطور مواقع دنبال مقصر گشت و همه چیز رو سر اون خراب کرد، باید دنبال علت تکرار این اتفاقات افتاد.موارد بالا چندتا از اتفاقات اخیر برای من بوده . همه فکر کنم کمو بیش تجربه داشتن. ولی چ خوب بود روشی بود که میشد توی چند دقیقه کل سیستم رو تست کنیم و مطمئن لانچ کنیم.اما همه این اتفاقات باعث شد تا من که چند سالی بود کم و بیش مطالعه های در مورد تست داشتم و هیچ وقت نتونستم بصورت جدی ازش استفاده کنم و اعضای تیم و مدیران تیم رو راضی کنم که ازش استفاده کنیم، یه مدتی هست که دارم خارج از ساعت کارم برای کیفیت کاری که دارم انجام میدم شروع کنم به تست نوشتن. بعد از این همه مدت تصمیم گرفتم که در این ضمینه شروع کنم به آموزش تست هایی که عملی خودم کار میکنم. هم سمت فرانت و هم بک اند(دوستانی هم که بتونن کمک کنن و از تجربیاتشون بگن هم خوشحال میشم).میخواستم اصطلاحات و انواع تست رو بنویسم که ترجیح دادم از این مقاله که آقا بهروز زحمتش رو کشیدن استفاده کنیم: نگاهی به انواع تست نرم افزارTest Automationچرا تست نرم‌افزار مهم است(جدی بشم یکم!)بیایید با در نظر گرفتن چرا تست لازم است، تست ضروری است زیرا همه ما اشتباه می کنیم. برخی از این اشتباهات مهم نیستند ، اما برخی گران هستند و ممکن است تهدید کننده زندگی باشند. ما باید همه چیزهایی را که تولید می کنیم آزمایش کنیم زیرا همه چیز میتواند اشتباه شود. انسانها می توانند هر زمان اشتباه كنند.خطاهای انسانی می توانند در هر مرحله از چرخه عمر توسعه نرم افزار باعث نقص یا خرابی شوند . بسته به عواقب خطا ، نتایج به صورت بی اهمیت یا فاجعه بار طبقه بندی می شوند.نیاز به تست دقیق و مستندات مرتبط با آنها در چرخه عمر توسعه نرم افزار به دلایل زیر ایجاد می شود:برای شناسایی باگ های نرم افزاراستفاده به عنوان مستندات نرم افزار(live documents)برای کاهش مشکلات و نواقص سیستمکیفیت کلی سیستم و کدها را افزایش می دهد( ولی واقعا تست ما رو وادار میکنه که کد تمیز بنویسیم و طراحی نرم افزارمون خوب بشه)همچنین می تواند یک الزام برای انجام تست نرم افزار برای مطابقت با الزامات قانونی یا استانداردهای خاص صنعت باشد. این استانداردها و قوانین می توانند مشخص کنند که چه نوع تکنیکی را باید برای توسعه محصول استفاده کنیم. به عنوان مثال ، صنایع موتور ، اویونیک ، پزشکی و داروسازی و غیره ، همگی دارای استانداردهای لازم برای آزمایش محصول هستند. نکات زیر اهمیت تست یک محصول نرم افزاری قابل اعتماد و آسان را نشان می دهد:آزمایش مهم است زیرا قبل از تحویل به مشتری ، نقایص / اشکالات را کشف می کند ، که کیفیت نرم افزار را تضمین می کند.این نرم افزار را قابل اعتماد تر و آسان تر می کند.نرم افزار کاملاً تست شده عملکرد نرم افزار قابل اعتماد و با کارایی بالا را تضمین می کند.به عنوان مثال ، فرض کنید شما از یک برنامه بانکی برای انتقال مبلغ به حساب دوست خود استفاده می کنید. بنابراین ، شما معامله را آغاز می کنید ، یک پیام معامله موفقیت آمیز دریافت می کنید ، و مبلغ نیز از حساب شما کسر می شود. با این حال ، دوست شما تأیید می کند که حساب وی هنوز اعتبار دریافت نکرده است. به همین ترتیب ، حساب شما نشان دهنده معامله معکوس نیز نیست. این مطمئناً شما را ناراحت کرده و شما را به عنوان مشتری ناخوشایند می کند.این سؤال پیش می آید که چرا این اتفاق افتاد؟ این به دلیل تست نادرست برنامه بانکی قبل از انتشار است. تست دقیق وب سایت برای کلیه عملیات احتمالی کاربر منجر به شناسایی زود هنگام این مشکل می شود. بنابراین، می توان قبل از انتشار آن برای یک تجربه روانتر، آن را برطرف کرد.سهم تست در موفقیتدر مثال بالا می توانیم مشاهده کنیم که به دلیل وجود نقص، سیستم نتوانسته عملیات مورد نیاز را انجام بده و شرایط مشتری را برآورده کنه. تکنیک های مناسب تست استفاده شده در هر سطح از آزمون نرم افزار، کاهش مطلق در فراوانی چنین خرابی های نرم افزاری را تضمین می کند.تحویل یک محصول نرم افزاری با کیفیت مطلوب که دارای ویژگی های منحصر به فرد و خلاقانه است ، همواره در اولویت صنعت نرم افزار در سراسر جهان بوده است. اما ، بدون ارزیابی مؤلفه های نرم افزار در شرایط مختلف مورد انتظار و غیر منتظره، تیم نمی تواند این جنبه ها را تضمین کند. بنابراین ، تست برای هر مؤلفه نرم افزاری بزرگ و کوچک انجام می شود.برای درک اهمیت تست نرم افزار، به نکات زیر توجه می کنیم: تست نرم افزار ضروری است، شاید نیاز به شروع دوباره نرم افزار نباشید: گاهی اوقات، ما یک محصول نرم افزاری کاملاً توسعه یافته را در برابر نیاز کاربر تست می کنیم و می بینیم که برخی عملکردهای اساسی وجود ندارد. این ممکن است به دلیل اشتباه در جمع آوری نیاز یا مرحله کدگذاری اتفاق بیفتد. سپس برای رفع این قبیل خطاها، شاید لازم باشد که توسعه را از ابتدا شروع کنیم. رفع چنین اشتباهاتی بسیار خسته کننده، وقت گیر و گران می باشد. بنابراین، همیشه امتحان کردن نرم افزار در مرحله توسعه آن مطلوب است. ارزیابی سهولت استفاده از نرم افزار: سهولت استفاده یک مفهوم ساده است. مشخص می کند که کاربران در نظر گرفته شده به راحتی می توانند از محصول نهایی استفاده کنند. آزمایش نرم افزار ساخت محصول نرم افزاری را به گونه ای تضمین می کند که انتظارات کاربر را در رابطه با رعایت خواسته ها به روشی راحت ، رضایت بخش و ساده تر برآورده کند.تأیید کلیه جنبه های نرم افزار: می توانید تمام جنبه های نرم افزار را در تست نرم افزار مانند بررسی عملکردهای اساسی و همچنین تست یک سیستم برای شرایط غیر منتظره تأیید کنید. شرایط غیر منتظره می تواند از نوع نادرست داده یا ناشی از حمله دزدی دریایی باشد. بنابراین ، آزمایش اطمینان می دهد که سیستم می تواند خیلی خوب این شرایط را اداره کند. بنابراین، اگر خطایی را از قبل پیدا کنیم، فرصت اصلاح آنها را داریم.تست های نرم افزاری به سرعت بخشیدن به توسعه کمک می کند: تست های نرم افزاری به توسعه دهندگان کمک می کند تا خطاها و سناریوها را برای تولید پیدا کنند، که به نوبه خود به آنها کمک می کند تا سریع آن را برطرف کنند. علاوه بر این ، تست کنندگان نرم افزار می توانند به طور موازی با تیم توسعه همکاری کنند، بنابراین از جزئیات، طراحی، مناطق خطر و غیره را درک می کنند. این تبادل دانش بین تست کنندگان و توسعه دهندگان باعث تسریع در کل فرآیند توسعه می شود.نتیجهاهمیت تست نرم افزار امری ضروری است. زیرا باعث بهتر شدن کد نویسی (Clean Code) و به مراتب طراحی درست سیستم (Clean Architecture) میشود، همچنین باعث تولید محصول با کیفیت تر و مطمئن تر و مشتریانی راضی تر داشته باشیم.در ادامه ما شروع به کد نویسی برای تست نوشتن خواهیم کرد که به شرح زیر استTest On AngularTest On C#