วิธีปรับโครงสร้างใหม่สำหรับ Startups 2022: เหตุผลและการแลกเปลี่ยน

(ข้ามโพสต์จากเว็บไซต์ Klotho )

โพสต์บล็อกนี้เป็นภาพรวมระดับสูงเกี่ยวกับเหตุผลในการปรับโครงสร้างโค้ดและระบบในการตั้งค่าเริ่มต้น เราจะพูดถึงความเสี่ยง แนวทาง และการแลกเปลี่ยนที่ต้องพิจารณาในปี 2565

วิธีตัดสินเมื่อต้นทุนคุ้มกับกำไร

ซื่อสัตย์กับตัวเอง

สิ่งล่อใจคือการรีแฟคเตอร์เสมอ: โค้ดในโลกแห่งความจริงนั้นยุ่งเหยิง และวิศวกรไม่ชอบโค้ดที่ยุ่งเหยิง ตรวจสอบให้แน่ใจว่ามีกรณีธุรกิจสำหรับการปรับโครงสร้างใหม่โดยการวัดระยะเวลาที่ทีมใช้ไปกับคุณลักษณะที่ลูกค้ามองเห็นได้โดยตรง

การวิจัยของเราแสดงให้เห็นว่าบริษัทขนาดกลางและสตาร์ทอัพที่เติบโตอย่างรวดเร็วใช้ความสามารถด้านวิศวกรรม 39% ไปกับงานที่ไม่สร้างความแตกต่าง เช่น โครงสร้างพื้นฐาน แบ่งเรื่องราวออกเป็นงานย่อย เช่น โครงสร้างพื้นฐานและการปรับโครงสร้างใหม่ เพื่อให้คุณสามารถวัดได้ว่าเวลาของคุณกำลังจะไปไหน

โครงสร้างที่ดีได้รับการบำรุงรักษาอย่างดี

ขอบเขตที่ชัดเจนระหว่างโมดูลช่วยให้ทดสอบ ปรับใช้ และตรวจสอบได้ง่ายขึ้น จับตาดูข้อบกพร่องที่ลูกค้ารายงาน เวลาแฝงของบริการ และความถี่ที่คุณต้องเปลี่ยนรหัสกลับ อีกด้านหนึ่งของวงจรชีวิตซอฟต์แวร์ มีตัวบ่งชี้หลายตัวที่คุณกำลังมีแนวโน้มว่าจะเกิดปัญหาคอขวด: ใช้เวลานานแค่ไหนในการออกแบบจนถึงการจัดส่ง ระดับความพึงพอใจด้านวิศวกรรม และต้นทุนโครงสร้างพื้นฐานที่เพิ่มขึ้น — สิ่งเหล่านี้สามารถเป็นตัวบ่งชี้หลักได้ ที่คุณสร้างหนี้ไว้

จุดเปลี่ยนในธุรกิจ

ฐานรหัสมีแนวโน้มที่จะจัดระเบียบตัวเองในสามมิติ: ขนาดทีม ก้าวของคุณสมบัติใหม่ และจำนวนลูกค้า เมื่อตัวเลขเหล่านี้เปลี่ยนไปอย่างมาก อาจถึงเวลาที่ต้องแยกส่วนประกอบออกจากกัน

หากคุณกำลังขยายทีมหรือเพิ่มอัตราการพัฒนาฟีเจอร์ ปัจจัยที่จำกัดคือความสามารถในการอ่านโค้ด เริ่มด้วยการปรับโครงสร้างใหม่ตามเป้าหมายและฉวยโอกาส หากฐานลูกค้าของคุณเติบโตขึ้น คุณอาจต้องการเทคโนโลยีหรือเวิร์กโฟลว์ที่ปรับขนาดได้มากขึ้น

ควบคุมสิ่งที่คุณทำได้ วางแผนสำหรับส่วนที่เหลือ

การเลือกที่ถูกต้องจะไม่ขัดขวางการสร้างใหม่

การ Refactoring และ Re-architecture ไม่ได้หมายความว่าคุณเลือกผิดก่อนหน้านี้ บ่อยครั้ง แรงผลักดันที่อยู่เบื้องหลังการปรับสถาปัตยกรรมใหม่นั้นเชื่อมโยงกับการเปลี่ยนแปลงข้อกำหนดหรือปัจจัยภายนอก มีมิติสำคัญอย่างน้อย 4 ประการที่จะบังคับให้ต้องสร้างสถาปัตยกรรมใหม่ตลอดอายุการใช้งานของผลิตภัณฑ์ ได้แก่ อัตราการพัฒนาฟีเจอร์ใหม่ ขนาดทีมวิศวกร ระยะเวลาที่ใช้ในงานที่ไม่แตกต่าง และการเติบโตของลูกค้า สิ่งเหล่านี้ยากขึ้นเรื่อย ๆ ในการควบคุมโดยตรง

เริ่มต้นด้วยการหมุนหมายเลขง่าย...

สำหรับสี่มิติ สองสิ่งที่ควบคุมได้ง่ายที่สุดคืออัตราของคุณสมบัติใหม่และขนาดทีมวิศวกร คุณสามารถควบคุมอัตราของคุณสมบัติใหม่ได้โดยเข้มงวดมากขึ้นเกี่ยวกับการวางแผนและการจัดลำดับความสำคัญ การขยายทีมเป็นกระบวนการที่ช้ากว่า แต่โดยปกติแล้วคุณสามารถวางแผนได้

หากทั้งทีมและอัตราของคุณสมบัติใหม่มีขนาดเล็ก การปรับโครงสร้างใหม่ก็ไม่น่าจะส่งผลกระทบอย่างมีนัยสำคัญต่อธุรกิจ ในอีกด้านของสเปกตรัม ทีมขนาดใหญ่ที่ทำงานเกี่ยวกับคุณลักษณะหลายอย่างอาจได้รับประโยชน์จากการจัดโครงสร้างใหม่ให้เป็นทีมขนาดเล็ก — และคุณควรพิจารณาการปรับโครงสร้างใหม่หรือวางโครงสร้างโค้ดใหม่เพื่อให้สอดคล้องกัน สถาปัตยกรรมที่ช่วยให้ขอบเขตองค์กรและโค้ดสะอาดขึ้นจะทำให้ผลิตภัณฑ์และบริษัทปรับขนาดได้

…จากนั้นไปยังสิ่งที่ยากขึ้น

ระยะเวลาที่ทีมของคุณใช้ไปกับงานที่ไม่แตกต่างอาจเป็นเรื่องยากที่จะควบคุม และการเติบโตของลูกค้าก็เป็นมาตรการที่ยากที่สุดในบรรดาทั้งหมดที่จะส่งผลกระทบ หากสิ่งเหล่านี้เป็นเรื่องง่าย ทุกคนจะลดงานที่ไม่แตกต่างและเพิ่มการเติบโตของลูกค้าให้ได้มากที่สุด! คุณยังทำได้

นำหน้าปัญหาด้วยวิธีการปรับโครงสร้างใหม่อย่างระมัดระวังและเชิงรุก

ขั้นตอนแรกคือการรู้ว่าเมื่อใดไม่ควรปรับโครงสร้างใหม่ หากการเติบโตของลูกค้าและระยะเวลาที่ใช้ไปกับงานที่ไม่สร้างความแตกต่างมีน้อย อย่าใช้เวลาในการปรับโครงสร้างใหม่: ให้เน้นที่คุณลักษณะที่สร้างผลกระทบและมองเห็นได้ของลูกค้าแทน ในทำนองเดียวกัน หากคุณมีการเติบโตของลูกค้าที่ดีและมีปริมาณงานที่ไม่แตกต่างกันต่ำ ทีมของคุณก็ทำได้ดี พิจารณาการปรับโครงสร้างทางยุทธวิธีเพื่อหลีกเลี่ยงไม่ให้ปริมาณงานที่ไม่แตกต่างเพิ่มขึ้น แต่อย่าใช้เวลากับมันมากเกินไป

หากทีมของคุณใช้เวลามากเกินไปกับงานที่ไม่สร้างความแตกต่าง ถึงเวลาแล้วที่จะต้องทบทวนสถาปัตยกรรมอีกครั้งเพื่อปรับขนาดให้ดีขึ้นเพื่อให้บริษัทของคุณอยู่ในทุกวันนี้

หากการยอมรับของลูกค้าต่ำกว่า ลำดับความสำคัญของคุณควรเป็นสถาปัตยกรรมที่ถูกกว่าซึ่งจะทำให้คุณมีทางวิ่งมากขึ้น
หากทั้งการยอมรับของลูกค้าและระยะเวลาที่ทีมของคุณใช้กับงานที่ไม่แตกต่างนั้นสูง อาจถึงเวลาแล้วที่จะต้องมุ่งเน้นไปที่โซลูชันที่รวมศูนย์และปรับให้เหมาะสมที่สุด โดยทั่วไปจะอยู่ในรูปแบบของทีมปฏิบัติการเฉพาะที่สามารถดำเนินงานโครงสร้างพื้นฐานได้อย่างมีประสิทธิภาพ นี่เป็นปัญหาใหญ่ที่เกิดขึ้น ดังนั้นใช้เวลาสักครู่เพื่อแสดงความยินดีกับตัวคุณเองและทีมของคุณที่มาที่นี่!

มีเป้าหมายแล้วหาทางลัดเพื่อไปให้ถึง

มีแผนแม้ว่าจะไม่สมบูรณ์แบบ

เมื่อคุณมุ่งมั่นที่จะปรับปรุงสถาปัตยกรรมใหม่แล้ว อย่ากลัวที่จะคิดการใหญ่ พึ่งพาวิศวกรของคุณเพื่อกำหนดสถานะสุดท้ายที่พวกเขาต้องการ จากนั้นลดขนาดลงตามความจำเป็น โอกาสที่โอกาสในการเปลี่ยนสถาปัตยกรรมครั้งใหญ่จะเกิดขึ้นเพียงครั้งหรือสองครั้งในวงจรอายุของผลิตภัณฑ์ ดังนั้นจงเตรียมพร้อมที่จะรับมือกับการประนีประนอมใดๆ ที่คุณทำ แต่ในขณะเดียวกัน ให้รู้ว่าแม้แต่แผนการที่ดีที่สุดก็ยังผิดพลาดได้เมื่อคุณเริ่มนำไปใช้

วางแผนการใหญ่ ทำตามขั้นตอนเล็กน้อย

เมื่อคุณทราบตำแหน่งที่คุณต้องการให้รหัสมีกลยุทธ์เกี่ยวกับวิธีนำรหัสไปไว้ที่นั่น ทำงานทีละหนึ่งส่วนประกอบ หรือเลือกส่วนประกอบที่อยู่ห่างจากกันมากที่สุด หากคุณยังไม่ได้ลงทุนในการทดสอบที่มั่นคง ทั้งในระดับหน่วยและระบบ ตอนนี้ถึงเวลาแล้ว การทดสอบจะทำให้คุณมั่นใจได้ว่าการเปลี่ยนแปลงของคุณจะไม่ทำลายประสบการณ์ของลูกค้าที่มีอยู่ แต่ยังช่วยทีมของคุณหาคำจำกัดความของคำว่าเสร็จสิ้นได้อีกด้วย เมื่อการทดสอบผ่าน ส่วนประกอบก็พร้อม!

เทคโนโลยีที่ดีที่สุดคือเทคโนโลยีที่คุณสามารถปรับใช้ได้

กุญแจสำคัญในการลดผลกระทบของการปรับโครงสร้างใหม่และการออกแบบสถาปัตยกรรมใหม่โดยเฉพาะกับสตาร์ทอัพคือการใช้เทคโนโลยีที่สามารถปรับเปลี่ยนได้

ในอดีต บริษัทต่างๆ เลือกใช้เทคโนโลยีเฉพาะ เช่น VM, ไร้เซิร์ฟเวอร์ หรือคอนเทนเนอร์เพื่อโฮสต์แอปพลิเคชันของตน ปัญหาคือการเปลี่ยนจากเทคโนโลยีหนึ่งไปเป็นอีกเทคโนโลยีหนึ่งนั้นมีราคาแพง และสิ่งที่คุณต้องการในวันนี้อาจไม่ใช่สิ่งที่คุณต้องการในวันพรุ่งนี้

สถาปัตยกรรมที่ปรับเปลี่ยนได้คือสถาปัตยกรรมที่ให้คุณโฮสต์แอปพลิเคชันของคุณบนเทคโนโลยีใดๆ ก็ตามอย่างง่ายดาย ซึ่งช่วยให้คุณปรับสภาพแวดล้อมการโฮสต์ได้ทันที เพื่อให้ตรงกับความต้องการในปัจจุบันของคุณ ตัวเลือกเทคโนโลยีเฉพาะ เช่น AWS Lambda, Fargate, Kubernetes, gRPC, Linkerd, Azure/GCP สามารถใช้แทนกันได้

การนำโครงสร้างภาษาการเขียนโปรแกรมที่มีอยู่กลับมาใช้ใหม่ เช่น ฟังก์ชันและตัวจัดการเหตุการณ์ รวมถึงอินเทอร์เฟซที่ตรงกับแต่ละภาษา สถาปัตยกรรมแบบปรับเปลี่ยนได้ทำให้บริการคลาวด์ใช้งานง่ายขึ้น

มองหาสิ่งที่เป็นนามธรรมและเครื่องมือที่มีน้ำหนักเบา แต่ยืดหยุ่นพอที่จะให้คุณเปลี่ยนเทคโนโลยีได้ เราคิดว่าคำอธิบายประกอบของ Klotho เหมาะสมกับการเรียกเก็บเงิน เนื่องจากช่วยให้คุณแยกความหมายเชิงความหมายของสถาปัตยกรรมของคุณออกจากการกำหนดค่าการปรับใช้ — แต่ด้วยการลงทุนที่เพียงพอในไลบรารีรันไทม์และระบบอัตโนมัติของโครงสร้างพื้นฐาน คุณจะสามารถสร้างโซลูชันที่คล้ายกันได้ด้วยตนเอง