حالت تاریک
فصل ۹ — تثبیت بازآرایی
بیش از یک سال پیش، دوستی به نام تیم تصمیم گرفت مصرف قند را کاملاً قطع کند تا چند کیلو اضافه را کم کند و انرژی بیشتری بگیرد. هفتهٔ اول سخت بود؛ خستگی و میل شدید به شیرینی، اما پایان هفتهٔ سوم محرومیت قند فروکش کرد و دوباره سرحال شد. بعد مزایای رژیم جدید آمد: هوشیاری بیشتر در روز کاری و چند کیلو کمتر.
بعد از آن، بزرگترین چالش پایبندی به رژیم بود. تیم دوستانی دید که رژیم را شروع کردند و رها کردند، پس انتظارات واقعبینانه گذاشت. برای حذف وسوسه، هر خوراکی شیرین را از آپارتمان بیرون کرد. دفترچهٔ غذا نگه داشت تا مسئول بماند، اما گاهی هنگام دیدار دوستان پاداش کوچک گرفت. دو ماه بعد شریکش هم بدون قند شد و با هم بهتر حمایت کردند. امروز تیم سلامت بهتری دارد و انرژیاش فقط با تولهسگش رقابت میکند.
بازآرایی کمی شبیه رژیم جدید و پایبندی به آن است. شاید بزرگترین چالش به نظر تعیین تغییر و پیادهسازی باشد، اما تلاش بهاندازهٔ همان برای ماندگار کردن تغییر لازم است. در این فصل ابزارها و شیوههایی را میبینیم که بهبودهای بازآرایی در مقیاس بزرگ را تا حد امکان پایدار نگه دارند: تشویق مهندسان سازمان به پذیرش الگوهای بازآرایی، استفاده از continuous integration برای ترویج پذیرش، اهمیت آموزش همتیمیها با roadshow پس از بازآرایی، و ادغام بهبود تدریجی در فرهنگ مهندسی تا شاید بازآراییهای بزرگ کمتری در آیندهٔ نزدیک لازم شود.
ترویج پذیرش
اغلب تعداد زیادی مهندس با بازآرایی شما تعامل خواهند داشت. برای دو دلیل به حمایت آنها و الگوهایی که بازآرایی برقرار کرده نیاز دارید.
اول، ماندگاری بلندمدت تغییرات. بازآراییهای گسترده قطبیکنندهاند؛ در هر شرکت بیش از چند نفر، هم طرفداران طراحی و هم مخالفان هستند. اگر مخالفان طراحی از نوشتن کد جدید طبق الگوهای جدید امتناع کنند، راه دور زدن میجویند و cruft جدید در مرز بین تغییرات شما و کد آنها تولید میکنند. در نهایت تقریباً همهٔ مزایای بازآرایی بیمعنی میشود.
حتی با برنامهریزی و اجرای باکیفیت، همه با چشمانداز شما موافق یا آگاه نیستند. برای تازهواردان تیم مهندسی، مشکلاتی که بازآرایی میخواست حل کند شاید روشن نباشد. بدون زمینهٔ لازم، در حاشیهٔ بازآرایی مشکل دارند: الگوهای جدید را اشتباه پیاده میکنند یا جایی که کد سود میبرد استفاده نمیکنند.
دوم، نفوذ بیشتر الگوهای بازآرایی در کدبیس. نهتنها میخواهید تغییرات بمانند، بلکه تصمیمهای آیندهٔ مهندسان را برای ماهها یا سالها شکل دهند. تشبیه ساده: بازآرایی مثل علفکشی باغچهٔ پر از علف، گردش خاک و کاشت چند پیازچه است. نگهداشتن پیازچه هدف اول؛ تشویق خانواده برای کاشت سبزیجات دیگر در خاک تازه هدف دوم.
مثال: تیمی کتابخانهٔ اصلی logging را در کدبیس گسترده بازآرایی کرد — بعد از چند حادثهٔ نشت اطلاعات شناسایی شخصی (PII) به pipelineهای پردازش داده. interface اصلی بازنویسی شد تا رشتهٔ دلخواه نپذیرد. برای log field یا log type جدید باید در کتابخانه ثبت و مطابق آن استفاده شود. بهجای جایگزینی هر callsite، دامنه را محدود کردند و منطق کتابخانهٔ قدیمی را طوری تغییر دادند که به جدید فراخوانی کند.
بعضی مهندسان از دست دادن انعطاف log کردن رشتهٔ دلخواه ناراضی بودند. کسانی از شرکتهای قبلی با logging انعطافپذیرتر شاید گیج شوند چرا محدودیت عمدی است. بدون ارتباط انگیزهها و کار با آنها برای رفع ناامیدی، ممکن است راههای خلاقانه برای دور زدن safeguardها پیدا کنند و دوباره خطر نشت PII بالا برود.
حتی با پذیرش تغییرات، همه موافق تبدیل فعال callsiteهای موجود به کتابخانهٔ جدید نیستند. شاید بیتفاوت باشند در افزودن log field و type جدید و از field و type موجود برای طیف وسیعتری از logها استفاده کنند — specificity کم میشود. با آسان کردن گسترش کتابخانه و آموزش نحوهٔ انجام، گذار را روانتر و استفادهٔ کلی از کتابخانهٔ جدید را بیشتر میکنید.
راههای زیادی برای تشویق پذیرش در سازمان مهندسی وجود دارد؛ روشهای زیر در تجربهٔ من بهتریناند. اول، ساخت interfaceهای ارگونومیک برای تعامل با کد بازآراییشده — از اوایل اجرا تعریف و در طول توسعه پالایش. بازخورد از همتیمیها و همتیمیهای مورد اعتماد در سازمان برای مرز بین بازآرایی و بقیهٔ کدبیس بگیرید. اگر بازآرایی تمام شد و interfaceها با کاربران آینده بهاندازهٔ کافی آزمایش نشده، workshop با چند مهندس از حوزههای محصول مختلف برگزار کنید و interfaceها را با آنها تکرار کنید.
روشهایی که در این فصل بیشتر بررسی میکنیم بیشتر پس از بازآرایی مؤثرند: آموزش با مستنداتی که ساختهاید، و تقویت دقیق استفاده از الگوهای جدید برای پذیرش مداوم.
آموزش
دو روش اصلی برای آموزش دیگران دربارهٔ بازآرایی: فعال — workshop و آموزش تعاملی؛ غیرفعال — آموزش گامبهگام خودآموز یا دورهٔ کوتاه آنلاین در پلتفرم یادگیری شرکت.
آموزش فعال
بخش آموزشی فعال وقتی مهمترین است که بازآرایی بخش حیاتی کدبیس را که مهندسان زیادی از تیمهای مختلف مرتب استفاده میکنند تحت تأثیر قرار داده. مهندسانی که به الگوهای قبلی عادت کردهاند باید با روش جدید آشنا شوند.
Workshopها
یکی از بهترین راهها برای کار مؤثر با کد بازآراییشده، engagement در فضایی است که مهندسان با نمونههای کد تعاملی کار کنند و هنگام یادگیری interface با بازآرایی سؤال بپرسند. مزیت workshop این است که مهندسان شلوغ را وادار میکند وقت عمدی برای بهروز شدن بگذارند — بعضی در کارهای زیاد گاهی هرگز اولویت نمیدهند.
زمان آموزش فعال بعد از تکمیل تازهٔ بازآرایی است. نمیخواهید مهندسان کد و الگوی جدید یاد بگیرند وقتی هنوز در flux است یا کاملاً برای استفادهٔ کسانی که جزئیات را نمیدانند آماده نشده. قبل از اولین workshop همه چیز را تأیید کنید. بهتر: dry run با تیم خودتان تا مشکلها را قبل از باز کردن به همتیمیها رفع کنید.
این جلسات نباید برای همیشه برگزار شوند. ایدهآل ظرف چند ماه بیشتر مهندسان متأثر بهخوبی آشنا شوند. آن وقت کد بازآراییشده عادی جدید میشود و تقاضا برای کمک فهم آن بهشدت کم میشود. دو یا سه workshop کافی است؛ علاقه و حضور را زیر نظر بگیرید.
آموزش زنده engaging است اما برای تیم شما بسیار وقتبر است — فقط چند بار. اگر بعد از چند جلسه هنوز تقاضا بود، در مستندات سرمایهگذاری کنید و بیشتر به آن تکیه کنید.
در عمل، چون تقریباً هر مهندس در workflow روزانه logging دارد، مثال logging کاندید عالی workshop است. ساختار پیشنهادی:
- مرور کوتاه اهداف بازآرایی. برای اثرگذاری و هیجان همکاران، مثالهای قانعکننده بزنید. برای logging: چند log گمراهکننده مسئول نشت PII در ماههای اخیر؛ سپس نحوهٔ استفاده از کتابخانهٔ جدید برای جلوگیری کامل از نشت.
- تثبیت مفاهیم: شرکتکنندگان را جفت کنید و همان log statement ساده را به کتابخانهٔ جدید مهاجرت دهند. سؤالات را پاسخ دهید. ممکن است بیش از یک راهحل باشد — جفتها راهحلهای متفاوت را توضیح دهند.
- log statement پیچیدهتر: جفتی log پیچیدهتر انتخاب کنند که گسترش کتابخانه لازم دارد (log type یا field type جدید). با هر گروه check-in و سؤالات را پاسخ دهید.
Office hours
Office hours هم برای آموزش فعال مفیدند. مهندسان فرصت باز میآیند و سؤال دربارهٔ بازآرایی و پذیرش در use case خاص خود بپرسند. همه وقت یا علاقهٔ workshop ندارند؛ office hours با توجه اختصاصی تیم احتمال تجربهٔ مثبت پذیرش را بیشتر میکند. شرکتکنندگان workshop هم میتوانند برای راهنمایی بیشتر بیایند.
مزیت office hours: time-box کردن زمانی که تیم صرف پاسخ به سؤالات بازآرایی میکند. بلافاصله بعد از اتمام بازآرایی ممکن است درخواستهای زیادی از سراسر شرکت بیاید. بدون مراقبت، این سؤالات توجه شما را monopolize میکند (و context-switching مکرر). با هدایت درخواستهای غیرفوری به office hours، زمان و تمرکز تیم محافظت میشود.
سؤالات و نگرانیهای برطرفشده در office hours را ثبت کنید و FAQ بنویسید — صرفهجویی در پاسخ مکرر همان سؤالات در office hours و بعد از آن.
گردهماییهای مهندسی
بسیاری از گروههای مهندسی forumهای باز منظم دارند (مثلاً Drinks and Demos پنجشنبه بعدازظهر، یا Lunch and Learn دو هفتهای) که مهندسان دربارهٔ کار پیشرو ارائه میدهند. پروژههای بازآرایی بزرگ اغلب داستانهای جالب دارند: باگ load-bearing باورنکردنی، برخورد با کدی که ۱۵ سال پیش تغییر کرده، deploy اشتباه. بیشتر ما از داستانهای تجربه در کد مشترک لذت میبریم و خوبها را بهخوبی به یاد میآوریم.
برای ارائهٔ کوتاه دربارهٔ بخش جذاب بازآرایی ثبتنام کنید تا همتیمیها از پروژه باخبر و کنجکاو شوند — انگیزهها و سود برای حوزهٔ خودشان. گاهی کمی داستانگویی خوب همهٔ تبلیغ لازم برای حمایت مهندسان است.
آموزش غیرفعال
در فصل ۷ اهمیت مستندات را دیدیم: تولید کامل در طول بازآرایی و انتخاب رسانه و ساختار مناسب. در مراحل پایانی، تیم باید مستنداتی دربارهٔ intent بازآرایی و سود برای مهندسان همان کدبیس بنویسد. طبق فصل ۷، همهٔ مستندات در دایرکتوری منبع واحد حقیقت.
مستندات میتواند FAQ، README کوتاه با خلاصهٔ اهداف، یا آموزش باشد. اشارهٔ مهندسان کنجکاو به مستندات آماده زمان پاسخگویی را کم میکند. طبق «Office hours»، سؤالات زیادی از همتیمیها در سراسر شرکت میآید — بهجای پاسخ فردی، به مستندات ارجاع دهید.
اگر راهنمای how-to برای پیمایش کدبیس پس از بازآرایی مینویسید، از دیدگاه تاریخی بنویسید: داستان بازآرایی از ابتدا تا وضعیت فعلی. این مانع کهنه شدن فوری مستندات میشود. هر جا ممکن است تاریخ بگذارید (حتی سال کافی است).
با مثال logging:
- بینشی که تیم با فهمیدن چرا کد degraded شده به دست آورد (فصل ۲). برای logging: طراحی اولیه و تصمیمها — سبک، آسان، امکان log تقریباً هر چیز با احتیاط.
- پیچیدگی محصول و پیوستن مهندسان بیشتر، ریسک نشت PII. نمونههای جدی اخیر با فراوانی رو به افزایش.
- راهحل و چگونگی جلوگیری از نشت PII. مقایسهٔ همان log statement با کتابخانهٔ قبلی و جدید. از «الان»، «در حال حاضر»، «امروز» پرهیز کنید — کد تکامل مییابد. «از سپتامبر ۲۰۲۰» بهجای «امروز» مستندات را future-proof میکند.
تقویت
تقویت مثبت ابزار قدرتمندی است. فارغ از نزدیکی به پروژه، توسعهدهندگان در شرکت باید بیش از یک بار به الگوهای بازآرایی یادآوری شوند. دو گزینهٔ کلی:
اول، بسیاری از تاکتیکهای انگیزشی «انگیزهٔ افراد» (فصل ۸) برای قدردانی از مهندسانی که الگوها را خوب پذیرفتهاند. دیدن تشویق عمومی همکاران میتواند پذیرش را در سراسر سازمان سریع افزایش دهد.
دوم، خودکارسازی تقویت در فرایند توسعه با continuous integration. با CI میتوان هنگام push، آمادهسازی برای review، یا merge با شاخهٔ اصلی، فرایندهایی را آغاز کرد. معمولاً تستها همراه lint و ابزار تحلیل کد اجرا میشوند. linting و code analyzer و پیکربندی آنها برای آزاد کردن تیم از تشویق و نظارت فعال پذیرش را میبینیم.
Linting تدریجی
Linting تدریجی (progressive linting) بهبود تدریجی کدبیس با اعمال قوانین فقط روی کد تازهنوشته یا تغییریافته. توسعهدهندگان مشکلات را آهسته هنگام بروز رفع میکنند بهجای اینکه یک یا دو مهندس همهٔ نقضها را patch کنند. اگر الگویی را با دیگری جایگزین میکنید، قانون linter تدریجی جدید راه سادهای است برای هل دادن به الگوی جدید و جلوگیری از الگوی deprecated.
مثال: در بازآرایی logging میخواهید logEvent (رشتهٔ دلخواه) را با logEventType (فقط دادهٔ مشخص غیر-PII) جایگزین کنید. قانون linter جدید که هر استفادهٔ جدید از logEvent را ممنوع میکند با پیام خطا که تابع deprecated است و logEventType را پیشنهاد میدهد.
بعضی مهندسان به شکست ناگهانی linter حساساند. هدف قانون جدید و زمان اثر را کافی اعلام کنید. تا حد امکان زمینه در پیام خطا بگذارید تا برای رفع نیاز به مستندات اضافی نباشد.
همهٔ زبانها linter قابل گسترش با قوانین سفارشی ندارند و کمتر progressive linting داخلی دارند. بعضی تیمها این ابزارها را داخلی میسازند (گاهی open-source میکنند). اگر linter قابل گسترش دارید، راه سریع progressive linting: اجرای linter فقط روی فایلهای تغییریافته در commit یا فقط روی diff.
ابزارهای تحلیل کد
بسیاری از معیارهای فصل ۳ را میتوان در طول زمان با ابزارهای تحلیل کد out-of-the-box در زمان integration پایش کرد. طیف وسیعی از راهحلهای رایگان و پولی open-source پیچیدگی کد را در مقیاسهای مختلف (تابع، کلاس، فایل و غیره) و آمار پوشش تست محاسبه میکنند. بسیاری قابل گسترشاند تا تیم معیار و قانون خود را اضافه کند.
مثال: هیچ تابعی در کدبیس از ۵۰۰ خط تجاوز نکند. ابزار تحلیل کد را طوری پیکربندی کنید که هنگام عبور تابع از آستانه هشدار یا خطا دهد. اگر کسی چند خط اضافه کند و از ۴۹۰ به ۵۱۲ برسد، برای merge به تقسیم به زیرتابعهای کوچکتر هدایت شود.
Gate در برابر Guardrail
هر گام تأیید در جریان integration میتواند gate باشد (مانع ادامه) یا guardrail (هشدار برای در نظر گرفتن قبل از ادامه).
gateهای زیاد برای سازمان مهندسی مضر است: توسعه را کند و مهندسان را ناامید میکند (بهویژه اگر غیرمنتظره باشند). فرض کنید ۱۰ مجموعه تست blocking دارید. هنگام آمادهسازی برای review، تستها موازی اجرا میشوند. نیمی بیش از ۱۰ دقیقه طول میکشد و بعضی flaky هستند. مهندسان وقت زیادی منتظر عبور از ۱۰ gate میمانند.
اگر بهجای gate، guardrail بگذارید: فقط دو یا سه مجموعه را واقعاً business-critical قبل از merge blocking کنید و بقیه اختیاری. مهندس تعیین میکند کدام برای تغییرش مهمتر است؛ اگر flaky بود میتواند نادیده بگیرد. guardrail بیشتر ریسک خود دارد — شاید باگ بیشتری به production برود — اما بهطور کلی معتقدم باید بیشتر به هممهندسان اعتماد کنیم.
مالکیت (Ownership)
مهندسان زیادی در شرکتهای بزرگ (از جمله من) با سؤال دربارهٔ کدی که آخرین بار آن را تغییر دادهاند ping میشوند. کسی که بازآرایی گسترده کرده سعی میکند تاریخچهٔ نسخه حفظ شود، اما نام من در git blame عمیق در توابعی که کمآشنا هستم ظاهر میشود. در incident، JIRA و code review با زمینهٔ کم آورده میشوم و ناامید میکنم کسانی که کمک میخواهند. اغلب تیم مسئول کد را درست شناسایی میکنیم؛ گاهی کد مالک ندارد و کسی مشتاق claim نیست.
کد بدون مالک مشکل خاردار تقریباً همهٔ شرکتهای بزرگ است — اینجا حل نمیکنیم، اما چند دفاع اگر git blame شما را بکشد: ممکن است خوشحال کمک کنید، اما مراقب precedent پذیرش مسئولیت کد بدون مالک باشید. قبل از آنکه مالک de facto شوید و دیگران برای کد unrelated بیایند، بگویید تیم شما مسئول نیست. پیشنهاد همکاری (یا مدیرتان با آنها) برای پیدا کردن کاندید بهتر. اگر درخواست کوتاهمدت و فوری (باگ ساده) است، شاید کسی با وقت و زمینه پیدا شود. جستجو در تاریخچهٔ نسخه برای مالک موقت قبل از تغییرات شما، یا توسعهدهنده/تیم با commitهای اخیر در همان فایل، گزینههای خوبیاند. بعد از شناسایی کسی برای درخواست فوری، از مدیر بخواهید با همتیمیها برای خانهٔ بلندمدت صحبت کند. ممکن است بازی hot potato طولانی شود، اما امیدوارانه خودتان را از معادله خارج کردهاید.
ادغام بهبود در فرهنگ
همیشه نیاز به بازآرایی در مقیاس بزرگ خواهد بود، تا وقتی نتوانیم پیشبینی کنیم فناوری و نیازمندیها چگونه سیستمها را تحت تأثیر قرار میدهند. اما باور دارم بعضی بازآراییهای بزرگ قابل اجتناباند و باید تا حد امکان جلوگیری کنیم. در پایان این فصل، چند فکر دربارهٔ فرهنگ بهبود مستمر:
اول و مهم، یکی از بهترین راهها برای کدبیس سالم، بازآرایی عمدی و کوچک بخشهای well-contained هنگام برخورد با فرصت است. drive-by refactorer نشویم (بخش «چون اتفاقاً از آنجا رد میشدید»، صفحهٔ ۱۶) — روی مناطقی که تیم خودمان مالک و نگهدارنده است تمرکز کنیم. همیشه فرصت مرتبکردن در محلهٔ خودمان هست. وقتی فرصتی برای تیم دیگر دیدیم، با سؤال برای فهم بهتر مشکل تماس بگیریم نه فوراً راهحل — با هم پیادهسازی تمیزتر بسازیم.
دوم، گفتوگوهای طراحی را مرتب در تیم تشویق و تسهیل کنیم — بازخورد زود بگیریم نه تنها پیشروی تنها. Code review فقط double-check نیست؛ فرصت بحث باز دربارهٔ بهتر کردن راهحل. بهعنوان نویسنده، code review را با سؤالات مشخص برای reviewer annotate کنیم. بهعنوان reviewer، بهاندازهٔ نوشتن کد، تحلیلی باشیم.
سوم، design reviewهای فراگیر زود در فرایند توسعهٔ feature. مهندسان از همهٔ پیشینهها برای ارزیابی طراحی و پرسیدن سؤال دعوت شوند — همهٔ سطوح تجربه و ارشدیت؛ دیدگاههای متنوع. هرچه دیدگاه متنوعتر، احتمال کشف نقص مرگبار زودتر و معماری برتر بیشتر.
دفعهٔ بعد که مینشینید کار کنید، فکر کنید کاری که امروز میکنید چگونه ممکن است بعداً به بازآرایی بزرگ منجر شود. گاهی یادآوری پیامد بلندمدت تصمیمها کافی است تا به مسیر درست برگردیم.
بخش چهارم — مطالعات موردی
قبل از ورود به مطالعات موردی، کمی دربارهٔ Slack بگویم: تاریخچهٔ محصول، شرکت و تأثیرات اولیه.
Slack بهعنوان ابزار داخلی در شرکت بازی کوچک Tiny Speck در ونکوور ساخته شد. تیم — ترکیبی از مهندسان، طراحان و افراد محصول از Flickr — میخواست بازی فانتزی massively multiplayer با تمرکز بر جامعهسازی بسازد: Glitch.
چون همه در سراسر آمریکای شمالی پراکنده بودند، Tiny Speck سنگین به internet relay chat (IRC) تکیه کرد. زود فهمید به چیزی قویتر نیاز دارد: ابزاری برای ارتباط ناهمگام، جستجو در تاریخچهٔ پیام و ارسال فایل. ساختنش را شروع کرد.
بازی در نهایت ۲۰۱۲ تعطیل شد و بیشتر کارمندان اخراج شدند، اما Tiny Speck یک ترفند نهایی داشت. در pivot غیرمحتمل، چند نفر باقیمانده ابزار ارتباط داخلی را تجاری کردند. تجربه را صیقل دادند و Slack نام گذاشتند: searchable log of all conversation and knowledge.
تیم Tiny Speck به دوستان و همکاران سابق برای تست تماس گرفت. با هر دسته کاربر، بازخورد جمع، باگ رفع و قابلیت جدید ساخت. تا می ۲۰۱۳ محصول برای preview آماده بود — برای عدهٔ منتخب با دعوتنامه. فقط نه ماه بعد Slack عمومی شد.
استفاده جهشی کرد. ظرف یک سال از زیر ۱۵٬۰۰۰ کاربر فعال روزانه به ۵۰۰٬۰۰۰ رسید. تا دومین سالگرد، بیش از ۲٫۳ میلیون کاربر روزانه. اواخر ۲۰۱۹، نزدیک به شش سال از راهاندازی، بیش از ۱۲ میلیون — با بیش از ۱ میلیارد پیام در هفته.
بسیاری از تصمیمهای فناوری و طراحی اولیهٔ Slack از تجربهٔ ساخت Flickr و Glitch بود. استفاده از PHP و MySQL منطقی بود با تجربهٔ ۲۰۰۴ در سایت اشتراک عکس. در واقع بخش زیادی از عملکرد سرور Slack ریشه در Flamework دارد — فریمورک PHP وباپلیکیشن از فرایندها و سبک خانه در Flickr؛ روی GitHub پیدا میشود. زیرساخت پیام real-time مستقیم از ابزار شبیه IRC داخلی Tiny Speck مشتق شد.
اوایل ۲۰۱۶ Slack جایگزینهایی برای مفسر Zend Engine II برای PHP بررسی کرد: ارتقا به PHP 7 و Zend Engine III، یا HipHop Virtual Machine (HHVM) فیسبوک. پس از بحث، رهبری HHVM را روی وبسرورها rollout کرد. پس از موفقیت، تیم مهندسی زبان Hack را پذیرفت — dialect تدریجی typed از PHP برای اجرا روی HHVM. در زمان انتشار، بخشی از کدبیس Slack که قبلاً PHP بود اکنون Hack است.
هر دو مطالعهٔ موردی این بخش روی تلاشهای بازآرایی بزرگ در بخشی از کدبیس که ابتدا PHP و بعد Hack بود تمرکز دارند. برای بیان ماهیت هر مسئله، نمونههای کد Hack خواهند بود. نگران نباشید! قطعهها مثالهای کوچک و ملموس هستند، نه تمرکز داستان. بازآرایی در مقیاس بزرگ بیشتر دربارهٔ فرایند و افراد است تا کد — امیدوارم مطالعات موردی دقیقاً همین را نشان دهند. اگر نگران parse کردن نمونهها هستید: در آن زمان Hack هنوز شبیه PHP بود. برای کسانی که با Hack یا PHP راحت نیستند، هر قطعه را با جزئیات مرور میکنیم.
یک مشاهدهٔ نهایی قبل از ادامه: در زمان انتشار، Slack فقط شش سال عمومی بوده. کد، محصول و شرکت نسبتاً جواناند. کد باید سریع scale کند — هم برای استفادهٔ مشتری و هم برای مهندسان بیشتر روی محصول. بسیاری از بازآراییهای بزرگ در طول سالها پاسخ به hypergrowth بوده — بیرونی از پذیرش بالا و داخلی از استخدام.