کتاب‌های تیتوس وینترز، تام مانشریک و هایروم رایت

تا حالا به این فکر کرده‌اید که ابزارها و برنامه‌هایی که هر روز استفاده می‌کنیم، چطور ناخواسته گروه بزرگی از انسان‌ها را نادیده می‌گیرند یا حتی به آن‌ها آسیب می‌زنند؟ وقتی نرم‌افزاری برای میلیون‌ها نفر ساخته می‌شود، کوچک‌ترین بی‌توجهی به تفاوت‌های انسانی می‌تواند پیامدهای جبران‌ناپذیری به همراه داشته باشد. در این اپیزود می‌خواهیم ببینیم چطور می‌توانیم نرم‌افزارهایی بسازیم که واقعاً برای همه انسان‌ها کار کنند و کسی را در حاشیه نگه ندارند.

در کتاب «مهندسی نرم‌افزار در گوگل» نوشته تیتوس وینترز، تام مانشریک و هایروم رایت، فصل چهارم با عنوان مهندسی برای برابری به همین موضوع حیاتی می‌پردازد و به ما یادآوری می‌کند که ساختن نرم‌افزار برای جامعه جهانی نیازمند مسئولیت‌پذیری فراتر از کدهای معمولی است.

نخستین چالش این است که تعصب ناخودآگاه (unconscious bias) تأثیر مخربی بر طراحی محصولات می‌گذارد، زیرا افراد بدون اینکه قصد بدی داشته باشند، کلیشه‌ها و نگرش‌های ذهنی خود را در کار دخالت می‌دهند. وقتی مهندسان بدون تمرکز روی کاربران گوناگون کار می‌کنند، ناخواسته در ارائه محصولات شکست می‌خورند. انتخاب دشوار در اینجا این است که تمرکز صرف بر سرعت توسعه و سودآوری، ما را از بررسی دقیق داده‌های ورودی غافل می‌کند. به عنوان نمونه، الگوریتم‌های تشخیص تصویر گوگل در سال‌های گذشته افراد رنگین‌پوست را به شکل نادرستی دسته‌بندی کردند؛ زیرا داده‌های آموزشیِ ورودی نمایانگر کل جامعه نبودند.

مشکل دوم این است که مهندسان نرم‌افزار با تحصیلات دانشگاهی رایج، لزوماً آموزش لازم برای درک مسائل اجتماعی و فرهنگی کاربران گوناگون را ندیده‌اند. تکیه صرف بر مدرک علوم کامپیوتر برای ساخت محصولات فراگیر کافی نیست و سازمان‌ها باید تنوع دیدگاه‌ها را بپذیرند. بهای این انتخاب در این است که سرمایه‌گذاری روی یادگیری مداوم و توسعه ظرفیت چندفرهنگی زمان‌بر است، اما از بروز خطاهای فاجعه‌بار جلوگیری می‌کند. به عنوان مثال، اگر سیستم‌های داخلی شرکت‌ها فقط بر اساس معیارهای یک گروه خاص طراحی شوند، مسیر ارتقای شغلی برای گروه‌های کمتر دیده‌شده ناهموار باقی می‌ماند.

چالش سوم تکیه بر رویکردهای تک‌بعدی برای حل مشکلات سیستمیک است. بسیاری از سازمان‌ها تصور می‌کنند با اصلاح صرفِ ورودیِ فرآیند استخدام می‌توانند تمام نابرابری‌ها را حل کنند، در حالی که خروج نیروهای باارزش به دلیل محیط‌های کاری نامناسب، پیشرفت را متوقف می‌کند. انتخاب سازمان‌ها این است که یا به اصلاحات سطحی اکتفا کنند یا در کل اکوسیستم حفظ و نگهداری نیروها بازنگری کنند. پذیرش این پیچیدگی یعنی به جای نگاه‌های ساده‌اندرکارانه، روی مواردی مانند امنیت روانی (psychological safety) که به معنی فضایی است که افراد می‌توانند بدون ترس از تحقیر، اشتباه یا سؤال را مطرح کنند، سرمایه‌گذاری کنیم تا افراد بدون ترس نظرات و دغدغه‌های خود را مطرح کنند.

چهارمین مسئله این است که مهندسان معمولاً تمایل دارند سیستم‌ها را برای حالت‌های رایج و اکثریت طراحی کنند و حالت‌های خاص را به آینده موکول کنند. مشکل این رویکرد آن است که کاربران دارای نیازهای خاص یا جوامع در حاشیه را کاملاً نادیده می‌گیرد و به جای طراحی فراگیر، بار مشکلات را به دوش کاربر می‌اندازد. انتخاب جایگزین این است که طراحی برای سخت‌ترین و دورافتاده‌ترین موارد استفاده، انرژی بیشتری می‌طلبد اما در نهایت محصولی به مراتب باکیفیت‌تر برای همه کاربران تولید می‌کند. برای نمونه، طراحی نرم‌افزار به گونه‌ای که برای افراد با توانایی‌های گوناگون یا مسلط به زبان‌های مختلف قابل دسترس باشد، تجربه کاربری کل جامعه را بهبود می‌بخشد.

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

ساختن ابزارهایی که جهان را به جای بهتری تبدیل کنند، نیازمند فروتنی، پذیرش اشتباهات گذشته و تلاش مستمر برای یادگیری است. بیایید در مسیر مهندسی خود به گونه‌ای عمل کنیم که هیچ‌کس از قطار پیشرفت فناوری جا نماند.

تا حالا به این فکر کرده‌اید که وقتی یک متخصص باارزش از سازمان شما می‌رود، چه حجم از دانش فنی او از دست می‌رود و چطور می‌توان جلوی فراموش شدن این تجربه‌ها را گرفت؟ چطور می‌توان مطمئن شد که دانش فنی در تمام بخش‌های یک شرکت بزرگ رسوب می‌کند و قفل نمی‌ماند؟

این موضوع در فصل سوم کتاب «مهندسی نرم‌افزار در گوگل» نوشته‌ی تیتوس وینترز، تام مانشریک و هایروم رایت بررسی شده است که به ما نشان می‌دهد سازمان‌ها چطور باید به اشتراک‌گذاری دانش به عنوان یک سرمایه حیاتی نگاه کنند.

اولین چالش جدی در سازمان‌های بزرگ، کمبود امنیت روانی است؛ یعنی فضایی که در آن افراد از ابراز بی‌اطلاعی یا اشتباه کردن ترس داشته باشند. راه‌حل گوگل برای این مسئله، تعیین یک مربی رسمی خارج از تیم برای نیروهای تازه‌وارد است تا آن‌ها بدون نگرانی از گرفتن وقت همکاران، راهنمایی دریافت کنند. این رویکرد به تازه‌کارها اجازه می‌دهد بدون دغدغه سؤال بپرسند و راحت‌تر با محیط سازگار شوند.

چالش دوم، شکل‌گیری جزیره‌های اطلاعاتی در بخش‌های مختلف سازمان است که با یکدیگر ارتباطی ندارند و راهکارهای متفاوتی برای مسائل مشابه می‌سازند. برای حل این مشکل، گوگل به جای تکیه صرف بر گفتگوهای دونفره، از ابزارهای مقیاس‌پذیر مانند فهرست‌های پستی و سامانه‌های پرسش و پاسخ داخلی استفاده می‌کند تا پاسخ‌ها ثبت شده و برای دیگران هم قابل جستجو باشند.

بسیاری از مهندسان وقتی با کدهای قدیمی روبه‌رو می‌شوند، وسوسه می‌شوند که همه چیز را کاملاً بازنویسی کنند زیرا منطق آن را درک نمی‌کنند. نویسندگان کتاب تأکید می‌کنند که پیش از دستکاری یا حذف هر بخش از کد، باید زمینه و دلیل شکل‌گیری آن را درک کرد تا از خطاهای پنهان و دوباره‌کاری‌های بی‌جا جلوگیری شود.

برای مقیاس‌پذیر کردن انتقال دانش در سطح شرکت، استفاده از ابزارهای خودکار نقش مهمی دارد. تحلیل ایستا (static analysis) به بررسی خودکار کدها بدون اجرای آن‌ها می‌پردازد و قواعد بهینه را گوشزد می‌کند تا مهندسان زمان بیشتری برای یادگیری مفاهیم پیچیده‌تر داشته باشند. علاوه بر این، فرآیند خوانایی (readability) به عنوان یک ساختار رسمی در بازبینی کد عمل می‌کند تا مطمئن شود همه توسعه‌دهندگان از الگوهای استاندارد و یکسانی پیروی می‌کنند.

پیشنهاد من به شما این است که در تیم خودتان فرهنگ پرسیدن را ترویج کنید و هر زمان که نکته تازه‌ای یاد گرفتید، آن را مکتوب کنید تا دیگران مجبور نباشند مسیر پرخطای شما را دوباره طی کنند. یادگیری جمعی، موتور محرک رشد هر سازمان نرم‌افزاری پایدار است.

امیدوارم از شنیدن این قسمت لذت برده باشید و نظرات خود را با ما در میان بگذارید.

تا حالا شده ساعت‌ها روی نوشتن یک تکه کد وقت بگذارید و بعد از اینکه بالاخره کامل شد، از این بترسید که دیگران آن را ببینند و قضاوتتان کنند؟ چرا خیلی از برنامه‌نویسان ترجیح می‌دهند در تنهایی کار کنند و کارهایشان را از چشم همکارانشان پنهان نگه دارند؟

فصل دوم از کتاب «مهندسی نرم‌افزار در گوگل» به کوشش تیتوس وینترز، تام مانشریک و هایروم رایت و نوشتهٔ برایان فیتزپاتریک، به همین چالش‌های فرهنگی و اجتماعی می‌پردازد و نشان می‌دهد که چطور رفتار فردی ما بر کل تیم تأثیر می‌گذارد.

نخستین مسئله، خطای شناختی بزرگی است که نویسندگان آن را اسطورهٔ نابغه می‌نامند. بسیاری از ما فکر می‌کنیم نرم‌افزارهای بزرگ دنیا، مثل لینوکس، حاصل کار یک نفر در تنهایی بوده‌اند؛ در حالی که لینوکس با کار گروهی هزاران نفر شکل گرفته است. گزینه‌های پیش روی برنامه‌نویسان این است که کدهای خود را پنهان کنند تا کسی خطاهایشان را نبیند یا اینکه کارشان را زود به اشتراک بگذارند. معاملهٔ این روش این است که کار در تنهایی، سرعت پیشرفت را کم می‌کند و خطر اتلاف وقت روی مسیر اشتباه را بالا می‌برد. مثلاً تصور کنید ما ماه‌ها روی ساخت یک قطعه‌ی سخت‌افزاری در گاراژ خانه کار کنیم بدون اینکه با کسی مشورت کنیم، در حالی که همسایهٔ ما با کمک دوستانش همان را خیلی زودتر ساخته است.

دومین موضوع مهم، ضریب اتوبوس Bus Factor است؛ یعنی تعداد افرادی که اگر خدای نکرده با اتوبوس تصادف کنند، پروژه کاملاً متوقف می‌شود. مسئله این است که اگر فقط یک نفر همه‌چیز را دربارهٔ کد بداند، امنیت شغلی دارد اما پروژه در خطر جدی قرار می‌گیرد. گزینه‌های ما این است که دانش را انحصاری نگه داریم یا آن را بین اعضای تیم پخش کنیم. معامله این است که اشتراک‌گذاری دانش، احساس امنیت فردی را کم می‌کند اما دوام پروژه را تضمین می‌کند. برای نمونه، اگر مستندسازی و مالکیت مشترک وجود داشته باشد، با رفتن یک نفر پروژه زمین نمی‌خورد.

سومین چالش، اهمیت بازبینی کد (Code Review) به همراه چرخهٔ بازخورد است؛ یعنی بررسی تغییرات کد توسط همکاران پیش از ادغام. مسئله این است که اگر برنامه‌نویس کد خود را تا لحظهٔ نهایی پنهان کند، خطاهای بنیادی دیر کشف می‌شوند. گزینه‌ها این است که منتظر بمانیم کار کاملاً تمام شود یا به صورت تدریجی بازخورد بگیریم. ترفند معامله این است که پذیرش بازخورد اولیه ممکن است به غرور ما لطمه بزند اما هزینه‌های رفع خطا را به شدت کاهش می‌دهد. درست مثل کامپایلر که در کنار برنامه‌نویس است تا خطاهای کوچک را همان لحظه کشف کند، تیم هم به عنوان یک بازخورد زنده عمل می‌کند.

چهارمین مفهوم کلیدی، سه ستارهٔ تعامل اجتماعی یعنی تواضع، احترام و اعتماد است. مسئله این است که انسان‌ها موجوداتی غیرقابل‌پیش‌بینی هستند و بیشتر درگیری‌های کاری ریشه در کمبود همین سه اصل دارد. گزینه‌ها این است که وارد چالش‌های انسانی شویم یا مثل خیلی‌ها گوشه‌گیر شویم و فقط با ماشین کار کنیم. معامله این است که کار کردن روی مهارت‌های اجتماعی زمان‌بر است اما روابط صمیمانه همیشه طولانی‌تر از پروژه‌ها عمر می‌کنند. مثلاً رفتار دوستانه با همکاران باعث می‌شود وقتی کار گره می‌خورد، دیگران با اشتیاق به کمک ما بیایند.

پنجمین نکته، پذیرش شکست و ایجاد یک فرهنگ عاری از سرزنش است. مسئله این است که وقتی اشتباهی رخ می‌دهد، واکنش طبیعی ترس از اخراج یا توبیخ است. گزینه‌ها این است که شکست را پنهان کنیم یا آن را به عنوان فرصتی برای یادگیری مستند کنیم. معامله این است که اعتراف به اشتباه آسیب‌پذیر به نظر می‌رسد اما در نهایت اعتبار و اعتماد تیم را بیشتر می‌کند. برای نمونه، نوشتن تحلیل پس از مرگ Post-mortem به تیم کمک می‌کند ریشهٔ مشکل را پیدا کنند بدون اینکه انگشت اتهام را به سمت فرد خاصی بگیرند.

پیشنهاد من به شما این است که در پروژه‌های روزمره، تمرین کنید کدهایتان را زودتر با همکارانتان به اشتراک بگذارید و به جای دفاع از خطاهای خود، از بازخوردها به عنوان ابزاری برای رشد استفاده کنید.

توسعهٔ نرم‌افزار یک کار گروهی است و موفقیت واقعی زمانی به دست می‌آید که به جای تلاش برای قهرمان تنهای میدان بودن، بخشی از یک تیم همدل باشیم.

تا حالا به این فکر کرده‌اید که چرا کدی که امروز به راحتی اجرا می‌شود، شاید چند سال دیگر به کلی از کار بیفتد؟ در دنیای امروز، ساختن نرم‌افزار فقط نوشتن چند خط کد نیست، بلکه مدیریت فرآیندی پیچیده است که در طول زمان تغییر می‌کند. آیا واقعاً فرقی بین نوشتن یک اسکریپت ساده و نگهداری یک سامانه بزرگ وجود دارد؟

در کتاب «مهندسی نرم‌افزار در گوگل» نوشتهٔ تیتوس وینترز، تام مانشریک و هایروم رایت، این تفاوت‌ها با دقت بررسی شده‌اند و این کتاب به ما نشان می‌دهد که چگونه می‌توان سامانه‌هایی ساخت که برای دهه‌ها دوام بیاورند.

یکی از چالش‌های اصلی در مهندسی نرم‌افزار (Software Engineering)، مسئلهٔ زمان و تغییرات پیاپی است. برنامه‌نویسی معمولاً به تولید کدی گفته می‌شود که عمر کوتاهی دارد، اما مهندسی نرم‌افزار یعنی برنامه‌نویسی به اضافهٔ زمان؛ یعنی کدی که باید سال‌ها زنده بماند و با تغییر سیستم‌عامل‌ها و کتابخانه‌ها سازگار شود. برای نمونه، کدی که برای یک اسکریپت چند دقیقه‌ای نوشته می‌شود نیازی به به‌روزرسانی ندارد، اما یک موتور جستجوی بزرگ نمی‌تواند روی نسخه‌های قدیمی و منسوخ متوقف بماند.

چالش دوم به رفتار پنهان سامانه‌ها مربوط می‌شود که در کتاب از آن به عنوان قانون هایروم (Hyrum's Law) یاد شده است. این قانون بیان می‌کند که وقتی یک رابط برنامه‌نویسی کاربردی به تعداد کافی کاربر داشته باشد، تمام رفتارهای قابل مشاهدهٔ سیستم، حتی آن‌هایی که در قرارداد رسمی ذکر نشده‌اند، مورد اتکای کاربران قرار می‌گیرند. مثلاً اگر ترتیب خروجی دادن یک ساختار داده در برنامه‌ای تغییر کند، تمام برنامه‌هایی که به طور ضمنی به آن ترتیب وابسته بوده‌اند دچار مشکل می‌شوند.

مقیاس‌پذیری (Scalability) سومین چالش بزرگی است که سازمان‌ها با آن دست و پنجه نرم می‌کنند. اگر سیاست‌های یک سازمان با رشد تیم به صورت خطی یا بهتر رشد نکنند، سیستم دچار افت کارایی می‌شود. برای نمونه، اگر سیاست منسوخ‌سازی به گونه‌ای باشد که بار سنگین مهاجرت به نسخهٔ جدید را به دوش مشتریان بگذارد، با بزرگ شدن سازمان، این کار غیرممکن خواهد شد؛ در حالی که سپردن این کار به تخصصِ تیم زیرساخت بسیار مؤثرتر است.

چهارمین موضوع مهم، اهمیت انتخاب‌ها و تحلیل هزینه‌ها بر اساس داده‌ها است. تصمیم‌گیری در این حوزه نباید بر پایهٔ جملاتی مثل چون من می‌گویم باشد، بلکه باید هزینه‌های مختلف مانند زمان مهندسین، مصرف پردازنده و فرصت‌های از دست رفته را بسنجد. به عنوان نمونه، فراهم کردن ماژیک‌های سفیدبرد به صورت آزاد و فراوان در گوگل، شاید هزینه‌ی مالی کوچکی داشته باشد، اما برای بهینه‌سازی جریان تفکر و جلوگیری از وقفه در کار تیمی بسیار ارزشمند است.

پیشنهاد من به شما این است که در پروژه‌های خود، از همین امروز هزینه‌های پنهان وابستگی‌ها را جدی بگیرید و پیش از بروز بحران، ابزارهای خودکار برای یکپارچه‌سازی پیوسته (Continuous Integration) را مستقر کنید تا تغییرات آینده درد کمتری داشته باشد.

امیدواریم از این بررسی کوتاه لذت برده باشید و دیدگاه تازه‌ای نسبت به چالش‌های ساخت نرم‌افزار پیدا کرده باشید.

تا حالا به این فکر کرده‌اید که چرا نوشتن چند خط کد ساده با ساختن یک نرم‌افزار بزرگ که سال‌ها کار می‌کند، تفاوت زمین تا آسمان دارد؟ آیا تا به حال از خودتان پرسیده‌اید که چرا در مهندسی‌های دیگر مثل هوافضا خطای کوچک فاجعه می‌سازد، اما در دنیای نرم‌افزار معمولاً این‌طور نیست و چرا این وضعیت باید تغییر کند؟

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

مسئلهٔ نخست این است که نرم‌افزار ثابت نمی‌ماند و در طول عمر خود باید با تغییرات محیطی و نیازمندی‌ها سازگار شود. گزینه‌های پیش روی تیم‌ها این است که یا کد را به حال خود رها کنند تا به مرور زمان غیرقابل‌نگهداری شود، یا اصول پایداری را به کار بگیرند. مبادله trade-off در اینجا هزینهٔ اولیهٔ بالاتر برای نوشتن کدهای ساختاریافته در برابر هزینه‌های سرسام‌آور رفع اشکال در آینده است. برای مثال، کدی که بدون در نظر گرفتن چرخهٔ حیات از ایده تا منسوخ‌سازی نوشته شود، با کوچک‌ترین تغییر در کتابخانه‌های وابسته از کار می‌افتد.

مسئلهٔ دوم مقیاس‌پذیری (scalability) سازمان و ابزارها هم‌زمان با رشد و تکامل است. وقتی تعداد مهندسان یک شرکت چند برابر می‌شود، روش‌های سنتی مدیریت تیم دیگر پاسخگو نیستند. انتخاب‌ها شامل حفظ روش‌های سنتی جزیره‌ای یا سرمایه‌گذاری روی فرهنگ، فرآیندها و ابزارهای مشترک است. مبادله شامل صرف زمان برای ایجاد زیرساخت مشترک در برابر هلافزایی و سرعت اولیهٔ تیم‌های منفرد است. برای نمونه، گوگل تجربه‌های خود را روی سه محور فرهنگ، فرآیندها و ابزارها بنا کرده تا به سازمان اجازه دهد بدون افت کیفیت رشد کند.

مسئلهٔ سوم مواجهه با هزینه‌ها و تصمیم‌گیری‌های ساختاری بر اساس زمان، تغییر، مقیاس و رشد است. سازمان‌ها باید یاد بگیرند که چگونه تصمیم‌های معماری خود را بر اساس درس‌های گذشته توجیه کنند. گزینهٔ موجود، اتخاذ تصمیمات سلیقه‌ای یا پیروی از چارچوب‌های مبتنی بر تجربه و داده است. مبادله این است که چارچوب‌های دقیق شاید در کوتاه‌مدت دست‌وپاگیر به نظر برسند، اما در بلندمدت از بروز بحران‌های بزرگ جلوگیری می‌کنند. برای مثال، ساختار بازبینی‌های کد و استانداردهای سخت‌گیرانه در گوگل برای همین هدف طراحی شده‌اند.

مسئلهٔ چهارم تمرکز کتاب روی مهندسی به جای مباحث تئوریک طراحی زبان یا مدیریت پروژه است. نویسندگان آگاهانه از موضوعاتی مانند طراحی رابط کاربری یا امنیت تخصصی عبور کرده‌اند تا روی چرخهٔ مهندسی تمرکز کنند. گزینه‌ها شامل پرداختن سطحی به همه‌چیز یا تمرکز عمیق روی اصول مهندسی‌پذیر است. مبادله این است که کتاب از پرداختن به جزئیات خاص زبان‌ها صرف‌نظر می‌کند تا اصول عمومی‌تری ارائه دهد که در هر زبانی قابل استفاده باشند. این رویکرد به تیم‌ها اجازه می‌دهد اصول بنیادی را به حوزهٔ تخصصی خود منتقل کنند.

پیشنهاد من این است که در پروژه‌های شخصی و تیمی خود، به جای تمرکز صرف روی تحویل سریع کد، زمان مشخصی را برای بهبود ابزارها، تست‌ها و مستندسازی اختصاص دهید تا کد شما در برابر تغییرات زمان مقاوم بماند.

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