วิธีการเขียนโค้ดที่มีประสิทธิภาพแม้จะถึงกำหนดส่งงานหนัก

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

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

มีเคล็ดลับใดบ้างที่ฉันสามารถทำให้โค้ดของฉันมีประสิทธิภาพ แต่ส่งตรงเวลา

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

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

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

• กินดี
• เข้าฌาน
• นอนหลับให้เต็มที่ (7-9 ชม. แล้วแต่บุคคล)
• งีบเมื่อใดก็ตามที่สมองของคุณเลือน
• เข้าสู่โหมดสลีปด้วยปัญหาที่ยังไม่แก้ อย่าจบวันด้วยทุกอย่างที่สมบูรณ์ ปล่อยให้ภารกิจยาก ๆ ค้างอยู่ - จิตใต้สำนึกของคุณมีประสิทธิภาพอย่างน่าทึ่ง
• สวมใส่เสื้อผ้าที่สะดวกสบาย
• การออกกำลังกาย
• ใช้เวลาในการทำแบบฝึกหัดทางจิต - ซูโดกุ (ไม่ใช่โปรแกรม), ปริศนาอักษรไขว้, การฝึกซ้อมคณิตศาสตร์, ปริศนาเชิงพื้นที่และอื่น ๆ
• ทำการทดลองตามวัตถุประสงค์กับตัวเองเพื่อดูว่าพฤติกรรมใดที่ส่งผลต่อประสิทธิภาพการทำงานของคุณ (คุณต้องมีวิธีที่เชื่อถือได้ในการทดสอบประสิทธิภาพเพื่อให้ทำงานได้)
• เข้าร่วมเพื่อสุขภาพจิตวิญญาณของคุณ
• กางเกงผ้าฝ้าย
• เข้าร่วมเพื่อสุขภาพทางเพศของคุณ
• หาเวลาให้กับครอบครัวและเพื่อนของคุณ
• มีความเชี่ยวชาญในสิ่งที่อยู่นอกอาชีพของคุณ (ดนตรี, การทำอาหาร, กีฬา, ฯลฯ ) และพบปะกับผู้อื่นที่ทำสิ่งเดียวกัน
• สำหรับบางคนสัตว์เลี้ยงเป็นสิ่งจำเป็น

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

แหล่งที่มา:

1. Your Miracle Brain: เพิ่มพลังสมองของคุณเพิ่มหน่วยความจำยกอารมณ์เพิ่ม IQ และความคิดสร้างสรรค์ของคุณป้องกันและย้อนกลับอายุผู้สูงอายุ
2. ตนเองเชิงปริมาณ
3. เซทโรเบิร์ตส์ - วิทยาศาสตร์อเมริกัน

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

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

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

มองหางานอื่น

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

หากเวลาผ่านไปนานเกินไป (พูดสองสามปีหรือมากกว่านั้น) คุณจะมีช่วงเวลาที่ยากลำบากมากที่จะได้รับการว่าจ้างจากทุกที่ยกเว้นงานที่ต้องทำอย่างรวดเร็วโดยที่โค้ดคุณภาพไม่ได้รับการยอมรับความเร็วเท่านั้น

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

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

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

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

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

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

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

โรเบิร์ตครอบคลุมประเด็นที่สำคัญที่สุด

ฉันทำงานในสภาพแวดล้อมเช่นนั้นรหัสไม่สามารถใช้งานได้ (ไม่สามารถ) ได้นานกว่าหกเดือน มีกฎง่ายๆที่ฉันนึกถึง:

1. ใช้ไลบรารีโอเพ่นซอร์สโซลูชันของบุคคลที่สาม ฯลฯ การเรียนรู้ที่เกี่ยวข้องจะได้รับผลตอบแทนจากการบำรุงรักษาและการดีบักที่น้อยลง อย่างไรก็ตามหากคุณติดกับห้องสมุดรถคุณจะถึงวาระ
2. ให้แน่ใจว่าการออกแบบของคุณจะขยายได้อย่างเข้มงวด ข้อกำหนดที่จำเป็น: งานส่วนใหญ่มาเป็นการปรับปรุงไม่ใช่การสร้างคุณลักษณะใหม่
3. สร้างแผนการทดสอบที่เข้มงวด รับการประกันคุณภาพหรือทำการทดสอบอัตโนมัติเพื่อให้แน่ใจว่าการทดสอบการถดถอย
4. ใช้เครื่องมืออัจฉริยะ - IDE, ยูทิลิตี้การสร้างรหัส ฯลฯ
5. ให้สิ่งต่าง ๆ ที่สามารถกำหนดค่าได้มากที่สุด (ด้านพลิกเพิ่มความพยายามในการทดสอบ)
6. ปรับปรุงความเร็วในการพิมพ์ของคุณ :-)

ในขั้นตอนการออกแบบการพูดคุยกับเพื่อนร่วมงาน

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

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

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

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

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

สุดท้าย: เท่าที่ผมได้กล่าวก่อน * คุณจะต้องเรียนรู้วิธีที่จะบอกว่าไม่มี

* วิธีการเขียนโปรแกรมในตารางที่แน่นมาก?

หากพวกเขากำหนดขอบเขตและเวลาทั้งหมดที่คุณสามารถทำได้เพื่อกำหนดเวลาส่งมอบคือคุณภาพที่ลดลง

หากเป็นไปได้ที่จะลดคุณภาพภายนอกซึ่งมองเห็นได้โดยผู้มีส่วนได้ส่วนเสียอย่าทำให้คุณภาพภายในแย่ลง

ฉันไม่คิดว่าการพัฒนาตนเองจะช่วยคุณได้ในสถานการณ์นี้ ถ้ามีอะไรก็ต้องขอโทษด้วย

พยายามเข้าไปในประตูเมื่อประเมินงาน หัวหน้าของคุณจะประเมินได้ว่าคุณต้องทำอะไรนานแค่ไหน?

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

พวกเขาไม่สามารถตัดขอบเขตหรือย้ายกำหนดเวลาถ้าคุณไม่บอกอะไรเลย

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

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

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

เหนือสิ่งอื่นใดโปรดจำไว้ว่าไม่มีในภายหลัง

ฉันเป็นนักพัฒนา. Net ที่ทำงานกับเว็บแอปพลิเคชัน

สิ่งที่ฉันเริ่มทำคือ -

หากเป็นรหัส C # ฉันพยายามเขียนรหัสนั้นใน LinqPad ก่อน (ถ้าเป็นไปได้)

หากเป็นรหัส Javascript ฉันจะเขียนรหัสนั้นก่อนและทดสอบเป็น jsfiddle / jsbin (ถ้าเป็นไปได้)

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