See the original English version of this article here
การเป็น Programmer ที่ดี คือการมีทั้งทักษะและ Common Sense ในบางเรื่อง ทุกอย่างล้วนเกี่ยวกับการปฏิบัติและการรู้ว่าอะไรคือ Solutions ที่เหมาะกับปัญหานั้น ๆ เมื่อคุณต้องเผชิญกับความท้าทาย มีบาง Software Principles ที่จะช่วย Guide คุณในการเลือกแนวทางที่เหมาะสมที่สุด และในบทความนี้ก็คือ 7 Software Development Principles ที่คุณควรนำไปใช้ในการทำงาน
1. You Aren’t Gonna Need It — YAGNI
มันดูเป็นเรื่องง่ายและมีความหมายชัดเจนในตัวแล้ว แต่ก็ไม่ใช่ทุกคนที่จะทำตามได้ เมื่อเพิ่ม Code เข้าไป คุณควรแน่ใจว่ามันจำเป็นต้องใช้จริง ๆ อย่าเขียน Code เพียงเพราะคิดว่า มันอาจจะมีประโยชน์ในภายหลัง
หลักการนี้สามารถประยุกต์ใช้ได้เมื่อคุณต้อง Refactor หากคุณ Refactor Method / Class / File คุณไม่ควรลังเลที่จะลบ Method ใดก็ตาม ที่ไม่ได้ใช้งานแล้วออกไป แม้ว่าในอดีตมันอาจมีประโยชน์ก็ตาม
หากมีวันหนึ่ง ที่คุณอาจต้องการใช้งานมันอีกครั้ง คุณสามารถใช้ Git Repository เพื่อนำพวกมันกลับมาใช้งานอีกครั้ง
2. Don’t Repeat Yourself — DRY
Concept นี้ ถูกกล่าวถึงครั้งแรกโดยหนังสือ The Pragmatic Programmer: From Journeyman to Master ของ Andy Hunt และ Dave Thomas
หลักการนี้เรียกง่าย ๆ ก็คือ หลักการที่เราเขียน Code โดยเน้นที่การลดความซับซ้อนของ Code ให้ได้มากที่สุด
การมี Code ที่ซ้ำซ้อนกันดูจะทำให้เกิดข้อเสียมากกว่า คุณจะต้อง Maintain Logic เดียวกันใน 2 แห่ง จะต้องทำการTest ทั้ง 2 แห่ง และเมื่อคุณเปลี่ยนแปลง Code ที่หนึ่ง คุณจะต้องไล่ตามไปเปลี่ยน Code ที่อยู่อีกที่หนึ่งด้วยเช่นกัน
โดยส่วนใหญ่แล้ว Code ที่ Duplicate กัน มาจากการขาดความรู้เกี่ยวกับ System ดังนั้นก่อนที่จะเขียน Code ก็ขอให้คุณมองไปที่ Code นั้นทั้งหมด บางที Feature นี้อาจถูกนำไปใช้งานที่อื่น บางที Business Logic มันอาจมีอยู่แล้วสักแห่งใน Code นั้น การนำ Code มา Reuse ดูจะเป็นทางเลือกที่ชาญฉลาด
3. Keep It Simple, Stupid — KISS
Design Principle นี้เป็น Design Principle ที่ถูกกล่าวถึงโดยกองทัพเรือสหรัฐฯ ในปี 1960 หลักการนี้ระบุว่า System ที่เรียบง่ายจะทำงานได้ดีที่สุดและมีความน่าเชื่อถือมากขึ้น
คุณจะพบความคล้ายคลึงกันระหว่างหลักการนี้กับ Reinventing The Wheel ซึ่งมันถูกใช้เป็นการเปรียบเทียบในทาง Business และ Advertising
ในการนำไปใช้กับ Software Development มันหมายถึง อย่าทำอะไรที่มากเกินความจำเป็น บางครั้งวิธีแก้ปัญหาที่ชาญฉลาดที่สุดก็คือการใช้วิธีที่เรียบง่ายที่สุด การสร้าง Code ที่มีประสิทธิภาพด้วยความเรียบง่ายนั้นเป็นเรื่องที่ยอดเยี่ยม
ปัจจุบัน Errors ที่พบบ่อยที่สุดอย่างหนึ่ง ก็คือการพยายามใช้ Tools ใหม่ ๆ เพียงเพราะมันน่าสนใจ Developer ไม่ควรถูกจูงใจให้ใช้เทคโนโลยีล่าสุดเพียงเพราะแค่มันเป็นของใหม่ แต่ควรเลือกเพราะมันเหมาะสมกับงานนั้น ๆ มากกว่า
4. Big Design Up Front
ในแนวทาง Software Development นั้นมีความสำคัญแต่หลายครั้งก็มักจะถูกละเลย ก่อนที่จะเข้าสู่ Part ของการ Implement โปรดตรวจสอบให้แน่ใจว่า ทุกอย่างถูกคิดมาแล้วเป็นอย่างดี
Developer หลายคนอาจรู้สึกว่า งานของพวกเขายังไม่ก้าวหน้าหากยังไม่ได้เริ่มเขียน Code ซึ่งนั่นเป็นสิ่งที่ผิด การที่คุณมีการวางแผนไว้ก่อน จะช่วยให้ตัวคุณเองไม่ต้องเริ่มทำใหม่จาก 0 ซ้ำอีกครั้ง
บางครั้ง ก็อาจมีคนอื่นที่มีส่วนเกี่ยวข้องในข้อบกพร่องของการ Design แต่ยิ่งมีการพูดคุยเกิดขึ้นเร็วมากเท่าไหร่ ก็ยิ่งดีสำหรับทุกคน
การโต้แย้งที่พบบ่อยมากก็คือ ต้นทุนในการแก้ไขปัญหานั้นต่ำกว่าเวลาที่ต้องใช้ในการวางแผน ซึ่งนั่นไม่เป็นความจริงอย่างแน่นอน ยิ่ง Users ของคุณพบข้อบกพร่อง หรือปัญหาน้อยมากเท่าไหร่ ประสบการณ์การใช้งานของพวกเขาก็ดีขึ้นมากเท่านั้น
5. SOLID
มันเป็นหนึ่งใน Software Principle ที่เป็นที่รู้จักมากที่สุดหลักการหนึ่ง โดย SOLID เป็นคำย่อของ:
S) Single-responsibility principle
เรื่องนี้สำคัญอย่างมาก ทุก Object, Class และ Method ควรจะมีหน้าที่เดียว หาก Object, Class และ Method ของคุณ ทำหน้าที่หลายอย่าง มันอาจจบลงด้วย Spaghetti Code ที่คุณคงรู้จักเป็นอย่างดี นี่ก็คือตัวอย่าง:
Method นี้ดูเหมือนจะไม่สร้างความเสียหายอะไรมากมาย แต่มันกำลังทำหน้าที่หลายอย่าง
ผลกระทบอื่น ๆ ก็คือเรื่องของการ Test นั่นคือมันเป็นเรื่องยากที่จะ Test Functionalities ที่มีความเกี่ยวข้องกันนั้น
O) Open–closed principle
Software Entities ควรจะเปิดเพื่อให้นำไปใช้/ไปต่อยอด แต่ควรถูกปิดสำหรับการแก้ไข ซึ่งหมายความว่า เราไม่ควรนำ Method / Class มาแก้ไขใหม่ เพียงแค่ต้องการเพิ่ม Functionalities อื่น ๆ ให้มากขึ้น
Inheritance ถือเป็นวิธีที่ดีในการทำแบบนี้ ซึ่งใน JavaScript ส่วนใหญ่แล้ว สิ่งนี้ถูกทำโดย Composition
หลักการง่ายๆ: หากคุณแก้ไขปรับแต่ง Entity เพื่อให้สามารถนำไปใช้งานอื่นได้ นั่นถือว่าคุณกำลังทำผิดหลักการตั้งแต่ต้น
L) Liskov substitution principle
Principle นี้ กล่าวว่า Objects ของ Superclass จะต้องถูกแทนที่ด้วย Objects ของ Subclasses ของพวกมัน และ Application ควรจะยังคงทำงานได้ตามที่ควรจะเป็น
I) Interface segregation principle
Principle นี้ ถูกกำหนดขึ้นมาโดย Robert C. Martin ในขณะที่ให้คำปรึกษากับ Xerox ซึ่งเป็นหลักการที่เข้าใจได้ชัดเจน
Software ควรถูกแบ่งออกเป็นหลาย ๆ ส่วนที่เป็นอิสระต่อกัน ผลข้างเคียงต่าง ๆ ควรจะถูกลดลงให้มากที่สุดเพื่อให้แน่ใจว่ามันเป็นอิสระต่อกัน
ควรตรวจสอบให้แน่ใจว่า คุณไม่ได้บังคับให้ Objects ใช้ Methods ที่ไม่จำเป็น นี่คือตัวอย่าง:
D) Dependency inversion principle
เราควรพึ่งพา Abstractions ไม่ใช่การนำไปใช้อย่างเป็นรูปธรรม Software ควรมี Low Coupling และ High Cohesion
คุณไม่ควรสนใจว่า สิ่งต่าง ๆ ถูกสร้างขึ้นอย่างไร มันเกี่ยวกับวิธีการทำงานมากกว่า ตัวอย่างที่เห็นกันง่าย ๆ คือ เมื่อใช้ Dates ใน JavaScript คุณสามารถสร้าง Abstraction Layer ของคุณเอง ด้วยวิธีนี้หากคุณเคยเปลี่ยน Date Provider คุณจะมีเพียงที่เดียวที่จะสามารถเปลี่ยนได้
บางครั้งการสร้าง Abstraction Layer นั้นต้องใช้ความพยายามพอสมควร แต่มันอาจคุ้มค่าในระยะยาว
ตัวอย่างเช่น check date-io มันจะสร้าง Abstraction Layer ที่ช่วยให้คุณสามารถใช้มันกับ Date vendors ต่าง ๆ ได้
6. Avoid Premature Optimization
Premature Optimization คือ แนวทางที่กระตุ้นให้ Developer ทำการ Optimize โดยที่ยังไม่จำเป็น ก่อนที่จะมีการพิสูจน์อย่างแน่ชัดว่า มันเป็นสิ่งจำเป็น และเชื่อว่าหากคุณใช้หลักการ KISS และ YAGNI อยู่ คุณคงจะไม่ชอบสิ่งนี้
ก่อนอื่นอย่าเพิ่งเข้าใจผิด มันเป็นการดีที่จะพยายามคาดการณ์ว่าอาจมีปัญหาเกิดขึ้นในอนาคต แต่ก่อนที่จะลงรายละเอียดในการ Implement คุณต้องตรวจสอบก่อนว่า การเพิ่มประสิทธิภาพเหล่านั้น มันมีประโยชน์จริง ๆ
ตัวอย่างที่ง่ายมากก็คือ เรื่องการ Scaling คุณคงจะไม่ซื้อ Servers 40 เครื่อง เพราะคิดว่า App ใหม่ของคุณกำลังจะเป็น Viral สิ่งที่คุณควรทำก็คือ เพิ่ม Servers เฉพาะเมื่อคุณต้องการมัน
การรีบ Optimize โดยที่ยังไม่จำเป็น อาจทำให้ Code ของคุณทำงานช้าลง และด้วยเหตุนี้จึงเพิ่มต้นทุนด้านเวลาโดยไม่จำเป็น
เชื่อว่าหลายคนคงรู้ดีอยู่แล้วว่า การรีบ Optimize โดยที่ยังไม่จำเป็น ถือเป็นต้นตอของสิ่งเลวร้ายทั้งหมด
7. Occam’s Razor
“Ocham’s Razor (Latin: novacula Occami) หรือ Law of Parsimony (Latin: lex parsimoniae) เป็นหลักการแก้ไขปัญหาที่ว่า “สิ่งต่าง ๆ ไม่ควรที่จะถูกขยายให้ซับซ้อนจนเกินความจําเป็น” หรือถ้าจะพูดง่าย ๆ ก็คือ คำอธิบาย/การขยายความที่เรียบง่ายที่สุด มักจะเป็นคำอธิบายที่ถูกต้อง” – Wikipedia
ความหมายของมันในโลกของ Programming ก็คือ อย่าสร้างสิ่งใดก็ตามโดยที่มันยังไม่จำเป็น ลองคิดดูว่า สิ่งเหล่านี้มันมีความจำเป็นหรือไม่ เพราะมันอาจทำให้เกิดความซับซ้อนใน Codebase ของคุณมากยิ่งขึ้น
ISM Technology Recruitment Ltd. (#1 Tech Recruiter in Thailand) เราเชี่ยวชาญในธุรกิจ IT Recruitment & IT Outsourcing โดยเฉพาะ เปิดทำการมา 30 ปี มีพนักงานทุกสายและทุกระดับทางด้าน IT ที่ได้ร่วมงานกับลูกค้าองค์กรใหญ่ที่มีชื่อเสียงและบริษัทข้ามชาติมากมาย
หากคุณเป็นคน IT ที่อยากทำงานท้าทายและร่วมงานกับองค์กรชั้นนำ สามารถฝากประวัติการทำงาน (Resume) ของคุณไว้กับ ISM ได้ที่ https://www.ismtech.net/submit-your-resume แล้วคุณจะพบว่าอนาคตและโอกาสก้าวหน้ากำลังรอคุณอยู่
Source: https://betterprogramming.pub/