อะไรคือสาเหตุที่นำไปสู่ซอฟต์แวร์ที่มีการทำ overbloated [ปิด]

วันนี้ฉันตัดสินใจที่จะทำการติดตั้งใหม่ทั้งหมดสำหรับไดรเวอร์ Creative Sound Blaster เนื่องจากพวกเขาเริ่มผิดพลาดด้วยตัวเองทุกครั้ง และนั่นหมายความว่าฉันต้องทำตามขั้นตอนการล้างทั้งหมด และนั่นใช้เวลาเกือบ 2 ชั่วโมง ..

และอย่างสุจริตฉันไม่เห็นเหตุผลว่าทำไม! และถึงแม้ว่า Creative, IMHO จะเป็นผู้ชนะอันดับหนึ่งในการผลิตซอฟต์แวร์ที่มีคุณภาพต่ำซึ่งไม่สามารถใช้งานได้ แต่ปัญหาของ bloat นั้นไม่ได้ จำกัด เฉพาะพวกเขาเท่านั้น

พีซีที่มีไดรเวอร์กล้องดิจิตอลของ Canon จะมีรายการ Canon ประมาณ 10 รายการที่เชื่อมต่อกับการเชื่อมต่อทุกประเภท Visual Studio เป็นตัวอย่างที่ดีมีรายการประมาณ 50 รายการสำหรับการติดตั้งแบบเต็มและการซ่อมแซมสิ่งนั้นเป็นไปได้เฉพาะเมื่อใช้ nuking ที่สมบูรณ์ และเมื่อมันยังจัดการทำลายการติดตั้งระบบปฏิบัติการทั้งหมดเมื่อฉันอัพเกรดจาก VS2k8 เป็น VS2k8SP1 หรือบางสิ่งบางอย่าง ตามที่ปรากฎว่าพื้นที่ว่าง 5GB นั้นไม่เพียงพอสำหรับแพทช์ 300Mb ...

ดังนั้นนี่เป็นปัญหาที่แพร่หลาย เกือบทุกแอปพลิเคชั่นทุกวันนี้มักจะมี unpackers, "เพื่อน" หลายคนที่ติดตั้งสปายแวร์มักจะมีไดรเวอร์ประมาณ 600Mb สำหรับทุกสิ่งรวมถึงเครื่องพิมพ์และอื่น ๆ

แต่ทำไม มันเป็นความผิดของนักพัฒนาหรือไม่? แอปพลิเคชั่นเช่นนี้เป็นฝันร้ายที่ให้การสนับสนุนพวกเขาไม่สามารถทำงานได้ 100% ในปัจจุบันและผู้ใช้เกือบทุกคนที่ฉันรู้จักนั้นเป็นลบมากเกี่ยวกับสิ่งที่พวกเขาได้รับเมื่อติดตั้งไดรเวอร์บังคับสำหรับ USB Thumb Drive / เครื่องพิมพ์ / กล้อง / การ์ดเสียง / เบราว์เซอร์

ดูเหมือนว่า NSIS จาก Nullsoft เป็นระบบการตั้งค่าที่สะอาดเพียงอย่างเดียวที่ไม่ได้บวมจากสิ่งที่ฉันรู้ตัวอย่างเช่น Firefox ติดตั้ง ทำความสะอาด xcopy ตามติดตั้งสวยมากไม่มีปัญหาใด ๆ

เหตุใดผู้คนจึงไม่ใช้การตั้งค่าและแอพพลิเคชั่นที่ไม่หยั่งรากกว่า 30 ชั้นของการเชื่อมต่อ เป็นเพราะนักพัฒนาขี้เกียจ? ใช้เครื่องมือ codegen หรือไม่ เป็นเพราะ บริษัท ต่างๆบังคับให้แอพหนาเป็นสิ่งที่ผู้ใช้จะรัก? สาเหตุคืออะไรและมีซอฟต์แวร์หวังว่าจะกลับไปสู่พื้นฐานในสักวันหนึ่งหรือไม่? ขั้นตอนในการหลีกเลี่ยงการเขียน bloat เมื่อคุณเริ่มต้นแอปพลิเคชันใหม่คืออะไร

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

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

หากต้องการอ้างอิง Joel ในStrategy Letter IV: Bloatware และ the 80/20 Myth :

[... ] มีเหตุผลดีๆมากมายสำหรับ bloatware สำหรับหนึ่งถ้าโปรแกรมเมอร์ไม่ต้องกังวลเกี่ยวกับรหัสของพวกเขามีขนาดใหญ่พวกเขาสามารถจัดส่งได้เร็ว [... ] หากผู้จำหน่ายซอฟต์แวร์ของคุณหยุดก่อนที่จะส่งและใช้เวลาสองเดือนบีบรหัสลงเพื่อให้เล็กลง 50% ผลประโยชน์สุทธิที่คุณจะมองไม่เห็น [... ] แต่ความสูญเสียที่คุณรออีกสองเดือนสำหรับเวอร์ชั่นใหม่นั้นชัดเจนและการสูญเสียของ บริษัท ซอฟต์แวร์ที่ต้องยอมแพ้สองเดือนของยอดขายนั้นยิ่งแย่ลงไปอีก

นักพัฒนาซอฟต์แวร์จำนวนมากถูกล่อลวงโดยกฎ "80/20" แบบเก่า มันดูเหมือนว่าจะทำให้ความรู้สึกมาก: 80% ของคนที่ใช้ 20% ของคุณสมบัติ ดังนั้นคุณจะต้องโน้มน้าวตัวเองว่าคุณจะต้องใช้คุณสมบัติ 20% เท่านั้นและคุณยังสามารถขายได้ 80% เป็นจำนวนมาก

น่าเสียดายที่มันไม่เหมือนเดิม 20% ทุกคนใช้ที่แตกต่างกันชุดของคุณลักษณะ [ ... ]

เมื่อคุณเริ่มต้นการตลาด "Lite" ของผลิตภัณฑ์และคุณบอกคน "เดี๋ยวก่อนมัน Lite เพียง 1MB" พวกเขามีแนวโน้มที่จะมีความสุขมากแล้วพวกเขาก็ขอให้คุณถ้ามันมีของพวกเขาคุณลักษณะที่สำคัญและมันไม่ได้ดังนั้น พวกเขาไม่ได้ซื้อผลิตภัณฑ์ของคุณ

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

ดังนั้นตัวติดตั้งแบบเต็มจะต้องรวมรุ่นที่ถูกต้องของทุกการพึ่งพาเพื่อให้แน่ใจว่าทุกอย่างจะทำงานได้อย่างแน่นอนหลังการติดตั้งไม่ว่าสถานะเริ่มต้นของการพึ่งพาแต่ละครั้งในคอมพิวเตอร์เป้าหมาย นี่อาจเป็นสิ่งสำคัญสำหรับแอปพลิเคชันบางประเภทตัวอย่างเช่นแอปพลิเคชันที่ใช้. NET ซึ่งจำเป็นต้องปรับใช้กับระบบ Windows XP

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

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

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

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

• "เราต้องการสิ่งที่ต้องทำ X ลองใช้ห้องสมุด $ BIGFATLIBDESIGNEDFORSOMETHINGELSE เพราะฉันใช้มันในโครงการอื่น"
• "ฉันคิดว่าเราไม่ต้องการส่วนของรหัสนี้อีกต่อไป แต่เพื่อให้แน่ใจว่าไม่มีอะไรผิดพลาดเพียงแค่เก็บมันไว้"
• การทดสอบหน่วยไม่เพียงพอหรือไม่ซึ่งนำไปสู่
• ไม่มีการปรับโครงสร้างใหม่
• ไม่มีการติดตามที่จัดเก็บการตั้งค่าในช่วงหลายปีที่ผ่านมาดังนั้นตอนนี้การตั้งค่าก็มีอยู่ทุกที่
• ...

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

1. นักธุรกิจถามถึงคุณสมบัติที่ป่อง
2. นักพัฒนาใช้คุณลักษณะที่มีการขยายแม้ว่าพวกเขาจะรู้ว่าพวกเขาไม่ควร
3. ลูกค้าชำระเงินสำหรับฟีเจอร์ป่องแม้ว่าพวกเขาต้องการเพียงผลิตภัณฑ์ แต่ไม่ใช่ฟีเจอร์โง่ ๆ
4. นักธุรกิจเชื่อว่าลูกค้าต้องการคุณสมบัติที่ป่อง
5. ไปที่ขั้นตอนที่หนึ่งและทำซ้ำ

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

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

ความเกียจคร้านอย่างต่อเนื่องของมันคือสิ่งที่ทำให้เกิดการขยายตัว (หรือโคลนในบทความน้ำเชื้อในหัวข้อนี้Big Ball of Mud )

ตัวอย่างเช่นที่ที่ฉันทำงานเรามีแอปพลิเคชัน "ดั้งเดิม" C ++ ที่ได้รับการออกแบบมาค่อนข้างดีลูกค้าพูดคุยกับ API ที่คุยกับเซิร์ฟเวอร์ที่ใช้งานฐานข้อมูลได้ ทำทั้งหมดอย่างสมเหตุสมผล เมื่อเร็ว ๆ นี้เราต้องการโมดูลเพิ่มเติม แต่แทนที่จะใช้อย่างถูกต้อง dev ตัดสินใจที่จะใช้สิ่งนี้ใน. NET และที่แย่กว่านั้นเขาตัดสินใจว่าการเข้าถึงข้อมูลผ่าน API นั้นยากเกินไป (ไม่ใช่ แต่ ... ) เขาจะทำการเชื่อมต่อฐานข้อมูล โดยตรง. ดังนั้นคุณจะเห็นว่าระเบียบนี้เกิดขึ้นได้อย่างไร (และทั้งหมดมีข้อตกลงของ TA ที่ทำให้ "เร็ว" มากกว่า "ดี")

ฉันเคยเห็นสิ่งแบบนี้มาก่อนเช่นกัน - ที่เดิมส่วนเล็ก ๆ ของ GUI เป็น html เนื่องจาก dev บางคนคิดว่าเป็นความคิดที่ดีที่จะเขียนข้อมูลในรูปแบบ html และมีหน้าจอ GUI นั้น ดังนั้น 1 ส่วนเล็ก ๆ ทำสิ่งที่แตกต่างจากที่เหลือ

กล่าวโดยย่อความเกียจคร้านนั้นไม่ดีและความสม่ำเสมอนั้นดี (ไม่ว่าจะใช้เทคโนโลยีใด) ฉันควรมีแอปพลิเคชัน All-MFC มากกว่าหนึ่งที่เป็นส่วนหนึ่ง MFC และส่วน Winforms และ WebGL ส่วนหนึ่งที่มีสถาปัตยกรรม back-end ที่แตกต่างกันจำนวนมากผูกทั้งหมดเข้าด้วยกัน