ทุกโปรเจกต์ใหม่มักจะกระซิบคำเชิญชวนเดิมๆ: เปิดเอดิเตอร์ เลือกเฟรมเวิร์ก แล้วเริ่มพิมพ์ สำหรับ MaxOS ผู้สร้างอย่าง Max Paardekam รู้สึกถึงแรงดึงดูดนั้นอย่างรุนแรง เมื่อไม่กี่สัปดาห์ก่อน โปรเจกต์นี้เป็นเพียงไอเดียที่กระจัดกระจายอยู่ในโน้ตของเขา สัญชาตญาณแรกของเขาคือการใช้เวลาชั่วโมงแล้วชั่วโมงเล่าเขียน TypeScript ใน Cursor ปล่อยให้ความจำกล้ามเนื้อ (muscle memory) และระบบเติมคำอัตโนมัติ (autocomplete) สร้างแรงขับเคลื่อน แต่เขาขัดขืนมัน แทนที่จะเขียนโค้ดแอปพลิเคชัน เขากลับสร้างสิ่งที่หาได้ยากกว่าและเปราะบางกว่า นั่นคือสถาปัตยกรรมที่เสร็จสมบูรณ์
ในตอนแรก การตัดสินใจนั้นให้ความรู้สึกเหมือนการหยุดนิ่ง เมื่อเครื่องมือต่างๆ พร้อมใช้งานและ boilerplate ก็ติดตั้งเสร็จในไม่กี่วินาที การหยุดเพื่อวาดกล่องและลูกศรอาจดูเป็นเรื่องไร้สาระ แต่ MaxOS ไม่ได้ถูกสร้างมาเพื่อเป็นเพียง Electron wrapper รอบ web view อีกตัวหนึ่ง เป้าหมายคือการสร้างบางสิ่งที่สามารถอยู่รอดผ่านการใช้งาน การทำ refactoring และการขยายตัวได้นานหลายปี ระบบที่มีอายุการใช้งานยาวนานขนาดนั้นต้องการสิ่งที่ลึกซึ้งกว่าการเริ่มต้นอย่างรวดเร็ว พวกมันต้องการความคิดที่สอดประสานกันก่อนที่จะเริ่มเขียนคำสั่ง import แรกเสียด้วยซ้ำ
ทำไม IDE ถึงรอได้
สภาพแวดล้อมการพัฒนาในปัจจุบันทำให้เส้นแบ่งระหว่างการวางแผนและการลงมือทำนั้นเลือนลาง Cursor และเอดิเตอร์ที่ช่วยด้วย AI อื่นๆ ทำให้เราสามารถสร้างคอมโพเนนต์ทั้งชุดได้จากเพียงแค่คอมเมนต์เดียว วงจรการตอบสนอง (feedback loop) นั้นเกิดขึ้นทันที และความรู้สึกฟิน (dopamine hit) จากการได้เห็น UI ปรากฏขึ้นมานั้นยากที่จะต้านทาน Paardekam เริ่มต้นด้วยสมมติฐานแบบนั้นพอดีว่า พลังงานส่วนใหญ่ในช่วงแรกของเขาจะไหลไปสู่ไฟล์ TypeScript โดยตรง แต่เขาก็ค่อยๆ เปลี่ยนทิศทางของวันเหล่านั้นไปสู่การทำงานด้านการออกแบบล้วนๆ
นี่คือการเปลี่ยนทิศทางที่ยากลำบากสำหรับนักพัฒนาเดี่ยว (solo builder) เมื่อคุณเป็นทีมวิศวกรทั้งทีม ทุกชั่วโมงที่ใช้ไปกับเครื่องมือวาดไดอะแกรมหรือเอกสารข้อความจะรู้สึกเหมือนเป็นชั่วโมงที่ถูกขโมยไปจากการส่งมอบงาน (shipping) แต่โค้ดในช่วงแรกมักจะเป็นภาระที่ปลอมตัวมาในคราบของความคืบหน้า ความแปลกใหม่ของโปรโตไทป์ที่ทำงานได้จะหายไปอย่างรวดเร็ว เมื่อทุกฟีเจอร์ใหม่ต้องมานั่งแก้ปัญหา (hacking) รอบๆ สมมติฐานที่ถูกฝังไว้ตั้งแต่ช่วงบ่ายวันแรก การบังคับตัวเองให้ออกห่างจากเอดิเตอร์ ทำให้ Paardekam ได้รับสินทรัพย์เพียงอย่างเดียวที่เพิ่มพูนขึ้นตามกาลเวลา นั่นคือ ความชัดเจน
คิดแบบระบบ ไม่ใช่แค่ฟีเจอร์
การเปลี่ยนแปลงที่สำคัญที่สุดในช่วงหลายสัปดาห์นี้ไม่ใช่เรื่องทางเทคนิค แต่เป็นเรื่องของกระบวนการคิด สถาปัตยกรรมซอฟต์แวร์เมื่อพิจารณาอย่างจริงจัง จะเปลี่ยนวิธีที่คุณตั้งคำถาม Paardekam เลิกเข้าหาโปรเจกต์ด้วยแนวคิดแบบเน้นฟีเจอร์ เขาไม่ได้ถามอีกต่อไปว่าจะเพิ่มความสามารถเฉพาะอย่างเข้าไปได้อย่างไร แต่เขากลับเผชิญกับคำถามที่ยากกว่านั้น: โครงสร้างพื้นฐานแบบไหนที่จะทำให้การเพิ่มความสามารถทุกอย่างในอนาคตทำได้ง่ายขึ้น?
ความแตกต่างนั้นสำคัญมาก แนวคิดแบบฟีเจอร์จะมองซอฟต์แวร์เหมือนรายการสิ่งที่ต้องทำ (to-do list) คุณทำระบบค้นหา ตามด้วยการแจ้งเตือน แล้วก็ปุ่มส่งออก แต่แนวคิดแบบระบบจะถามว่า ระบบค้นหา การแจ้งเตือน และการส่งออก จะสามารถใช้โมเดลข้อมูลเดียวกัน, event bus เดียวกัน และเลเยอร์การอนุญาต (permission layer) เดียวกันได้อย่างไร มันหมายถึงการออกแบบไวยากรณ์ของแอปพลิเคชันก่อนที่จะเริ่มเขียนประโยค ต้นทุนในช่วงแรกอาจจะสูงกว่า แต่ผลตอบแทนคือ งานในอนาคตจะไม่รู้สึกเหมือนการประกอบชิ้นส่วน แต่จะรู้สึกเหมือนการรังสรรค์ (composition)
สิ่งนี้สำคัญอย่างยิ่งสำหรับโปรเจกต์อย่าง MaxOS ซึ่งมีเป้าหมายที่จะรวมฟังก์ชันต่างๆ ที่ปกติจะอยู่ในแอปพลิเคชันที่แตกต่างกันถึงสิบแอปฯ เข้าด้วยกัน การรวมกันอย่างแนบแน่นโดยปราศจากความคิดเชิงระบบจะกลายเป็นฝันร้ายของสะพานเชื่อมที่เปราะบางและสถานะ (state) ที่ไม่สอดคล้องกัน แต่หากมีมัน พื้นที่ทำงาน (workspace) จะทำงานเหมือนสิ่งมีชีวิตหนึ่งเดียว แทนที่จะเป็นเพียงการรวมกลุ่มของเครื่องมือที่นำมาปะติดปะต่อกัน
พื้นที่ทำงาน ไม่ใช่ระบบปฏิบัติการ
Paardekam พูดอย่างตรงไปตรงมาเกี่ยวกับขอบเขตของความทะเยอทะยานของเขา MaxOS จะไม่มาแทนที่ Windows หรือ macOS มันไม่ได้มุ่งหวังที่จะจัดการไดรเวอร์, การจัดสรรหน่วยความจำ หรือเลเยอร์การแยกส่วนฮาร์ดแวร์ (hardware abstraction layers) เป้าหมายของมันคือสิ่งที่ใกล้ชิดกว่านั้น นั่นคือ พื้นที่ทำงาน (workspace)
คนทำงานสายความรู้ (knowledge workers) ส่วนใหญ่ใช้ชีวิตอยู่ในสภาพแวดล้อมที่แตกแยก คุณต้องสลับไปมาระหว่างอีเมลกับปฏิทิน จากแอปโน้ตไปที่เทอร์มินัล จากเครื่องมือออกแบบไปที่แพลตฟอร์มส่งข้อความ ทุกการสลับสร้างความติดขัด (friction) บริบทสูญหาย ความสนใจกระจัดกระจาย ระบบปฏิบัติการเป็นเพียงเวที แต่ไม่ได้เป็นผู้กำกับการแสดง
MaxOS ตั้งใจที่จะรวมประสบการณ์นั้นให้เป็นหนึ่งเดียวในสภาพแวดล้อมที่เข้าใจลำดับขั้นตอนการทำงานของคุณ และช่วยให้คุณเคลื่อนที่ได้เร็วขึ้นอย่างจริงจัง นั่นเป็นความท้าทายทางวิศวกรรมที่แตกต่างจากการสร้าง OS แบบดั้งเดิม มันต้องอาศัยความเข้าใจอย่างลึกซึ้งต่อเวิร์กโฟลว์ (workflows) การตัดขอบเขตงานอย่างเด็ดขาด และอินเทอร์เฟซที่ปรับตัวตามความต้องการของผู้ใช้ แทนที่จะบังคับให้ผู้ใช้ต้องปรับตัวเข้าหาเครื่องมือ การแทนที่พื้นที่ทำงานหมายถึงการแทนที่นิสัย และนิสัยจะเปลี่ยนก็ต่อเมื่อทางเลือกใหม่ให้ความรู้สึกที่ผ่อนคลายมากกว่าที่จะเป็นภาระในการเรียนรู้
สิ่งที่ถูกสร้างขึ้นในช่วงสัปดาห์ที่เงียบสงบ
ช่วงการวางสถาปัตยกรรมของ Paardekam ให้ผลลัพธ์ที่เป็นรูปธรรมสองอย่าง อย่างแรกคือการกำหนดวิสัยทัศน์และพันธกิจที่ชัดเจน นี่ไม่ใช่แค่คำโฆษณาที่สวยหรู สำหรับผู้ก่อตั้งสายเทคนิคที่ลุยเดี่ยว สิ่งนี้ทำหน้าที่เป็นเกราะป้องกันขอบเขตงาน (scope) ที่ดีที่สุด เมื่อคุณต้องตัดสินใจว่าจะเพิ่มแถบด้านข้างสำหรับแชทหรือตลาดปลั๊กอิน (plugin marketplace) คำแถลงพันธกิจจะเป็นตัวตัดสินว่าจะรับมันเข้ามาหรือตัดมันทิ้งไป อย่างที่สองคือเขาได้จัดทำพิมพ์เขียวโครงการ (project blueprint) ที่สมบูรณ์
การได้เห็นแผนงานทั้งหมดตั้งแต่ต้นจนจบช่วยเปลี่ยนสภาวะทางจิตวิทยาของโครงการ ไอเดียในสมุดบันทึกให้ความรู้สึกเหมือนเป็นเพียงสมมติฐาน แต่พิมพ์เขียวให้ความรู้สึกว่ามันต้องเกิดขึ้นจริงอย่างแน่นอน มันช่วยเผยให้เห็นช่องว่างในขณะที่ต้นทุนในการแก้ไขยังต่ำอยู่ และเผยให้เห็นว่าความเสี่ยงที่ยากที่สุดซ่อนอยู่ตรงไหน ในขั้นตอนนี้ เอกสารที่แม่นยำมีความสำคัญมากกว่าบรรทัดของโค้ดอย่างแท้จริง โค้ดสามารถทำ refactor ได้ แต่สมมติฐานที่คลุมเครือจะกลายเป็นหนี้ทางเทคนิค (technical debt) ที่แข็งตัวจนการแก้บั๊ก (debugging) ยามดึกแค่ไหนก็ไม่สามารถสลายมันได้
จากกระดาษสู่ Monorepo
เมื่อสถาปัตยกรรมเสร็จสิ้น ระยะต่อไปก็ได้เริ่มต้นขึ้น Paardekam กำลังเปลี่ยนจากเอกสารไปสู่โค้ด โดยเริ่มจากการเริ่มต้นใช้งาน (initialization) monorepo การเปลี่ยนผ่านนี้มาพร้อมกับความกังวลในตัวมันเอง พิมพ์เขียวคือคำสัญญา แต่ codebase คือข้อพิสูจน์ เขายอมรับว่ารู้สึกประหม่าว่าการออกแบบจะยังคงใช้ได้หรือไม่เมื่อต้องเผชิญกับการลงมือทำจริง (implementation) ความซื่อสัตย์นั้นสะท้อนถึงความเคารพต่อสิ่งที่ไม่รู้ ซึ่งจะปรากฏขึ้นก็ต่อเมื่อทฤษฎีต้องมาเจอกับเวอร์ชันของ library, กรณีขอบเขต (edge cases) และความเป็นจริงของพฤติกรรมแบบ cross-platform
การเริ่มต้น monorepo เป็นมากกว่าแค่การทำ git init ตามพิธีการ มันเป็นการกำหนดโครงสร้างทางกายภาพที่จะสะท้อนถึงสถาปัตยกรรมเชิงตรรกะ (logical architecture) ตำแหน่งที่ package ต่างๆ อยู่, วิธีที่พวกมันพึ่งพากัน และขอบเขตระหว่างชั้น (layers) จะเป็นภาพสะท้อนของการวางแผนตลอดหลายสัปดาห์ที่ผ่านมา หากทำได้ดี โครงสร้างโฟลเดอร์และ build pipeline ชุดแรกจะช่วยนำทางในการพัฒนาต่อในอนาคต แต่หากทำได้แย่ สิ่งเหล่านี้จะลงโทษนักพัฒนาทุกคนที่แตะต้องโครงการนี้อย่างเงียบๆ ไปอีกหลายปี
บทเรียนที่แท้จริง
ประสบการณ์ของ Paardekam ขัดแย้งกับลัทธิแห่งความเร็ว (cult of velocity) ที่ครอบ