Continuous integration คือ อะไร

เรื่องนี้ไม่ใช่เรื่องใหม่ครับ แต่ผมลอง search google ด้วย ประโยคเหมือนชื่อโพสแล้วไม่มีผลลัพธ์ดีๆ ภาษาไทยใน 2 หน้าแรกเลย ก็เลยมาเขียนให้อ่านกัน

เนื้อหาในโพสนี้ เขียนจากประสบการณ์ส่วนตัว ประกอบกับ แปลและสรุปจาก Continuous Integration ครับ

ใครอ่านตรงไหนไม่รู้เรื่องแล้วอยากให้อธิบายเพิ่มเติมก็ถามมาได้นะครับ

ปัญหา

1. การ merge code ระหว่าง dev ยาก ใช้เวลานาน
2. Dev พัฒนาอยู่บน code ส่วนที่ถูกคนอื่นลบหรือเลิกใช้ไปแล้ว
3. Dev ไม่กล้าแก้ code มากนัก เพราะกลัวจะกระทบคนอื่นและกลัว bug ส่งผลให้ code เน่าง่าย
4. เมื่อมีคนมาถามถึงความเสถียรของโปรแกรม ตอบได้แค่ว่า “น่าจะใช้งานได้”
5. ผลจากความผิดพลาดของการ merge ถูกพบเมื่อ code ขึ้นไปอยู่บน production แล้ว
6. Code บน dev environment ไม่สามารถ deploy บน production environment ได้ หรือได้แต่ใช้เวลานาน
7. Regression test ใช้เวลานาน และนานขึ้นเรื่อยๆ ตามความแก่ของโปรเจ็ค
8. Management รู้ความก้าวหน้าของโปรเจ็คได้แค่จากปากคำของ Dev
9. เมื่อเจอ bug ในระบบเวอร์ชั่นเก่ากว่าที่พัฒนาอยู่ ใช้เวลา setup เครื่องเพื่อทดสอบ bug นาน

วิธีแก้ไข

0. Dev ทุกคนเขียน unit test และมี acceptance test คลุมฟังก์ชัน

1. ทำงานชิ้นเล็กๆ merge บ่อยๆ ทำเสร็จชิ้นนึง merge ทันที 
2. พัฒนาบน branch เดียวกันทุกคนในโปรเจ็ค
3. ตรวจสอบว่า test รันผ่านก่อน commit/push ขึ้น repository กลาง
4. มีระบบ automate สำหรับดึง source code มา build , นำลงเครื่องที่เหมือนเครื่อง production ที่สุด และรัน test ใหม่อีกรอบ ทุกครั้งที่ source code มีการเปลี่ยนแปลง แจ้งผลลัพธ์อย่างชัดเจน ทันที
5. ทำ versioning ไฟล์ build 
6. แก้ test ที่พังอย่างรวดเร็ว ให้ความสำคัญการแก้ test ที่พังเป็นอันดับต้นๆ

ผลลัพธ์

1. merge code กันเครียดน้อยลง
2. ได้ code ที่พร้อมใช้งานตลอดเวลา regression test time เข้าใกล้ 0
3. ไม่เสียแรงเปล่าไปทำงานบนส่วนที่เลิกใช้ไปแล้ว
4. ได้ code ที่ไม่มี bug ที่เคยแก้ไปแล้วเกิดซ้ำ
5. พบ bug ได้เร็วขึ้น ทำให้หาสาเหตุได้ง่ายขึ้น
6. Dev กล้าที่จะ refactor code มาขึ้น
7. โปรแกรม version ใหม่ๆ ออกเร็วขึ้น
8. ไม่ต้องมาเครียดในการ deploy ขึ้น production โดยเฉพาะอย่างยิ่งวันท้ายๆ กำหนด release
9. Dev เครียดน้อยลง รู้สึกว่าทำงานแล้ว “เสร็จ” จริงๆ
10. Management เห็นความก้าวหน้าการทำงานของ dev ในแต่ละวันด้วยผลลัพธ์การ test ที่เพิ่มขึ้นทุกวันๆ
11. สามารถ build ระบบขึ้นจาก version ใดก็ได้อย่างรวดเร็ว

สิ่งที่จำเป็น

1. วินัยของ Dev
2. การตัดแบ่งงานเป็นชิ้นเล็กๆ ต้องใช้ความสามารถในด้านการเขียนโปรแกรมให้เป็น modular และ refactoring
3. เทคนิคการเขียน test ทำให้เทสได้เร็ว ครอบคลุม
4. การทำระบบ build ให้ทำงานได้อย่างรวดเร็ว

เพิ่มเติม

บางบริษัทไปไกลถึงขั้นหลังจาก build และ test แล้ว นำขึ้น deploy บน production เลย ตามอ่านได้จาก keyword Continuous Deployment, Continuous Delivery ครับ

ของแถม

Tools for Continuous Integration at Google Scale ด้านเทคนิคเค้าไปไกลกว่าที่ผมเขียนมามากครับ

คนดี?

จาก โพส Facebook ที่ได้รับความนิยมอย่างสูง (สูงแล้วจริงๆนะ) ของผม (ขอบคุณอรุชที่ช่วยแก้คำผิด)

คนที่น้อยใจว่า เพราะคนเราชอบมองคนแต่ที่หน้าตา ไม่มองที่จิตใจ จึงไม่มีใครมาสนใจ เค้ารู้ได้ไงว่าจิตใจเค้าดีกว่าคนอื่น

ขอนำมาขยายความหน่อย

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

เมื่อเราไม่เข้าใจถึงที่มาของมัน ปัญหาจึงเกิดขึ้น เพราะคนเราทุกคนต่างประพฤติตัวเป็นคนดีในมุมมองของตัวเองเสมอ แม้ว่าบางครั้งปากเราจะบอกว่าสิ่งที่เราทำมันไม่ดี แต่ถ้าเราตัดสินใจทำแสดงว่าใจเราบอกว่ามันดี

เราไม่ผิดที่เราจะพูดว่าคนนั้นดี คนนั้นเลว จากความรู้สึกของเรา เพราะทุกคนก็ทำแบบนี้ แต่คนที่ไม่เห็นด้วยกับเราก็ไม่ผิดเช่นกัน ความขัดแย้งก็มีสาเหตุแค่จากความชอบไม่ตรงกัน

และก็ไม่แปลกที่การเป็นคนดีทำให้เราไม่สมหวังในความรัก เพราะการเป็นคนดี คือ การทำให้ตัวเราชอบ ไม่ได้ทำให้คนอื่นชอบซักหน่อย

จงเป็นคนที่เค้าชอบ ไม่ใช่เป็นคนดี หรือหา/รอคนที่ชอบในสิ่งเดียวกัน ครับ

Making CHANGE possible

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

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

mindset เรื่องการยอมรับความเปลี่ยนแปลง เป็นเรื่องที่ผมรู้สึกว่า ขาด อยู่ในโลกการพัฒนา software ในปัจจุบัน เป็นสาเหตุสำคัญที่ทำให้ชีวิตนักพัฒนา software มัน เศร้า กันอย่างที่เป็นอยู่

ผมจะบอกคุณว่า ถ้าคุณมี mindset เรื่องยอมรับการเปลี่ยนแปลง ชีวิตการพัฒนา software ของคุณจะไม่เหมือนเดิมอีกต่อไป

ผมจะยกตัวอย่างวงจรอุบาตนึงให้ฟัง

กลัวการเปลี่ยนแปลง -> Design อย่างละเอียด จะได้ไม่ต้องแก้ -> ลงมือ code -> งานเสร็จ ไปส่วนหนึ่ง -> แก้ เพราะมี requirement เพิ่ม, design ผิด ทำไม่ได้จริง -> เหนื่อย, เปลืองพลังงาน, เปลืองเวลา(ทั้งตอน design และตอนแก้), งานเลท -> ไม่อยากแก้แล้ว -> กลัวการเปลี่ยนแปลง -> …

ถ้าเราเปลี่ยนความคิดมาตีซี้กับความเปลี่ยนแปลง ทำให้มันเป็นเพื่อนของเรา จะเกิดวงจรใหม่ขึ้น

ชอบการเปลี่ยนแปลง -> Design น้อยๆ พอที่จำเป็น -> ลงมือ code พร้อมเขียน test -> แก้เพราะมี requirement เพิ่ม, ทำเพิ่ม -> test พัง -> แก้ code และแก้ test -> รัน test ผ่านหมด นอนหลับฝันดี -> ชอบการเปลี่ยนแปลง -> …

เรื่องนี้มีประเด็นหนึ่งที่น่าสนใจ คือ ยิ่งคุณเป็นคนที่ design เก่งเท่าไหร่ คุณจะยิ่งเกลียดความเปลี่ยนแปลงเท่านั้น เพราะคุณจะเจอความเปลี่ยนแปลงน้อยกว่าคนอื่น แต่เมื่อมันมาถึงทุกอย่างจะเป็นเรื่องใหญ่โต และคุณจะโทษ design ของคุณ หรือโทษความเปลี่ยนแปลง ที่ทำให้ชีวิตคุณมีปัญหา ความจริงแล้ว ไม่ใช่เลย ความเปลี่ยนแปลง เป็นเรื่องธรรมชาติ ถ้าใครนับถือศาสนาพุทธคงทราบดี เราต้องยอมรับว่ามันมีจริง และหาทางรับมือกับมัน ไม่ใช่พยายามหลีกเลี่ยง

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

คุณรู้หรือไม่ว่าการ design ที่มากเกินไป อาจจะหยุดยั้ง innovation ในโปรเจ็คของคุณ!!! 

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

• ความรู้ในเรื่อง design, abstraction และเทคนิคการเขียน code เพื่อให้เกิดสิ่งเหล่านี้ คุณไม่ควร design เป็นจำนวนมากในครั้งเดียว แต่คุณต้องรู้ว่า design ที่ดีเป็นอย่างไร เพื่อที่คุณจะได้ evolve software ของคุณไปได้ถูกทาง
• Incremental dev & just enough design ทำทีละส่วนเล็กๆ ให้สำเร็จขึ้นมา คิดในส่วนที่กำลังจะทำให้มากๆ ส่วนที่ยังไม่ทำ ไม่ต้องคิด ไม่ต้องทำเผื่อ เพราะเมื่อถึงวันที่เราจะทำทุกอย่างมันเปลี่ยนไปแล้ว ไว้ค่อยมาคิดกันใหม่
• test & refactoring หลังจากที่คุณทำที่ละส่วนเล็กๆ แล้ว เมื่อคุณจะทำเพิ่ม แน่นอนคุณต้องแก้ของเก่า เพราะคุณไม่ได้คิดเผื่อไว้ คุณต้องมี test เพื่อตรวจจับของเก่าที่พัง และ refactor code หลังจากที่ทำเสร็จ เพื่อให้มันคงความแก้ง่าย เอาไว้
• clean code ทำให้คุณและเพื่อนร่วมทีมแก้ code ได้ง่ายขึ้น

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

ปล. จริงๆ แล้วเรื่องนี้มันคือ เรื่องเดียวกับ pull system ที่ผมเคยเขียนไป แต่แค่เป็นคนละมุมมองเท่านั้นเองแหละครับ

Intro to fun automate testing

เชื่อว่าทุกคนคงมีความเห็นตรงกัน ว่าการที่โปรแกรมที่เขียนขึ้น จะมีคุณภาพได้นั้น จะต้องผ่านการ test

แต่ test มันมีต้นทุน การจะเขียน test มันต้องลงทุนลงแรง เหนื่อยมากขึ้น เปลืองเวลามากขึ้น จะทำไงดี จะไม่ test ก็คงไม่ได้ (เอ๊ะ หรือว่าได้ อันนี้แล้วแต่มุมมองนะครับ)

สิ่งที่เราพอจะทำได้คือ ทำให้ test มัน สนุกขึ้น เหนื่อยน้อยลง ใช้พลังงานและทรัพยากรน้อยลงในการดูแลมัน

จากข้อต่างๆ ที่กล่าวมานั้นหลีกเลี่ยงไม่ได้ที่เราจะต้องทำการ test แบบ automate ไม่อย่างนั้นคิดง่ายๆ test มือ ซ้ำๆ ที่เดิม 2 รอบก็ไม่สนุกแล้ว

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

1. ต้องเขียนง่าย
2. ต้องแก้ง่าย
3. ต้องสั้น
4. ต้องอ่านรู้เรื่อง
5. ต้องรันง่าย
6. ต้องรันได้เร็ว
7. ต้องพังในจังหวะที่ควรจะพัง

โดย concept นึงที่ เป็นส่วนหนึ่งที่ทำให้เกิดข้อ 1,2,3,4,6,7 ได้ คือ เรื่อง testability

ลิงค์ต่อไปนี้ คือ ส่วนหนึ่งที่ผมใช้ศึกษาเรื่องนี้

youtube , pdf , youtube2 , youtube3

Concept หลักๆเลย คือ ต้องทำให้เราสามารถ test เฉพาะส่วนที่ต้องการเป็นส่วนๆได้ โดยไม่ต้องไปผูกพันธ์ test ส่วนอื่นไปด้วย จาก link ด้านบน ดึงออกมาเป็น guideline ดังนี้

1. ใน code ส่วนสร้าง object ใดๆ จะต้องไม่มีโลจิค เพราะว่า ไม่อย่างนั้นในทุกการทดสอบแปลว่าเรา ทดสอบ code ส่วนนั้นด้วยเสมอ ถ้า code ส่วนนั้นพัง test พังหมด ถ้า​ code ส่วนนั้นช้า test ช้าหมด
2. ใน code ไม่ควรมีการสร้าง object อื่นปะปนอยู่กับโลจิค เพราะว่า เราต้องควบคุมสภาพแวดล้อมรอบ code กลุ่มที่เราจะ test และลดการ test ซ้ำซ้อน ในบางครั้งเราจึงต้องมีการเปลี่ยน object อื่นๆที่เกี่ยวข้องไปอยู่ในสภาพที่เราควบคุมให้มัน return ผลลัพธ์ตามที่ต้องการ, ทำงานได้เร็วขึ้น ตามอ่านได้ที่ Test Double
3. ใน code จะต้องไม่มีส่วนที่เรียกใช้งาน ไลบรารี global ที่เมื่อเรียกแต่ละครั้งอาจได้ค่ากลับคืนไม่เท่ากัน (Global State) โดยตรง เช่น เวลา, ส่ง e-mail, database สิ่งเหล่านี้มีผลต่อการ test ของเรา เช่น ระบบที่รันเดือนละครั้ง, ส่ง e-mail ทุกคร้ังที่ test, database access ช้า สิ่งเหล่านี้ต้องถูกกำจัดออกไปด้วย Test Double เช่นกัน
4. ใน code ต้องไม่มีการเรียก property ของ object ที่เกี่ยวภายใน (Violate laws of demeter) เพราะไม่เช่นนั้น เวลาจะเขียน test ทีต้อง setup ยาวมาก
5. code ส่วนที่ test ต้องไม่ทำอะไรมากเกินไป ไม่อย่างงั้น test จะพังง่าย และอ่านเข้าใจยาก เนื่องจากต้อง test หลายเรื่อง อาจจะทำให้ไม่ชัดเจนว่าจะ test เรื่องใด

ถ้าอยากจะทำสิ่งเหล่านี้ได้โดยอัตโนมัติ ลองศึกษาการทำ TDD แบบถูกวิธีดูครับ มีโพสที่เคยเขียนเรื่อง TDD ไว้หน่อย อันนี้

 

สิ่งที่เขียนมาข้างต้นมีผลกระทบโดยตรงกับภาษาที่เป็น static และ strong typing

สำหรับภาษา dynamic typing บางภาษา ความสามารถในการเปิด class/function ออกมาแก้ไขได้ ทำให้สามารถสร้างสภาพแวดล้อมที่เหมาะสมกับการ test ถึงแม้จะมีการละเมิดข้อด้านบนก็ตาม

ด้านภาษา functional language จะกังวลเรื่องเหล่านี้น้อยหน่อย เพราะเขียนให้ละเมิดสิ่งด้านบนได้ยาก

 

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

 

เขียนไปเขียนมา รู้สึกว่า organize ไม่ดีเลย และมีรายละเอียดที่ข้ามไปอีกเยอะมาก ไว้นานๆไป มีแรง จะกลับมาเขียนใหม่ลึกๆ แบ่งแยกดีๆ แล้วกันครับ

Happy testing สวัสดีครับ

บาร์แคมป์ สิงคโปร์ 7

ตามคำเรียกร้อง ไปงานกลับมาแล้ว จะมาเล่าให้ฟังกัน

วันนี้ตื่นสายนิดหน่อย และไปถึงงานหลังจากเค้าจบ session แรกไปแล้ว เพราะสถานที่ค่อนข้างไกลจากที่พักมาก North-east กับ South-west

มี schedule ให้ดูตามนี้

ตอนไปเกือบจะถึง เปิดดู schedule สงสัยว่านี่จะไม่ใช่งานของเรา เพราะมีแต่ topic management, startup ทั้งนั้นเลย เลย tweet บนนิดหน่อย

รูปนี้ไม่เกี่ยวกับงาน เห็นตึกที่กำลังก่อสร้างอยู่ตรงข้ามป้ายรถบัส เสาเฉียงๆ แปลกดี

 

ไปถึงงานไม่มีป้ายชื่อ มีแต่สติกเกอร์ขาวพร้อมปากกา ให้เขียนชื่อแล้วเอามาแป๊ะเสื้อเอาเอง

Topic ก็เขียนกันบนกระดาน vote กันบนกระดานนั้นเลย

 

อย่างที่บอกไปแล้ว ว่า topic มีแต่เรื่อง การลงทุน, startup, pitch สิ่งทีทำ จริงเข้าใจว่ามี dev ไปพอสมควร แต่เจอ topic แบบนี้ คงคิดว่าไม่มีคนฟังเลยไม่มีใครกล้าพูดอะไร คิดว่า dev คงจะเบื่อๆ กัน และครั้งต่อไป dev น่าจะน้อยลงเรื่อยๆ เพราะมันไม่หนุก

ลองคาดเดาสาเหตุ น่าจะเกิดจาก พวกคน management, founder, sale เป็นคนพูดเก่ง และอยากพูด อาจจะเพื่อผลประโยชน์ส่วนตัวหรืออะไรก็แล้วแต่ แต่ความยากพูดและความสามารถในการพูดเค้าสูงกว่าพวก dev แน่ๆ เหตุการณ์จึงออกมาเป็นแบบนี้

ลองไปดูแต่ละ session ที่ผม ได้เข้าไปฟังบ้าง ไม่ฟังบ้าง รู้เรื่องไม่รู้เรื่องบ้าง ละกัน

session นี้เข้าใจว่าเป็นคนจัด startup training

 

Lighting talk คนนี้เป็นคน organize BarCamp ที่พม่า

 

พักเที่ยงนั่งกินข้าวโรงอาหารเล็กๆ ใกล้ๆ มีคนสองคนมาขอนั่งด้วย เป็น investor ทั้งสองคนเลย คนนึงเป็นคน Texas อีกคนเป็นคนมาเล คนมาเลถามว่ามีเพื่อนที่กำลังจะทำ startup ที่ไทยมั้ย ใครมีไอเดีย ต้องการเงิน อยากได้ contact ก็ถามมาก็ได้ เค้าให้นามบัตรไว้

 

คนนี้พูดถึงแนวทางการทำ startup เช่น เราต้องชั่งน้ำหนักระหว่าง feedback และ strategic plan ที่วางไว้ตอนเริ่ม, หรือการ focus ในส่วนเล็กๆ ในตอนเริ่มต้น ตัวเค้าเองทำ startup web infrastructure เริ่มปี 03 เจ๊งปี 08 ช่วงนี้อยู่ในช่วงกลับมาและดีขึ้นเรื่อยๆ

 

คนนี้พูดเรื่อง technical หน่อย แต่ไม่อยู่เรื่องนี้เลย เลยอยู่ไม่จบ เค้าพูดเรื่อง การเลือก CDN แล้วก็เห็น ถกๆ กับคนฟังเรื่อง Amazon Cloudfront กับ S3 บลา บลา

 

คนนี้ประทับใจเป็นพิเศษ ถึงแม้ว่าจะไม่ใช่เรื่อง tech เรื่องของเค้าคือ Investing in Death คือ เค้าเป็นเหมือนพ่อค้าคนกลาง คอนโดฝังศพที่ Hongkong สองปีที่่ผ่านมา ได้ return 100%

 

คนนี้พูดเรื่อง Mobile App design ก็ไม่มีอะไรแปลกใหม่ เค้าย้ำๆ ว่าให้ทำ cycle prototype-feedback ให้ดีๆ ก่อนเริ่ม code อันนี้เห็นด้วยแค่บางส่วน คือ คิดว่ามันต้องเป็นทั้ง life cycle ช่วงอื่นก็สำคัญไม่แพ้ช่วง prototype ที่เค้าย้ำๆๆ

 

คนสุดท้ายที่ฟัง เห็นหัวข้อน่าสนใจ Web framework สำหรับเด็ก 6 ขวบ ไอ่เราก็คิดว่าเค้าทำ web framework ให้เด็ก 6 ขวบ เหมือนที่ community Haskell ตอนนี้กำลังพูดถึงสอนเด็กโปรแกรมด้วย Haskell กันอยู่ แต่ที่ไหนได้ เป็นการมาเล่าว่าเขียนเว็บง่ายนิดเดียว อะไรทำนองน้ั้น พอเค้าเริ่ม Scaffolding Rails ก็เลยลุกออกมา

 

ออกจาก session นั้นมาก็ออกจากงานเลยประมาณ 4 โมง

งานนี้ เป็นสวรรค์สำหรับคนมีไอเดีย มีความสามารถ ที่กำลังจะเปิดบริษัทโดยแท้ จะได้หาผู้ลงทุน และประสบการณ์จาก startup อื่นๆ

มางานนี้ยิ่งตอกย้ำความเข้าใจเกี่ยวกับประเทศนี้ว่า เป็นประเทศพ่อค้าและผู้ลงทุนอย่างแท้จริง เราว่าประเทศเราขาดบุคลากรแค่ไหน ประเทศเค้าความต้องการสูงกว่าแน่นอน เพราะมี investor ชาวต่างชาติเข้ามาผสมโรงด้วยเยอะ สังเกตดูจาก topic จะมี topic นึง ถามว่าจะทำ startup จะ in-house หรือ outsource ดี ส่วนตัวเพิ่งเคยได้ยิน outsource startup ครั้งแรกก็ที่นี่แหละ

สรุปไม่เสียหายกับการได้ไปดูบรรยากาศ แต่คราวหน้า ขอคิดก่อนละกัน

่ตอบแทนเวลา

ถ้าหากเวลาเป็นมนุษย์ คงเป็นดังมนุษย์ผู้ให้
เป็นผู้ให้ที่มีผู้รับผู้ไม่เคยพอใจในสิ่งที่ให้

“ไม่มีเวลา”, “เวลาไม่พอ” เป็นคำที่เราได้ยินอยู่อย่างเป็นประจำ
แต่ลองย้อนคิดดูว่ามีอะไรบนโลกที่ให้คุณได้ดังเช่นเวลา
มันยังทำหน้าที่อย่างสม่ำเสมอ ไม่ขาดตกบกพร่อง
และไม่เคยได้รับสิ่งใดตอบแทน

เมื่อเราให้อะไรกับใคร
สิ่งที่เราหวังคือ ให้ผู้รับใช้มัน และได้ความสุขจากสิ่งที่เราให้

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

Framework คือ

MVC คือ หนึ่งใน design pattern ที่ programming framework ใช้กันมากที่สุดในโลก

ผมมีคำถามว่า MVC มีประโยชน์อย่างไร (ห้ามไป google นะครับ)

.

.

.

.

.

ตอนที่ผมถามคำถามนี้กับตัวเอง คำตอบแรกในใจของผม คือ loosely coupling ระหว่าง M, V และ C เพื่อประโยชน์ในการถอดเปลี่ยน หรือทำ unit test

แต่วันนี้ คำตอบคำถามนี้ของผม จากเพื่อนร่วมงานคนหนึ่งคือ “เพื่อจะได้แยก code ออกตามการทำงาน และทำให้ดูง่าย” 

อื้มมม ก็ถูก

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

คำตอบในใจก็บอกว่า ใช่

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

ผมเลยคิดว่า จริงๆ แล้ว programmer มีความต้องการที่จะทำในสิ่งที่ดีๆ (เช่น การจัด code ให้เป็นระเบียบ) อยู่แล้ว เพียงแต่ว่า บางครั้งมันเข้าใจยาก มันเสียเวลา ฯลฯ การที่มีสิ่งที่มาแนะนำสิ่งที่ควรทำ พร้อมมี guideline ที่เข้าใจง่าย และปฏิบัติตามง่าย จึงน่าจะเป็นสาเหตุที่ทำให้ MVC แทบจะกลายเป็น defacto standard ของ web development ในยุคที่ผ่านมาจนถึงปัจจุบัน

 

และจากเรื่องนี้ทำให้ผมเข้าใจ คำว่า framework ที่แปลเป็นภาษาไทยว่า “กรอบวิธี” ในมุมที่ผมไม่เคยเข้าใจมาก่อน

ก่อนหน้านี้ผมเข้าใจเพียงว่า framework คือ การนำ library/tool/utility ที่เกี่ยวๆข้องกันในเรื่องหนึ่งๆ หลายๆ อันมารวมกัน เพื่อช่วยในงานทำสิ่งใดสิ่งหนึ่ง มาโดยตลอด โดยบางครั้งอาจจะต้องทำตาม step บางอย่าง เพื่อให้มันทำงานได้ เลยคิดว่านี่หละมั้ง “กรอบ”

เป็นผลให้ผมไม่เคยเข้าใจ ในเวลาผมได้ยินคำว่า framework จากสาขาอื่นๆ เพราะมันไม่เห็นดูเป็น library/tool/utility ตรงไหน มันกลับกลายเป็นวิธีที่บอกให้เราทำตาม อย่างโน้น อย่างนี้ เป็นขั้นๆ โดยมุ่งหวังให้ประสบความสำเร็จในสิ่งหนึ่งๆ ยกตัวอย่างเช่น framework ในวิชา SE หรือ framework ในพวก management

 

สรุป เราสามารถสร้าง programming framework ที่มีประโยชน์ได้ ด้วย framework นี้ (ขำๆ อย่าจริงจังมากนะครับ)

1. มองหาส่วนใดใน code ที่ควรจะทำ แต่โปรแกรมเมอร์ส่วนใหญ่ละเลย
2. ทำการเขียน code ที่เป็น guideline ในส่วนนั้น
3. ตั้งชื่อ
4. เตรียมคำอธิบายวิธีการทำตาม ที่เข้าใจง่าย
5. เผยแพร่