คอฟฟี่เบรค #64. วิธีเขียนโค้ดที่สะอาด เหตุใด Java จึงดีกว่า C++ สำหรับระบบที่มีความหน่วงต่ำ

วิธีเขียนโค้ดที่สะอาด

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

1. โค้ดไม่ควรเพียงใช้งานได้แต่ยังสามารถอ่านได้ด้วย

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

2. ภายหลังหมายถึงไม่เคย

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

3. คุณสมบัติควรมีขนาดเล็ก

กฎข้อแรกของการเขียนฟังก์ชันคือ ฟังก์ชันเหล่านี้ควรมีขนาดเล็ก โดยมีความยาวไม่เกิน 20 บรรทัด ยิ่งฟังก์ชันเล็กลงและยิ่งเน้นไปที่งานเดียวมากเท่าใด การค้นหาชื่อที่ดีก็จะยิ่งง่ายขึ้นเท่านั้น สำหรับอาร์กิวเมนต์ของฟังก์ชัน จำนวนในอุดมคติคือ 0 ถัดมาคือ 1, 2 แต่คุณควรพยายามให้มีอาร์กิวเมนต์ไม่เกิน 3 ตัว จะ บรรลุผลนี้ได้อย่างไร ฟังก์ชั่นควรเขียนตามหลักการของความรับผิดชอบเดี่ยวและเปิด/ปิด

4. การทำสำเนาโค้ดไม่ดี

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

5. ความคิดเห็นที่ดีเพียงอย่างเดียวคือความคิดเห็นที่คุณพบวิธีที่จะไม่เขียน

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

6. วัตถุเปิดเผยพฤติกรรม แต่ไม่ใช่ข้อมูล

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

7. การทดสอบ

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

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

8. การจัดการข้อผิดพลาดและข้อยกเว้น

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

9. ชั้นเรียน

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

10. การจัดรูปแบบ

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

หลักการพัฒนาโปรแกรม

ใช้เทคนิคต่อไปนี้และโค้ดของคุณจะสะอาดอยู่เสมอ: การตั้งชื่อตัวแปร การเลือกชื่อที่เหมาะสม (การตั้งชื่อที่ดี) เป็นสิ่งสำคัญในการทำให้โค้ดสามารถอ่านได้และสามารถบำรุงรักษาได้ “คุณควรเลือกชื่อตัวแปรให้มีความรับผิดชอบเช่นเดียวกับที่คุณทำกับลูกหัวปีของคุณ” การเลือกชื่อที่ดีมักเป็นเรื่องท้าทายสำหรับนักพัฒนา สิ่งนี้ต้องใช้ทักษะการอธิบายที่ดีและมีภูมิหลังทางวัฒนธรรมร่วมกัน Clean Code คือโค้ดที่อ่านและปรับปรุงโดยนักพัฒนาที่แตกต่างกันโดยสิ้นเชิง ชื่อของตัวแปร ฟังก์ชัน หรือคลาสควรตอบคำถามพื้นฐานทั้งหมด: เหตุใดเอนทิตีนี้จึงมีอยู่ อะไร และนำไปใช้อย่างไร หากชื่อต้องการความคิดเห็น หมายความว่าชื่อนั้นไม่ได้เปิดเผยสาระสำคัญของสิ่งที่อธิบายอย่างเพียงพอ ชื่อที่ยาวมีความสำคัญมากกว่าชื่อที่สั้น และชื่อที่ค้นหาได้ก็ดีกว่าค่าคงที่ ชื่อที่มีตัวอักษรเดี่ยวสามารถใช้เป็นตัวแปรท้องถิ่นภายในวิธีการแบบสั้นเท่านั้น ความยาวของชื่อจะต้องตรงกับขอบเขต ชื่อวิธีการต้องเป็นคำกริยาหรือวลีกริยา ชื่อชั้นเรียนจะต้องไม่เป็นคำกริยา การพึ่งพาควรถูกเก็บไว้ให้น้อยที่สุด เป็นการดีกว่าที่จะพึ่งพาสิ่งที่คุณควบคุมมากกว่าสิ่งที่คุณไม่สามารถควบคุมได้ มิฉะนั้นสิ่งเหล่านี้จะควบคุมคุณ ความแม่นยำ. โค้ดทุกชิ้นควรอยู่ในตำแหน่งที่ผู้อ่านคาดหวังว่าจะพบมัน การนำทางผ่าน codebase ควรใช้งานง่าย และความตั้งใจของนักพัฒนาควรมีความชัดเจน การทำความสะอาด อย่าทิ้งโค้ดที่ไม่มีประโยชน์ไว้ในโค้ดเบส (เก่าและไม่ได้ใช้หรือสร้างขึ้น "เผื่อไว้") อีกต่อไป ลดความซ้ำซ้อนและสร้างนามธรรมง่ายๆ ตั้งแต่เนิ่นๆ การทำให้เป็นมาตรฐาน เมื่อเขียนโค้ด คุณควรปฏิบัติตามสไตล์และแนวทางปฏิบัติที่กำหนดไว้สำหรับพื้นที่เก็บข้อมูล มีวินัยในตนเอง เมื่อเทคโนโลยีที่ใช้พัฒนาและมีเทคโนโลยีใหม่ปรากฏขึ้น นักพัฒนามักมีความปรารถนาที่จะเปลี่ยนแปลงและปรับปรุงบางสิ่งในโค้ดที่มีอยู่ อย่ายอมแพ้ต่อการโฆษณาเร็วเกินไป: ศึกษาสแต็คใหม่อย่างละเอียดและเพื่อจุดประสงค์เฉพาะเท่านั้น การรักษาโค้ดเบสของคุณให้สะอาดเป็นมากกว่าการแสดงความสุภาพต่อเพื่อนร่วมงานทั้งในปัจจุบันและอนาคต มันเป็นสิ่งจำเป็นสำหรับการอยู่รอดในระยะยาวของโปรแกรม ยิ่งโค้ดของคุณสะอาดมากขึ้นเท่าไร นักพัฒนาก็จะยิ่งมีความสุขมากขึ้นเท่านั้น ผลิตภัณฑ์ก็จะยิ่งดีขึ้นและใช้งานได้นานขึ้นเท่านั้น

เหตุใด Java จึงดีกว่า C++ สำหรับระบบที่มีความหน่วงต่ำ

ที่มา: StackOverflow ในฐานะนักพัฒนา เราทุกคนรู้ว่ามีสองวิธีในการทำสิ่งต่างๆ: ดำเนินการด้วยตนเอง ช้าและน่ารำคาญ หรือโดยอัตโนมัติ ยากและรวดเร็ว ฉันสามารถใช้ปัญญาประดิษฐ์เพื่อเขียนบทความนี้ให้ฉันได้ สิ่งนี้สามารถช่วยฉันประหยัดเวลาได้มาก - AI สามารถสร้างบทความได้หลายพันบทความต่อวินาที แต่บรรณาธิการของฉันคงไม่มีความสุขที่รู้ว่าต้องใช้เวลาสองปีในการสร้างบทความแรก สถานการณ์ที่คล้ายกันเกิดขึ้นเมื่อพัฒนาระบบซอฟต์แวร์ที่มีค่าหน่วงเวลาต่ำ ภูมิปัญญาดั้งเดิมก็คือ การใช้สิ่งอื่นนอกเหนือจาก C++ คงจะบ้ามาก เพราะสิ่งอื่นมีเวลาแฝงมากเกินไป แต่ฉันมาที่นี่เพื่อโน้มน้าวให้คุณมีความคิดที่ตรงกันข้าม ขัดกับสัญชาตญาณ และเกือบจะนอกรีต: เมื่อพูดถึงการบรรลุเวลาแฝงที่ต่ำในระบบซอฟต์แวร์ Java จะดีกว่า ในบทความนี้ ฉันต้องการยกตัวอย่างเฉพาะของซอฟต์แวร์ที่ให้ค่าความหน่วงต่ำ: ระบบการซื้อขาย อย่างไรก็ตาม ข้อโต้แย้งที่นำเสนอนี้สามารถนำไปใช้กับเกือบทุกสถานการณ์ที่ต้องการหรือต้องการเวลาแฝงต่ำ ง่ายกว่าที่จะหารือเกี่ยวกับการพัฒนาที่ฉันมีประสบการณ์ และความจริงก็คือความหน่วงนั้นวัดได้ยาก ทั้งหมดนี้ขึ้นอยู่กับสิ่งที่คุณหมายถึงโดยเวลาแฝงที่ต่ำ ลองคิดดูตอนนี้

ได้รับปัญญา

เนื่องจาก C++ มีความใกล้เคียงกับฮาร์ดแวร์มากขึ้น นักพัฒนาส่วนใหญ่จะบอกคุณว่าการเขียนโค้ดในภาษานี้ให้ข้อได้เปรียบด้านความเร็ว ในสถานการณ์ที่มีเวลาแฝงต่ำ เช่น การซื้อขายด้วยความเร็วสูง ซึ่งเสี้ยววินาทีสามารถสร้างความแตกต่างระหว่างซอฟต์แวร์ที่ใช้งานได้กับการเปลืองพื้นที่ดิสก์แบบเดิม C++ ถือเป็นมาตรฐานทองคำ อย่างน้อยมันก็เคยเป็นแบบนั้น แต่ความจริงก็คือธนาคารและนายหน้าขนาดใหญ่หลายแห่งใช้ระบบที่เขียนด้วยภาษา Java และฉันหมายถึงเขียนด้วยภาษา Java ไม่ใช่เขียนด้วย Java แล้วตีความด้วย C++ เพื่อลดเวลาในการตอบสนอง ระบบเหล่านี้กำลังกลายเป็นมาตรฐานแม้กระทั่งสำหรับธนาคารเพื่อการลงทุนระดับ 1 แม้ว่าระบบเหล่านี้จะช้ากว่าก็ตาม แล้วเกิดอะไรขึ้น? ใช่ C++ อาจมี "เวลาแฝงต่ำ" เมื่อพูดถึงการรันโค้ด แต่แน่นอนว่าไม่ใช่เวลาแฝงต่ำอย่างแน่นอนเมื่อพูดถึงการปรับใช้คุณสมบัติใหม่ หรือแม้แต่การค้นหานักพัฒนาที่สามารถเขียนมันได้

ความแตกต่าง (จริง) ระหว่าง Java และ C ++

ปัญหาเวลาในการพัฒนาเป็นเพียงจุดเริ่มต้นเมื่อพูดถึงความแตกต่างระหว่าง Java และ C++ ในระบบโลกแห่งความเป็นจริง เพื่อให้เข้าใจถึงคุณค่าที่แท้จริงของแต่ละภาษาในบริบทนี้ เรามาเจาะลึกกันอีกสักหน่อย อันดับแรก สิ่งสำคัญคือต้องจำเหตุผลที่แท้จริงว่า C++ เร็วกว่า Java ในสถานการณ์ส่วนใหญ่: ตัวชี้ C++ คือที่อยู่ของตัวแปรในหน่วยความจำ ซึ่งหมายความว่าซอฟต์แวร์สามารถเข้าถึงตัวแปรแต่ละตัวได้โดยตรง และไม่จำเป็นต้องรวบรวมข้อมูลผ่านตารางที่เน้นการคำนวณเพื่อค้นหาตัวแปรเหล่านั้น หรืออย่างน้อยก็สามารถแก้ไขได้ด้วยการระบุว่าพวกมันอยู่ที่ไหน เพราะด้วย C++ คุณมักจะต้องจัดการอายุการใช้งานและความเป็นเจ้าของอ็อบเจ็กต์อย่างชัดเจน ด้วยเหตุนี้ เว้นแต่คุณจะเก่งในการเขียนโค้ด (ทักษะที่ต้องใช้เวลาหลายสิบปีกว่าจะเชี่ยวชาญ) C++ จะต้องใช้เวลาหลายชั่วโมง (หรือสัปดาห์) ในการแก้ไขจุดบกพร่อง และอย่างที่ใครก็ตามที่ได้พยายามดีบักกลไก Monte Carlo หรือเครื่องมือทดสอบ PDE จะบอกคุณว่า การพยายามดีบักการเข้าถึงหน่วยความจำในระดับพื้นฐานอาจใช้เวลานานมาก พอยน์เตอร์ที่ผิดพลาดเพียงตัวเดียวอาจทำให้ทั้งระบบล่มได้อย่างง่ายดาย ดังนั้นการเปิดตัวเวอร์ชันใหม่ที่เขียนด้วยภาษา C++ จึงเป็นเรื่องที่น่ากลัวอย่างแท้จริง แน่นอนว่านั่นไม่ใช่ทั้งหมด ผู้ที่ชื่นชอบการเขียนโปรแกรมด้วย C++ จะชี้ให้เห็นว่าตัวรวบรวมขยะของ Java ได้รับผลกระทบจากความล่าช้าที่ไม่เป็นเชิงเส้น โดยเฉพาะอย่างยิ่งเมื่อทำงานกับระบบเดิม ดังนั้นการส่งอัพเดตไปยังโค้ด Java โดยไม่ทำให้ระบบไคลเอนต์เสียหายอาจทำให้ระบบช้ามากจนใช้งานไม่ได้ เพื่อเป็นการตอบสนอง ฉันอยากจะชี้ให้เห็นว่ามีการทำงานหลายอย่างในช่วงทศวรรษที่ผ่านมาเพื่อลดเวลาแฝงที่สร้างโดย Java GC ตัวทำลาย LMAXตัวอย่างเช่น เป็นแพลตฟอร์มการซื้อขายที่มีเวลาแฝงต่ำซึ่งเขียนด้วย Java ซึ่งสร้างเป็นเฟรมเวิร์กที่มี “การโต้ตอบทางกลไก” กับฮาร์ดแวร์ที่ทำงานอยู่และไม่จำเป็นต้องล็อค ปัญหาสามารถบรรเทาลงเพิ่มเติมได้หากคุณสร้างระบบที่ใช้กระบวนการบูรณาการและการส่งมอบอย่างต่อเนื่อง (CI/CD) เนื่องจาก CI/CD อนุญาตให้ปรับใช้การเปลี่ยนแปลงโค้ดที่ทดสอบแล้วโดยอัตโนมัติ เนื่องจาก CI/CD ให้แนวทางที่ทำซ้ำเพื่อลดเวลาแฝงในการเก็บรวบรวมขยะ โดยที่ Java สามารถปรับปรุงและปรับให้เข้ากับสภาพแวดล้อมฮาร์ดแวร์ที่เฉพาะเจาะจงได้ทีละน้อย โดยไม่ต้องใช้กระบวนการที่ต้องใช้ทรัพยากรมากในการเตรียมโค้ดสำหรับข้อกำหนดฮาร์ดแวร์ที่แตกต่างกันก่อนที่จะจัดส่ง เนื่องจากการรองรับ Java ของ IDE นั้นกว้างกว่า C++ มาก กรอบงานส่วนใหญ่ (Eclipse, IntelliJ IDEA) จึงอนุญาตให้คุณรีแฟกเตอร์ Java ได้ ซึ่งหมายความว่า IDE สามารถปรับโค้ดให้เหมาะสมเพื่อประสิทธิภาพเวลาแฝงต่ำ แม้ว่าความสามารถนี้จะยังคงจำกัดเมื่อทำงานกับ C++ แม้ว่าโค้ด Java จะไม่ตรงกับความเร็วของ C++ แต่นักพัฒนาส่วนใหญ่ยังคงพบว่าการบรรลุประสิทธิภาพที่ยอมรับได้ใน Java นั้นง่ายกว่าใน C++

เราหมายถึงอะไรโดย "เร็วขึ้น"?

ในความเป็นจริง มีเหตุผลที่ดีที่จะสงสัยว่า C++ นั้น "เร็วกว่า" จริงๆ หรือยังมี "เวลาแฝงที่ต่ำกว่า" กว่า Java อีกด้วย ฉันรู้ว่าฉันกำลังเข้าสู่น่านน้ำที่ค่อนข้างมืดมน และนักพัฒนาหลายคนก็เริ่มตั้งคำถามกับสุขภาพจิตของฉัน แต่ฟังฉันหน่อยสิ ลองจินตนาการถึงสถานการณ์นี้: คุณมีนักพัฒนาสองคน - คนหนึ่งเขียนด้วยภาษา C++ และอีกคนเขียนด้วยภาษา Java และคุณขอให้พวกเขาเขียนแพลตฟอร์มการซื้อขายความเร็วสูงตั้งแต่เริ่มต้น ด้วยเหตุนี้ ระบบที่เขียนด้วยภาษา Java จะใช้เวลาในการทำธุรกรรมการค้าให้เสร็จสิ้นนานกว่าระบบที่เขียนด้วยภาษา C++ อย่างไรก็ตาม Java มีอินสแตนซ์ของพฤติกรรมที่ไม่ได้กำหนดน้อยกว่า C++ มาก ขอยกตัวอย่างเพียงตัวอย่างเดียว การทำดัชนีภายนอกอาร์เรย์ถือเป็นจุดบกพร่องทั้งใน Java และ C++ หากคุณทำสิ่งนี้โดยไม่ได้ตั้งใจในภาษา C++ คุณอาจได้รับ segfault หรือ (บ่อยกว่านั้น) คุณจะจบลงด้วยตัวเลขสุ่ม ใน Java การออกไปนอกขอบเขตจะทำให้เกิด ข้อผิดพลาด ArrayIndexOutOfBoundsExceptionเสมอ ซึ่งหมายความว่าการดีบักใน Java นั้นง่ายกว่ามาก เนื่องจากข้อผิดพลาดมักจะถูกระบุทันทีและตำแหน่งของข้อผิดพลาดนั้นง่ายต่อการติดตาม นอกจากนี้ อย่างน้อยจากประสบการณ์ของผม Java ดีกว่าในการรับรู้ว่าโค้ดส่วนใดไม่จำเป็นต้องรัน และโค้ดใดมีความสำคัญต่อการทำงานของซอฟต์แวร์ของคุณ แน่นอน คุณสามารถใช้เวลาหลายวันในการปรับแต่งโค้ด C++ ของคุณเพื่อที่จะไม่มีโค้ดที่ไม่เกี่ยวข้องเลย แต่ในโลกแห่งความเป็นจริง ซอฟต์แวร์ทุกชิ้นมีส่วนขยายตัว และ Java จะดีกว่าในการจดจำมันโดยอัตโนมัติ ซึ่งหมายความว่าในโลกแห่งความเป็นจริง Java มักจะเร็วกว่า C++ แม้จะวัดค่าเวลาแฝงมาตรฐานก็ตาม และแม้ว่าจะไม่เป็นเช่นนั้นก็ตาม ความแตกต่างของเวลาในการตอบสนองระหว่างภาษาก็มักจะถูกครอบงำโดยปัจจัยอื่น ๆ ที่ไม่ใหญ่พอที่จะสำคัญแม้แต่ในการซื้อขายที่มีความเร็วสูง

ประโยชน์ของ Java สำหรับระบบที่มีความหน่วงต่ำ

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

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

• เวลาในการพัฒนาที่สั้นลงของ Java ยังหมายความว่าในโลกแห่งความเป็นจริง ซอฟต์แวร์ที่เขียนด้วย Java สามารถปรับให้เข้ากับการเปลี่ยนแปลงฮาร์ดแวร์ (หรือแม้แต่กลยุทธ์การซื้อขายใหม่) ได้เร็วกว่า C++

• หากคุณเจาะลึกลงไป คุณจะเห็นว่าแม้แต่การเพิ่มประสิทธิภาพซอฟต์แวร์ Java ก็สามารถทำได้เร็วกว่า (เมื่อพิจารณาทั่วทั้งซอฟต์แวร์) มากกว่างานที่คล้ายกันใน C ++

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

ข้อสรุป

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