Category Software Development

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

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

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

จากหัวข้อของบทความ หลายคนน่าจะสงสัยว่าทำไม “เขียน Code แล้วทำไมถึงติดหนี้ แถมมีดอกเบี้ยด้วย !!!” เดี๋ยวผมจะมาอธิบายครับ ว่าทำไมเราถึงได้สร้างหนี้ และหนี้ในการเขียน Code จริงๆ ก็ไม่เชิงนะ บอกว่าเป็นหนี้ในการพัฒนาระบบ น่าจะดีกว่าครับ โดยหนี้ที่เกิดขึ้นมี ดังนี้ครับ Acceptable – เป็นหนี้ในระยะสั้น และระยะยาวได้ประโยชน์ มองเป็นการลงทุนแนวๆ VI ได้เลยนะเนี่ย Make a trade-off to Hit a market window – ยอมลงทุน ผมไม่มองว่าเป็นหนี้นะ เพื่อให้ตามตลาดให้ทัน ในระยะสั้น อาทิ เช่น การเพิ่มการเชื่อมต่อกับ…

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.…

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 พัฒนาระบบ ระบบหนึ่ง มันมีเรื่องที่เราต้องสนใจมากมาย…

คิดให้เยอะ ลงมือทำให้น้อยที่สุด

หลายๆคนอาจจะเคยเห็นภาพนี้แล้วนะครับ มันสื่อถึงอะไร หละ ? บางคนอ่านแล้ว ก็หัวเราะเลย บางคนยังไม่ Get  จากภาพนี้ในมุมของผม ตีความถึงการมองปัญหาครับ ทุกปัญหา เราไม่สามารถใช้วิธีการเดียวกันจัดการกับมันได้ เราต้องค่อยๆลับปัญหาเปลี่ยนมุมมองบ้าง โดยในแง่ของการพัฒนา Software สิ่งที่มาขยาย ปรับ องศา มุมมองที่มีต่อปัญหา ได้แก่ Requirement(ต้องชัดเจน ใช้ได้แค่ทฤษฏีนะ แต่ในความเป็นจริงก็รู้ๆกันอยู่ 555) Skill ที่ใช้ในการวิเคราะห์ปัญหา อันนี้อาจจะต้องใช้ประสบการณ์สะสมนะครับ ว่าแต่ละปัญหาเกิดจากอะไร ตรงนี้เป็นปัญหาสำหรับ Dev ส่วนใหญ่ที่ผมเจอมาเลย คือ เขียนโปรแกรมได้ แต่พอโปรแกรมผิิดขึ้นมา ยังไม่สามารถวิเคราะห์จุดที่ผิดได้ครับ (ตามรูปด้านบนที่ผมเอามาอ้างเลย) ความเข้าใจของคนกลุ่มต่างๆ ต่อชิ้นงานที่ทำ ตั้งแต่ User…

Shallow Copy กับ Deep Copy มีประโยชน์อย่างไรบ้าง

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