รหัสการพิสูจน์อักษรในอนาคต

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

ก่อนอื่นมีบางสิ่งที่ต้องการคำอธิบาย:

• การพิสูจน์ในอนาคตไม่ได้เพิ่มเนื้อหา
• การตรวจสอบในอนาคตคือการทำให้แน่ใจว่าคุณสามารถได้อย่างง่ายดายเพิ่มรหัส / คุณสมบัติโดยไม่ทำลายการทำงานที่มีอยู่

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

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

2c ของฉัน

อย่าเขียนรหัสที่จะไม่ใช้เป็นเวลานาน มันจะไร้ประโยชน์เพราะส่วนใหญ่จะไม่เหมาะกับความต้องการในเวลานั้น (ซึ่งคุณนิยามยังไม่ทราบ)

ทำให้โค้ดมีเสถียรภาพในสถานการณ์ที่ไม่คาดคิดทำให้สามารถกู้คืนได้อย่างรวดเร็วหรือล้มเหลว แต่อย่าเขียนโค้ดเพื่อใช้ในอนาคต

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

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

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

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

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

ดังนั้นโดยทั้งหมดให้สร้างรหัสการพิสูจน์ในอนาคต (NASA ยังคงส่งยานอวกาศขึ้นโดยใช้ Fortran) แต่อย่าเขียนโค้ด 'ในกรณี'

ลองคิดดูว่าคุณเปิดใช้งานโค้ดในสภาพแวดล้อมการผลิตและคิดว่า "ขอบคุณพระเจ้าที่ฉันเขียนเมื่อ 2 ปีที่แล้ว!"

รหัสควรแก้ไข / ขยายได้อย่างง่ายดาย อย่าเพิ่มโค้ดที่ไม่จำเป็นในทันทีเพราะสิ่งนี้ให้ความรู้สึกที่ผิด ๆ เกี่ยวกับความปลอดภัยและสิ้นเปลืองทรัพยากร dev / test ในโลกที่มีการเปลี่ยนแปลงข้อกำหนด

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

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

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

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

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

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

รหัสที่ดีสะอาดและมีการจัดการที่ดีเป็นหลักฐานในอนาคตในแง่ที่ทำให้การเปลี่ยนแปลงและการเพิ่มเติมนั้นง่ายต่อการใช้อย่างถูกต้อง

"การพิสูจน์ในอนาคต" ที่ดีที่สุดหมายถึง "การออกแบบแบบคู่ - หลวม" 80% ของเวลาที่ผู้คนหมายถึง "ยืดหยุ่น" เมื่อพวกเขาพูดว่า "หลักฐานในอนาคต" บางครั้งพวกเขาก็พูดว่าลองและฟังดูเท่ แต่อย่างน้อยพวกเขากำลังส่งมอบงานตรงเวลาที่ใช้ได้

"หลักฐานในอนาคต" ที่เลวร้ายที่สุดนั้นไร้ความหมาย 20% ของเวลามันเป็นข้ออ้างที่จะเสียเวลาค้นคว้าเทคโนโลยีทางเลือกแทนที่จะส่งอะไรบางอย่าง พวกเขาไม่ได้ส่งอะไร (หรือสิ่งที่พวกเขากำลังส่งมีความซับซ้อนเกินไปสำหรับปัญหาที่เกิดขึ้นในมือ)

มีสองกรณีขอบ

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

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

   เราจะต้องส่งมอบโครงการ "A" โดยรู้ว่าโครงการ "B" จะนำไปสู่การเขียน "A" ทันที ในกรณีนี้เท่านั้นเราอาจพิสูจน์ได้ในอนาคต "A"

YAGNI = You Are Not Gonna จำเป็นต้องใช้มัน

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

โปรดดูที่: ชุบทอง

ไม่สนใจหัวเรื่องของคำถามและติดประเด็นหลักเกี่ยวกับ "การใส่สิ่งของเพราะบางคนอาจต้องการมันสักวัน" ...

คำตอบคือไม่ ไม่เคย อย่าเขียนรหัสที่คุณไม่ต้องการในวันนี้ นี่คือเหตุผล:

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

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