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

42

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

นี่เป็นเรื่องปกติ (ไม่ใช่สภาพแวดล้อมขององค์กร) หรือไม่ จะเกิดอะไรขึ้นถ้า "การเขียนโปรแกรม" ของฉันไม่มีอะไรมากไปกว่าการติดไลบรารี่ต่าง ๆ เข้าด้วยกัน?

ฉันรู้เกี่ยวกับ "ไม่ต้องคิดค้นล้อใหม่" แต่จะเกิดอะไรขึ้นเมื่อคุณไม่ได้ประดิษฐ์ล้อเดียวอีกต่อไป

programming-practices libraries code-reuse

— Henrik P. Hessel
แหล่งที่มา

3

คุณหมายถึง "non corporate environment" หรือสภาพแวดล้อมที่ผู้คนไม่ให้ความร่วมมือหรือไม่?

— ไบรอัน Oakley

ฉันคิดว่าเหตุผลที่เราเขียนในอินเทอร์เฟซและคลาสนามธรรมคือไลบรารีของเรามีความเป็นสากลมากขึ้นพึ่งพาน้อยลงมีความยืดหยุ่นมากขึ้น ...

— IAbstract

1

แย่มากตามความจริงแล้วเข็มขัดของพ่อกำลังจะหลุดออกมา

— Thomas Eding

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

— hanzolo

3

ไม่มันไม่ได้ทำให้คุณโปรแกรมเมอร์แย่ แต่มันก็ไม่ได้ทำให้คุณเป็นโปรแกรมเมอร์ที่ดีขึ้นเช่นกัน

85

การใช้ห้องสมุดแทนการพลิกโฉมวงล้อ: เยี่ยมมาก! นั่นเป็นวิธีที่ทุกคนควรทำ คุณไม่ได้รับเงินเพื่อทำสิ่งที่ทำไปแล้ว

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

— user281377
แหล่งที่มา

นั่นคือสิ่งที่ฉันคิดว่า. บางทีฉันควรจะเริ่มต้นโครงการที่มาเปิดที่จะกำจัดความรู้สึกนี้ :)

— เฮนริกพี Hessel

25

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

— Tim Post

5

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

— Rei Miyasaka

12

ทิม: เกี่ยวกับห้องสมุดฉันไม่ต้องเข้าใจว่ามันจะทำอะไรตราบเท่าที่ฉันรู้ว่ามันทำอะไร ตัวอย่างเช่นเราหลายคนใช้ crypto libs; ฉันไม่รู้ว่า AES ทำงานอย่างไร แต่ฉันรู้ว่ามันใช้งานอย่างไรและเมื่อใดจึงจะใช้

— 281377

@Rei Miyasaka ดูเหมือนว่าตัวอย่างข้อมูลมักมีคุณภาพน้อยกว่าห้องสมุดแบบสแตนด์อโลน ฉันตัวฉันเองต้องสร้างตัวอย่างข้อมูลอีกหลายส่วนที่ฉันใช้

— Henrik P. Hessel

24

โปรแกรมเมอร์ที่ดีเขียนโค้ดที่ดี โปรแกรมเมอร์ที่ดีขโมยรหัสที่ดี

— dan_waterworth
แหล่งที่มา

+1 สำหรับสาย มันเป็นต้นฉบับหรือไม่

— apoorv020

ฉันหวังว่าไม่มีมันเป็นคำพูดที่แปลก

— dan_waterworth

ฉันใช้ iPhone ของฉัน แต่ฉันคิดว่ามันเป็นคำพูดจาก Pablo Picasso (แทนที่โปรแกรมเมอร์ด้วยศิลปิน)

— Henrik P. Hessel

21

Good artists copy, Great artists stealปิกัสโซกล่าวว่า

— dan_waterworth

3

คำพูดที่ยอดเยี่ยม คิดว่าฉันจะขโมย ^ H ^ H ^ H ^ H ^ H นำมาใช้ซ้ำ

— Wonko the Sane

24

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

— Eugene Mayevski 'Allied Bits
แหล่งที่มา

13

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

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

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

ฉันรู้ว่าโปรแกรมเมอร์ C ที่เก่งจริงๆที่สามารถนำไลบรารี่ C มาตรฐานไปใช้ได้บางส่วนเป็นเพียงการฝึกหัดเพื่อการเรียนรู้ / การลับคม ความสนุกที่สุดที่ฉันมีในช่วงงานอดิเรกคือการทำงานในห้องสมุด C ใน HelenOS

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

— ทิมโพสต์
แหล่งที่มา

คุณอธิบายความเกลียดชังของฉันกับ jQuery, +1

— aaaaaaaaaaaa

5

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

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

1) ฉันเข้าใจอินเทอร์เฟซไปยังไลบรารีเหล่านั้นอย่างเต็มที่ (ฉันเป็น ASIHTTPRequest ninja!)
2) ฉันกำลังเลือกไลบรารีที่โดยทั่วไปการใช้งานที่กว้างขวางดังนั้นฉันจึงมั่นใจได้ว่าพวกเขาได้ไปสำรวจปัญหาแล้ว (เช่น ASIHTTP, ห้องสมุด JSON ของ Stig Brautaset, ห้องสมุด obj-c ของ Facebook และอื่น ๆ )
3) ความล้มเหลว # 2 มันง่ายพอที่ฉันสามารถเลือกวิธีผ่านมันและค้นหา / แก้ไข / ปรับแต่งสิ่งที่ต้องการค้นหา / แก้ไข / ปรับแต่ง .

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

— แดนเรย์
แหล่งที่มา

3

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

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

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

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

— Joris Meys
แหล่งที่มา

3

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

— เควินไคลน์
แหล่งที่มา

3

การใช้รหัสซ้ำเป็นความคิดที่ดีมาก จะช่วยลดความซ้ำซ้อนและส่งเสริมการบำรุงรักษา

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

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

— pswg
แหล่งที่มา

คุณมาถึงฉันแล้ว ฉันยังอ้างถึงการคัดลอกรหัสหลายบรรทัดของงานของผู้อื่น (ไม่ใช่ไลบรารี่) เนื่องจากมันถูกกฎหมายในกรณีของฉัน คุณคิดอย่างไร?

— Arman

1

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

— pswg

: หนึ่งคำถามสุดท้าย: ดังนั้นตามที่ Mason กล่าวถ้าเช่นฉันพบว่ารหัส 2,500 บรรทัด (อีกครั้งฉันกำลังเน้นว่าไม่ได้ห้องสมุด) ของคุณค่อนข้างมีประโยชน์ในการเริ่มงานของฉันและคุณให้ฉันทำสำเนา คุณคิดว่ามันดีสำหรับฉัน มีจริยธรรมหรือไม่

— Arman

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

— pswg

4

เป็นการดีที่คุณควรเข้าใจวิธีการทำงานของรหัสที่คัดลอก

— Mike Partridge

1

โดยทั่วไปเป็นความคิดที่ดีตราบใดที่ไม่มีปัญหาทางกฎหมาย

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

— Mason Wheeler
แหล่งที่มา

1

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

— Arman

2

@Arman: ลองถามเขา

— Mason Wheeler

1

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

— Darius X.

1

การใช้ซ้ำรหัสอย่างถูกกฎหมายนั้นไม่มีข้อเสียและมี Upside ใหญ่สองรายการ:

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

— Kilian Foth
แหล่งที่มา

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

— Arman

1

การใช้ไลบรารี่และโค้ดขนาดใหญ่ทำให้คุณเป็นโปรแกรมเมอร์ที่ไม่ดีหรือไม่?

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

อย่างไรก็ตาม ...

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

— จิมจี
แหล่งที่มา

0

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

0

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

คุณอาจเสียเวลาโดยตั้งใจหรือ
คุณอาจตั้งใจส่งมอบผลิตภัณฑ์ที่น้อยลง

โปรดจำไว้ว่าทั้งสองอย่างนั้นยากที่จะกำหนดล่วงหน้า

นอกจากนี้ให้ดูที่Not Invented Hereซึ่งโดยทั่วไปเรียกว่ารูปแบบ anit

— Zachary Yates
แหล่งที่มา

0

เพื่อวัตถุประสงค์ที่สมบูรณ์ให้อนุญาตการโต้แย้ง: http://web.archive.org/web/20150326134617/https://michaelochurch.wordpress.com/2015/03/25/never-invent-here-the-even-worse -sibling ของไม่ได้คิดค้น-ที่นี่ /

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

มีความสมดุลอยู่เสมอ

— Dimitrios Mistriotis
แหล่งที่มา

-2

ฉันไม่ได้ใช้ห้องสมุดถ้าจำเป็นจริงๆ การพึ่งพา จำกัด การพกพาและอายุการใช้งาน ฉันมี 34 ปีในการพัฒนาซอฟต์แวร์และต้องการมีอย่างน้อย 1 โปรแกรมของฉันนานกว่า 3 ปีโดยไม่ถูกทำลายจากการสึกกร่อน (เปลี่ยน)

COM (Component Object Model) คำตอบ 17 ปีที่ผ่านมาในทางทฤษฎีที่ยอดเยี่ยมในทางปฏิบัติที่น่าสงสัยส่วนประกอบที่นำมาใช้ซ้ำไม่ได้จริงๆฉันจะใช้องค์ประกอบพื้นฐานมากเท่านั้นและถ้าฉันต้อง

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

Frameworks: Zend, Silverlight, WCF, .NET, ระบบเลเยอร์, ใช่พวกเขาสามารถเพิ่มความเร็วในการพัฒนาเริ่มต้นได้ แต่เมื่อฉันถึงขีด จำกัด เวลาที่ฉันใช้แก้ไขรอยแตกนั้นไม่คุ้มค่ากับความพยายาม พวกเขาอายุเท่าไหร่และพวกเขาไม่สามารถกัดเซาะ?

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

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

— gbjbaanb

-2

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

— Jadzia
แหล่งที่มา