وظیفه شما فقط نوشتن کد نیست، بلکه تصمیمگیری است. شما از آنها درس میگیرید. با گذشت زمان، اشتباهات کمتری مرتکب میشوید. در نهایت، دیگران را از میان همان مه و ابهامها راهنمایی میکنید. این مسیر — از نوشتن منطق تا مالکیت نتایج — همان چیزی است که یک تایپیستِ سینتکس را از یک سیستمساز متمایز میکند.
شما هر روز انتخابهایی میکنید. برخی بیاهمیت به نظر میرسند، مثل انتخاب رنگ یک دکمه. برخی دیگر کل محصول را بازطراحی میکنند. نکته اصلی این است که خیلی زود تشخیص دهید این دو به هم مرتبط هستند. یک تصمیم کوچک که با بیدقتی گرفته شود، میتواند بعداً به یک محدودیت بزرگ تبدیل شود، در حالی که یک انتخاب سخت که در ابتدا انجام شود، اغلب در نگاه به گذشته، نبوغآمیز به نظر میرسد.
شعاع انفجار انتخابهای اولیه
وقتی تازه کار را شروع میکنید، اشتباهات شما در یک اتاق کوچک طنینانداز میشود. یک commit بد، build محلی را از کار میاندازد. یک تابع بیدقت، سرعت یک صفحه را کم میکند. شعاع انفجار محدود میماند. شما افراد کمی را تحت تأثیر قرار میدهید و هزینه بازیابی ناچیز است.
اما همانطور که رشد میکنید، چه به عنوان یک مهندس مستقل و چه به عنوان یک شرکت، تصمیمات شما در سیستمهای بیشتری اثر میگذارد. همان انتخاب اگر در مقیاس بزرگ انجام شود، میتواند هفتهها هزینه داشته باشد. به همین دلیل است که باید یاد بگیرید همین حالا تصمیمات حسابشده بگیرید، قبل از اینکه بهای آن سنگین شود.
به سه تله رایج فکر کنید:
استفاده از پلتفرمی که وابستگیهای (
dependencies) شما از آن پشتیبانی نمیکنند، میتواند دهها یا صدها ساعت مهندسی را تلف کند. آن ساعتها فقط تایپ کردن نیست؛ بلکه عیبیابی مشکلات عجیب سازگاری، وصله کردن کتابخانههای واسط (transitive libraries) و توضیح به ذینفعان است که چرا یک ویژگی ساده، یک فصل کامل زمان برده است.تغییر از احراز هویت مبتنی بر نشست (
session-based) بهJWTها در مراحل اولیه عمر محصول، از بازنویسی پرهزینه در آینده جلوگیری میکند. بازسازی (refactor) منطق ورود زمانی که هزاران کاربر دارید، بسیار آسانتر از زمانی است که میلیونها کاربر دارید و از کار افتادن سیستم (downtime) هزینههای واقعی مالی به همراه دارد.تخمین زمان به اندازه دو برابرِ بهترین حدس خود، تنها زمانی کار میکند که از آن حاشیه امنیت (
buffer) برای محافظت از کیفیت استفاده کنید. پر کردن زمانبندی برای اینکه بتوانید در شبکههای اجتماعی بچرخید، اتلاف وقت است. اما پر کردن آن برای نوشتن تستها، بررسی موارد خاص (edge cases) و تأیید قابلیت مشاهدهپذیری (observability)، یک سرمایهگذاری است.
الگوی اینجا ساده است: بدهی فنی (technical debt) مرکب است. تا زمانی که اصل بدهی کم است، آن را تسویه کنید.
تاریخهای تعیینشده و توهم کنترل
ضربالاجلها همهجا هستند. تاریخهای انتشار، تاریخهای دمو، زمانهای فریز شدن کد (code freezes). در شرکتهای بزرگ، اینها اغلب بیشتر از آنکه هدف فنی داشته باشند، هدف روانشناختی دارند. آنها حسی از کنترل بر پیچیدگی ایجاد میکنند که هیچکس بهطور کامل آن را درک نمیکند.
عارضه جانبی آن قابل پیشبینی است. با نزدیک شدن به تاریخ تعیینشده، کیفیت کاهش مییابد. تیمها تستها را حذف میکنند، مدیریت خطاها را کامنت میکنند و کدی را عرضه میکنند که هیچکس دوست ندارد نگهداری کند. ضربالاجل رعایت میشود. تقویم تمیز به نظر میرسد. اما محصول بدتر شده است.
این اتفاق به این دلیل میافتد که مهندسان عاشق کد بینقص و معماری ظریف هستند. این در طبیعت ماست. اما پاسخ بینقص همیشه وجود ندارد. انتخاب درست، انتخابی است که با وضعیت فعلی تیم شما همخوانی داشته باشد. یک استارتاپ سه نفره به همان تشریفات و فرآیندهایی نیاز ندارد که یک پلتفرم مراقبتهای بهداشتی تحت نظارت قانونی نیاز دارد. شما برای جایی که هستید میسازید، نه برای جایی که یک سازمان مهندسی هزار نفره پنج سال پیش بود.
وقتی رشد، قوانین قدیمی را میشکند
این چیزی است که مدیریت اغلب نادیده میگیرد. با رشد یک شرکت، ضربالاجلها نیز باید رشد کنند. فرآیندها گسترش مییابند. افراد جدید میآیند و نیاز به آشنایی با سیستم (onboarding) دارند. وظایف تکثیر میشوند چون محصولات بیشتری وجود دارند. الزامات انطباق (compliance) انباشته میشوند — بررسیهای امنیتی داخلی، حسابرسیهای خارجی، بررسیهای حاکمیت داده. سطح تماس (surface area) افزایش مییابد، اما خط پایان ثابت میماند.
استفاده از همان ضربالاجلها برای حجم کار بیشتر، تیم را سریعتر نمیکند؛ بلکه آنها را بیدقت میکند. از زیر کار در میروند. مستندات ناپدید میشوند. پاسخ به حوادث (incident response) صرفاً واکنشی میشود. همان مهندسانی که زمانی کد تمیز عرضه میکردند، اکنون چون تقویم اجازه انعطاف نمیدهد، فقط وصلهپینه عرضه میکنند.
اگر شرکتی سرعت در مقیاس بالا را میخواهد، باید یا مسیرهای موازی کار را اضافه کند یا بازههای زمانی را طولانیتر کند. شما نمیتوانید یک بکلاگ (backlog) همیشه در حال رشد را در یک اسپرینتی (sprint) جا دهید که سه استخدام قبل، فشرده به نظر میرسید.
گنجاندن حاشیه امنیت در برنامهریزی
یک عادت که سلامت روان شما را حفظ میکند: فرض کنید قرار است مشکلی پیش بیاید. این بدبینی نیست، بلکه واقعگرایی است.
سیستمها از کار میافتند. APIهای شخص ثالث کند میشوند. الزامات تغییر میکنند چون یک مدیر محصول دیروز با یک مشتری صحبت کرده است. وقتی برای اصطکاک برنامهریزی میکنید، ضربالاجلهای شما صادقانه باقی میمانند. شما این توانایی را به دست میآورید که بین سرعت و کیفیت انتخاب کنید. بدون آن حاشیه امنیت، هر بار این انتخاب برای شما انجام میشود. شما مجبور میشوید سرعت را انتخاب کنید، که یعنی مجبور هستید کیفیت را فدا کنید.
آن زمانِ اضافه، همان جایی است که یادگیری در آن جریان دارد. اگر هر ساعت به توسعهی قابلیتها اختصاص یابد، هیچکس فضایی برای بهبود build pipeline، بازنویسی (refactor) لایه query یا مستندسازی قرارداد API نخواهد داشت. تیم برای همیشه در سرعت فعلی خود متوقف میماند.
جایگزینی یک خطا با خطایی دیگر
ما در حال حاضر با شتاب به سمت یک معاملهی عجیب میرویم. ما در حال جایگزین کردن خطاهای انسانی با خطاهای نرمافزاری غیرقطعی (non-deterministic) هستیم. مدلهای زبانی بزرگ میتوانند کدهای boilerplate تولید کنند، تستها را پیشنهاد دهند و مستندات را سریعتر از هر مهندس تازهکاری پیشنویس کنند. اما آنها این کار را با اعتمادبهنفس انجام میدهند، و به شکلی اشتباه انجام میدهند که...