https://virgool.ir/feed/@nazanin.sayadiتوسعه دهنده نرم‌افزارfa2026-11-11 10:51:45https://files.virgool.ir/upload/users/73252/avatar/S30UNV.pnghttps://virgool.ir/@nazanin.sayadihttps://virgool.ir/@nazanin.sayadi/solid-principles-srp-ooqx1vesyn34قبل از هر چیزی، بیایید تکلیفمان را با کلمه‌ی «اصول» در عبارت «اصول SOLID» روشن کنیم.قاعده، قانون و وحی‌منزل نیستند. رابرت.سی.مارتین در مقاله‌ای میگوید جمله‌ی «An apple a day, keeps the doctor away» یک اصل و توصیه‌ی خوبه! اما حقیقتِ محض یا قانون نیست.اصول، به مفاهیم یک اسم اختصاص میدهد تا ما بتوانیم با استفاده از آن اسم‌، راجع به آن مفهوم حرف بزنیم و استدلال کنیم. با این تعریف‌، اصول مثل یک مرهم و یا آرام‌بخش‌ هستند - در مورد کدی که به آن احساس بدی دارید، شاید بتوانید اصلی را پیدا کنید که به شما توصیه‌ای برای اینکه حس بهتری پیدا کنید بدهد.چنین اصولی، اکتشافی‌ هستند - توصیه‌هایی متداول برای حل یک‌سری مشکلات مشترک!اما مثل هرچیزِ اکتشافی دیگری، ماهیت تجربی دارند. در خیلی از موارد استفاده می‌شوند و جواب میدهند. اما هیچ مدرکی نیست که ثابت کند همیشه جواب میدهند یا باید همیشه از آنها پیروی کنیم.تقریبا هر تصمیم و انتخابی در مسیر توسعه نرم‌افزار یک Trade-off است - نه یک انتخاب مطلقا خوب یا مطلقا بد. Trade-off کردن یعنی پذیرفتن معایب و هزینه‌های یک انتخاب در برابر مزیت‌هایی که در یک Context مشخص برای ما دارد و یکی از مهم‌ترین تصمیمات ما به عنوان توسعه‌دهنده‌ی نرم‌افزار بالانس کردن این Trade-offها و پذیرفتن هزینه‌ای‌ست که آن تصمیم در قبال چیزی که به دست می‌آوریم برای ما در پی دارد.اصول SOLIDمجموعه‌ای از اصول طراحی، در توسعه یک نرم‌افزارِ شی‌گراست. فلسفه‌ی طراحی شی‌‌گرا نه ابزارهایی‌ست که در اختیار ما قرار می‌دهد و نه کمکی که در مدل کردن مفاهیم واقعی به ما می‌کند، بلکه به دلیل کمک در مدیریت کردن وابستگی‌هاست و با این رویکرد، اصول SOLID تضمین میکنند که وابستگی در سیستم ما درست مدیریت شود. این اصول در کنار هم، فرآیند توسعه و نگهداری نرم‌افزار را تسهیل می‌کنند.در نگاه اول این 5 اصل مستقل از هم به نظر می‌رسند اما نقض کردن هر کدام از آنها با احتمال بالایی منجر به نقض شدن 4 اصل دیگر میشود. آن‌ها می‌توانند از ایجاد Code Smellها جلوگیری کنند ،انجام Refactoring را راحت‌تر کنند و حتی می‌توانند یک فلسفه‌‌ی اصلی برای روش توسعه‌ی چابک و توسعه‌ی یک نرم‌افزار Adaptive باشند.SOLID مخفف پنج اصل طراحی زیر است که در این نوشتاره‌ از اصل اول صحبت می‌شود و در آینده به باقی اصول می‌پردازیم :Single Responsibility PrincipleOpen/Closed PrincipleLiskov Substitution PrincipleInterface Segregation PrincipleDependency Inversion Principleاصل اول | SRPهر ماژول نرم‌افزاری باید، فقط و فقط یک دلیل برای تغییر کردن داشته باشد.معنی «یک دلیل برای تغییر کردن» چیست؟مثلا Bug-Fixing یا Refactoring هم یک دلیل برای تغییر کردنِ یک ماژول هستند؟توضیح کلمه‌ی «مسئولیت»، به واضح شدن پاسخ این سوال کمک می‌کند. قاعدتاً مسئولیت رفع خطا و Refactoring با توسعه‌دهنده‌ست، نه کد و برنامه!سوال درست‌تر این است که کد ما مسئول چه عملکردی در برنامه‌است؟برای پاسخ دادن به این سوال، مثال زیر را از مقاله‌ای که توسط آقای رابرت سی.مارتین منتشر شده است، بررسی می‌کنیم:در یک شرکت نرم‌افزاری، افرادی همچون مدیر ارشد عملیات(COO)، مدیر ارشد مالی (CFO) و مدیر ارشد فنی (CTO) فعالیت دارند. ‌کد زیر را در نظر بگیرید:فرض کنید هر کدام از این مدیران ارشد، در برابر یکی از عملکردهای بالا مسئول‌اند و در صورت ایجاد یک مشکل فاجعه‌بار در نحوه‌ی عمکلرد آنها، شخص مسئول اخراج می‌شود.محاسبه‌ی حقوق، یک مفهوم «مالی»ست و اگر قرار بر تغییر نحوه‎ی محاسبه‌ی حقوق باشد، این درخواستِ تغییر، از طرف CFO شرکت صورت می‌گیرد و ایشان مسئولیت انجام درست این عملکرد را به عهده دارد.تصمیم‌گیری در مورد چگونگیِ ذخیره‌ی موجودیت «کارمند» در دیتابیس و اعمال تغییر در بیزینس فعلی، به عهده‌ی CTO شرکت است و مسئولیت هرگونه اشتباه در نحوه‌ی ذخیره‌سازی گریبان‌گیر CTO می‌شود.و این COO شرکت است که در مورد آیتم‌هایی که باید در گزارش‌ ساعات کاری کارمند وجود داشته باشد و نحوه‌ی گزارش‌گیری اعمال نظر می‌کند و در صورت بروز خطا مسئولیت پاسخ‌گویی به عهده‌ی COOست.از اینجا به تعریف اصل Single Responsibility می‌رسیم.شکستن سیستم به ماژول‌ها و طراحی بر اساس Flowchart تقریبا همیشه کار اشتباهی‌ست. به جای آن، بهتر است با لیستی از تصمیمات سخت طراحی یا تصمیمات طراحی‌ای که احتمال تغییر آنها بیشتر است شروع کنیم. در این صورت هر ماژول به گونه‌ای طراحی می‌شود که آن تصمیم طراحی را از بقیه جدا نگه می‌دارد.منشا این تغییرات «آدم‌ها» هستند. آدم‌ها هستند که درخواست تغییرات را می‌دهند. وقتی یک ماژول نرم‌افزاری را توسعه می‌دهیم،می‌خواهیم مطمئن بشویم که تغییرات فقط می‌توانند «یک منبع اعلام تغییرات» داشته باشند. منظور از این یک منبع، برای مثال یک واحد خاص در سازمان‌ست که عملکرد مشخصی دارد. می‌خواهیم که مبنای طراحی ما به صورتی باشد که هر ماژول، مسئول رفع نیاز فقط یک عملکرد از کسب‌وکار باشد. چرا؟ چون ما نمی‌خواهیم CFO شرکت به دلیل تغییری که CTO روی نحوه‌ی محاسبه‌ی حقوق داده است اخراج بشود!برای رعایت SRP در مثال بالا، طراحی سیستم باید به این شکل تغییر کند:هیچ چیزی ترسناک‌تر از این نیست که مشتری، یک نقص عملکرد در برنامه مشاهده کند که هیچ‌جوره با چیزی که درخواست تغییر آن را داده بود، ربط ندارد و این دلیلی‌ست که ما باید به‌خاطرش مفاهیم High-Cohesion، Separation Of Concerns و Low Coupling رو در تعریف ماژول‌ها رعایت کنیم تا هر چه بهتر، مرز بین چیزهایی که به «دلایل متفاوتی» تغییر می‌کنند را از یکدیگر تفکیک کنیم.اگر که با ایجاد تغییری، دچار تغییر عملکرد در همان ماژول (Rigidity Design Smell) و یا ماژول‌های دیگر (Fragility Design Smell) بشویم و یا مجبور باشیم برای رفع خطا یا هرگونه تغییری چندین و چند کلاس را تغییرات کوچک و بزرگ بدهیم (Shotgun Surgery Code Smell) در تقسیم مسئولیت اشتباه و یک مسئولیت را بین کلاس‌های مختلفی پخش کرده‌ایم و SRP را رعایت نکرده‌ایم.نازنین صیادینازنین صیادیTue, 30 Jun 2020 22:08:46 +0430https://virgool.ir/coderlife/re-engineering-legacy-software-2-jcvr8yutkfs9قسمت قبل | در باب خصوصیات پروژه‌ای که آن را Legacy می‌نامیم | قسمت اول |زیرساخت Legacyاگرچه کیفیت کد، اساسی‌ترین فاکتور Maintainability در پروژه‌های Legacy ست، اما بیشتر نرم‌افزارها برای اجرا شدن وابسته به مجموعه‌ای از زیرساخت‌ها و ابزارها هستند و کیفیت این ابزارها تاثیر به سزایی توی بهره‌وری تیم داره.محیط توسعهفرآیند Checkout کردن پروژه از Version Control و رسیدن به مرحله‌ای که بتونیم اون رو روی سیستم خودمون اجرا کنیم در یک پروژه‌ی Legacy، پروسه‌ی زمان‌بریه و معمولا شامل دانلود و نصب کردن و یادگرفتن راز و رمز وابستگی‌های اون سیستم، اجرای اسکریپت‌های عجیب‌غریب و طی کردن یک سری مراحل دستیه.درسته که این کارها رو یک‌بار و وقتی که میخوایم برای اولین بار پروژه رو بگیریم انجام میدیم، اما فقط ما نیستیم که مجبور به گذروندن این مراحلیم و بهای این ضعف، بالا رفتن زمان تلف‌شده‌ایه که هر توسعه‌دهنده‌ای توی تیم یا در آینده صرف این پرو‌سه‌ میکنه.وابستگی‌های قدیمی و منسوخ شدههر پروژه‌ای به یک‌سری Library و نرم‌افزارهای Third-Party وابستگی داره که میزان تغییرات اونها در اختیار ما نیست. اینکه اونها رو همیشه با آخرین نسخه‌ آپدیت نگه‌داریم هم مستلزم یک تلاش مداومه، اما ارزش زمان صرف کردن رو داره. به‌روزرسانی معمولا موجب بهبود عملکرد میشه، باگ‌ نسخه‌های پیشین رفع میشه و گاهی شامل Patch‌های امنیتی Critical هستند.به‌روزرسانی‌های منظم به ورژن‌های Minor شاید در ماه چند دقیقه وقت بگیره، اما اگه اینکار رو پشت گوش بندازیم، بدون اینکه خبردار بشیم چند ورژن Major رو جا انداختیم و وقتی به صرافت به‌روزرسانی میوفتیم که ریسک و هزینه‌ی توسعه و تست زیادی رو باید متحمل بشیم و نویسنده از شرکتی میگه که در یک پروژه‌ی Legacy ماه‌ها درگیر Upgrade کردن برنامه‌شون از Java 6 به Java 7 بودند. اونها از ترس بروز شکست در قسمت‌های مبهم برنامه سال‌ها در برابر به‌روزرسانی وابستگی‌هاشون مقاومت کرده بودند و چون با یک پروژه‌ی Legacy سر و کار داشتند، هیچ‌کسی دید واضحی از رفتار فعلی برنامه یا رفتاری که ازش انتظار میره داشته باشه، نداشت. زمانی که عمر Java 6 به آخر رسید، تصمیم گرفتند که تن به به‌روزرسانی بدهند و ارتقاء به Java 7 به معنی ارتقاء دادن سایر وابستگی‌ها هم بود. این کار موجب ایجاد شکست در APIهای تغییر کرده، و همچنین ایجاد تغییرات نامحسوس و غیرمستقیم در رفتار برنامه شد. این داستان عاقبت خوشی هم نداشت و پس از چند هفته تلاش برای حل و فصل کردن تغییراتِ رفتاریِ مبهمی که در XML Serialization ایجاد شده بود، از خیر به‌روزرسانی گذشتند.محیط‌های اجرای ناهماهنگبیشتر نرم‌افزارها در طول حیات با عزت‌شون در محیط‌های مختلفی اجرا میشن، مثلا: توسعه‌دهنده‌ها اون رو روی سیستم Local خودشون اجرا میکنندبعد برای تست Automatic و Manual توی محیط تست Deployش میکنند در قدم بعدی توی محیط Stage اون رو Deploy میکنن تا محیط Production رو شبیه‌سازی بکنندو در نهایت Release می‌گیرند و برنامه رو در محیط Deploy ،Production می‌کنندهدف این پروسه‌ی چند مرحله‌ای اینه که قبل از Release کردن، مطمئن بشیم که برنامه داره به درستی کار میکنه. اما ارزش اینکار بستگی به میزانِ همانندی این محیط‌ها با هم داره. محیط Staging اگر که کپیِ دقیقی از محیط Production نباشه ارزشش رو در نشون دادن رفتار برنامه در اون محیط از دست میده. همانندی محیط توسعه و تست با محیط Production هم، باعث میشه مسائل پیش اومده‌ی مربوط به محیط و نرم‌افزار رو - بدون اینکه مجبور به Deploy کردن در محیط Staging باشیم - سریع‌تر تشخیص بدیم. برای مثال استفاده از یک ورژن یکسان از MySQL در همه‌ی محیط‌ها، تمامی شُبهات در مورد تغییر رفتار -که مربوط به این ناهماهنگی ورژن‌ها در محیطی که نرم‌افزار به درستی کار میکنه و محیطی که نرم‌افزار در اون به مشکل خورده باشه- رو مرتفع میکنه.حرف زدن از این انطباق بین محیط‌ها، از عمل کردن به اون ساده‌تره. مخصوصا زمانی که از Automation استفاده نشه. در حالت همانندسازی به صورت دستی احتمال پیدایش اختلاف در این محیط‌ها، از راه‌های متفاوتی افزایش پیدا میکنه : آپگرید کردن از محیط Production به دیگر محیط‌ها نشت کنهتیم Operation در پاسخ به یک اکسپلویت Zero-Day، یکی از وابستگی‌های سیستم رو در Production آپگرید میکنند، چند هفته بعد یکی متوجه میشه این به‌روزرسانی در محیط Staging صورت نگرفته و انجامش میده، چند ماه بعدتر هم یکی دیگه یادش میوفته که ورژنِ روی محیط تست رو به‌روزرسانی کنه. اما اون برنامه روی سیستم توسعه‌دهنده داره به درستی کار میکنه و نیازی برای تغییرش ایجاد نمی‌شه و به همون صورت باقی می‌مونه. استفاده از ابزار متفاوت در محیط‌های متفاوتمثلا شما از یک دیتابیس Lightweight در محیط توسعه استفاده می‌کنید، اما دیتابیس مناسب‌تر رو روی محیط‌های دیگه راه می‌اندازید.تغییرات موقتیشما در حال صحنه‌سازی برای تست کردن یک Feature جدید هستید و به این منظور به Redis احتیاج دارید و اون رو روی محیط Test نصب می‌کنید. آخرش تصمیم می‌گیرید این Feature پیاده‌سازی نشه اما یادتون میره Redis رو Uninstall کنید و سال‌ها میگذره و کسی دیگه یادش نمیاد چرا Redis روی محیط تست نصبه.این واگرایی به مروز زمان بیشتر و بیشتر میشه و موجب وحشتناک‌ترین پدیده‌ی نرم‌افزاری میشه، باگی که فقط در Production ایجاد میشه! این باگ در اثر تعامل نرم‌افزار با محیطی که توش اجرا میشه و فقط در Production به وجود میاد و انجام هزاران هزار تست در محیط‌های دیگه کاملا بی‌فایده‌ست.فرهنگ Legacyبیشتر تیم‌هایی که اغلب زمان‌شون رو صرف نگهداری از پروژه‌ی Legacy میکنن، معمولا ویژگی‌های مشترکی در رابطه با روش توسعه‌ی محصول و ارتباطاتِ بینِ خودشون دارند.ترس از تغییرکسانی که پروژه‌های Legacy رو Maintain می‌کنند، به دلیل پیچیدگی پروژه و نداشتن مستندِ قوی، نمیتونن همه‌چیز رو راجع به اون بدونند. مثلا اینکه از کدوم Feature دیگه استفاده نمیشه و حذف کردنش مشکلی ایجاد نمیکنه، یا کدوم باگ رو اگه Fix کنیم به مشکل برنمی‌خوریم (مورد بوده که بعضی کاربرها با یک باگ انقدر خو گرفتن که فکر می‌کنند اون Feature کارکردش همین‌طوریه و برطرف کردنش کاربر رو دچار مشکل می‌کنه)، یا با کدوم کاربرها باید قبل از ایجاد تغییر در رفتار برنامه مشورت کرد.به دلیل فقدان این اطلاعات، بسیاری از تیم‌ها سعی میکنن این امن‌ترین وضعیت رو همینطوری نگه‌دارند و از ایجاد هرگونه تغییرات غیرضروری ترس داشته باشند. هر تغییری یه خطر محسوب میشه و عطای مزایای احتمالی اون تغییر رو به لقاش میبخشن و پروژه وارد یک فاز سکون میشه که در اون توسعه‌دهنده‌ها بیشتِر انرژی خودشون رو صرف حفظ وضع موجود می‌کنند.قرار گرفتن در این موقعیت که اجازه نمیده برنامه تکامل‌ پیدا کنه،سازمان رو با خطر بزرگتری روبه‌رو میکنه و اون اینه که توسط رقیبان‌شون پشت‌سر گذاشته میشن. بحث سر زمانه. اگر رقیب بتونه زودتر از ما یک Feature رو به برنامه اضافه کنه، که کاملا هم در این حالت سکون محتمله، باید اونجوری که شایسته‌ست با مشتری‌هامون وداع کنیم و جمع کنیم بریم.میتونه اینطوری هم پیش نره، اگر که تیم یک چشم‌انداز داشته باشه و وزن مزایای یک تغییر رو در مقابل ریسک‌هایی که داره بسنجه و فعالانه به دنبال اطلاعات گمشده‌ای که برای چنین تصمیماتی بهش کمک میکنه بگرده، نرم‌افزار میتونه تکامل و با تغییرات سازگاری پیدا کنه.انبارهای دانشمعمولا بزرگترین مشکلی که توسعه‌دهنده‌ها هنگام توسعه و نگهداری از نرم‌افزار باهاش مواجه میشن، فقدان دانشه و ممکنه شامل «کمبود اطلاعات Domain در مورد نیاز‎های کاربران و مشخصات کاربردی نرم‌افزار»، «کمبود اطلاعات فنیِ خاصِ پروژه در مورد طراحی نرم‌افزار و معماری» و یا «کمبود دانش فنی عمومی مانند الگوریتم‌های بهینه، ویژگی‌های زبانیِ پیشرفته، ترفند‌های کدنویسیِ سودمند و Libraryهای مفید» باشه.یک مزیت کار کردن در قالب تیم اینه که اگه شما چیزی را بلد نباشید، ممکنه یک عضو دیگه‌ی تیم بتونه اون رو ارائه بده. برای اینکه این اتفاق بیوفته، یا باید ازشون بخواهید و یا بهتر از اون، اونها به خواست و رغبت خودشون با شما دانش رو به اشتراک بذارن.این موضوع خیلی بدیهیه، اما تو خیلی از تیم ها این مبادله‌ی اطلاعات صورت نمی‌گیره. هر توسعه‌دهنده‌ای به اصطلاح تبدیل به یک انبارِ دانش میشه که همه‌ی دانشِ باارزشش به جای اینکه در جهت منافع کل تیم به اشتراک گذاشته بشه پیش خودش می‌مونه، مگر اینه تلاش زیادی صورت بگیره تا یک محیط ارتباطی و به‌ اشتراک‌گذاری اطلاعات پرورش داده بشه. عوامل موثر در کمبود ارتباطات درون یک تیم میتونه شامل موارد زیر باشه: ◦ نداشتن ارتباط رو در رو --توسعه‌دهنده‌ها بغل‌دست هم نشستن اما به جای گفتگو با هم چت میکنن. ◦ Ego کد --«اگه بذارم کسی کد منو ببینه، ممکنه بهش انتقاد کنه» ◦ استایل سرشلوغی گرفتن --یک روش دفاعی متداول برای توسعه‌دهنده‌ها، برای قرار نگرفتن در معرضِ انجامِ کارِ ناخواسته‌ست. (بزرگوار اشاره میکنن به داستان هندزفری و اخم و اینها D: ) این‌ کار همچنین باعث میشه این افراد کمتر برای توسعه‌دهنده‌های دیگه که میخوان ازشون سوال بپرسن در دسترس باشند.و در انتها از کارهایی مثل Code Review ، Pair Programming یا برگزاری Hackathonها میگه که می‌تونه به بالابردن ارتباط درون یک تیم کمک کنه که در فصل‌های بعدی راجع به این‌ها بیشتر صحبت شده.| پایان فصل اول |نازنین صیادینازنین صیادیFri, 17 Apr 2020 23:47:43 +0430https://virgool.ir/@nazanin.sayadi/در-باب-خصوصیات-پروژهای-که-آن-را-legacy-مینامیم-قسمت-اول-hq9neo7beqr9قسمت قبل | قسمت پیش از اول قسمت بعد | در باب خصوصیات پروژه‌ای که آن را Legacy می‌نامیم | قسمت دوم | نویسنده، پروژه‌ی Legacy رو پروژه‌‌ی موجودی که توسعه و نگهداری از اون سخت باشه تعریف میکنه. صحبت از Codebase به تنهایی نیست و جنبه‌های مختلفی- از جمله اسکریپت‌ها و ابزارهای build پروژه ، وابستگی بین سیستم‌ها، زیرساختی که نرم‌افزار روی اون اجرا میشه، مستندات پروژه و روش‌های ارتباطی بین توسعه‌دهنده‌ها یا بین توسعه‌دهنده‌ها و Stakeholderها - رو در برمیگیره و همه‌ی این فاکتورها با هم در کیفیت و Maintainability یک پروژه نقش دارند.ویژگی‌های مشترک پروژه‌هایی که Legacy محسوب میشن:قدمتمعمولا هر پروژه‌ای به زمان نیاز داره تا به جایی برسه که نگهداری از اون دیگه واقعا سخت بشه. تا اون زمان هم توسعه‌دهنده‌های زیادی برای نگهداری از پروژه میان و میرن و در خلال این جابجایی‌ها دانش طراحی اولیه‌ی سیستم و اهدافی که توسعه‌دهنده‌ی قبلی برای نگهداری داشته هم از بین میره.وسعتناگفته پیداست که هر چقدر ابعاد پروژه بزرگ‌تر باشه، نگهداری از اون سخت‌تره.◦◦ وجود کد بیشتر برای درک کردن | باگ بیشتر برای برطرف کردن | احتمال بالاتر رخ دادن Regression ◦◦همچنین سایز پروژه روی تصمیمات مرتبط با نگهداری هم تاثیر میذاره، هرچی پروژه‌ بزرگ‌تر باشه، جایگزینی اون سخت‌تر و پرریسک‌تره و پتانسیل بیشتری برای Legacy شدن داره.از دیگری به ارث رسیدنهمینطوری که از معنی عمومی کلمه‌ی Legacy برمیاد، چنین پروژ‌هایی معمولا از تیم یا توسعه‌دهنده‌های قبلی به ارث رسیدن. به عبارت دیگه، آدم‌هایی که کد اورجینال رو نوشتن با آدمهایی که از اون کد نگهداری میکنن یکی نیستن. چه بسا بین این دو، توسعه‌دهنده‌های مختلفی هم اومده و رفته باشن.معنی‌ش این میشه که هیچ راهی وجود نداره که آدم‌های فعلی بفهمن این کد چرا اینطوری کار میکنه و غالباً مجبورن اهداف و مفروضات ضمن طراحیِ آدم‌هایی که این کد رو نوشتن رو حدس بزنن.مستندات ضعیفبه دلیل اینکه پروژه نسل‌های متعددی از توسعه‌دهنده‌ها رو به خودش دیده، وجود مستندات دقیق و کامل به بقای طولانی‌مدت پروژه کمک زیادی میکنه. و متاسفانه تنها چیزی که ما توسعه‌دهنده‌ها بیشتر از داکیومنت نوشتن ازش بدمون میاد، آپدیت نگه‌داشتن اونه.و میگه از اینکه اگر یه پروژه‌ای مشمول این ویژگی‌ها باشه،لزوما Legacy نیست و مثال این مورد پروژه‌ی Kernel لینوکسه. از سال 1991 در حال توسعه‌ست، و سایز پروژه بزرگه اما به این وجود از کیفیت بسیار بالایی برخورداره و نویسنده یکی از دلایل این حجم از کیفیت رو فرهنگ ارتباط باز و بی‌پرده اونها میدونه که در این فرهنگ هر تفییری در کد، Review و با این کار موجب به اشتراک‌گذاری اطلاعات بین توسعه‌دهنده‌ها میشه.حالا از کدِ Legacy میگیم و از فاکتورهایی که یک کد رو Legacy میکنه:کد تست نشده و غیرقابل تست (صدای گریه‌ی حضار)همه‌مون میدونیم که مستندات فنی برای پروژه‌ها یا معمولا وجود ندارن، یا اگه وجود دارن قابل اعتماد نیستن.در این شرایط تست‌ها بهترین مکان برای پیدا کردن سرنخ‌ها در مورد رفتار سیستم و مفروضات طراحیه. تست خوب، چون با رفتار فعلی سیستم سینک نگه‌داشته میشه میتونه از مستندات هم بهتر باشه. یک توسعه‌دهنده‌ی مسئولیت‌پذیر حواسش به فیکس کردن تست‌هایی که بر اثر تغییراتش در کد Fail ، Production شده هست! و خبر بد اینکه بسیاری از پروژه‌های Legacy، تست که ندارن هیچ، با ذهنیت تست هم نوشته نشده‌اند و این موضوع اضافه کردن تست به این پروژه‌ها رو سخت‌تر میکنه.کد انعطاف‌ناپذیریکی از مشکلات رایج یک کد Legacy اینه که پیاده‌سازی فیچر‌ جدید، یا تغییر دادن رفتار فعلی توش سخته. یک تغییر کوچیک باعث ویرایش کردن کد در خیلی جاهای دیگه میشه و هر کدی که ادیت بشه هم باید دوباره (بله! غالباً به صورت دستی) تست بشه.کدی که بخاطر بدهی فنی دست‌وپا‌گیر شدههر توسعه‌دهنده‌ای بخاطر نوشتن کدی که خودش هم میدونه Perfect نیست، اما برای حالا خوبه فعلا مقصره. که البته معمولا رویکرد درستیه. داشتن کدی که کار میکنه بهتر از هیچیه.اما هر باری که یک کد برای حالا خوبه فعلا رو به پروژه اضافه می‌کنید، باید برنامه‌ای بچینید تا یه زمانی که فرصت بیشتری داشتید دستی به سر روش بکشید. هر راه حل موقتی‌ای، کیفیت Overallی پروژه رو کاهش میده و کار آینده رو سخت‌تر میکنه. میگه به بدهی فنی مثل یه وام نگاه کنید که بازپرداخت اون Refactoringه. و با یک مثال از سرنوشت شرکتی میگه که توسعه‌دهنده‌هاش در ابتدای پروژه ذهنیت مقیاس‌پذیری رو هنگام انتخاب دیتابیس نداشتند و وقتی که اقبال بهشون رو کرد و کاربرانشون از مقیاس هزار به میلیون رسید، با چاره‌اندیشی‌های موقتی سعی کردند پرفورمنس رو بالا نگه‌ دارن و فیچر جدید توسعه بدن و در نهایت پس شد آنچه شد :))در قسمت بعدی، به جنبه‌های دیگه‌ای که روی Legacy شدن پروژه موثر هستن می‌پردازیم و فصل مقدماتی رو تموم میکنیم.نازنین صیادینازنین صیادیThu, 09 Apr 2020 18:04:07 +0430https://virgool.ir/@nazanin.sayadi/re-engineering-legacy-software-book-zmdxzoiesc9oفصل اول کتاب با یه مقدمه‌ی آشنا شروع میشه:میگه تصور کنید یه روز صبح میرید سرکار، قهوه‌تون رو میریزید، و سری به بلاگ‌های تکنولوژی میزنین و شروع به خوندن یه مقاله از فلان شرکت میکنید که اونها چطوری زبان برنامه‌نویسی X رو با پایگاه داده‌ی Y و ابزار داده‌ی Z ترکیب کردن تا دنیا رو زیر و رو کنند و وقتی میفهمین که شما حتی «زمان» برای امتحان کردن هیچ یک از این تکنولوژیها توی پروژه خودتون رو ندارید، چه برسه به اینکه از اونها برای بهبود محصول‌تون استفاده کنید قلبتون هزار تیکه میشه. چرا؟ چون که وظیفه‌ی ناجذابِ نگهداری از بی‌نهایت خط کدِ بدون تستِ داکیومنت نشده‌ی غیر قابل درکِ Legacy به شما سپرده شده. این کد قبل از اینکه شما اولین خطِ کدِ !Hello World خودتون رو بنویسید تو Production بوده و ده‌ها توسعه‌دهنده اومدن و رفتن. نصف روز کاری رو صرف Review کردن Commitها میکنید تا یک وقت منجر به پسرفت و شکست نشه و نصف دیگه به برطرف کردن Bug میگذره و دردناک‌ترین قسمت ماجرا اینجاست که هر چی زمان میگذره و کد بیشتری به این Codebase شکننده اضافه میشه، اوضاع بد و بدتر میشه.در ادامه میفرمایند که ناامید نشین! اول از همه یادتون باشه که تنها نیستین. نصف توسعه‌دهنده‌ها بیشتر زمان‌شون رو صرف دست و پنجه نرم کردن با کد موجود میکنن تا نوشتن کد جدید ، و اکثریت قریب به اتفاق توسعه‌دهنده‌ها هم مجبورن به نحوی با نوعی از کد Legacy سر و کله بزنن. دوم اینکه، صرف نظر از اینکه چقدر در نظر اول بعید به نظر بیاد، اما همیشه امیدی برای احیا کردن یک پروژه‌ی Legacy هست. و این کتاب - Re-Engineering Legacy Software نوشته‌ی Chris Birchall - دقیقا با همین هدف نوشته شده.در فصل اول و مقدماتی، به بیان نمونه مشکلاتی که سعی در حل کردن اونها داره می‌پردازه و طرحی برای دمیدن روح تازه‎ای در کالبد بی‌جان پروژه‌ی Legacy میریزه و از این میگه که کلا Legacy چیه و در چه سطوحی دیده میشه و مظاهر و مصادیق اون چیه.و در آخر، من تصمیم گرفتم گزیده‌ای از این کتابِ جذاب رو با شما به اشتراک بذارم.قسمت بعد | در باب خصوصیات پروژه‌ای که آن را Legacy می‌نامیم | قسمت اول |نازنین صیادینازنین صیادیWed, 08 Apr 2020 00:19:10 +0430