ข้อสมมติฐานการเขียนโปรแกรมที่ใช้เวลานานและไม่ถูกต้อง [ปิด]

ฉันกำลังทำการวิจัยเกี่ยวกับข้อผิดพลาดทั่วไปและข้อสันนิษฐานที่ไม่ดีของวิศวกรซอฟต์แวร์จูเนียร์ (และอาจอาวุโส)

ข้อสันนิษฐานที่ถือครองยาวนานที่สุดของคุณที่ได้รับการแก้ไขในที่สุด

ตัวอย่างเช่นฉันเข้าใจผิดว่าขนาดของจำนวนเต็มไม่ใช่มาตรฐานและขึ้นอยู่กับภาษาและเป้าหมายแทน ค่อนข้างน่าอายที่จะพูด แต่ก็มี

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

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

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

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

ผู้คนรู้ว่าพวกเขาต้องการอะไร

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

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

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

แก้ไข: คำตอบนี้เป็นชุมชน -wiki เพื่อเอาใจผู้คนที่อารมณ์เสียที่คำตอบนี้ให้ฉันตัวแทน

ฉันรู้ว่าปัญหาด้านประสิทธิภาพอยู่ที่ใดโดยไม่ทำโปรไฟล์

ว่าฉันควรมีจุดทางออกเดียวจากฟังก์ชั่น / วิธี

ผู้เขียนโปรแกรมที่ไม่เข้าใจสิ่งที่ฉันกำลังพูดถึง

ซอฟต์แวร์ bugfree นั้นเป็นไปได้

ตัวแปรสมาชิกส่วนตัวนั้นเป็นส่วนตัวของอินสแตนซ์ไม่ใช่คลาส

ฉันคิดว่าการพิมพ์แบบคงที่กำลังนั่งอยู่ที่คีย์บอร์ด

ให้คุณเข้าใจปัญหาก่อนที่จะเริ่มพัฒนา

คนฉลาดฉลาดกว่าฉันเสมอ

ฉันสามารถเอาชนะตัวเองได้จริง ๆ เมื่อฉันทำผิดพลาดและมักจะถูกบอกเลิกเพราะตัวเองเลิก ฉันเคยเงยหน้าขึ้นมาด้วยความหวาดกลัวต่อนักพัฒนาจำนวนมากและมักจะคิดว่าเนื่องจากพวกเขารู้มากกว่าฉันในXพวกเขาจึงรู้มากกว่าฉัน

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

คุณธรรมของเรื่องราว: อย่าประมาทสิ่งที่คุณสามารถนำไปไว้ที่โต๊ะ

เป็นเวลานานที่สุดที่ฉันคิดว่าการเขียนโปรแกรมไม่ดีเป็นสิ่งที่เกิดขึ้นที่ชายขอบ .. การทำสิ่งต่าง ๆ อย่างถูกต้องเป็นบรรทัดฐาน ฉันไม่ได้ไร้เดียงสาดังนั้นวันนี้

ฉันคิดว่าฉันควรจะก้าวไปสู่การเป็นนามธรรมมากที่สุด ฉันโดนหัวเมเจอร์ด้วยสิ่งนี้เพราะฟังก์ชั่นเล็ก ๆ น้อย ๆ พันกันมากเกินไป

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

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

ผู้หญิงที่พบว่านักเขียนโปรแกรมคอมพิวเตอร์เซ็กซี่ ...

ซึ่งคุณภาพของซอฟต์แวร์จะนำไปสู่การขายที่มากขึ้น บางครั้งก็ไม่ แต่ไม่เสมอไป

ว่าทุกภาษา (ส่วนใหญ่) สร้างขึ้นเท่ากับ

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

การเลือกภาษาที่เหมาะสมสำหรับงานมีความสำคัญ / สำคัญเท่ากับการตัดสินใจโครงการอื่น ๆ ที่ทำ

นั่นคืออัตราส่วนความคิดเห็น / รหัสขนาดใหญ่เป็นสิ่งที่ดี

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

การเขียนโปรแกรมนั้นเป็นไปไม่ได้

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

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

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

"On Error Resume Next" เป็นชนิดของการจัดการข้อผิดพลาดบางอย่าง

ซอฟต์แวร์การเขียนโปรแกรมนั้นต้องการรากฐานที่แข็งแกร่งในวิชาคณิตศาสตร์ที่สูงขึ้น

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

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

การเพิ่มประสิทธิภาพนั้น == การเขียนใหม่ในภาษาแอสเซมบลี

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

• ที่ผู้บริหารของ บริษัท ใส่ใจเกี่ยวกับคุณภาพของรหัส
• เส้นที่น้อยลงนั้นดีกว่า

ฉันจะบอกว่าการจัดเก็บองค์ประกอบปีของวันที่เป็นตัวเลข 2 หลักเป็นข้อสันนิษฐานที่ทำให้นักพัฒนาทั้งรุ่น เงินที่ถูกเป่าบนY2Kนั้นค่อนข้างน่ากลัว

สิ่งอื่นใดนอกเหนือจากการแทรก / การเรียงลำดับฟองนั้นเป็นเพียงแค่เวทมนตร์มืด

XML นั้นจะเป็นรูปแบบข้อมูลที่ใช้งานร่วมกันได้อย่างแท้จริงและมนุษย์สามารถอ่านได้

C ++ นั้นดีกว่าภาษาอื่นทั้งหมด

สิ่งนี้ฉันได้รับจากเพื่อนสองสามปีข้างหน้าของฉันในวิทยาลัย ฉันเก็บมันไว้กับฉันเป็นเวลานานอย่างน่าอาย (ตอนนี้ฉันเขิน) หลังจากทำงานกับมันมา 2 ปีหรือมากกว่านั้นก่อนที่ฉันจะเห็นรอยแตกของสิ่งที่พวกเขาเป็น

ไม่มีใคร - และไม่มีอะไร - สมบูรณ์แบบมีห้องสำหรับการปรับปรุงอยู่เสมอ

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

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

รูปแบบการออกแบบรู้สึกเหมือนเวทมนตร์ คุณสามารถทำสิ่งที่เรียบร้อยจริงๆ ต่อมาฉันค้นพบการเขียนโปรแกรมที่ใช้งานได้ (ผ่าน Mozart / Oz, OCaml, ภายหลัง Scala, Haskell และ Clojure) จากนั้นฉันเข้าใจว่ารูปแบบจำนวนมากเป็นเพียงแค่ต้นแบบสำเร็จรูปหรือความซับซ้อนเพิ่มเติมเนื่องจากภาษานั้นไม่สามารถแสดงออกได้เพียงพอ

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

ในช่วงสองสามปีแรกที่ฉันเขียนโปรแกรมฉันไม่ได้รู้ว่า 1 Kbyte นั้นมี 1024 ไบต์ทางเทคนิคไม่ใช่ 1,000 ฉันมักสับสนเล็กน้อยจากความจริงที่ว่าขนาดไฟล์ข้อมูลของฉันดูเหมือนเล็กน้อยจากที่ฉันคาดไว้ เป็น

ตรวจสอบสภาพที่ชอบ:

if (condition1 && condition2 && condition3)

จะดำเนินการในการสั่งซื้อที่ไม่ระบุ ...

ว่าการเขียนโปรแกรมของฉันจะเร็วขึ้นและดีขึ้นถ้าฉันทำมันคนเดียว