สิ่งที่เปลี่ยนความคิด: สิ่งที่เมื่อก่อนเคยเถียง แต่ตอนนี้เชื่อแล้ว
- ในทีมที่มีคนหลากหลายระดับประสบการณ์ ภาษาแบบ Typed ดีกว่า
- การประชุมสแตนด์อัปมีประโยชน์ในการคอยดูแลคนใหม่
- การรีโทรสเปกทีฟของสปรินต์มีทั้งส่วนที่มีประโยชน์และส่วนที่ไม่ดี (Agile/Scrum master ที่ทำให้ทุกคนเสียเวลา)
- สถาปัตยกรรมซอฟต์แวร์สำคัญกว่าสิ่งอื่นใด การทำ abstraction ที่ดีแต่ implement ได้ไม่ดี ไม่ได้ทำร้าย codebase เท่ากับ abstraction ที่แย่หรือการขาดชั้น layer ที่ทำให้ทุกอย่างแย่ลง
- Java ไม่ได้เป็นภาษาที่แย่ขนาดนั้น
- โค้ดที่ดูฉลาดแพรวพราวมักไม่ใช่โค้ดที่ดี ความชัดเจนสำคัญเหนือสิ่งอื่นใด
- เขียนโค้ดแย่ ๆ ได้ในทุก paradigm
- "best practice" ขึ้นอยู่กับบริบท และใช้กับทุกอย่างไม่ได้ ถ้าทำตามแบบไม่ลืมหูลืมตาก็จะกลายเป็นคนโง่
- ถ้าออกแบบระบบให้ scalable ทั้งที่ยังไม่จำเป็น ก็เป็นวิศวกรที่แย่
- การวิเคราะห์แบบสถิตมีประโยชน์
- DRY เป็นวิธีหลีกเลี่ยงปัญหาเฉพาะอย่าง ไม่ใช่เป้าหมายสุดท้าย
- โดยทั่วไป RDBMS > NoSQL
- functional programming ไม่ใช่ยาครอบจักรวาล แต่เป็นอีกหนึ่งเครื่องมือ
ความเห็นที่ฉันเลือกหยิบมาระหว่างทาง:
- YAGNI > SOLID > DRY : ตามลำดับนี้
→ You Aren't Gonna Need It : หนึ่งในหลักการของ XP
→ SOLID : หลักการออกแบบเชิงวัตถุ 5 ข้อ
Single responsibility
Open-close
Liskov substitution
Interface segregation
Dependency inversion
→ DRY : Don't Repeat Yourself - ดินสอกับกระดาษคือเครื่องมือเขียนโปรแกรมที่ดีที่สุดซึ่งกลับถูกใช้น้อยเกินไป
- โดยทั่วไปแล้ว การแลกความบริสุทธิ์เพื่อให้ได้ความใช้งานจริงเป็นทางเลือกที่ดี
- การเพิ่มเทคโนโลยีให้มากขึ้นไม่ใช่ทางเลือกที่ดี
- ถ้าคุยกับลูกค้าโดยตรง จะเข้าใจปัญหาได้มากขึ้น แม่นยำขึ้น และใช้เวลาน้อยลง
- คำว่า "Scalable" มีพลังลึกลับและน่าตกใจต่อจิตใจของวิศวกรซอฟต์แวร์ แค่เอ่ยเบา ๆ ก็ทำให้พวกเขาตกอยู่ในความคลั่งอย่างเสื่อมทรามได้ การใช้คำนี้ทำให้การกระทำอันโหดเหี้ยมถูกทำให้ดูชอบธรรม
- แม้จะถูกเรียกว่า "วิศวกร" แต่การตัดสินใจส่วนใหญ่ก็เป็นแค่ cargo-cult ที่ไม่มีการวิเคราะห์ ข้อมูล หรือตัวเลขรองรับ
→ cargo-cult: ธรรมเนียมการเฝ้ารอโดยเชื่อว่าใครบางคนที่ก้าวหน้าทางเทคโนโลยี (สังคม/บรรพบุรุษ) จะนำสินค้าพิเศษมาทางเรือหรือเครื่องบิน - ผู้จัดการโครงการ 90% หรืออาจ 93% สามารถหายไปได้ตั้งแต่พรุ่งนี้ เพราะแทบไม่มีประโยชน์ด้านประสิทธิผลหรือประสิทธิภาพ
- หลังผ่านการสัมภาษณ์มา 100 ครั้ง ก็พบว่าวิธีสัมภาษณ์พังหมดแล้ว และฉันเองก็ไม่รู้จะปรับปรุงมันอย่างไร
ความเห็นเดิมที่ยังไม่เปลี่ยน:
- คนที่หมกมุ่นกับ code style, กฎ linting และเรื่องจุกจิกอื่น ๆ เป็นพวกเพี้ยนสุดโต่ง
- code coverage ไม่เกี่ยวอะไรกับคุณภาพโค้ดเลย
- monolith ใช้ได้ดีมากในสถานการณ์ส่วนใหญ่
- พวก TDD สายบริสุทธิ์คือแย่ที่สุด จิตใจอันบอบบางเล็ก ๆ ของพวกเขารับไม่ได้ว่ามี workflow แบบอื่นอยู่ด้วย
- ไว้ตอนครบ 10 ปีจะกลับมาดูว่าอะไรเปลี่ยนหรือพลิกอีกบ้าง
9 ความคิดเห็น
เป็นประโยคที่อ่านแล้วเห็นด้วยทีละข้อเลยนะครับ/ค่ะ ดูเหมือนว่ากำลังเปลี่ยนจากอุดมคติที่เชื่อว่าทุกอย่างทำให้สมบูรณ์แบบได้ ไปสู่แนวคิดแบบปฏิบัตินิยมมากขึ้น
หลังจากอยู่ในวงการมา 6 ปี หัวข้อเกี่ยวกับการพัฒนาซอฟต์แวร์ที่เปลี่ยนมุมมองไป
เมื่อได้ตระหนักถึงความสำคัญของ TDD จากนั้นโปรแกรมเมอร์ ...
ดูเหมือนจะยังมีความเห็นออกมาเรื่อย ๆ ว่ากระบวนการสัมภาษณ์มันพังอยู่ ถ้าให้เริ่มจากผมเอง ถ้าถูกบอกให้ไปสอบโค้ดดิ้งเทสต์ก็ไม่ค่อยมั่นใจเหมือนกัน (...)
มีบทความแบบนี้ด้วยนะครับ/ค่ะ บอกว่าเป็นเนื้อหาที่อยู่ในหนังสือชื่อ 『HARD CODE』
https://johngrib.github.io/wiki/better-interview/
เพิ่งมารู้เรื่องพวกนี้หลังผ่านไป 6 ปีเองเหรอ 5555 สุดยอดจริง ๆ นะ
เพิ่งตาสว่างในรอบ 6 ปีจนบรรลุเป็นพระพุทธเจ้าเลยสินะ!
บน Hacker News มีนักพัฒนาคนอื่น ๆ และวิศวกรที่มีประสบการณ์มากกว่า 20 ปีเข้ามาเขียนคอมเมนต์เพิ่มเติมกันอยู่ด้วย
https://news.ycombinator.com/item?id=25887373
คอมเมนต์แรกก็แรงเลย 555 ถ้าค่อย ๆ แยกพิจารณาทีละข้อก็น่าจะมีกรณียกเว้นอยู่บ้าง แต่ดูเหมือนว่าการเชื่ออะไรงมงายไม่ว่าจะเรื่องไหนก็อันตราย
ดูเหมือนว่านี่จะเป็นประเด็นที่ถูกหยิบยกขึ้นมาเรื่อย ๆ เพราะมีบั๊กจำนวนไม่น้อยที่แก้ได้เพียงแค่ทำ type check ให้ดี และวิธีจัดการ type อย่างปลอดภัยก็กำลังพัฒนาให้ดีขึ้นอย่างต่อเนื่องด้วย
(แต่
TypeScriptนี่ก็ค่อนข้างยากอยู่เหมือนกัน T_T)