คุณจะเอาชนะอคติการเข้ารหัสของคุณเองได้อย่างไรเมื่อส่งมอบรหัสเดิม? [ปิด]

ในฐานะโปรแกรมเมอร์เรามักภาคภูมิใจในทักษะของเราอย่างมากและมีความคิดเห็นที่แข็งแกร่งมากเกี่ยวกับโค้ดที่ 'ดี' และ 'ไม่ดี'

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

คุณเตรียมความพร้อมทางใจเมื่อพยายามทำให้งานของโปรแกรมเมอร์อื่นดีขึ้นอย่างไร

สำหรับฐานรหัสมรดกใด ๆ วิธีที่ถูกต้องเพื่อเตรียมความพร้อมตัวเองจิตใจสำหรับการรับมือกับมันคือการเริ่มต้นด้วยการเขียนการทดสอบหน่วยสำหรับมัน

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

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

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

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

และสุดท้ายมาทำความเข้าใจว่านี่คือสาเหตุที่คุณมีงานทำ

หัวเราะที่มันพยายามอย่างหนักที่จะไม่ตัดสินมันมากเกินไปและแค่ผ่านมันไป มันไม่ดีเลยที่จะเป็น code-nazi ที่แท้จริง ... มีบางอย่างที่ 'ดีพอ' หรือแม้แต่ 'ดีพอในเวลา' มีหลายครั้งที่บางสิ่งบางอย่างได้รับการพัฒนาหรือใช้เป็นผ้าพันแผลในการแก้ไขวิกฤตการณ์

ถ้ามันแย่จริง ๆ ลองดูว่าคุณสามารถสร้างเคสสำหรับการเขียนซ้ำได้ไหม .. ถ้ามันไม่สำคัญลองเข้าและออก

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

บ่อยครั้งที่ฉันพบว่ามีประโยชน์ในการทำความเข้าใจกับสิ่งที่ devs ดั้งเดิมคิดว่าดี

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

บางครั้งคุณพบว่า dev ดั้งเดิมนั้นแย่จริง ๆ แต่คุณมีความคิดว่าพวกเขาขายอะไรไม่ดีในตอนนั้น

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

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

หากฉันมีเวลาฉันจะโจมตีและฆ่ารหัสที่เขียนไม่ดี

มันเป็นสงคราม

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

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

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

ในอดีตเมื่อฉันไม่ได้มีเวลาที่จะฉี่ตามรหัสของคนอื่นและเอาชนะมันในรูปแบบ "ของฉัน" ฉันต้องหันไปทำงานเป็นตัวขับเคลื่อน:

ฉันกำลังพยายามเพิ่มอะไรในรหัสนี้ / แก้ไข / ทำงาน?

ฉันกำลังทำงานเพื่อบรรลุเป้าหมายนั้นหรือไม่? ถ้าไม่หยุดทำและย้อนกลับไปเป็นครั้งสุดท้ายที่ฉันทำการเปลี่ยนแปลงเชิงงาน

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

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

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

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

วันนี้ฉันทำงานโดยเฉพาะรหัสดั้งเดิมและฉันคิดเสมอว่า"โอ้% sh% t พวกเขาคิดอะไรอยู่?" . จากนั้นฉันก็เริ่มเขียนการทดสอบหน่วยสำหรับโค้ดและนั่นคือจุดที่ฉันต้องวิเคราะห์โฟลว์การควบคุมและการพึ่งพา

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

สำหรับฉันมันจะช่วยให้คิดว่ารหัสของฉันจะมีลักษณะเดียวกันกับตัวเองเมื่อฉันกลับมาใน 12 เดือน

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

นี่คือเครื่องหมายของรหัสที่ไม่ดีอย่างแท้จริง:

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

การขาดการทดสอบอัตโนมัติไม่ได้หมายความว่ารหัสไม่ถูกต้อง แต่หมายความว่าโครงการไม่ดี

นี่ไม่ใช่เรื่องของรสนิยม วิธีปฏิบัติเหล่านี้ทำให้การบำรุงรักษาโปรแกรมมีราคาแพงกว่ามาก

คุณเตรียมตัวอย่างไร

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