0101
3 subscribers
53 photos
4 videos
4 files
29 links
Download Telegram
توی مهندسی نرم افزار و کلا ساخت نرم افزار باید مکانیزمی رو داشته باشید که شکست ها تاوان سختی نداشته باشن

اصل کلی:
Fail fast, fail safe, fail cheap.

قسمت اول یعنی شکست زود اتفاق بیفته، نه آخر پروژه.
قسمت دوم یعنی شکست باعث خرابی کل سیستم نشه.
قسمت سوم یعنی هزینه‌ی زمانی، مالی یا ذهنی کمی داشته باشه


🦓
به اون کاری که امروز کردی نگو "ریفکتور" (Refactor). اگه تست نداره، اون فقط یه "گندکاریِ تمیزه".
این فقط یه جمله‌ی قشنگ نیست؛ این یه زخمه که من هنوز یادمه.
اوایل کارم، میخواستم قهرمان باشم. ‍️ تو یه پروژه‌ی لگسی، یه "God Function" هزار خطی پیدا کردم و گفتم: "من اینو تمیز میکنم!"
نشستم و تیکه‌تیکه‌اش کردم. ۵۰ تا تابع کوچولوی تر و تمیز. اصل DRY رو پیاده کردم. ظاهر کد عالی شد. "تمیز" و "حرفه‌ای". احساس غرور میکردم.
مشکل چی بود؟ اون کد اصلی لعنتی، یه دونه هم تست خودکار نداشت.
اونجا بود که فاجعه اتفاق افتاد. کاری که من انجام دادم، "ریفکتور" نبود؛ "تغییر دادنِ کورکورانه" بود.
اون کد "تمیز" من، چند تا باگ جدید و پنهان داشت. چرا؟ چون اون "کد اسپاگتی" زشت، پر از منطق‌های تجاری پنهان و وابستگی‌های زمانی بود که فقط تو همون حالت کار میکرد.
من "بدهی فنی" رو پرداخت نکردم؛ من یه بدهی کم‌بهره (مثل تکرار کد که فهمیدنش ساده بود) رو برداشتم و با یه بدهی پربهره (مثل یه "انتزاع اشتباه" که حالا دیباگ کردنش غیرممکنه) عوض کردم.
این "تله‌ی کد تمیز"ئه. مهم‌ترین تعریفی که تو این صنعت باید بلد باشیم مال مایکل فدرز (Michael Feathers) ئه: "کد لگسی، کدیه که تست نداره." همین.
تو یه سیستم لگسی، قانون اول "تمیز کن" نیست. قانون اول اینه: "اول امنش کن." برو "تست‌های مشخصه‌یابی" (Characterization Tests) بنویس تا رفتار فعلیِ سیستم (با همه‌ی باگ‌هاش) رو قفل کنی. وقتی اون تور ایمنی رو ساختی، اونوقت حق داری که شروع به تمیزکاری کنی.

🦓
🌷