กระสุนทุกนัดย่อมมีเป้าหมายของมัน
— WILLIAM III OF ENGLAND, PRINCE OF ORANGE
ใครก็ตามที่คิดว่าจะได้เห็นผลงานที่ไร้ที่ติ
ก็กำลังคิดถึงสิ่งที่ไม่มีอยู่ ไม่มี และจะไม่มีวันมี [1]
— ALEXANDER POPE, AN ESSAY ON CRITICISM
On Werewolves and Other Legendary Terrors (ว่าด้วยมนุษย์หมาป่าและสัตว์ประหลาดในตำนาน)
" No Silver Bullet—Essence and Accident of Software Engineering " (ปัจจุบันคือ บทที่ 16 ) เดิมเป็นบทความที่ได้รับเชิญให้นำเสนอในงานประชุม IFIP '86 ที่ดับลิน และได้รับการตีพิมพ์ใน proceedings ของงานดังกล่าว [2] นิตยสาร Computer ได้นำมาพิมพ์ซ้ำ โดยมีปกสไตล์กอธิคที่ตกแต่งด้วยภาพจากภาพยนตร์อย่าง The Werewolf of London [3] พวกเขายังมีแถบอธิบายข้าง "To Slay the Werewolf" ที่กล่าวถึงตำนาน (สมัยใหม่) ว่ามีเพียงกระสุนเงินเท่านั้นที่ใช้ได้ผล ผมไม่รู้มาก่อนว่ามีแถบอธิบายและภาพประกอบเหล่านี้ก่อนตีพิมพ์ และไม่เคยคาดคิดว่าเอกสารทางเทคนิคที่จริงจังจะถูกตกแต่งเช่นนี้
ถึงกระนั้น บรรณาธิการของ Computer ก็เชี่ยวชาญในการสร้างเอฟเฟกต์ที่ต้องการได้สำเร็จ และดูเหมือนว่าหลายคนได้อ่านบทความนี้ ผมจึงเลือกภาพมนุษย์หมาป่าอีกภาพหนึ่งมาประกอบบทนี้ ซึ่งเป็นภาพโบราณของสิ่งมีชีวิตที่ดูเกือบจะตลกขบขัน ผมหวังว่าภาพที่ดูไม่ฉูดฉาดเกินไปนี้จะให้ผลดีเช่นเดียวกัน
There is Too a Silver Bullet—AND HERE IT IS! (ก็มีกระสุนเงินเหมือนกัน—และนี่ไงล่ะ!)
บทความ "No Silver Bullet" ยืนยันและโต้แย้งว่าไม่มีพัฒนาการทางวิศวกรรมซอฟต์แวร์ใดเพียงหนึ่งเดียวที่จะสามารถเพิ่ม productivity ในการเขียนโปรแกรมได้ถึงระดับ order-of-magnitude ภายในสิบปี (นับจากปีตีพิมพ์ในปี 1986) ตอนนี้เราผ่านมาเก้าปีในทศวรรษนั้นแล้ว จึงถึงเวลาที่จะดูว่าคำทำนายนี้เป็นจริงแค่ไหน
ในขณะที่ The Mythical Man-Month ถูกอ้างถึงอย่างมากมายแต่ไม่ค่อยถูกโต้แย้ง "No Silver Bullet" กลับก่อให้เกิดบทความโต้แย้ง จดหมายถึงบรรณาธิการวารสาร รวมถึงจดหมายและบทความวิจารณ์ที่ยังคงมีต่อเนื่องมาจนถึงทุกวันนี้ [4] ส่วนใหญ่โจมตีข้อโต้แย้งหลักที่ว่าไม่มีทางออกที่วิเศษ และความเห็นที่ชัดเจนของผมว่าไม่มีทางมีได้ หลายคนเห็นด้วยกับข้อโต้แย้งส่วนใหญ่ใน "NSB" แต่แล้วก็ยืนยันว่ามีกระสุนเงินสำหรับปีศาจซอฟต์แวร์ ซึ่งผู้เขียนได้คิดค้นขึ้นมา เมื่อผมอ่านคำตอบในยุคแรก ๆ อีกครั้งในวันนี้ ผมอดไม่ได้ที่จะสังเกตว่ายาวิเศษที่ถูกผลักดันอย่างแข็งขันในปี 1986 และ 1987 นั้นไม่ได้ให้ผลลัพท์ที่ dramatic อย่างที่อ้างไว้
ผมซื้อ hardware และ software โดยส่วนใหญ่ใช้ "happy user" test—คือการพูดคุยกับลูกค้าที่จ่ายเงินจริง ๆ ที่ใช้ product และพอใจ เช่นเดียวกัน ผมจะเชื่อว่ามีกระสุนเงินเกิดขึ้นจริงเมื่อมีผู้ใช้งานอิสระตัวจริงออกมากล่าวว่า "ผมใช้ methodology, tool หรือ product นี้ และมันทำให้ software productivity ของผมดีขึ้นสิบเท่า"
ผู้ติดต่อจำนวนมากได้ให้ข้อแก้ไขหรือคำชี้แจงที่มีประโยชน์ บางคนได้ทำการวิเคราะห์และโต้แย้งแบบ point-by-point ซึ่งผมรู้สึกขอบคุณ ในบทนี้ ผมจะแบ่งปันการปรับปรุงต่าง ๆ และตอบข้อโต้แย้งเหล่านั้น
Obscure Writing Will Be Misunderstood (งานเขียนที่คลุมเครือย่อมถูกเข้าใจผิด)
นักเขียนบางคนชี้ให้เห็นว่าผมล้มเหลวในการทำให้ข้อโต้แย้งบางข้อชัดเจน
Accident. ข้อโต้แย้งหลักของ "NSB" ได้ถูกระบุไว้อย่างชัดเจนที่สุดเท่าที่ผมจะทำได้ในบทคัดย่อของ บทที่ 16 อย่างไรก็ตาม บางคนสับสนกับคำว่า accident และ accidental ซึ่งเป็นการใช้ตามความหมายโบราณที่สืบย้อนไปถึงอริสโตเติล [5] การที่ผมใช้คำว่า accidental นั้น ไม่ได้หมายถึง ที่เกิดขึ้นโดยบังเอิญ หรือ โชคร้าย แต่หมายถึง ที่เป็นส่วนประกอบ หรือ ที่ติดเนื่องมา
ผมไม่ได้มีเจตนาจะดูถูกส่วนที่เป็น accidental ของการสร้างซอฟต์แวร์ แต่ผมเห็นด้วยกับ Dorothy Sayers นักเขียนบทละคร นักเขียนเรื่องสืบสวน และนักเทววิทยาชาวอังกฤษ ว่ากิจกรรมสร้างสรรค์ทั้งหมดประกอบด้วย (1) การสร้างกรอบแนวคิด (2) การนำไปปฏิบัติในสื่อจริง และ (3) การปฏิสัมพันธ์กับผู้ใช้ในการใช้งานจริง [6] ส่วนของการสร้างซอฟต์แวร์ที่ผมเรียกว่า essence คือการสร้างกรอบแนวคิดทางความคิด ส่วนที่ผมเรียกว่า accident คือกระบวนการนำไปปฏิบัติ
A question of fact. สำหรับผมแล้ว (แม้ไม่ใช่ทุกคนจะเห็นด้วย) ความจริงของข้อโต้แย้งหลักสรุปได้ที่คำถามเชิงข้อเท็จจริง: สัดส่วนเท่าไหร่ของความพยายามทั้งหมดในการพัฒนาซอฟต์แวร์ที่เกี่ยวข้องกับการนำเสนอกรอบแนวคิดอย่างถูกต้องและเป็นระเบียบ และสัดส่วนเท่าไหร่ที่เป็นความพยายามในการสร้างกรอบแนวคิดทางความคิด การค้นหาและแก้ไขข้อบกพร่องตกอยู่ในทั้งสองส่วน ขึ้นอยู่กับว่าข้อบกพร่องนั้นเป็นเชิงแนวคิด เช่น การไม่รู้จัก exception บางอย่าง หรือเป็นเชิงการนำเสนอ เช่น pointer mistake หรือ memory allocation mistake
ความคิดเห็นของผม—และนั่นคือทั้งหมด—คือส่วนที่เป็น accidental หรือ representational ของงานตอนนี้ลดลงเหลือประมาณครึ่งหนึ่งหรือน้อยกว่าของทั้งหมด เนื่องจากสัดส่วนนี้เป็นคำถามเชิงข้อเท็จจริง ตามหลักการแล้วค่าของมันสามารถหาได้จากการวัด [7] ถ้าไม่มีข้อมูลนั้น การประมาณของผมก็สามารถถูกแก้ไขได้ด้วยการประมาณที่แม่นยำและทันสมัยกว่า ที่น่าสังเกตคือ ไม่มีใครที่เขียนมาทั้งต่อสาธารณะหรือส่วนตัวที่ยืนยันว่าส่วนที่เป็น accidental มีมากถึง 9/10
"NSB" โต้แย้งอย่างปฏิเสธไม่ได้ว่าถ้าส่วนที่เป็น accidental ของงานน้อยกว่า 9/10 ของทั้งหมด การทำให้มันเป็นศูนย์ (ซึ่ง คง ต้องใช้เวทมนตร์) ก็จะไม่ทำให้ productivity ดีขึ้นถึง order of magnitude เราจำเป็น ต้อง โจมตีที่ essence
หลังจาก "NSB" Bruce Blum ได้ดึงความสนใจของผมไปที่งานของ Herzberg, Mausner และ Sayderman ในปี 1959 [8] พวกเขาพบว่าปัจจัยด้านแรงจูงใจสามารถเพิ่ม productivity ได้ ในทางกลับกัน ปัจจัยด้านสภาพแวดล้อมและ accidental ไม่ว่าจะดีแค่ไหนก็ไม่สามารถเพิ่ม productivity ได้ แต่ปัจจัยเหล่านี้สามารถลด productivity ได้เมื่อเป็นเชิงลบ "NSB" โต้แย้งว่าความก้าวหน้าทางซอฟต์แวร์ส่วนใหญ่เป็นการกำจัดปัจจัยเชิงลบเหล่านี้ เช่น ภาษาเครื่องที่ยุ่งยากอย่างน่าตกใจ, batch processing ที่มี turnaround time ยาวนาน, tools ที่ไม่ดี และข้อจำกัดด้านหน่วยความจำที่รุนแรง
Are the essential difficulties therefore hopeless? บทความที่ยอดเยี่ยมในปี 1990 โดย Brad Cox ชื่อ "There Is a Silver Bullet" โต้แย้งอย่างมีน้ำหนักว่าวิธีการแบบ reusable, interchangeable component เป็นการโจมตี essence เชิงแนวคิดของปัญหา [9] ผมเห็นด้วยอย่างยิ่ง
อย่างไรก็ตาม Cox เข้าใจ "NSB" ผิดในสองประเด็น ประการแรก เขาอ่านว่า "NSB" กำลังยืนยันว่าปัญหาทางซอฟต์แวร์เกิดขึ้น "จากข้อบกพร่องบางอย่างในวิธีที่ programmer สร้างซอฟต์แวร์ในปัจจุบัน" ข้อโต้แย้งของผมคือปัญหาสำคัญนั้นมีอยู่ในความซับซ้อนเชิงแนวคิดของฟังก์ชันซอฟต์แวร์ที่ต้องออกแบบและสร้างขึ้นในทุกยุคทุกสมัย ไม่ว่าจะใช้วิธีใดก็ตาม ประการที่สอง เขา (และคนอื่น ๆ) อ่านว่า "NSB" ยืนยันว่าไม่มีความหวังที่จะโจมตีปัญหาสำคัญของการสร้างซอฟต์แวร์ นั่นไม่ใช่เจตนาของผม การสร้างกรอบแนวคิดนั้นมีความยากลำบากที่ติดตัวมาอยู่แล้ว ได้แก่ complexity, conformity, changeability และ invisibility อย่างไรก็ตาม ปัญหาที่เกิดจากความยากลำบากแต่ละอย่างนี้สามารถบรรเทาลงได้
Complexity is by levels. ตัวอย่างเช่น complexity เป็นปัญหาสำคัญที่ร้ายแรงที่สุด แต่ไม่ใช่ทุก complexity จะหลีกเลี่ยงไม่ได้ ส่วนใหญ่—แต่ไม่ทั้งหมด—ของความซับซ้อนเชิงแนวคิดในซอฟต์แวร์ของเรามาจากความซับซ้อนตามอำเภอใจของตัว application เอง อันที่จริง Lars Sodahl แห่ง MYSIGMA Sodahl and Partners ซึ่งเป็นบริษัทที่ปรึกษาการจัดการข้ามชาติ เขียนว่า:
จากประสบการณ์ของผม ความซับซ้อนส่วนใหญ่ที่พบในงานระบบเป็นอาการของความผิดปกติขององค์กร การพยายามสร้างโมเดลความจริงนี้ด้วยโปรแกรมที่ซับซ้อนพอ ๆ กันนั้นแท้จริงแล้วเป็นการรักษาความยุ่งเหยิงไว้แทนที่จะแก้ปัญหา
Steve Lukasik แห่ง Northrop โต้แย้งว่าแม้แต่ความซับซ้อนขององค์กรก็อาจไม่ใช่เรื่องตามอำเภอใจ แต่อาจอ่อนไหวต่อหลักการจัดระเบียบ:
ผมได้รับการฝึกฝนมาเป็นนักฟิสิกส์ จึงมองว่าสิ่งที่ "ซับซ้อน" นั้นอ่อนไหวต่อการอธิบายในรูปของแนวคิดที่เรียบง่ายกว่า ตอนนี้คุณอาจจะพูดถูก ผมจะไม่ยืนยันว่าสิ่งที่ซับซ้อนทั้งหมดนั้นอ่อนไหวต่อหลักการจัดระเบียบ... แต่ด้วยกฎของการโต้แย้งเดียวกัน คุณก็ไม่สามารถยืนยันได้ว่ามันจะ ไม่ เป็นเช่นนั้น
...ความซับซ้อนของเมื่อวานคือระเบียบของวันพรุ่งนี้ ความซับซ้อนของความไม่เป็นระเบียบของโมเลกุลได้เปิดทางให้กับทฤษฎีจลน์ของแก๊สและกฎสามข้อของเทอร์โมไดนามิกส์ ตอนนี้ซอฟต์แวร์อาจจะไม่เปิดเผยหลักการจัดระเบียบแบบนั้น แต่ภาระในการอธิบายว่าทำไมไม่ถึงตกอยู่ที่คุณ ผมไม่ได้ดื้อรั้นหรือชอบโต้แย้ง ผมเชื่อว่าวันหนึ่ง "ความซับซ้อน" ของซอฟต์แวร์จะถูกเข้าใจในรูปของแนวคิดระดับสูงกว่า (invariants ในภาษาของนักฟิสิกส์)
ผมไม่ได้ทำการวิเคราะห์เชิงลึกตามที่ Lukasik เรียกร้องอย่างถูกต้อง ในฐานะสาขาวิชาหนึ่ง เราต้องการทฤษฎีสารสนเทศที่ขยายขอบเขต ซึ่งสามารถวัดปริมาณเนื้อหาสารสนเทศของโครงสร้างแบบ static ได้ เช่นเดียวกับที่ทฤษฎีของ Shannon ทำกับกระแสข้อมูลที่สื่อสาร นั่นเกินความสามารถของผมไปมาก สำหรับ Lukasik ผมเพียงตอบว่าความซับซ้อนของระบบเป็นฟังก์ชันของรายละเอียดนับไม่ถ้วนที่แต่ละอย่างต้องถูกระบุอย่างแม่นยำ ไม่ว่าจะด้วยกฎทั่วไปหรือแบบทีละรายละเอียด แต่ไม่ใช่แค่ในเชิงสถิติ ดูไม่น่าเป็นไปได้อย่างยิ่งที่ผลงานที่ไม่ได้ประสานกันของคนจำนวนมากจะมีความเชื่อมโยงกันมากพอที่จะถูกอธิบายอย่างแม่นยำด้วยกฎทั่วไป
อย่างไรก็ตาม ความซับซ้อนส่วนใหญ่ในซอฟต์แวร์ไม่ได้เกิดจากการปรับให้เข้ากับโลกภายนอก แต่เกิดจากตัว implementation เอง—ไม่ว่าจะเป็น data structures, algorithms, หรือการเชื่อมต่อกัน การสร้างซอฟต์แวร์ในระดับชิ้นส่วนที่สูงขึ้น ไม่ว่าจะสร้างโดยคนอื่นหรือ reuse จากงานในอดีตของตนเอง ช่วยให้ไม่ต้องเผชิญกับความซับซ้อนหลายชั้น "NSB" สนับสนุนการโจมตีปัญหาความซับซ้อนอย่างเต็มที่ โดยมองในแง่ดีว่าสามารถมีความก้าวหน้าได้ และเสนอให้เพิ่มความซับซ้อนที่จำเป็นให้กับระบบซอฟต์แวร์:
• ตามลำดับชั้น ด้วยโมดูลหรือ object ที่เป็นชั้น ๆ
• แบบค่อยเป็นค่อยไป เพื่อให้ระบบทำงานได้ตลอดเวลา
Harel's Analysis (การวิเคราะห์ของ Harel)
David Harel ในบทความปี 1992 ชื่อ "Biting the Silver Bullet" ได้ทำการวิเคราะห์ "NSB" อย่างละเอียดถี่ถ้วนที่สุดเท่าที่เคยมีมา [10]
Pessimism vs. optimism vs. realism. Harel มองทั้ง "NSB" และงานของ Parnas ในปี 1984 เรื่อง "Software Aspects of Strategic Defense Systems" [11] ว่า "มืดมนเกินไป" ดังนั้นเขาจึงตั้งใจจะฉายแสงสว่างให้อีกด้านของเหรียญ โดยตั้งชื่อรองของบทความว่า "Toward a Brighter Future for System Development" ทั้ง Cox และ Harel อ่าน "NSB" ในแง่ pessimistic และเขาบอกว่า "แต่ถ้าคุณมองข้อเท็จจริงเดียวกันนี้จากมุมมองใหม่ ข้อสรุปในแง่ optimistic ก็จะเกิดขึ้น" ทั้งคู่เข้าใจน้ำเสียงผิดไป
ประการแรก ภรรยา เพื่อนร่วมงาน และบรรณาธิการของผมต่างพบว่าผมมักจะผิดในแง่ optimistic มากกว่า pessimistic ยังไงเสีย ผมก็เป็น programmer โดยพื้นฐาน และ optimism ก็เป็นโรคประจำอาชีพของเรา
"NSB" กล่าวอย่างชัดเจนว่า "เมื่อเรามองไปยังขอบฟ้าอีกทศวรรษข้างหน้า เราไม่เห็นกระสุนเงิน... แต่ความสงสัยไม่ใช่แง่ลบ... ไม่มีทางลัด แต่ก็มีทาง" มันทำนายว่านวัตกรรมที่กำลังดำเนินอยู่ในปี 1986 ถ้าได้รับการพัฒนาและใช้ประโยชน์ ร่วมกัน จะสามารถทำให้ productivity ดีขึ้นถึง order-of-magnitude ได้จริง เมื่อทศวรรษ 1986–1996 ดำเนินไป คำทำนายนี้ดูจะมองในแง่ดีเกินไปมากกว่าจะมืดมน
ถึงแม้ว่า "NSB" จะถูกมองว่า pessimistic โดยทั่วไป แล้วมันผิดตรงไหน? คำกล่าวของ Einstein ที่ว่าไม่มีอะไรเดินทางเร็วกว่าแสงนั้น "มืดมน" หรือ "หดหู่" หรือไม่? แล้วผลลัพธ์ของ Gödel ที่ว่าบางสิ่งไม่สามารถคำนวณได้ล่ะ? "NSB" พยายามสร้างข้อเท็จจริงที่ว่า "ธรรมชาติของซอฟต์แวร์ทำให้ไม่น่าเป็นไปได้ที่จะมีกระสุนเงินเกิดขึ้น" Turski ในบทความตอบกลับที่ยอดเยี่ยมของเขาในงานประชุม IFIP กล่าวอย่างมีชั้นเชิงว่า:
ในบรรดาความพยายามทางวิทยาศาสตร์ที่หลงผิดทั้งหมด ไม่มีอะไรที่น่าเวทนาไปกว่าการตามหาศิลานักปราชญ์ (philosophers' stone) ซึ่งเป็นสสารที่ supposed ว่าจะเปลี่ยนโลหะธรรมดาให้เป็นทองคำ เป้าหมายสูงสุดของการเล่นแร่แปรธาตุ ที่ถูก追寻อย่างกระตือรือร้นโดยนักวิจัยหลายชั่วอายุคน ซึ่งได้รับทุนสนับสนุนอย่างเหลือเฟือจากผู้ปกครองทั้งทางโลกและทางธรรม คือสารสกัดบริสุทธิ์ของการคิดตามใจปรารถนา (wishful thinking) และสมมติฐานทั่วไปที่ว่าสิ่งต่าง ๆ เป็นอย่างที่เราอยากให้เป็น มันเป็นความเชื่อที่เป็นมนุษย์อย่างแท้จริง ต้องใช้ความพยายามอย่างมากในการยอมรับการมีอยู่ของปัญหาที่ไม่สามารถแก้ไขได้ ความปรารถนาที่จะหาทางออก ไม่ว่าจะมีอุปสรรคแค่ไหน แม้ว่าจะพิสูจน์แล้วว่าไม่มีทางออก ก็ยังคงรุนแรงอย่างยิ่ง และพวกเราส่วนใหญ่ก็มีความเห็นใจอย่างมากต่อวิญญาณผู้กล้าหาญเหล่านี้ที่พยายามทำให้สิ่งที่เป็นไปไม่ได้เป็นจริง ดังนั้นมันจึงดำเนินต่อไป วิทยานิพนธ์เกี่ยวกับการทำให้วงกลมเป็นสี่เหลี่ยมจัตุรัสก็ยังคงถูกเขียนขึ้น ยา restorative สำหรับผมร่วงก็ถูกปรุงและขายดี วิธีการปรับปรุง software productivity ก็ถูกคิดค้นและขายดีเช่นกัน บ่อยครั้งเกินไปที่เรามักจะทำตาม optimism ของตัวเอง (หรือใช้ประโยชน์จากความหวังในแง่ดีของผู้สนับสนุนเรา) บ่อยครั้งเกินไปที่เรายินยอมที่จะเพิกเฉยต่อเสียงแห่งเหตุผลและหลงเชื่อคำเรียกร้องของผู้ขายยาวิเศษ [12]
Turski และผมทั้งคู่ยืนยันว่าการฝันกลางวัน ขัดขวางความก้าวหน้าและทำให้ความพยายามสูญเปล่า
"Gloom" themes. Harel มองว่าความมืดมนใน "NSB" เกิดจากสามประเด็น:
• การแยก essence และ accident อย่างชัดเจน
• การพิจารณา silver bullet แต่ละตัวแยกกัน
• การทำนายแค่ 10 ปี แทนที่จะเป็นระยะเวลาที่ยาวนานพอ "ที่จะคาดหวังการปรับปรุงที่มีนัยสำคัญ"
สำหรับประเด็นแรก นั่นคือจุดสำคัญทั้งหมดของบทความ ผมยังคงเชื่อว่าการแยกนี้เป็นหัวใจสำคัญในการทำความเข้าใจว่าทำไมซอฟต์แวร์ถึงยาก มันเป็นแนวทางที่แน่นอนว่าควรโจมตีแบบไหน
สำหรับการพิจารณา silver bullet แต่ละตัวแยกกัน "NSB" ก็ทำเช่นนั้นจริง ๆ ผู้สมัครต่าง ๆ ถูกเสนอมาทีละตัว พร้อมกับคำกล่าวอ้างที่เกินจริงสำหรับแต่ละตัว โดยตัวมันเอง การประเมินทีละตัวก็เป็นเรื่องที่ยุติธรรม ไม่ใช่เทคนิคที่ผมคัดค้าน แต่เป็นความคาดหวังว่ามันจะทำงานได้อย่างมหัศจรรย์ Glass, Vessey และ Conger ในบทความปี 1992 ของพวกเขาให้หลักฐานมากมายว่าการค้นหากระสุนเงินที่ไร้ประโยชน์ยังไม่สิ้นสุด [13]
สำหรับการเลือก 10 ปีเทียบกับ 40 ปีเป็นระยะเวลาทำนาย ระยะเวลาที่สั้นกว่าเป็นส่วนหนึ่งของการยอมรับว่าอำนาจการทำนายของเราไม่เคยดีเกินกว่าหนึ่งทศวรรษ ในพวกเรามีใครบ้างที่ในปี 1975 ทำนายการปฏิวัติไมโครคอมพิวเตอร์ในทศวรรษ 1980 ได้?
ยังมีเหตุผลอื่นสำหรับการจำกัดที่หนึ่งทศวรรษ: คำกล่าวอ้างสำหรับ silver bullet แต่ละตัวล้วนมีความเร่งด่วนอยู่ในตัว ผมจำไม่ได้เลยว่ามีใครบอกว่า "ลงทุนในยาวิเศษของฉัน แล้วคุณจะเริ่มได้รับผลตอบแทนหลังจาก 10 ปี" ยิ่งไปกว่านั้น อัตราส่วน performance/price ของ hardware พัฒนาขึ้นประมาณร้อยเท่าต่อทศวรรษ และการเปรียบเทียบนั้น แม้จะไม่ถูกต้องนัก แต่ก็หลีกเลี่ยงไม่ได้ในจิตใต้สำนึก เราจะมีความก้าวหน้าอย่างมากในอีก 40 ปีข้างหน้า การเพิ่มขึ้น order of magnitude ใน 40 ปีแทบจะไม่ใช่เรื่องมหัศจรรย์เลย
Harel's thought experiment. Harel เสนอการทดลองทางความคิดโดยสมมติให้ "NSB" ถูกเขียนขึ้นในปี 1952 แทนที่จะเป็นปี 1986 แต่ยืนยันใน propositions เดียวกัน เขาใช้สิ่งนี้เป็น reducto ad absurdum เพื่อโต้แย้งการพยายามแยก essence ออกจาก accident
ข้อโต้แย้งนี้ใช้ไม่ได้ ประการแรก "NSB" เริ่มต้นด้วยการยืนยันว่าความยากลำบากแบบ accidental ครอบงำความยากลำบากแบบ essential ในการเขียนโปรแกรมยุค 1950s ว่ามันไม่ได้เป็นเช่นนั้นอีกต่อไป และการกำจัดมันทำให้เกิดการปรับปรุงแบบ orders-of-magnitude การย้ายข้อโต้แย้งนั้นกลับไป 40 ปีนั้นไม่สมเหตุสมผล แทบจะจินตนาการไม่ได้ว่าจะมีใครในปี 1952 ยืนยันว่าความยากลำบากแบบ accidental ไม่ได้เป็นส่วนสำคัญของความพยายาม
ประการที่สอง สถานการณ์ที่ Harel จินตนาการว่าเกิดขึ้นในยุค 1950s นั้นไม่ถูกต้อง:
นั่นเป็นช่วงที่แทนที่จะต่อสู้กับการออกแบบระบบขนาดใหญ่และซับซ้อน programmer กำลังยุ่งอยู่กับการพัฒนาโปรแกรมคนเดียวแบบเดิม ๆ (ซึ่งจะอยู่ที่ประมาณ 100–200 บรรทัดในภาษาโปรแกรมมิ่งสมัยใหม่) ที่ใช้ทำงานอัลกอริทึมที่มีขอบเขตจำกัด ด้วยเทคโนโลยีและ methodology ที่มีในตอนนั้น งานเหล่านี้ก็ยากไม่แพ้กัน ความล้มเหลว ข้อผิดพลาด และการพลาดกำหนดส่งงานมีอยู่ทั่วทุกหนทุกแห่ง
จากนั้นเขาอธิบายว่าความล้มเหลว ข้อผิดพลาด และการพลาดกำหนดส่งในโปรแกรมคนเดียวเล็ก ๆ ตามสมมติฐานนั้นดีขึ้นถึง order of magnitude ในอีก 25 ปีต่อมา
แต่สภาพของงานในยุค 1950s นั้นแท้จริงแล้วไม่ใช่โปรแกรมคนเดียวเล็ก ๆ ในปี 1952 Univac กำลังทำงานประมวลผลสำมะโนประชากรปี 1950 ด้วยโปรแกรมที่ซับซ้อนซึ่งพัฒนาโดย programmer ประมาณแปดคน [14] เครื่องจักรอื่น ๆ กำลังคำนวณทางเคมีพลศาสตร์ การแพร่กระจายนิวตรอน การคำนวณสมรรถนะขีปนาวุธ ฯลฯ [15] Assembler, relocating linker และ loader, ระบบ interpretative แบบ floating-point ฯลฯ ถูกใช้เป็นประจำ [16] ภายในปี 1955 ผู้คนกำลังสร้างโปรแกรมธุรกิจขนาด 50 ถึง 100 man-year [17] ภายในปี 1956 General Electric ได้ใช้งานระบบ payroll ในโรงงานเครื่องใช้ไฟฟ้าที่ Louisville ซึ่งมีโปรแกรมมากกว่า 80,000 คำ ภายในปี 1957 คอมพิวเตอร์ระบบป้องกันภัยทางอากาศ SAGE ANFSQ/7 ทำงานมาแล้วสองปี และระบบ real-time แบบ fail-safe-duplexed ที่ใช้การสื่อสารซึ่งมี 75,000 คำสั่งกำลังทำงานอยู่ใน 30 แห่ง [18] แทบจะกล่าวไม่ได้ว่าวิวัฒนาการของเทคนิคสำหรับโปรแกรมคนเดียวเป็นตัวอธิบายหลักของความพยายามทางวิศวกรรมซอฟต์แวร์ตั้งแต่ปี 1952
AND HERE IT IS. Harel เสนอ silver bullet ของเขาเอง ซึ่งเป็นเทคนิคการสร้างแบบจำลองที่เรียกว่า "The Vanilla Framework" วิธีการดังกล่าวยังไม่ได้ถูกอธิบายในรายละเอียดมากพอที่จะประเมินได้ แต่มีการอ้างอิงถึงบทความและรายงานทางเทคนิคที่จะตีพิมพ์เป็นหนังสือในเวลาอันควร [19] การสร้างแบบจำลองเข้าถึง essence ซึ่งก็คือการสร้างและ debug แนวคิดอย่างเหมาะสม ดังนั้นจึงเป็นไปได้ที่ Vanilla Framework จะปฏิวัติวงการ ผมหวังเช่นนั้น Ken Brooks รายงานว่าเขาพบว่ามันเป็น methodology ที่มีประโยชน์เมื่อลองใช้กับงานจริง
Invisibility. Harel โต้แย้งอย่างหนักแน่นว่าส่วนใหญ่ของกรอบแนวคิดของซอฟต์แวร์นั้นมีลักษณะเป็น topology โดยธรรมชาติ และความสัมพันธ์เหล่านี้มีสิ่งที่เทียบเคียงได้ตามธรรมชาติในการแสดงผลเชิงพื้นที่/กราฟิก:
การใช้ visual formalisms ที่เหมาะสมสามารถมีผลกระทบที่น่าทึ่งต่อวิศวกรและ programmer ยิ่งไปกว่านั้น ผลกระทบนี้ไม่ได้จำกัดอยู่แค่เรื่อง accidental เท่านั้น คุณภาพและความรวดเร็วของ _การคิด ของพวกเขาก็พบว่าดีขึ้นเช่นกัน การพัฒนาระบบที่ประสบความสำเร็จในอนาคตจะหมุนรอบการแสดงผลด้วยภาพ เราจะ conceptualize ก่อน โดยใช้ entities และ relationships ที่ "เหมาะสม" จากนั้นจึง formulate และ reformulate แนวคิดของเราเป็นชุดของแบบจำลองที่ครอบคลุมมากขึ้นเรื่อย ๆ ซึ่งแสดงผลในรูปแบบที่เหมาะสมของ visual languages ที่ผสมผสานกัน ต้องเป็นการผสมผสานเพราะแบบจำลองของระบบมีหลายแง่มุม แต่ละแง่มุมก่อให้เกิดภาพทางความคิดที่แตกต่างกัน ...บางแง่มุมของกระบวนการสร้างแบบจำลองก็ไม่เอื้อต่อการแสดงภาพที่ดีเท่าแง่มุมอื่น ยกตัวอย่างเช่น การดำเนินการเชิงอัลกอริทึมกับตัวแปรและ data structures อาจจะยังคงเป็นข้อความต่อไป_
Harel และผมค่อนข้างใกล้เคียงกัน สิ่งที่ผมโต้แย้งคือโครงสร้างของซอฟต์แวร์ไม่ได้ฝังอยู่ในปริภูมิสามมิติ ดังนั้นจึงไม่มีการแมปเดียวที่ natural จากการออกแบบเชิงแนวคิดไปเป็นแผนภาพ ไม่ว่าจะเป็นสองมิติหรือมากกว่า เขายอมรับ และผมเห็นด้วย ว่าเราต้องการแผนภาพหลายแบบ แต่ละแบบครอบคลุมแง่มุมที่แตกต่างกัน และบางแง่มุมก็ไม่สามารถทำเป็นแผนภาพได้ดีเลย
ผมเห็นด้วยอย่างเต็มที่กับความกระตือรือร้นของเขาในการใช้แผนภาพเป็นเครื่องมือช่วยคิดและออกแบบ ผมชอบถาม programmer ที่สมัครงานมานานแล้วว่า "เดือนพฤศจิกายนปีหน้าอยู่ที่ไหน?" ถ้าคำถามคลุมเครือเกินไป ก็ถามต่อว่า "บอกฉันเกี่ยวกับ mental model ของคุณเกี่ยวกับปฏิทินหน่อย" programmer ที่เก่งจริง ๆ มีประสาทสัมผัสเชิงพื้นที่ที่แข็งแกร่ง พวกเขามักจะมีโมเดลเชิงเรขาคณิตของเวลา และพวกเขามักจะเข้าใจคำถามแรกโดยไม่ต้องอธิบายเพิ่ม พวกเขามีโมเดลที่เป็นส่วนตัวสูง
Jones's Point—Productivity Follows Quality (ประเด็นของ Jones—Productivity ตามหลัง Quality)
Capers Jones ซึ่งเขียนในบันทึกหลายฉบับก่อนแล้วจึงเป็นหนังสือ เสนอมุมมองที่ลึกซึ้ง ซึ่งผู้ติดต่อหลายคนของผมก็กล่าวไว้เช่นเดียวกัน "NSB" เช่นเดียวกับงานเขียนส่วนใหญ่ในเวลานั้น มุ่งเน้นไปที่ productivity หรือผลลัพธ์ซอฟต์แวร์ต่อหน่วย input Jones กล่าวว่า "ไม่ใช่ ให้ focus ที่ quality แล้ว productivity จะตามมา" [20] เขาโต้แย้งว่าโปรเจกต์ที่แพงและล่าช้านั้นลงทุนงานและเวลาพิเศษส่วนใหญ่ไปกับการค้นหาและแก้ไขข้อผิดพลาดใน specification, design และ implementation เขานำเสนอข้อมูลที่แสดงความสัมพันธ์ที่strong betweenการขาดการควบคุมคุณภาพอย่างเป็นระบบและหายนะด้านกำหนดส่ง ผมเชื่อมั่นในเรื่องนี้ Boehm ชี้ให้เห็นว่า productivity ลดลงอีกครั้งเมื่อเรา追求 quality ที่สูงมาก เช่นในซอฟต์แวร์กระสวยอวกาศของ IBM
Coqui โต้แย้งในทำนองเดียวกันว่าระเบียบวินัยในการพัฒนาซอฟต์แวร์อย่างเป็นระบบถูกพัฒนาขึ้นเพื่อตอบสนองต่อความกังวลด้าน quality (โดยเฉพาะการหลีกเลี่ยงหายนะครั้งใหญ่) มากกว่าความกังวลด้าน productivity
แต่ขอให้สังเกต: เป้าหมายของการประยุกต์ใช้หลักการทางวิศวกรรมกับการผลิตซอฟต์แวร์ในยุค 1970s คือการเพิ่ม Quality, Testability, Stability และ Predictability ของ product ซอฟต์แวร์—ไม่จำเป็นต้องเป็นประสิทธิภาพของการผลิตซอฟต์แวร์
แรงผลักดันในการใช้หลักการวิศวกรรมซอฟต์แวร์ในการผลิตซอฟต์แวร์คือความกลัวต่ออุบัติเหตุร้ายแรงที่อาจเกิดจากการปล่อยให้ศิลปินที่ควบคุมไม่ได้รับผิดชอบในการพัฒนาระบบที่ซับซ้อนมากขึ้นเรื่อย ๆ [21]
So What Has Happened to Productivity? (แล้ว Productivity เกิดอะไรขึ้นบ้าง?)
Productivity numbers. ตัวเลข productivity นั้นนิยามยาก ปรับเทียบยาก และหาข้อมูลยาก Capers Jones เชื่อว่าสำหรับโปรแกรม COBOL ที่เทียบเท่ากันสองโปรแกรมที่เขียนห่างกัน 10 ปี โปรแกรมหนึ่งไม่มี structured methodology และอีกโปรแกรมหนึ่งมี อัตราขยายจะอยู่ที่สามเท่า
Ed Yourdon กล่าวว่า "ผมเห็นคนได้รับการปรับปรุงถึงห้าเท่าจาก workstation และ software tools" Tom DeMarco เชื่อว่า "ความคาดหวังของคุณเกี่ยวกับการปรับปรุง order-of-magnitude ใน 10 ปี จากเทคนิคทั้งหมดรวมกันนั้นมองในแง่ดีเกินไป ผมยังไม่เห็นองค์กรใดที่ทำการปรับปรุงถึง order-of-magnitude ได้"
Shrink-wrapped software—Buy; don't build. การประเมินหนึ่งใน "NSB" ปี 1986 ผมคิดว่าได้พิสูจน์แล้วว่าถูกต้อง: "การพัฒนาของตลาดมวลชนคือ...แนวโน้มระยะยาวที่ลึกซึ้งที่สุดในวิศวกรรมซอฟต์แวร์" จากมุมมองของสาขาวิชา ซอฟต์แวร์ตลาดมวลชนแทบจะเป็นอุตสาหกรรมใหม่เมื่อเทียบกับการพัฒนาซอฟต์แวร์แบบ custom ไม่ว่าจะทำใน-house หรือ out-house เมื่อแพคเกจขายได้เป็นล้าน—หรือแม้แต่เป็นพัน—คุณภาพ ความทันเวลา performance ของ product และต้นทุนการสนับสนุนกลายเป็นประเด็นหลัก แทนที่จะเป็นต้นทุนการพัฒนาที่สำคัญมากสำหรับระบบ custom
Power tools for the mind. วิธีที่ดีที่สุดในการปรับปรุง productivity ของ programmer ระบบสารสนเทศเพื่อการจัดการ (MIS) คือการเดินไปที่ร้านคอมพิวเตอร์ใกล้บ้านแล้วซื้อสิ่งที่พวกเขาจะสร้างขึ้นมา(จากชั้นวาง) นี่ไม่ใช่เรื่องไร้สาระ การมีซอฟต์แวร์ shrink-wrapped ราคาถูกและทรงพลังได้ตอบสนองความต้องการมากมายที่เมื่อก่อนต้องใช้แพคเกจแบบ custom เครื่องมือทรงพลังสำหรับสมองเหล่านี้เหมือนกับสว่านไฟฟ้า เลื่อย และเครื่องขัด มากกว่าเครื่องมือผลิตขนาดใหญ่ที่ซับซ้อน การรวมเครื่องมือเหล่านี้เป็นชุดที่เข้ากันได้และเชื่อมโยงกัน เช่น Microsoft Works และ ClarisWorks ที่ผสานรวมได้ดีกว่า ให้ความยืดหยุ่นมหาศาล และเช่นเดียวกับชุดเครื่องมือไฟฟ้าของเจ้าบ้าน การใช้เครื่องมือชุดเล็ก ๆ บ่อยครั้งสำหรับงานต่าง ๆ มากมายจะช่วยพัฒนาความคุ้นเคย เครื่องมือเหล่านี้ต้องเน้นความง่ายในการใช้งานสำหรับผู้ใช้ทั่วไป ไม่ใช่มืออาชีพ
Ivan Selin ประธานบริษัท American Management Systems, Inc. เขียนถึงผมในปี 1987:
ผมขอโต้แย้งกับคำพูดของคุณที่ว่า package ไม่ได้เปลี่ยนแปลงมากนัก... ผมคิดว่าคุณมองข้ามนัยสำคัญของข้อสังเกตของคุณที่ว่า [ software packages ] "อาจจะมีความทั่วไปมากกว่าและปรับแต่งได้มากกว่าแต่ก่อน แต่ก็ไม่มาก" ถึงจะยอมรับข้อความนี้ตามที่เห็น ผมเชื่อว่าผู้ใช้มองว่า package มีทั้งความทั่วไปมากกว่าและปรับแต่งได้ง่ายกว่า และการรับรู้นี้ทำให้ผู้ใช้เปิดรับ package มากขึ้น ในกรณีส่วนใหญ่ที่บริษัทของผมพบ เป็น [ ผู้ใช้ปลายทาง ] ไม่ใช่คนซอฟต์แวร์ ที่ไม่ eager to use packages เพราะคิดว่าจะสูญเสียฟีเจอร์หรือฟังก์ชันที่จำเป็น ดังนั้น prospect ของการปรับแต่งที่ง่ายจึงเป็นจุดขายสำคัญสำหรับพวกเขา
ผมคิดว่า Selin พูดถูกทีเดียว—ผมประเมินทั้งระดับความสามารถในการปรับแต่งของ package และความสำคัญของมันต่ำเกินไป
Object-Oriented Programming—Will a Brass Bullet Do? (Object-Oriented Programming—กระสุนทองเหลืองใช้ได้ไหม?)
Building with bigger pieces. ภาพประกอบที่เปิดบทนี้เตือนเราว่าถ้าเราประกอบชิ้นส่วนต่าง ๆ ซึ่งแต่ละชิ้นอาจซับซ้อน และทั้งหมดถูกออกแบบให้มี interface ที่ราบรื่น โครงสร้างที่ค่อนข้างซับซ้อนก็จะประกอบเข้าด้วยกันได้อย่างรวดเร็ว
มุมมองหนึ่งของ object-oriented programming คือมันเป็นระเบียบวินัยที่บังคับใช้ modularity และ interface ที่สะอาด มุมมองที่สองเน้น encapsulation ข้อเท็จจริงที่ว่าเราไม่สามารถมองเห็น—ไม่ต้องพูดถึงการออกแบบ—โครงสร้างภายในของชิ้นส่วนได้ มุมมองอีกแบบเน้น inheritance ที่มาพร้อมกับโครงสร้าง hierarchical ของคลาส และ virtual functions มุมมองอีกแบบเน้น strong abstract data-typing ที่ให้ความมั่นใจว่า data-type หนึ่ง ๆ จะถูกจัดการโดยการดำเนินการที่เหมาะสมกับมันเท่านั้น
ตอนนี้ระเบียบวินัยใด ๆ เหล่านี้สามารถมีได้โดยไม่ต้องใช้ Smalltalk หรือ C++ ทั้งแพคเกจ—หลายอย่างมาก่อนเทคโนโลยี object-oriented ความน่าสนใจของแนวทาง object-oriented ก็เหมือนกับยา multivitamin: ในครั้งเดียว (นั่นคือการ retrain programmer) คุณก็ได้มาทั้งหมด มันเป็นแนวคิดที่มีแนวโน้มดีมาก
Why has object-oriented technique grown slowly? ในเก้าปีหลังจาก "NSB" ความคาดหวังก็เพิ่มขึ้นเรื่อย ๆ ทำไมการเติบโตถึงช้า? มีทฤษฎีมากมาย James Coggins ผู้เขียนคอลัมน์ "The Best of comp.lang.c++" ใน The C++ Report เป็นเวลาสี่ปี เสนอคำอธิบายนี้:
ปัญหาคือ programmer ที่ทำงานด้าน O-O ได้ทดลองใน application ที่ซ้ำซากและตั้งเป้าหมาย abstraction ต่ำเกินไป แทนที่จะสูง ตัวอย่างเช่น พวกเขาสร้างคลาสอย่าง linked-list หรือ set แทนที่จะเป็นคลาสอย่าง user-interface หรือ radiation beam หรือ finite-element model โชคไม่ดีที่การตรวจสอบชนิดข้อมูลที่แข็งแกร่งของ C++ ซึ่งช่วยให้ programmer หลีกเลี่ยงข้อผิดพลาด ก็ทำให้การสร้างของใหญ่จากของชิ้นเล็กเป็นเรื่องยากเช่นกัน [22]
เขากลับไปที่ปัญหาพื้นฐานของซอฟต์แวร์ และโต้แย้งว่าวิธีหนึ่งในการจัดการกับความต้องการซอฟต์แวร์ที่ยังไม่ได้รับการตอบสนองคือการเพิ่มขนาดของแรงงานที่มีความสามารถด้วยการ enable และดึงลูกค้าของเรามาร่วมงาน นี่เป็นการสนับสนุนการออกแบบแบบ top-down:
ถ้าเราออกแบบคลาสที่มี granularity ใหญ่ที่ตรงกับแนวคิดที่ลูกค้าของเราทำงานด้วยอยู่แล้ว พวกเขาจะเข้าใจและตั้งคำถามกับการออกแบบที่กำลังเติบโต และพวกเขาสามารถร่วมมือในการออกแบบ test cases ได้ ผู้ร่วมงานด้านจักษุวิทยาของฉันไม่สนใจ stack แต่พวกเขาสนใจ Legendre polynomial shape descriptions ของกระจกตา การ encapsulate เล็ก ๆ ให้ประโยชน์เล็ก ๆ เท่านั้น
David Parnas ซึ่งบทความของเขาเป็นหนึ่งในต้นกำเนิดของแนวคิด object-oriented มองเรื่องนี้แตกต่างออกไป เขาเขียนถึงผม:
คำตอบง่ายมาก มันเป็นเพราะ [ O-O ] ถูกผูกไว้กับภาษาที่ซับซ้อนหลากหลาย แทนที่จะสอนคนว่า O-O เป็นรูปแบบหนึ่งของการออกแบบ และให้หลักการออกแบบแก่พวกเขา กลับมีคนสอนว่า O-O คือการใช้เครื่องมือเฉพาะอย่างหนึ่ง เราสามารถเขียนโปรแกรมที่ดีหรือไม่ดีด้วยเครื่องมือใดก็ได้ ถ้าเราไม่สอนคนถึงวิธีการออกแบบ ภาษาเองก็มีความสำคัญน้อยมาก ผลลัพธ์คือคนออกแบบไม่ดีด้วยภาษาเหล่านี้และได้คุณค่าจากมันน้อยมาก ถ้าคุณค่ามีน้อย มันก็จะไม่เป็นที่นิยม
Front-loaded costs, down-stream benefits. ความเชื่อส่วนตัวของผมคือเทคนิค object-oriented มีอาการที่รุนแรงเป็นพิเศษของโรคที่แสดงถึงการปรับปรุงด้าน methodology หลายอย่าง ต้นทุน upfront สูงมาก—หลัก ๆ คือการ retrain programmer ให้คิดในวิธีที่ใหม่เอี่ยม แต่ยังรวมถึงการลงทุนพิเศษในการเปลี่ยนฟังก์ชันให้เป็นคลาสทั่วไปด้วย ผลประโยชน์ซึ่งผมคิดว่าจริงและไม่ใช่แค่สมมติ เกิดขึ้นตลอดวงจรการพัฒนา แต่ผลประโยชน์ใหญ่ ๆ จะ come to fruition ในระหว่างการสร้างระบบต่อเนื่อง การขยาย และการบำรุงรักษา Coggins กล่าวว่า "เทคนิค object-oriented จะไม่ทำให้โปรเจกต์แรกหรือโปรเจกต์ถัดไปเร็วขึ้น แต่โปรเจกต์ที่ห้าของตระกูลนั้นจะเร็วอย่างน่าตกใจ" [23]
การเดิมพันด้วยเงิน upfront จริง ๆ เพื่อผลประโยชน์ที่คาดการณ์ไว้แต่ยังไม่แน่นอนในอนาคตคือสิ่งที่นักลงทุนทำทุกวัน อย่างไรก็ตาม ในองค์กรพัฒนาซอฟต์แวร์หลายแห่ง มันต้องใช้ความกล้าหาญในการจัดการ ซึ่งเป็นสิ่งหายากกว่าความสามารถทางเทคนิคหรือความชำนาญด้านการบริหาร ผมเชื่อว่าระดับที่รุนแรงของการลงทุน upfront และผลประโยชน์ที่ตามมาทีหลังเป็นปัจจัยเดี่ยวที่ใหญ่ที่สุดที่ทำให้การนำเทคนิค O-O มาใช้ช้าลง ถึงกระนั้น C++ ก็ดูเหมือนจะกำลังแทนที่ C ในหลายชุมชนอย่างต่อเนื่อง
What About Reuse? (แล้วเรื่อง Reuse ล่ะ?)
วิธีที่ดีที่สุดในการโจมตี essence ของการสร้างซอฟต์แวร์คือไม่ต้องสร้างมันเลย Package software เป็นเพียงหนึ่งในวิธีในการทำเช่นนี้ การ reuse โปรแกรมเป็นอีกวิธีหนึ่ง อันที่จริง คำสัญญาของการ reuse คลาสอย่างง่าย พร้อมการปรับแต่งที่ง่ายผ่าน inheritance เป็นหนึ่งในจุดดึงดูดที่แข็งแกร่งที่สุดของเทคนิค object-oriented
เช่นเดียวกับที่มักเกิดขึ้นเสมอ เมื่อเรามีประสบการณ์กับวิธีทำธุรกิจแบบใหม่ วิธีการใหม่ก็ไม่ได้ง่ายอย่างที่คิดในตอนแรก
แน่นอนว่า programmer มักจะ reuse ผลงานของตัวเองอยู่เสมอ Jones กล่าวว่า:
programmer ที่มีประสบการณ์ส่วนใหญ่มี library ส่วนตัวที่ช่วยให้พวกเขาพัฒนาซอฟต์แวร์โดยมีโค้ดที่ reuse ประมาณ 30% โดยปริมาตร Reusability ในระดับองค์กรตั้งเป้าไว้ที่ 75% ของโค้ดที่ reuse โดยปริมาตร และต้องมี library และการสนับสนุนด้านการบริหารเป็นพิเศษ โค้ดที่ reuse ได้ในระดับองค์กรยังหมายถึงการเปลี่ยนแปลงในแนวปฏิบัติด้านบัญชีและการวัดผลโปรเจกต์เพื่อให้เครดิตสำหรับการ reusability [24]
W. Huang เสนอให้จัดตั้ง software factory ด้วยการจัดการแบบ matrix ของผู้เชี่ยวชาญด้านฟังก์ชัน เพื่อใช้ประโยชน์จากแนวโน้มตามธรรมชาติของแต่ละคนในการ reuse โค้ดของตนเอง [25]
Van Snyder จาก JPL ชี้ให้ผมเห็นว่าชุมชนซอฟต์แวร์ทางคณิตศาสตร์มีประเพณีการ reuse ซอฟต์แวร์มายาวนาน:
เราสันนิษฐานว่าอุปสรรคในการ reuse ไม่ได้อยู่ที่ฝ่ายผู้ผลิต แต่อยู่ที่ฝ่ายผู้บริโภค ถ้าวิศวกรซอฟต์แวร์ซึ่งเป็นผู้บริโภคที่มีศักยภาพของ component ซอฟต์แวร์มาตรฐาน รับรู้ว่าการหา component ที่ตรงกับความต้องการและตรวจสอบความถูกต้องนั้นแพงกว่าการเขียนขึ้นมาใหม่ component ใหม่ที่ซ้ำซ้อนก็จะถูกเขียนขึ้น สังเกตว่าเราพูดว่า รับรู้ ข้างต้น ไม่สำคัญว่าต้นทุนที่แท้จริงของการสร้างใหม่คือเท่าไหร่
Reuse ประสบความสำเร็จในซอฟต์แวร์ทางคณิตศาสตร์ด้วยสองเหตุผล: (1) มันเป็นเรื่องลึกลับ ต้องใช้ input ทางปัญญามหาศาลต่อโค้ดหนึ่งบรรทัด และ (2) มีระบบการตั้งชื่อที่เข้มข้นและเป็นมาตรฐาน นั่นคือคณิตศาสตร์ ในการอธิบายฟังก์ชันการทำงานของแต่ละ component ดังนั้นต้นทุนในการสร้าง component ซอฟต์แวร์คณิตศาสตร์ขึ้นใหม่จึงสูง และต้นทุนในการค้นพบฟังก์ชันการทำงานของ component ที่มีอยู่แล้วจึงต่ำ ประเพณีอันยาวนานของวารสารวิชาการที่ตีพิมพ์และรวบรวม algorithm และเสนอในราคาย่อมเยา รวมถึงองค์กรเชิงพาณิชย์ที่เสนอ algorithm คุณภาพสูงมากในราคาที่สูงกว่าเล็กน้อยแต่ก็ยังย่อมเยา ทำให้การค้นพบ component ที่ตรงกับความต้องการง่ายกว่าในสาขาวิชาอื่น ๆ ซึ่งบางครั้งก็ไม่สามารถระบุความต้องการได้อย่างแม่นยำและกระชับ ปัจจัยเหล่านี้ร่วมกันทำให้การ reuse น่าสนใจมากกว่าการสร้างซอฟต์แวร์คณิตศาสตร์ขึ้นมาใหม่
ปรากฏการณ์ reuse เดียวกันนี้พบได้ในหลายชุมชน เช่น ชุมชนที่สร้างโค้ดสำหรับเครื่องปฏิกรณ์นิวเคลียร์ แบบจำลองสภาพอากาศ และแบบจำลองมหาสมุทร ด้วยเหตุผลเดียวกัน แต่ละชุมชนเติบโตมาพร้อมกับตำราเรียนและสัญกรณ์มาตรฐานเดียวกัน
How does corporate-level reuse fare today? มีการศึกษามากมาย แต่ปฏิบัติจริงค่อนข้างน้อยในสหรัฐอเมริกา มีรายงานเล่าต่อ ๆ กันถึงการใช้ reuse ที่มากกว่าในต่างประเทศ [26]
Jones รายงานว่าลูกค้าทุกรายของบริษัทเขาที่มี programmer มากกว่า 5,000 คนมีการวิจัย reuse อย่างเป็นทางการ ในขณะที่ลูกค้าน้อยกว่า 10 เปอร์เซ็นต์ที่มี programmer ต่ำกว่า 500 คนทำเช่นนั้น [27] เขารายงานว่าในอุตสาหกรรมที่มีศักยภาพในการ reuse สูงที่สุด การวิจัย reusability (ไม่ใช่การนำไปใช้) "กำลังดำเนินอยู่อย่างแข็งขันและกระตือรือร้น ถึงแม้จะยังไม่ประสบความสำเร็จอย่างสมบูรณ์" Ed Yourdon รายงานเกี่ยวกับบริษัทซอฟต์แวร์แห่งหนึ่งในมะนิลาที่มี programmer 50 คนจาก 200 คนสร้างเฉพาะโมดูลที่ reuse ได้ให้คนอื่นใช้ "ผมเห็นบางกรณี—การนำไปใช้เกิดจากปัจจัยขององค์กร เช่น โครงสร้างการให้รางวัล ไม่ใช่ปัจจัยทางเทคนิค"
DeMarco บอกผมว่าการมีแพคเกจตลาดมวลชนและความเหมาะสมของมันในฐานะผู้ให้บริการฟังก์ชันทั่วไป เช่น ระบบฐานข้อมูล ได้ลดทั้งแรงกดดันและประโยชน์ส่วนเพิ่มของการ reuse โมดูลของโค้ด application ลงอย่างมาก "โมดูลที่ reuse ได้มักจะเป็นฟังก์ชันทั่วไปอยู่แล้ว"
Parnas เขียนว่า:
Reuse เป็นสิ่งที่พูดง่ายกว่าทำมาก การทำให้มันเกิดขึ้นต้องอาศัยทั้งการออกแบบที่ดีและ documentation ที่ดีมาก แม้เมื่อเราเห็นการออกแบบที่ดี ซึ่งก็ยังเกิดขึ้นไม่บ่อยนัก เราก็จะไม่เห็น component ถูกนำไป reuse ถ้าไม่มี documentation ที่ดี
Ken Brooks ให้ความเห็นเกี่ยวกับความยากในการคาดการณ์ว่าการทำให้ทั่วไปแบบไหนจะจำเป็น: "ผมต้องดัดแปลงสิ่งต่าง ๆ อยู่เสมอ แม้กระทั่งในการใช้ครั้งที่ห้าของ personal user-interface library ของผมเอง"
การ reuse ที่แท้จริงดูเหมือนจะเพิ่งเริ่มต้น Jones รายงานว่าโมดูลโค้ดที่ reuse ได้บางส่วนกำลังถูกเสนอขายในตลาดเปิดในราคาระหว่าง 1 เปอร์เซ็นต์ถึง 20 เปอร์เซ็นต์ของต้นทุนการพัฒนาปกติ [28] DeMarco กล่าวว่า:
ผมเริ่มท้อแท้กับปรากฏการณ์ reuse ทั้งหมดแล้ว แทบจะไม่มี existence theorem สำหรับ reuse เลย เวลาได้ยืนยันว่ามีค่าใช้จ่ายมหาศาลในการทำให้สิ่งต่าง ๆ สามารถ reuse ได้
Yourdon ประมาณค่าใช้จ่ายมหาศาลนี้: "กฎง่าย ๆ คือ component ที่ reuse ได้จะใช้ความพยายามเป็นสองเท่าของ component แบบ 'ใช้ครั้งเดียวทิ้ง'" [29] ผมมองว่าค่าใช้จ่ายนั้นคือความพยายามในการทำ productize component ซึ่งได้กล่าวถึงใน บทที่ 1 ดังนั้นการประมาณอัตราส่วนความพยายามของผมคือสามเท่า
เห็นได้ชัดว่าเรากำลังเห็น reuse ในหลายรูปแบบและหลากหลาย แต่ก็ยังไม่มากเท่าที่เราคาดหวังไว้ในตอนนี้ ยังมีอะไรให้เรียนรู้อีกมาก
Learning Large Vocabularies—A Predictable
but Unpredicted Problem for Software Reuse (การเรียนรู้คำศัพท์จำนวนมาก—ปัญหาที่คาดเดาได้
แต่ไม่ถูกคาดการณ์สำหรับ Software Reuse)
ยิ่งระดับที่เราคิดสูงขึ้นเท่าไหร่ องค์ประกอบความคิดพื้นฐานที่เราต้องจัดการก็ยิ่งมากขึ้นเท่านั้น ดังนั้นภาษาโปรแกรมมิ่งจึงซับซ้อนกว่าภาษาเครื่องมาก และภาษาธรรมชาติก็ซับซ้อนยิ่งกว่านั้นอีก ภาษาระดับสูงมีคำศัพท์ที่ใหญ่กว่า ไวยากรณ์ที่ซับซ้อนกว่า และความหมาย (semantics) ที่สมบูรณ์กว่า
ในฐานะสาขาวิชาหนึ่ง เรายังไม่ได้ครุ่นคิดถึงนัยของข้อเท็จจริงนี้สำหรับการ reuse โปรแกรม เพื่อปรับปรุงคุณภาพและ productivity เราต้องการสร้างโปรแกรมโดยประกอบชิ้นส่วนของฟังก์ชันที่ debug แล้ว ซึ่งมีระดับสูงกว่าคำสั่งในภาษาโปรแกรมมิ่งอย่างมาก ดังนั้น ไม่ว่าเราจะทำสิ่งนี้ผ่าน object class libraries หรือ procedure libraries เราต้องเผชิญกับความจริงที่ว่าเรากำลังเพิ่มขนาดของคำศัพท์ในการเขียนโปรแกรมของเราอย่างรุนแรง การเรียนรู้คำศัพท์เป็นอุปสรรคทางปัญญาส่วนสำคัญที่ไม่น้อยต่อการ reuse
ดังนั้นทุกวันนี้ผู้คนมี class libraries ที่มีสมาชิกมากกว่า 3,000 รายการ หลาย object ต้องการการระบุ parameter และ option variables 10 ถึง 20 ตัว ใครก็ตามที่เขียนโปรแกรมด้วย library นั้นต้องเรียนรู้ syntax (interface ภายนอก) และ semantics (พฤติกรรมเชิงฟังก์ชันโดยละเอียด) ของสมาชิกของมัน ถ้าพวกเขาต้องการเข้าถึงศักยภาพการ reuse ทั้งหมด
งานนี้ไม่ได้สิ้นหวังเลย ผู้ใช้ภาษาพื้นเมืองใช้คำศัพท์มากกว่า 10,000 คำเป็นประจำ คนที่มีการศึกษาสูงยิ่งใช้มากกว่านั้นอีก อย่างใดอย่างหนึ่งเราก็เรียนรู้ syntax และ semantics ที่ละเอียดอ่อนมาก เราแยกความแตกต่างระหว่าง giant, huge, vast, enormous, mammoth ได้อย่างถูกต้อง ผู้คนไม่พูดถึง mammoth deserts หรือ vast elephants
เราต้องการงานวิจัยเพื่อนำองค์ความรู้ขนาดใหญ่เกี่ยวกับวิธีที่มนุษย์เรียนรู้ภาษามาประยุกต์ใช้กับปัญหาการ reuse ซอฟต์แวร์ บทเรียนบางอย่างชัดเจนทันที:
• ผู้คนเรียนรู้ในบริบทของประโยค ดังนั้นเราต้องเผยแพร่ตัวอย่างผลิตภัณฑ์ที่ประกอบสำเร็จจำนวนมาก ไม่ใช่แค่ library ของชิ้นส่วน
• ผู้คนไม่ได้จดจำอะไรเลยนอกจากตัวสะกด พวกเขาเรียนรู้ syntax และ semantics แบบค่อยเป็นค่อยไป ในบริบท โดยการใช้งาน
• ผู้คนจัดกลุ่มกฎการประกอบคำตามคลาสทางไวยากรณ์ ไม่ใช่ตาม subset ที่เข้ากันได้ของ object
Net on Bullets—Position Unchanged (สรุปเรื่องกระสุนเงิน—จุดยืนไม่เปลี่ยนแปลง)
ดังนั้นเรากลับมาที่พื้นฐาน ความซับซ้อนคือธุรกิจที่เราอยู่ และความซับซ้อนคือสิ่งที่จำกัดเรา R. L. Glass ซึ่งเขียนในปี 1988 สรุปมุมมองของผมในปี 1995 ได้อย่างแม่นยำ:
แล้วย้อนกลับไปดู Parnas และ Brooks ได้บอกอะไรแก่เราบ้าง? ว่าการพัฒนาซอฟต์แวร์เป็นธุรกิจที่ยากในเชิงแนวคิด ว่าไม่มีทางออกที่วิเศษใกล้แค่เอื้อม ว่าถึงเวลาแล้วที่ผู้ปฏิบัติจะต้องพิจารณาการปรับปรุงแบบค่อยเป็นค่อยไป แทนที่จะรอ—หรือหวัง—การปฏิวัติ
บางคนในวงการซอฟต์แวร์พบว่านี่เป็นภาพที่น่าท้อใจ พวกเขาคือคนที่ยังคิดว่าความก้าวหน้าครั้งใหญ่อยู่ใกล้แค่เอื้อม
แต่พวกเราบางคน—พวกที่หัวแข็งพอที่จะคิดว่าเราเป็น realist—มองว่านี่เป็นลมหายใจสดชื่น ในที่สุด เราสามารถ focus ที่สิ่งที่เป็นไปได้มากกว่าพายในท้องฟ้า ตอนนี้ บางที เราอาจจะเดินหน้าต่อไปกับการปรับปรุง software productivity แบบค่อยเป็นค่อยไปที่เป็นไปได้ แทนที่จะรอความก้าวหน้าที่ไม่น่าจะมาถึง [30]