# สิ่งที่คนเขียนโค้ดมักเข้าใจผิด

## 😢 ปัญหา

เราทุกคนมีความเชื่อบางอย่างตั้งแต่เริ่มหัดโค้ดกันทุกคนอยู่แล้ว แล้วพอเขียนโค้ดมาได้เรื่อยๆ อ่านบทความ อ่านโค้ดคนอื่นมาเรื่อยๆ เราก็จะมีมุมมองที่ตกผลึกกลายมาเป็น **ความเชื่อของเรา** กันอยู่ทุกคน แต่ในหลายๆครั้งเวลาที่เราไปทำงานกลับพบว่า โดนเขาดุบ้าง โดนปฏิเสธงานกลับมาบ้าง บลาๆ เชื่อไหมว่าในหลายๆครั้งมันก็**เกี่ยวกับความเชื่อที่ฝั่งอยู่ในหัว**เราก็ได้ ดังนั้นในรอบนี้ผมจะขอแชร์มุมมองที่ผมเจอข้อผิดพลาดทั้งของตัวเองและของคนอื่นๆให้ฟังกันบ้างนะ

## 😄 วิธีแก้ปัญหา

**รับฟังความคิดเห็นคนอื่นบ้าง**แล้วเอาไปวิเคราะห์ว่าเราควรจะปรับไหม? และปรับยังไง? โดยสิ่งแรกที่เราควรจะทำคือการ **เปิดใจฟัง** เสียงอื่นนอกจากเสียงของตัวเองบ้าง และที่สำคัญไม่แพ้กันเลยคือเรียนรู้ความผิดพลาดของคนอื่น ตามหัวข้อด้านล่างนี้

{% hint style="warning" %}
ไม่ได้ตั้งใจให้บทความนี้ยาวขนาดนี้เลย แต่มันก็เป็นเรื่องจริงที่อยากจะแชร์ว่าส่วนใหญ่เราจะเจอคนที่มี mindset พวกนี้บ่อยมากในวงการ ดังนั้นเลือกๆอ่านหัวข้อที่สนใจเอาละกันเน่อ
{% endhint %}

## 🥴 โค้ดยิ่งสั้นยิ่งดี ยิ่งสั้นยิ่งเทพ ยิ่งสั้นยิ่งเร็ว!!

**ส่วนใหญ่ 99% ไม่จริงครับ** การที่แข่งกันสั้นไม่ได้หมายความว่ามันจะทำงานได้เร็วหรือดีเสมอไป เพราะจำนวนบรรทัดไม่สามารถนำไปวัด performance ได้จริงๆนั่นเอง มันขึ้นอยู่กับ **BigO** ของ function ที่เราเรียกใช้จริงๆต่างหาก

ยกตัวอย่างให้เข้าใจมากขึ้น ผมจะลองเขียนโค้ด C# สร้าง array ตัวเลข 1\~100 โดยใช้โค้ด 2 แบบเทียบกันดู

**แบบที่ 1**

```csharp
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 ได้จากลิงค์นี้ [จิ้มตรงนี้ด้วยความอ่อนโยนเลย](https://saladpuk.gitbook.io/learn/basic/clean-code))
{% endhint %}

{% hint style="info" %}
**จงอย่าเชื่อเพราะมีแมวน้ำมาบอก แต่จงพิสูจน์**\
สามารถเข้าไปดูการทำงานจริงๆของ Enumerable.Range() ได้ที่ลิงค์ด้านล่างนี้ครับ บรรทัดที่ 1,265\~1,273 คือการทำงานที่แท้จริงของ method นี้ซึ่งทาง Microsoft ได้เปิดแชร์ source code ให้ทั่วโลกเห็น อยู่บน GitHub แล้วนะครับ\
[Microsoft GitHub .NET Core Enumerable](https://github.com/microsoft/referencesource/blob/master/System.Core/System/Linq/Enumerable.cs)
{% endhint %}

## 🥴 เขียนโค้ดยากๆ Algorithms จ๋าๆ คนอื่นไม่รู้เรื่องเลยเท่ห์บาดใจ

อย่ามาให้ผมเจอเชียว จะหอมแก้มซักฟอดใหญ่ๆ 🤞 ซึ่งเชื่อไหมว่า developer หลายๆคนชอบทำกัน (แต่ก่อนผมก็ชอบฮ่าๆ) แต่เชื่อไหมว่าคนที่เขียนโค้ดระดับปรมาจารย์ในวงการทุกคน เวลาเขาเขียนโค้ดทีไร มันจะออกมาแบบพื้นมากๆ ไม่ใช่เขียนกากๆนะ แต่โค้ดไม่ได้สลับซับซ้อนใดๆเลย อ่านแล้วเข้าใจได้ง่ายด้วย และสิ่งที่มหาเทพพวกนี้สอนพวกเราตลอดเวลาคือ **Keep it simple ทำให้มันง่าย** นั่นเอง

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

![สปาเก็ตตี้โค้ด พันกันยุ่งไปหมด](/files/-Lp1_4I7PWGliUKz_RPW)

เผื่อสนใจไปลองอ่านสปาเก็ตตี้โค้ดเล่นได้นะครับ [Amazon book - $4.99 USD](https://www.amazon.com/Spaghetti-Code-Detangling-Programmer-Wisdom-ebook/dp/B078QR56ZH/ref=sr_1_1?keywords=Spaghetti+Code%3A+Detangling+Life+and\&qid=1567122288\&s=gateway\&sr=8-1) แต่ถ้าไม่อยากซื้อก็ไปอ่าน Clean Code ได้ฟรีที่นี่ 😛

{% content-ref url="/pages/-Ln6-ot5tSQI\_QxfDv7e" %}
[Clean Code](/basic/clean-code.md)
{% endcontent-ref %}

{% hint style="danger" %}
**ผลเสียจากการเขียนยากๆ**\
เหมือนเขียนโค้ดสั้นๆเลย และเพิ่มเติมคือจะทำ**ให้ระบบซับซ้อนโดยไร้สาระอีกต่างหาก**
{% endhint %}

{% hint style="success" %}
**จงเขียนโค้ดให้ Clean**\
เหมือนเดิมเลย เขียนให้คลีนซะจะเป็นอภิมหาบุญของตัวเราและคนในทีม ต่อไปนี้ผมจะไม่เขียนว่า **จงเขียนโค้ดให้ Clean** แล้วนะ เพราะทุกประเด็นชี้กลับมาที่เรื่องนี้หมดทุกตัวเลย
{% endhint %}

{% hint style="info" %}
**จงอย่าเชื่อเพราะมีแมวน้ำมาบอก แต่จงพิสูจน์**\
หลักในการออกแบบโค้ดมีตัวนึงที่ชื่อว่า **KISS (keep it simple, stupid)** คือทำทุกอย่างให้ง่ายเข้าไว้ ซึ่งไม่ใช่แบบมักง่ายนะ แต่ต้องถูกลั่นมาแล้วทำให้ง่ายต่อการใช้งาน ซึ่งสามารถศึกษาต่อได้จากลิงค์นี้ครับ [Wikipedia - KISS](https://en.wikipedia.org/wiki/KISS_principle)
{% endhint %}

## 🥴 โค้ดไปก๊อปๆมาก็ได้

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

ในความเป็นจริงการเขียนโค้ดมีหลายระดับ ซึ่งถ้างานที่เราได้รับมันเป็นแค่ตัวอย่าง (PoC) ก็อาจจะปล่อยโค้ดไว้แบบนั้นก็ได้ แต่สำหรับงานที่เขียนจริงใช้จริงมีลูกค้าจริง หรือที่เราเรียกว่างาน **Production** นั้น เราไม่สามารถทำแบบนั้นได้ครับ (สำหรับบริษัทที่ให้ความสำคัญกับตัวงานจริงๆ เขาจะไม่ปล่อยให้มีของแบบนี้หลุดออกมา) เพราะ**โค้ดที่ทำงานได้มันไม่ได้หมายความว่ามันเป็น Production Code เสมอไป** และโค้ดที่เราก๊อปมามันอาจจะแค่ทำงานได้แต่มันอาจจะทำให้ประสิทธิภาพในการทำงานตกลงจนทำให้ Server down โดยไม่รู้สาเหตุก็เป็นได้นะ

![รูปจาก wikipedia.org/wiki/Copy-and-paste\_programming](/files/-LnUhkmoe8SxT6s_A-ek)

สุดท้ายโค้ดที่ก๊อปๆมา ในหลายๆทีเราก็ไม่ได้ทำ **Refactor** ด้วย ก็ยิ่งทำให้กลายเป็น **Bad Code** ส่งกลิ่นเหม็นคลุ้งไปหมดด้วย อ่านบทความเรื่อง **Code Smells** ได้จากลิงค์นี้

{% content-ref url="/pages/-Ln1xlroLGxlvmu4uoJT" %}
[Code Smells](/basic/code-smells.md)
{% endcontent-ref %}

{% hint style="danger" %}
**ผลเสียจากการก๊อปโค้ดมาใช้**\
โค้ดไม่ Clean, โค้ดไม่เหมาะกับลักษณะการทำงาน ซึ่งส่งผลให้ performance ตกลงอย่างที่ไม่ควรเป็น และทำให้คนอื่นๆในทีมเลียนแบบพฤติกรรม และที่สำคัญที่สุดคือ โค้ดที่ไปก๊อปมาอาจจะ**ทำให้ระบบซับซ้อนมากขึ้น**โดยไม่สมควรอีกด้วย

### **โค้ดที่ทำงานได้  != Production Code**

{% endhint %}

{% hint style="success" %}
**ศึกษาปัญหาให้เข้าใจแล้วแก้ให้ถูกจุด**\
การไปดูจากเน็ทไม่ใช่เรื่องที่ผิด แต่การแก้ปัญหาจริงๆคือ เราต้อง**หาต้นเหตุของปัญหาที่แท้จริงว่ามันคืออะไรแล้วค่อยหาทางแก้ด้วยวิธีการที่เหมาะสม** ไม่ใช่ก๊อปมาวางแล้วใช้งานได้ก็ปล่อยจบ และอย่าลืมทำ **Refactor** ด้วยเพื่อทำคลีนโค้ดด้วย
{% endhint %}

## 🥴 ไม่ต้องเขียนเทสก็ได้

อันนี้เป็นบ่อยสำหรับ developer ที่รู้จักเทสใหม่ๆ หรือ ไม่ได้คลุกคลีกับการเขียน test case สักเท่าไหร่ จะรู้สึกว่าการเขียน test case เป็นอะไรที่ยุ่งยากเสียเวลา ทำไมไม่เอาเวลาไปเขียนโค้ดเลย!

ซึ่งในความเป็นจริง**การเขียนเทสก่อนในระยะยาวจะทำให้ความเร็วในการเขียนโค้ดสูงขึ้นแบบเห็นได้ชัดเมื่อเทียบกับการไม่เขียนเทส** เพราะเราไม่ต้องกลับมานั่งแก้ bug และเวลาที่เราเพิ่มความสามารถใหม่ๆให้กับโปรแกรมก็จะสามารถทำได้ทันที ไม่ใช่เขียน 1 จุด bug ผุดขึ้นมา 10 จุด นอกจากนี้การเขียนเทสเคสยังจะช่วยให้เราเข้าใจในสิ่งที่ลูกค้าต้องการได้อย่างถูกต้อง และข้อดีที่สุดในการเขียนเทสก่อนคือ **โค้ดจะมีดีไซน์ที่ดีและสามารถทำ refactor เมื่อไหร่ก็ได้**

![หัวใจในการทำ TDD คือ Red - Green - Refactor](/files/-Lo43_Y0E6QEF9TBm3Dc)

ไปศึกษาการเขียนเทสได้จากคอร์สนี้เลย

{% content-ref url="/pages/-LmTBsJjoq1GWMJb8oCt" %}
[Test-Driven Development](/software-testing/tdd101.md)
{% endcontent-ref %}

{% hint style="danger" %}
**ผลเสียจากการไม่เขียนเทส**\
โค้ดมี bugs เยอะ, เพิ่มความสามารถใหม่ๆลงไปยาก, แก้ 1 จุดพัง 10 จุด, ทำในสิ่งที่ลูกค้าไม่อยากได้, ทีมเข้าใจไม่ตรงกัน โดยรวมๆมันส่งผลเสียทั้งต่อเราเองและต่อทีมสูงมาก และในระยะยาวจะทำให้**เขียนแอพได้ช้าลงไปเรื่อยๆในขณะที่แอพมันโตขึ้น** ดังนั้น

### **ไม่เขียนเทส = บาป**

{% endhint %}

## 🥴 ต้องเขียนเป็นทุกๆภาษา

เรื่องนี้ผมขอตอบแบบนี้ละกันว่า **ถ้าคุณยังไม่รู้ลึกจริงๆซัก 1 ภาษาก็ยังไม่จำเป็นต้องไปเรียนภาษาอื่นหรอก** เพราะ**ทุกๆภาษามันมีแก่นแท้เหมือนๆกัน** ถ้าคุณตัสรู้เข้าใจมันจริงๆเพียงแค่ภาษาเดียว คุณก็จะสามารถเปลี่ยนไปเขียนอีกภาษาได้ภายในเวลาไม่นาน

จงเรียนให้เข้าใจแก่นแท้ซัก 1 ภาษาก่อนเอาที่ตัวเองถนัดหรือไม่ก็ที่มีคนแนะนำเราได้จริงๆจะเหมาะกว่า อย่าไปคิดว่าภาษานี้เท่กว่าภาษานี้ ภาษานี้ใหม่กว่าดีกว่า จับซัก 1 ตัวแล้วเหยียดขารู้มันให้สุดๆไปซะ!!

**พูดให้เห็นภาพ** สมมุติว่าตอนนี้แค่พูดภาษาไทยคุณยังงูๆปลาๆพูดผิดๆถูกๆอยู่เลย ก็อย่าพึ่งไปเรียนภาษาจีนดิ!! เอาภาษาไทยให้รอดก๊อนนนน!!! เพราะภาษาส่วนใหญ่บนโลกมันก็มีแก่นแท้โครงสร้างคล้ายๆกันนั่นแหละ ประธาน-กิริยา-กรรม *ส่วนพี่ญี่ปุ่นหรืออื่นๆเป็นเคสพิเศษช่างมันก่อน*

{% hint style="success" %}
**แก่นแท้ของภาษาโปรแกรมส่วนใหญ่เหมือนกัน** ดังนั้นศึกษาจนเข้าใจอย่างลึกซึ้งซักตัวก่อนแล้วที่เหลือจะเปลี่ยนภาษาเมื่อไหร่ก็ไม่ถึงเดือน
{% endhint %}

## 🥴 Command line เป็นเรื่องของคนแก่ นี่มันยุกต์ไหนกันแร๊วว\~\*

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 นะรักเบย 😍

![](/files/-Lsf8aQrQb_4IAWsmJmC)

{% 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 ของมันด้วยนะ ไม่เชื่อลองตอบคำถามพวกนี้ดูสิ (ถ้าตอบได้หมดก็น่าจะโอเคในระดับนึงละ)

* คุณรู้ได้ยังไงว่าจุดนั้นควรจะใช้เทคนิคนั้นจริงๆ?
* คุณเข้าใจเทคนิคนั้นและทำมันถูกจริงๆหรือเปล่า?
* คุณชั่งข้อดีข้อเสียมันแล้วก่อนที่จะเอามาใช้หรือเปล่า?

![ชั่งน้ำหนักก่อนใช้เทคนิกต่างๆเสมอ](/files/-LtpRv0kYlwQoL3pvASg)

{% 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 %}

## 🥴 ลูกค้าจะเอาวันไหน วันนั้นคือ deadline

หลายๆครั้งที่ลูกค้าบอกว่าอยากให้เขียน Feature นี้ แล้วก็กำหนดวันส่งงานมาให้ เหล่า developer ผู้ซื้อสัตย์ก็จะฝากตัวรับใช้นายตรงตาม deadline นั้นเป๊ะๆ ทำงานหามรุ่งหามค่ำกันทีเดียว ซึ่งสิ่งที่ผมอยากจะบอกคือ จริงๆเรา**สามารถคุยต่อรองกับลูกค้าได้นะ!**

การต่อรองเรื่อง deadline เราจะต้องบอกลูกค้าไปว่า ตัว feature นี้จริงๆต้องใช้เวลาทำนานขนาดไหน และจะเสร็จทันหรือเปล่า และถ้ามันไม่ทันจริงๆ เราจะต้องให้ลูกค้าตัดสินใจว่าจะลด scope งานลงมาได้ขนาดไหน หรืออะไรกันแน่ที่เป็นตัวสำคัญจริงๆที่เขาต้องได้ภายใน deadline นั้น เพื่อให้ลูกค้าไปจัดลำดับความสำคัญของงานเรามาใหม่ และเรากับลูกค้าก็จะเข้าใจกันตามหลักเหตุผลได้ง่ายขึ้น ไม่งั้นเราจะทำงานภายใต้ความกดดันอยู่ตลอดเวลา

{% hint style="danger" %}
**ข้อเสียจากการไม่อธิบายกับลูกค้า**\
ทำงานภายใต้แรงกดดัน อาจไม่ได้นอน ไม่มีเวลากับครอบครัว บลาๆ ที่สำคัญคือ เรากับลูกค้าเข้าใจไม่ตรงกัน และอาจจะไม่ได้เข้าใจกันด้วยเหตุด้วยผล
{% endhint %}

{% hint style="info" %}
**จงอย่าเชื่อเพราะมีแมวน้ำมาบอก แต่จงพิสูจน์**\
หลักพระธรรมนี้มีให้เราศึกษาอยู่นานแล้วในหลักของ Agile ลองไปศึกษาดูนะกับ [Agile manifesto](https://agilemanifesto.org)\
หลักการทำ Agile เดี๋ยวผมจะคอร์สสอนเบื้องต้นอยู่รออ่านเอาได้ที่ side menu นะ
{% endhint %}

## 🎯 บทสรุป

เวลาทำงานผมเลือกเน้นไปที่เรื่องต่างๆดังนี้

* เน้นการเขียน Clean Code แทนการเขียนโค้ดที่ดูเทพๆแต่แก้ไขต่อยอดยาก
* เทสต้องเขียนเสมอ ไม่งั้นอย่าพูดถึงว่าจะทำ Clean Code ยังไงเลย เพราะมันจะทำไม่ได้
* เวลาทำอะไรให้ชั่งน้ำหนักข้อดีข้อเสียก่อนทำเสมอ เพราะทุกอย่างมี overhead
* เน้นให้เข้าใจอย่างถ่องแท้เพียงภาษาเดียวก่อน แล้วค่อยต่อยอดไปที่ภาษาอื่น
* หัดใช้ command line ซะ
* ทีมเวิร์คสำคัญ เพราะงานของทีมไม่เสร็จก็คืองานทั้งหมดไม่เสร็จเช่นกัน
* เอา Requirement เป็นที่ตั้ง แล้วค่อยดูเลือกเทคโนโลยีที่จะใช้
* หัดพูดภาษามนุษย์ให้คนทั่วไปฟังรู้เรื่อง
* อย่าลองวิชาที่ตัวงานจริง
* ฟัง Requirement แล้วหัดถามจะได้รู้ว่าจริงๆเขาอยากได้อะไร
* Deadline ของลูกค้า สามารถพูดคุยด้วยเหตุผลได้เสมอ

ซึ่งคอร์สที่เกี่ยวข้องกับเรื่องนี้ทั้งหมดไปศึกษาต่อได้จากลิงค์ด้านล่าง

{% content-ref url="/pages/-Ln6-ot5tSQI\_QxfDv7e" %}
[Clean Code](/basic/clean-code.md)
{% endcontent-ref %}

{% content-ref url="/pages/-Ln1xlroLGxlvmu4uoJT" %}
[Code Smells](/basic/code-smells.md)
{% endcontent-ref %}

{% content-ref url="/pages/-LmQMABDZJvFe25M6sbA" %}
[Design Patterns](/software-design/designpatterns.md)
{% endcontent-ref %}

{% content-ref url="/pages/-LmXswgLXrRV0ZatXkxU" %}
[SOLID Design Principles](/basic/solid.md)
{% endcontent-ref %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.saladpuk.com/basic/mist.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.