The Impact of Business Justifications (ผลกระทบของการให้เหตุผลทางธุรกิจ)

หนึ่งในผู้เขียนหนังสือเล่มนี้เคยเป็นหัวหน้าสถาปนิกในโครงการที่ใช้ Java ซึ่งซับซ้อนเป็นพิเศษและมีทีมพัฒนาขนาดใหญ่ สมาชิกในทีมคนหนึ่ง หลงใหลในภาษาโปรแกรม Scala และอยากใช้มันในโครงการนี้อย่างมาก ความต้องการใช้ Scala ของเขากลายเป็นเรื่องที่สร้างความปั่นป่วนจนสมาชิกทีมหลัก สองคนประกาศว่าจะออกจากโครงการไปหาสภาพแวดล้อมอื่นที่ "เป็นพิษน้อยกว่า" ผู้เขียนของเราจึงโน้มน้าวให้พวกเขาชะลอการตัดสินใจไว้ก่อน จากนั้นเขาก็บอกกับคนที่หลงใหล Scala ว่าเขาจะสนับสนุนการใช้ Scala ในโครงการ ถ้า คนหลงใหลคนนั้นสามารถให้เหตุผลทางธุรกิจสำหรับค่าใช้จ่ายในการฝึกอบรมและการเขียนโค้ดใหม่ที่เกี่ยวข้องได้ คนหลงใหล Scala ดีใจมากและบอกว่า จะรีบไปทำทันที เขาออกจากห้องประชุมพร้อมตะโกนว่า "ขอบคุณครับ คุณเจ๋งที่สุด!"

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

อีกวิธีที่ดีในการสื่อสารหลักการออกแบบคือผ่านการอธิบายด้วยภาพว่าการตัดสินใจใดที่ทีมพัฒนาสามารถทำเองได้ และการตัดสินใจใดที่ทำไม่ได้ กราฟิกใน Figure 24-11 แสดงตัวอย่างว่าสิ่งนี้อาจมีหน้าตาอย่างไรสำหรับการควบคุม layered stack

Figure 24-11. การให้คำแนะนำสำหรับ layered stack

หมวดหมู่เหล่านี้เป็นเพียงตัวอย่าง แต่สามารถกำหนดเพิ่มเติมได้อีกมาก เมื่อนำเสนอ Figure 24-11 ให้ทีม สถาปนิกควรนำแต่ละหมวดหมู่ไปใช้กับไลบรารีจากบุคคลที่สามที่เสนอให้ใช้:

Special purpose (เฉพาะทาง)

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

General purpose (ใช้งานทั่วไป)

ไลบรารีเหล่านี้เป็น wrapper อยู่บน API ของภาษา และรวมถึงสิ่งต่างๆ เช่น Apache Commons และ Guava สำหรับ Java

Framework (เฟรมเวิร์ก)

ไลบรารีเหล่านี้ใช้สำหรับสิ่งต่างๆ เช่น persistence (เช่น Hibernate) และ inversion of control (เช่น Spring) กล่าวอีกนัยหนึ่งคือ มันประกอบกันเป็นเลเยอร์หรือโครงสร้างทั้งหมดของแอปพลิเคชัน และมีความล้ำลึกเข้าไปในระบบมาก

ต่อไป สถาปนิกจะสร้าง "ห้อง" รอบๆ หลักการออกแบบนี้ สังเกตได้ใน Figure 24-11 ว่าสถาปนิกได้อนุญาตให้นักพัฒนาตัดสินใจเรื่องไลบรารีเฉพาะทางได้เองโดยไม่ต้องปรึกษาสถาปนิก สำหรับไลบรารีใช้งานทั่วไป แม้นักพัฒนาจะสามารถวิเคราะห์ความซ้ำซ้อน ให้เหตุผล และเสนอคำแนะนำได้ แต่หมวดหมู่ไลบรารีนี้ต้องได้รับการอนุมัติจากสถาปนิก สุดท้าย ไลบรารีประเภทเฟรมเวิร์กเป็นความรับผิดชอบของสถาปนิกทั้งหมด ทีมพัฒนาไม่ควรแม้แต่จะวิเคราะห์ไลบรารีประเภทนี้เลยด้วยซ้ำ