نرمافزار کمتر¶
کدتان را تا جای ممکن ساده نگه دارید¶
شاید فکر کنید دو برابر کد، نرمافزار شما را فقط دو برابر پیچیدهتر میکند. اما در واقع، هر بار مقدار کد را زیاد میکنید، نرمافزارتان بهصورت نمایی پیچیدهتر میشود. هر اضافه کوچک، هر تغییر، هر وابستگی متقابل و هر preference اثر آبشاری دارد. اگر بیمحابا کد اضافه کنید، تا به خودتان بیایید آن Big Ball of Mud ترسناک را ساختهاید.
راه جنگیدن با این پیچیدگی، نرمافزار کمتر است. نرمافزار کمتر یعنی قابلیت کمتر، کد کمتر، اتلاف کمتر.
کلید کار این است که هر مسئله سختی را که نرمافزار زیادی میخواهد، دوباره به مسئلهای ساده تبدیل کنید که نرمافزار خیلی کمتری میخواهد. شاید دقیقاً همان مسئله را حل نکنید، اما اشکالی ندارد. حل ۸۰٪ مسئله اصلی با ۲۰٪ تلاش، برد بزرگی است. مسئله اصلی تقریباً هیچوقت آنقدر بد نیست که ارزش پنج برابر تلاش را داشته باشد.
نرمافزار کمتر یعنی crystal ball را کنار میگذارید. به جای تلاش برای پیشبینی مسئلههای آینده، فقط با مسئلههای امروز کار میکنید. چرا؟ ترسهایی که درباره فردا دارید اغلب هرگز واقعی نمیشوند. خودتان را با حل این مسئلههای خیالی گرفتار نکنید.
از ابتدا، محصولهایمان را بر پایه مفهوم نرمافزار کمتر طراحی کردهایم. هر وقت ممکن باشد، مسئلههای سخت را به مسئلههای آسان خرد میکنیم. فهمیدهایم راهحل مسئلههای آسان نهتنها پیادهسازی و پشتیبانی آسانتری دارد، بلکه فهم و استفادهاش هم آسانتر است. این بخشی از شیوه تمایز ما از رقباست؛ به جای تلاش برای ساختن محصولهایی که کارهای بیشتری میکنند، محصولهایی میسازیم که کارهای کمتری میکنند.
- نرمافزار کمتر آسانتر مدیریت میشود.
- نرمافزار کمتر codebase شما را کوچک میکند و این یعنی
- کار نگهداری کمتر و کارکنان خوشحالتر.
- نرمافزار کمتر هزینه تغییر را پایین میآورد تا بتوانید سریع سازگار شوید. میتوانید نظرتان را عوض کنید بدون اینکه ناچار شوید قایققایق کد را تغییر دهید.
- نرمافزار کمتر به باگهای کمتر میرسد.
- نرمافزار کمتر یعنی پشتیبانی کمتر.
اینکه کدام قابلیتها را اضافه یا حذف میکنید هم به نرمافزار کمتر ربط زیادی دارد. از نه گفتن به درخواست قابلیتهایی که انجامشان سخت است نترسید. مگر اینکه مطلقاً ضروری باشند، با کنار گذاشتنشان زمان، تلاش و سردرگمی را کم کنید.
کندتر هم بروید. یک هفته روی ایدهای اقدام نکنید و ببینید بعد از خوابیدن هیجان اولیه هنوز عالی به نظر میرسد یا نه. این زمان اضافه برای جا افتادن ایده، اغلب کمک میکند مغزتان راهحل آسانتری پیدا کند.
برنامهنویسها را تشویق کنید counteroffer بدهند.
میخواهید این را بشنوید: «راهی که پیشنهاد کردید ۱۲ ساعت طول میکشد. اما راهی هست که میتوانم در یک ساعت انجامش بدهم. x را انجام نمیدهد، اما y را انجام میدهد.» بگذارید نرمافزار مقاومت کند. به برنامهنویسها بگویید برای چیزی که فکر میکنند بهترین راه است بجنگند.
همچنین دنبال مسیرهای انحرافی برای ننوشتن نرمافزار بیشتر بگردید. آیا میتوانید copy روی صفحه را طوری عوض کنید که مسیر جایگزینی به مشتری پیشنهاد دهد، بدون اینکه مدل نرمافزار تغییر کند؟ مثلاً میتوانید به آدمها پیشنهاد کنید تصویرهایی با اندازه مشخص upload کنند، به جای اینکه دستکاری تصویر را سمت سرور انجام دهید؟
برای هر قابلیتی که وارد اپ میشود، از خودتان بپرسید: آیا راهی هست این را طوری اضافه کنیم که نرمافزار کمتری بخواهد؟ فقط کدی را بنویسید که لازم دارید و نه بیشتر. نتیجهاش اپی لاغرتر و سالمتر خواهد بود.
هیچ کدی منعطفتر از بیکدی نیست¶
«راز» طراحی نرمافزار خوب در دانستن اینکه چه چیزی را داخل کد بگذاریم نبود؛ در دانستن این بود که چه چیزی را بیرون بگذاریم. در تشخیص نقطههای سخت و نرم، و دانستن اینکه کجا باید فضا باقی گذاشت، به جای تلاش برای چپاندن طراحی بیشتر.
—Brad Appleton، مهندس نرمافزار (از There is No CODE that is more flexible than NO Code!)
پیچیدگی با اندازه به شکل خطی رشد نمیکند¶
مهمترین قاعده مهندسی نرمافزار، در عین حال کمشناختهترین آن است: پیچیدگی با اندازه به شکل خطی رشد نمیکند... یک برنامه ۲۰۰۰ خطی بیش از دو برابر برنامهای نصف آن اندازه، زمان توسعه میخواهد.
—The Ganssle Group (از Keep It Small)
منبع اصلی: Less Software