ซอฟต์แวร์มีอยู่เพื่อแก้ปัญหาบางอย่าง ด้วยเหตุนี้นักพัฒนาจึงต้องทำความเข้าใจปัญหา ออกแบบให้เหมาะสมกับปัญหา และลงมือพัฒนา ในกระบวนการทำความเข้าใจปัญหาและการออกแบบนั้น การคิดเชิงนามธรรมและการคิดเชิงโครงสร้างถือเป็นอาวุธสำคัญของนักพัฒนา
โดยปกติแล้ว การคิดเชิงนามธรรมและเชิงโครงสร้างมักถูกอธิบายอย่างเข้าใจยากหรือค่อนข้างคลุมเครือ แต่จริง ๆ แล้วมีวิธีการที่เป็นรูปธรรมสำหรับการคิดลักษณะนี้อยู่ชัดเจน ในการบรรยายนี้จะอธิบายวิธีคิดเชิงนามธรรมและเชิงโครงสร้างอย่างเป็นรูปธรรมสำหรับนักพัฒนา รวมถึงแนะนำวิธีออกแบบซอฟต์แวร์ เช่น domain modeling, refactoring และ architecture โดยอาศัยแนวคิดเหล่านี้
- งานของนักพัฒนาคือการสร้างโปรแกรม
- เหตุผลที่สร้างโปรแกรมคือเพื่อแก้ปัญหาเฉพาะบางอย่าง และเหตุผลที่แก้ปัญหาก็เพื่อธุรกิจ
- การสร้างโปรแกรมประกอบด้วย 4 ขั้นตอน
- ทำความเข้าใจ / วิเคราะห์ -> ออกแบบ -> พัฒนา -> รับ feedback
- ยิ่งนักพัฒนามีความเป็น senior มากขึ้น ก็จะไม่ได้มีส่วนแค่การเขียนโค้ด แต่เกี่ยวข้องกับทุกขั้นตอนเหล่านี้
- senior แก้ปัญหาได้อย่างรวดเร็วผ่านสัญชาตญาณที่อิงจากประสบการณ์
- แต่สัญชาตญาณอาจมีความเสี่ยงได้ ดังนั้นการเรียนรู้วิธีการจึงสำคัญ
- การคิดเชิงนามธรรมและเชิงโครงสร้างคือพื้นฐานของวิธีการดังกล่าว
- นามธรรมคือการดึงสิ่งที่เป็นจุดร่วม หรือสิ่งที่เราสนใจ ออกจากองค์ประกอบต่าง ๆ
- เพราะฉะนั้น นามธรรมจึงอาจมองได้ว่าเป็นการทำให้สิ่งต่าง ๆ เรียบง่ายลงแล้วตีความใหม่
- เราสามารถทำให้เรียบง่ายและตีความใหม่ได้ผ่านแนวคิด reductionism ที่ลดทอนลงเป็นองค์ประกอบ
- ไม่ใช่แค่องค์ประกอบเท่านั้น แต่พฤติกรรมก็สามารถทำ abstraction ได้เช่นกัน
- abstraction มีลำดับชั้น
- ต้องกำหนดระดับของ abstraction ที่เหมาะสม
- abstraction ที่มากเกินไปไม่ดี เพราะจะทำให้มองไม่เห็นตัวตนที่แท้จริง
- การคิดเชิงโครงสร้างคือการจัดระเบียบเนื้อหาโดยไม่ซ้ำซ้อนและไม่ตกหล่น
- คล้ายกับ framework แบบ MECE
- แต่สิ่งสำคัญไม่ใช่ว่าต้องจัดให้ไม่ซ้ำซ้อนและไม่ตกหล่นแบบตายตัวเสมอไป
- การจัดโครงสร้างก็มีหลายระดับเหมือน abstraction ทำให้สามารถมองจากมุมที่ไกลขึ้นได้อีกหนึ่งก้าว
- มีวิธีที่เป็นรูปธรรมสำหรับการคิดแบบเชิงนามธรรมและเชิงโครงสร้าง
- top-down และ bottom-up
- model
- Classification
- Abstraction
- Generalization
- การคิดแบบ framework
- สามารถประยุกต์การคิดเชิงนามธรรมและเชิงโครงสร้างกับการออกแบบซอฟต์แวร์ได้
- หากแบ่งขั้นตอนการพัฒนาซอฟต์แวร์แบบกว้าง ๆ ออกเป็น 3 ส่วน จะได้เป็น domain modeling, architecture และการเขียนโค้ด
- domain modeling สามารถดึงความต้องการออกมาในเชิงนามธรรมและค่อย ๆ ขยายต่ออย่างเป็นลำดับได้
- architecture แสดงถึงวิธีการทำงาน
- ทำงานอย่างไร แบ่งอย่างไร
- architecture ดำเนินตามกระบวนการ ความต้องการ -> คอนเซปต์ -> พัฒนา -> feedback
- สามารถค่อย ๆ ทำให้คอนเซปต์ทาง architecture ที่เป็นนามธรรมมีความเป็นรูปธรรมมากขึ้นได้
- programming paradigm คือมุมมองที่ใช้มององค์ประกอบของซอฟต์แวร์
- เราสามารถมอง logic ได้จาก 3 ด้าน คือ Function, Usecase, Aspect
- syntax sugar คือไวยากรณ์การเขียนโปรแกรมที่ถูกทำให้เป็น abstraction แล้ว
- มันอาจกลายเป็นพิษได้เช่นกัน
- refactoring สามารถมองได้จาก 6 มุม ได้แก่ paradigm, ขนาดโค้ด, ownership, การมีโค้ดซ้ำ, ความสามารถในการแก้ไข, และ dependency
- refactoring มี 3 วิธี คือ abstraction, การจัดโครงสร้าง, และ generalization
- หากต้องการพัฒนาความสามารถในการคิดเชิงนามธรรมและเชิงโครงสร้าง ควรมีประสบการณ์ที่หลากหลาย
- การทำแผนภาพช่วยได้มาก
- สัญชาตญาณคือการคิดแบบประสบการณ์นิยม ช่วยประหยัดเวลาได้ แต่ก็อาจมีความเสี่ยง
- pattern ช่วยในการฝึกการคิดเชิงนามธรรม
- การเป็นเชิงนามธรรมและเชิงโครงสร้างไม่ใช่คำตอบ万能เสมอไป
10 ความคิดเห็น
ขอบคุณสำหรับสไลด์นำเสนอและสรุปเนื้อหา
ดูจากไอดีแล้วเหมือนคุณจะเป็นวิทยากรเองเลยนะครับ! ผมพลาดจับสลากงาน Infocon เลยไม่ได้เข้าไปฟัง,, ขอบคุณที่แชร์สไลด์นำเสนอครับ :)
ขอบคุณครับ :D หวังว่าเนื้อหาของผมจะเป็นประโยชน์นะครับ!
ขอบคุณสำหรับสรุปที่ละเอียดครับ
สรุปนี่ใช้เวลานานกว่าที่คิดนะครับ ^^;; ขอบคุณที่เข้ามาอ่านครับ!
ขอบคุณสำหรับบทความดี ๆ และสรุปนะครับ~
ขอบคุณที่มองกันในแง่ดีนะครับ :D
อ่านได้ดีมากครับ!
ต้องกำหนดระดับของการนามธรรมที่เหมาะสม
-> ตรงนี้มีคำพิมพ์ผิดครับ :)
ขอบคุณที่ตรวจสอบให้ครับ :) แต่ดูเหมือนว่าถ้าโพสต์ไปแล้วจะไม่สามารถแก้ไขได้ ฮือๆ
อ๋อ ผมไม่เคยรู้มาก่อนเลย ขอบคุณที่ช่วยตรวจสอบครับ!