See the original English version of this article here
ในการทำงาน เราสามารถเรียนรู้ได้จากหลากหลายวิธี แต่วิธีหนึ่งที่น่าสนใจก็คือ การเรียนรู้จากคนอื่น ๆ ที่มีความสามารถมากกว่าเรา ซึ่งบทความนี้คุณ Daniel Anderson ได้บอกเล่าถึง 19 สิ่ง ที่ได้ (แอบ) เรียนรู้จาก Developer เก่ง ๆ มา เรามาดูกันว่าจะมีอะไรบ้าง
1. กฏ 3 สิ่ง
กฏ 3 สิ่ง หรือ “Rule of 3” เป็นกฎง่าย ๆ ในการ Refactor Code เพื่อตัดสินใจว่า เมื่อใดที่ “ส่วนของ Code ที่ถูกใช้งานซ้ำบ่อย ๆ” ควรถูกแทนที่ด้วย Code / Procedures / Methods ใหม่
“โดยทั่วไป คุณสามารถ Copy และ Paste Code ได้ครั้งเดียว แต่เมื่อ Code เดียวกัน ถูกใช้งานซ้ำ 3 ครั้งขึ้นไป ส่วนของ Code นั้น ควรจะถูกแยกออกเป็น Procedure ใหม่”
แนวคิดหลักคือ การสร้าง Code / Procedures / Methods เพื่อให้สามารถใช้งานซ้ำได้ในหลาย ๆ จุดของ Code
2. Consistency สำคัญที่สุด
ทำทุกอย่างให้สอดคล้อง (Consistency) กันไม่ว่าจะเป็น Structure หรือวิธีการเขียน Code ก็ตาม เพราะสิ่งนี้จะช่วยในเรื่อง Readability และ Maintainable ใน Application ของคุณ
การใช้ Coding Standard จะช่วยในเรื่อง Consistency ไม่ว่าจะเป็นแนวทางการตั้งชื่อตัวแปรของคุณ หรือแม้แต่สิ่งที่สำคัญอย่าง Structure ของ Application ซึ่งควรต้องกำหนดให้ชัดเจนว่า Developer ต้องทำการเปลี่ยนแปลงหรือเพิ่มเติมสิ่งใดเข้าไปบ้าง
3. ลดการใช้ Nesting
การใช้ “IF” ซ้อน ๆ กัน อาจทำให้ยากในการอ่านทำความเข้าใจได้ บางครั้งคุณอาจไม่สามารถแก้ไขปัญหาเหล่านี้ได้ แต่คุณต้องดู Structure ของ Code ของคุณด้วยเสมอ
ซึ่งก็เช่นเดียวกันกับการใช้ “ELSE IF” ถ้าเลี่ยงได้ก็ควรเลี่ยงที่จะใช้มัน เพราะอาจทำให้อ่าน Code ได้ยากขึ้น
“การใช้ Guard Clause ดูจะเป็นวิธีที่มีประสิทธิภาพในการช่วยแก้ปัญหาในเรื่องนี้”
ตัวอย่าง กรณีที่ไม่ใช้ Guard Clause:
ตัวอย่าง กรณีที่ใช้ Guard Clause:
4. ให้นึกถึงภาพที่ใหญ่ขึ้น
การได้เข้าใจในภาพที่ใหญ่ขึ้น ถือเป็นสิ่งสำคัญมาก เพราะมันจะช่วยทำให้สามารถติดตามรายละเอียดที่เล็ก ๆ ได้ง่ายขึ้น เมื่อคุณเข้าใจภาพที่ใหญ่ขึ้นแล้ว คุณจะใช้เวลาไม่นานในการแก้ไขปัญหาในสิ่งที่มีรายละเอียดเล็ก ๆ น้อย ๆ
5. ใช้เวลาคิดเกี่ยวกับการตั้งชื่อสิ่งต่าง ๆ
การตั้งชื่อสิ่งต่าง ๆ ในการ Coding ถือเป็นสิ่งที่ยากที่สุดอย่างหนึ่งที่คุณสามารถทำได้ ซึ่งอาจเป็นการตั้งชื่อ Class, Method หรือแม้แต่ตัวแปร
Developer ที่ยอดเยี่ยม จะใช้เวลาเพื่อคิดชื่อที่เกี่ยวข้อง เนื่องจากพวกเขารู้ว่า สิ่งนี้ช่วยในเรื่องของ Readability
6. Technical Debt เป็นสิ่งที่แย่
การประมาณการงานให้สูงเกินกว่าความเป็นจริง(Overestimate) สามารถช่วยในเรื่องนี้ได้ จงพยายามเขียน Code ให้ดีที่สุดเท่าที่จะทำได้ ไม่เช่นนั้นคุณจะต้องกลับมาอ่าน Code ใหม่ซ้ำแล้วซ้ำอีก
“Technical Debt เป็นแนวคิดในการพัฒนา Software ที่สะท้อนถึงต้นทุนโดยนัยของการทำงานซ้ำ ๆ ซึ่งเกิดจากการเลือก Solution ที่ง่าย (จำกัด ) ในตอนนี้ แทนที่จะใช้แนวทางที่ดีกว่าซึ่งอาจจะใช้เวลาที่นานกว่า”
7. Overestimate
มันอาจจะรู้สึกแปลกสักหน่อย และขึ้นอยู่กับว่าคุณทำงานอยู่ในฝ่ายใด คุณอาจไม่ค่อยชอบในเรื่องนี้ แต่คุณคงเคยได้เห็น Developer ที่เก่ง ๆ มักจะประมาณการงานของพวกเขาให้สูงเกินกว่าความเป็นจริง เนื่องจากพวกเขารู้ว่า สิ่งต่าง ๆ จะใช้เวลานานกว่าที่คุณคาดหวังไว้เสมอ และการประมาณการให้สูงกว่าความเป็นจริง จะสามารถช่วยคุณให้สามารถทำสิ่งต่าง ๆ ได้ถูกต้องยิ่งขึ้น
สิ่งนี้สามารถช่วยในประเด็นก่อนหน้านี้ได้ เพราะ “Technical Debt ไม่ใช่เรื่องที่ดี” หากคุณประมาณการเวลาที่พิจารณาเฉพาะในแง่บวกก็สามารถเป็นต้นเหตุให้เกิด Technical Debt ได้ เนื่องจากคุณจะมีเวลาทำให้มันแค่ใช้งานได้เท่านั้น แต่ไม่มีเวลามากพอที่จะทำให้ Code ของคุณ Clean และง่ายต่อการ Maintain
8. Documentation และ Code Comments
สิ่งเหล่านี้จะช่วยให้ทุกคนเข้าใจในบริบทต่าง ๆ และยังเป็นการแบ่งปันความรู้อีกด้วย คุณอาจเคยได้ยินคนที่มีประสบการณ์มาก ๆ กล่าวว่า เราควรจะจัดทำ Document ของ Process นั้น หรือไม่ก็ล้มเหลวในการ Review Code เนื่องจากไม่มี Comment เกี่ยวกับสิ่งต่าง ๆ อย่างเช่น Interfaces
9. มั่นใจในการลบ Bad Code
คุณจะเห็น Developer จำนวนมากที่ไม่ค่อยมั่นใจในการ Comment เกี่ยวกับ Code จำนวนมากและสุดท้ายก็ทิ้งมันไว้แบบนั้น เรามี Version Control ไว้เพื่อจุดประสงค์บางอย่าง Developer ที่เก่ง ๆ จะไม่รู้สึกอายที่จะลบส่วนที่ไม่ดีของ Application
10. ใช้เวลาในการ Review Code
Developer ที่ดี จะใช้เวลาในการ Review Code ให้นานขึ้น และเข้าใจถึงความสำคัญของการ Review Code ซึ่งมีข้อดีหลายข้อดังนี้
-
- ช่วยให้สามารถค้นหา Bugs เจอตั้งแต่ต้น
- ช่วยปรับปรุงทักษะของ Developer และนำทีมที่เหลือไปสู่แนวทางปฏิบัติที่ดี
- เป็นการแบ่งปันความรู้กัน
- ช่วยให้มี Design และการ Implement ที่สอดคล้องกัน
กระบวนการ Review Code ที่ดีที่สุดที่ Developer เก่ง ๆ มักทำกันก็คือ:
สำหรับงานเล็ก ๆ ที่มีความเสี่ยงน้อย – ควรได้รับการ Review โดย Developer เพียงคนเดียวก็เพียงพอ
สำหรับงานที่มีการเปลี่ยนแปลงที่มากขึ้นหรือเป็นการเปลี่ยนแปลงที่มีความเสี่ยง – ควรได้รับการ Review โดย Developer 3 คน โดยมีคนหนึ่งที่เป็น Senior Developer
สำหรับการเปลี่ยนแปลงที่มีความเสี่ยงสูงมากหรือต้องสร้างส่วนใหม่ ๆ ใน Application ที่กำลังถูก Develop – ควรมีการ Meeting กันและมี Developer 3 คน ซึ่งอย่างน้อย 1 คนควรเป็น Lead Developer ที่ทำงานร่วมอยู่ในทีม
11. เขียน Test ที่ดี
คุณจะสังเกตเห็นว่า Developer ที่มีประสบการณ์และเก่งมาก ๆ จะใช้เวลาให้มากขึ้นเพื่อเขียน Test ที่ดี
การมี Test ที่ดี จะช่วยให้คุณปรับขนาด (Scalable) ของ Application ได้อย่างมั่นใจ และช่วยลด Bugs ได้มากขึ้น
12. ใช้เวลาในการ Design
ก่อนที่ Developer จะดำดิ่งลงไปใน Code พวกเขาควรจะพิจารณาและแบ่ง Code ออกเป็นส่วนย่อย ๆ สิ่งนี้จะช่วยให้พวกเขาในการเตรียมพร้อมได้มากขึ้นว่า ทุกอย่างสามารถเข้ากันได้อย่างไรบ้างและสร้าง Code ที่ Clean มากขึ้น
13. มุ่งเน้นในสิ่งที่เป็นพื้นฐานไม่ใช่ Syntax
นี่ถือเป็นเรื่องใหญ่ Developer ที่เก่ง ๆ จะชอบเรียนรู้สิ่งที่เป็นพื้นฐานมากกว่าที่จะเน้นไปที่ Syntax มากเกินไป สิ่งนี้ช่วยให้พวกเขาค้นหาปัญหาได้อย่างมีประสิทธิภาพมากขึ้น นอกจากนี้ยังสามารถช่วยให้ค้นหาปัญหาต่าง ๆ จาก Google ด้วยความเข้าใจมากขึ้น
14. Google คือเพื่อนที่ดีที่สุดของคุณ
Developer เก่ง ๆ จะมีความเชี่ยวชาญในการค้นหาข้อมูลใน Google เพื่อช่วยแก้ปัญหาของพวกเขา สิ่งนี้ช่วยในหัวข้อก่อนหน้านี้ คือ “มุ่งเน้นในสิ่งที่เป็นพื้นฐานไม่ใช่ Syntax”
เนื่องจากพวกเขามุ่งเน้นไปที่สิ่งที่เป็นพื้นฐาน จึงทำให้รู้ว่าควรจะค้นหา Google ด้วยคำไหน นี่เป็นเรื่องยากหากคุณหมกมุ่นอยู่กับการเรียนรู้แต่ Syntax
15. ทำให้มันใช้งานได้ก่อนแล้วค่อยปรับแต่งให้ดีขึ้นภายหลัง
คุณคงเคยเห็นว่า Developer ที่ยังไม่เก่งหรือประสบการณ์น้อย มักจะใช้เวลาไปมากมายกับการทำให้ Code ดูดีตั้งแต่ช่วงต้นของการเขียน Code จากนั้นถึงกลับมาดูว่าทำไม Code ของพวกเขาถึงไม่ทำงานอย่างที่ควรจะเป็น
Developer ที่เก่ง ๆ จะมีความสุขในการทำงานมากกว่า เนื่องจากวิธีการนี้จะช่วยให้พวกเขาสามารถระบุปัญหาได้ตั้งแต่เนิ่น ๆ ก่อนที่จะมาปรับแต่งให้ Code ดูดีอ่านง่าย ซึ่งยังช่วยให้ Projects มีความราบรื่นขึ้นอีกด้วย
16. การจัดการความเสี่ยงและการแก้ไขปัญหา
Senior Developers จะสามารถระบุความเสี่ยง รวมทั้งสามารถแยกแยะปัญหาที่ซับซ้อนผ่านการประยุกต์ใช้ Design Pattern และสามารถแก้ไขปัญหาต่าง ๆ ได้ดี จากประสบการณ์ที่ผ่านมาของพวกเขา
17. รู้จักตั้งคำถาม
Developer ที่เก่ง ๆ มักจะต้องการรู้ในทุก ๆ อย่าง พวกเขาไม่อายที่จะถามคำถามแม้ว่าสิ่งนั้นจะฟังดูง่ายก็ตาม ซึ่งคำถามเหล่านี้อาจเป็นได้ทั้งคำถามทางด้านเทคนิค หรือเกี่ยวกับธุรกิจ
การเข้าใจความต้องการของธุรกิจ จะช่วยให้พวกเขาสร้าง Code ได้ดีขึ้น พวกเขาไม่กลัวที่จะถามคำถามเพราะพวกเขามั่นใจในความสามารถของตนเอง
18. ถ้าเป็นไปได้ อย่าเอา Logic ไปใช้กับ Database
ประเด็นนี้ขึ้นอยู่กับประเภทของ Application ที่คุณกำลังสร้าง และมันจะไม่ส่งผลกระทบต่อประสิทธิภาพ
Developer ที่เก่ง ๆ จะรู้ว่าควรทำให้ Database Queries ของพวกเขาง่ายต่อการ Create, Read (หรือที่เรียกกันว่า Retrieve), Update และ Delete
จากนั้น ส่วนของ Business Logic ควรจะดึงสิ่งนี้เข้าด้วยกัน ซึ่งจะช่วยให้ Developer ทราบว่า พวกเขาจะค้นหา Business Logic ได้จากที่ใด สิ่งนี้จะทำให้เกิดความยุ่งยากได้อย่างรวดเร็วหากคุณใช้ Logic ใน Database Queries และใน Code
19. KISS (Keep It simple, Stupid)
Developer เก่ง ๆ จะรู้ว่า การทำให้ Code เรียบง่ายเป็นสิ่งที่ควรทำ แม้ว่านั่นจะหมายถึง การต้องเขียน Code เพิ่มขึ้นในบางครั้ง คุณอาจจะได้เห็น Developer ประสบการณ์น้อยจำนวนมาก ที่เขียน Code ที่ดูเจ๋ง ๆ ในบรรทัดเดียว ดังด้านล่างนี้:
มันเป็น Code ที่ใช้งานได้ แต่แน่นอนว่ามันอ่านยากมาก
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://medium.com/