دربارهٔ این فصل
یادداشتِ همراه نوارتا حالا به این فکر کرده‌اید که چرا نوشتن چند خط کد ساده با ساختن یک نرم‌افزار بزرگ که سال‌ها کار می‌کند، تفاوت زمین تا آسمان دارد؟ آیا تا به حال از خودتان پرسیده‌اید که چرا در مهندسی‌های دیگر مثل هوافضا خطای کوچک فاجعه می‌سازد، اما در دنیای نرم‌افزار معمولاً این‌طور نیست و چرا این وضعیت باید تغییر کند؟
این مبحث از کتاب «مهندسی نرم‌افزار در گوگل» نوشتهٔ تیتوس وینترز، تام مانشریک و هایروم رایت به ما نشان می‌دهد که چگونه رویکرد شرکتی با مقیاس گوگل به تعریف دوبارهٔ این مرزها کمک می‌کند. برنامه‌نویسی معمولاً به معنی نوشتن کد برای حل یک مسئله در لحظه است، در حالی که مهندسی نرم‌افزار (software engineering) کل ابزارها و فرآیندهایی را شامل می‌شود که یک سازمان برای ساخت و نگهداری آن کد در طول زمان استفاده می‌کند. تفاوت اصلی در این است که مهندسی نرم‌افزار در واقع برنامه‌نویسیِ یکپارچه‌شده با زمان است.
مسئلهٔ نخست این است که نرم‌افزار ثابت نمی‌ماند و در طول عمر خود باید با تغییرات محیطی و نیازمندی‌ها سازگار شود. گزینه‌های پیش روی تیم‌ها این است که یا کد را به حال خود رها کنند تا به مرور زمان غیرقابل‌نگهداری شود، یا اصول پایداری را به کار بگیرند. مبادله trade-off در اینجا هزینهٔ اولیهٔ بالاتر برای نوشتن کدهای ساختاریافته در برابر هزینه‌های سرسام‌آور رفع اشکال در آینده است. برای مثال، کدی که بدون در نظر گرفتن چرخهٔ حیات از ایده تا منسوخ‌سازی نوشته شود، با کوچک‌ترین تغییر در کتابخانه‌های وابسته از کار می‌افتد.
مسئلهٔ دوم مقیاس‌پذیری (scalability) سازمان و ابزارها هم‌زمان با رشد و تکامل است. وقتی تعداد مهندسان یک شرکت چند برابر می‌شود، روش‌های سنتی مدیریت تیم دیگر پاسخگو نیستند. انتخاب‌ها شامل حفظ روش‌های سنتی جزیره‌ای یا سرمایه‌گذاری روی فرهنگ، فرآیندها و ابزارهای مشترک است. مبادله شامل صرف زمان برای ایجاد زیرساخت مشترک در برابر هلافزایی و سرعت اولیهٔ تیم‌های منفرد است. برای نمونه، گوگل تجربه‌های خود را روی سه محور فرهنگ، فرآیندها و ابزارها بنا کرده تا به سازمان اجازه دهد بدون افت کیفیت رشد کند.
مسئلهٔ سوم مواجهه با هزینه‌ها و تصمیم‌گیری‌های ساختاری بر اساس زمان، تغییر، مقیاس و رشد است. سازمان‌ها باید یاد بگیرند که چگونه تصمیم‌های معماری خود را بر اساس درس‌های گذشته توجیه کنند. گزینهٔ موجود، اتخاذ تصمیمات سلیقه‌ای یا پیروی از چارچوب‌های مبتنی بر تجربه و داده است. مبادله این است که چارچوب‌های دقیق شاید در کوتاه‌مدت دست‌وپاگیر به نظر برسند، اما در بلندمدت از بروز بحران‌های بزرگ جلوگیری می‌کنند. برای مثال، ساختار بازبینی‌های کد و استانداردهای سخت‌گیرانه در گوگل برای همین هدف طراحی شده‌اند.
مسئلهٔ چهارم تمرکز کتاب روی مهندسی به جای مباحث تئوریک طراحی زبان یا مدیریت پروژه است. نویسندگان آگاهانه از موضوعاتی مانند طراحی رابط کاربری یا امنیت تخصصی عبور کرده‌اند تا روی چرخهٔ مهندسی تمرکز کنند. گزینه‌ها شامل پرداختن سطحی به همه‌چیز یا تمرکز عمیق روی اصول مهندسی‌پذیر است. مبادله این است که کتاب از پرداختن به جزئیات خاص زبان‌ها صرف‌نظر می‌کند تا اصول عمومی‌تری ارائه دهد که در هر زبانی قابل استفاده باشند. این رویکرد به تیم‌ها اجازه می‌دهد اصول بنیادی را به حوزهٔ تخصصی خود منتقل کنند.
پیشنهاد من این است که در پروژه‌های شخصی و تیمی خود، به جای تمرکز صرف روی تحویل سریع کد، زمان مشخصی را برای بهبود ابزارها، تست‌ها و مستندسازی اختصاص دهید تا کد شما در برابر تغییرات زمان مقاوم بماند.
امیدوارم این نگاه به فرآیند ساخت نرم‌افزار، الهام‌بخش کارهای بعدی شما باشد. تا اپیزود بعدی، پیروز و پایدار باشید.