ความคิดที่เปลี่ยนไป
- ความเรียบง่ายไม่ได้เกิดขึ้นเอง แต่เป็นสิ่งที่ต้องอาศัยความพยายามอย่างต่อเนื่อง
- ได้ตระหนักว่าไม่มีเหตุผลอะไรที่จะภูมิใจกับการจัดการหรือทำความเข้าใจความซับซ้อน
- ในทีมที่มีระดับประสบการณ์หลากหลายปะปนกัน ภาษาแบบ Typed เป็นสิ่งจำเป็น
- Java เป็นภาษาที่ยอดเยี่ยมเพราะมันไม่น่าสนุก
- REPL ไม่มีประโยชน์มากนักในฐานะเครื่องมือออกแบบ แต่มีประโยชน์สำหรับการสำรวจทดลอง
- การเขียนโปรแกรมจริง ๆ ควรเกิดขึ้นเกือบทั้งหมดก่อนถึงขั้นตอนการเขียนโค้ด
- การพัฒนา Frontend ได้กลายเป็นดินแดนฝันร้ายแบบ Kafkaesque และไม่สนุกอีกต่อไป
- แนวคิดเรื่องความสง่างามไม่สามารถเป็นตัวชี้วัดที่วัดผลได้จริง
- การบริหารจัดการที่ดีจริง ๆ เป็นสิ่งล้ำค่ามาก (ตลอดอาชีพที่ผ่านมาพบการจัดการที่ดีจริง ๆ แทบไม่กี่ครั้ง)
- DynamoDB เป็นฐานข้อมูลที่ดี หากตรงกับ workload เฉพาะทางนั้นอย่างพอดี
- OOP เป็นแนวทางที่ยอดเยี่ยมในบริบทที่เหมาะสม การยึดติดกับ Functional เพียงอย่างเดียวเป็นเรื่องไม่ฉลาด
ความเห็นที่ได้มา
- แก่นของวิศวกรรมคือการสื่อสาร
- อย่าใช้แนวคิด Monad หนักเกินไปใน Java
- Query Planner คือสิ่งที่โหดร้าย
- ช่วงเวลาที่เรารู้สึกว่าอะไรบางอย่าง 'ง่าย' แท้จริงแล้วมักเป็นสัญญาณว่าเรายังเข้าใจมันไม่ดีพอ
- ควรเปิดพื้นที่ให้นักพัฒนามือใหม่ได้สำรวจและทำผิดพลาดบ้าง
- ควรพัฒนา Soft skill อย่างจริงจัง เพราะผลตอบแทนจากการลงทุนนั้นเห็นได้ทันที
- ในการพัฒนาแอปพลิเคชันทั่วไป แทบไม่มีสิ่งที่เรียกว่า 'นามธรรมแบบใช้ได้ทั่วไปจริง ๆ' การเขียนเฉพาะโค้ดที่จำเป็นมักดีกว่า
- ตรงกันข้าม การพัฒนาไลบรารีคือการออกแบบ abstraction จึงควรใช้เวลาเพื่อหาโครงสร้างที่ถูกต้อง (รูปแบบเชิงพีชคณิต)
- ORM มีปัญหามากในทุกภาษาและทุก implementation เขียน SQL เองตรง ๆ ยังดีกว่า
- ปัญหาของ Functional programming หลายครั้งเกิดจากผู้ศรัทธาในแนวทางนี้เอง
- หากเวลาผ่านไปนานพอ คุณมักจะเสียใจมากที่สร้างระบบไว้บน Serverless Functions
- Type คือคำยืนยันที่เราตัดสินลงไปขณะมองโลก
- Distributed lock ยังคงเป็นปัญหาที่ยากมากอยู่เสมอ
- ความสามารถด้านการทำ formal modeling และการวิเคราะห์เป็นทักษะที่ต้องมี
- คุณสมบัติที่สำคัญที่สุดของชุดทดสอบ integration test คือความเป็นอิสระแยกขาดจากกัน
- DynamoDB อาจเป็นตัวเลือกที่แย่ที่สุดสำหรับการพัฒนาแอปพลิเคชันทั่วไปก็ได้
- คนส่วนใหญ่ไม่ได้สนใจเรื่อง 'craftsmanship' ของโค้ดมากนัก จงให้คุณค่ากับคนที่สนใจ แต่กับคนอื่นก็ต้องร่วมงานกับพวกเขาในจุดที่พวกเขาเป็นอยู่
- เชื่อว่าภาษาแบบ gradual, dependently typed คืออนาคต
- มั่นใจว่าในโค้ดทดสอบนั้น จะใส่คอมเมนต์มากแค่ไหนก็ยังไม่ถือว่ามากเกินไป
ความเห็นที่ไม่เปลี่ยนไป
- ยังคิดว่าคนที่หมกมุ่นกับเรื่องเล็กน้อยอย่างสไตล์โค้ดหรือกฎ linting เป็นคนประหลาดอยู่ดี ควรไปโฟกัสเรื่องที่สำคัญกว่า
- ยังคงยืนยันว่าสัดส่วน code coverage ไม่เกี่ยวข้องกับคุณภาพโค้ด (และหลายกรณียังมีแนวโน้มแปรผกผันกันด้วย)
- Monolith ยังคงเป็นตัวเลือกที่ใช้ได้ดี
- ยอมรับว่ายากมากที่จะเอาชนะงานวิจัยและการปรับปรุงของ RDBMS ที่สั่งสมมาหลายสิบปี
- การจะใช้ Micro-service ต้องมีเหตุผลที่เหมาะสมจริง ๆ (น่าเสียดายที่ทุกวันนี้มันเริ่มถูกมองเป็นเรื่องปกติเกินไป)
- โปรเจกต์ส่วนใหญ่ (แม้แต่โปรเจกต์ภายใน AWS เองก็เช่นกัน) ไม่ได้ต้องการ 'การสเกล' จริง ๆ และหลายครั้งการออกแบบโดยตั้งต้นจากการสเกลกลับให้ผลเสียมากกว่า
- เชื่อว่า 93% ของผู้จัดการโครงการ หรืออาจถึง 95.2% หายไปก็แทบไม่ส่งผลอะไร หรืออาจทำให้องค์กรมีประสิทธิภาพขึ้นด้วยซ้ำ (สัดส่วนนี้เพิ่มขึ้นจากเมื่อ 4 ปีก่อน)
- จะคอยดูว่าพอถึงปีที่ 15 แล้วมันจะเปลี่ยนไปอีกอย่างไร*
20 ความคิดเห็น
เรื่องที่คนส่วนใหญ่น่าจะเห็นด้วย
หลังอยู่ในวงการมา 10 ปี หัวข้อเกี่ยวกับการพัฒนาซอฟต์แวร์ที่เปลี่ยนมุมมองไป
โปรเจ็กต์ส่วนใหญ่ไม่เคยมีวันที่ต้องสเกลจริง ๆ หรือไม่ก็หายไปก่อนจะถึงวันที่จำเป็นต้องสเกล...
ภาษาแบบค่อยเป็นค่อยไปและมี dependent types คืออะไรเหรอ..?
เคยได้ยินผ่านๆ จากพอดแคสต์มาว่าเป็นระบบชนิดข้อมูลที่ค่ามีผลต่อชนิดข้อมูล อะไรทำนองนั้นครับ เห็นผู้เขียนบทความนี้พูดถึงภาษา functional ก็น่าจะเป็นเรื่องนั้นแหละ
ยกตัวอย่างเช่น ชนิดข้อมูล
Listถ้าค่าข้างในถูกเรียงไว้หมดแล้ว ก็จะกลายเป็นSortedList....ถ้ามีคุณสมบัติแบบนี้ การตรวจชนิดข้อมูลตอนคอมไพล์ก็น่าจะพิสูจน์อะไรได้มากขึ้น
ถ้ามีฟังก์ชันที่รับ
SortedListแล้วคืนค่าSortedList... แต่ถ้าในโค้ดมีบั๊กจนทำให้สถานะการ sort พัง ตอนคอมไพล์ก็คงขึ้น type error เลยแน่นอนว่า.... ต้นทุนของการตรวจชนิดข้อมูลก็น่าจะสูงพอสมควร...
แต่ในทางปฏิบัติมันไปได้ไกลถึงไหนแล้ว ผมก็ยังนึกภาพไม่ค่อยออกเลยครับ.
อ๋อ ขอบคุณครับ ฟังดูน่าทึ่งดีนะ...
หมายถึงภาษาที่สามารถย้ายและประยุกต์ใช้ได้อย่างยืดหยุ่นระหว่างระบบชนิดข้อมูลแบบ static และ dynamic
Java น่าเบื่อ เลยกลับกลายเป็นภาษาที่ยอดเยี่ยม
หมายความว่ายังไง?
ไม่ว่าใครจะเขียนก็ออกมาคล้าย ๆ กัน เลยดูแลง่าย น่าจะหมายถึงแบบนั้นมั้งครับ
ผมคิดว่าคงหมายถึงว่ามันมีความมั่นคงในตัวเอง เพราะไม่มีส่วนไหนที่ต้องใส่ใจเป็นพิเศษมากขึ้นหรือทำให้นักพัฒนาตกใจเป็นพิเศษ
เรื่องที่เกี่ยวกับสไตล์โค้ดหรือการ lint หลายส่วนแก้ได้ด้วยเครื่องมืออยู่แล้ว ดังนั้นพอไปเจอคนที่ไม่ใส่ใจเรื่องพวกนี้ ผมก็ไม่ค่อยอยากทำงานด้วยเท่าไหร่
เห็นด้วยครับ ผมเพิ่มการตรวจสอบสไตล์ไว้ใน CI และตั้งค่าให้ไม่สามารถ merge ได้หากไม่ปฏิบัติตามสไตล์
> ผมยังคงคิดว่าคนที่หมกมุ่นกับเรื่องจุกจิกอย่างสไตล์โค้ด กฎการ lint และอะไรทำนองนั้น เป็นคนแปลกอยู่ดี ควรโฟกัสกับเรื่องที่สำคัญกว่านี้
https://www.youtube.com/watch?v=JcY35HD77lg&t=828s
แต่ก็มีคนบอกว่าไม่ควรปล่อยผ่านไปเฉย ๆ เพราะสิ่งเหล่านี้เป็นปัจจัยที่ทำให้คนซึ่งก็เป็นมนุษย์เหมือนกัน มีสมาธิได้ยากขึ้น ดังนั้นแก้ให้เรียบร้อยแล้วค่อยเดินหน้าต่อจะดีกว่า
> คนส่วนใหญ่ไม่ได้สนใจเรื่อง "ความเป็นช่างฝีมือ" ของโค้ดมากนัก ควรให้คุณค่ากับคนที่สนใจเรื่องนี้ แต่กับคนที่เหลือก็ควรร่วมงานกับพวกเขาจากจุดที่พวกเขาอยู่
เห็นด้วย..
เป็นคนหนึ่งที่เสียใจกับการสร้างระบบอยู่บนเซิร์ฟเวอร์เลส หลังอยู่ในวงการมา 10 ปี
Cold start ก็ยังช้าอยู่เหมือนเดิม,
พอถึงจุดหนึ่งทราฟฟิกก็พุ่งจนแทบไม่ต่างจาก on-demand แล้ว,
ต่อให้ระดมทุกวิถีทางมาก็ยัง deploy ช้าเกินไป
กรณีที่ code coverage ไม่เกี่ยวข้องกับคุณภาพของโค้ด น่าจะมีอยู่สองแบบ
ผมคิดว่าน่าจะมีอยู่สองกรณีนี้
ผมคิดว่า test code จะมีความหมายก็ต่อเมื่อมี coverage สูง และทดสอบส่วนเดิมซ้ำหลายครั้งด้วย input ที่ต่างกัน ภายใต้สถานการณ์ที่หลากหลายซึ่งสามารถทำให้เกิด error ได้
ผมก็รู้สึกว่าเมื่อตีความในความหมายอย่างหลัง มันเข้าถึงใจมากกว่านะครับ เพราะตัวเลขอย่าง code coverage ที่สูง ไม่ได้เชื่อมโยงกับคุณภาพของโค้ดโดยตรง สิ่งสำคัญคือการเติมเต็มด้วย test case ที่มีความหมาย
> Java เป็นภาษาที่ยอดเยี่ยมก็เพราะมันไม่น่าสนุก
ฟังดูขำดีนะ 555
เห็นด้วยครับ
หลังอยู่ในวงการมา 6 ปี มุมมองต่อประเด็นการพัฒนาซอฟต์แวร์ที่เปลี่ยนไป
ความเห็นจาก Hacker News