“ ไม่พลิกโฉมพวงมาลัย” ไม่สนใจขีด จำกัด ของความทรงจำของมนุษย์หรือไม่?

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

มีการเน้นย้ำว่าการนำเอา abstractions มาใช้ในการเขียนโปรแกรมซึ่งบ่อยครั้งฉันรู้สึกว่าลำบากใจระหว่าง: 1) แค่เขียนโค้ดบางอย่างที่สั้นและสกปรกด้วยตัวเองหรือ 2) ใช้เวลาในการค้นหาไลบรารี่ / โซลูชันที่แข็งแกร่งกว่า

เช่นเดียวกับเมื่อเร็ว ๆ นี้หนึ่งในผู้เขียนที่นี่เขียนขึ้น (de) serializer สำหรับไฟล์ CSV และฉันไม่สามารถช่วย แต่คิดว่าบางสิ่งบางอย่างเช่นนั้นอาจเป็นเรื่องง่ายมากที่จะหาออนไลน์ถ้ามันไม่ได้มาพร้อมกับมาตรฐาน. NET APIs

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

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

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

มีการเน้นย้ำว่าการนำเอา abstractions มาใช้ในการเขียนโปรแกรมซึ่งบ่อยครั้งฉันรู้สึกว่าลำบากใจระหว่าง: 1) แค่เขียนโค้ดบางอย่างที่สั้นและสกปรกด้วยตัวเองหรือ 2) ใช้เวลาในการค้นหาไลบรารี่ / โซลูชันที่แข็งแกร่งกว่า

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

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

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

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

1. ม้วนของคุณเอง
2. สร้างบางสิ่งบางอย่างบนโซลูชันของคนอื่น

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

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

(หรือสิ่งที่คล้ายกัน) นี้เกิดขึ้นกับฉันในงานก่อนหน้านี้ซึ่งกรอบงานนั้นได้รับผลกระทบจาก Inner Platform Effect อย่างรุนแรง

โดยพื้นฐานแล้วฐานรหัสของพวกเขาวิวัฒนาการมาจากยุคแรก ๆ ของ Windows C / C ++ จากนั้นก็เริ่มที่จะรวบรวมภายใต้ MFC - และเพื่อให้ผู้ดูแลเริ่มผสม MFC และโครงสร้างข้อมูลในบ้านเก่าและส่วนประกอบหน้าต่าง แพลตฟอร์มด้านในไม่ได้รับการบันทึกไว้อย่างดีนัก แต่มันควรจะเป็น "The Way" ในการทำสิ่งต่าง ๆ บนผลิตภัณฑ์นั้นเนื่องจากมีสิ่งอำนวยความสะดวกภายในที่จัดไว้ให้ ฉันมักจะพบว่ามันง่ายกว่าและเร็วกว่าในการเขียนข้อมูลของฉันเองตั้งแต่ต้น (จากพื้นฐาน MFC) แทนที่จะคิดว่าจะทำอย่างไรกับกรอบภายในของ บริษัท

(โอเคดังนั้นนี่ก็เกือบจะตรงกันข้ามกับจุดเริ่มต้นของคุณ - แต่หลักการก็เหมือนกัน hehe! ใช่บางครั้งการทำสิ่งของคุณเองเร็วกว่าการใช้เวลาและความพยายามในการหาสิ่งที่มีอยู่แล้ว วิธีการแก้.)