ฉันคิดว่าของฉันคือ "ไม่มีสิ่งใดเป็นงานห้านาที" - โปรแกรมเมอร์มักจะมองโลกในแง่ดีเกี่ยวกับการพัฒนาและเราควรคิดผ่านผลกระทบจริง ๆ ก่อนที่จะสัญญาว่าจะแก้ปัญหาได้อย่างรวดเร็ว
ฉันคิดว่าของฉันคือ "ไม่มีสิ่งใดเป็นงานห้านาที" - โปรแกรมเมอร์มักจะมองโลกในแง่ดีเกี่ยวกับการพัฒนาและเราควรคิดผ่านผลกระทบจริง ๆ ก่อนที่จะสัญญาว่าจะแก้ปัญหาได้อย่างรวดเร็ว
คำตอบ:
มีวิธีที่ดีกว่าในการเขียนโค้ดของคุณอยู่เสมอ
ไม่ว่าคุณจะพบโค้ดที่คุณเขียนยอดเยี่ยมแค่ไหนคุณจะแปลกใจว่ามันแย่แค่ไหนถ้าคุณอ่านมันในอีกไม่กี่ปีข้างหน้า เพียงไม่กี่ปีก่อนคุณไม่รู้รูปแบบบางอย่างที่คุณรู้วันนี้หรือคุณสมบัติภาษาบางอย่างที่คุณได้เรียนรู้ในขณะเดียวกันเป็นต้น
คิดก่อนที่จะเริ่มการเข้ารหัส
ไม่มีอะไรถาวรมากกว่าการแก้ปัญหาชั่วคราว :)
หากยากที่จะแก้ไขปัญหาอย่างสุดความสามารถส่วนใหญ่แล้วปัญหาจะเกิดจากจุดเริ่มต้นที่ไม่ดี
ซอฟต์แวร์ของคุณจะใช้งานได้นานกว่าที่คุณคิดในเวลาที่คุณเขียน
ฉันเริ่มอาชีพของฉันในยุค 80 ฉันเริ่มต้นด้วยซอฟต์แวร์ที่มีต้นกำเนิดในยุค 70 และยังคงถูกใช้งานในยุค 90 (อาจนานกว่านั้นฉันไม่รู้ว่าเป็นเรื่องของชะตากรรมหรือไม่) โค้ดโอเพนซอร์ซของฉันบางตัวใช้วิธีครึ่งทางจนถึงทศวรรษที่สอง
การทำงานกับผู้อื่นได้ดีนั้นสำคัญมาก
"แสดง 'Go to guy' ของคุณให้ฉันแล้วฉันจะแสดงปัญหาให้คุณ"
Slapdash Hero Coders - ผู้ที่เพิ่งออกรหัสโดยไม่คำนึงถึงแบบแผนความสามารถในการอ่านหรืออะไรก็ตามที่คนอื่นกำลังทำอยู่ - อาจก่อให้เกิดอันตรายมากกว่าดี
การไม่พูดว่าคนที่สามารถเขียนรหัสคุณภาพดีจำนวนมากเป็นสิ่งไม่ดี หายาก
นั่นจะเป็นบทเรียนแห่งความอ่อนน้อมถ่อมตน
การเรียนรู้ภาษาใหม่เป็นส่วนหนึ่งของงาน
ฉันเรียนรู้เกี่ยวกับสี่ภาษาโปรแกรมในโรงเรียนย้อนกลับไปในยุค 80 แต่ได้ใช้หนึ่งในนั้นในงาน ฉันมีสี่งานที่ฉันไม่รู้ด้วยซ้ำว่าภาษาที่ฉันจ้างมาใช้นั้น
โดยรวมแล้วฉันได้เรียนรู้และใช้งานอย่างมืออาชีพบางทีอาจมีหลายภาษาในอาชีพของฉันรวมถึง FORTRAN, c, c ++, c #, java, perl, Tcl, ruby, groovy, awk, python, sh, แบทช์, DCL, javascript และ a DSL เล็ก ๆ น้อย ๆ ทำคณิตศาสตร์เล็กน้อยฉันดูเหมือนจะเฉลี่ยภาษาใหม่ทุกสองสามปีแม้ว่าจะมีการทับซ้อนกันมากมาย
หากมีอะไรที่คงที่ในอาชีพการงานของฉันมันก็เปลี่ยนไป
ซอฟต์แวร์ไม่สมบูรณ์
มีการเปลี่ยนแปลงข้อกำหนดการปรับปรุงแก้ไขข้อผิดพลาดบางอย่างที่คุณต้องเตรียมไว้เสมอ ดังนั้นจงยืดหยุ่นและยอมรับความจริงที่ว่า"software is never complete"และมีที่ว่างสำหรับการปรับปรุงอยู่เสมอ
เรียนต่อทุกวัน ความรู้ในวันนี้ล้าสมัยไปแล้วในวันพรุ่งนี้
กระแทกแดกดันคำตอบนี้ควรล้าสมัยเกินไป แต่จริงๆแล้วศึกษาสิ่งหนึ่งหรือสองอย่างและรับรองว่าเป็นไปได้เป็นพระเจ้าของสิ่งนั้น (อาจเป็นภาษาโปรแกรมหรือระบบ / เครือข่าย / การจัดการฐานข้อมูล) และคอยจับตาดูสิ่งเล็ก ๆ น้อย ๆ อื่น ๆ เช่นภาษาอื่น ๆ คุณ.
ฉันหมายถึงเป็นมืออาชีพที่ยอดเยี่ยมของการบริหาร Java และ Oracle DB แต่ศึกษา Python, PHP, C ++, HTML5, Javascript เล็กน้อยแม้ว่าจะไม่ได้รับการรับรอง ศึกษาแต่ละเว็บหรือกรอบภาษาที่มีอยู่ ศึกษาหรือพยายามที่จะมีประสบการณ์ (พื้นฐาน) กับฐานข้อมูลแต่ละตัวที่มีอยู่เช่น SQL Server, MySQL, Cassandra, HBase, PostgreSQL และโลกที่ไม่มี SQL เช่น MongoDB และ CouchDB พยายามที่จะมีประสบการณ์กับ linux administation และ virtualization
นั่นเป็นบทเรียนที่ยิ่งใหญ่ที่สุดที่ฉันได้เรียนรู้จากประสบการณ์ 16 ปีของฉัน ฉันเป็นโปรแกรมเมอร์ภาษาโมโนเกือบ 10 ปีใช้ Pascal ในยุคนั้นและ Visual Basic 6 ที่เริ่มต้นของสหัสวรรษและนักพัฒนา PHP ตั้งแต่ 9 ปีที่แล้ว แต่จากนั้นฉันเรียนรู้ว่านักพัฒนาจำเป็นต้องรู้ทุกอย่างเป็นอย่างน้อย
"ถ้าคณิตศาสตร์ของคุณผิดคุณก็ปิ้ง"
เรียนรู้มันเป็นครั้งแรกเมื่อหลายปีก่อน เรียนรู้มันอีกครั้งเมื่อสองสัปดาห์ก่อน
ฉันจะบอกว่าบทเรียนที่ดีที่สุดที่ฉันเรียนรู้คือ
"คุณควรไปหาวิธีที่ดีที่สุดเสมอและไม่ใช่แนวทางของคุณ "
ฉันได้เรียนรู้ว่าหลักการออกแบบที่ดีที่สุดคือ KISS (ให้มันง่ายโง่!)
ฉันได้เรียนรู้ว่าการทำให้โค้ดของคุณง่ายและสะอาดควรเป็นข้อกังวลหลักและสมาชิกในทีมแต่ละคนควรเข้าใจสิ่งที่คุณมีรหัส The KISS principleกล่าวว่าระบบส่วนใหญ่ทำงานได้ดีที่สุดหากพวกเขาเก็บไว้ง่าย ๆ แทนที่จะทำให้ซับซ้อนดังนั้นความเรียบง่ายจึงควรเป็นเป้าหมายสำคัญในการออกแบบและควรหลีกเลี่ยงความซับซ้อนที่ไม่จำเป็น
ถ้ามันไม่พังอย่าซ่อมมัน!
การพยายามขยายและปรับปรุงสิ่งที่ใช้งานได้อาจทำให้คุณปวดหัวมาก
ไม่ต้องลอง
ให้บอกว่าคุณมีงานหรืองานที่คาดว่าจะใช้เวลา 4 วัน จากนั้นหัวหน้าหรือผู้จัดการโครงการของคุณถามว่าคุณสามารถพยายามทำให้เสร็จภายในสองวันด้วยเหตุผลสำคัญบางอย่าง หากต้องการเป็นพนักงานที่ดีและยืดหยุ่นคุณอาจถูกล่อลวงให้พูดว่า: แน่นอนคุณสามารถลองได้ ผลลัพธ์ที่น่าจะเป็นไปได้มากที่สุดคือคุณไม่พลาดกำหนดเวลาหรือคุณจะต้องแฮ็คแบบครึ่งทางเพื่อให้เสร็จ และไม่ใช่ความผิดของเจ้านายที่ขอให้คุณทำนั่นเป็นหน้าที่ของเขา มันเป็นความผิดของคุณที่ไม่ได้บอกว่าไม่ซึ่งเป็นงานของคุณ
คุณไม่สามารถต่อรองกับเวลา คุณสามารถต่อรองกับขอบเขต เป็นมืออาชีพและอย่าขายตัวเองให้สั้น
"นั่นจะไม่เกิดขึ้นจริง ๆ " หมายความว่า "จะไม่เกิดขึ้นจนกว่าจะถึงวันแรกของการผลิต"
รู้สึกดีที่ได้เขียนโค้ดที่ทันสมัยทันสมัยโค้ดที่สะอาด
แม้ว่าฉันจะถูกขอให้ทำวิธีแก้ไขปัญหาด่วน ๆ ซึ่งจะทำลายฐานรหัสฉันก็ควรทำในลักษณะที่ดี
การเขียนรหัสเป็นเรื่องง่าย การอ่านรหัสเป็นเรื่องยาก แม้ว่ารหัสเป็นของคุณ ดังนั้นเมื่อเป็นไปได้ลองหาวิธีอ่าน
คุณไม่ฉลาดกว่าคนอื่น อย่าคิดว่าคุณกำลังเข้าใกล้เป็นสิ่งที่ดีที่สุดเพราะเป็นของคุณ
ให้ความสนใจกับสิ่งที่มีการพูดไม่ใช่โดยที่มีการกล่าวถึง ความคิดที่ยอดเยี่ยมอาจมาจากแหล่งที่ไม่คาดคิดที่สุด
อย่าขี้เกียจ ใช้เวลาในการเขียนโค้ดที่ดี คุณจะต้องแก้ไขด้วยค่าใช้จ่ายที่สูงขึ้น
อย่าใช้คุณสมบัติ OOP แฟนซีเพราะคุณทำได้! - YAGNI (คุณไม่ต้องการมัน)
Use fancy OOP featuresเพราะพวกเขามีที่เฉพาะเจาะจงซึ่งแสดงให้เห็นประโยชน์ในการแก้ไขปัญหาที่คุณกำลังพยายามที่จะแก้ปัญหา คุณหัวเราะ แต่ฉันเห็นสิ่งนี้ตลอดเวลา โปรแกรมเมอร์ส่วนใหญ่ไม่เคยพบวัตถุที่ไม่ชอบ ผมคิดว่ามันควรจะเป็นรอบวิธีอื่น ๆ : เทคนิคเหล่านี้มีความผิดจนกว่าจะพิสูจน์ความบริสุทธิ์ในศาลของKISS