ฉันจะหลีกเลี่ยงความรู้สึกตลอดเวลาได้อย่างไรหากฉันสร้างโปรแกรมขึ้นใหม่ทั้งหมดตั้งแต่เริ่มต้นฉันจะทำได้ดีกว่ามาก? [ปิด]

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

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

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

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

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

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

นี่เป็นประสบการณ์ที่พบบ่อยมาก

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

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

"ทุกคนมีแผนจนกว่าพวกเขาจะถูกชกต่อหน้า"

จะทำอย่างไรกับมัน

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

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

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

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

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

แม้ในกรณีที่มีความสุขคุณอาจเรียนรู้คุณสมบัติภาษาใหม่ที่จะช่วยทำให้การออกแบบดีขึ้น

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

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

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

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

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

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

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

แต่อย่าแปลกใจถ้าหลังจาก N ปีคุณกลับมาที่รหัสนี้และคิดว่า "มันเป็นเรื่องยุ่งเหยิง"

จำมนต์นี้:

ที่สมบูรณ์แบบเป็นศัตรูของดี

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

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

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

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

ฉันพยายามวางแผนล่วงหน้า แต่ฉันไม่สามารถคาดการณ์ล่วงหน้าได้ทุกอย่างจนกว่าฉันจะเริ่มใช้รหัส

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

คุณเคยได้ยินเกี่ยวกับการเคลื่อนไหวเปรียวหรือไม่? เป็นวิธีคิดที่เราให้ความสำคัญกับ "การตอบสนองต่อการเปลี่ยนแปลง" เมื่อเทียบกับ "การทำตามแผน" (เหนือสิ่งอื่นใด) นี่คือรายการ (อ่านอย่างรวดเร็ว) คุณยังสามารถอ่านเกี่ยวกับ Big Design Up Front (BDUF) และสิ่งที่เป็นข้อผิดพลาด

น่าเสียดายที่รุ่น "Agile" ของ บริษัท เป็นพวงปลอม (ปริญญาโทที่ได้รับการรับรองกระบวนการหนักในนามของ "Agile" บังคับให้มีการต่อสู้แย่งชิงบังคับให้ครอบคลุมรหัส 100% ฯลฯ ) และมักส่งผลให้กระบวนการเปลี่ยนแปลง asinine เพราะผู้จัดการ คิดว่า Agile เป็นกระบวนการและเป็น bullet เงิน (ซึ่งมันไม่ใช่) อ่านแถลงการณ์ที่คล่องแคล่วฟังผู้ที่เริ่มต้นการเคลื่อนไหวนี้เช่นลุงบ็อบและมาร์ตินฟาวเลอร์และอย่าถูกดูดเข้าไปใน "Corporate Agile" เวอร์ชั่นไร้สาระ

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

ฉันคิดว่าเราทุกคนสามารถตกลงกันได้ว่าnumpyเป็นซอฟต์แวร์ทางวิทยาศาสตร์ที่ประสบความสำเร็จ อินเทอร์เฟซของพวกเขามีขนาดเล็กใช้งานได้ดีสุด ๆ และทุกอย่างเล่นด้วยกันอย่างดี โปรดทราบว่าnumpy's คู่มืออ้างอิงอย่างชัดเจนแนะนำ TDD: https://docs.scipy.org/doc/numpy-1.15.1/reference/testing.html ฉันเคยใช้ TDD ในอดีตสำหรับซอฟต์แวร์ถ่ายภาพ SAR (Synthetic Aperature Radar): และฉันยังสามารถยืนยันได้ว่ามันทำงานได้ดีมากสำหรับโดเมนนั้น

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

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

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

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

HTH

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

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

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

เพื่อเพิ่มคำตอบที่ยอดเยี่ยมอื่น ๆ ที่นี่สิ่งหนึ่งที่ฉันคิดว่ามีประโยชน์คือการรู้ว่าคุณต้องการไปที่ไหน

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

อาจใช้เวลานาน แต่ขั้นตอนส่วนใหญ่จะปรับปรุงโค้ดและผลลัพธ์สุดท้ายจะคุ้มค่า

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

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

เนื่องจากการพัฒนาซอฟต์แวร์กลายเป็นกระแสหลักในยุค 90 เท่านั้นจริงๆแล้วมันมีอายุประมาณ 30 ปี เราได้เรียนรู้ว่ามันไม่ได้มีระเบียบวินัยทางวิศวกรรมมากนักในฐานะสังคมศาสตร์และเราเพิ่งจะเริ่มต้นเท่านั้น

ใช่คุณจะลองใช้ TDD, Refactoring, Function Programming, รูปแบบ Repository, Event Sourcing, MV บางอย่าง, Java Script (<- ทำสิ่งนี้, มันบ้า), การผูกแบบจำลอง, ไม่มี SQL, คอนเทนเนอร์, Agile, SQL (<- ทำสิ่งนี้ มันทรงพลัง)

ไม่มีใครแก้ไขได้ แม้แต่ผู้เชี่ยวชาญก็ยังจับฟางอยู่

ยินดีต้อนรับและถูกเตือนว่าเป็นสถานที่โดดเดี่ยว แต่น่าหลงใหลอย่างแน่นอน

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

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

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

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

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

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

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

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

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

นั่นคือวิธีที่คุณจะดีขึ้นและไม่ใช่สิ่งที่คุณควรหลีกเลี่ยง

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

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

ในที่สุดสัญชาตญาณของคุณจะเปลี่ยนจากการคิดว่า "ฉันสามารถเขียนระบบนี้ได้ดีกว่ามาก" เป็นการคิด "ความผิดปกติของระบบนี้อาจบ่งบอกถึงความซับซ้อนบางอย่างที่ไม่ชัดเจนในทันที"