หัวข้อที่ถกเถียงกันเป็นประจำในโปรเจกต์พัฒนา software คือ การเลือกระหว่างการใช้เวลาเพื่อปรับปรุงคุณภาพของ software กับการทุ่มเทไปกับการปล่อย feature ที่มีมูลค่าเพิ่มขึ้น โดยปกติแล้ว แรงกดดันในการส่งมอบ function การทำงานมักจะครอบงำการสนทนา ทำให้นักพัฒนาหลายคนบ่นว่าพวกเขาไม่มีเวลาทำงานด้านสถาปัตยกรรม (architecture) และคุณภาพของ code
กฎของ Betteridge เกี่ยวกับพาดหัวข่าว (Betteridge's Law of headlines) เป็นสุภาษิตที่กล่าวว่า บทความใดก็ตามที่มีพาดหัวข่าวหรือชื่อเรื่องที่ลงท้ายด้วยเครื่องหมายคำถาม สามารถสรุปได้ด้วยคำว่า ไม่ สำหรับผู้ที่รู้จักผมคงไม่สงสัยในความปรารถนาของผมที่จะแหกกฎดังกล่าว แต่บทความนี้ไปไกลกว่านั้น—มันแหกตัวคำถามเองเสียเลย คำถามนี้ตั้งอยู่บนสมมติฐานที่ว่ามีการแลกเปลี่ยน (trade-off) ทั่วไปมาระหว่างคุณภาพและต้นทุน แต่ในบทความนี้ผมจะอธิบายว่าการแลกเปลี่ยนนี้ไม่ได้ใช้กับ software—ว่า software คุณภาพสูงนั้นจริงๆ แล้วมีต้นทุนการผลิตที่ถูกกว่า
แม้ว่างานเขียนส่วนใหญ่ของผมจะมุ่งเป้าไปที่นักพัฒนา software มืออาชีพ แต่สำหรับบทความนี้ ผมจะไม่ถือว่าผู้อ่านมีความรู้เกี่ยวกับกลไกของการพัฒนา software เลย ผมหวังว่านี่จะเป็นบทความที่มีคุณค่าสำหรับทุกคนที่เกี่ยวข้องกับการคิดเกี่ยวกับความพยายามด้าน software โดยเฉพาะอย่างยิ่งผู้ที่เป็นผู้นำธุรกิจที่ทำหน้าที่เป็นลูกค้าของทีมพัฒนา software
เราคุ้นเคยกับการแลกเปลี่ยนระหว่างคุณภาพและต้นทุน
อย่างที่ผมกล่าวไปในตอนต้น เราทุกคนคุ้นเคยกับการแลกเปลี่ยนระหว่างคุณภาพและต้นทุน เมื่อผมเปลี่ยนสมาร์ทโฟนเครื่องใหม่ ผมสามารถเลือกรุ่นที่แพงกว่าพร้อม process เซอร์ที่เร็วกว่า หน้าจอที่ดีกว่า และหน่วยความจำที่มากกว่า หรือผมสามารถยอมสละคุณภาพเหล่านั้นบางส่วนเพื่อจ่ายเงินให้น้อยลง มันไม่ใช่กฎที่ตายตัวเสมอไป บางครั้งเราอาจจะเจอของถูกและดี แต่ส่วนใหญ่มักจะเป็นความจริงที่ว่า คุณภาพที่สูงกว่ามักจะมาพร้อมกับราคาที่แพงกว่า
คุณภาพของ software มีความหมายหลายอย่าง
หากผมจะพูดถึงคุณภาพสำหรับ software ผมต้องอธิบายก่อนว่ามันคืออะไร นี่คือจุดที่เกิดความซับซ้อนประการแรก—มีหลายสิ่งหลายอย่างที่สามารถนับเป็นคุณภาพสำหรับ software ได้ ผมสามารถพิจารณาเรื่องส่วนต่อประสานกับผู้ใช้ (User Interface): มันนำพาผมไปสู่แผนงานที่ผมต้องทำได้อย่างง่ายดาย ทำให้ผมมีประสิทธิภาพมากขึ้นและขจัดความหงุดหงิดหรือไม่? ผมสามารถพิจารณาเรื่องความน่าเชื่อถือ (Reliability): มันมีข้อบกพร่องที่ทำให้เกิดข้อผิดพลาดและความหงุดหงิดหรือไม่? อีกแง่มุมหนึ่งคือสถาปัตยกรรม (Architecture): ซอร์ส code(source code) ถูกแบ่งออกเป็น module(modules) ที่ชัดเจน เพื่อให้นักโปรแกรมสามารถค้นหาและเข้าใจได้ง่ายหรือไม่ว่าพวกเขาต้องทำงานในส่วนไหนของ code ในสัปดาห์นี้?
ตัวอย่างคุณภาพทั้งสามนี้ไม่ใช่รายการที่ครอบคลุมทั้งหมด แต่ก็เพียงพอที่จะแสดงให้เห็นประเด็นสำคัญ หากผมเป็นลูกค้าหรือผู้ใช้ software ผมจะไม่เห็นคุณค่าของบางสิ่งที่เรียกได้ว่าคุณภาพไปเสียทุกอย่าง ผู้ใช้สามารถบอกได้ว่า UI นั้นดีหรือไม่ ผู้บริหารสามารถบอกได้ว่า software ทำให้พนักงานของเธอทำงานได้อย่างมีประสิทธิภาพมากขึ้นหรือไม่ ผู้ใช้และลูกค้าจะสังเกตเห็นข้อบกพร่อง (Defects) โดยเฉพาะอย่างยิ่งหากมันทำให้ข้อมูลเสียหายหรือทำให้ระบบใช้งานไม่ได้ชั่วขณะ แต่ลูกค้าและผู้ใช้ไม่สามารถรับรู้ถึง architecture ของ software ได้
ดังนั้นผมจึงแบ่งคุณลักษณะคุณภาพของ software ออกเป็น ภายนอก (External- เช่น UI และข้อบกพร่อง) และ ภายใน (Internal- สถาปัตยกรรม) ความแตกต่างคือ ผู้ใช้และลูกค้าสามารถมองเห็นสิ่งที่ทำให้ผลิตภัณฑ์ software มีคุณภาพภายนอกสูง แต่ไม่สามารถบอกความแตกต่างระหว่างคุณภาพภายในที่สูงหรือต่ำกว่าได้
เมื่อมองเพียงผิวเผิน คุณภาพภายในอาจดูเหมือนไม่สำคัญสำหรับลูกค้า
เนื่องจากคุณภาพภายในไม่ใช่สิ่งที่ลูกค้าหรือผู้ใช้สามารถมองเห็นได้—มันจะสำคัญไหม? ลองจินตนาการว่า Rebecca และผมเขียน application(application) เพื่อติดตามและทำนายความล่าช้าของเที่ยวบิน application ของเราทั้งคู่ทำหน้าที่เหมือนกันทุกประการ ทั้งคู่มี interface ผู้ใช้ (user interface) ที่หรูหราพอกัน และทั้งคู่แทบไม่มีข้อบกพร่องเลย ข้อแตกต่างเพียงอย่างเดียวคือ source code ภายในของเธอนั้นจัดระเบียบไว้อย่างประณีต ในขณะที่ของผมนั้นยุ่งเหยิงไปหมด ยังมีข้อแตกต่างอีกอย่างหนึ่งคือ: ผมขายแอปในราคา 6 ดอลลาร์ และเธอขายในราคา 10 ดอลลาร์
ในเมื่อลูกค้าไม่เคยเห็น source code นี้ และมันไม่ส่งผลต่อการทำงานของแอป ทำไมใครๆ ถึงต้องจ่ายเงินเพิ่มอีก 4 ดอลลาร์เพื่อซื้อ software ของ Rebecca? หากกล่าวโดยทั่วไป นี่ควรหมายความว่ามันไม่คุ้มที่จะจ่ายเงินมากขึ้นเพื่อคุณภาพภายในที่สูงกว่า
อีกวิธีหนึ่งที่ผมนำเสนอเรื่องนี้คือ มันมีเหตุผลที่จะแลกต้นทุนกับคุณภาพภายนอก แต่ไม่มีเหตุผลเลยที่จะแลกต้นทุนกับคุณภาพภายใน ผู้ใช้สามารถตัดสินได้ว่าพวกเขาต้องการจ่ายเงินมากขึ้นเพื่อให้ได้ UI ที่ดีขึ้นหรือไม่ เพราะพวกเขาสามารถประเมินได้ว่า UI นั้นดีพอที่จะคุ้มค่ากับเงินที่จ่ายเพิ่มหรือไม่ แต่ผู้ใช้ไม่สามารถเห็นโครงสร้าง module ภายในของ software ได้ ดังนั้นพวกเขาจึงตัดสินไม่ได้ว่ามันดีกว่าหรือไม่ แล้วทำไมต้องจ่ายแพงกว่าสำหรับสิ่งไม่มีผลลัพธ์ที่จับต้องได้? หากเป็นเช่นนั้น—ทำไมนักพัฒนา software จึงควรทุ่มเทเวลาและความพยายามในการปรับปรุงคุณภาพภายในงานของพวกเขา?
คุณภาพภายในทำให้การเพิ่มประสิทธิภาพ software ง่ายขึ้น
แล้วทำไมนักพัฒนา software ถึงให้ความสำคัญกับคุณภาพภายในนักล่ะ? โปรแกรมเมอร์ใช้เวลาส่วนใหญ่ไปกับการแก้ไข code แม้แต่ในระบบใหม่ การเขียนโปรแกรมเกือบทั้งหมดทำในบริบทของฐาน code(codebase) ที่มีอยู่แล้ว เมื่อผมต้องการเพิ่ม feature ใหม่ให้กับ software งานแรกของผมคือการค้นหาว่า feature นี้เข้ากับโฟลว์ (flow) ของ application ที่มีอยู่ได้อย่างไร จากนั้นผมจำเป็นต้องเปลี่ยนโฟลว์นั้นเพื่อให้ feature ของผมเข้าที่ ผมมักจะต้องใช้ข้อมูลที่มีอยู่แล้วใน application ดังนั้นผมจึงต้องเข้าใจว่าข้อมูลนั้นหมายถึงอะไร มันเกี่ยวข้องกับข้อมูลรอบข้างอย่างไร และข้อมูลใดที่ผมอาจต้องเพิ่มสำหรับ feature ใหม่
ทั้งหมดนี้คือการที่ผมต้องทำความเข้าใจ code ที่มีอยู่ แต่ software นั้นทำให้เข้าใจยากได้ง่ายมาก ตรรกะอาจจะยุ่งเหยิง ข้อมูลอาจจะติดตามได้ยาก ชื่อที่ใช้เรียกสิ่งต่างๆ อาจจะดูสมเหตุสมผลสำหรับ Tony เมื่อหกเดือนก่อน แต่กลับดูลึกลับสำหรับผมพอๆ กับเหตุผลที่เขาลาออก สิ่งเหล่านี้คือกองขยะที่เหล่านักพัฒนาเรียกว่า Cruft—ความแตกต่างระหว่าง code ปัจจุบันกับรูปแบบที่ควรจะเป็นในอุดมคติ
คำอุปมาที่พบบ่อยสำหรับ Cruft คือ หนี้ทางเทคนิค (Technical Debt) ต้นทุนที่เพิ่มขึ้นในการเพิ่ม feature เปรียบเสมือนการจ่ายดอกเบี้ย การทำความสะอาดกองขยะเปรียบเสมือนการจ่ายคืนเงินต้น แม้ว่ามันจะเป็นคำอุปมาที่มีประโยชน์ แต่มันก็สนับสนุนให้หลายคนเชื่อว่า Cruft นั้นวัดและควบคุมได้ง่ายกว่าที่เป็นจริงในทางปฏิบัติ
หนึ่งในคุณสมบัติหลักของคุณภาพภายในคือ การทำให้ผมเข้าใจได้ง่ายขึ้นว่า application ทำงานอย่างไร เพื่อที่ผมจะได้เห็นวิธีการเพิ่มสิ่งต่างๆ หาก software ถูกแบ่งออกเป็น module แยกกันอย่างสวยงาม ผมไม่จำเป็นต้องอ่าน code ทั้งหมด 500,000 บรรทัด ผมสามารถหา code ไม่กี่ร้อยบรรทัดในบาง module ได้อย่างรวดเร็ว หากเราทุ่มเทให้กับการตั้งชื่อที่ชัดเจน ผมสามารถเข้าใจส่วนต่างๆ ของ code ได้อย่างรวดเร็วโดยไม่ต้องปวดหัวกับรายละเอียด หากข้อมูลเป็นไปตามภาษาและโครงสร้างของธุรกิจนั้นๆ อย่างเหมาะสม ผมสามารถเข้าใจได้ง่ายว่ามันสัมพันธ์กับคำขอที่ผมได้รับจากเจ้าหน้าที่บริการลูกค้าอย่างไร Cruft จะเพิ่มเวลาที่ผมต้องใช้ในการทำความเข้าใจว่าจะทำการเปลี่ยนแปลงอย่างไร และยังเพิ่มโอกาสที่ผมจะทำผิดพลาด หากผมตรวจพบความผิดพลาด ก็จะเสียเวลาไปกับการทำความเข้าใจว่าความผิดปกติคืออะไรและจะแก้ไขอย่างไร หากผมตรวจไม่พบ เราก็จะได้ข้อบกพร่องในการใช้งานจริง และต้องเสียเวลาแก้ไขในภายหลังมากขึ้น
การเปลี่ยนแปลงของผมยังส่งผลต่ออนาคตด้วย ผมอาจเห็นวิธีที่รวดเร็วในการใส่ feature นี้ลงไป แต่มันเป็นเส้นทางที่ขัดต่อโครงสร้าง module ของโปรแกรม ซึ่งเป็นการเพิ่ม Cruft หากผมเลือกเส้นทางนั้น ผมจะทำให้งานของผมเร็วขึ้นในวันนี้ แต่จะทำให้ทุกคนที่ต้องจัดการกับ code นี้ในสัปดาห์และเดือนต่อๆ ไปช้าลง เมื่อสมาชิกคนอื่นๆ ในทีมตัดสินใจแบบเดียวกัน application ที่แก้ไขง่ายก็สามารถสะสม Cruft จนถึงจุดที่การเปลี่ยนแปลงเล็กๆ น้อยๆ ทุกอย่างต้องใช้ความพยายามนานหลายสัปดาห์
ลูกค้าใส่ใจว่า feature ใหม่ๆ จะมาถึงอย่างรวดเร็ว
ตรงนี้เราเริ่มเห็นเบาะแสว่าทำไมคุณภาพภายในจึงสำคัญต่อผู้ใช้และลูกค้า คุณภาพภายในที่ดีกว่าทำให้การเพิ่ม feature ใหม่ง่ายขึ้น ดังนั้นจึงเร็วขึ้นและถูกลง Rebecca และผมอาจมี application ที่เหมือนกันในตอนนี้ แต่ในอีกไม่กี่เดือนข้างหน้า คุณภาพภายในที่สูงของ Rebecca จะช่วยให้เธอเพิ่ม feature ใหม่ได้ทุกสัปดาห์ ในขณะที่ผมติดอยู่กับการพยายามฟันฝ่ากองขยะเพื่อให้ได้ feature ใหม่เพียงอย่างเดียว ผมไม่สามารถแข่งกับความเร็วของ Rebecca ได้ และในไม่ช้า software ของเธอก็จะมี feature มากกว่าของผมมาก จากนั้นลูกค้าทั้งหมดของผมก็จะลบแอปของผมทิ้งและไปใช้ของ Rebecca แทน แม้ว่าเธอจะเพิ่มราคาขึ้นก็ตาม
การสร้างภาพจำลองของผลกระทบจากคุณภาพภายใน
บทบาทพื้นฐานของคุณภาพภายในคือการลดต้นทุนของการเปลี่ยนแปลงในอนาคต แต่ก็ต้องใช้ความพยายามเป็นพิเศษในการเขียน software ที่ดี ซึ่งทำให้เกิดต้นทุนเพิ่มขึ้นในระยะสั้น
วิธีหนึ่งในการจินตนาการถึงสิ่งนี้คือการใช้กราฟจำลอง (pseudo-graph) ต่อไปนี้ โดยผมจะพล็อต function การทำงานสะสมของ software เทียบกับเวลา (และต้นทุน) ในการผลิต สำหรับความพยายามด้าน software ส่วนใหญ่ เส้นโค้งจะมีลักษณะดังนี้
นี่คือสิ่งที่เกิดขึ้นกับคุณภาพภายในที่ต่ำ ความคืบหน้าจะรวดเร็วในช่วงแรก แต่เมื่อเวลาผ่านไป การเพิ่ม feature ใหม่ๆ ก็จะยากขึ้นเรื่อยๆ แม้แต่การเปลี่ยนแปลงเล็กๆ น้อยๆ ก็ต้องการให้โปรแกรมเมอร์ทำความเข้าใจกับ code ในพื้นที่กว้าง ซึ่งเป็น code ที่ทำความเข้าใจได้ยาก เมื่อพวกเขาทำการเปลี่ยนแปลง ก็เกิดความเสียหายที่ไม่คาดคิดตามมา นำไปสู่เวลาในการทดสอบที่ยาวนานและข้อบกพร่องที่ต้องแก้ไข
การมุ่งเน้นที่คุณภาพภายในที่สูงคือการลดการลดลงของประสิทธิภาพการทำงานนั้น อันที่จริงผลิตภัณฑ์บางอย่างเห็นผลตรงกันข้าม คือนักพัฒนาสามารถเร่งความเร็วได้เมื่อ feature ใหม่ๆ สามารถสร้างขึ้นได้อย่างง่ายดายโดยการใช้ประโยชน์จากงานก่อนหน้า สถานการณ์ที่น่ายินดีนี้เป็นกรณีที่หาได้ยากกว่า เนื่องจากต้องใช้ทีมที่มีทักษะและระเบียบวินัยเพื่อให้มันเกิดขึ้นได้ แต่เราก็เห็นมันเป็นครั้งคราว
ความละเอียดอ่อนตรงนี้คือ มีช่วงเวลาหนึ่งที่คุณภาพภายในต่ำให้ประสิทธิภาพการทำงานที่สูงกว่าช่วงคุณภาพสูง ในช่วงเวลานี้มีการแลกเปลี่ยนบางอย่างระหว่างคุณภาพและต้นทุน คำถามคือ: ช่วงเวลานั้นนานแค่ไหนก่อนที่เส้นจะตัดกัน?
ไม่สามารถวัดประสิทธิภาพการทำงานได้
เราเห็นการถกเถียงทางอารมณ์มากมายเกี่ยวกับกระบวนการ software แนวปฏิบัติในการออกแบบ และสิ่งอื่นๆ ที่คล้ายคลึงกัน ข้อโต้แย้งเหล่านี้หลายข้อไม่สามารถตัดสินได้เนื่องจากอุตสาหกรรม software ขาดความสามารถในการวัดองค์ประกอบพื้นฐานบางอย่างของประสิทธิผลของการพัฒนา software โดยเฉพาะอย่างยิ่งเราไม่มีวิธีที่สมเหตุสมผลในการวัดประสิทธิภาพการทำงาน (Productivity)
ณ จุดนี้เราจึงพบว่าทำไมกราฟนี้จึงเป็นกราฟจำลอง เพราะไม่มีทางวัด function การทำงานที่ส่งมอบโดยทีม software ได้เลย ความไม่สามารถในการวัดผลผลิตและประสิทธิภาพการทำงานนี้ ทำให้ไม่สามารถระบุตัวเลขที่ชัดเจนเกี่ยวกับผลที่ตามมาของคุณภาพภายในต่ำ (ซึ่งก็วัดได้ยากเช่นกัน) การไม่สามารถวัดผลผลิตได้นั้นค่อนข้างเป็นเรื่องปกติในงานวิชาชีพ—เราจะวัดประสิทธิภาพการทำงานของทนายความหรือแพทย์ได้อย่างไร?
วิธีที่ผมใช้ประเมินว่าเส้นจะตัดกันที่ไหนคือการรวบรวมความคิดเห็นของนักพัฒนาที่มีทักษะที่ผมรู้จัก และคำตอบก็ทำให้หลายคนประหลาดใจ นักพัฒนาพบว่า code ที่มีคุณภาพต่ำทำให้พวกเขาช้าลงอย่างเห็นได้ชัดภายในไม่กี่สัปดาห์ ดังนั้นจึงไม่มี "รันเวย์" มากนักสำหรับการแลกเปลี่ยนระหว่างคุณภาพภายในและต้นทุน แม้แต่ความพยายามด้าน software เล็กๆ น้อยๆ ก็ได้รับประโยชน์จากการใส่ใจในแนวปฏิบัติที่ดีของ software ซึ่งเป็นสิ่งที่ผมสามารถยืนยันได้จากประสบการณ์ของผมเอง
แม้แต่ทีมที่ดีที่สุดก็สร้างกองขยะ (Cruft)
คนที่ไม่ใช่นักพัฒนาหลายคนมักจะคิดว่า Cruft เกิดขึ้นเฉพาะเมื่อทีมพัฒนาประมาทและทำผิดพลาดเท่านั้น แต่แม้แต่ทีมที่เก่งที่สุดก็ยังสร้าง Cruft ขึ้นมาอย่างหลีกเลี่ยงไม่ได้ในขณะที่พวกเขาทำงาน
ผมชอบแสดงประเด็นนี้ด้วยเรื่องเล่าตอนที่ผมคุยกับหัวหน้าทีมเทคนิคที่เก่งที่สุดคนหนึ่งของเรา เขาเพิ่งเสร็จสิ้นโปรเจกต์ที่ได้รับความพิจารณาอย่างกว้างขวางว่าเป็นความสำเร็จครั้งใหญ่ ลูกค้าพอใจกับระบบที่ส่งมอบ ทั้งในแง่ของความสามารถ รวมถึงเวลาและต้นทุนในการสร้าง คนของเราก็รู้สึกดีกับประสบการณ์การทำงานในโปรเจกต์นี้ หัวหน้าทีมเทคนิคพอใจในภาพรวมแต่ยอมรับว่าสถาปัตยกรรมของระบบนั้น "ไม่ค่อยดีนัก" ผมจึงถามไปว่า "มันจะเป็นไปได้อย่างไร—ในเมื่อคุณเป็นหนึ่งในสถาปนิกที่เก่งที่สุดของเรา?" คำตอบของเขาเป็นสิ่งที่สถาปนิก software ที่มีประสบการณ์คุ้นเคยดี: "เราตัดสินใจได้ดีแล้ว แต่ตอนนี้เราเพิ่งเข้าใจว่าเราควรจะสร้างมันขึ้นมาอย่างไร"
หลายคน รวมถึงคนจำนวนไม่น้อยในอุตสาหกรรม software เปรียบการสร้าง software กับการสร้างอาสนวิหารหรือตึกระฟ้า—ท้ายที่สุดแล้วทำไมเราถึงใช้คำว่า "สถาปนิก" สำหรับโปรแกรมเมอร์อาวุโสล่ะ? แต่การสร้าง software นั้นอยู่ในโลกของความไม่แน่นอนที่โลกทางกายภาพไม่รู้จัก ลูกค้าของ software มีความคิดเพียงคร่าวๆ ว่าพวกเขาต้องการ feature อะไรในผลิตภัณฑ์ และจะได้เรียนรู้มากขึ้นเมื่อ software ถูกสร้างขึ้น—โดยเฉพาะอย่างยิ่งเมื่อเวอร์ชันแรกๆ ถูกปล่อยออกมาให้ผู้ใช้ องค์ประกอบพื้นฐานของการพัฒนา software—ภาษา library(libraries) และ platform(platforms)—เปลี่ยนแปลงอย่างมีนัยสำคัญทุกๆ ไม่กี่ปี สิ่งที่เทียบเท่าในโลกทางกายภาพคือ ลูกค้ามักจะเพิ่มชั้นใหม่และเปลี่ยนผังพื้นหลังจากที่สร้างและเข้าอยู่ไปแล้วครึ่งหนึ่ง ในขณะที่คุณสมบัติพื้นฐานของคอนกรีตเปลี่ยนแปลงทุกๆ สองปี
ไซด์บาร์: การศึกษาของ DORA เกี่ยวกับทีมระดับหัวกะทิ (
Elite Teams) การเลือกระหว่างคุณภาพและความเร็วนั้นไม่ใช่ทางเลือกเดียวในการพัฒนาsoftwareที่ฟังดูสมเหตุสมผลแต่กลับผิดพลาด นอกจากนี้ยังมีความคิดที่รุนแรงว่ามีทางเลือกแบบBimodalระหว่างการพัฒนาที่รวดเร็วพร้อมการอัปเดตระบบบ่อยๆ กับระบบที่เชื่อถือได้และไม่พังในการใช้งานจริง ความจริงที่ว่าเป็นทางเลือกที่ผิดพลาดนั้นได้รับการพิสูจน์โดยงานวิจัยทางวิทยาศาสตร์อย่างรอบคอบในรายงานState of DevOps Reportเป็นเวลาหลายปีที่พวกเขาใช้การวิเคราะห์ทางสถิติจากการสำรวจเพื่อค้นหาแนวปฏิบัติของทีม
softwareที่มีประสิทธิภาพสูง งานของพวกเขาแสดงให้เห็นว่าทีมsoftwareระดับหัวกะทิอัปเดตcodeในระบบจริงวันละหลายครั้ง โดยส่งการเปลี่ยนแปลงcodeจากการพัฒนาไปยังระบบจริงในเวลาไม่ถึงชั่วโมง ในขณะที่พวกเขาทำเช่นนี้ อัตราความล้มเหลวจากการเปลี่ยนแปลง (Change failure rate) ของพวกเขานั้นต่ำกว่าองค์กรที่ทำงานช้ากว่าอย่างเห็นได้ชัด ดังนั้นพวกเขาจึงกู้คืนจากข้อผิดพลาดได้เร็วกว่ามาก ยิ่งไปกว่านั้น องค์กรที่ส่งมอบsoftwareระดับหัวกะทิเช่นนี้ยังมีความสัมพันธ์กับประสิทธิภาพการทำงานขององค์กรที่สูงกว่าอีกด้วย
ด้วยระดับของการเปลี่ยนแปลงนี้ โปรเจกต์ software มักจะสร้างสิ่งใหม่ๆ เสมอ เราแทบจะไม่พบว่าตัวเองกำลังทำงานกับปัญหาที่เป็นที่เข้าใจกันดีและเคยได้รับการแก้ไขมาแล้วโดยธรรมชาติ เราเรียนรู้เกี่ยวกับปัญหามากที่สุดในขณะที่เรากำลังสร้างวิธีแก้ปัญหา ดังนั้นจึงเป็นเรื่องปกติที่ผมจะได้ยินว่าทีมต่างๆ เข้าใจดีที่สุดว่าสถาปัตยกรรมของ software ของพวกเขาควรเป็นอย่างไร หลังจากที่พวกเขาใช้เวลาสร้างมันไปแล้วหนึ่งปีหรือมากกว่านั้น แม้แต่ทีมที่ดีที่สุดก็ยังมี Cruft ใน software ของพวกเขา
ความแตกต่างคือ ทีมที่ดีที่สุดจะสร้าง Cruft น้อยกว่ามาก และยังกำจัด Cruft ที่พวกเขาสร้างขึ้นได้เพียงพอเพื่อให้พวกเขาสามารถเพิ่ม feature ต่อไปได้อย่างรวดเร็ว พวกเขาใช้เวลาสร้างการทดสอบอัตโนมัติเพื่อให้สามารถตรวจพบปัญหาได้อย่างรวดเร็วและใช้เวลาในการกำจัดบั๊ก (bugs) น้อยลง พวกเขาทำการปรับปรุงโครงสร้าง code(Refactor) บ่อยครั้งเพื่อที่พวกเขาจะได้กำจัด Cruft ก่อนที่มันจะสะสมมากพอจนขวางทาง การรวม code อย่างต่อเนื่อง (Continuous Integration) จะช่วยลดการสะสมของ Cruft เนื่องจากการที่สมาชิกในทีมทำงานขัดแย้งกัน คำอุปมาที่พบบ่อยคือ มันเหมือนกับการทำความสะอาดพื้นผิวงานและอุปกรณ์ในห้องครัว คุณไม่สามารถทำอาหารโดยไม่ทำให้สิ่งของสกปรกได้ แต่ถ้าคุณไม่ทำความสะอาดสิ่งต่างๆ อย่างรวดเร็ว คราบสกปรกจะแห้งตัวลง ขจัดออกได้ยากขึ้น และสิ่งสกปรกทั้งหมดก็จะขวางทางการทำอาหารจานต่อไป
##software คุณภาพสูงนั้นถูกกว่าในการผลิต
สรุปทั้งหมดนี้:
- การละเลยคุณภาพภายในนำไปสู่การสะสมของ
Cruftอย่างรวดเร็ว *Cruftนี้ทำให้การพัฒนาfeatureช้าลง - แม้แต่ทีมที่ยอดเยี่ยมก็สร้าง
Cruftแต่การรักษาคุณภาพภายในให้สูงจะช่วยให้ควบคุมมันได้ - คุณภาพภายในที่สูงช่วยรักษา
Cruftให้เหลือน้อยที่สุด ทำให้ทีมสามารถเพิ่มfeatureได้โดยใช้ความพยายาม เวลา และต้นทุนที่น้อยลง
น่าเศร้าที่นักพัฒนา software มักจะอธิบายสถานการณ์นี้ได้ไม่ดีนัก นับครั้งไม่ถ้วนที่ผมได้คุยกับทีมพัฒนาที่พูดว่า "พวกเขา (ฝ่ายบริหาร) ไม่ยอมให้เราเขียน code ที่มีคุณภาพดีเพราะมันใช้เวลานานเกินไป" นักพัฒนามักจะให้เหตุผลในการใส่ใจคุณภาพโดยอ้างถึงความจำเป็นของความเป็นมืออาชีพที่เหมาะสม แต่ข้อโต้แย้งทางศีลธรรมนี้สื่อเป็นนัยว่าคุณภาพนี้แลกมาด้วยต้นทุน—ซึ่งทำให้ข้อโต้แย้งของพวกเขาล้มเหลว สิ่งที่น่ารำคาญคือ code ที่เต็มไปด้วย Cruft นั้นทำให้ชีวิตของนักพัฒนายากขึ้นและทำให้ลูกค้าต้องเสียเงินเพิ่ม เมื่อคิดถึงคุณภาพภายใน ผมเน้นย้ำว่าเราควรเข้าหาเรื่องนี้ด้วยข้อโต้แย้งทางเศรษฐกิจเท่านั้น คุณภาพภายในที่สูงช่วยลดต้นทุนของ feature ในอนาคต ซึ่งหมายความว่าการสละเวลาในการเขียน code ที่ดีนั้นแท้จริงแล้วช่วยลดต้นทุนได้
นี่คือเหตุผลที่คำถามที่เป็นหัวข้อของบทความนี้พลาดประเด็น "ต้นทุน" ของ software คุณภาพภายในสูงนั้นติดลบ การแลกเปลี่ยนตามปกติระหว่างต้นทุนและคุณภาพที่เราคุ้นเคยสำหรับการตัดสินใจส่วนใหญ่ในชีวิตของเรานั้นไม่มีความหมายกับคุณภาพภายในของ software(มันมีความหมายกับคุณภาพภายนอก เช่น ประสบการณ์ผู้ใช้ที่สร้างขึ้นอย่างพิถีพิถัน) เนื่องจากความสัมพันธ์ระหว่างต้นทุนและคุณภาพภายในเป็นความสัมพันธ์ที่ผิดปกติและขัดกับสัญชาตญาณ จึงมักจะเข้าใจได้ยาก แต่การทำความเข้าใจเรื่องนี้เป็นสิ่งสำคัญต่อการพัฒนา software ที่มีประสิทธิภาพสูงสุด
การวัดผลกระทบของคุณภาพภายในที่ต่ำ
(เพิ่มเมื่อ: 2024-01-29)
อย่างที่ผมกล่าวไว้ข้างต้น เราไม่รู้วิธีวัดคุณภาพภายในหรือประสิทธิภาพการทำงานจริงๆ ดังนั้นจึงเป็นเรื่องยากที่จะหาหลักฐานเชิงปริมาณเกี่ยวกับความสำคัญของคุณภาพภายใน อย่างไรก็ตาม ในช่วงไม่กี่ปีที่ผ่านมา มีความพยายามเพิ่มขึ้นในการวัดผลนี้
งานวิจัยชิ้นหนึ่งที่น่าสนใจเป็นพิเศษที่ผมพบคือ การศึกษาจาก Adam Tornhill และ Markus Borg พวกเขาใช้เครื่องมือที่เป็นกรรมสิทธิ์ของพวกเขาที่ชื่อว่า CodeScene เพื่อกำหนดระดับสุขภาพของไฟล์ในฐาน code ที่เป็นกรรมสิทธิ์ 39 แห่ง พวกเขาพบว่าการแก้ไขปัญหาใน code ที่มีคุณภาพต่ำใช้เวลานานกว่าการแก้ไขใน code ที่มีคุณภาพสูงกว่าสองเท่า และ code ที่มีคุณภาพต่ำมีความหนาแน่นของข้อบกพร่องสูงกว่าถึง 15 เท่า