Legacy Code คืออะไร และใช้งานอย่างไร
ที่มา: Dou ไม่ช้าก็เร็ว โปรแกรมเมอร์อาจจะต้องเผชิญกับโค้ดรุ่นเก่า เพื่อลดผลที่ตามมาจากคนรู้จักนี้ ฉันได้เลือกเคล็ดลับและตัวอย่างที่เป็นประโยชน์จากประสบการณ์ของตัวเอง โดยเฉพาะอย่างยิ่งการทำงานกับระบบ Java รุ่นเก่าคุณสมบัติดั้งเดิม
Legacy คือโค้ดของคนอื่น ซึ่งมักจะแย่มากจนโดยทั่วไปไม่ชัดเจนว่าจะใช้งานอย่างไร และหากคุณต้องทำงานกับระบบเดิม นอกเหนือจากโค้ดเก่าแล้ว คุณยังจะต้องเผชิญกับ:- ด้วยเทคโนโลยีที่ล้าสมัย
- สถาปัตยกรรมที่แตกต่างกัน
- ขาดหรือไม่มีเอกสารครบถ้วน
-
เราไม่สามารถดูหมิ่นระบบที่สร้างคนนับล้านหรือเข้าถึงได้โดยคนหลายพันคนต่อวัน ไม่ว่ามันจะเขียนได้แย่แค่ไหนก็ตาม โค้ดที่น่าขยะแขยงนี้ก็ยังคงอยู่จนถึงการผลิตและใช้งานได้ตลอด 24 ชั่วโมงทุกวัน
-
เนื่องจากระบบนี้นำเงินมาจริง การทำงานกับระบบจึงมาพร้อมกับความรับผิดชอบที่ยิ่งใหญ่ นี่ไม่ใช่การเริ่มต้น แต่เป็นสิ่งที่ผู้ใช้จะได้ร่วมงานด้วยในวันพรุ่งนี้ นอกจากนี้ยังแสดงถึงต้นทุนของข้อผิดพลาดที่สูงมาก และประเด็นนี้ไม่ได้อยู่ในคำกล่าวอ้างของลูกค้า แต่อยู่ในสถานการณ์จริง
วิศวกรรมย้อนกลับ
เพื่อให้ทำงานกับโค้ดเดิมได้สำเร็จ คุณจะต้องใช้เทคนิควิศวกรรมย้อนกลับ ขั้นแรก คุณต้องอ่านโค้ดอย่างละเอียดเพื่อทำความเข้าใจวิธีการทำงานอย่างชัดเจน นี่เป็นข้อบังคับ เนื่องจากเรามักจะไม่มีเอกสารประกอบ หากเราไม่เข้าใจแนวความคิดของผู้เขียน เราจะทำการเปลี่ยนแปลงพร้อมกับผลที่ตามมาที่คาดเดาไม่ได้ เพื่อป้องกันตัวเองจากสิ่งนี้ คุณต้องเจาะลึกโค้ดที่อยู่ติดกันด้วย และในเวลาเดียวกันไม่เพียงเคลื่อนไหวในเชิงกว้างเท่านั้น แต่ยังเคลื่อนไหวในเชิงลึกด้วย วิธีการที่เรียกว่ามีข้อผิดพลาดอยู่ที่ไหน? รหัสที่เรียกมันมาจากไหน? ในโปรเจ็กต์เดิม "ลำดับชั้นการโทร" และ "ลำดับชั้นประเภท" ถูกใช้บ่อยกว่าสิ่งอื่นใด คุณจะต้องใช้เวลาส่วนใหญ่กับดีบักเกอร์: ประการแรกเพื่อค้นหาข้อผิดพลาดและประการที่สองเพื่อทำความเข้าใจว่าทุกอย่างทำงานอย่างไร สำหรับเอกสารประกอบ การหันไปใช้โบราณคดีอุตสาหกรรมก็ไม่ใช่ความคิดที่ดี การขุดค้นเอกสารเก่าๆ ที่ไหนสักแห่งและพูดคุยกับผู้ที่จำได้ว่าโค้ดที่คุณได้รับมานั้นเขียนอย่างไรจึงมีประโยชน์มาก การใช้เทคนิคเหล่านี้ไม่ช้าก็เร็วคุณจะเริ่มเข้าใจโค้ดไม่มากก็น้อย แต่เพื่อป้องกันไม่ให้ความพยายามของคุณสูญเปล่า คุณต้องบันทึกผลการวิจัยของคุณทันที ในการทำเช่นนี้ ฉันแนะนำให้วาดไดอะแกรมบล็อกหรือไดอะแกรมลำดับ แน่นอนว่าคุณจะขี้เกียจ แต่คุณต้องทำเช่นนี้อย่างแน่นอน ไม่เช่นนั้นภายในหกเดือนหากไม่มีเอกสาร คุณจะต้องค้นหาโค้ดนี้เหมือนเป็นครั้งแรก
อย่าเขียนโค้ดซ้ำ
สิ่งที่สำคัญที่สุดในกระบวนการพัฒนาคือการเอาชนะตัวเองให้ตรงเวลา และไม่พยายามเขียนโค้ดใหม่ทั้งหมดตั้งแต่เริ่มต้น ประมาณว่าต้องใช้เวลากี่ปี ไม่น่าเป็นไปได้ที่ลูกค้าจะต้องการใช้เงินจำนวนมากในการทำสิ่งที่ได้ผลอยู่แล้วซ้ำ สิ่งนี้ไม่เพียงใช้กับระบบโดยรวมเท่านั้น แต่ยังรวมถึงส่วนใดส่วนหนึ่งของระบบด้วย แน่นอนว่าพวกเขาอาจให้เวลาคุณหนึ่งสัปดาห์เพื่อแก้ไขปัญหา และอีกหนึ่งสัปดาห์เพื่อแก้ไขปัญหาบางอย่าง แต่ไม่น่าจะให้เวลาคุณสองเดือนในการเขียนส่วนหนึ่งของระบบอีกครั้ง ให้ใช้ฟังก์ชันใหม่ในลักษณะเดียวกับโค้ดที่เหลือแทน กล่าวอีกนัยหนึ่ง หากโค้ดเก่า คุณไม่ควรถูกล่อลวงให้ใช้เทคโนโลยีที่สวยงามใหม่ๆ เพราะโค้ดดังกล่าวจะอ่านยากมาก ตัวอย่างเช่น คุณอาจเผชิญกับสถานการณ์เหมือนที่เรามี ส่วนหนึ่งของระบบเขียนด้วย Spring MVC และส่วนหนึ่งเขียนด้วยเซิร์ฟเล็ตเปล่า และหากจำเป็นต้องเพิ่มอย่างอื่นในส่วนที่เขียนด้วยเซิร์ฟเล็ต เราก็เพิ่มมันในลักษณะเดียวกัน - ในเซิร์ฟเล็ตเคารพผลประโยชน์ทางธุรกิจ
ต้องจำไว้ว่างานใด ๆ ถูกกำหนดตามมูลค่าของธุรกิจเป็นอันดับแรก หากคุณไม่ได้พิสูจน์ให้ลูกค้าเห็นถึงความจำเป็นในการเปลี่ยนแปลงบางอย่างจากมุมมองทางธุรกิจ การเปลี่ยนแปลงเหล่านี้จะไม่เกิดขึ้น และเพื่อที่จะโน้มน้าวลูกค้า คุณต้องพยายามยืนแทนเขาและเข้าใจความสนใจของเขา โดยเฉพาะอย่างยิ่ง หากคุณต้องการปรับโครงสร้างใหม่เพียงเพราะโค้ดอ่านยาก คุณจะไม่ได้รับอนุญาตให้ทำมัน และคุณต้องอยู่กับมัน หากคุณทนไม่ได้จริงๆ คุณสามารถจัดระเบียบโค้ดใหม่อย่างเงียบๆ ทีละน้อย โดยกระจายงานไปตามตั๋วธุรกิจ หรือโน้มน้าวลูกค้าว่าสิ่งนี้จะช่วยลดเวลาที่ต้องใช้ในการค้นหาข้อผิดพลาด และลดต้นทุนในที่สุดทดสอบ
เห็นได้ชัดว่าการทดสอบเป็นสิ่งจำเป็นในทุกโครงการ แต่เมื่อทำงานกับระบบเดิม จะต้องให้ความสนใจเป็นพิเศษกับการทดสอบด้วย เนื่องจากผลกระทบของการเปลี่ยนแปลงที่เกิดขึ้นนั้นไม่สามารถคาดเดาได้เสมอไป คุณจะต้องมีผู้ทดสอบอย่างน้อยเท่ากับนักพัฒนา ไม่เช่นนั้นคุณน่าจะเก่งเรื่องระบบอัตโนมัติอย่างไม่น่าเชื่อ ในโครงการของเรา การทดสอบประกอบด้วยขั้นตอนต่อไปนี้:- การตรวจสอบ เมื่อมีการตรวจสอบฟังก์ชันการใช้งานของฟีเจอร์ในสาขาที่แยกต่างหาก
- ความเสถียรเมื่อมีการตรวจสอบสาขาการเผยแพร่ซึ่งคุณสมบัติทั้งหมดจะถูกรวมเข้าด้วยกัน
- การรับรอง เมื่อมีการเรียกใช้สิ่งเดียวกันอีกครั้งในกรณีทดสอบที่แตกต่างกันเล็กน้อยในสภาพแวดล้อมการรับรองที่ใกล้เคียงกับการใช้งานจริงมากที่สุดในแง่ของคุณลักษณะของฮาร์ดแวร์และการกำหนดค่า
ทำ DevOps และ Release อย่างเป็นทางการ
ขั้นตอนการปล่อยอาจเป็นดังนี้ เมื่อการพัฒนาเสร็จสมบูรณ์และขั้นตอนการทดสอบสองหรือสามขั้นตอนเสร็จสิ้น เราจะเขียนอีเมลถึงทีม DevOps 36 ชั่วโมงก่อนเวลาเผยแพร่ที่คาดไว้ หลังจากนี้ เราจะโทรหาทีม Devops และหารือเกี่ยวกับการเปลี่ยนแปลงทั้งหมดในสภาพแวดล้อม (เราจะแจ้งให้พวกเขาทราบเกี่ยวกับการเปลี่ยนแปลงทั้งหมดในฐานข้อมูลและการกำหนดค่า) เรามีเอกสารสำหรับการเปลี่ยนแปลงทุกครั้ง (ตั๋วในจิระ) จากนั้น ในระหว่างการเปิดตัว ทุกคนที่เกี่ยวข้องกับสิ่งนี้จะมารวมตัวกัน และทุกคนพูดว่าพวกเขากำลังทำอะไรอยู่: “เราอัปโหลดฐานข้อมูลแล้ว” “เรารีสตาร์ทเซิร์ฟเวอร์ดังกล่าว” “เราไปทำการทดสอบการถดถอยในสภาพแวดล้อมการใช้งานจริง ” หากมีสิ่งผิดปกติเกิดขึ้น ขั้นตอนการย้อนกลับการเผยแพร่จะเริ่มขึ้น ตามที่อธิบายไว้อย่างชัดเจนในเอกสารการเผยแพร่ต้นฉบับ - หากไม่มีเอกสารดังกล่าว เราจะลืมบางสิ่งบางอย่างหรือสับสนอย่างแน่นอนควบคุมคุณภาพโค้ด
และสุดท้าย การตรวจสอบโค้ดเป็นแนวทางปฏิบัติที่ไม่ได้ใช้ในทุกโครงการด้วยเหตุผลบางประการ จะดีมากหากโค้ดทุกชิ้นได้รับการตรวจทานโดยคนมากกว่าหนึ่งคน แม้แต่ในทีมที่แข็งแกร่งมาก จุดบกพร่องบางอย่างก็มักจะถูกค้นพบในระหว่างกระบวนการตรวจสอบโค้ด และหากมีคนดูหลายคน จำนวนจุดบกพร่องที่ระบุก็จะเพิ่มขึ้น ยิ่งไปกว่านั้น บางครั้งผู้วิจารณ์คนที่สามหรือสี่ก็พบสิ่งที่แย่ที่สุดเครื่องมือที่ทำให้การเขียนเอกสารทางเทคนิคง่ายขึ้น
ที่มา: Dzone โปรแกรมเมอร์ส่วนใหญ่ไม่ชอบเขียนเอกสารทางเทคนิค ผู้เชี่ยวชาญด้านจิตวิทยา Gerald Weinberg เรียกเอกสารประกอบว่า "น้ำมันละหุ่งของการเขียนโปรแกรม": นักพัฒนาชอบที่จะอ่านมัน แต่พวกเขาแค่เกลียดการเขียนมันเอง
การขาดคำแนะนำหรือแผนการทำงานที่ว่างเปล่าส่งผลให้ขาดข้อมูลเกี่ยวกับการทำงานของส่วนต่างๆ ของซอฟต์แวร์ สิ่งนี้ทำให้ประสบการณ์ของผู้ใช้โค้ดแย่ลงในที่สุด เนื่องจากหากไม่มีเอกสารประกอบ พวกเขาไม่สามารถพึ่งพาความถูกต้องและประโยชน์ของผลิตภัณฑ์ได้ เพื่อให้โปรแกรมเมอร์สร้างนิสัยในการเขียนเอกสารได้ง่ายขึ้น ฉันขอแนะนำให้ใส่ใจกับเครื่องมือที่ยอดเยี่ยมสี่อย่างที่ตอนนี้เกือบทุกคนสามารถใช้ได้
หน้า GitHub
ในปัจจุบันคงไม่มีนักพัฒนาเพียงรายเดียวที่ไม่มีประสบการณ์ในการทำงานกับ GitHub นอกจากนี้ยังเป็นสถานที่ที่ดีเยี่ยมสำหรับโปรแกรมเมอร์ที่ต้องการจัดเก็บเอกสารต่างๆ หลายๆ คนใช้ Readme มาตรฐานในโค้ดเบสของตนเพื่อให้คำแนะนำวิธีการง่ายๆ แก่ผู้ใช้ แต่นี่ไม่ใช่วิธีเดียวที่จะสร้างเอกสารประกอบบน GitHub ด้วยGitHub Pagesคุณจะได้รับมากกว่าการโฮสต์เพจโปรเจ็กต์ของคุณ รวมถึงเอกสารประกอบและบทช่วยสอน คุณมีความสามารถในการโต้ตอบโดยตรงกับที่เก็บ GitHub ทั้งหมด ช่วยให้นักพัฒนาสามารถอัปเดตเอกสารประกอบได้ในลักษณะเดียวกับที่พวกเขาอัปเดตโค้ด ยิ่งไปกว่านั้น คุณสามารถใช้Jekyll ได้ที่นี่ ซึ่งจะช่วยให้คุณแปลงมาร์กอัปของคุณให้เป็นข้อความธรรมดาหรือเป็นหน้าเว็บแบบเต็มได้
GO TO FULL VERSION