ความยากลำบากของโปรแกรมเมอร์สมัยนี้คือมีเรื่องที่ต้องเรียนรู้เยอะมาก…

มากจนไม่รู้ว่าจะเริ่มต้นที่ไหนดี

บทความนี้รวมสิ่งที่ผมคิดว่าสำหรับโปรแกรมเมอร์มือใหม่ ควรจะเรียนรู้เอาไว้ ไม่ว่าจะเป็นสาย Frontend, Backend, หรือ Fullstack เรื่องพวกนี้ได้ใช้แน่ๆ และได้ใช้นานด้วย

ผมเชื่อว่าความรู้พวกนี้ ในอีก 20 ปีข้างหน้า โปรแกรมเมอร์ยุคนั้นก็ยังต้องรู้กัน (ถ้าไม่โดน AI แย่งงานไปก่อน)

แทนที่จะเอาเวลาไปเรียนรู้พวกเฟรมเวิร์ค ภาษา หรือไลบรารี่ที่เปลี่ยนใหม่ทุกๆ 3-5 ปี เรียนรู้พวกนี้ดีกว่าครับ เรียนรอบเดียว ใช้ยาว

มาดูกันครับว่ามีอะไรบ้าง

Git

ยังไงโปรแกรมเมอร์ก็ต้องใช้ Version Control ครับ

ผมหวังว่าในทีมที่ทำงานอยู่ คงใช้ Version Control กันนะครับ ถ้าไม่ใช้นี่เป็นสัญญาที่แย่มากๆ อยากให้พิจารณาย้ายที่ได้เลย

ถ้าไม่ได้กะอยู่กับเทคโนโลยีของ Microsoft แต่อย่างเดียว ตัว Version Control ที่ใช้ ยังไงก็หนีไม่พ้น Git

สำหรับโปรแกรมเมอร์ที่เคยใช้งาน Git ในระดับหนึ่ง คงทำ Commit, push, pull กันตามปกติอยู่แล้ว

นอกเหนือจากนั้น มีอีกหลายๆคำสั่งที่รู้ไว้ ได้ใช้แน่ๆ

1. Concept of Staging
2. Branch, tag, merge, rebase, conflict resolution, cherry-pick
3. Revert, Reset (soft/hard)
4. Reflog
5. Stash

พวกนี้เป็นคอนเซ็บที่ถ้าไม่รู้ไว้ว่าทำได้ ต่อให้มี Google ก็ไม่รู้จะหาด้วยคีย์เวิร์ดอะไร ซึ่งมักจะจบที่ต้องหาท่าแปลกๆ ประหลาดๆ มาทำ ทั้งๆที่มีคำสั่งให้ใช้อยู่แล้ว

ถ้ามีเวลา ไม่ต้องคิดอะไรมาก อ่านเล่มนี้เลยครับ เล่มเดียวจบ

• Pro Git

Linux + Command Line Interface (CLI)

สำหรับคนที่โตมากับวินโดว์อย่างผม การใช้ Command Line เป็นอะไรที่น่ากลัวมากในช่วงแรกๆ

ยิ่งผมทำ Frontend เป็นหลักในช่วงแรก เวลามีอะไรพังใน Backend นี่เซ็งมาก ชีวิตจะวนลูปประมาณนี้

• ssh นี่ทำไงนะ ไม่ได้เข้าไปนานแล้ว
• CPU/Memory เต็มรึเปล่า ใช้คำสั่งอะไรดีเนี่ย เอ้ะ ทำไมค่า Load มันเยอะจัง ค่านี้มันอะไรนะ
• หา Log file ไม่เจอ คำสั่งหานี่มันอะไรนะ
• อ่าน Log file นี่มันคำสั่งอะไรนะ แล้วจะหา Error ในไฟล์นี่ทำไงดี

พอทำซ้ำๆไปสักสิบยี่สิบรอบ ก็ต้องยอมรับความจริงครับ ว่ายังไงก็ต้อง

• ชำนาญ CLI และจำคำสั่งได้ในระดับหนึ่ง
• เข้าใจว่า Linux มันทำงานยังไง
• แก้อะไรเล็กๆน้อยๆด้วย vi ได้

ผมแนะนำหนังสือสองเล่มนี้ครับ อ่านง่าย ไม่ทฤษฏีมากเกิน

• How Linux Works
• Linux Command Line

จริงๆ วิธีการที่จะทำให้เป็น Linux เร็ว คือเลิกใช้ Windows ครับ ซึ่งผมแนะนำมากนะ กัดฟันทนไปสักเดือน ชีวิตจะดีขึ้นมาก

เพราะพอทำทุกอย่างผ่าน Command Line ได้ คุณจะรู้สึกว่า UI นี่เป็นอะไรที่ทำงานได้ช้ามาก พอเวลาผ่านไปอีกสักพัก คุณจะเริ่มเขียน Bash Script ง่ายๆเองเพื่อประหยัดเวลา ซึ่งเป็นพื้นฐานที่สำคัญมากสำหรับการทำ Operation ในอนาคต

Shortcut ของ IDE/Editor ที่ใช้อยู่

วันวันนึง เราใช้เวลากับ IDE/Editor เยอะมากนะครับ

ไม่ใช่แก้การเขียนอย่างเดียว แต่รวมไปถึงการอ่านโค้ด กระโดดไปไฟล์นู้นไฟล์นี้

ดังนั้น ใช้เวลาเรียนรู้ Shortcut มันให้คล่องครับ

การทำงานด้วย Keyboard อย่างเดียวเร็วกว่าใช้เม้าส์มาก IDE/Editor ใหม่ๆ สามารถ Config ให้ทำทุกอย่างผ่าน Keyboard ได้กว่า 90%

นอกเหนือจากเรื่องว่ามันเร็วขึ้นแล้ว มันทำให้เราโฟกัสกับงานได้ง่ายขึ้นด้วย

โดยปกติ ความจำระยะสั้นของมนุษย์เราจะได้ประมาณ 3-7 อย่าง แต่ Shortcut จะจำด้วย Muscle memory (เหมือนเวลาเราพิมพ์สัมผัส) ทำให้ไม่ต้องทำ Context Switching ในสมอง

ตัวอย่างเช่น เราจะ Extract Method ทีนึง ถ้าต้องมานั่งไล่เม้าส์ไปตามเมนูแล้วกด Edit->Refactor->Extract Method…

เทียบกับกด Shortcut ทีเดียวจบเลย เหมือนกดคีย์บอร์ดหนึ่งจึ้ก

เอาพื้นที่ในสมองไปโฟกัสกับงานที่เราต้องทำจริงๆดีกว่าครับ

(สำหรับ Web Dev) Chrome Developer Tool

สำหรับใครที่ทำเว็บ ใช้เวลาสักสิบนาทีทุกวันเรียนรู้ Chrome Dev Tool ให้ละเอียดเลยครับ นี่เป็นความรู้ที่จะได้ใช้ไปอีกนานแน่นอน

จากประสบการณ์ Tool ตัวนี้ถ้าใช้เป็น สามารถลดเวลาดีบั้กได้สองสามเท่าเลยนะครับ เวลาผมประเมิน Web Dev ว่าเก่งแค่ไหน ผมดูจากการใช้ Chrome Developer Tool นี่แหละ

ตัวอย่างเช่น

1. Shortcut ต่างๆ (ex. Ctrl + O ในการกระโดดไปยัง File ต่างๆ)
2. Breakpoints/Blackboxing (ex. Set Event breakpoint + blackboxing เพื่อกระโดดข้าม Library event handler ไปยังโค้ดของเราเลย)
3. Network tab (ex. เข้าใจค่าต่างๆ, ความหมายของแถบสี) ใช้วิเคราะห์ได้ว่าเว็บโหลดช้าตรงไหน
4. Profiling

วิธีการจำเทคนิคต่างๆของ Chrome Developer Tool คือต้องใช้จริงครับ อย่าอ่านอย่างเดียว ลองสร้างสถานการดูว่าเทคนิคต่างๆที่พึ่งเรียนรู้ จะเอามาใช้กับงานที่เราทำอยู่ได้อย่างไร

Design Patterns

เวลาเขียนโปรแกรมไปสักพักหนึ่ง ความยากจะไม่ได้อยู่ในเรื่องของตัวภาษา แต่ไปตกในเรื่องของการออกแบบมากกว่า

ถ้าเป็นในโลกของ Object-oriented Programming ความยากคือจะออกแบบคลาสยังไงให้ทำงานแต่พอดี ไม่มากไม่น้อยไป แล้วทำยังไงให้คนอื่นที่มาอ่านโค้ดเราเข้าใจการออกแบบของเราได้ง่าย

Design Patterns เป็นรูปแบบการออกแบบที่ใช้กันบ่อย เป็นคอนเซ็บที่ได้ใช้ไม่ว่าจะเขียนภาษา Object-oriented ภาษาอะไร

การเรียนรู้ Design Patterns ทำให้เราเข้าใจ “ภาษากลางในการออกแบบ” ซึ่งสะดวกในการสื่อสารระหว่างโปรแกรมเมอร์

เวลาผมคุยกับโปรแกรมเมอร์อื่นๆ ก็เรียกทับศัพท์เลย “ตรงนี้ใช้ Adapter pattern ดีไหม?” ไม่ต้องอธิบายเพิ่ม ก็จะเป็นอันรู้กันเลยว่ากำลังจะให้ออกแบบแบบไหน

ผมเลยถือว่านี่เป็นหัวข้อพื้นฐานที่ไม่ว่าเขียนภาษา Object-oriented ภาษาไหนก็ควรจะเข้าใจ

• Desing Patterns by GoF เล่มต้นฉบับ
• Head First Design Patterns ถ้าดูเล่มต้นฉบับแล้วงง ผมแนะนำเล่มนี้ครับ อ่านง่ายกว่า

Docker

ผมเป็นคนที่ไม่ค่อยชอบใช้เวลากับเทคโนโลยีใหม่ๆมาก เพราะส่วนใหญ่ไม่ได้แก้ปัญหาที่แท้จริง และหากคนไม่ใช้กัน เราก็จะกลายเป็นเรียนรู้ฟรี

แต่ Docker เป็นข้อยกเว้น นี่เป็นหนึ่งในเทคโนโลยีที่ผมไม่ชอบการ Implement ของมันมากๆ บั้กเยอะ คอนเซ็บสับสนสุดๆ แต่ก็ใช้มันทุกวัน เพราะประโยชน์มันอยู่เหนือความไม่ชอบ

มันเอาไปใช้ทำ Dev Environment ได้ดี เอาไปทำ CI ก็ได้ เดี๋ยวนี้คนก็ใช้ใน Prod กันเยอะแล้ว

ยิ่งในโลกปัจจุบันที่นิยม MicroService กัน ผมเชื่อว่า Docker ยังอยู่กับเราไปอีกนานครับ

เล่มที่แนะนำครับ

• Docker In Action

เดี๋ยวนี้นอกจาก Docker เองแล้ว อาจจะต้องรู้เรื่อง Orchastration Tool ด้วย ซึ่งตอนนี้ Swarm, Kubernetes, Mesos ยังแข่งขันกันอยู่ ถ้าไม่ได้ต้องเซ็ตอัพอะไรใหญ่ๆเอง รอให้ชัดเจนก่อนว่าใครชนะแล้วค่อยเรียนรู้ก็ได้ครับ

สรุป

สำหรับคนที่เริ่มต้นเขียนโปรแกรม ถ้าจะเรียนรู้อะไร เรียนอันที่ใช้ได้นาน และได้ใช้ชัวร์ๆดีกว่า

เวลาเจอน้องที่ถามว่า “พี่ครับ เทคโนโลยี/เฟรมเวิร์ค xxx นี่มันจะมาไหม” ก็ต้องตอบว่าไม่รู้ครับ

และจะถามกลับว่า น้อง rebase ใน Git เป็นยัง ถ้าเซอร์เวอร์เดี้ยงควรจะเช็คอะไรบ้าง ถ้ายังไม่รู้พวกนี้ เอาเรื่องพวกนี้ก่อนเลยดีกว่า ได้ใช้ชัวร์ๆ

ชื่อมันอาจจะไม่ค่อยเท่เหมือนเทคโนโลยีใหม่ๆ แต่จะเร็วจะช้า ยังไงก็ต้องเรียนรู้อยู่ดี