Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
มาทำความเข้าใจกันหน่อยนุงน๊า
เรื่องเกร็ดความรู้ในการทำซอฟต์แวร์ทั้งหมด ดช.แมวน้ำ จะเอามาเขียนไว้ในโซนนี้ทั้งหมด ซึ่งคิดเรื่องอะไรก็ได้จะเอามาพล่ามในโซนนี้เรื่อยๆฮั๊ฟ
บทความเก่าหายไปไหน ? ไม่ได้หายไปไหนหรอก ที่เมนูด้านบนซ้ายสุดให้กดไปที่เมนู 🏆 เนื้อหาหลัก ก็จะเป็นการกลับไปที่โซนเนื้อหาทั้งหมดที่เคยเห็นเช่นเดิมขอรับ
อย่าใจร้อนรีบไปเดี๋ยวมันไม่เข้าที ~*` พักสักที...เดี๋ยวค่อยไป
พอดีถูกใจไอ้รูปด้านล่างเลยอยากแชร์ และ จะแปลแบบนี้มีไรมิ ?
ป๊อปคอร์นทุกเม็ดมันก็ถูกเตรียมไว้ในหม้อเดียวกัน โดนความร้อนเท่ากัน และอะไรก็ได้พอๆกัน แต่ว่า ... มันใช้เวลาในการแตกจากเมล็ดข้าวโพดเป็นป๊อปคอร์นต่างเวลากัน ดังนั้นอย่าเปรียบเทียบว่าทำไมเราไม่ได้เหมือนเขา ไม่เก่งเหมือนเขา เรียนมาตั้งนานแล้วยังทำไม่ได้เลย . . . เพราะคนทุกคนมีความต่างกัน มีจุดที่จะเข้าใจไม่เหมือนกัน บางคนช้า บางคนเร็ว ดังนั้นแต่ละคนมีลู่วิ่งของตัวเอง และมีหนทางในการประสบความสำเร็จในรูปแบบที่แตกต่างกัน จงหาหนทางของตัวเองและจงพยายามต่อไป สักวันมันก็จะถึงเวลาของเราที่จะกลายเป็นป๊อปคอร์นเองแหละ (นี่พึ่งรู้ว่าเราเกิดมาเป็นป๊อปคอร์นนะเนี่ย) 🍿
แมวน้ำไม่ได้เขียนโค้ดแล้วเทพในวันแรกหรอก แต่เรียนรู้ไปเรื่อยๆเดี๋ยวมันก็เป็น Master เอง (ถึงตอนนี้จะเป็นแค่แมวน้ำอยู่เหมือนเดิมก็ตาม)
กว่าจะถึงฝั่งฝันนั้นมันยากเย็น ... อย่าพึ่งเห็นฉันเดินเข้ามาง่ายง่าย ... กว่าจะถึงที่ฉันยืน ... กล้ำกลืนฝืนทนเกือบตาย การโค้ดดิ้ง จะท้อไม่ใช่เรื่องแปลก
ท้อได้แต่อย่ายอมแพ้ แมวน้ำเป็นกำลังใจให้เสมอ งง เรื่องอะไรก็ทักมา จะถามปัญหาเรื่องงานที่ติดก็ถามโลด แต่ถ้ามีปัญหาเรื่องเงินแล้วพบทางแก้ฝากกระซิบบอกแมวน้ำด้วย 💰
ช่วงนี้แมวน้ำต้องทำกิจกรรมว่ายน้ำต้านโควิทแถวๆอลาสก้า เลยทำให้บทความเสาร์อาทิตย์นี้ถูดงกไปก่อนนะขอรับ แต่เดี๋ยวจะมาโพสต์มุกตลกของเหล่าโปรแกรมเมอร์แทนละกัน ... ส่วนสำหรับใครจะไปสวดมนต์ต้านโควิท แมวน้ำแนะนำว่าถ้าเป็นไปได้ก็สวดที่บ้านแทนจะช่วยกว่าการไปรวมตัวกันสวดมนต์นะขอรับ ด้วยความเป็นห่วง 😘
โดนดราม่าเพราะรูปนี้จนได้ และเริ่มขี้เกียจตอบคำถามเดิมๆซ้ำหลายๆครั้ง เลยจะขอเขียนไว้ตรงนี้เลยละกันว่า
จริงๆภาษา php มันก็โดนแซะไม่ต่างจากภาษาอื่นๆ เช่นภาษา javascript เท่าไหร่หรอก และภาษา PHP ไม่ได้เลวร้ายขนาดนั้นนะ แต่ที่มันกลายเป็นมุกแบบนั้น เราต้องเข้าใจพื้นหลังของเขาก่อนดีกว่า
PHP ก็สามารถเขียน backend ได้นะ และส่วนใหญ่งานที่ลูกค้าจ้าง 80-90% ก็เป็นเว็บง่ายๆไม่ได้วุ่นวายอะไร แต่สำหรับงาน backend จ๋าๆ แล้วให้ใช้ PHP ทำ มันจะเหมือนตกนรกทั้งเป็นเลย ยกตัวอย่างง่ายๆ เช่น การประมวลผลธรรมดานี่แหละ แต่มีผู้ใช้ request มาเป็นล้านๆครั้งต่อนาที ปัญหาที่จะเกิดขึ้นคือ ภาษา PHP มันเป็น interpreter ซึ่งหมายความว่า "มันจะหน่วง" ดังนั้นมันจะมีปัญหาเรื่อง perfomance และ ด้วยความที่เขาเป็น server side script เพียงอย่างเดียว นั่นหมายความว่า ทุกอย่างเซิฟเวอร์ต้องประมวลผลทั้งหมด ไม่มีการลดภาระของเซิฟเวอร์เลย
Facebook ยังใช้ PHP เลย!! ใช่ครับแต่เพราะ php นี่แหละ เลยเกือบทำให้ facebook ตายมาแล้ว และตอนนี้เขาโล๊ะทิ้งแล้วนะ ไม่มี php ในฝั่ง facebook backend เหลือแล้ว (ไปอ่านตามข่าวเองละกัน) แต่ที่ยังเห็น facebook รับพนักงานที่เขียน php อยู่ ก็เพราะโปรแกรมเมอร์ที่เขียน php หาง่าย แล้ว facebook ก็เอาคนเหล่านั้นไปเขียน php ซึ่งทาง facebook มีโปรแกรมแปลง php ให้กลายเป็น ภาษา c++ เพื่อเอาไปใช้ใน backend ของเขาต่อนั่นเอง
ภาษา PHP เป็นหนึ่งในภาษาที่อยากเขียนอะไรลงไปก็ได้ บรรทัดนี้ตัวแปร money อาจมีค่าเป็นตัวเลข บรรทัดถัดไปกลายเป็นตัวอักษร บรรทัดที่สามกลายเป็น object หรือเอา boolean ไปเขียน if แล้วได้ค่า 1 ไรงี้ และรวมถึงอยากจะเขียนอะไรตรงไหนก็เขียนได้หมดเลย อยากแทรกก็แทรกลงไปได้ดื้อๆ เลยทำให้หลายๆคนหลงรัก PHP เพราะมันง่ายม๊วกๆ แต่ก็เช่นเคย ด้วยความง่ายนั่นแหละมันจะทำลายนิสัยในการเขียนโปรแกรมที่ดี และต้องมีการควบคุมที่มากขึ้น ถึงจะให้ทุกคนในทีมทำงานร่วมกันได้ ซึ่งถ้าใครเคยศึกษาเรื่องการทำ Clean Code & Clean Architect จะเข้าใจปัญหาที่มากับความง่ายของภาษาลักษณะนี้ (บอกแล้วไม่ได้มีแค่ php ที่มีปัญหานี้นะ)
ว่าเขาไปตั้งเยอะละ มาปิดฉากสวยๆกับ php บ้างดีกว่า
ถามกับแมวน้ำได้ แต่ไม่มีกะตังให้หรอก ทุกวันนี้ก็กินแกลบอยู่ 😭
เทรนโลกสมัยนี้อัพเดทกันจนแทบจะเรียกว่า กระพริบตาก็ตามแทบไม่ทันแล้ว เมื่อวานพึ่งหัดเขียน JavaScript วันรุ่งขึ้นบอกให้ไปใช้ TypeScript แทนดีกว่า ไหนศึกษาไปได้ซักพักมีเวอร์ชั่นไหมออก แถมจะไปสมัครคอร์สเรียนแต่ละทีก็เสียเงินกันมิใช่น้อย เลยมาแอบอ่าน saladpuk.com แทนเพราะมีแมวน้ำมาแจกความรู้ฟรี (ฮาๆ)
ในรอบนี้ผมเลยจะเอา คอร์สเรียนออนไลน์ฟรี มาแจก แต่มันไม่เหมือนกับคอร์สเรียนทั่วๆไปนะ เพราะมันถูกส่งตรงมาจาก ผู้หลิตโดยตรงเลย ซึ่งข้อดีของมันคือ เราจะได้ความรู้ที่มีการแนะนำ Best Practices & Principles ในการใช้งาน อัดอยู่ในวีดีโอให้เราเรียนเรียบร้อยเลย ดังนั้นไปดูกันเรยว่ามันมีคอร์สเรียนอะไรบ้าง
👍 https://docs.microsoft.com/en-us/learn/azure
แหล่งความรู้ส่งตรงจาก Microsoft ซึ่งสิ่งที่เขาสอนมีตั้งแต่ไม้จิ้มฟันยันเรือรบกันเลยทีเดียว แค่เข้าไปดูในรายการที่เขามีบอกได้เลยว่า วันหยุดยาวทั้งปีนี้ก็ไม่น่าจะดูได้จนจบ ลาก่อนลูกแก้วเมียขวัญ และ ฝาละมีอันเป็นที่ยักษ์ 😂
ส่วนถ้าใครสนใจอยากเรียนรู้เฉพาะหน้างานของตัวเอง ก็สามารถเลือกเฉพาะคอร์สเฉพาะทางออกมาก็ได้ หรือจะเป็นเอาเฉพาะ product ที่ตัวเองต้องดูแล อีกทั้งยังเลือกระดับความยากงานได้ด้วย เช่น มือใหม่ไรงี้
👍 https://www.pluralsight.com/partners/microsoft/azure
เว็บเรียนออนไลน์สุดแจ่มที่แมวน้ำฝังตัวกับมันมานานก็ตัวนี้เลย โดยเราสามารถเข้ามาดูดความรู้จากเขาได้เลย (เฉพาะเรื่องที่เปิดฟรีนะ) โดยเราสามารถเลือกเรียนได้ตามลิสต์นี้เบย
👍 https://my.visualstudio.com/benefits
สำหรับคนที่มี Microsoft Account และถ้ายิ่งเคยใช้งาน Azure อยู่แล้ว หรือถ้ายังไม่เคยใช้ก็แนะนำให้ไปสมัครซะไม่เสียกะตังเลย ซึ่งทาง Microsoft แจกสิทธิประโยชน์ให้กับ Developer เต็มไปหมดเลย ตามรายการด้านล่าง
แนะนำให้อ่าน อยากสมัครใช้งานแต่ไม่รู้จะเริ่มต้นยังไง อ่านได้จากลิงค์นี้เบยครัช สมัคร Microsoft Azure
คือสิทธิประโยชน์ที่ให้มาเยอะม๊วกกก แถมยังมีเจ้า Pluralsight ให้ดูฟรี 1 เดือนเต็มๆอีกด้วย หรือใครสนใจ DataCamp อยากศึกษาเรื่อง AI ก็กระโดดเข้าไปเรียนได้เลย ใครไม่เอารบกวนบอกผมด้วยนะอยากดั๊ยยยยยย
สมัยนี้ความรู้มันกระโดดเข้ามาจนเกือบจะถีบยอดหน้าอยู่แล้ว อย่าไปกลัวว่าเราจะทำได้หรือเปล่า? มันจะยากไหม? หัดกระโดดลงน้ำแล้วว่ายมันให้เป็นซะเดี๋ยวนั้นเลยคือการพิสูจน์ว่า มันเหมาะกับเราหรือเปล่า? เราทำไม่ได้จริงๆหรือเปล่า? และต่อให้ทำไม่ได้ ก็ไม่ได้หมายว่าเราจะไปสายงานนี้ไม่ได้ซักหน่อย สายงานนี้มีแตกแขนงออกยั๊วเยี๊ยไปหมด ไม่ได้ต้องเขียนโค้ดเป็น ไม่ได้ต้องเก่งคณิตศาสตร์ ก็มีทางไปของมันอยู่เสมอแหละ ทุกอย่างมันขึ้นอยู่กับก้าวแรกของเราเสมอ (บร๊ะวันนี้สงสัยหยิบกาวมาใช้ผิดวิธีอีกแล้วซะนะ)
ของหลายๆอย่างที่เราคิดว่ามันดีนั้น มันอาจจะไม่จริงเสมอไปก็ได้นะ เช่น เราเชื่อกันว่า ถ้าเราสร้าง AI ที่ฉลาดๆ เทพๆ ล้ำๆ ออกมาได้ มันก็น่าจะเป็นที่นิยมชิมิ? แต่เชื่อไหมว่าหนึ่งใน "หลักการออกแบบ AI" (Principles of AI design) เขาบอกว่า "อย่าไปทำแบบนั้น" ... ทำไมนะเหรอ? ขอยกตัวอย่างนี้ให้ฟังละกัน
สมมุติว่าเราสร้าง AI โคตรเทพ ฉลาดฝุดๆ โต้ตอบหลายภาษา สั่งการด้วยเสียงได้ด้วย นั่นคือ "โถส้วมอัจฉริยะ" แต่ถามหน่อยว่า ปรกติเราจะคุยอะไรกับโถส้วมเหรอ? มันจะช่วยแก้ปัญหาอะไรเราเหรอ? และ ตลกร้ายคือ ถ้ากลุ่มลูกค้าที่เป็นผู้พิการทางหูมาใช้ มันจะต่างอะไรกับโถส้วมธรรมดาหรือเปล่า?
เพราะหลักในการออกแบบจริงๆแล้วเข้าเน้นไปที่เรื่อง "แก้ปัญหาได้จริง ง่ายและเร็ว" หรือพูดง่ายๆคือ คนใช้ไม่ต้องทำด๋อยอะไรเลยปัญหาก็ถูกแก้ไขไปแล้ว ... (ยังไม่ทันถอดกางเกงนั่งส้วมเลย เจ้าโถส้วมอัจฉริยะก็ทำให้คุณไม่ต้องขี้แล้ว) นี่คือสุดยอดแห่งการแก้ปัญหา ... และอย่าลืมว่า ผู้ใช้เขาไม่สนใจหรอกว่าคุณจะสร้างมันมาจากอะไร ใช้ Back-end ที่มี security ดีเท่าไหร่? Architecture เป็นยังไง? (ผู้ใช้ 90% น่าจะไม่เคยสงสัยเรื่องเหล่านี้กับแอพธนาคารเลย แม้ว่ามันจะมีเรื่องสนุกๆให้ดูทุกๆสิ้นเดือนก็ตาม)
ซึ่งทั้งหมดที่โม้มาจะขาดสิ่งสุดท้ายไม่ได้เลยนั่นก็คือ "มุมมอง" เพราะของสิ่งเดียวกัน แต่ถ้า ผู้ใช้งานต่างกลุ่มกัน มันอาจจะไม่ได้แก้ปัญหาเขาเขาได้โดยตรงก็ได้ เช่น ฝ่ายบัญชีบอกว่าแบบนี้ดีที่สุด มันอาจจะไม่จริงในมุมของฝ่ายการตลาดก็ได้นะจ๊ะ
ในแต่ละบริษัทนั้นมีตำแหน่งอำนาจที่แตกต่างกัน ซึ่งแต่ละที่จะใช้อะไรเป็นตัวกำหนดตำแหน่งนั้นไม่ใช่เรื่องที่แมวน้ำตัวนี้จะไปวุ่นวายด้วย แต่สิ่งที่แมวน้ำเห็นว่ามันควรจะเป็นคือ
💖การทำงานเป็นทีมนั้นควรจะใช้เหตุผลมาก่อนตำแหน่งงานเสมอ (เพราะผมเชื่อว่าทุกคนในทีมย่อมอยากให้งานออกมาดีที่สุดนั่นเอง)
แต่หลายครั้งที่เราจะเห็นของแปลกๆโผล่เข้ามาในโปรเจคเราเสมอ ซึ่งถ้าเราไปเค้นเอาความจริงว่าทำไมเขาถึงทำแบบนั้น ซึ่งเชื่อไหมว่า ส่วนใหญ่จะทำไปเพราะความหวังดีอยากให้งานเสร็จ โดยที่เจ้าตัวที่ใส่ของแปลกๆเข้าไป บางทีก็ไม่รู้ด้วยซ้ำว่ามันไม่ควรทำแบบนั้น หรือคิดหาวิธีแก้ปัญหาแบบอื่นไม่ได้นั่นเอง
ดังนั้นวิธีการแก้ปัญหาเรื่องพวกนี้จริงๆก็คือ "การสร้างทีมให้มี Mindset เปิดใจรับความคิดเห็นคนอื่น" และ ทีมต้องมีเวลาในการสอนกันเอง เช่น การทำ Code Review นั่นเอง หรือไม่มีเวลาจริงๆก็ควรจะต้องมีการทำ Pair Programming ก็จะเป็นการช่วยละช่องว่างของ Junior & Senior ลงได้ดีทีเดียว
ไม่ว่าคนพูดจะมีตำแหน่งอะไร หรือ เขาจะดูโง่แค่ไหนในสายตาเราก็ตาม เราก็ควรจะรับฟังสิ่งที่เขาพูด แล้วค่อยเสนอเหตุผลหรือวิธีการที่ดีกว่าให้เขาฟัง บางทีเราอาจจะประหลาดใจที่พบว่า พอเขาฟังเราเสร็จ เขาอาจจะบอกจุดอ่อนของเหตุผลของเราให้ฟัง แล้วพบว่าวิธีการของเขามันง่ายกว่าของเราก็เป็นได้ ... แต่เชื่อผมเถอะเราต้องฟังเขาก่อนตัดบทเขาเสมอ เพราะ ... เป็นคุณก็ไม่อยากทำฟังเหตุผลอีกคนถ้าเขาตัดบทพูดเราหรอก ... เขาคนนั้นก็เช่นกัน
แนะนำให้อ่าน สำหรับใครที่คิดว่าการทำ Pair Programming เป็นการเสียเวลา ผมแนะนำให้ไปอ่านหนังสือเรื่อง Agile Principles, Patterns, and Practices in C# ในบทที่ 4 เพียงบทเดียว ผมรับรองว่าเราจะมองการทำ pair programming เปลี่ยนไปเยอะเลย ส่วนอีกตัวที่แนะนำคือหลักในการทำงานพื้นฐานที่เหมาะกับการพัฒนาซอฟต์แวร์ 👦 Agile Methodology
สำหรับคนที่คิดอะไรม่ค่อยออก จำอะไรไม่ค่อยได้ และยังไม่มั่นใจว่ามาทำงานสายโปรแกรมเมอร์แล้วจะรอดหรือเปล่า ?ดช.แมวน้ำ โดนคำถามนี้มาเยอะม๊วกเวลาไปสอนน้องๆ มัธยมหรือมหาลัย ดังนั้นในบทความสั้นรอบนี้จะมาบอกเคล็ดไม่ลับที่ป๋มใช้เอาตัวรอดมาจนถึงทุกวันนี้ตามนี้ขอรับ
การท่องจำนั้นจะช่วยให้เราจำสิ่งนั้นๆได้ "ในระยะเวลาสั้นๆ" แต่ผ่านไปซักพักใหญ่ๆเราก็จะลืมมันจนหมด (ลองนึกดูของที่นั่งท่องก่อนไปสอบอ่ะ ยังจำกันได้ป่าว?) แต่สิ่งที่ป๋มใช้ตลอดมาก็คือการ "ทำความเข้าใจ" ซึ่งถ้าเราเข้าใจเรื่องอะไรแล้วเราก็จะ "ไม่ลืมตลอดชีวิต" แต่ถ้าลืมขึ้นมา แล้วไปทวนนิดหน่อยก็จะจำได้ทันที (ลองนึกดูว่าเราเคยลืมการบวกลบคูณหารเลขหรือเปล่า? เคยต้องไปนั่งท่องจำไหมว่าการคูณมันทำยังไง?)
การอ่านเป็นเรื่องดีที่ทำให้เราเข้าใจสิ่งต่างๆได้ แต่การอ่านนั้นก็เป็น "ความทรงจำระยะสั้น" เหมือนกัน (ถ้าเป็นเรื่องที่เราชอบอาจจะเป็นระยะยาว) และสิ่งที่เราเข้าใจ "อาจจะไม่ถูกหมดก็ได้" ดังนั้นวิธีการที่ดีที่สุด ไม่ว่าจะเป็นแมวน้ำที่เก่งกาจแค่ไหนก็ตามก็ต้อง เอาสิ่งที่ได้เรียนรู้มา "ไปลองทำ" เพื่อพิสูจน์ว่าตัวเองเข้าใจมันจริงๆหรือเปล่า ซึ่งมันจะทำให้เราเข้าใจได้ลึกขึ้น และมันจะกลายเป็น "ความทรงจำระยะยาว"
คนส่วนใหญ่ชอบจำแต่คำตอบ ซึ่งมันจะทำให้เราแก้ปัญหาได้ถ้าคำถามยังเป็นแบบเดิมๆ แต่สิ่งที่มีค่าที่สุดของคำตอบนั่นคือ "เหตุผลของการได้คำตอบ" นั่นเอง เช่น เราจำว่าเจองานปัญหาแบบนี้ให้ใช้ if..else นะ ซึ่งเราก็จะทำตามกันโดยไม่ได้สนใจเหตุผล ดังนั้นเราก็จะไม่รู้ว่าทำไมการใช้ switch case ถึงไม่เหมาะสม แล้วเมื่อไหร่มันถึงจะเหมาะสม? นั่นแหละคือสิ่งที่บอกว่า เหตุผลของคำตอบ คือสิ่งที่สำคัญที่สุด เพราะมันจะทำให้เราตัดสินใจในหลายๆสถานะการณ์ได้มากขึ้น
จริงไม่ว่าจะเป็นเรื่องไหนก็ตามมันมาจากหลักการคิดแบบ "ตรรกะ (Logic)" เพราะสมองเราไม่ได้เก่งในเรื่องการจดจำแบบมั่วๆ แต่มันเก่งในเรื่องการจดจำแบบมีเหตุผลมาประกอบเสมอ เช่น ลองเทียบการจำแบบที่ไม่มีตรรกะ กับแบบมีตรรกะดูนะ
แบบไม่มีตรรกะ คุณแม่ เด็กผู้หญิง ขนมปัง คุณยาย ป่ารกทึก หมาป่า นายพราน
แบบมีตรรกะ คุณแม่ให้เด็กผู้หญิงเอาขนมปังไปให้คุณยาย ที่อาศัยในป่ารกทึบ ซึ่งคุณแม่บอกว่าให้ระวังหมาป่าด้วย ดังนั้นเลยจ้ายนายพรานไปช่วยดูแลความปลอดภัย
แม้ว่าแบบมีตรรกะอาจจะยาวไปหน่อย แต่ผมเชื่อว่าถ้าให้จำแล้วล่ะก็ แบบมีตรรกะน่าจะจำง่ายกว่าเยอะเลยชิมิ?
ดังนั้น ดช.แมวน้ำ ขอฝากให้เพื่อนๆที่คนไปเข้าใจที่เหตุผลว่าเขามีตรรกะในการคิดยังไงกันนะครับ จะได้เอาไปใช้งานได้กับหลายๆสถานะการณ์ เพราะถ้าไม่อย่างนั้นเราจะ รู้คำตอบ แต่พลิกแพลงไม่ได้เหมือนในการ์ตูนนั่นเองนั่นเอง
แนะนำให้อ่าน ส่งที่จะช่วยให้เราสามารถเรียบเรียงความคิดได้ง่ายขึ้น เพื่อช่วยดูภาพรวมทั้งหมด นั่นคือ UML นั่นเอง ซึ่งเพื่อนๆสามารถศึกษาต่อได้จากลิงค์ด้านล่างนี้เบยครัช 👶 UML พื้นฐาน
ดช.แมวน้ำ ไม่ได้มีเจตนาจะว่าในรสนิยมความรักในกลุ่มนี้นะครับ และสนับสนุนความรักทุกรสนิยมด้วย เพราะผมก็เป็นโอตาคุที่ชื่นชอบใน สาวแว่น และ ผู้หญิง 2.5 D ทุกประการ ฮ่าๆ
โค้ดคือส่วนหนึ่งที่ทำให้ซอฟต์แวร์เกิดขึ้นมาได้ และ Developer หลายๆคนก็ไม่ได้สนใจคุณภาพของโค้ดที่ตัวเองเขียนสักเท่าไหร่ เพราะหลายคนคิดว่า "ถ้าส่งงานเก็บเงินได้ก็ถือว่าเป็นอันจบกัน" (น่าเสียดายงานส่วนใหญ่ในประเทศอุ๊งๆของเราเป็นแบบนี้) และจะคิดแบบนั้นก็ไม่ได้ผิดอะไรนะ แต่แมวน้ำอยากเตือนไว้ว่า
แนวคิดลักษณะนี้มันจะทำลายอาชีพ Programmer ของคุณในระยะยาว โดยตัวคุณจะทำงานแบบเด็กจบใหม่ทำกัน และมันจะบ่มนิสัยการเขียนโค้ดที่มืออาชีพเขาไม่ทำกันอีกด้วย !!
เพราะแนวคิดนี้มันจะทำให้เรามุ่งเน้นไปที่ "การสร้างซอฟต์แวร์เพื่อเอาไปขาย" และเมื่อขายได้ก็ไปสร้างตัวใหม่เพื่อขายต่อไปเรื่อยๆ ดังนั้นมันจะ "มุ่งไปที่ความเร็วในการผลิตซอฟต์แวร์" นั่นเอง
แต่เชื่อไหมว่า "ตัวชีวัดการอยู่รอดของบริษัทซอฟต์แวร์กลับไม่ใช่การสร้างซอฟต์แวร์" แต่มันเป็นเรื่องการ "ปรับปรุงรักษา" ต่างหาก ซึ่งเรื่องนี้แหละทำให้บริษัทที่ไม่ได้เข้าใจเรื่องนี้ส่วนใหญ่จะหายไปจากวงการ (ผลวิจัยคือ 80% ของบริษัทซอฟต์แวร์ที่ไม่เข้าใจเรื่องนี้จะปิดตัวลง)
ถ้าเราแอบไปดูบริษัทใหญ่ๆที่ทำซอฟต์แวร์ที่เรารู้จักเราจะพบว่า รายได้หลักของบริษัทจะเกิดจากการเซอร์วิสซอฟต์แวร์ตัวเดิมๆ มากกว่าการสร้างซอฟต์แวร์ตัวใหม่ เพราะรายได้ในระยะยาวของซอฟต์แวร์คือการเซอร์วิสโดยเน้นที่กินยาวๆนั่นเอง (Microsoft, Google, Facebook แม้ว่าจะมี product ใหม่ๆออกมา แต่ตัวที่เป็นพระเอกทำเงินก็ตัวเดิมๆแหละ)
ก็อย่างที่บอกไปว่ารายได้หลักของงานซอฟต์แวร์คือการกินงานเดิมไปยาวๆ ดังนั้นเราต้องมีการปรับปรุง พัฒนาความสามารถใหม่ๆให้กับมันไปเรื่อยๆ แต่ถ้าเราสร้างซอฟต์แวร์ขึ้นมาจากโค้ดที่ไม่ได้คิดถึงเรื่องเหล่านี้ สุดท้ายเรื่องเล็กๆน้อยๆพวกนั้นก็จะเป็นดินพอกหางแมวน้ำ ทำให้เราจมอยู่กับ Technical debt จนเราไม่สามารถไปเซอร์วิสอะไรได้อีกต่อไป และหนึ่งในแม่ทัพใหญ่เจ้าปัญหาก็คือการคลีนโค้ดนี่แหละ เพราะโค้ดที่พันกันมั่วซั่วเป็นสปาเก็ตตี้ มันไม่มีทางที่จะสามารถปรับปรุงแก้ไขได้ง่าย แถมเพิ่มความสามารถใหม่ๆก็ยากอีกด้วยนั่นเอง
แนะนำให้อ่าน ปัญหาที่ใหญ่ที่สุดในการทำซอฟต์แวร์
ลองหันมารักโค้ดของคุณดูดิ ! (ผมไม่ได้เมานะ) เพราะโค้ดมันเป็นกระจกสะท้อนตัวคุณตลอดเวลาแหละ โค้ดที่มีระเบียบ มี consistency ที่ดี มีการออกแบบ และ มีการใส่ใจที่ดี มันก็บ่งบอกได้ในระดับหนึ่งว่าคุณเป็นคนยังไง (บางที่แค่เห็นโค้ดก็รับเขาทำงานแล้ว เพราะ โค้ด = ตัวคุณ) หรือให้ลองคิดง่ายๆว่า การเขียนโค้ดมันก็เหมือนกับการเขียนนิยายดีๆซักเรื่องหนึ่ง ที่รอคนมาเปิดอ่าน แค่เราใส่ใจ ใส่ความรู้สึกว่าจะทำยังไงให้มันดีขึ้นให้ได้มากกว่านี้ เชื่อแมวน้ำตัวนี้เถอะเพียงแค่เรามี Mindset แบบนี้ โค้ดในปีนี้กับปีหน้ามันจะต่างกันจนคิดว่าเป็นคนละคนเขียนเลย เพราะ มีแต่ Professional เท่านั้นแหละที่ใส่ใจรักในลูกที่เขาสร้างขึ้นมา และสิ่งที่ได้มันจะเกิดขึ้นอัตโนมัติทุกอย่าง เหมือนกับการหายใจเลย
แนะนำให้อ่าน Clean Coder Blog เป็น blog ของหนึ่งในมหาเทพของวงการซอฟต์แวร์ของโลก ที่สอนในเรื่องการออกแบบ และอื่นๆอีกมากมาย ซึ่งเรียกได้ว่าถ้าอยากเป็น Professional ในวงการก็ต้องเรียนรู้จากคนนี้แหละ
เนื้อหาในรูปทั้งหมดในบทความนี้ไม่ใช่ของ Saladpuk นะจ๊ะ แต่พอดีไปอ่านมาแล้วรู้สึกว่าก็แนะนำได้กว้างดี ถึงจะมีบางเรื่องที่ไม่เห็นด้วยแต่โดยรวมๆก็ถือว่าทำมาได้ดีมากครับ ไปอ่านเนื้อหาจากต้นทางได้จากลิงค์นี้เบย https://github.com/kamranahmedse/developer-roadmap
เนื้อหาใน roadmap นี้เป็นแค่เพียงคำแนะนำว่า คุณควรจะศึกษาเรื่องอะไรบ้าง ซึ่งมันจะช่วยให้เราเข้าใจภาพรวมทั้งหมดว่าของต่างๆมันทำงานร่วมกันได้ยังไง สำหรับมือใหม่ ไม่ต้องตกใจ และ ไม่ต้องตะบี้ตะบันเรียนมันทั้งหมดก็ได้นะจ๊ะ ค่อยๆเรียนค่อยๆศึกษามันไปทีละตัว เดี๋ยวเขาจะทำไกด์ไลน์ของมือใหม่ให้อีกที
สำหรับคนที่อยากทำเว็บนั้นตอนที่กระโดดเข้ามา เราสามารถเลือกได้ 2 เส้นทางคือ Front-end
กับ Back-end
ตามรูปด้านบนนั่นเอง ซึ่งทั้งสองสายนี้ต้องมีความรู้ในการเขียนโค้ดในระดับหนึ่งเหมือนกัน แต่จะเป็น coding skill คนละแบบกัน และหน้างานที่รับผิดชอบก็ไม่เหมือนกันตามนี้
เป็นงานที่ทำหน้าเว็บ เช่น ตกแต่งหน้าตาให้สวยงามตามที่กราฟฟิคออกแบบไว้ เขียนสคริปให้มันมีลูกเล่นแจ่มๆ ทำให้มันแสดงผลได้ทั้งใน PC และ มือถือ ไรงี้ ดังนั้นใครที่ชอบเห็นผลลัพท์ทันทีทันใด ชอบอยู่กับความสวยความงามแล้วล่ก็ เตรียมตกนรกเจอกับเหล่า Browser ยี่ห้อต่าง ที่พร้อมจะแสดงผล ให้เราได้ปวดกบาลกัน และไหนจะผู้ใช้ที่พร้อมจะทำอะไรแผลงๆให้เราได้เซอร์ไพรส์กัน
เป็นงานที่เตรียมให้ระบบทั้งหมดดำเนินการไปตามที่คนจ้างอยากให้มันเป็น ซึ่งงานฝั่งนี้จะรอให้ฝั่ง Front-end ส่งข้อมูลทำงานต่อ เช่น ผู้ใช้กดสั่งซื้อสินค้าจากหน้าเว็บปุ๊ป ฝั่ง Back-end ก็จะต้องทำให้การสั่งซื้อนั้นไปดำเนินการต่างๆต่อ เช่น เช็คสต๊อกสินค้า ออกใบเสร็จ บลาๆ จนกระทั้งลูกค้าได้รับสินค้าไรงี้ ซึ่งนรกของฝั่งนี้ก็คือโค้ดโค้ดโค้ดและก็โค้ด เพราะความสวยงามของฝั่งนี้ที่จับต้องได้มีเพียงอย่างเดียวคือ เทสเคสสีเขียวสีแดง เพราะทุกอย่างของฝั่งนี้คือการออกแบบวางแผน Architecture ให้ระบบของเรามันดำเนินการได้โดยไม่ล่มนั่นเอง
ถ้าดูจากรูปแล้วเขาจะบอกว่าคนฝั่ง Front-end จะฝันมาเล่นการทำ DevOps ซึ่งในมุมผมคือก็ถูกส่วนหนึ่ง แต่จริงๆแล้วการทำ DevOps นั้นเราสามารถไปได้ทั้ง Front-end และ Back-end ครับ ส่วนมันเป็นอะไรไปอ่านต่อได้จากลิงค์นี้ละกัน 👶 DevOps พื้นฐาน
ไม่ว่าเราจะเลือกสายไหนก็ตาม แต่สิ่งที่สำคัญที่เราต้องเรียนรู้และใช้มันเป็นก็คือ
Git version control - เพราะสมัยนี้ไม่มี developer คนไหน copy งานใส่ flash drive แล้วส่งให้กับอีกแล้วนั่นเอง ส่วนถ้าสนใจอยากเรียนรู้เรื่อง Git ก็ไปศึกษาต่อได้จากวีดีโอชุดนี้ครับภาษาไทย Git Fundamental
Basic Terminal Usage - คำสั่งจากพวก command line เดี๋ยวนี้จำเป็นมาก เพราะมันเร็ว และส่วนใหญ่มันจะทำได้มากกว่าใน IDE แต่ที่ขาดมันไม่ได้เลยคือการ build ในหลายๆเรื่องมันต้องใช้ command เท่านั้น
Data structure & Algorithms - เพราะมันจะช่วยให้เราเข้าใจหลักการคิดแบบพื้นฐาน และโครงสร้างในการทำงานหลายๆอย่างมันใช้ของพวกนี้เป็นหลัก เช่น ถ้าบอกว่ามันทำงานแบบ Stack เราก็จะเข้าใจทันทีว่ามันทำงานยังไง โดยไม่ต้องเสียเวลาไปอธิบาย ซึ่งของพวกนี้เจอบ่อยม๊วก
HTTP/HTTPS & API - สมัยนี้ถ้าคนทำเว็บไม่เข้าใจหลักในการทำงานของมันนี่ เตรียมบอกลาอาชีพนี้ได้เลย เพราะมันเหมือนกับ เรารู้แต่บวกลบ แต่ทำคูณหารไม่เป็น นั่นเอง เพราะต่อไปนี้งานฝั่ง front-end มันจะวิ่งไปที่เรื่องเหล่านี้หมด เช่น จะจัดการเรื่อง performance ก็ต้องรู้จัก roundtrip เป็นอย่างน้อย หรือการทำงานของ POST กับ PUT มันต่างกันยังไง (Developer 70% ทำเรื่องพวกนี้ผิดนะจ๊ะ มันไม่ได้บาปหรอก แต่คนทำเป็นดูปุ๊ปเขาจะเห็นว่าคุณกำลังเอาฆ้อนไปเลื่อยไม้อ่ะ)
เรื่องอื่นๆที่เขาแนะนำมา ส่วนตัวผมก็คิดว่ารู้ไว้ก็ไม่เสียหาย แต่ไม่รู้ก็ยังไปในสายอาชีพนี้ได้อยู่นะ ดังนั้นไม่ขอลงรายละเอียดละกัน
สำหรับเหล่าแมวน้ำที่หลงไหลในความสวยงาม หรือ ไม่ชอบโค้ดอันหนักหน่วง แต่ทนรับการปวดกบาลของเหล่าผู้ใช้ และความตลกของสคริปต่างๆได้ล่ะก็ ถัดไปก็มาดูกันว่าเราควรจะต้องรู้เรื่องอะไรกันบ้าง ตามรูปด้านล่างเลย
กดไปดูที่เว็บเขาจะง่ายกว่าเยอะเลย ไม่ก็ดาวโหลดลงมาดูในเครื่องเอาละกัน
โดยหลักๆของสายนี้จะเน้นไปที่เรื่อง CSS, Javascript และการจัดการ Build pack ต่างๆ ดังนั้นถ้าไม่รู้เรื่องอะไรเลย ลองศึกษา CSS กับ Javascript แค่ตัวพื้นฐานของมันให้ทะลุเสียก่อน เพราะเวลาเราไปทำงานจริงนั้นส่วนใหญ่ เขาจะไม่ใช้ CSS ดิบๆ หรือใช้ Javascript ดิบๆ สุดท้ายก็ไปใช้ Framework ต่างๆต่ออยู่ดี เช่น CSS ก็จะไป SASS กับ Compass ส่วน Javascript ก็กระโดดไป TypeScript เล่นพวก Angular, React, Ionic บลาๆ ส่วนพวก Build pack เดี๋ยวความรู้พวกนี้ก็จะได้ตอนที่ไปเจอ node, gulp, bower แล้วค่อยไปตกนรกกับมันต่ออีกที
สำหรับเหล่าแมวน้ำที่หลงไหลในโค้ดเป็นชีวิตจิตใจ ชอบความท้าทายที่มองไม่เห็น ยอมรื้อโปรเจคเพื่อ Architecture ที่ดีกว่าได้เสมอ ก็จงไปดูเอาละกันว่าต้องเรียนรู้เรื่องอะไรบ้าง ตามรูปด้านล่างเบย
กดไปดูที่เว็บเขาจะง่ายกว่าเยอะเลย ไม่ก็ดาวโหลดลงมาดูในเครื่องเอาละกัน
โดยหลักๆของสายนี้เน้นไปที่ ภาษาใดภาษาหนึ่งเป็นหลักก่อน ศึกษาให้เข้าใจมันจนถึงแก่นเสียก่อน เพราะทุกภาษามันมีแก่นอันเดียวกัน ซึ่งเมื่อเข้าใจแล้วจะเปลี่ยนภาษาเมื่อไหร่ก็ได้ และตามมาด้วย Best Practices ที่ developer บ้านเราไม่ยอมอ่านไม่ยอมทำกัน เลยเกิดปัญหาเปิด stackoverflow ไปก๊อปงานมาส่งทุกครั้งที่เจอปัญหายังไงล่ะ (70-80% ของปัญหา ยิ่งเรื่อง security leak มันเกิดเพราะเราไม่ทำตาม best practices นะจ๊ะ) ถัดมาเป็นเรื่องความเข้าใจใน Architecture และ Database family เพื่อเลือกใช้มันให้เหมาะสมกับแต่ละโปรเจค แล้วก็ปิดท้ายด้วยการทำ Automation นั่นเอง ซึ่งฝั่ง Backend จำเป็นต้องเรียนรู้โคตรเยอะ เพราะงานมันล่มไม่ได้เลยทำให้ค่าตัวโดยเฉลี่ยเขาสูงกว่ายังไงล่ะ (ไม่ได้หมายความว่าคนทำ back-end จะเก่งกว่า front-end เสมอไป)
สำหรับแมวน้ำที่สุดท้ายก็ต้องการทำ Automation ให้กับระบบ และ ชื่นชอบในการทำงานร่วมกันเป็นทีมโดยไม่ต่อยกัน ก็จงเรียนรู้สิ่งต่างๆเหล่านี้ต่อเลย
กดไปดูที่เว็บเขาจะง่ายกว่าเยอะเลย ไม่ก็ดาวโหลดลงมาดูในเครื่องเอาละกัน
โดยสรุปคนทำรูปนี้เน้นเรื่อง DevOps ไปในเชิงการทำ Infrastructure ดังนั้นเลยหนีไม่พ้นการเรียนรู้พวก คลาว์, Build pipeline (CI/CD), IaC (Infrastructure as Code), OS ต่างๆ และเหล่า VM & Containers นั่นเอง
🤔 เดี๋ยวนี้การทำซอฟต์แวร์โปรเจคมันเป็นยังไงบ้างนะ
ตั้งแต่พระเจ้าแมวน้ำที่ 18 เรื่องธุรกิจ "เวลา" คือสิ่งที่สำคัญที่สุดเสมอมา ดังนั้นการทำซอฟต์แวร์โปรเจค "ความเร็ว" คือหนึ่งในสิ่งที่ขาดไม่ได้ในวงการนี้ แต่จะเร็วอย่างเดียวก็ไม่ได้ ต้องมี "ความปลอดภัย" ควบคู่ไปด้วย เพราะไม่อย่างนั้นเราจะทิ้งเศษซากแห่ง "หายนะ" ที่จะเป็นปัญหาในอนาคตของเรา
ดังนั้นวงจรการทำซอฟต์แวร์ของเรานั้น จะต้องเปลี่ยนทุกอย่างที่เคยทำด้วยมือ (Manual) ให้กลายเป็นของที่ทำได้เองอัตโนมัติ (Automation ) ให้มากที่สุดเท่าที่จะทำได้ เพื่อให้เราสามารถทดสอบมันซ้ำๆได้โดยไม่ต้องรอทีมเทส หรือแม้กระทั้งการทำ Build pipeline เพื่อให้ได้ Continuous Integration (CI) และ Continuous Deployment (CD) มานั่นเอง เพราะทุกวันนี้ตัวงานจริงๆมันจะต้องมี Environments เต็มไปหมดเลย เช่น สภาพแวดล้อมที่เอาไว้ให้ developer ทดสอบ (Development Environment) สภาพแวดล้อมสำหรับทีมทดสอบ (Test Environment) สภาพแวดล้อมก่อนเอาขึ้นใช้งานจริง (Staging Environment) และ สภาพแวดล้อมของงานจริงๆ (Production Environment) เห็นไหมแค่ไล่ environments ออกมาก็ปวดกบาลนะ
ลองคิดเล่นๆดูนะว่า ถ้าเราจะต้องมานั่งเอา product ไปไล่ deploy ลงในแต่ละ environment ด้วยมือแต่ละตัวแล้วล่ะก็ มันจะวุ่นวายขนาดไหน? แล้วถ้าเกิดเอางานขึ้นผิดตัวล่ะ? เช่น เอางานที่พึ่งเขียนสดๆที่ยังไม่ผ่านการเทสไปขึ้น production ไรงี้ (มันก็น่าจะสนุกดีนะ 😂) ดังนั้นเราจงค่อยๆเปลี่ยนสิ่งต่างๆที่เราเคยทำแบบ Manual ให้มันค่อยๆกลายมาเป็น Automation ให้ได้มากที่สุดนั่นเองครัช
แนะนำให้ลอง หากใครที่กำลังหาเครื่องมือทำ Build pipeline หรือ ตัววางแผนงานต่างๆอยู่ ผมอยากให้ลองใช้ Azure DevOps ดูนะ เพราะมันมีทุกอย่างที่เราอยากได้อยู่ในนั้นเลย ้เช่น Git Repository, CI/CD, Kanban board, รองรับการทำงานแบบ Agile และ Agile Scrum ด้วย หรือเราอยากจะ custom ให้เหมาะกับทีมตัวเองก็ได้นะ และแจ่มฝุดๆเพราะมันรองรับทุกภาษาสมัยใหม่น่าจะครอบคลุมทุกตัวหมดเบย ส่วนถ้าอยากลองให้กดดูได้จากลิงค์ด้านล่างนี้เบย Microsoft Azure DevOps Services
หนึ่งในข้อดีในการเขียน Test คือ "การแก้ปัญหาก่อนที่ปัญหานั้นจะได้เกิด" ลองคิดดูว่าถ้าเราเข้าใจโจทย์ผิดและเขียนลงไปในโค้ดแล้ว แล้วพอมีคนไปเจอ bug เหล่านั้น เราจะไปตามแก้ตามเช็ดกันขนาดไหน แต่ในทางตรงกันข้าม ถ้าเราป้องกันไม่ให้มันมีโอกาสเกิดปัญหาพวกนั้นเลยอันไหนมันจะง่ายกว่ากัน ลองดูตัวอย่างที่ดูแล้วก็ไม่มีอะไร แต่มันอาจะทำให้เกิด bugs ง่ายๆในระบบได้เลย
ตัวอย่าง ลูกค้าทั่วไปที่มาซื้อหนังสือถ้าซื้อเกิน 200 บาทจะได้ส่วนลด 10 บาท แต่ถ้าเป็นลูกค้า VIP จะได้ส่วนลด 15%
จากด้านบนก็ดูเหมือนจะไม่มีอะไรชิมิ? แต่ผมถามหน่อยว่า
ลูกค้าทั่วไปถ้าซื้อ 200 บาทพอดีเป๊ะ จะได้ส่วนลดหรือเปล่า ? (รู้ได้ไงว่าลูกค้าอยากได้แบบที่เราคิด?)
ลูกค้า VIP ที่ซื้อเกิน 200 บาทจะได้ส่วนลด 10 บาทนั่นด้วยหรือเปล่า ? (รู้ได้ไงว่าโปรโมชั่นมันทับซ้อนกันไม่ได้ ?)
ลูกค้า VIP จำเป็นไหมที่ต้องซื้อเกิน 200 เพื่อให้ได้ส่วนลด 15% (ในโจทย์ไม่ได้บอกนิ ?)
เห็นป่าว เพียงแค่โจทย์ที่ดูเหมือนจะไม่มีอะไรซับซ้อนเลย แต่ถ้าเราไม่เคลียประเด็นพวกนี้กับลูกค้า นั่นก็หมายความว่าเราได้ก่อ bug ไว้ในระบบแล้ว ซึ่งในตัวอย่างมันอาจจะเล็กน้อยจนคนอาจจะไม่ได้ใส่ใจมาก แต่ถ้าลองคิดในมุมกลับดูว่า นี่มันเป็นเรื่องเงิน และถ้าเราคำนวณเงินผิดและทำให้เงินของร้านหาย อาจจะครั้งละไม่กี่บาทก็จริง แต่ถ้าลูกค้าตรวจบัญชีแล้วพบขึ้นมา เงินที่หายไปเขาจะมาทวงที่ใคร ? และถ้าเป็นตัวเราเองจะยังอยากจ้างบริษัทที่เขียนงานแบบนี้อยู่ต่อหรือเปล่า ?
สำหรับคนที่สนใจอยากรู้เรื่องการเขียน Test แนะนำลิงค์นี้เบยดูได้ฟรีตั้งแต่ต้นจนจบ
👦 Test-Driven Development (คอร์สจัดหนัก)
👦 Test-First Design (ตัวอย่างเบาๆ)
หนังสือแนะนำ Writing Great Specifications: Using Specification By Example and Gherkin
หรือจะลองเข้าไปอ่านตัวนี้ก่อนก็โอเคอยู่นะ Writing Great Specifications
💀 สิ่งที่คนในวงการซอฟต์แวร์ทำผิดกันคือ การเอา solution เป็นที่ตั้ง แล้วค่อยมาปรับให้เข้ากับความต้องการของลูกค้า ซึ่งเรื่องนี้เป็นเรื่องที่อันตรายมาก เพราะมันอาจจะทำให้ของที่ออกแบบมานั้นอาจได้รือทำใหม่ หรือต้องแก้แบบไม่ถูกหลักในการออกแบบชนิดแมวเห็นยังกรีดร้องถามหาคนออกแบบ
💖 หัวใจสำคัญของวงการซอฟต์แวร์คือ Business Requirements ดังนั้นจงนำสิ่งนี้เป็นตัวตั้ง ห้ามมโน ห้ามมั่ว เป็นอันขาด และเมื่อเข้าใจความต้องการที่แท้ทรูของลูกค้าแล้ว เราค่อยมาเลือกเทคโนโลยี ค่อยมาหา solution ที่เหมาะสมกับมันอีกทีต่างหาก
ลองคิดง่ายๆ เราจะไปจีบใครซักคน เราจะเดินไปหาเขาแล้วซื้อไอติมให้เข้าเลยหรือเปล่า? หรือจะทำความเข้าใจก่อนว่าเขามีรสนิยมยังไง เป็นคนแบบไหน ชอบอะไร แล้วค่อยมาตัดสินใจอีกทีว่าจะจีบเขายังไง? ... การทำซอฟต์แวรก็เช่นกับการจีบใครซักคนแหละ อย่าเข้าใจลูกค้าแค่พอผ่านๆ เพราะสิ่งที่ลูกค้าพูดอาจจะไม่ใช่ความต้องการที่แท้จริงของเขาก็ได้
"ความรู้คือที่สุดแห่งสายอาชีพนี้" ผมเชื่อว่าหลายคนก็น่าจะเห็นด้วยกับประโยคดังกล่าว เพราะการที่เราจะออกแบบของต่างๆที่ดีได้นั้น เราจำเป็นต้องอาศัย ความรู้ นั่นเอง
แต่ก็มีหลายครั้งที่เราไปอ่านตำราบางเรื่อง เทคนิคบางอย่าง แล้วกลับพบว่าทำยังไงก็ไม่เข้าใจมันซักที ไม่ว่าจะอ่านมันซักกี่รอบ หาตัวอย่างมาซักกี่แบบก็ตามที ก็ยังคงไม่เข้าใจ หรือบางทีก็เข้าใจนะ แต่ก็ยังมีคำถามคาใจว่าทำไมต้องทำแบบนั้นหว่า (เช่นเรื่อง SOLID Design หรือ Design Patterns) แต่พอผ่านมาซักระยะหนึ่ง (อาจจะเป็นปีก็ได้) พอเราได้ย้อนกลับไปอ่านมันใหม่ เรากลับพบว่า เราเข้าใจมันได้แบบง่ายๆ แถมยังสามารถตอบคำถามที่เคยสงสัยได้อีกด้วย ทำไมถึงเป็นแบบนั้นหว่า ?
คำตอบก็คือเรามี ประสบการณ์ ถึงจุดที่จะเข้าใจแล้วยังไงล่ะ เช่น เคยเจอปัญหานั้นกับตัวเอง เคยได้ยินได้เห็นวิธีการแก้ไขปัญหาเหล่านั้นมาแล้วนั่นเอง ซึ่งเรื่องเหล่านี้มันเป็นสิ่งที่ สอนกันยาก ต้องเจอกับตัวเองถึงจะได้มันมา ดังนั้นเราไม่ต้องซีเรียส ถ้าศึกษาเรื่องอะไรแล้วยังไม่เข้าใจมันอย่างถ่องแท้ เพราะเรายังสะสมประสบการณ์เรื่องนั้นๆไม่มากพอ แต่เมื่อเวลาผ่านไป เดี๋ยวเราก็จะเข้าใจมันเอง และหลายๆคนทำงานอยู่ดีๆก็อาจจะร้อง อ๋อ ในเรื่องที่เคยศึกษามาเมื่อ 2 ปีก่อนก็เป็นได้ (ตรัสรู้ขณะทำงานฮ่าๆ)
เราเคยได้ยินไหมว่า ที่สุดของเรื่องนั้นๆ คือการไม่ต้องทำเรื่องนั้นๆ เช่น สุดยอดแห่งการเรียน คือการไม่ต้องเรียน, ที่สุดแห่งการล้างแค้น คือการไม่ล้างแค้น ไรงี้
ซึ่ง วงจรในการเรียนรู้ ไม่ว่าจะเป็นวงการไหน มันก็สรุปออกมาได้เป็นแบบนี้
👶 ช่วงแรก - ที่เราเข้าใจเรื่องที่รู้สึกว่ามันเจ๋งมากๆ เราก็อยากจะเอามาใช้ในงาน เพื่อแก้ปัญหาในรูปแบบนั้นๆ เพราะเรารู้ว่ามันดีมากๆนั่นเอง ซึ่งอาจจะใช้มันผิดๆถูกๆอยู่บ้าง
👦 ช่วงกลาง - พอใช้ไปใช้มาเราก็จะชำนาญมากขึ้น ใช้งานมันได้ถูกต้องตามหลักการ แถ้มยังพลิกแพลงมันตามสถานะการณ์ต่างๆได้อีกด้วย
🧔 ช่วงตรัสรู้ - เราเลือกที่จะไม่ใช้มันได้ ตามสถานะการณ์ เพราะรู้ว่าถ้าใช้มันจะนำพาอะไรมา และรู้ว่าเมื่อไหร่ควรที่จะใช้มัน อีกทั้งยังรู็ว่าความรู้เรื่องนั้น จริงๆมันไม่มีอะไรเลยนั่นเอง
ตัวอย่างหมอผ่าตัด
👶 ช่วงแรกที่จบใหม่ - พอมีคนไข้ผ่าตัดเข้ามา เขาก็จะพาไปเข้าห้องผ่าจัดเพื่อรักษาเลย อาจจะใช้เวลานานหน่อยกว่าจะทำเสร็จ
👦 ช่วงกลาง - พอมีคนไข้ผ่าตัดเข้ามา ก็สามารถผ่าตัดได้อย่างชำนาญ เสร็จเร็ว ปิดแผลสวย
🧔 ช่วงตรัสรู้ - พอมีคนไข้ผ่าตัดเข้ามา เขาก็ดูอาการหน่อยแล้วอาจจะเลือก ไม่ต้องผ่า เพราะถ้ารอไปอีกซักหน่อย แล้วค่อยผ่าจะดีกว่า หรือบางเคสอาจจะไม่จำเป็นต้องผ่าเลยก็ได้
*เป็นเรื่องสมมุติเพื่อให้เห็นภาพนะ ของจริงไม่เป็นแบบนี้หรอก เขาไม่ให้หมอจบใหม่ทำเรื่องพวกนี้เอง แต่เขาจะให้หมอจบใหม่-จบมานานแล้ว ไปฝึกเป็นผู้ช่วยไปเรื่อยๆเก็บประสบการณ์จนกว่าจะ Level UP นั่นเอง เพราะชีวิตคนมันล้อเล่นไม่ได้ ... แล้วซอฟต์แวร์ล่ะ ?
สุดยอดของการเป็นโปรแกรมเมอร์ คือการที่เราสามารถเลือกได้ว่า เมื่อไหร่ควร เมื่อไหร่ไม่ควร ในแต่ละจังหวะเวลาได้อย่างถูกต้อง ซึ่งการที่จะทำแบบนั้นได้ย่อมต้องผ่าน ประสบการณ์ไปถึงจุดนึงก่อน ดังนั้นจงหาโอกาสไปผจญภัยเก็บ exp มาอัพเวลกันโดยพลัน แต่อย่าเมากาวพุ่งทยานฟันโจทย์อย่างเดียว เราต้องหันกลับมา วิเคราะห์ สิ่งที่เราได้เรียนรู้จากโจทย์เหล่านั้นๆด้วยถึงจะได้สิ่งที่เรียกว่า การเข้าใจอย่างแท้จริง หรือที่ผมชอบเรียกติดปากว่า ตรัสรู้ นั่นเอง 😍
แนะนำให้อ่าน สำหรับเพื่อนๆที่สนใจอยากศึกษาเรื่องหลักในการออกแบบขั้นพื้นฐานที่ชื่อว่า SOLID Design สามารถอ่านได้จากลิงค์นี้ https://saladpuk.gitbook.io/learn/basic/solid
สำหรับเพื่อนๆที่อยากศึกษาหลักในการแก้ปัญหาที่เจอบ่อยๆในการพัฒนาซอฟต์แวร์ที่ชื่อว่า Design Patterns สามารถอ่านได้จากลิงค์นี้ https://saladpuk.gitbook.io/learn/software-design/designpatterns
🤔 เวลาทำซอฟต์แวร์โปรเจคจริงๆมันไม่มีอะไรเลย ถ้าเขาใจธรรมชาติของมัน
ปัญหาเรื้อรังอีกตัวที่จะคอยกัดกินเหล่า developer ในระยะยาวคือ "ความรู้ในการเขียนโค้ด" เพราะปัญหาส่วนใหญ่ที่เกิดขึ้นกับการทำซอฟต์แวร์นั่นคือ "เราไม่สามารถแก้ไขปรับปรุงโค้ดได้ง่ายเหมือนที่เราอยากให้มันเป็น" นั่นเอง ซึ่งเชื่อไหมว่าเหล่า developer หลายๆคนได้ทุ่มเงิม ทุ่มเวลา เพื่อหวังว่าจะได้ความรู้เรื่องเหล่านี้มา ซึ่งเชื่อไหมว่าเคล็ดลับทั้งหมดเมื่อกลั่นออกมาแล้ว เราจะสรุปมันออกมาได้ง่ายๆว่า
1.ฝึกเขียนโค้ดบ่อยๆ - ไม่ใช่ตะบี้ตะบันเขียนไปเรื่อย แต่จงดูปัญหาที่มันเกิด แล้วจงวิเคราะห์ว่าจะแก้ด้วยวิธีการแบบไหน หรือจะไปดูโค้ดคนอื่นๆด้วยก็จะทำให้เราได้เรียนรู้ข้อดีข้อเสียแบบต่างๆได้เร็วขึ้น และอย่าลืมคิดถึงเรื่องการออกแบบไว้ด้วยว่ามันดีพอหรือยัง? ทำยังไงถึงจะดียิ่งๆขึ้นไปอีก?
2.ทำตาม Best practices - ในการทำงานกับเรื่องอะไรก็ตาม ในแต่ละเรื่องมันจะมี best practices ของมันเสมอ ซึ่งถ้าเราไม่ทำตามก็ไม่เป็นไรนะ แต่มันจะทำงานได้ไปจนถึงจุดหนึ่งแล้วมันจะเริ่มมีปัญหานั่นเอง ซึ่งเรื่องนี้ก็เป็นเรื่องแปลกที่เหล่า developer ส่วนใหญ่จะไม่ยอมไปอ่านเรื่องพวกนี้ จนกว่ามันจะเกิดปัญหาแล้วค่อยไปนั่งไล่อ่าน
3.มี Code Coverage - การที่โค้ดของเรามีตัวมาช่วยตรวจสอบความถูกต้องนั้นถือว่า "เป็นบุญของทีมและของบริษัท" เลย เพราะในระยะยาวเราจะสามารถเพิ่มเติมแก้ไขปรับปรุง ทุกอย่างได้ตามที่เราอยากจะทำได้ง่ายม๊วกๆ แต่ในระยะสั้นที่เห็นผลได้เลยคือ เราสามารถมั่นใจได้เลยว่าโค้ดของเรามันไม่ได้เป็นตัวการผลิต bug หรือต่อให้มีก็ไม่ได้เยอะนั่นเอง
เรื่องตลกร้าย พวกเราเหล่า developer ส่วนใหญ่จะรู้เรื่องพวกนี้อยู่แล้ว แต่จะมองว่ามันเป็นเรื่องเสียเวลาที่จะทำของพวกนั้น แล้วหลายคนก็บอกว่าก็รอให้มันเกิดก่อนค่อยไปแก้มันดิ ซึ่งมันก็เป็นคำตอบที่เข้าใจได้อยู่ว่าทำไมเขาถึงเลือกทำแบบนั้น เพราะสถานะการณ์แต่ละคนอาจะไม่เหมือนกัน แต่ผมอยากจะฝากอีกมุมมองนึงไว้ว่า
จงรักโค้ดเราเหมือนรักลูก เพราะเราคือ "ผู้เชี่ยวชาญ" ในการสร้างซอฟต์แวร์ ดังนั้นความรู้ทุกอย่างในการทำมาหากินของเราคือ "ความรู้" และ "ความปราณีต" ในตัวงานนั่นเอง ถ้าเราฝึกมันจนเป็นธรรมชาติไปแล้ว ทุกอย่างมันจะออกมาเอง เหมือนกับเราไม่ต้องไปคอยบังคับให้เราหายใจยังไงล่ะ ดังนั้นสุดท้ายแล้ว ของที่เราต้องใช้บ่อยๆ เราก็ควรที่จะรู้ Best Practices ของมันอยู่ดี เช่นเราเขียน MongoDB มาตลอด 5 ปี เราก็ควรจะต้องรู้จัก Best Practices ของมันได้แล้วนะ ไม่งั้นมันก็จะเหมือนกับ ช่างที่รู้จักเครื่องมือแค่ไม่กี่ตัว แถมยังเอาเครื่องมือไปใช้ผิดๆถูกอีก เวลาเราเห็นช่างเอาค้อนไปเลื่อยไม้ เราจะคิดยังไง? แต่โชคดีหน่อยที่การทำซอฟต์แวร์นายจ้างไม่ได้เข้าใจมาเห็นเราเอาค้อนไปเลื่อยไม้ยังไงล่ะ
🤔 developer ชอบลาออก เป็นปัญหาของใครกันแน่ ?
การหา Developer ซักคนที่ "ทำงานเป็น" ในวงการการทำซอฟต์แวร์นั้น ยากพอๆกับการถูกหวยเลยก็ว่าได้ แต่ที่ยากกว่าการหาคนนั้นคือ "การรักษาให้เขาอยู่กับเราไปนานๆ" ต่างหาก คือความหินที่แท้จริง ดังนั้นบริษัทต่างๆเลยเริ่มมีโครงการ "ปั้นดินให้เป็นดาว" เพื่อหวังว่าพอเป็นดาวแล้ว บริษัทก็จะสบายในอนาคต ... สุดท้ายกว่าจะรู้ตัว ดาวเหล่านั้นก็ไปทอแสงให้กับบริษัทอื่นแทนซะงั้น เพราะเงินเดือนที่มากกว่า
จากที่ร่ายมาจะโทษว่าเป็นความผิดของโปรแกรมเมอร์อย่างเดียวก็ไม่ได้ ที่เขาจะลาออกไปหาบริษัทอื่นที่เขาคิดว่าดีกว่า แต่ในบทความนี้ผมอยากให้แง่คิดของ Developer รุ่นใหม่ๆ และ แง่คิดกับบริษัทต่างๆ ว่าทำยังไงถึงจะอยู่ร่วมกันได้แบบวินๆ
เงินเดือนไม่ใช่สิ่งที่สำคัญที่สุด - ถ้าคุณกำลังจะย้ายงานเพราะอีกบริษัทให้เงินเดือนมากกว่าเพียงแค่นั้นแล้วล่ะก็ ผมแนะนำว่าอย่าทำ แต่ผมจะแนะนำว่า "จงเล็งหาบริษัทที่เราสามารถไปเรียนรู้วิชาต่างๆเพื่อพัฒนาตัวเองแบบก้าวกระโดดได้จะดีกว่า" เพราะสุดท้ายถ้าคุณไม่ได้มี skill ที่เหมาะกับรายได้นั้นจริงๆ สุดท้ายคุณก็จะกลับมาอยู่ใกล้ๆกับฐานเงินเดือนที่เท่ากับ skill ที่คุณมีนั่นแหละ ซ้ำร้ายถ้าคุณติดสบายจากเงินเดือนเยอะๆแล้ว มันจะเป็นการกดดันตัวเอง เพราะต้องหาบริษัทที่ให้เงินเดือนเท่าเดิมหรือมากขึ้น ทั้งๆที่ฐาน skill เราไม่ใช่ของจริงนั่นเอง แต่ในทางกลับกันถ้าเราเลือกบริษัทที่สามารถทำให้เราเก่งขึ้นไปได้เรื่อยๆ "สุดท้ายคุณนั่นแหละจะเป็นคนเลือกบริษัท ไม่ใช่บริษัทมาเลือกคุณ" เพราะ โปรแกรมเมอร์ที่ทำงานเป็นจริงๆ มันขาดแคลนพอๆกับวงการแพทย์เลยนั่นเอง
>>> ประสบการณ์คือสิ่งที่สำคัญที่สุดในสายอาชีพนี้ <<<
1.บริษัทได้ให้โอกาสเขาพิสูจน์ตัวเองหรือเปล่า? - ถ้าคุณจ้าง developer ที่เก่งๆเข้ามา แต่คุณไม่เคยมีเวทีให้เขาได้พิสูจน์ฝีมือเขาเลย ทำแต่งานเดิมๆซ้ำๆเดิมๆ ไม่ได้ให้ทีมรู้สึกว่ามันมีความท้าทายต่ออนาคตเขาแล้วล่ะก็ เตรียมบอกลาพวกเขาได้เลย เพราะสุดท้าย ถ้ามีบริษัทไหนเสนอเงินเดือนที่มากกว่าให้ มันก็มีโอกาสสูงที่พวกเขาก็พร้อมจะเก็บกระเป๋าเดินไปฉายแววที่อื่นเช่นกัน
2.บรรยากาศในการทำงานสนุกไหม? - ถ้าคุณเห็นว่าคนในทีมเริ่มทำงานใครทำงานมัน ตอนเที่ยงกินข้าวแยกใครแยกมัน มีการแบ่งชั้นวรรณะกันชัดเจน หรือแย่กว่านั้นมีการเล่นการเมืองภายในกันด้วย ขอให้คุณไปคุยกับฝ่าย HR เรื่องเตรียมหาคนมาสำรองไว้ได้เลย เพราะบรรยากาศในการทำงานของวงการนี้สำคัญที่สุด ต่อให้เงินเดือนไม่ได้มากมายเท่าไหร่ (พอมีเงินเก็บมีเงินเที่ยวเล่นบ้าง) แต่ถ้าเราทำงานแล้วสนุก เพื่อนเยอะ คุยกันเล่นกันได้แบบพี่เหมือนน้องแล้วล่ะก็ Loyalty ที่เขาจะอยู่กับบริษัทคุณจะทนทานกว่าเยอะ แม้จะมีบริษัทอื่นมาให้เงินเดือนมากกว่า เขาก็(น่าจะ)เลือกทำงานอยู่กับเราเหมือนเดิม (ถ้าไม่เยอะแบบกระโดดอ่ะนะ)
3.เงินเดือนเหมาะสมกับงานหรือเปล่า? - เรื่องเงินเป็นเรื่องที่ยังไงก็เลี่ยงไม่ได้ ต่อให้เราทำทุกอย่างดีแล้วก็ตามสุดท้ายก็ขึ้นอยู่กับ loyalty และมุมมองในการใช้ชีวิตของคนแต่ละคนแล้วล่ะ แต่ทางบริษัทก็ต้อง "ให้ในสิ่งที่ developer สมควรจะได้ ตามความเหมาะสมของงานที่เขารับผิดชอบด้วยเช่นกัน"
กฎเหล็กในการทำงานให้มีประสิทธิภาพสูงสุด
เวลาทำอะไรก็แล้วแต่ให้คิดถึงกฎ 80:20 ไว้เสมอ โดยให้เราทุ่มแรงไปกับงานกลุ่ม 20% แต่งานกลุ่มนั้นมันได้ผลลัพท์กลับมาถึง 80% ตลอด เพราะทุกวันนี้ในการทำซอฟต์แวร์นั้นมันจะมี features อยู่เป็นร้อยๆอย่างเลยภายในโปรเจคเดียว แต่เชื่อไหมว่ามันจะมี feature ที่เป็นพระเอกที่คนส่วนใหญ่เข้าไปใช้งานจริงๆอยู่แค่เพียง 20% เท่านั้น ดังนั้นหมายความว่าอีก 80% ที่เหลือมันเป็นแค่ของที่มีไว้ก็ดีแต่อาจจะไม่จำเป็นต้องมีก็ได้ ดังนั้นในการลงมือทุ่มแรงทีมควรจะเลือกงานที่ได้ประโยชน์สูงสุดต่อ Business และต่อ Architecture ที่สุดตลอดเวลา ไม่งั้นเราจะส่งมอบงานที่ผู้ใช้แทบจะไม่ใช้กันเลยและมันอาจจะไม่ส่งผลดีเท่าที่ควรให้กับ business ก็ได้
🤔 แปลกแต่จริง และ เราก็จะเจอมันเสมอ
ในการทำซอฟต์แวร์โปรเจค หลังจากที่เราได้รับ Requirements จากลูกค้า หรือ อะไรก็ตาม เราจะพบว่า Developer หลายๆคนเลือกที่จะ "เขียนโค้ดเป็นอันดับแรก" ไม่ก็ไป "ออกแบบระบบต่างๆเป็นอันดับแรก" เช่น ออกแบบฐานข้อมูล, ทำ class diagram, เลือกเทคโนโลยีที่จะใช้ บลาๆ ซึ่งเชื่อไหมว่านั่นก็เป็นหนึ่งในปัญหาที่เราคิดว่ามันเป็นเรื่องปรกติไปเสียแล้ว
เพราะการทำซอฟต์แวร์นั้น ถ้าตัวเรา คนในทีม และลูกค้า ยังไม่ได้เคลียประเด็นความเข้าใจกัน ว่างานแต่ละส่วนคืออะไร?, งานแต่ละตัวมีลำดับความสำคัญยังไง?, และอะไรคือจะเรียกว่าเราปิดงานตัวนั้นได้? หรือพูดรวมๆคือ
แต่ทีมกระโดดไปทำของที่ยังคลุมเคลืออยู่มันจะเกิดอะไรขึ้นถ้าสิ่งนั้นมันต้องแก้ไข? ดังนั้นสิ่งที่ทีมควรจะทำเมื่อได้รับ requirements ต่างๆจากลูกค้า คือ
คุยกับลูกค้าก่อนว่า features เหล่านั้นมันจะไปช่วยตอบโจทย์อะไรเขา เพื่อหาความต้องการที่แท้จริง เพราะบ่อยครั้งลูกค้าจะพูดสิ่งที่เขาอยากได้ แต่มันไปแก้โจทย์ทาง business แบบอ้อมๆเท่านั้นเอง
คุยกับลูกค้าก่อนว่า ความเร่งด่วนของแต่ละ features เป็นยังไง และกับในหน้าตักตอนนี้ เขาอยากได้อะไรก่อน เพื่อเราจะได้ส่งมอบงานที่มีผลกระทบสูงสุดกับธุรกิจเขาก่อน เพราะผมเชื่อว่าระบบ login น่าจะมีผลน้อยกว่า ระบบสั่งซื้อแน่นอน
เคลียความเข้าใจกับลูกค้าก่อนว่า features ที่เรากำลังจะทำให้เขานั้น ลูกค้าตีว่าเขาต้องได้อะไรบ้างถึงจะถือว่าส่งมอบงานได้ เพราะไม่งั้นเราจะทำงานเสร็จโดยเรารู้สึกว่ามันเสร็จ แต่สำหรับลูกค้าอาจจะมองว่ามันยังไม่เสร็จก็ได้
จากเรื่องที่เล่ามา บริษัทหลายๆบริษัทเลือกที่จะไม่ทำของเหล่านี้เพราะคิดว่ามันเสียเวลาที่จะมานั่งคุยกัน ซึ่งคำตอบตอบคือใช่ครับ มันเสียเวลาในระยะแรก แต่ถ้านับในระยะยาวแล้วมันคุ้มค่าในการทำ
🤔 คุณภาพดีแต่ทำเสร็จช้า กับ ทำเร็วแต่คุณภาพกาก เลือกไรดี ?
ในเรื่องของธุรกิจ เวลา คือสิ่งที่สำคัญที่สุด เพราะถ้าปล่อยของออกตลาดได้ช้า นั่นก็อาจจะหมายถึงจากไปของบริษัทเลยก็เป็นได้ และแน่นอนเหล่าโปรแกรมเมอร์ก็มันจะโดยท้าทายด้วยตัวเลือก 2 ตัวนี้เสมอ
"ทำให้ส่งงานได้ไปก่อนแล้วค่อยมาแก้ทีหลัง" หรือจะเลือก "ทำให้มันถูกต้องไปเลยแต่อาจจะช้าหน่อยนะ"
คำตอบมีหลากหลายแง่มุมมาก ดังนั้นในบทความนี้ผมอยากจะให้แนวทางแบบรวบรัดว่าทีมควรจะเลือกเดินยังไงต่อเมื่อเจอปัญหาพวกนี้ครับ
1.มันเป็นเรื่องคอขาดบาดตายแล้วจริงๆ - เช่น บริษัทเราอาจไปรับปากอีกบริษัทหนึ่งว่ามันจะเสร็จ ซึ่งเมื่อถึงเวลาที่ต้องส่งงาน เหล่า developer ก็ต้องทำทุกอย่างให้มันได้ตามที่คุยกันจริงๆไม่ว่าจะด้วยอะไรก็ตาม
2.ทีมขวัญกำลังใจตก - เหมือนจะไร้สาระ แต่ถ้าทีมส่งมอบอะไรไม่เคยได้ตามที่ตกลงเลยบ่อยๆเข้า ทีมนั้นจะหมดกำลังใจในการทำงานและยิ่งทำก็จะยิ่งกดดัน ดังนั้นในบางครั้งถ้ามันพอจะปล่อยได้และไม่ได้เป็นเรื่องซีเรียสมาก เราก็อาจจะต้องยอมปล่อย เพื่อให้ทีมได้มีความเชื่อมั่นกลับมาอีกครั้งนั่นเอง
1.สิ่งนั้นมันเป็น Core Architecture และเราคุยกับลูกค้าแล้วเขารับผลกระทบที่ตามมาได้ - เพราะตัว core architecture ถ้าเราทำมันแบบส่งๆแล้วล่ะก็ Bad Code เหล่านั้นจะลามและแก้ยากมาก ดังนั้นตัดไฟตั้งแต่ต้นลมจะดีกว่าครับ
2.ใช้เวลาแก้แล้วก็ยังอยู่ภายใน iteration ที่ commit อยู่ - เพราะ Bad Code ถ้าเราปล่อยไว้แทบจะเรียกได้เลยว่า ไม่มีใครกลับมาแก้หรอก ถ้าไม่ได้ใจรักจริง และการปล่อยให้มี Bad Code อยู่สุดท้ายมันจะกลายเป็น Technical debt ซึ่งเจ้าตัวนี้นี่แหละคือตัวภัยร้ายที่จะฆ่าบริษัทเราในภายหลัง (อ่านเรื่องนี้ได้จากบทความ ปัญหาที่ใหญ่ที่สุดในการทำซอฟต์แวร์) ดังนั้นถ้าไม่มีผลกระทบมากผมเลือกที่จะลดจำนวน features ที่จะ commit ลงแล้วเก็บงานให้มันเป็นของที่มันควรจะเป็นจะดีกว่าครับ
สุดท้าย ไม่ว่าจะเลือกวิธีไหนมันก็ต้องมีผลตามมาแน่นอน ดังนั้นไม่ว่าจะทำอะไร (ถ้าทำได้) เราก็ควรจะปรึกษากับลูกค้าก่อนที่จะลงมือตัดสินใจเดินงานต่อ เพราะในบางทีของที่เราคิดว่าสำคัญนั้น ในมุมของลูกค้าอาจจะไม่สำคัญเลย และตรงกันข้ามกัน ของที่ลูกค้าคิดว่ามัน โคตรสำคัญ เราดันกลับไปมองว่ามันไร้สาระก็เป็นได้
ความสนุกก็เกิดขึ้นได้ทุกวัน เมื่อทีมไม่เข้าใจกัน
เรื่อง Communication เป็นหนึ่งในเรื่องที่เราไม่สามารถปฎิเสธได้เลยว่า มันคือหนึ่งในปัญหาหลักของการทำงานเป็นทีมเลย เนื่องจากถ้ามีคนในทีมเข้าใจไม่ตรงกันแล้วไม่ได้เคลียความเข้าใจ ปัญหาที่จะเกิดขึ้นมันจะไม่ใช่แค่กับคนที่เข้าใจผิดเท่านั้น เพราะมันอาจะทำให้งานของทั้งทีมไม่สามารถปิดได้ตามเวลาที่กำหนดนั่นเอง และถ้าแม้กระทั่งคนภายในทีมยังเข้าใจไม่ตรงกันได้ นั่นหมายความว่า ทีมเราและทีมอื่นๆที่ทำงานร่วมกันก็อาจจะเข้าใจไม่ตรงกันด้วยได้เช่นกัน ส่งผลให้เกิดเป็น Domino effect กระทบกันไปเรื่อยๆจนสุดท้ายบริษัทอาจจะหมดความน่าเชื่อถือไปเลยก็มี
✋ จงอย่าทำทุกอย่างให้ Perfect ตั้งแต่ครั้งแรก
กฎ 80:20 คือตัวที่จะทำให้ชีวิต Developer ดีขึ้นถ้าเราเข้าใจมัน ซึ่งมันอยู่ในทุกวงการ และเราไม่สามารถหนีจากมันได้ ดังนั้นมารู้จักมันซักหน่อยดีกว่านะเหล่าแมวน้ำทั้งหลาย
กฎ 80:20 นั้นจริงๆไม่มีอะไรเลย เขาแค่บอกว่า "ถ้าเรามีงาน 100 เรื่อง" ตามรูปด้านล่าง แล้วล่ะก็
งาน 80 เรื่อง เราออกแรงแค่ 20% ก็จะสามารถทำมันเสร็จได้
ส่วนงาน 20 เรื่องที่เหลือ เราต้องออกแรง 80% ถึงจะสามารถทำมันเสร็จได้
ซึ่งมันหมายความว่า "งานกว่า 80% เราสามารถปิดมันได้โดยใช้แรงทำแค่ 20%" แต่ว่าถ้าเราต้องการ "ทำงานให้สมบูรณ์ 100% เราต้องใช้แรงทำมากกว่าปรกติ 4 เท่า เพื่อให้ได้งาน 20% ที่เหลือ"
💖 หัวใจของกฎ 80:20 คือการลง effort ให้ถูกจุด เพื่อให้ได้ผลลัพท์ที่คุ้มค่าที่สุด
เพราะสิ่งที่มีค่าสูงสุดของธุรกิจคือ "เวลา" ดังนั้นเราควรจะลงแรงให้น้อยที่สุด แต่ได้ผลลัพท์ที่ดีที่สุดกลับมาเสมอ ซึ่งถ้าเรามองย้อนกลับไปที่ซอฟต์แวร์เราจะพบว่า "สิ่งที่ซอฟต์แวร์ทำได้อาจจะมีเป็น 100 เรื่อง" แต่มันจะมี "feature ที่คนใช้บ่อยๆอยู่แค่ 20 เรื่องเท่านั้นเอง"
ดังนั้นเราเลยสามารถพูดในอีกแง่ได้ว่า โปรแกรมที่เราทำมานั้นจริงๆแล้วมีตัวสำคัญที่เป็นพระเอกแค่ 20 เรื่องเท่านั้น ที่เป็นตัวชี้วัดว่าจะอยู่รอกหรือไม่ ส่วนอีก 80 เรื่องที่เหลือ มันจะมีอยู่หรือไม่ก็ไม่มีผลอะไรเลยกับโปรแกรมของเรา ดังนั้น
"จงทุ่มเวลาให้กับงานที่เป็นหัวใจหลักจริงๆทั้ง 20 ตัวนั้นซะ เพราะมันได้ผลลัพท์กลับมาดีกว่าเราไปเสียเวลากับงาน 80 ตัวที่เสียเวลาทำเยอะกว่า แต่ได้ผลลัพท์ที่ไม่คุ้มกลับมา"
พูดให้เห็นภาพก่อนจบ Google มันทำอะไรได้บ้าง? เชื่อไหมว่าจริงๆมันทำอะไรต่อมิอะไรได้อีกเป็น 1,000+ เรื่องเลยนะ แต่คนส่วนใหญ่จะใช้มันแค่เป็นตัว search เท่านั้นเอง ซึ่งนั่นแหละคืองานหลัก 20% ของมัน ซึ่งมันได้ผลลัพท์ที่คุ้มทุน 80% กลับมา ส่วนงาน 80% ที่เหลือที่มันทำได้ เราแทบไม่ได้สนใจด้วยซ้ำว่ามัน ค้นหาแบบพิเศษได้, เป็นเครื่องคิดเลขได้, มีเกมส์ในตัวให้เล่น, พล๊อตกราฟได้, ดูหุ้นได้ และอื่นๆอีกเต็มไปหมดเลยลองไปค้นหาเอาละกัน
แอบแซวก่อนโดนจับ - ในโลกแห่งความเป็นจริงเราจะพบว่าทุกเรื่องบนโลกใบนี้
อำนาจกว่า 80% จะอยู่ในมือของกลุ่มคนแค่ 20% เท่านั้น
อำนาจ 20% ที่เหลือจะอยู่ในมือของกลุ่มคน 80%
ดุลอำนาจมันไม่เคยสมดุลมาก่อน เลยทำให้เกิด รวยกระจุก จนกระจาย นั่นเอง
🤔 อะไรคือสาเหตุหลักที่ทำให้บริษัทซอฟต์แวร์ต้องปิดตัว
ถ้าเราไปค้นหาสาเหตุที่ทำให้การทำซอฟต์แวร์โปรเจคล่ม ส่วนใหญ่ก็จะเจอเรื่อง Requirement ไม่นิ่ง, คุยงานกันไม่เคลีย, ส่งมอบงานไม่ได้, ปัญหาเรื่องเงินและเวลา บลาๆ ซึ่งเชื่อไหมว่าทุกปัญหาที่ว่ามามันชี้ไปหาเรื่องเดียวกัน ซึ่งมันเป็นจุดชี้เป็นชี้ตายของบริษัทซอฟต์แวร์เลยก็ว่าได้ (มันคือไรเดี๋ยวเฉลยตอนท้าย)
ในธุรกิจซอฟต์แวร์นั้นจะอยู่รอดหรือไม่มันขึ้นอยู่กับ "ความสามารถในการรับมือเรื่อง Maintenance" นั่นเอง เพราะต่อให้เราทำแอพที่ดีแค่ไหนให้ลูกค้าก็ตาม มันก็ต้องมีซักช่วงเวลานึงที่เราต้องกลับไปแก้ไขหรือเพิ่มความสามารถใหม่ๆเข้าไปโดยเลี่ยงไม่ได้อยู่ดี ดังนั้นมันหมายความว่า เราต้องเสียกำลังคนไปจัดการกับเรื่องพวกนั้นยังไงล่ะ โดยยิ่งเรามีโปรเจคเยอะนั่นก็หมายความว่าเราจะมีความเสี่ยงให้เกิดสภาวะ กำลังคนขาดแคลน นั่นเอง (และอย่างที่รู้ๆกันอยู่ว่า developer ที่มีฝีมือทำงานได้จริงนั้น จัดอยู่ในกลุ่มอาชีพหายากพอๆกับหมอเลยทีเดียว)
จากเรื่องที่เล่ามาสรุปสั้นๆเรื่อง สาเหตุที่แท้จริงที่ทำให้บริษัทซอฟต์แวร์ต้องปิดตัวก็คือ "การวางแผนจัดการโปรเจค" นั่นเอง แต่เรื่องนี้ไม่ได้หมายถึงการทำ SDLC เพียงอย่างเดียวนะ แต่มันหมายถึง เราต้องวางแผนรับมือกับทุกๆเรื่องเลยต่างหาก เช่น จะทำยังไงถ้าต้องเสียกำลังคนไปทำโปรเจคเมื่อปีที่แล้ว, จะทำยังไงโปรเจคนี้เขาเร่งเวลามา, จะต้องทำ feature ใหม่แต่ทีมยังไม่เคยทำเรื่องนี้เลย, ลูกค้าขอให้ส่งงานสำคัญ 2 ตัวแต่ทีมทำได้แค่ตัวเดียวเท่านั้น บลาๆ ดังนั้นจะเห็นว่า การวางแผนจัดการ มันจะช่วยมาควบคุมลดความรุนแรงต่างๆที่จะเกิดขึ้นได้ เพราะไม่อย่างนั้น ต่อให้บริษัทสามารถวิ่งไปรับงานมาได้เก่งแค่ไหนก็ตาม แต่ถ้าบริษัทไม่มีกำลังคนมาทำงานเหล่านั้นได้ หรือไม่สามารถกลับไป maintenance ตัวโปรเจคได้ มันก็จะเป็นดินพอกหางหมูที่คอยกัดกินบริษัทและกำลังใจในการทำงานของทุกฝ่ายไปเรื่อยๆครับ