هر پروژه جدید همان وسوسه را زمزمه میکند: ویرایشگر را باز کن، یک فریمورک انتخاب کن و شروع به تایپ کن. برای MaxOS، سازنده آن Max Paardekam این کشش را به شدت حس میکرد. چند هفته پیش، پروژه تنها به صورت ایدههای پراکنده در یادداشتهای او وجود داشت. غریزه فوری او این بود که ساعتها وقت صرف نوشتن TypeScript در Cursor کند و اجازه دهد حافظه عضلانی و تکمیل خودکار (autocomplete) شتاب بگیرند. او مقاومت کرد. به جای کد اپلیکیشن، او چیزی کمیابتر و شکنندهتر تولید کرد: یک معماری کامل.
آن تصمیم در ابتدا شبیه به رکود به نظر میرسید. وقتی ابزارها آماده هستند و کدهای اولیه (boilerplate) در چند ثانیه نصب میشوند، توقف برای کشیدن جعبهها و فلشها میتواند مضحک به نظر برسد. اما MaxOS قرار نیست یک رپر (wrapper) ساده Electron دور یک web view دیگر باشد. هدف ساخت چیزی است که سالها در برابر استفاده، ریفکتورینگ (refactoring) و گسترش دوام بیاورد. سیستمهایی با این طول عمر، چیزی عمیقتر از یک شروع سریع میطلبند. آنها پیش از اولین دستور import به تفکر منسجم نیاز دارند.
چرا IDE میتواند منتظر بماند
محیطهای توسعه مدرن مرز بین برنامهریزی و اجرا را کمرنگ میکنند. Cursor و ویرایشگرهای مشابه که با هوش مصنوعی کمک میگیرند، تولید کل کامپوننتها را تنها از طریق یک کامنت ممکن میسازند. حلقه بازخورد فوری است و لذت ناشی از ترشح دوپامین هنگام تماشای شکلگیری یک UI به سختی قابل جایگزینی است. Paardekam دقیقاً با همین فرض شروع کرد: بیشتر انرژی اولیه او مستقیماً صرف فایلهای TypeScript خواهد شد. با این حال، او به تدریج آن روزها را به سمت کار طراحی خالص هدایت کرد.
این یک چرخش دشوار برای هر سازنده تکنفره است. وقتی شما تمام تیم مهندسی خود هستید، هر ساعتی که در یک ابزار نمودار یا یک سند متنی سپری میشود، مانند ساعتی است که از زمان عرضه محصول (shipping) دزدیده شده است. اما کدهای اولیه اغلب بدهیای هستند که در لباس پیشرفت ظاهر شدهاند. جذابیت یک پروتوتایپ در حال اجرا، زمانی که هر ویژگی جدید مستلزم تغییرات کثیف (hacking) برای دور زدن فرضیات ایجاد شده در اولین بعدازظهر است، به سرعت از بین میرود. Paardekam با مجبور کردن خود به دوری از ویرایشگر، تنها داراییای را خرید که با گذشت زمان ارزشش بیشتر میشود: شفافیت.
تفکر سیستمی، نه ویژگیمحور
مهمترین تغییر در طول این هفتهها فنی نبود، بلکه شناختی بود. معماری نرمافزار، وقتی جدی گرفته شود، سوالاتی را که میپرسید بازسازی میکند. Paardekam دیگر با ذهنیت ویژگیمحور به پروژه نگاه نمیکرد. او دیگر نمیپرسید چگونه یک قابلیت خاص را به سیستم اضافه کند. در عوض، با سوال سختتری روبرو شد: چه ساختار زیربنایی باعث میشود افزودن هر قابلیت در آینده آسانتر شود؟
این تمایز اهمیت دارد. ذهنیت ویژگیمحور با نرمافزار مانند یک لیست انجام کار (to-do list) برخورد میکند. شما جستجو را پیادهسازی میکنید، سپس اعلانها، و سپس یک دکمه خروجی. اما ذهنیت سیستمی میپرسد که چگونه جستجو، اعلانها و خروجیها میتوانند از یک مدل داده، یک event bus و یک لایه دسترسی یکسان استفاده کنند. این یعنی طراحی دستور زبان (grammar) اپلیکیشن پیش از نوشتن جملات آن. هزینه اولیه بالاتر است، اما پاداش آن این است که کارهای آینده دیگر شبیه مونتاژ کردن نیستند، بلکه شبیه ترکیب کردن (composition) میشوند.
این موضوع بهویژه برای پروژهای مانند MaxOS که هدفش ادغام عملکردهایی است که معمولاً در ده اپلیکیشن مختلف قرار دارند، حیاتی است. ادغام تنگاتنگ بدون تفکر سیستمی، به کابوسی از پلهای شکننده و وضعیتهای ناسازگار تبدیل میشود. با وجود آن، فضای کاری (workspace) به جای اینکه مجموعهای از ابزارهای وصلهپینه شده باشد، مانند یک موجود واحد عمل میکند.
فضای کاری، نه سیستمعامل
Paardekam درباره مرزهای جاهطلبی خود صریح بوده است. MaxOS جایگزین Windows یا macOS نخواهد شد. این پروژه قصد مدیریت درایورها، تخصیص حافظه یا لایههای انتزاع سختافزار (hardware abstraction layers) را ندارد. هدف چیزی صمیمیتر است: فضای کاری.
اکثر کارکنان دانشمحور در محیطی تکهتکه زندگی میکنند. شما از کلاینت ایمیل به تقویم، از اپلیکیشن یادداشت به ترمینال، و از ابزار طراحی به پلتفرم پیامرسان میپرید. هر پرش اصطکاک به همراه دارد. بافتار (context) از دست میرود. تمرکز تکهتکه میشود. سیستمعامل صحنه را فراهم میکند، اما کارگردانی نمایش را بر عهده نمیگیرد.
MaxOS قصد دارد آن تجربه را در یک محیط واحد متحد کند که سیر کار شما را درک کرده و فعالانه به شما کمک میکند سریعتر حرکت کنید. این یک چالش مهندسی متفاوت با ساخت یک سیستمعامل سنتی است. این کار مستلزم همدلی عمیق با جریانهای کاری (workflows)، ویرایش بیرحمانه محدوده پروژه (scope) و رابطهایی است که خود را با هدف کاربر تطبیق میدهند، نه اینکه کاربر را مجبور کنند با ابزار سازگار شود. جایگزین کردن یک فضای کاری به معنای جایگزین کردن عادتهاست، و عادتها تنها زمانی تغییر میکنند که جایگزین، به جای اینکه یک منحنی یادگیری دشوار باشد، حس آسودگی بدهد.
آنچه در هفتههای آرام ساخته شد
مرحله معماری Paardekam دو خروجی ملموس داشت. اول، تعریف دقیق چشمانداز و مأموریت. این یک شعار تبلیغاتی نیست. برای یک بنیانگذار فنی تکنفره، این کار به عنوان نگهبان نهایی محدوده پروژه عمل میکند. وقتی با تصمیمی روبرو میشوید که آیا یک نوار کناری چت اضافه کنید یا یک بازارچه افزونه، بیانیه مأموریت یا آن را میپذیرد یا رد میکند. دوم، او یک طرح اولیه (blueprint) کامل از پروژه را تکمیل کرد.
دیدن کل برنامه که از ابتدا تا انتها ترسیم شده بود، روانشناسی پروژه را تغییر داد. ایدهها در دفترچه یادداشت، فرضی به نظر میرسند؛ اما یک طرح اولیه، قطعی و اجتنابناپذیر به نظر میرسد. این طرح، شکافها را زمانی که اصلاح آنها هنوز کمهزینه است، آشکار میکند و نشان میدهد که سختترین ریسکها کجا پنهان شدهاند. در این مرحله، یک سند دقیق واقعاً بیشتر از خطوط کد اهمیت دارد. کد را میتوان بازسازی (refactor) کرد؛ اما یک پیشفرض مبهم به بدهی فنی تبدیل میشود که هیچ مقدار عیبیابی (debugging) در نیمهشب نمیتواند آن را از بین ببرد.
از کاغذ تا Monorepo
با اتمام معماری، مرحله بعدی آغاز شده است. Paardekam در حال حرکت از اسناد به سمت کد است و کار را با راهاندازی monorepo شروع میکند. این انتقال اضطراب خاص خود را دارد. یک طرح اولیه، یک وعده است؛ اما یک مجموعه کد (codebase)، یک اثبات است. او اعتراف کرده که نگران است که آیا طراحی در مواجهه با پیادهسازی دوام خواهد آورد یا خیر. این صداقت نشاندهنده احترام سالم به ناشناختههایی است که تنها زمانی ظاهر میشوند که تئوری با نسخههای کتابخانهها، موارد خاص (edge cases) و واقعیتهای رفتار چندپلتفرمی برخورد میکند.
راهاندازی monorepo چیزی فراتر از یک git init تشریفاتی است. این کار ساختار فیزیکی را تعیین میکند که بازتابدهنده معماری منطقی خواهد بود. اینکه بستهها (packages) کجا قرار میگیرند، چگونه به یکدیگر وابسته هستند و مرزهای بین لایهها کجاست، بازتابدهنده هفتهها برنامهریزی خواهد بود. اگر این کار به خوبی انجام شود، اولین ساختار پوشهبندی و خط لوله ساخت (build pipeline) راهنمای مشارکتهای آینده خواهد بود. اگر بد انجام شود، سالها هر توسعهدهندهای را که پروژه را لمس کند، بیصدا مجازات خواهد کرد.
نکته اصلی
تجربه Paardekam برخلاف «کیش سرعت» است که بر بخش بزرگی از فرهنگ مدرن نرمافزار حاکم است. فشار شدیدی برای عرضه سریع، نشان دادن رشد و اجازه دادن به کد برای جایگزینی با گفتگو وجود دارد. اما برخی پروژهها، بهویژه آنهایی که قرار است ماندگار باشند، پاداش صبر را میدهند. انضباط در تعریف چشمانداز، ترسیم طرح اولیه و طراحی سیستم پیش از تعریف متغیرها، نصیحتی قدیمی است که هرگز اعتبار خود را از دست نداده است.
اگر در حال حاضر ایدهای در سر دارید و مشتاق هستید که ادیتور خود را باز کنید، بررسی کنید که آیا چند روز طراحی آگاهانه بیشتر، ممکن است ماهها از بازکاریهای پراکنده شما جلوگیری کند یا خیر. دوپامینِ ناشی از اجرای یک اپلیکیشن محو میشود، اما وضوحِ یک معماری خوب، اثر مرکب دارد. با دانستن دقیق اینکه چه چیزی میسازید و چرا، شروع کنید. تایپ کردن میتواند منتظر بماند.