| description |
|---|
เราเข้าใจว่ามันต้องเป็นแบบนี้ แล้วรู้ได้ไงว่าเราเข้าใจมันถูก? |
เราทุกคนมีความเชื่อบางอย่างตั้งแต่เริ่มหัดโค้ดกันทุกคนอยู่แล้ว แล้วพอเขียนโค้ดมาได้เรื่อยๆ อ่านบทความ อ่านโค้ดคนอื่นมาเรื่อยๆ เราก็จะมีมุมมองที่ตกผลึกกลายมาเป็น ความเชื่อของเรา กันอยู่ทุกคน แต่ในหลายๆครั้งเวลาที่เราไปทำงานกลับพบว่า โดนเขาดุบ้าง โดนปฏิเสธงานกลับมาบ้าง บลาๆ เชื่อไหมว่าในหลายๆครั้งมันก็เกี่ยวกับความเชื่อที่ฝั่งอยู่ในหัวเราก็ได้ ดังนั้นในรอบนี้ผมจะขอแชร์มุมมองที่ผมเจอข้อผิดพลาดทั้งของตัวเองและของคนอื่นๆให้ฟังกันบ้างนะ
รับฟังความคิดเห็นคนอื่นบ้างแล้วเอาไปวิเคราะห์ว่าเราควรจะปรับไหม? และปรับยังไง? โดยสิ่งแรกที่เราควรจะทำคือการ เปิดใจฟัง เสียงอื่นนอกจากเสียงของตัวเองบ้าง และที่สำคัญไม่แพ้กันเลยคือเรียนรู้ความผิดพลาดของคนอื่น ตามหัวข้อด้านล่างนี้
{% hint style="warning" %} ไม่ได้ตั้งใจให้บทความนี้ยาวขนาดนี้เลย แต่มันก็เป็นเรื่องจริงที่อยากจะแชร์ว่าส่วนใหญ่เราจะเจอคนที่มี mindset พวกนี้บ่อยมากในวงการ ดังนั้นเลือกๆอ่านหัวข้อที่สนใจเอาละกันเน่อ {% endhint %}
ส่วนใหญ่ 99% ไม่จริงครับ การที่แข่งกันสั้นไม่ได้หมายความว่ามันจะทำงานได้เร็วหรือดีเสมอไป เพราะจำนวนบรรทัดไม่สามารถนำไปวัด performance ได้จริงๆนั่นเอง มันขึ้นอยู่กับ BigO ของ function ที่เราเรียกใช้จริงๆต่างหาก
ยกตัวอย่างให้เข้าใจมากขึ้น ผมจะลองเขียนโค้ด C# สร้าง array ตัวเลข 1~100 โดยใช้โค้ด 2 แบบเทียบกันดู
แบบที่ 1
var numbers = new int[100];
for (int i = 0; i < numbers.Length; i++)
{
numbers[i] = i + 1;
}แบบที่ 2
var numbers = Enumerable.Range(1, 100).ToArray();
คิดว่าแบบ 1 หรือแบบที่ 2 เร็วกว่ากันครับ ? ... ติ๊กตอกๆๆ ... เชื่อไหมว่าพอๆกัน แม้ว่าแบบที่1 จะใช้ทั้งหมด 5 บรรทัดแต่ในขณะที่ แบบที่ 2 ใช้แค่บรรทัดเดียวก็ตาม ส่วนสาเหตุที่เท่ากันเพราะ ตัว function ในแบบที่ 2 จริงๆมันทำงานแทบจะเหมือนแบบที่ 1 เลยครับ เพียงแค่เราเรียกใช้มันได้ง่ายเฉยๆ
แต่ที่พูดมาไม่ได้หมายความว่าจะให้เขียนยาวๆนะ แต่ให้เลือกใช้สิ่งที่ทีมรู้จักและคำสั่งที่เหมาะสมดีกว่าครับ
{% hint style="danger" %}
ผลเสียจากการเขียนโค้ดสั้น
โค้ดอาจจะไม่ Clean และมีแนวโน้มสูงว่าคนอื่นจะไม่เข้าใจโค้ดตัวนั้น ทำให้งานมากองไว้กับคนที่เขียนคนเดียว ถ้าจะแก้ต้องเป็นคนนี้เท่านั้น และเวลาที่จะเพิ่มความสามารถให้โค้ดตัวนั้นก็จะกลายเป็นเรื่องยาก เพราะบางทีคนเขียนก็ลืมว่ามันย่อแบบนั้นได้ยังไง
{% endhint %}
{% hint style="success" %}
จงเขียนโค้ดให้ Clean
แทนที่จะแข่งกันเขียนให้สั้น เปลี่ยนเป็นแข่งกันเขียนให้ Clean ดีกว่าครับ คนอื่นในทีมทำความเข้าใจง่าย เพิ่มความสามารถใหม่ๆก็ง่าย (อ่านเรื่อง Clean Code ได้จากลิงค์นี้ จิ้มตรงนี้ด้วยความอ่อนโยนเลย)
{% endhint %}
{% hint style="info" %}
จงอย่าเชื่อเพราะมีแมวน้ำมาบอก แต่จงพิสูจน์
สามารถเข้าไปดูการทำงานจริงๆของ Enumerable.Range() ได้ที่ลิงค์ด้านล่างนี้ครับ บรรทัดที่ 1,265~1,273 คือการทำงานที่แท้จริงของ method นี้ซึ่งทาง Microsoft ได้เปิดแชร์ source code ให้ทั่วโลกเห็น อยู่บน GitHub แล้วนะครับ
Microsoft GitHub .NET Core Enumerable
{% endhint %}
อย่ามาให้ผมเจอเชียว จะหอมแก้มซักฟอดใหญ่ๆ 🤞 ซึ่งเชื่อไหมว่า developer หลายๆคนชอบทำกัน (แต่ก่อนผมก็ชอบฮ่าๆ) แต่เชื่อไหมว่าคนที่เขียนโค้ดระดับปรมาจารย์ในวงการทุกคน เวลาเขาเขียนโค้ดทีไร มันจะออกมาแบบพื้นมากๆ ไม่ใช่เขียนกากๆนะ แต่โค้ดไม่ได้สลับซับซ้อนใดๆเลย อ่านแล้วเข้าใจได้ง่ายด้วย และสิ่งที่มหาเทพพวกนี้สอนพวกเราตลอดเวลาคือ Keep it simple ทำให้มันง่าย นั่นเอง
ทำไมต้องเขียนให้โค้ดมันง่าย? ลองคิดดูนะ ถ้าโค้ดที่เราเขียนมันใช้เวลาทำความเข้าใจยาก นั่นหมายความว่ามันก็จะเสียเวลาไปทำความเข้าใจโค้ดในส่วนนั้น หรือแม้จะแก้ไขก็ยากด้วยเช่นกัน เพราะอะไรต่อมิอะไรมันพันกันเป็นสปาเก็ตตี้ไปหมดยังไงล่ะ
เผื่อสนใจไปลองอ่านสปาเก็ตตี้โค้ดเล่นได้นะครับ Amazon book - $4.99 USD แต่ถ้าไม่อยากซื้อก็ไปอ่าน Clean Code ได้ฟรีที่นี่ 😛
{% page-ref page="clean-code/" %}
{% hint style="danger" %}
ผลเสียจากการเขียนยากๆ
เหมือนเขียนโค้ดสั้นๆเลย และเพิ่มเติมคือจะทำให้ระบบซับซ้อนโดยไร้สาระอีกต่างหาก
{% endhint %}
{% hint style="success" %}
จงเขียนโค้ดให้ Clean
เหมือนเดิมเลย เขียนให้คลีนซะจะเป็นอภิมหาบุญของตัวเราและคนในทีม ต่อไปนี้ผมจะไม่เขียนว่า จงเขียนโค้ดให้ Clean แล้วนะ เพราะทุกประเด็นชี้กลับมาที่เรื่องนี้หมดทุกตัวเลย
{% endhint %}
{% hint style="info" %}
จงอย่าเชื่อเพราะมีแมวน้ำมาบอก แต่จงพิสูจน์
หลักในการออกแบบโค้ดมีตัวนึงที่ชื่อว่า KISS (keep it simple, stupid) คือทำทุกอย่างให้ง่ายเข้าไว้ ซึ่งไม่ใช่แบบมักง่ายนะ แต่ต้องถูกลั่นมาแล้วทำให้ง่ายต่อการใช้งาน ซึ่งสามารถศึกษาต่อได้จากลิงค์นี้ครับ Wikipedia - KISS
{% endhint %}
ในหลายๆครั้งเวลาที่เราแก้ปัญหาไม่ได้ เราก็จะไปหาจากโค้ดจากเน็ทมาชิมิ? แล้วก็ลองเอาไปใช้ดูซึ่งบางทีก็ใช้ได้ แล้วพอใช้ได้เราทำไงต่อ? ส่วนใหญ่ก็จะปล่อยโค้ดตัวนั้นไปเลยเพราะมันทำงานได้แล้วนิ!
ในความเป็นจริงการเขียนโค้ดมีหลายระดับ ซึ่งถ้างานที่เราได้รับมันเป็นแค่ตัวอย่าง (PoC) ก็อาจจะปล่อยโค้ดไว้แบบนั้นก็ได้ แต่สำหรับงานที่เขียนจริงใช้จริงมีลูกค้าจริง หรือที่เราเรียกว่างาน Production นั้น เราไม่สามารถทำแบบนั้นได้ครับ (สำหรับบริษัทที่ให้ความสำคัญกับตัวงานจริงๆ เขาจะไม่ปล่อยให้มีของแบบนี้หลุดออกมา) เพราะโค้ดที่ทำงานได้มันไม่ได้หมายความว่ามันเป็น Production Code เสมอไป และโค้ดที่เราก๊อปมามันอาจจะแค่ทำงานได้แต่มันอาจจะทำให้ประสิทธิภาพในการทำงานตกลงจนทำให้ Server down โดยไม่รู้สาเหตุก็เป็นได้นะ
สุดท้ายโค้ดที่ก๊อปๆมา ในหลายๆทีเราก็ไม่ได้ทำ Refactor ด้วย ก็ยิ่งทำให้กลายเป็น Bad Code ส่งกลิ่นเหม็นคลุ้งไปหมดด้วย อ่านบทความเรื่อง Code Smells ได้จากลิงค์นี้
{% page-ref page="code-smells.md" %}
{% hint style="danger" %}
ผลเสียจากการก๊อปโค้ดมาใช้
โค้ดไม่ Clean, โค้ดไม่เหมาะกับลักษณะการทำงาน ซึ่งส่งผลให้ performance ตกลงอย่างที่ไม่ควรเป็น และทำให้คนอื่นๆในทีมเลียนแบบพฤติกรรม และที่สำคัญที่สุดคือ โค้ดที่ไปก๊อปมาอาจจะทำให้ระบบซับซ้อนมากขึ้นโดยไม่สมควรอีกด้วย
{% endhint %}
{% hint style="success" %}
ศึกษาปัญหาให้เข้าใจแล้วแก้ให้ถูกจุด
การไปดูจากเน็ทไม่ใช่เรื่องที่ผิด แต่การแก้ปัญหาจริงๆคือ เราต้องหาต้นเหตุของปัญหาที่แท้จริงว่ามันคืออะไรแล้วค่อยหาทางแก้ด้วยวิธีการที่เหมาะสม ไม่ใช่ก๊อปมาวางแล้วใช้งานได้ก็ปล่อยจบ และอย่าลืมทำ Refactor ด้วยเพื่อทำคลีนโค้ดด้วย
{% endhint %}
อันนี้เป็นบ่อยสำหรับ developer ที่รู้จักเทสใหม่ๆ หรือ ไม่ได้คลุกคลีกับการเขียน test case สักเท่าไหร่ จะรู้สึกว่าการเขียน test case เป็นอะไรที่ยุ่งยากเสียเวลา ทำไมไม่เอาเวลาไปเขียนโค้ดเลย!
ซึ่งในความเป็นจริงการเขียนเทสก่อนในระยะยาวจะทำให้ความเร็วในการเขียนโค้ดสูงขึ้นแบบเห็นได้ชัดเมื่อเทียบกับการไม่เขียนเทส เพราะเราไม่ต้องกลับมานั่งแก้ bug และเวลาที่เราเพิ่มความสามารถใหม่ๆให้กับโปรแกรมก็จะสามารถทำได้ทันที ไม่ใช่เขียน 1 จุด bug ผุดขึ้นมา 10 จุด นอกจากนี้การเขียนเทสเคสยังจะช่วยให้เราเข้าใจในสิ่งที่ลูกค้าต้องการได้อย่างถูกต้อง และข้อดีที่สุดในการเขียนเทสก่อนคือ โค้ดจะมีดีไซน์ที่ดีและสามารถทำ refactor เมื่อไหร่ก็ได้
ไปศึกษาการเขียนเทสได้จากคอร์สนี้เลย
{% page-ref page="../software-testing/tdd101/" %}
{% hint style="danger" %}
ผลเสียจากการไม่เขียนเทส
โค้ดมี bugs เยอะ, เพิ่มความสามารถใหม่ๆลงไปยาก, แก้ 1 จุดพัง 10 จุด, ทำในสิ่งที่ลูกค้าไม่อยากได้, ทีมเข้าใจไม่ตรงกัน โดยรวมๆมันส่งผลเสียทั้งต่อเราเองและต่อทีมสูงมาก และในระยะยาวจะทำให้เขียนแอพได้ช้าลงไปเรื่อยๆในขณะที่แอพมันโตขึ้น ดังนั้น
{% endhint %}
เรื่องนี้ผมขอตอบแบบนี้ละกันว่า ถ้าคุณยังไม่รู้ลึกจริงๆซัก 1 ภาษาก็ยังไม่จำเป็นต้องไปเรียนภาษาอื่นหรอก เพราะทุกๆภาษามันมีแก่นแท้เหมือนๆกัน ถ้าคุณตัสรู้เข้าใจมันจริงๆเพียงแค่ภาษาเดียว คุณก็จะสามารถเปลี่ยนไปเขียนอีกภาษาได้ภายในเวลาไม่นาน
จงเรียนให้เข้าใจแก่นแท้ซัก 1 ภาษาก่อนเอาที่ตัวเองถนัดหรือไม่ก็ที่มีคนแนะนำเราได้จริงๆจะเหมาะกว่า อย่าไปคิดว่าภาษานี้เท่กว่าภาษานี้ ภาษานี้ใหม่กว่าดีกว่า จับซัก 1 ตัวแล้วเหยียดขารู้มันให้สุดๆไปซะ!!
พูดให้เห็นภาพ สมมุติว่าตอนนี้แค่พูดภาษาไทยคุณยังงูๆปลาๆพูดผิดๆถูกๆอยู่เลย ก็อย่าพึ่งไปเรียนภาษาจีนดิ!! เอาภาษาไทยให้รอดก๊อนนนน!!! เพราะภาษาส่วนใหญ่บนโลกมันก็มีแก่นแท้โครงสร้างคล้ายๆกันนั่นแหละ ประธาน-กิริยา-กรรม ส่วนพี่ญี่ปุ่นหรืออื่นๆเป็นเคสพิเศษช่างมันก่อน
{% hint style="success" %} แก่นแท้ของภาษาโปรแกรมส่วนใหญ่เหมือนกัน ดังนั้นศึกษาจนเข้าใจอย่างลึกซึ้งซักตัวก่อนแล้วที่เหลือจะเปลี่ยนภาษาเมื่อไหร่ก็ไม่ถึงเดือน {% endhint %}
Developer หลายคนไม่ชอบใช้ command line กัน เพราะ รู้สึกไม่ชิน ขี้เกียจไปจำคำสั่งต่างๆ หรือกลัวมันไปเลยก็มี และรู้สึกว่ามันทำงานได้ช้าลง
ความจริงคือ command line นี่แหละคือตัวเทพเลย เพราะไม่ว่าจะเป็นภาษาอะไรก็ตามเวลาที่เขาอัพเดทความสามารถใหม่ๆให้กับตัว compiler ทำให้เราใช้คำสั่งแบบใหม่ๆได้นั้น มันก็เข้าไปอยู่ในชุดคำสั่งที่เป็น command line นั่นแหละ แล้วเวลาที่เราใช้เครื่องมือในการเขียนโค้ด เช่น Visual Studio, Android Studio, Eclipse, NetBeans, IntelliJ อะไรพวกนี้ สุดท้ายเวลาที่เราจิ้มคำสั่งต่างๆลงไปสุดท้ายมันก็มาเรียกใช้ command line ให้ทำงานอยู่ดีนั่นเอง และในหลายๆทีที่ตัว IDE ยังไม่มีคำสั่งแบบนี้ แต่ใน command line กลับมี ก็แหงล่ะ command line มันเป็นตัวที่ใหม่กว่า IDE นิ และเราสามารถใส่ option ต่างๆได้โดยที่บางทีใน IDE กลับทำไม่ได้ก็เจออยู่ถมเถไป
ถ้ายิ่งใช้ PowerShell ใน Windows นะรักเบย 😍
{% hint style="danger" %}
ผลเสียจากการไม่ใช้ command line
ต้องรอให้ IDE อัพเดทก่อนถึงจะทำบางเรื่องได้ ทั้งๆที่ทำได้ใน command line ตั้งแต่แรกอยู่แล้ว
{% endhint %}
{% hint style="success" %}
จงหัดใช้ Command line
เพราะมันเร็จดุจสายฟ้า ถ้าใช้เป็นจะเร็วยิ่งกว่ารอให้ IDE สั่งเสียอีก อีกทั้งภายในคำสั่งเดียวกันมันมี options ต่างเยอะมาในการใช้งาน และที่สำคัญเวลาที่เราเจอปัญหาใน IDE แล้วเราอ่านมันไม่เข้าใจ กลับพบว่าใน command line มีทางออกให้และอ่านง่ายกว่าด้วย
{% endhint %}
ผมเชื่อว่าหลายๆคนก็รู้จักคนที่มี mindset แบบนี้ และ หลายๆคนที่เป็นแบบนี้อยู่อาจจะไม่รู้ว่ามีข้อเสียอะไร (เพราะผมก็เคยคิดแบบนั้น ตอนนี้ฉีดยาหายแบ๊วนะ)
ในเรื่องการทำงานกับซอฟต์แวร์จริงๆมันไม่ได้ดูที่งานเราเสร็จหรือเปล่า แต่มันวัดกันที่ งานของทั้งทีมเสร็จหรือเปล่า ต่างหาก ลองคิดดูนะถ้างานที่ต้องส่งในอาทิตย์นี้ไม่สามารถส่งได้ คุณสามารถบอกลูกค้าว่างานส่วนของผมเสร็จอยู่นะแบบนี้ได้ไหม? ถ้างานของทีมไม่เสร็จมันก็คืองานของคุณไม่เสร็จไปด้วยกลายๆนั่นแหละ ดังนั้นจงอย่ามองแค่ตัวเองแต่ให้มองภาพรวมด้วย เพราะถ้ามันไม่เสร็จ บริษัทไม่ได้ผลประโยชน์ ทีมไม่ได้ผลประโยชน์ แล้วเราจะหวังผลประโยชน์จากเรื่องอะไร?
นอกจากเรื่องการทำงานแล้ว เรื่องการสนใจคนอื่นๆก็สำคัญ เพราะชีวิต developer นั้นขาดการอัพเดทไม่ได้ เพราะเทคโนโลยีสมัยนี้มาเร็วไปเร็วมาก คุณไม่มีทางเรียนรู้ทุกสิ่งด้วยตัวคนเดียวได้หรอก จงช่วยกันเป็นทีมจะดีกว่า
และไม้เด็ดของเรื่องนี้คือ ต้องพูดภาษามนุษย์เป็น ไม่ใช่พูดแต่คำศัพท์ programming เพราะคุณสมบัติการที่จะเป็น Leader ที่แท้จริงไม่ใช่เก่งแค่ในเรื่องเชิงเทคนิคเพียงอย่างเดียว แต่คุณจะต้องสรุปเรื่องราวต่างๆให้คนอื่นฟังเป็นภาษาคนได้ด้วย!!
ผมต้องเขียนข้อเสียในประเด็นนี้จริงๆเหรอ ???
{% hint style="success" %}
เปิดใจรับฟังความคิดเห็นคนอื่นบ้าง
ความคิดเห็นโง่ๆในสายตาเรา บางทีก็เป็นทางสว่างที่เราไม่เคยมอง จงอย่าสักแต่ฟังแต่จงวิเคราะห์มันให้หลากหลายแง่มุมด้วย
{% endhint %}
Developer หลายๆคนพอได้ยินว่าลูกค้าอยากได้อะไร ก็มักจะนึกถึงว่าเราจะต้องใช้ไอ้นู่นไอ้นี่ไอ้นี่ที่เป็นตัวใหม่ๆงานจะได้เท่ๆคูล์ๆกัน ซึ่งผมอยากแอบกระซิบว่า การทำซอฟต์แวร์อย่าเอาเทคโนโลยีมาเป็นตัวตั้งต้น! จงเอาความต้องการเป็นตัวตั้งต้นต่างหาก แล้วค่อยวิเคราะห์ดูว่าความต้องการนั้นเราจะเลือกใช้เทคโนโลยีอะไรถึงจะตอบโจทย์ลูกค้าได้
หลายครั้งที่เวลาเราเจอเทคโนโลยีใหม่ๆ เช่นช่วง Bitcoin กำลังบูม เราจะเห็นว่า developer วิ่งไล่จับเขียน Blockchain กันวุ่นวายเลย ผมไม่ได้บอกว่ามันผิดนะเพราะถ้า Requirement บอกว่ามันต้องใช้ Blockchain ถึงจะเอางานไปขายได้ อันนี้เราก็ต้องเขียน Blockchain แต่ถ้าไม่ใช่เราก็ไม่มีความจำเป็นต้องไปเขียน Blockchain เพราะ database ทั่วไปก็อาจจะตอบโจทย์แล้วก็ได้ #NoSQL ก็เช่นกัน หลายบริษัทชอบโดดมาจับ NoSQL ทั้งๆที่มันไม่ได้ตอบโจทย์ในตัวงานจริงๆเลย (เดี๋ยวจะเขียนบทความเรื่อง NoSQL อยู่รออ่านจาก side menu เอาละกัน)
{% hint style="danger" %}
ผลเสียจากการใช้เทคโนโลยีใหม่ๆเสมอ
ทีมขาดประสบการณ์ในเทคโนโลยีทำให้เกิดข้อผิดพลาดได้ง่าย ระบบพัฒนาได้ช้า และในหลายๆทีก็ทำให้งานซับซ้อนจากเทคโนโลยีนั้นๆโดยไม่จำเป็น
{% endhint %}
{% hint style="success" %}
Requirement คือจุดกำเหนิด
เวลาทำงานให้เอา Requirement เป็นตัวตั้งต้น แล้วค่อยมองว่าเทคโนโลยีอะไรที่สามารถตอบโจทย์ Requirement นั้นได้ อย่าเอาเทคโนโลยีมาเป็นตัวตั้งต้นแล้วค่อยมองกลับไปที่ Requirement เด็ดขาด
{% endhint %}
อันนี้เจอบ่อยม๊วกๆๆ โดยเฉพาะคนที่พึ่งมาทำงานโปรเจคใหม่ๆ เวลาที่ไปเรียนอะไรแปลกๆใหม่ๆมาเสร็จ ก็จะเอาความรู้ที่ได้มาเขียนในงานจริงเลยทันที เช่นเรียน Design Patterns มา แล้วเห็นว่าตรงนี้น่าจะใช้ Observer Pattern นะก็จัดเลยไรงี้
งานจริงมันลองเล่นไม่ได้ เพราะมันคือของใช้จริง มีลูกค้าจริง ทำเงินจริง จงอย่าทำเช่นนั้น เพราะวิชาใหม่ๆที่พึ่งได้มาส่วนใหญ่เราจะยังไม่ได้เข้าใจมันอย่างถ่องแท้ มันต้องใช้เวลาทำความเข้าใจซักพักก่อนถึงจะตรัสรู้ ซึ่งวิชาแต่ละวิชามันก็มี overhead ของมันด้วยนะ ไม่เชื่อลองตอบคำถามพวกนี้ดูสิ (ถ้าตอบได้หมดก็น่าจะโอเคในระดับนึงละ)
- คุณรู้ได้ยังไงว่าจุดนั้นควรจะใช้เทคนิคนั้นจริงๆ?
- คุณเข้าใจเทคนิคนั้นและทำมันถูกจริงๆหรือเปล่า?
- คุณชั่งข้อดีข้อเสียมันแล้วก่อนที่จะเอามาใช้หรือเปล่า?
{% hint style="danger" %}
ข้อเสียจากการใช้ของใหม่ๆที่พึ่งศึกษามากับงานจริง
งานจริงเล่นจริงเจ็บจริงไม่ใช่ที่ลองเล่น และอาจทำให้ performance ตกหรือทำให้ server down โดยใช่เหตุ แล้วจะโดน Team lead เรียกเข้าไปตบรางวัลได้
{% endhint %}
{% hint style="success" %}
ศึกษามันให้เข้าใจก่อนเอาไปใช้
ถ้าจะลองวิชาให้ลองเขียนลองเล่นในโปรเจคเล่นๆของเราก่อนก็ได้ หรือจะเป็นพวก PoC ก็ได้จะได้ไม่ทำให้ใครต้องถูกเรียกตัว และควรดูข้อดีข้อเสียก่อนใช้
{% endhint %}
ในหลายๆครั้งที่ลุกค้าบอกว่าอยากได้อะไร เราก็มันจะเขียนสิ่งนั้นให้ลูกค้าตรงตามตัวอักษรที่เขาพูดเลย แต่ในความเป็นจริง สิ่งที่ลูกค้าพูดอาจจะไม่ใช่ความต้องการที่แท้จริงก็ได้ แล้วเราก็จะทำของตรงที่เขาพูดออกมาแต่ไม่ใช่ของที่เขาอยากได้จริงๆ
สิ่งที่เราควรจะทำคือ ถามคำถาม ว่าทำไมเขาอยากได้แบบนั้น เพราะลูกค้าส่วนมากไม่ได้เข้าใจในเรื่องเทคโนโลยีมากนัก เขาแค่รู้ว่าเขามีปัญหาเรื่องนี้ เลยคิดว่าจะแก้ปัญหายังไงในรูปแบบของเขาเอง ซึ่งมันอาจจะแก้ปัญหาได้ไม่ตรงจุดก็เป็นได้ ซึ่งในขณะที่เราต่างหากที่เป็น technology specialist ที่จะต้องฟังปัญหาแล้วเลือกว่าจะใช้อะไรมาตอบโจทย์ของลูกค้า ไม่ใช่ให้ลูกค้ามาเลือก!! แล้วเราค่อยบอก solution ให้ลูกค้าลองเอาไปพิจารณาอีกทีต่างหาก
ลองคิดภาพตามนะ สมมุติว่าเราเป็นหมอแล้วมีคนไข้มาบอกว่าผมปวดท้องสงสัยมีแมลงในท้องผมรบกวนผ่าตัดเอาแมลงออกให้หน่อย มัน make sense แล้วเหรอ? #นักพัฒนาโปรแกรมก็เช่นกัน
{% hint style="danger" %}
ข้อเสียจากการทำตามที่ลูกค้าอยากได้เป๊ะๆ
งานที่ทำไม่ตรงกับ Business requirement และอาจะเสียลูกค้าก็ได้ เพราะเขาไม่ได้พอใจในงานที่เราทำตามที่ว่ามาเป๊ะๆ (ช่างสวนทางกันยิ่งนัก)
{% endhint %}
{% hint style="success" %}
ถามลูกค้าเพื่อหาสิ่งที่เขาอยากได้ที่แท้จริง (Root Cause)
ถ้าเราสามารถแก้ปัญหาที่แท้จริงให้กับลูกค้าได้ สิ่งที่เรียกว่า TRUST ก็จะเกิด ทำให้ลูกค้าอยากมาใช้บริการเราเรื่อยๆ และเราก็ไม่ต้องส่งงานที่เขาไม่อยากได้แต่เขาสั่งแบบนี้มาอีกด้วย
{% endhint %}
หลายๆครั้งที่ลูกค้าบอกว่าอยากให้เขียน Feature นี้ แล้วก็กำหนดวันส่งงานมาให้ เหล่า developer ผู้ซื้อสัตย์ก็จะฝากตัวรับใช้นายตรงตาม deadline นั้นเป๊ะๆ ทำงานหามรุ่งหามค่ำกันทีเดียว ซึ่งสิ่งที่ผมอยากจะบอกคือ จริงๆเราสามารถคุยต่อรองกับลูกค้าได้นะ!
การต่อรองเรื่อง deadline เราจะต้องบอกลูกค้าไปว่า ตัว feature นี้จริงๆต้องใช้เวลาทำนานขนาดไหน และจะเสร็จทันหรือเปล่า และถ้ามันไม่ทันจริงๆ เราจะต้องให้ลูกค้าตัดสินใจว่าจะลด scope งานลงมาได้ขนาดไหน หรืออะไรกันแน่ที่เป็นตัวสำคัญจริงๆที่เขาต้องได้ภายใน deadline นั้น เพื่อให้ลูกค้าไปจัดลำดับความสำคัญของงานเรามาใหม่ และเรากับลูกค้าก็จะเข้าใจกันตามหลักเหตุผลได้ง่ายขึ้น ไม่งั้นเราจะทำงานภายใต้ความกดดันอยู่ตลอดเวลา
{% hint style="danger" %}
ข้อเสียจากการไม่อธิบายกับลูกค้า
ทำงานภายใต้แรงกดดัน อาจไม่ได้นอน ไม่มีเวลากับครอบครัว บลาๆ ที่สำคัญคือ เรากับลูกค้าเข้าใจไม่ตรงกัน และอาจจะไม่ได้เข้าใจกันด้วยเหตุด้วยผล
{% endhint %}
{% hint style="info" %}
จงอย่าเชื่อเพราะมีแมวน้ำมาบอก แต่จงพิสูจน์
หลักพระธรรมนี้มีให้เราศึกษาอยู่นานแล้วในหลักของ Agile ลองไปศึกษาดูนะกับ Agile manifesto
หลักการทำ Agile เดี๋ยวผมจะคอร์สสอนเบื้องต้นอยู่รออ่านเอาได้ที่ side menu นะ
{% endhint %}
เวลาทำงานผมเลือกเน้นไปที่เรื่องต่างๆดังนี้
- เน้นการเขียน Clean Code แทนการเขียนโค้ดที่ดูเทพๆแต่แก้ไขต่อยอดยาก
- เทสต้องเขียนเสมอ ไม่งั้นอย่าพูดถึงว่าจะทำ Clean Code ยังไงเลย เพราะมันจะทำไม่ได้
- เวลาทำอะไรให้ชั่งน้ำหนักข้อดีข้อเสียก่อนทำเสมอ เพราะทุกอย่างมี overhead
- เน้นให้เข้าใจอย่างถ่องแท้เพียงภาษาเดียวก่อน แล้วค่อยต่อยอดไปที่ภาษาอื่น
- หัดใช้ command line ซะ
- ทีมเวิร์คสำคัญ เพราะงานของทีมไม่เสร็จก็คืองานทั้งหมดไม่เสร็จเช่นกัน
- เอา Requirement เป็นที่ตั้ง แล้วค่อยดูเลือกเทคโนโลยีที่จะใช้
- หัดพูดภาษามนุษย์ให้คนทั่วไปฟังรู้เรื่อง
- อย่าลองวิชาที่ตัวงานจริง
- ฟัง Requirement แล้วหัดถามจะได้รู้ว่าจริงๆเขาอยากได้อะไร
- Deadline ของลูกค้า สามารถพูดคุยด้วยเหตุผลได้เสมอ
ซึ่งคอร์สที่เกี่ยวข้องกับเรื่องนี้ทั้งหมดไปศึกษาต่อได้จากลิงค์ด้านล่าง
{% page-ref page="clean-code/" %}
{% page-ref page="code-smells.md" %}
{% page-ref page="../software-design/designpatterns/" %}
{% page-ref page="solid/" %}