✍🏼 คิดให้ดีก่อน “เขียนใหม่” – ภาคสอง

นี่เป็นบทความแปลนะครับ ต้นฉบับมาจากโจเอล สโพลสกี้ Things You Should Never Do, Part I เค้าเขียนดีมากถึงข้อควรระวังก่อนการเริ่มโครงการเขียนโค๊ดใหม่แทนโค๊ดเก่า ลองอ่านกันดูครับ

อ่านภาคแรกได้ที่นี่: คิดให้ดีก่อน Re Write — ภาคหนึ่ง

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

เมื่อไรก็ตามที่โปรแกรมเมอร์พูดว่าโค๊ดของเค้าเละตุ้มเป๊ะ (อย่างที่พวกเค้าพูดอยู่ตลอดเวลา) มันมีสิ่งที่ไม่ถูกต้องอยู่สามจำพวก

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

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

สาม โค๊ดมันอาจจะโคตรเละเทะน่าเกลียด โปรเจกต์นึงที่ผมเคยทำงานด้วยมีตัวแปรที่ใช้เก็บข้อมูลตัวหนึ่งถูกตั้งชื่อว่า “ฟักค์สตริง — FuckedString” ส่วนอีกโปรเจกต์หนึ่งเริ่มต้นด้วยรูปแบบการตั้งชื่อตัวแปรที่ขึ้นต้นด้วยอันเดอร์สกอร์แต่ก็มาเปลี่ยนเป็นอะไรที่เป็นมาตรฐานมากขึ้นด้วยการขึ้นต้นด้วยตัวเอ็มเล็กตามด้วยอันเดอร์สกอร์ “m_” นั่นทำให้ครึ่งนึงของโค๊ดขึ้นต้นด้วยอันเดอร์สกอร์อีกครึ่งนึ่งเป็นเอ็มอันเดอร์สกอร์ซึ่งดูน่าเกลียด แต่ว่ากันตรงๆนะ นี่คือเรื่องที่คุณแก้ไขมันได้ภายในเวลาห้านาทีด้วยการใช้มาโครในอีแมคส์ ไม่ใช้เรื่องที่ต้องเขียนใหม่ทั้งหมด

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

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