Category Software Development

สายไฟที่ยุ่งเยิงกับซอฟต์แวร์ที่สับสน

ระหว่างทางไปทำงาน กลับบ้าน วิวรอบทางของมนุษญ์เงินเดือนในเมืองใหญ่ คงไม่พ้นกับสายไฟ สายโทรศัพท์ ดูๆไปแล้ว มันโคตรจะยุ่งเหยิง บดบังทศนีย์ภาพ แล้วถ้าเราเอาภาพของสายไฟ มาเปรียบกับ Software บ้างหละ สิ่งที่เราทำอยู่มันเป็นอย่างไร เริ่มที่ภาพแรกเลยและกัน ชุมสาย ชุม Code >> ยำ Code >> Spaghetti code ถ้ามี Change หละ คนแก้คงทำใจ ก่อนแก้ Code และจะต้องคิดหนัก ว่าแก้อย่างไร ไม่ให้กระทบ Code คนอื่น (สายไฟ สายโทรศัพท์ของเจ้าอื่นๆ) เปลืองสาย อันนี้ไม่แน่ใจว่า มีการขดสายไฟพันไว้ทำไม !!! แต่มุมของผมเดินผ่านมา…

วันแรงงาน เมื่อโปรแกรมเมอร์ เป็นตัวละครในสื่อโฆษณา

วันนี้ระหว่างปั่นงานระบบ ฺBOT DMS ในวันแรงงาน ก็แว๊บไปเปิด youtube เพื่อฟังเพลง แลวบังเอิญเจอโฆษณาอันนี้ มันเป็นโฆษณาที่ผมต้องดูจนจบ เพราะ มันมีวลีนึงโผล่ขึ้นมา “แล้วเราจะเขียนโปรแกรมอย่างไร !!!” เจ้าโฆษณาตัวนี้เราจะได้เห็น ญาญ่า มาเขียน Code น่ารักด้วยยยย เข้าเรื่องดีกว่า พระเอก (หมาก) เป็นนักพัฒนาแอปพลิเคชั่น ถ้าภาษาบ้านๆทั่วไป คือ โปรแกรมเมอร์ ได้มี idea ที่จะนำอาหารเหลือที่ต้องทิ้ง ในแต่ละวัน มาสร้างประโยชน์ สร้างมูลค่าขึ้นมา ที่นี้คนในทีมมีประเด็นขึ้นมาว่า “อาหารเหลือเนี่ยนะ จะสร้างมูลค่ามหาศาล” “แล้วเราจะเขียนโปรแกรมอย่างไร !!!” แต่ก็มีแง่คิดที่ดีเหมือนกัน “Idea ดีๆบนโลกนี้ เริ่มมาจากคำว่าเป็นไปไม่ได้ทั้งนั้นแหละ” จากนั้นพระเอกก็ไปนั่นคิด นอนคิด…

Technical Debt เขียน Code แล้วทำไมถึงติดหนี้ แถมมีดอกเบี้ยด้วย !!!

จากหัวข้อของบทความ หลายคนน่าจะสงสัยว่าทำไม “เขียน Code แล้วทำไมถึงติดหนี้ แถมมีดอกเบี้ยด้วย !!!” เดี๋ยวผมจะมาอธิบายครับ ว่าทำไมเราถึงได้สร้างหนี้ และหนี้ในการเขียน Code จริงๆ ก็ไม่เชิงนะ บอกว่าเป็นหนี้ในการพัฒนาระบบ น่าจะดีกว่าครับ โดยหนี้ที่เกิดขึ้นมี ดังนี้ครับ Acceptable – เป็นหนี้ในระยะสั้น และระยะยาวได้ประโยชน์ มองเป็นการลงทุนแนวๆ VI ได้เลยนะเนี่ย Unavoidable – หนี้ที่เกิดจากสถานการณ์ที่เราไม่สามารถคาดเดาได้ Unnecessary – หนี้ที่เกิดแล้วทำให้ระบบงานเรารอดมีงานส่งได้ หนี้ที่เกิดแล้วทำให้ระบบงานเรารอดมีงานส่งได้ แต่ไม่มีประโยชน์ให้แก่ทีมงาน หรือองค์กรเลย Bad – หนี้แบบซุกไว้ใต้พรม หนี้แบบนี้ ถ้าเกิดแล้วระบบงานของเราคงจะรอดยาก หรือขึ้น Production…

Proudly-Found-Elsewhere Syndrome

  Proudly-Found-Elsewhere Syndrome (PFE Syndrome) หรือ Invent Syndrome ความหมายของมันแตกต่างกับตัว Not-Invented-here Syndrome อย่างสิ้นเชิงเลยครับ คือ มีการสร้างงาน หรือ นวัตกรรมใหม่ขึ้นมาครับ สำหรับในมุมของ Software Development เป็นการนำ Library ที่ Common มาใช้งานเสริมได้ เวลาที่เหลือเราก็เอาไปใส่ใจกับส่วนของ Core Business มากขึ้นได้ครับ ส่วน PFE Syndrome คำแนะนำของผม คือ ต้องเปิดใจ พร้อมที่จะเรียนรู้ และคำนึงถึงความสมเหตุสมผลที่เลือกใช้ เพราะ มันไม่ได้มีวิธีการตายตัวที่ตอบโจทย์กับปัญหาต่างๆครับ และก็ท้ายที่สุด ผมมีบทความแนะนำครับ From not invented here…

Not-Invented-Here Syndrome

Not-Invented-Here Syndrome

Not-Invented-Here Syndrome หลายคนอาจจะงง ว่า Blog นี้มันสาย IT นี่หว่า แต่แล้วทำไมมาเขียนแนวคุณหมอซะหละ สำหรับเจ้า Not-Invented-Here Syndrome หรือ NIT Syndrome คือ การยึดติดกับสิ่งเดิม ระบบความเชื่อความคิดของตนเองเป็นหลัก มักจะพบในหน่วยงาน หรือองค์กรที่มีอายุยาวนาน และประสบความสำเร็จมากมายครับ ซึ่งเจ้าตัว Not-Invented-Here Syndrome มันเป็นตัวขัดขวางสิ่งที่เรียกว่า นวัตกรรม หรือ Innovation นั้นเองครับ โดยเจ้า NIT Syndrome มีส่วนที่ต่างๆ ที่บ่งบอกว่า หน่วยงาน หรือองค์กร กำลังจะเป็น ดังนี้ครับ แต่เจ้า NIT Syndrome มันก็ไม่ได้ร้ายเสมอไปนะครับ บางครับมันมีเหตุผลที่จำเป็นเหมือนกันนะครับ เช่น โมดูลนี้มันเป็น Core…

ความแตกต่างของ Unit Test และ Integration Test

Unit Test คือ การทดสอบ Code ในส่วนที่เล็กที่สุดของ Developer เพื่อทดสอบว่าสิ่งที่เขียนมามันใช้ได้จริงนะ และมี Test ตามที่ผู้พัฒนาเห็นว่ามันสำคัญ (พยายามทำให้ได้เยอะที่สุดครับ) Test ควรทำได้ง่าย เขียนสั้น และกระชับ เพราะกลุ่มคนหลักๆที่ใช้ คือ ตัว Developer เองครับ สิ่งที่เป็นหัวใจหลักของ Unit Test คือ ทำให้มันอยู่ได้ด้วยตัวมันเอง ไม่มี Dependency ไปยุ่งกับ Code ตัวอื่นๆ ถ้าจำเป็นต้องใช้จริงๆ ให้ Mock มันเข้ามาให้หมด เพราะจุดประสงค์ของ Unit Test ดูเฉพาะ Logic การทำงานในส่วนที่เราสนใจจริงๆ…

Code Mania 11: Raise the Bar

เมื่อวันเสาร์ที่แล้ว ผมได้ไปงาน Code Mania 11 โดยมีเรื่องน่าสนใจ ดังนี้ Session ตอนเช้า – Wongnai Engineering Story ในช่วงนี้เป็นการเล่าถึงการจัดการด้าน Infrastructure ของ Wongnai ว่าตั้งแต่เริ่มต้นจาก Mac เพียง 1 เครื่องทีตั้งไว้ที่ CAT จนมีปัญหาที่ละ เรื่อง และทำให้ย้ายไปใช้ Cloud ในแต่ละชั้น ดังนี้ครับ 1. ระบบเมล์ 2. App Server 3. อีกส่วนเป็นปัญหาของ DB ที่ใช้ MySQL ซึ่งก็รู้ๆกันอยู่ว่า 4.…

การจัดการเมื่อต้อง Query กับฐานข้อมูลที่ขนาดใหญ่

บางครั้งเรามี Query ที่ Join Table เยอะๆ และมีผลลัพธ์มหาศาลประมาณหลายแสนรายการครับ เราอาจจะมีการปรับจูน DB เช่น ทำ Index หรือทำ Query Cache เป็นต้น แต่ในมุมของ Dev เราสามารถปรับโปรแกรมได้เหมือนกัน โดยปรับ Query จากเดิมที่ Join กับหลายๆ Table มา Query ตรงๆที่ละ Table แล้วนำข้อมูลมา Process ใน App แทนครับ

UAT Test Script ควรทำขึ้นมาจากอะไร

หลังจากที่ได้ไปงาน CodeMania 11 ได้ไปฟัง Session ของพี่รูฟนะครับ ในหัวข้อ ATDD (Acceptance Test Driven Development) ครับ จากแนวคิด Zero Defect ก่อนเข้าเรื่องมาอารัมภบทกันก่อน เกิดจากความเข้าใจของ User, BA, SA และ DEV มีความเข้าใจที่ไม่ตรงกัน Zero Defect มันบอกตรงตัวอยู่แล้วว่า ข้อผิดพลาดทุกอย่างเป็นศูนย์ แล้วมันทำได้อย่างไร ? สำหรับบางที่อาจจะเกิดปัญหาว่า User ไม่เข้าใจกระบวนการพัฒนาระบบ เราอาจจะต้องมีการ Guide ด้วยนะครับ ไม่งั้นความต้องการจะบิดเบี้ยวไปหมด

[AOP] Aspect Oriented Programming

พอดีได้รื้อพื้นความรู้เก่าๆ และก็เจอเรื่องน่าสนใจมาเขียน blog พอดีเลย เข้าเรื่องกันเลยดีกว่า AOP เนี่ย หรือ ชื่อทางการของมัน คือ Aspect Oriented Programming โดยเจ้า AOP เป็นแนวคิดนึง ที่เป็น Guideline ที่ช้วยในการพัฒนาระบบครับ เหมือนกับ OOP ที่มองทุกอย่างเป็น Object ครับ !!! AOP ไม่ได้มาแทนที่ OOP นะครับ !!! หลายคนที่อ่านมาถงตรงนี้อาจจะงงกัน มองง่ายๆว่าเป็นส่วนเสริมของ OOP ครับ เพราะ OOP เนี่ย ถ้าเรานำมา Implement พัฒนาระบบ ระบบหนึ่ง มันมีเรื่องที่เราต้องสนใจมากมาย…