Every new project whispers the same temptation: open the editor, pick a framework, and start typing. For MaxOS, creator

Mỗi dự án mới đều thì thầm cùng một sự cám dỗ: mở trình soạn thảo, chọn một framework, và bắt đầu gõ. Với MaxOS, người sáng lập Max Paardekam đã cảm nhận được sức hút đó một cách mãnh liệt. Vài tuần trước, dự án này chỉ tồn tại dưới dạng những ý tưởng rời rạc trong ghi chú của anh. Bản năng tức thời của anh là dành hàng giờ liền để viết TypeScript trong Cursor, để trí nhớ cơ bắp và tính năng tự động hoàn thành tạo đà. Anh đã cưỡng lại. Thay vì viết mã ứng dụng, anh đã tạo ra một thứ hiếm hoi và mong manh hơn: một kiến trúc hoàn chỉnh.

Quyết định đó ban đầu mang lại cảm giác như sự trì trệ. Khi các công cụ đã sẵn sàng và các mã mẫu (boilerplate) được cài đặt chỉ trong vài giây, việc tạm dừng để vẽ các ô và mũi tên có vẻ thật vô lý. Nhưng MaxOS không được định hình để trở thành một bản bọc Electron đơn giản khác xung quanh một web view. Mục tiêu là xây dựng một thứ có thể tồn tại qua nhiều năm sử dụng, tái cấu trúc (refactoring) và mở rộng. Những hệ thống có tuổi thọ như vậy đòi hỏi điều gì đó sâu sắc hơn là một sự khởi đầu nhanh chóng. Chúng cần tư duy mạch lạc trước cả câu lệnh import đầu tiên.

Tại sao IDE có thể chờ đợi

Các môi trường phát triển hiện đại đang làm mờ đi ranh giới giữa lập kế hoạch và thực thi. Cursor và các trình soạn thảo hỗ trợ AI tương tự cho phép tạo ra toàn bộ các component chỉ từ một dòng chú thích. Vòng lặp phản hồi diễn ra tức thì, và cảm giác hưng phấn (dopamine hit) khi chứng kiến một giao diện người dùng (UI) hiện ra là điều rất khó cưỡng lại. Paardekam đã bắt đầu với chính giả định đó: phần lớn năng lượng ban đầu của anh sẽ đổ trực tiếp vào các tệp TypeScript. Tuy nhiên, anh đã dần dần chuyển hướng những ngày đó sang công việc thiết kế thuần túy.

Đây là một sự chuyển hướng khó khăn đối với bất kỳ nhà phát triển độc lập nào. Khi bạn là cả một đội ngũ kỹ thuật, mỗi giờ dành cho công cụ vẽ sơ đồ hoặc tài liệu văn bản đều cảm giác như một giờ bị đánh cắp khỏi việc ra mắt sản phẩm. Nhưng mã nguồn sớm thường là một gánh nặng được ngụy trang dưới danh nghĩa tiến độ. Sự mới mẻ của một bản mẫu (prototype) đang chạy sẽ nhanh chóng tan biến khi mỗi tính năng mới đều đòi hỏi phải sửa đổi chắp vá xung quanh những giả định đã được định hình ngay từ buổi chiều đầu tiên. Bằng cách ép bản thân rời xa trình soạn thảo, Paardekam đã mua được một tài sản duy nhất có khả năng tích lũy theo thời gian: sự rõ ràng.

Tư duy theo Hệ thống, không phải Tính năng

Sự thay đổi đáng kể nhất trong những tuần này không phải là về mặt kỹ thuật. Đó là về mặt nhận thức. Kiến trúc phần mềm, khi được xem xét một cách nghiêm túc, sẽ định hình lại những câu hỏi mà bạn đặt ra. Paardekam đã ngừng tiếp cận dự án với tư duy tính năng. Anh không còn hỏi làm thế nào để gắn thêm một khả năng cụ thể nào đó. Thay vào đó, anh đối mặt với một câu hỏi khó hơn: cấu trúc nền tảng nào sẽ giúp việc thêm mọi khả năng trong tương lai trở nên dễ dàng hơn?

Sự khác biệt đó rất quan trọng. Tư duy tính năng coi phần mềm như một danh sách việc cần làm. Bạn triển khai tìm kiếm, sau đó là thông báo, rồi đến nút xuất dữ liệu. Tư duy hệ thống đặt câu hỏi làm thế nào để tìm kiếm, thông báo và xuất dữ liệu có thể chia sẻ cùng một mô hình dữ liệu, cùng một event bus và cùng một lớp phân quyền. Điều đó có nghĩa là thiết kế "ngữ pháp" của ứng dụng trước khi viết các "câu văn" của nó. Chi phí ban đầu sẽ cao hơn. Nhưng phần thưởng là công việc trong tương lai sẽ không còn cảm giác như đang lắp ráp mà bắt đầu giống như đang sáng tác.

Điều này đặc biệt quan trọng đối với một dự án như MaxOS, vốn nhằm mục đích tích hợp các chức năng thường nằm trong mười ứng dụng khác nhau. Sự tích hợp chặt chẽ mà thiếu tư duy hệ thống sẽ trở thành một cơn ác mộng của những "chiếc cầu" mong manh và trạng thái không nhất quán. Có được tư duy đó, không gian làm việc sẽ hoạt động như một thực thể duy nhất thay vì là một tập hợp các công cụ được chắp vá lại với nhau.

Không gian làm việc, không phải Hệ điều hành

Paardekam đã thẳng thắn về ranh giới tham vọng của mình. MaxOS sẽ không thay thế Windows hay macOS. Nó không có tham vọng quản lý driver, cấp phát bộ nhớ hay các lớp trừu tượng phần cứng. Mục tiêu là một thứ gần gũi hơn: không gian làm việc.

Hầu hết những người làm việc trí óc đều sống trong một môi trường phân mảnh. Bạn nhảy từ trình duyệt email sang lịch, từ ứng dụng ghi chú sang terminal, từ công cụ thiết kế sang nền tảng nhắn tin. Mỗi lần chuyển đổi đều mang theo sự ma sát. Ngữ cảnh bị mất đi. Sự tập trung bị phân tán. Hệ điều hành cung cấp sân khấu, nhưng nó không đạo diễn vở diễn.

MaxOS dự định thống nhất trải nghiệm đó vào một môi trường duy nhất, nơi hiểu được tiến trình công việc của bạn và chủ động giúp bạn di chuyển nhanh hơn. Đó là một thách thức kỹ thuật khác biệt so với việc xây dựng một OS truyền thống. Nó đòi hỏi sự thấu hiểu sâu sắc về quy trình làm việc, sự cắt tỉa phạm vi một cách quyết liệt, và các giao diện thích ứng với ý định của người dùng thay vì buộc người dùng phải thích nghi với công cụ. Thay thế một không gian làm việc đồng nghĩa với việc thay thế các thói quen, và thói quen chỉ thay đổi khi sự lựa chọn thay thế mang lại cảm giác nhẹ nhõm thay vì là một rào cản học tập.

Những gì đã được xây dựng trong những tuần tĩnh lặng

Giai đoạn kiến trúc của Paardekam đã tạo ra hai kết quả bàn giao cụ thể. Đầu tiên là định nghĩa rõ ràng về tầm nhìn và sứ mệnh. Đây không phải là những lời quảng cáo sáo rỗng. Đối với một nhà sáng lập kỹ thuật độc lập, nó đóng vai trò như một người bảo vệ phạm vi tối thượng. Khi bạn đối mặt với quyết định có nên thêm một thanh bên trò chuyện hay một chợ ứng dụng (plugin marketplace) hay không, tuyên bố sứ mệnh sẽ hoặc là chấp nhận nó, hoặc là bác bỏ nó. Thứ hai, anh ấy đã hoàn thành một bản thiết kế dự án (blueprint) đầy đủ.

Việc nhìn thấy toàn bộ kế hoạch được vạch ra từ đầu đến cuối đã thay đổi tâm lý của dự án. Những ý tưởng trong sổ tay mang lại cảm giác giả định. Một bản thiết kế mang lại cảm giác tất yếu. Nó bộc lộ những lỗ hổng khi chúng vẫn còn dễ dàng để khắc phục. Nó tiết lộ nơi ẩn giấu những rủi ro khó khăn nhất. Ở giai đoạn này, một tài liệu chính xác thực sự quan trọng hơn những dòng mã. Mã nguồn có thể được tái cấu trúc (refactor); nhưng một tiền đề mơ hồ sẽ kết tinh thành nợ kỹ thuật (technical debt) mà không có lượng công việc gỡ lỗi (debugging) đêm khuya nào có thể xóa bỏ được.

Từ giấy tờ đến Monorepo

Khi kiến trúc đã hoàn tất, giai đoạn tiếp theo đã bắt đầu. Paardekam đang chuyển từ tài liệu sang mã nguồn, bắt đầu với việc khởi tạo monorepo. Sự chuyển đổi này mang theo nỗi lo âu riêng. Một bản thiết kế là một lời hứa. Một kho mã nguồn (codebase) là bằng chứng. Anh ấy thừa nhận cảm thấy lo lắng về việc liệu thiết kế có trụ vững được khi đối mặt với quá trình triển khai thực tế hay không. Sự trung thực đó phản ánh một sự tôn trọng lành mạnh đối với những điều chưa biết, vốn chỉ xuất hiện khi lý thuyết gặp phải các phiên bản thư viện, các trường hợp biên (edge cases) và thực tế của hành vi đa nền tảng.

Khởi tạo monorepo không chỉ đơn thuần là một lệnh git init mang tính thủ tục. Nó thiết lập cấu trúc vật lý sẽ phản chiếu kiến trúc logic. Nơi các gói (packages) cư ngụ, cách chúng phụ thuộc lẫn nhau và ranh giới giữa các lớp (layers) nằm ở đâu sẽ là sự phản chiếu của nhiều tuần lập kế hoạch. Nếu được thực hiện tốt, cấu trúc thư mục và quy trình xây dựng (build pipeline) đầu tiên sẽ dẫn dắt các đóng góp trong tương lai. Nếu làm không tốt, chúng sẽ âm thầm trừng phạt mọi lập trình viên chạm vào dự án trong nhiều năm tới.

Bài học thực sự

Kinh nghiệm của Paardekam đi ngược lại với "sùng bái tốc độ" đang thống trị phần lớn văn hóa phần mềm hiện đại. Có một áp lực khổng lồ về việc phải phát hành nhanh, cho thấy sự tăng trưởng và để mã nguồn thay thế cho việc thảo luận. Nhưng một số dự án, đặc biệt là những dự án được định hướng để tồn tại lâu dài, sẽ đền đáp sự kiên nhẫn. Kỷ luật trong việc xác định tầm nhìn, lập bản thiết kế và thiết kế hệ thống trước khi bạn khai báo các biến là một lời khuyên cũ nhưng chưa bao giờ lỗi thời.

Nếu bạn đang ấp ủ một ý tưởng và đang rất muốn mở trình soạn thảo mã nguồn, hãy cân nhắc xem liệu vài ngày thiết kế có tính toán kỹ lưỡng có thể giúp bạn tiết kiệm hàng tháng trời làm lại một cách rời rạc hay không. Cảm giác hưng phấn (dopamine) khi một ứng dụng chạy được sẽ phai nhạt. Sự rõ ràng của một kiến trúc tốt sẽ tạo ra giá trị cộng dồn. Hãy bắt đầu bằng việc biết chính xác bạn đang xây dựng cái gì và tại sao. Việc gõ phím có thể chờ sau.