ควรลบความซับซ้อนเมื่อใด

การแนะนำความซับซ้อนก่อนกำหนดโดยการนำรูปแบบการออกแบบมาใช้ก่อนจำเป็นต้องใช้ไม่ใช่วิธีปฏิบัติที่ดี

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

อย่างไรก็ตามเมื่อความซับซ้อนนั้นถูกนำเสนอและทำงานเหมือนแชมป์เมื่อไหร่ที่คุณลบมัน?

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

เวลาผ่านไปและเจ้าของคนใหม่เข้าครอบครอง เจ้าของคนใหม่นี้ยากจมูกมากทำให้ทุกอย่างง่ายและมีวิธีเดียวเท่านั้นที่จะเพิ่ม

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

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

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

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

แต่ฉันสนใจ 2 สิ่ง (เกี่ยวข้อง)

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

2. แต่ยิ่งฉันกังวลเกี่ยวกับคู่แข่งที่เห็นความซับซ้อนนี้และคิดว่าฉันเพิ่งใช้รูปแบบการออกแบบเพื่อลดเวลาทำงานของฉัน จากนั้นกระจายข่าวลือนี้เพื่อทำร้ายธุรกิจอื่นของฉัน (ฉันเคยได้ยินเรื่องนี้มาแล้ว)

ดังนั้น...

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

แม้ว่าคำถามข้างต้นจะได้รับคำตอบว่า "ไม่" คุณควรที่จะลบความซับซ้อนที่ "ไม่ต้องการ" ออกหากส่งมอบโครงการให้กับคู่แข่ง (หรือคนแปลกหน้า)?

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

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

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

กล่าวโดยสรุปคือการวิเคราะห์ต้นทุน - กำไรและการประเมินความเสี่ยงของทั้งสองเส้นทางและดำเนินการอย่างปลอดภัยมีประสิทธิภาพมากที่สุดและได้ผลกำไรสูงสุด

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

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

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

คำพูดที่พบบ่อยคือ: "ถ้ามันยังไม่พังไม่ต้องแก้ไข"

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

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

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

นอกเหนือจากนี้การเปลี่ยนแปลงที่ไม่สำคัญกับรหัสการทำงานมักก่อให้เกิดความเสี่ยงดังนั้น (ตามที่คนอื่น ๆ ระบุไว้) ลูกค้าควรเห็นด้วยกับ (และชำระ) หากความซับซ้อน "พิเศษ" ในปัจจุบันไม่ทำให้เกิดข้อเสียเปรียบที่สังเกตเห็นได้ (เช่นปัญหาด้านประสิทธิภาพการทำงาน) จะไม่มีเหตุผลอันสมควรที่จะลบออก

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

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

เลขที่

แม้ว่าโดยทั่วไปแล้วคำถามข้างต้นจะตอบว่า "ไม่" ก็ควรที่จะลบความซับซ้อนที่ "ไม่ต้องการ" นี้หากส่งมอบโครงการให้กับคู่แข่ง (หรือคนแปลกหน้า)

ไม่ทำไมคุณต้องเสียเวลาแก้ไขงานที่มีลำดับความสำคัญต่ำเช่นนี้ ไม่เป็นอันตรายต่อโค้ดที่อยู่ที่นั่น

สำหรับคำถามของคุณ: ควรลบความซับซ้อนเมื่อใด

ใช้เวลาของฉันคือถ้ามันยังไม่หักไม่ซ่อมมัน

เพื่อให้สามารถลบความซับซ้อนดังต่อไปนี้จะต้องเป็นจริง:

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

ฉันคิดว่ามีบางอย่างที่ใหญ่กว่าในที่ทำงาน ...

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

ดังนั้นฉันว่าเก็บรหัสและเอกสาร มันเป็นคุณสมบัติของวิธีการใช้งานแอปพลิเคชัน

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

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

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

แม้ว่าคำถามข้างต้นจะได้รับคำตอบว่า "ไม่" คุณควรที่จะลบความซับซ้อนที่ "ไม่ต้องการ" ออกหากส่งมอบโครงการให้กับคู่แข่ง (หรือคนแปลกหน้า)?

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

หากความต้องการมีการเปลี่ยนแปลงคุณสามารถปรับการปล่อยให้เป็นไปได้เนื่องจากความเสี่ยงที่คุณอาจทำลายรหัส (หรือจำนวนงานที่จะลบรูปแบบการผ่าตัด)

ฉันคิดว่ามันเป็นการดีที่จะแยกแยะระหว่างความซับซ้อนโดยไม่ตั้งใจกับความซับซ้อนที่จำเป็นเนื่องจากรูปแบบมักเกี่ยวข้องกับทั้งสองอย่าง

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

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

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