cc :: somkiat

สิ่งที่น่าสนใจในการพัฒนา software คือ เราทำการเตรียม environment ต่าง ๆ เช่น ทั้ง Dev, Test/QA, UAT, Staging, Pre-Prod และ Prod กันตอนไหน ? ที่สำคัญคือ แต่ละ environment นั้นเหมือนหรือต่างกัน ? ซึ่งสิ่งต่าง ๆ เหล่านี้มันสะท้อนความสัมพันธ์ระหว่าง Development team และ Pre/Production team ว่าเป็นอย่างไร ?

ผลที่เกิดขึ้นมาคือ feedback loop ที่จะได้รับ รวมทั้งการตอบรับจากการเปลี่ยนแปลง จากทั้ง business และ technical อีกด้วย

ไปอ่านบทความเรื่อง Environment Creation Times in Modern Teams มา

น่าสนใจดีเลยเอามาสรุปสั้น ๆ ไว้นิดหน่อย เริ่มด้วยรูปนี้

การทำงานของชาว Enterprise โดยอธิบายจากรูปนี้ได้ว่า นั่นคือจาก business idea ไปสู่การ deploy ระบบบน production environment จะต้องกำหนดแผนใหญ่ไปยังแผนย่อย ๆ ขนาดเล็ก ๆ สิ่งที่น่าสนใจคือ เราจะทำการสร้าง environment เพียงครั้งเดียว !! แต่สิ่งที่เกิดขึ้น หรือ ปัญหาตลอดคือ

ใช้เวลานานเท่าไรในการเตรียม environment ต่าง ๆ ?
เรา shared environment ต่าง ๆ กันอีก ?
environment ต่าง ๆ ดันไม่เหมือนกับ production environment อีก ?

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

เปิด request ขอเครื่อง 1 สัปดาห์ เราก็ได้แต่เครื่องเปล่า ๆ
เปิด request ขอ OS 1 สัปดาห์ เราก็จะได้ OS เปล่า ๆ
เปิดขอ user/password 1 สัปดาห์ เราก็จะได้ user/password มา
เปิดขอ firewall ไปยังระบบต่าง ๆ 1 สัปดาห์ เราก็จะได้การ access ไปยังที่เราต้องการ

เปิดขอ x ในเวลา y สัปดาห์ ??? คำถามคือ มันเร็วหรือช้า มันเป็นการทำเพื่อใคร ? เพื่อ business ? เพื่อจะได้ไม่ต้องเปลี่ยนแปลงหรือปรับปรุงอะไร ? ทีมพัฒนาก็มีปัญหากับทีมต่าง ๆ ที่เตรียม environment ให้อีก ? ขั้นตอนการทำงานมันก็เยอะ เทอะทะไปหมด ?

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

เมื่อมองดูทีมดีนั้น

จะทำการสร้าง environment ใหม่ ๆ สำหรับผ่านระบบ Continuous Integration ทุก ๆ ครั้งที่ code หรือ configuration มีการเปลี่ยนแปลง โดยจะสร้างระบบที่ไม่ใหญ่มาก ๆ แต่ว่าเหมือนหรือใกล้เคียง production environemnt มาก ๆ ทั้ง version ของ software ทั้ง configuration ของระบบ ทั้งระบบ network เพื่อให้สามารถ build -> test -> deploy ได้ตลอดเวลา จากนั้นก็จะทำการลบ environment นี้ทิ้งไป

ดังนั้นเวลาในการสร้าง หรือ provisioning environment ต่าง ๆ ช้าเกินนาทีหรือหลายนาที มันก็ไม่น่าจะดีใช่ไหม เพราะว่า เรารู้ปัญหาได้ช้า

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

ปล. บางคนอาจจะบอกว่า แค่ได้เครื่องมาก็บุญแล้ว ประเด็นคือ ทาง business รู้ไหมว่า ทีมพัฒนามีปัญหาแบบนี้ ??

แนวคิด Continuous Integration และ Continuous Delivery/Deployment นั้น เป็นสิ่งที่สำคัญมาก ๆ สำหรับการพัฒนา software มันไม่ใช่เรื่องของ process เพียงอย่างเดียว มันไม่ใช่เรื่องของ tool เพียงอย่างเดียว มันไม่ใช่เรื่องของ culture เพียงอย่างเดียว มันไม่ใช่เรื่องของทีมพัฒนาเพียงอย่างเดียว แต่มันคือเรื่องของการเปลี่ยนจาก requirement มาเป็นสิ่งที่อยู่ในคนใช้หรือสร้างคุณค่าให้กับลูกค้าและบริษัทนั้น ๆ อย่างต่อเนื่องและมีคุณภาพ

แต่ใช่ว่าจะสร้างระบบต่าง ๆ เหล่านี้ขึ้นมาได้ง่าย ๆ

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

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

การเริ่มต้น น่าจะเป็นเรื่องของให้ความรู้ความเข้าใจเรื่อง CI/CD ก่อน

มันคือการปรับเปลี่ยนแนวคิดและวัฒนธรรมขององค์กรกันเลย ยกตัวอย่างเช่น

การจัด session ต่าง ๆ เพื่ออธิบายและแนะนำ พร้อมยกตัวอย่างระบบ เพื่อให้เห้นประโยชน์และคุณค่า
มีการพูดคุยจากกลุ่มคนหรือบริษัทต่าง ๆ เพื่อหยิบยก real-world case ให้เห็น
มีการจัด workshop หรือ working group สำหรับให้แต่ละกลุ่มมาพูดคุยกัน แบ่งปันความรู้ และ ช่วยเหลือซึ่งกันและกัน

จากนั้นก็เริ่มทำการปรับปรุงด้วยการใช้คำถามที่น่าสนใจ ยกตัวอย่างเช่น

Development server สามารถสร้างใหม่ได้รวดเร็วเพียงใด ?

ถ้าช้าก็ทำให้การพัฒนาช้าไปด้วย ใช่ไหม ? ถ้ามันช้า ลองสรุปหน่อยสิว่า ขั้นตอนการทำงานมีอะไรบ้าง ? ต้องทำ manual process อะไรบ้าง ? ต้องทำการ configuration อะไรบ้าง ? เร็วที่สุดต้องใช้เวลากี่ชั่วโมง กี่วัน กี่สัปดาห์ ?

ทดสอบระบบทั้งหมดได้เร็วเพียงใด ?

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

แต่ละ feature ทำการ deploy และ release เร็วเพียงใด ?

ทั้ง feature ใหม่ ๆ ทั้งการแก้ไข bug เวลาในการ deploy และ release ช้าลงเรื่อย ๆ จำนวน feature ที่มากขึ้นหรือไม่ ? มี feature อะไรที่ไม่ใช้งาน แต่ต้อง maintain บ้าง ?

ลองตอบคำถามเหล่านี้กันดู

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

มีโอกาสไปแบ่งปันเรื่อง TDD with Golang สำหรับผู้เริ่มต้น ตั้งแต่การติดตั้ง เริ่มทำความรู้และเข้าใจเกี่ยวกับพื้นฐานของภาษา Go จากนั้นจึงเริ่มแนะนำการเขียน Test จนไปถึง Testable code ด้วยภาษา Go แต่สิ่งที่อยากสรุปไว้นิดหน่อยคือ เทคนิคสำหรับการเขียน Test ด้วยภาษา Go มาดูกันว่ามีอะไรที่น่าสนใจบ้าง ปล. อยากรู้เรื่องอะไร ก็แบ่งปันคนอื่นซะ

ไม่จำเป็นต้องใช้ testing framework อื่น ๆ

เนื่องจากภาษา Go นั้นได้เตรียม testing package ไว้ให้แล้ว ซึ่งมีความสามารถครบครัน ไม่ต้องเรียนรู้ framework อื่น ๆ อีก ดังนั้นสำหรับผู้เริ่มต้นแนะนำให้ใช้ก่อนเลย ไม่ต้องไปหา framework อื่น จนกว่าคุณจะเข้าใจมัน ในการใช้งาน testing package นั้นอาจจะต้องเขียน code ต่าง ๆ เองเยอะพอควร ดังนั้นแนะนำให้ลองสร้าง helper function สำหรับการทดสอบไว้ด้วย แล้วชีวิตจะสะดวกสบายมากขึ้น ตัวอย่างเช่น function equals() สำหรับการเปรียบเทียบค่า [gist id="452c4eec4b860505d7f904c96b51e230" file="helper.go"] มีคำตอบสำหรับคำถามว่า Why does Go not have assertions? รวมไปถึงการ mock และ stub ก็ใช้ Go ล้วน ๆ ได้เลย ไม่ต้องไปหา framework อื่น ๆ

การตั้งชื่อสำหรับการทดสอบก็สำคัญนะ

ชื่อไฟล์ของการทดสอบจะลงท้ายด้วย _test.go เสมอ ตัวอย่างเช่นใน package hello มีไฟล์ชื่อว่า sample.go ถ้าต้องการทดสอบก็เขียนไว้ในไฟล์ sample_test.go ซึ่งอยู่ใน package hello เช่นกัน ส่วนชื่อของ test case นั้นต้องขึ้นต้นด้วยคำว่า Test เสมอ จากนั้นคำต่อมาต้องขึ้นต้นด้วยตัวพิมพ์ใหญ่เสมอนะ !! ยกตัวอย่างเช่น [code] Test<ชื่อ function ที่ทดสอบ>ToReturn<ผลที่คาดหวัง><เงื่อนไขที่ต้องการทดสอบ> [/code] ในการทดสอบก็ไม่ยาก ใช้คำสั่งดังนี้ (ปกติจะทดสอบแบบ parallel อยู่แล้ว) [code] $go test ./… #ทำการทดสอบทั้งหมด $go test -p 1 ./… #ทำการทดสอบทีละ package $go test -run TestName #ทำการทดสอบตามชื่อ test case ที่ต้องการ [/code]

การเขียน Example ก็คือการทดสอบนะ

ใน Go นั้นอนุญาติให้เขียน example ใน package ต่าง ๆ ได้ โดยจะเขียนในไฟล์ *_test.go นั่นเอง และชื่อ function จะขึ้นต้นด้วยคำว่า Example ไม่มี argument ใด ๆ ตัวอย่าง code เป็นดังนี้ [gist id="452c4eec4b860505d7f904c96b51e230" file="example.go"]

หลีกเลี่ยงการกำหนดค่าคงที่แบบ Global scope

ถ้าเรากำหนดค่าคงที่ใน code แล้ว ในส่วนของ test นั้นไม่สามารถเปลี่ยนแปลงค่าได้ ดังนั้นเปลี่ยนดีกว่านะ ยกตัวอย่างเช่น การกำหนด port ของระบบ [gist id="452c4eec4b860505d7f904c96b51e230" file="global.go"]

สำหรับ test fixture นั้นแนะนำให้สร้างใน directory ชื่อว่า testdata

ในการทดสอบบ่อยครั้งจำเป็นต้องมีไฟล์ของข้อมูลสำหรับการทดสอบใน package นั้น ๆ สิ่งที่ Go แนะนำคือ การสร้างไว้ใน directory ชื่อว่า testdata ซะ โดยที่ go build จะไม่สนใจ directory ชื่อนี้ รวมทั้งตอนทดสอบก็ดึงข้อมูลใน directory ได้ง่าย ๆ เพราะว่า directory ปัจจุบันคือ package นั้น เขียน code ได้ดังนี้ [gist id="452c4eec4b860505d7f904c96b51e230" file="testdata.go"]

สุดท้ายต้องคอยดูด้วยว่าชุดการทดสอบใดบ้างที่มันทำงานช้า

มีวิธีการแก้ไขหลายทางเช่น

แก้ไขให้เร็วขึ้น
ให้ข้ามหรือลบทิ้งไป !!
ทำการแยกไปอยู่ใน integration testing แทน จากนั้นก็เพิ่ม tag integration เข้าไปใน code เช่น

[gist id="452c4eec4b860505d7f904c96b51e230" file="some_integration_test.go"] จากนั้นทำการทดสอบด้วยคำสั่ง [code] $go test -tags=integration [/code]

วันนี้คุณเขียน test แล้วหรือยัง ?

ไว้มาดูเรื่อง Testable code กันใน blog ต่อไปนะ

การเรียนรู้เรื่องต่าง ๆ อย่างต่อเนื่องสำหรับนักพัฒนา ไม่ว่าจะเรียนรู้จากหนังสือ ต่าง ๆ ไม่ว่าจะเรียนรู้จาก web/blog/article ต่าง ๆ ไม่ว่าจะเรียนรู้จาก course online ไม่ว่าจะเรียนรู้จาก podcast ไม่ว่าจะเรียกรู้ทางช่องทางใด ๆ ก็ตาม เป็นสิ่งที่จำเป็นและสำคัญอย่างมาก ดังนั้นจึงสรุป Poscast ที่น่าสนใจและที่ติดตามอยู่ไว้นิดหน่อย ใครสนใจก็ลองไปฟังหรือ download มาฟังเล่น ๆ ดูนะครับ น่าจะสะดวกสำหรับการฟังด้วยโทรศัพท์ มันสนุกดีนะ

ใครมี Podcast ดี ๆ ก็เอามาฝากกันบ้างนะ ขอให้สนุกกับการ coding ครับ Reference Websites https://stackoverflow.blog/2017/08/09/5-great-podcasts-developers/ https://simpleprogrammer.com/2016/10/29/ultimate-list-developer-podcasts/ https://www.quora.com/What-are-the-best-podcasts-for-software-developers

เมื่อวันที่ 18 สิงหาคมที่ผ่านมาทีมพัฒนา App Google I/O 2017 ได้ทำการเปิดเผย source code ออกมาแล้ว (ปกติก็เปิดอยู่แล้วนะ) แน่นอนว่า เป็นอีกหนึ่งแหล่งความรู้ชั้นดีสำหรับ Android developer ซึ่งพลาดไม่ได้ด้วยประการทั้งปวง มาดูกันสิว่า ต้นฉบับเข้าพัฒนา Android app กันอย่างไรบ้าง ?

ปล. ไม่น่าจะมีปัญหาเรื่องลิขสิทธิ์อะไรนะ !!

โดย source code ใน version นี้ได้ทำการปรับปรุงความสามารถหลายอย่างเลย

ทั้งเพิ่มเติมและแก้ไข รวมทั้งยังใช้งาน Firebase อีกด้วย เช่น ระบบการจองในแต่ละ session ทำการ verify ผ่าน NFC ข้อมูลต่าง ๆ เหล่านี้ช่วยทำให้ทีมผู้จัด สามารถนำข้อมูลมาช่วยได้เช่นการลดหรือขยายขนาดห้องของแต่ละ session

ในระบบการจองนั้นได้นำ Firebase มาใช้คือ

Firebase Realtime Database (RTDB) ช่วยทำให้ง่ายต่อการ sync ข้อมูลระหว่างเครื่องของผู้ใช้งานกับระบบ ที่สำคัญสนับสนุน offline mode อีก
Cloud Functions for Firebase ทำการประมวลผลคำสั่งจองต่าง ๆ ในแบบ background process รวมทั้งจัดการด้วย transaction ดังนั้นทำให้มั่นใจในความถูกต้องได้เลย ไม่ต้องกลัวจองซ้ำ จองเกิน

ส่วนเรื่องของ Feed ต่าง ๆ ของงาน ก็ยังคงใช้ RTDB เช่นกัน

ข้อมูลจะถูกส่งมาจากระบบ CMS ทั่วไป (Content Management System) จะใช้ระบบ Cloud function ในการคอยดูว่าข้อมูลมีการเปลี่ยนแปลงหรือไม่ ถ้าข้อมูล feed มีการเปลี่ยนแปลง ก็จะส่งข้อมูลไปยัง device ของผู้ใช้งานแต่ละคน ผ่าน Firebase Cloud Messaging (FCM) ต่อไป การทำงานของระบบการจองแสดงดังรูป

ส่วนโครงสร้างของ App ยังคงเป็น MVP (Model-View Presenter) ต่อไปจากของเดิม

ซึ่งยังคงแยกส่วนการทำงานต่าง ๆ ได้ดีอยู่ รวมทั้งง่ายต่อการทดสอบ ส่วน feature ใหม่ ๆ เช่น Feed ก็ปรับเปลี่ยนมาใช้ MVP อีกรูปแบบ ตาม Android Architecture Blueprint

สิ่งที่น่าสนใจคือ ควรเลือกโครงสร้างของ App ให้เหมาะสมกับ feature ด้วยนะ ไม่ใช่ว่า ใช้โครงสร้างเดียวในทุก ๆ feature

สิ่งที่ใช้มาก ๆ เลยคือ Firebase Remote Config

ซึ่งใน version ที่ผ่าน ๆ มา การจะเปลี่ยนอะไรที จะบังคับให้ผู้ใช้งานทำการ update app ใหม่ตลอด ซึ่งมันไม่ดีต่อผู้ใช้งานเลย ดังนั้นจึงนำ Firebase Remote Config มาใช้ เพียงแค่กำหนดค่าเริ่มต้นของ App ไว้ จากนั้นถ้าต้องการเปลี่ยนค่าอะไร ก็เปลี่ยนผ่าน Firebase Remote Config เลย ผู้ใช้งานก็ไม่ต้อง update app เองอีกต่อไป

โดยสรุปแล้ว App ใช้งาน Firebase เพียบเลยคือ

ถ้าข้อมูลของงานและข้อมูลของผู้ใช้งานมีการเปลี่ยนแปลง จะทำการสื่อสารผ่าน Firebase Cloud Messaging และ การ sync ข้อมูล
ข้อมูลของ Feed ที่เปลี่ยนแปลงจัดการผ่าน RTDB
การเปลี่ยนแปลงค่าตคงที่ต่าง ๆ ใน App จัดการผ่าน Firebase Remote Config

ดังนั้นไปศึกษากันได้เลยครับที่ Source code ของ Google I/0 2017 ทำการ Fork และจัดการได้เลยครับ รออะไรกันอยู่ ขอให้สนุกกับการเขียน code นะครับ Reference Websites https://android-developers.googleblog.com/2017/08/google-releases-source-for-google-io.html

เมื่อสัปดาห์ที่ผ่านมาเห็นมีคนพูดถึง BMA Traffic app กันพอสมควร ดังนั้นในฐานนะนักพัฒนา Mobile app คนหนึ่ง เลยลองเข้าไปดูหน่อยสิว่า app พัฒนาอย่างไร ? มีการใช้ library อะไรที่น่าสนใจบ้าง ? ตลอดจนโครงสร้างและการทำงาน แต่จะไม่พูดถึง UX/UI นะครับ

น่าจะทำให้เราเข้าใจการพัฒนามากยิ่งขึ้น มาเริ่มกันเลย

ปล. เพื่อการศึกษาและเรียนรู้การพัฒนาระบบนะครับ

เริ่มด้วย library ที่ใช้งาน

ก็จะเป็น library พื้นฐานทั่วไป ยกตัวอย่างเช่น

Picasso สำหรับจัดการข้อมูลรูปภาพ แถมยังใช้ Glide อีกด้วย
Firebase สำหรับ Analytic, Authentication และ Cloud messaging และยังใช้ GCM อยู่นะ (Google Cloud Messaging) ในส่วน analytic มีการใช้งาน e-commerce tracker ด้วยนะ
OrmLite สำหรับจัดการข้อมูลกับ SQLite
Android GPUImage สำหรับทำ image fileter บน OpenGL
OKHttp3 สำหรับติดต่อข้อมูลผ่านระบบ Network
GoogleMap สำหรับเรื่องการแสดงแผนที่และตำแหน่ง
การจัดการข้อมูล JSON ยังคงใช้ org.json ที่มากับ Android
ksoap2 for android สำหรับติดต่อ WebService ด้วย SOAP

ต่อมาเรื่องการขอ Permission ก็เพียบนะ

มีเรื่อง badge ที่ขอตามยี่ห้อของ device เลยเยอะดี น่าสนใจดีนะ อันนี้ผมไม่เคยทำ

แน่นอนว่า code ก็ต้องแยกตาม device เช่น

Samsung
LG
Sony
Asus
HTC
Nova
Xiaomi
OPPO
Apex

การเก็บข้อมูลใน SQLite จะเก็บข้อมูล user ไว้ ซึ่งการใช้งาน OrmLite นั้น ช่วยลดจำนวน code ไปได้เยอะเลย

โครงสร้างของ app มี package ดังนี้

model สำหรับ POJO class ต่าง ๆ
dao (Data Access Object) สำหรับจัดการข้อมูลใน SQLite
connector สำหรับจัดการข้อมูลผ่านระบบ network ด้วย SOAP Connector ไปยัง WebService
task สำหรับการเรียกข้อมูลผ่าน connector ซึ่งยังคงใช้งาน AsynTask อยู่ทั้งหมด
flow สำหรับจัดเก็บพวก Activity และ Fragment ต่าง ๆ ของ app ไว้ โดยในแต่ละ activity มีขนาดใหญ่น่าดู เนื่องจากยังเขียนในรูปแบบปกติ คือ รับ action ต่าง ๆ ผ่าน activity และเรียก class ต่าง ๆ เพื่อให้ได้ข้อมูลที่ต้องการ และแสดงผลกลับไป

โดยการสร้าง instance ต่าง ๆ ของ class ต่าง ๆ ใน app เช่น การดึงข้อมูลต่าง ๆ เช่น การจัดการข้อมูลใน SQLite จะทำบน Application class ทั้งหมด

อีกอย่างที่น่าสนใจคือ ระบบนี้จะเรียกใช้งาน WebService ด้วย SOAP ทั้งหมด

ใน code ก็ระบุ ip ของ WSDL ตรง ๆ เลย !! ส่วนจะมีระบบ secure หรือไม่ อันนี้ไม่แน่ใจ แต่ถ้าเป็นข้อมูลแบบ public ก็ไม่น่ามีปัญหาอะไร ซึ่ง code ทั้งหมดอยู่ในไฟล์เดียว ใน package connector นั่นเอง ที่น่าสนใจคือ มีบาง service ที่ส่งค่าเป็นข้อมูล String ในรูปแบบ JSON กลับมา จากนั้นต้องทำการแปลงกลับมาเป็น JSONObject/Array เพื่อนำมาใช้งานต่อไป ส่วนการจัดการ error ต่าง ๆ พบว่า ยังมีการใช้ e.printStackTrace() อยู่ ยังไม่ยอมยิงไปเก็บที่ Crash Analytic Tool !!

ปิดท้ายด้วยตำแหน่งหรือ localtion ที่กำหนดไว้ใน code (ค่า default)

โดยรวมเป็น app ที่ไม่ได้มีความซับซ้อนอะไรมากนัก

จำนวน code ยังไม่เยอะ แต่ว่าแต่ละไฟล์แอบใหญ่พอสมควร จะมีเรื่องเยอะหน่อย ๆ ก็เช่นการประมวลผลกับรูปภาพ รวมทั้งการจัดการเรื่อง Home Badger ของแต่ละ device และการดึงข้อมูลจากระบบ WebService ที่อาจจะเทอะถะหน่อย รวมทั้งเรื่องของความปลอดภัยของข้อมูลที่ต้องดูกันต่อไป แต่ถ้าระบบทำงานได้เร็ว และ รองรับปริมาณการใช้งานได้ก็น่าจะ ok นะครับ ขอให้สนุกกับการ coding ครับ ส่วนใครอยากดูว่า version แรกเป็นอย่างไรที่นี่เลยครับ

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

1. ต้องรู้และเข้าใจในสิ่งที่นำมาใช้งาน นั่นคือการทำงานภายในของ Android

ตัวอย่างเช่น จะใช้งาน Activity/Fragment ก็ต้องเข้าใจ และจัดการ Lifecycle ของมันได้ การทำงานของ Main Thread และ Background Thread ว่ามันทำงานอย่างไร ว่ามันมีปัญหาอย่าง ว่ามันมีวิธีการแก้ไขปัญหาอย่างไร ดังนั้นเอกสารต่าง ๆ จาก Android Developer มันก็สำคัญมาก ๆ ดังนั้นจำเป็นต้องอ่านกันบ้างนะ แต่การจะเรียนรู้ทั้งหมด มันเป็นไปไม่ได้เลย ดังนั้นให้เรียนรู้เท่าที่จำเป็นและเพียงพอต่อการใช้งาน สำหรับพัฒนา app

2. เริ่มต้นด้วยการไปอ่านและศึกษาจาก code ของคนอื่น

เพียงแค่การเขียนอย่างเดียวยังไม่เพียงพอ สิ่งที่ต้องทำเพิ่มคือ ไปอ่านและศึกษาจาก code ของคนอื่น ซึ่งมีให้ศึกษาเยอะเลย ยกตัวอย่างเช่น Opensource Android App จะทำให้เราเห็นรูปแบบการเขียน code ทั้งโครงสร้างของ app ทั้งแนวคิดต่าง ๆ ซึ่งทำให้เราพัฒนาความสามารถได้อย่างต่อเนื่อง

3. รีดความสามารถของ IDE ที่ใช้ออกมาให้ได้เยอะ ๆ

เครื่องมือที่นำมาใช้งานนั้น เพื่อช่วยทำให้เราสะดวกและง่ายต่อการพัฒนา IDE ก็เช่นกัน ยกตัวอย่างเช่น Android Studio เราก็สามารถปรับแต่งค่าต่าง ๆ และใช้ความสามารถที่มันมีมาให้เยอะ ๆ ลองศึกษาเพิ่มเติมได้ที่ Use Android Studio like a pro จะช่วยเพิ่ม productivity ในการพัฒนาได้อย่างมาก

4. ให้ความสำคัญต่อการเลือกโครงสร้างของระบบ

บ่อยครั้งเรามักพบว่า class ต่าง ๆ ของระบบงานนั้น มีจำนวนบรรทัดต่อ class เยอะมาก ๆ (God class) ซึ่งมันส่งผลต่อเวลาในการพัฒนาอย่างมาก รวมไปถึงยากต่อการดูแลรักษา และ ทดสอบอีกด้วย โดยโครงสร้างของระบบมีมากมาย เช่น

MVP
MVC
MVVM
VIPER
Clean Architecture
Redux
Architecture Component

สามารถเริ่มได้จาก Android Architecture อีกทั้งยังมี guildeline สำหรับการเขียน code ที่ดีอีกด้วย Android guildeline

5. ต้องทำการศึกษาแนวปฏิบัติที่ดีสำหรับการพัฒนา Android app

หลังจากที่พัฒนาระบบงานได้ดีแล้ว สิ่งที่ต้องทำการศึกษาเพิ่มเติมคือ แนวปฏิบัติที่ดีต่าง ๆ ว่าอะไรบ้างที่ควรทำ ว่าอะไรบ้างที่ไม่ควรทำ ยกตัวอย่างเช่น Better Practices in Android Development

การใช้งาน Gradle
การจัดการ sensitive data
การจัดการข้อมูล JSON
การจัดการข้อมูลผ่านระบบ network
การระมัดระวังเรื่อง 65k method limit
การจัดการ layout
การใช้งาน shared preference
การใช้งาน Leak canary สำหรับหาจุดที่ทำให้เกิด memory leak

6. จำเป็นอย่างมากที่ต้องศึกษาเรื่องการออกแบบ (UX/UI)

โดยปกติแล้วผมจะเน้นที่การเขียน code ให้ดีมากกว่า การออกแบบ UI ที่สวยงามและใช้งานได้ง่าย ดังนั้นสิ่งที่ยังขาดคือ เรื่องของการออกแบบ ที่ Android developer ควรที่จะเข้าใจ

7. เริ่มเขียนชุดการทดสอบขึ้นมาเรื่อย ๆ แต่ให้เริ่มนับ 1 ก่อนนะ

สิ่งที่มักจะแนะนำคือ อะไรที่เราทดสอบด้วยมือหรือ manual test ได้ ให้ทำการจดบันทึกไว้เพื่อนำมาทดสอบอีกครั้งให้ได้ นั่นคือการเขียนชุดของการทดสอบ หรือ automated test ไว้ เพื่อช่วยบอกว่า เราทดสอบอะไรบ้าง เพื่อช่วยบอกว่า เราไม่ทดสอบอะไรบ้าง เพื่อช่วยทำให้เรามีความเชื่อมั่นต่อ code ที่เขียน ที่สำคัญ เราจะไม่ผิดซ้ำที่เดิม ๆ

8. ซื้อเครื่องดี ๆ สำหรับการพัฒนานะครับ

เพราะว่าในการพัฒนานั้น เครื่องมือต่าง ๆ มันใช้งาน resource เยอะเหลือเกิน ทั้ง CPU และ Memory เช่น Android Studio ก็กิน Memory ในช่วงเริ่มต้น 1 GB แล้ว ถ้าใช้ Emulator อีกก็ 1 GB ทางที่ดีก็ใช้มือถือจริง ๆ ดีกว่า !!

สุดท้ายแล้ว Android developer ต้องฝึกเขียนกันบ่อย ๆ

ทำทุกอย่างให้สม่ำเสมอ นั่นคือค่อย ๆ ศึกษาทีละเรื่องในทุก ๆ วัน ถ้าเป็นไปได้ การเริ่มต้นทำบางสิ่งนั้นมันง่าย แต่การทำสิ่งเหล่านั้นต่อไปอย่างต่อเนื่องมันยากมาก ๆ ดังนั้นแนะนำให้ทำแบบค่อยเป็นค่อยไป

มีคำถามที่น่าสนใจในกลุ่ม Thailand Android Developer ว่า ในการพัฒนา App ระหว่าง Native กับ Hybrid app ควรเลือกใช้อะไรดี ? รวมทั้งในแง่ความต้องการของตลาดงาน รวมทั้งในแง่ความนิยมในปัจจุบันและอนาคต โดยใน comment มีการตอบที่น่าสนใจเยอะเลย ตัวอย่างเช่น

ดูเรื่องลักษณะของงาน และ feature ก่อนว่าต้องการอะไร
ต้องศึกษาทั้งสองอย่างให้เข้าใจก่อน เพื่อจะได้เลือกของที่เหมาะกับงาน
ดูเรื่อง performance ของระบบ
ถ้ามองเรื่องตลาดแรงงาน แน่นอนว่าเป็น Native และพวก Hybrid ก็แรงขึ้นมาเช่น React Native เป็นต้น
เวลาในการเรียนรู้ (Learning curve)

แต่ก่อนอื่นเรามาทำความรู้จักกับ Native และ Hybrid app กันก่อน

มิเช่นนั้นอาจจะเข้าใจผิดและเลือกผิดก็เป็นไปได้ Native app พัฒนาด้วยภาษาโปรแกรมที่ถูกกำหนดมาใจแต่ละ platform เลย เช่น

Android app พัฒนาด้วย Java, Kotlin และ C++ เป็นต้น
iOS app พัฒนาด้วย Objective-C และ Swift เป็นต้น

โดยปกติแล้วการพัฒนาด้วย Native นั้นจะมีประสิทธิภาพการทำงาน ทั้งการ render และ animation ที่ดีกว่า Hybrid (ถ้าเขียนดีนะ) Hybrid app เป็น app ที่จะมี Web View หรือส่วนการแสดงผล web ซึ่งจะอยู่ใน Native app ทำให้สามารถเราสามารถ run web ใน app ของเราได้ รวมทั้งยังสามารถใช้งานความสามารถต่าง ๆ ของ device ได้ ยกตัวอย่างเช่น กล้องถ่ายรูป และ GPS เป็นต้น โดยที่ Hybrid app จะสร้างส่วนการติดต่อสื่อสาร ระหว่าง Web View กับ Native ขึ้น แน่นอนว่าไม่ได้อยู่ในมาตรฐานของ iOS และ Android แต่เป็น 3-party tool/framework ที่มาครอบอีกชั้นหนึ่ง ยกตัวอย่างเช่น Codova, Ionic, NativeScript, Xamarine, PhoneGap และ React Native เป็นต้น เมื่อทำการ build Hybrid app นั้น จะทำการ compile code และแปลง code จะ web มาเป็น Native app ให้ ซึ่งมีขั้นตอนที่เยอะพอสมควรเลยนะ แต่มันทำให้เราเขียน code ครั้งเดียว แล้วได้ App ที่ทำงานได้ทั้ง Android และ iOS (ในแง่แนวคิดนะ !!)

มาลองเปรียบเทียบกันหน่อย

Native app

พัฒนาด้วยภาษาตาม platform นั้น ๆ
แยก code ตามแต่ละ platform
มีประสิทธิภาพการทำงานที่ดี
ใช้จำนวนคน และ เวลาในการพัฒนาที่สูง
รอบการพัฒนาจะช้า สวนทางกับค่าใช้จ่าย

Hybrid app

พัฒนาด้วย HTML, CSS และ JavaScript
Write once, Run anywhere !!
ใช้เวลาและค่าใช้จ่ายในการพัฒนาน้อยลง
รอบการพัฒนาเร็วขึ้น
ประสิทธิภาพการทำงานจะต่ำกว่า Native

ส่วน Hybrid app นั้นมี tool และ framework มากมาย ดังนั้นก่อนจะเลือกใช้อะไรก็ต้องศึกษา และ ลองใช้มันก่อน ว่ามีข้อดีข้อเสีย ว่ามีข้อแตกต่างกันอย่างไร ลงมือทำซะตอนนี้เลย

การพูดคุยหรือถกเถียงเรื่องของ Hybrid และ Native app

มักจะคุยเรื่องต่าง ๆ ดังนี้

Speed/Time to Market
One source code
Cross-platform compatibility
ง่ายต่อการ update
เรื่องของงบประมาณ
เรื่องของคนหรือทีมพัฒนา

เมื่อคุยสิ่งต่าง ๆ เหล่านี้ก็มักจะเอนเอียงไปยัง Hybrid app เสมอ แต่เมื่อต้องดูและรักษาระบบไปนาน ๆ จะพบว่าต้องเสียเวลามากมายไปกับ การแก้ไขเรื่องของการทำงานและใช้งาน app เช่น User Experience และ User Interface ให้ตรงตามความต้องการของผู้ใช้งาน รวมทั้งการปรับปรุงเรื่องของ performance ต่าง ๆ ส่วนทาง Native app นั้นก็มีข้อได้เปรียบ เรื่องของการเข้าถึงการทำงานของ device ต่าง ๆ ได้ง่าย เช่น กล้องถ่ายรูป, address book และ GPS เป็นต้น รวมทั้งเรื่องของความปลอดภัยต่าง ๆ อีกด้วย แต่ก็แลกมาด้วยค่าใช้จ่ายที่สูงกว่าในช่วงแรก !!

ดังนั้นก่อนจะเลือกได้นั้น

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

ถึงอย่างไรก็ตามทั้ง Native และ Hybrid ต่างก็มีข้อดีและข้อเสียด้วยกัน ลองด้วยตัวเองก่อนนะ

ขอให้สนุกกับการ coding ครับ

ปิดท้ายด้วย Decision Tree ของการตัดสินใจที่น่าสนใจ

Reference Websties http://blog.techmagic.co/native-vs-hybrid-apps/ https://www.facebook.com/groups/thaidroiddev/permalink/1472477739499373/ https://medium.com/@ankushaggarwal/ionic-vs-react-native-3eb62f8943f8 https://developer.salesforce.com/page/Native,_HTML5,_or_Hybrid:_Understanding_Your_Mobile_Application_Development_Options

มีคำถามเกี่ยวกับการทดสอบระบบงานกับพวก Database ชนิดต่าง ๆ ทั้ง RDBMS (Relational DataBase Management System) ทั้ง NoSQL เช่น Document, Key-value, Column และ Graph อีกทั้ง Time series ว่าจะทดสอบกันอย่างไรดี ? ต้องทำการ mock/stub database ไหม ? ต้องเขียน code อย่างไรเพื่อให้ทดสอบได้ง่าย (Testable) ? ต้องทำอย่างไร ??? แต่ก่อนที่จะลงมือทำนั้น ลองมาคิดก่อนสิว่า มีวิธีการอะไร อย่างไรบ้าง ? และแต่ละวิธีเป็นอย่างไร มีข้อดีข้อเสียอะไรบ้าง ? จากนั้นจึงมาตัดสินใจว่าจะทำอย่างไรต่อไป

1. การใช้ Mock หรือ Stub Database ไปเลย

เราสามารถทำการสร้าง Mock database ขึ้นมาได้ ซึ่งถ้าส่วนการจัดการข้อมูลกับ Database อยู่ที่ DAO (Data Access Object) หรือ Repository แล้ว เราสามารถทำการสร้าง interface คั่น จากนั้นในการทดสอบก็สามารถสร้าง implementation class มาจาก interface ได้เลย จากนั้นทำการส่ง implementation class นั้นเข้ามายัง DAO เราเรียกวิธีการนี้แบบหล่อ ๆ ว่า Dependency Injection (DI) แต่วิธีการนี้จะทำได้เฉพาะ Unit test เท่านั้น ส่วน integration test ยังไม่ได้ตอบโจทย์ โดยวิธีการนี้ผมชอบเรียกว่า การทดสอบภายในบ้านของระบบที่เราควบคุมได้ ดังนั้นสิ่งที่ต้องการมากขึ้นเพื่อความมั่นใจก็คือ integration test และ end-to-end test

2. การใช้งาน Embedded database

นั่นคือการใช้งาน Database ชนิดเดียวกัน ทำการ start และ shutdown ในทุก ๆ ชุดการทดสอบได้ ส่วนใหญ่จะเป็น In-memory data ซึ่งทำงานได้อย่างรวดเร็ว ตัวอย่างเช่น H2, HSQLDB, SQLite, Derby เป็นต้น แต่วิธีการนี้ก็ไม่ได้การันตีว่า ถ้าทดสอบผ่านแล้ว จะสามารถทำงานบน Database จริง ๆ ได้ทั้งหมดนะ !! แต่การันตีเพียงพฤติกรรมการทำงานมันจะถูกต้องตามที่คาดหวังเท่านั้น ยกตัวอย่างเรื่องของ constraint ต่าง ๆ เป็นต้น

3. ใช้งาน Database จริง ๆ ไปในแต่ละ environment ที่ต้องการ

ตัวอย่างเช่น Development, Testing และ Staging เป็นต้น แต่ปัญหาที่ตามมาก็คือ ข้อมูลและ state ต่าง ๆ นั้น ต้องทำการ clean up เมื่อทำการทดสอบเสร็จสิ้นแล้วเสมอ นั่นคือ สามารถทดสอบซ้ำแล้วซ้ำอีกได้ ถ้าทำไม่ได้ มันก็ยากต่อการทดสอบอย่างแน่นอน และอาจจะเป็นเหตุผลในการไม่ทำ ก็เป็นไปได้

4. ทดสอบแบบ End-to-End test ไปเลย

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

จะเห็นได้ว่าวิธีการที่ 3 และ 4 มันยากต่อการเตรียมการมาก

แต่ด้วยเทคโนโลยีต่าง ๆ พัฒนาไปอย่างมาก มาจนถึงยุคของ Containerization มีเครื่องมือมากมายให้ใช้งาน ยกตัวอย่างเช่น Docker หรือ Moby ทำให้เราสามารถสร้าง container ของระบบงานที่ต้องการใช้ในการทดสอบได้ง่ายและสะดวกขึ้น ทั้ง Database container ทั้ง Web server container ซึ่งใช้ได้ตั้งแต่ developer => development ไปจนถึง production server ทำการสร้างและลบได้บ่อยเท่าที่ต้องการ แต่จริง ๆ ก็ไม่ง่ายขนาดนั้น ต้องมาวางแผนและลงมือทดลองกันก่อนนะ

มาถึงตรงนี้จะเห็นได้ว่ามีวิธีการที่หลากหลาย

ต่างมีข้อดีและข้อเสีย คำถามคือ สิ่งที่คุณต้องการคืออะไร ? คำถามคือ ต้องการทดสอบอะไร ? คำถามคือ ต้องการทดสอบเพื่ออะไร ? ขอให้สนุกกับการ coding ครับ

เข้าไปอ่านบทความเรื่อง Refactoring React จาก 8thlight มา ทำการอธิบายเกี่ยวกับการ Refactor หรือการปรับปรุงโครงสร้างของระบบที่พัฒนาด้วย React จาก React แบบปกติ ไปจนถึง ELM Architecture มีความน่าสนใจและมีประโยชน์ต่อการพัฒนาระบบงานอย่างมาก จึงทำการแปลและสรุปเพื่อเก็บไว้อ่าน รวมทั้งฝึกการเขียน code และชุดการทดสอบไปในตัวอีกด้วย ทำการแบ่งออกเป็น 2 ส่วน เนื่องจากมีรายละเอียดที่เยอะพอสมควรคือ

การพัฒนาและทดสอบ React app
การปรับปรุงโครงสร้างของ React app ให้เป็นไปตาม ELM Architecture

มาเริ่มในส่วนแรกกันดีกว่า

ในบทความเริ่มด้วยคำถามนี้ ซึ่งน่าสนใจมากคือ

How should i best test my React components ?

เรื่องของการทดสอบ React app และ Component นั้น มันเป็นเรื่องที่ซับซ้อนสับสนวุ่นวายอย่างมาก เนื่องจาก React เอง มีทั้งเรื่องของ DOM (Document Object Model) มีทั้งเรื่องของ State มีทั้งเรื่องของการแสดงผล มีทั้งเรื่องของ Life cycle ซึ่ง React ได้นำส่วนต่าง ๆ เหล่านี้เข้ามาไว้ด้วยกัน จะเรียกหรือใช้งานบ่อย ๆ คือ Component นั่นเอง ดังนั้นการทดสอบ React นั้นจะต้องทดสอบในระดับของ Component กันเลย

พูดไปมันไม่เห็นภาพ มาเขียน code กันดีกว่า

โดยบทความนี้จะทำการสร้าง Simple Counter App เป็น app ที่เพิ่มหรือลบตัวเลขเท่านั้น ดังนั้นมีปุ่มบวก ปุ่มลบ และการแสดงตัวเลข ซึ่งมันง่ายมาก ๆ สามารถเขียนได้ดังนี้ [gist id="fb3628de4f29dc88959b69334baac2ac" file="Counter.js"] จาก code นั้นเป็นอะไรที่ง่ายมาก ๆ แต่ว่าถูก layer ของ React ซ่อนความซับซ้อนไว้เพียบ เช่น

การทำ caching ค่าของ component
การกำหนดค่าเริ่มต้นของ state จากตัวอย่างคือ counter
ในส่วนของการ render ก็มีการจัดการข้อมูลจาก state รวมทั้ง callback ต่าง ๆ เพื่อจัดการกับ action/event ที่เกิดขึ้น คือ การกดปุ่มเพื่อเพิ่มหรือลดค่า counter

จากนั้นเพื่อให้เข้าใจมากขึ้น มาเขียนชุดการทดสอบกันดีกว่า

รวมทั้งทำให้เรามั่นใจอีกว่า ถ้าเราต้องการแก้ไขโครงสร้าง และ reactor app ของเราแล้ว จะไม่ทำให้การทำงานเปลี่ยนไป หรือทำให้เรารู้ได้ทันทีว่าเกิดข้อผิดพลาดตรงส่วนไหนบ้าง ไม่ใช่การทำไปเรื่อย ๆ หรือตามอารมณ์อีกต่อไป การเขียน test สำหรับ React app นั้นมีทางเลือกเยอะมาก ๆ ทั้ง Jest, Karma, Mocha, Chai และ Enzyme เป็นต้น แต่ในบทความนี้เลือกใช้ Enzyme + mocha/chai ซึ่ง Enzyme จะทำการจำลอง React component lifecycle ขึ้นมา ทำให้เราสามารถทดสอบ React app/component ได้ง่ายขึ้น มาเริ่มกันเลย

ก่อนที่จะเขียนสิ่งที่เราควรต้องคิดและออกแบบก่อนคือ

ต้องทำการทดสอบอะไรบ้าง ? เนื่องจากเป็นการทดสอบในมุมมองของผู้ใช้งาน หรือ ผ่าน User Interface ดังนั้นชุดการทดสอบจะประกอบไปด้วย

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

[gist id="fb3628de4f29dc88959b69334baac2ac" file="Counter.spec.js"]

สิ่งที่ได้เรียนรู้จากการเขียนชุดการทดสอบด้วย Enzyme

ประกอบไปด้วย

การติดตั้ง library ที่ต้องใช้งาน
การใช้งาน Enzyme เพื่อจำลอง React component และทดสอบ component
การใช้งาน Chai สำหรับการ assertion หรือตรวจสอบผลการทำงาน

เมื่อทำการเขียนชุดการทดสอบแล้ว ลองกลับมาดูระบบงานกันหน่อย

ถึงตรงนี้เราทำการทดสอบระบบงานในรูปแบบของ End-to-End testing ? ตอนนี้เรากำลังทดสอบ framework หรือ framework testing หรือไม่ ? ประเด็นคือเราผูกติดไปกับ framework มากเกินไปหรือไม่ ? ส่วนการทำงานหลัก หรือ business logic อยู่ตรงไหน ? เราสามารถแยกออกมาเพื่อทดสอบได้หรือไม่ ? สิ่งที่เราควรให้ความสำคัญคือ

การจัดการ state
การเพิ่มหรือลดค่า
การเชื่อมต่อ event ของแต่ละปุ่ม นั่นคือปุ่มบวกต้องเพิ่มค่า ปุ่มลบต้องลดค่า
การแสดงผลตัวเลขของ counter

โดยสิ่งต่าง ๆ เหล่านี้ไม่ได้เกี่ยวข้องหรือใช้งาน lifecycle ของ React เลย React มีหน้าที่เพียงเชื่อมโยงส่วนต่าง ๆ เข้าด้วยกัน (Integration)

ดังนั้นสิ่งที่เราต้องทำกันต่อไปคือ แยกส่วนการทำงานต่าง ๆ ออกจากกัน

จากนั้นทำการทดสอบในแต่ละส่วน สุดท้ายนำมาผูกหรือเชื่อมต่อกันใน React app โดยใน React community นั้นนิยมใช้งาน Redux แต่ในบทความนี้ไม่ต้องการที่จะติดตั้ง Redux หรือ library อื่น ๆ เพิ่มเข้ามาอีก เนื่องจากทำให้ระบบมีความซับซ้อนมากยิ่งขึ้น และต้องการใช้งาน pure JavaScript เท่านั้น โดย source code อยู่ที่ Github :: Up1 :: Learn React to ELM

ในบทความส่วนที่ 2 จะทำการอธิบายเกี่ยวกับ ELM architecture และขั้นตอนการพัฒนาต่อไป ซึ่งมันสนุกสนานและน่าสนใจอย่างมาก

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

Hardware
Operating System (OS)
Programming ในภาษาต่าง ๆ

ดังนั้นลองมาหาคำตอบกันหน่อยสิ ปล. เขียนไปแบบงง ๆ

Concurrent เป็นการจัดการหลาย ๆ งานในเวลาเดียวกัน

งานคือสิ่งที่เราต้องการให้ทำจนเสร็จสิ้น ยกตัวอย่างเช่น เราไม่สามารถใช้มือเดียวยกแก้วเบียร์พร้อมกับเขียน blog ได้ นั่นหมายความว่า เราสามารถจัดการงานได้เพียงงานเดียว เช่น ยกแก้วเบียร์เพื่อกิน เราทำการกินเบียร์ไปสักคำ จากนั้นวางแก้วลง แล้วมาเขียน blog ไปสักสองถึงสามประโยค จากนั้นกลับมายกแก้วเบียร์ จากนั้นวางแก้วแล้วไปถือโทรศัพท์ จากนั้นกลับมายกแก้วเบียร์ต่อ ... สังเกตุไหมว่า แต่ละงานจะเข้ามาพร้อม ๆ กัน แต่เราใช้มือเพียงข้างเดียว ดังนั้นจึงต้องเลือกว่าจะทำงานอะไรก่อนหลัง จากนั้นทำการสลับงานที่ทำไปมา ในขณะที่แต่ละงานยังไม่เสร็จเลย นั่นคือการจัดการคิวงานนั่นเอง มันคือเรื่อง Context Switching คุ้น ๆ กันไหมนะ มันคือ multi-tasking หรือเปล่านะ ?

Parallel เป็นการ execute หรือทำงานหลาย ๆ งานพร้อมกันในเวลาเดียวกัน

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

สังเกตุไหมว่าทั้งสองเรื่อง คือ เทคนิคการแบ่งงานเป็นงานย่อย ๆ

เพื่อให้สามารถทำงานแบบขนานหรือ parallel ได้ เพื่อเพิ่มประสิทธิภาพการทำงานของระบบ รวมทั้งช่วยจัดการความเสี่ยงต่าง ๆ ที่อาจจะเกิดขึ้นเมื่อทำงานพร้อม ๆ กัน บางงานอาจจะทำงานแบบ Concurrent แต่ไม่ Parallel บางงานอาจจะทำงานแบบ Parallel แต่ไม่ Concurrent อ่านแล้วงงดีไหม ?

โดยสรุปแล้ว

Concurrent เป็นการจัดการหลาย ๆ งานในเวลาเดียวกัน นั่นคือเรื่องของโครงสร้างเพื่อจัดการปัญหา (Structure) มักจะพูดถึง Modularity, Responsive และ Maintainability สิ่งที่ได้ตามมาคือ ประสิทธิภาพของการทำงาน โดยจะให้ความสำคัญกับเรื่องของ

จะเริ่มทำงานเมื่อใด ?
ข้อมูลมีการแลกเปลี่ยนอย่างไร ?
จัดการการเข้าถึง shared resource กันอย่างไร ?

Parallel เป็นการทำงานหลาย ๆ งานในเวลาเดียวกัน นั่นคือเรื่องของทำงาน หรือ ประมวลผล (Execution) เป้าหมายหลักเพิ่มประสิทธิภาพของการทำงาน Parallel hardware ประกอบไปด้วย Multi-core processor, GPU และ computer cluster เป็นต้น Parallel programming จะเน้นในเรื่อง

จะแบ่งงานใหญ่ ๆ ออกเป็นงานย่อย ๆ ได้อย่างไร ?
จะใช้งาน parallel hardware อย่างไร ให้เหมาะสมที่สุด ?

เพื่อทำให้การประมวลผลรวดเร็วสุด ๆ การประมวลผลข้อมูลขนาดใหญ่และซับซ้อน เช่น Data analysis, 3D rendering เป็นต้น

ทั้งสองไม่เหมือนกันนะ แต่ดันเกี่ยวข้องกัน ไปกินเบียร์เย็น ๆ พร้อมกันสองแก้วดีกว่า !!

Reference Websites https://www.coursera.org/learn/parprog1/ https://takuti.me/note/parallel-vs-concurrent/ http://tutorials.jenkov.com/java-concurrency/concurrency-vs-parallelism.html http://www.dietergalea.com/parallelism-concurrency/ https://talks.golang.org/2012/waza.slide#1 https://www.braveclojure.com/concurrency/

ถ้าพูดถึงเรื่อง DevOps เครื่องมือที่มักถูกพูดถึงและแนะนำให้นำมาใช้งาน มักจะมี Docker และ Kubernetes เป็นสิ่งที่คล้ายกันมาก ๆ ทั้งสองมีเป้าหมายเดียวกันคือ ลดปัญหาเรื่อง compatibility ของระบบ ลดปัญหาเรื่อง portability ของระบบ ซึ่งเป็นความรับผิดชอบหลักของทีม development และ operation

โดยในบทความนี้เจะเน้นไปที่ Kubernetes

แต่ถ้าเราต้องการนำมาทดสอบหรือใช้งานบนเครื่องเรามันไม่ง่ายเลย เพราะว่า Kubernetes นั้นต้องการมากกว่า 1 instance ในการเริ่มใช้งาน คือหนึ่งสำหรับ master service สองสำหรับ discover service และสามสำหรับ node

แต่ถ้าจะใช้งานจริง ๆ ก็มีเครื่องมือช่วยคือ Minikube

โดยที่ Minikube เป็นเครื่องมือที่ทำให้ชีวิตนักพัฒนาง่ายขึ้น

ทำให้สามารถ run Kubernetes cluster บนเครื่องนักพัฒนาได้เลย ดังนั้นมาลองใช้งานกันแบบพื้นฐานสุด ๆ กันหน่อย

ปล. การทดสอบทั้งหมดอยู่บน Mac OS นะ ส่วนการติดตั้งดูจากที่นี่ได้เลย Installation น่าเบื่อนิดหน่อยที่ต้องใช้พวก VirtualBox หรือ VMWare Fusion เป็นบ้านให้ container ต่าง ๆ ที่จะสร้างขึ้นมา

มาเริ่มด้วยการสร้าง Kubernetes cluster กันดีกว่า

[gist id="bdd999fb1e17219222351b676ca63cdc" file="1.txt"] จากทำการตรวจสอบด้วยคำสั่ง [gist id="bdd999fb1e17219222351b676ca63cdc" file="2.txt"] ในตอนนี้เรามี 1 node ทำงานแล้วนะ

จะรออะไรมาลองสร้าง Nginx container เล่นกันหน่อย

รวมทั้ง expose port ออกมาหน่อยนะ [code] kubectl run webserver --image=nginx:1.13 --port=80 kubectl expose deployment webserver --type=NodePort [/code] โดยใน Kubernetes นั้นจะเรียกว่า Pod ดังนั้นขอดูหน่อยสิว่าที่เราเพิ่งสร้างมานั้นมีจริงหรือเปล่า ด้วยคำสั่ง [gist id="bdd999fb1e17219222351b676ca63cdc" file="3.txt"]

จากนั้นปัญหาคือ URL ของ web server ละ คืออะไร ?

โดยสามารถดูด้วยคำสั่ง [code] $minikube service webserver --url [/code] ลองเข้าใชงานตาม url ได้ผลดังรูป

ยังไม่พอนะ ยังมี Dasdboard หน้าสวย ๆ ให้ใช้งานอีกด้วย

สามารถเข้าด้วยคำสั่ง [code] $minikube dashboard [/code] แสดงผลดังรูป

ยังไม่พอนะ ยังมี proxy สำหรับการเข้าถึง

[code] $kubectl proxy [/code] จะทำการ start server มาให้ (Local ของเรานั่นเอง) ทำให้เราสามารถเข้าถึงได้ง่ายขึ้น แสดงรายชื่อ url ดังรูป

คำถามที่ตามมาคือ อยากเข้าไปใน container หรือ pod ทำอย่างไรดี ?

การใช้งานเหมือน docker เลยคือ [gist id="bdd999fb1e17219222351b676ca63cdc" file="4.txt"] เมื่อทุกอย่างเรียบร้อยก็ทำการลบทิ้งไปซะ [code] $kubectl delete deployments --all $kubectl delete pods --all [/code]

ปิดท้ายด้วยการ stop Minikube

[code] $minikube stop [/code] เพียงเท่านี้เราก็สามารถเริ่มต้น Kubernetes บนเครื่องเราได้แล้วนะครับ ขอให้สนุกกับการ coding ครับ

ต่อจากตอนที่ 1 อธิบายเรื่องของการพัฒนาระบบและเขียนการชุดสอบสำหรับ React app ในตอนที่ 2 จะมาอธิบายเรื่อง การปรับปรุงโครงสร้าง code ให้อยู่ในรูปแบบ ELM Architecture ซึ่งมีส่วนการทำงานดังนี้

View
Model
Update

จากนั้นลงมือปรับปรุง code ทีละส่วน แน่นอนว่า ต้องมีชุดการทดสอบด้วยเสมอ ดังนั้นมาเริ่มกันเลย

ทำความเข้าใจเกี่ยวกับ ELM Architecture กันก่อน

ประกอบไปด้วย 3 ส่วนหลัก

View คือส่วนที่นำ model มาแสดงผลนั่นเอง
Model คือส่วนหลักของระบบ รวมทั้งการจัดการ state ต่าง ๆ หรือข้อมูลนั่นเอง
Update คือส่วนการทำหน้าที่เปลี่ยนแปลงสถานะต่าง ๆ ของ model แต่แทนที่จะเปลี่ยนแปลงตรง ๆ ก็ทำการสร้างของใหม่ออกมา ซึ่งลดผลกระทบต่าง ๆ ที่จะเกิดขึ้น

อ่านไปอ่านมาก็คล้าย ๆ กับ Redux นะ แต่เป้าหมายของบทความนี้ ไม่ต้องการติดตั้ง library อะไรเพิ่มเติม ต้องการเขียนด้วย pure JavaScript เท่านั้น แน่นอนว่า การทำงานยังคงต้องเหมือนเดิม นั่นคือ ชุดการทดสอบที่เขียนด้วย Enzyme ใน Part 1 ยังคงต้องผ่านนะ มาเริ่มปรับปรุงโครงสร้าง หรือ Reactor code กันเถอะ

ขั้นตอนที่ 1 เรื่องของ Action และ State

สิ่งที่ต้องคิดถึงคือ state และ action ที่เกิดขึ้นใน app ของเรา มาดู state ของ app กันก่อน ซึ่งประกอบไปด้วย

init คือสถานะเริ่มต้นของ app นั่นคือ counter มีค่าเป็น 0 เสมอ
update คือการ update ค่าต่าง ๆ ใน model ตาม Action

เริ่มด้วยการเขียนชุดการทดสอบของ State กัน ประกอบไปด้วย 2 test cases คือ

init สำหรับตรวจสอบค่าเริ่มต้นของ counter ต้องเป็น 0
update สำหรับตรวจสอบสถานะ

มาดูชุดการทดสอบกันหน่อย (state.spec.js) [gist id="ea4e26042b3d73dfb097b2e1d0d90dcc" file="state.spec.js"] ทำการเขียน code ง่าย ๆ (state.js) สิ่งที่น่าสนใจคือ spread operator (...) สำหรับการส่งทั้ง object กลับมา [gist id="ea4e26042b3d73dfb097b2e1d0d90dcc" file="state.js"] จากนั้นมาดู Action ที่เกิดขึ้นใน app หน่อยสิว่ามีอะไรบ้าง ?

INCREMENT action สำหรับการเพิ่มค่า
DECREMENT action สำหรับการลดค่า

โดย action ต่าง ๆ จะถูกประกาศไว้ในไฟล์ actions.js ดังนี้ [gist id="ea4e26042b3d73dfb097b2e1d0d90dcc" file="actions.js"] ตอนนี้เรามาคิดกันหน่อยสิว่า แต่ละ Action ส่งผลต่อ state อย่างไรบ้าง ?

INCREMENT เพิ่มค่าขึ้นมา 1
DECREMENT ลดค่าลงมา 1

สามารถเขียนเขียนชุดการทดสอบใน state.spec.js ได้ดังนี้ [gist id="ea4e26042b3d73dfb097b2e1d0d90dcc" file="state.spec_v2.js"] จากนั้นทำการเขียน code ง่าย ๆ (state.js) ด้วยการใช้ swich-case ปกตินั่นเอง [gist id="ea4e26042b3d73dfb097b2e1d0d90dcc" file="state_v2.js"] สิ่งที่ห้ามลืมคือ นำ state ไป integrate เข้ากับ React component ด้วยนะ นั่นคือต้องเปลี่ยนแปลงไฟล์ Counter.js หรือ Counter component ด้วย สามารถเขียน code ได้ดังนี้

ทำการ initial ค่าของ State ด้วย State.init()
ทำการ update ค่าต่าง ๆ ด้วย Action INCREMENT และ DECREMENT

[gist id="ea4e26042b3d73dfb097b2e1d0d90dcc" file="Counter.js"]

หลังจากการเปลี่ยนแปลงแล้ว ผลที่ตามมาคือ ชุดการทดสอบยังต้องผ่านเช่นเดิม !! Unit tests ผ่านหมด Integration tests ผ่านหมด ก็ไว้ใจได้ในระดับหนึ่งแล้วนะ

ขั้นตอนที่ 2 เรื่องของ Lifecycle และ View

เมื่อเราทำการแยก State และการ Update ตามแต่ละ action ออกไปจาก component แล้ว (State และ Action) สิ่งที่ยังเหลือคือ การทดสอบในระดับ component โดยในตอนนี้เราทำการรวมทุกอย่างไว้ใน component เดียวคือ Counter Component (counter.js) ทั้งส่วนการประมวลผลและการแสดงผล ดังนั้นเราต้องทำการแยกทั้งสองส่วนออกจากกัน โดยส่วนหลักเราจะเรียกว่า Container component หรือ Lifecycle component ทำหน้าที่รับ action จากผู้ใช้งาน และรวม component ต่าง ๆ เข้าไว้ด้วยกัน และอีกส่วนเรียกว่า View component หรือ Dumb component ซึ่งทำหน้าที่แสดงผลตามข้อมูล หรือ state หรือ model ที่ส่งเข้ามาเท่านั้น มาแยกส่วนการแสดงผลออกมาดีกว่า !! โดยส่วนการแสดงผลหรือ View component ประกอบไปด้วย

การแสดงปุ่มบวก และ ปุ่มลบ
การแสดงข้อมูล counter
การรับ action มาทำงาน

โดยจะส่งข้อมูลผ่าน props มายัง component นี้ทั้งหมด สามารถเขียนได้ดังนี้ [gist id="ea4e26042b3d73dfb097b2e1d0d90dcc" file="View.js"] ต่อมาก็ต้องเขียนชุดการทดสอบด้วย Enzyme ดังนี้ สังเกตุไหมว่า ชุดการทดสอบน้อยลง เนื่องจากเราทดสอบเพียง state ที่เปลี่ยนและการแสดงผลตามข้อมูลที่กำหนดเท่านั้น [gist id="ea4e26042b3d73dfb097b2e1d0d90dcc" file="View.spec.js"] เมื่อทุกอย่างผ่านไปด้วยดีแบบนี้

ก็ได้เวลาแก้ไข Counter component หรือไฟล์ Counter.js เพื่อให้ใช้งาน View component ดังนั้น Container component คือ Counter.js ส่วน Dump component คือ View.js ทำการแก้ไขได้ดังนี้ [gist id="ea4e26042b3d73dfb097b2e1d0d90dcc" file="Counter_v2.js"] จากนั้นชุดการทดสอบก็ต้องเปลี่ยนไปเช่นกัน เนื่องจากใน Counter component จะมีเพียง View component เท่านั้น ซึ่งแก้ไขได้ดังนี้ [gist id="ea4e26042b3d73dfb097b2e1d0d90dcc" file="Counter_v2.spec.js"]

แน่นอนว่าชุดการทดสอบทั้งหมดต้องผ่าน ถือเป็นอันจบขั้นตอนการปรับปรุง code ของ React app ให้อยู่ในรูปแบบของ ELM Architecture

โดยสรุปแล้ว ถ้าใครอ่านมาถึงตรงนี้

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

ดังนั้นเลือกโครงสร้างให้เหมาะกับงานและทีมด้วยนะครับ

โดย source code อยู่ที่ Github :: Up1 :: Learn React to ELM ขอให้สนุกกับการเขียน code และ test นะครับ

อ่านบทความสรุปสิ่งที่น่าสนใจจากงาน Dev Tools @Scale 2017 ที่ London จากบทความเรื่อง Dev Tools @Scale Recap เป็นงานที่มี speaker จากบริษัทใหญ่ ๆ ทั้งนั้น มาพูดเกี่ยวกับเครื่องมือในการพัฒนาสำหรับระบบงานขนาดใหญ่ ไม่ว่าจะเป็น Facebook, Amazon, ARM, GitHub, Google, Microsoft และ Spotify เริ่มกันตั้งแต่การจัดการ source code, code quality, การ build, การทดสอบ ตลอกจนการ deploy เลยนำมาแบ่งปันกันหน่อย ซึ่งน่าจะมีประโยชน์สำหรับการพัฒนา software บ้าง

เริ่มด้วยเรื่องระบบ Resource Management ของ Facebook

โดยระบบงานชื่อว่า One World ซึ่งระบบนี้สามารถทำการทดสอบแบบ End-to-End ใน device ต่าง ๆได้หมด ทั้ง Android emulator, Android device, iOS Simulator ตลอดจน web browser

เรื่องที่สองคือ Facebook Infer คือ Static Analysis Tool

เป็นเครื่องมือที่ช่วยปรับปรุงคุณภาพของ source code ซึ่งเป็นเครื่องมือ opensource พัฒนาโดย Facebook โดยใช้กับระบบที่พัฒนาด้วย Java, C, C++ และ Objective-C หัวใจของเครื่องมือตัวนี้คือ ความเร็วในการทำงาน และสามารถนำไปทำงานในระบบ Continuous Integration ได้ง่ายอีกด้วย เพื่อช่วยหาปัญหาเรื่อง Null pointer และ Memory leak ซึ่งจะทำก่อนการ commit code เสมอ

เรื่องที่สามคือ Top Ten Worst Repositories to Host on GitHub

ทำการอธิบาย use case ที่ GitHub ต้องเผชิญ ซึ่งเป็น repository ที่มีขนาดใหญ่และจำนวนไฟล์มาก ๆ โดยทางทีม GitHub ต้องใช้เทคนิคที่หลากหลายมากจัดการกับปัญหา ไม่ว่าจะเป็นการ replicate และ caching เป็นกรณีศึกษาที่น่าสนใจอย่างมาก แต่ผมฟังไม่ค่อยรู้เรื่องเท่าไรนัก !!

เรื่องที่สี่คือ Scaling the Git Client with the Git Virtual File System

เป็นเรื่องรวมของทีมจาก Microsoft ที่ทำการเปลี่ยนให้ทีมพัฒนา Windows มาใช้งาน Git !! โดยสิ่งที่ต้องเผชิญคือ source code เป็นร้อย GB !! มีไฟล์เป็นล้านไฟล์ใน repository เดียว ซึ่งทาง Microsoft ได้พัฒนา Git Virtual File system (GVFS) ขึ้นมาเพื่อจัดการปัญหาเหล่านี้ เนื่องจากโดยปกติแล้ว Git ไม่สามารถรองรับความต้องการแบบนี้ได้

เรื่องที่ห้าคือ Scaling Android Application Testing at Spotify

เป็นเรื่องที่ผมสสนใจมาก ๆ คือการทดสอบ Android app นั่นเอง โดยพูดถึงเรื่องเครื่องมือที่ใช้ ไปจนถึง infrastructure ที่ต้องเตรียม เพื่อรองรับการเติมโตของทีมที่สูงขึ้นอย่างก้าวกระโดด สิ่งที่อธิบายและแสดงให้เห็นคือ การปรับปรุงคุณภาพของการทดสอบ ทั้งการทดสอบที่รวดเร็วขึ้น ทั้งเรื่องของการเตรียม test data ทั้งรายงานผลการทดสอบที่ดีและอ่านง่ายขึ้น เพื่อช่วยให้หาปัญหาได้รวดเร็ว ทั้งการใช้ linter ทั้งการลดหรือกำจัดชุดการทดสอบที่พังบ่อย ๆ ให้หมดไป โดยกระบวนการทดสอบจะมีทั้งก่อน merge code และหลังจาก merge code ไปแล้ว สามารถดู VDO เพิ่มเติมได้ที่ Facebook :: At Scale Events ปล. ถ้ามีโอกาส น่าไปร่วมงานจริง ๆ แต่ได้ดูผ่าน VDO ก็แจ่มแล้วครับ ขอให้สนุกกับการพัฒนาครับ

ในการพัฒนา Mobile app นั้น ถึงแม้จะเป็น app ที่น่าสนใจ โดนใจ และ แจ่มขนาดไหน แต่สิ่งที่นักพัฒนาต้องไม่พลาดหรือต้องใส่ใจเสมอคือ เรื่องของประสิทธิภาพการทำงาน และ ความน่าเชื่อถือ ลองคิดดูว่า ถ้าเปิด app ใช้เวลานานมาก ถ้า app ทำการดึงข้อมูลต่าง ๆ นานมาก ถ้าใช้งาน app ไป ๆ มา ๆ ดัน crash หรือปิดตัวเองไป ถ้า app ใช้ resource ต่าง ๆ ของเครื่องเยอะ เช่น CPU, Memory และ Battery

คำถามคือ ผู้ใช้งานส่วนใหญ่ยังจะใช้งานมันอยู่หรือไม่ ?

ดังนั้นมาดูกันหน่อยว่ามีอะไรที่นักพัฒนา Mobile app ควรใส่ใจ

เรื่องของ Latency ของ End-to-End (Low Latency, Fast Response time)

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

การทำงานของ Mobile app นั้นมักจะช้าจากการดึงข้อมูลจาก API ต่าง ๆ ผ่านระบบ network ซึ่งถ้านักพัฒนามองแค่นั้นมันคงยังไม่พอ ต้องดูให้ลึกในรายละเอียดอีกว่า แต่ละ API มีการทำงานภายในอย่างไร มี End-to-End Latency อย่างไร เพื่อทำให้เห็นถึงปัญหาจริง ๆ ที่ต้องแก้ไขและปรับปรุงกันต่อไป เช่น

ใช้เวลาในการดึงข้อมูลจาก database เท่าไร
ใช้เวลาในการเขียน log เท่าไร
ใช้เวลาในการบันทึกข้อมูลลง database เท่าไร
ใช้เวลาในการติดต่อไปยังระบบ A, B, C เท่าไร

นั่นคือการเข้าไปดูในทุก ๆ hop ของการทำงานนั่นเอง วันนี้คุณมีระบบแบบนี้หรือยัง ? มีตัวอย่างสวย ๆ จาก AppDynamic มาให้ดู

เรื่องที่สองคือ User Session หรือเวลาที่ผู้ใช้งานตั้งแต่เปิดยันปิด app

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

เกมส์จะใช้เวลาใน app ประมาณ 7 นาที
e-commerce ใช้เวลาใน app ประมาณ 3 นาที

ดังนั้นสิ่งที่เราต้องรู้คือ ผู้ใช้งานอยู่ใน app ของเรานานเท่าไร ? และเราคาดหวังหรือมีเป้าหมายอย่างไร ?

แต่ค่านี้จะใช้ไม่ได้เลย ถ้า network ที่เชื่อมต่อมายัง API มันช้า ซึ่งอาจจะทำให้ค่าของ User session ตกลงไปอย่างมาก เป็นสิ่งที่ทำให้เราเข้าใจพฤติกรรมการใช้งาน app มากยิ่งขึ้น เพื่อนำมาใช้ในการปรับปรุงและแก้ไขต่อไป ไม่ใช่ทำแบบคิดเอง เออเอง หรือ คิดไปเอง !! ข้อมูลจาก AppsFlyer บอกว่า

หลังจากใช้งาน Android app ไป 30 วัน มีผู้ใช้งานเพียง 3.3% ที่ยังคง active หรือใช้งาน
หลังจากใช้งาน Android app ไป 30 วัน มีผู้ใช้งานเพียง 3.2% ที่ยังคง active หรือใช้งาน

คำถามที่น่าสนใจคือ เราในฐานะนักพัฒนารู้ค่าต่าง ๆ ของ app ที่พัฒนาหรือไม่ ? และจะทำการปรับปรุงค่าต่าง ๆ เหล่านี้อย่างไร ?

เรื่องที่สาม การจัดการเรื่อง Crash Report ต่าง ๆ ของ app

เรารู้หรือไม่ว่า app มัน crash หรือมีปัญหาไหนบ้าง ? ผู้ใช้งานเขาไม่ report กลับมาหรอกนะ ถ้าไม่จำเป็นจริง ๆ ผู้ใช้งานเมื่อเจอ app ที่ crash หรือ พังประจำก็คงไม่อยากใช้งาน คำถามที่น่าสนใจคือ เราในฐานนะนักพัฒนา รู้หรือไม่ว่า app ของเรานั้นเกิด crash ตรงไหนบ้าง ? เพื่อใช้ในการปรับปรุงประสิทธิภาพการทำงาน รวมทั้งทำให้ผู้ใช้งานใช้งานอย่างราบรื่นไม่สะดุด

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

สุดท้ายคำถามง่าย ๆ คือ คุณรู้ตัวเลขต่าง ๆ เหล่านี้แล้วหรือยัง ?

ขอให้สนุกกับการพัฒนาครับ Reference Websites https://dzone.com/articles/3-mobile-app-performance-issues-you-cant-ignore

อ่านบทความเรื่อง Rapid release at massive scale จาก Facebook แล้วไปเจอ paper ที่ทาง facebook เขียนไว้คือ Continuous Deployment of Mobile Software at Facebook (Showcase) ตามจริงมี paper ที่เกี่ยวข้องอีกหลายฉบับเลย ใน paper ฉบับนี้มีความน่าสนใจในเรื่อง

Release cycle ของ mobile app ทั้ง iOS และ Android
การจัดเก็บข้อมูลต่าง ๆ ที่เกี่ยวกับการ release และ deployment
การทดสอบระบบงาน
มีการสรุปข้อมูลต่าง ๆ ของการพัฒนาอีกด้วย

ดังนั้นมาดูกันนิดหน่อย

เปิดด้วยข้อสรุปของ paper นี้ดีกว่า

รอบของการ release ระบบที่สั้น ๆ นั้น ช่วยทำให้ Time to Market เร็วขึ้น ช่วยทำให้ได้รับ feedback จากผู้ใช้งานเร็วและดีขึ้น แต่การมีเพียง continuous deployment เพียงอย่างเดียว มันไม่ได้ช่วยเพิ่ม productivity ของทีมพัฒนาหรอกนะ

รอบการ release ที่สั้นลงนั้น มันเป็นการบังคับให้องค์กร ให้ทีมต้องทำการปรับปรุงสิ่งต่าง ๆ ด้วยเช่นกัน ทั้งคน ทั้งกระบวนการ ทั้งเครื่องมือ และการทดสอบแบบอัตโนมัติ

สำหรับการ release ของ Mobile app นั้นมันไม่ง่ายเลยทั้งการ rollout และ rollback ดังนั้นสิ่งที่นำมาใช้งานคือ Feature Flag เพื่อให้สามารถเปิดหรือปิด function/feature ของระบบจาก server ได้ง่าย ๆ ดังนั้นถ้า function/feature ใด ๆ มีปัญหา ก็สามารถทำการปิดจาก server ได้เลย การ release แบบรอบสั้น ๆ ช่วยลดปัญหาต่าง ๆ ลงไป เช่นข้อขัดแย้งของ code ในไฟล์เดียวกัน ที่ต้องแก้ไขจากหลาย ๆ คน

เรื่องของ Mobile Release Cycle

โดยแบ่งออกเป็นสองส่วนคือ

Development Activity โดยนักพัฒนาจะทำการ push code ไปที่ Master branch
Deployment Activity โดย Release engineer จะทำการ cut code จาก Master branch มายัง Release branch

จากนั้นก็เข้าสู่กระบวนการ release ต่อไป Release Cycle สำหรับ iOS เป็นดังรูป โดยแบ่งเป็นรอบ ๆ ละ 2 สัปดาห์

เรื่องการจัดเก็บข้อมูลของแต่ละ release และ deployment

มีเยอะมาก ๆ ยกตัวอย่างเช่น

Revision-control system records เก็บข้อมูลของแต่ละ commit, push เช่น จำนวนบรรทัดและเจ้าของ เป็นต้น
Crash database เป็นระบบ crash report ซึ่งจะได้รับข้อมูลเมื่อ FB app มีปัญหา ซึ่งแบ่งตามการ release ไป
Flytrap database เก็บข้อมูลของ issue ต่าง ๆ ที่ถูก report มาจากผู้ใช้ภายในและภายนอก
Tasks database เป็น database หลักของทีม Release Engineer ซึ่งเก็บข้อมูล task ต่าง ๆ ทั้งการ implement และ issue ต่าง ๆ ที่ทำ
Production issue database ปัญหาต่าง ๆ ที่เกิดขึ้นบน production
Daily Active People (DAP) ข้อมูลผู้ใช้งาน Facebook app ในแต่ละวัน

โดยข้อมูลเหล่านี้จะนำมาใช้ในการวิเคราะห์ต่อไป

เรื่องการทดสอบระบบงาน

การทดสอบเป็นสิ่งที่สำคัญมากสำหรับ Mobile app เนื่องจาก

Mobile software มีการเปลี่ยนแปลงที่บ่อยและเยอะมาก ๆ
จำนวน device และ version ของ device มีมากมายและแตกต่างกัน
ยากต่อการแก้ไขปัญหาที่เกิดขึ้นหลังจากการ deploy/release !!

โดยการทดสอบของ FB app นั้นจะมีการทดสอบต่าง ๆ เหล่านี้

Unit test เป็น white-box testing สำหรับการ verify การทำงานในส่วนต่าง ๆ
Static Analysis เป็นการวิเคราะห์ source code เพื่อช่วยหาจุดที่อาจจะก่อให้เกิดปัญหาได้ เช่น null pointer, resource leak และ memory leak เป็นต้น
Build test เป็นการทดสอบว่า source code ทั้งหมดยัง build ได้
Snapshot test เป็นการทดสอบโดยบันทึกแต่ละหน้าจอเป็นรูปภาพ จากนั้นเอามาเปรียบเทียบกับสิ่งที่ต้องการ
Integration test เป็น black-box testing เพื่อทดสอบการทำงานในแต่ละ feature และ flow ต่าง ๆ ทั้งหมด นั่นคือ regression test นั่นเอง
Performance test เป็นการทดสอบใน mobile lab เน้นในเรื่องประสิทธิภาพของการทำงาน รวมทั้งการใช้งาน resource ต่าง ๆ อีกด้วย

สิ่งที่น่าสนอีกเรื่องของ Testing Principle

Coverage การทดสอบต้องครอบคลุมการทำงานในส่วนต่าง ๆ และแต่ละ test ต้องมีประโยชน์และทำการทดสอบบ่อย ๆ
Responsive การทดสอบต้องเร็ว เมื่อเกิดปัญหาต้องบอกได้เลยว่าเป็นปัญหาจากอะไร ตรงไหน
Quality
Automation การทดสอบต้องทำงานแบบอัตโนมัติให้ได้มากที่สุดเท่าที่จะเป็นไปได้ จะทำให้สามารถทดสอบซ้ำแล้วซ้ำอีกได้ และทดสอบได้บ่อยเท่าที่ต้องการ
Prioritization ต้องจัดเรียงลำดับความสำคัญของการทดสอบด้วย เนื่องจากการทดสอบต้องใช้ resource ต่าง ๆ เยอะ แต่ก็ต้องการความเร็วเช่นกัน ยกตัวอย่างเช่น developer อยากรู้ว่า code มีปัญหาหรือไม่ ดังนั้นทำการทดสอบ unit test ก่อน เพื่อให้นักพัฒนารู้ผล จากนั้นจึงทำการทดสอบ integration test ต่อไป

และสิ่งที่ขาดไปไม่ได้เลยคือ Testing Infrastructure และแน่นอนว่า Manual testing ก็ยังไม่อยู่เช่นกัน

ส่วนผลการวิเคราะห์ในมุมต่าง ๆ ลองอ่านใน Paper ดูนะครับ

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

ปล. จะเรียก NGINX Unit ว่า Unit

NGINX Unit คืออะไร ?

จากเอกสารอธิบายว่า

Lightweight application server
Dynamic web application server
ออกแบบมาเพื่อให้ง่ายต่อการ run หลาย ๆ ภาษาโปรแกรมได้ หลาย ๆ version ได้บนเครื่อง หรือ server เดียวกัน
ตอนนี้สนับสนุน PHP, Python และ Go ก่อน ส่วน Java, JavaScript และ Ruby ก็รอนิดนึง

โดยแต่ละ Unit ทำการออกแบบได้ดังรูป นั่นคือแต่ละ Unit จะ run อะไรก็ได้ตามที่สนับสนุน แต่ว่าการ run ภาษาเดียวแต่หลาย version ยังไม่ได้ลอง ซึ่งมองแล้วมันมีประโยชน์มาก ๆ ไว้ต้องทดลองดูบ้าง !!

สิ่งที่น่าสนใจมาก ๆ คือ สามารถทำการ configuration หรือ ปรับแต่งค่าต่าง ๆ ของระบบ

ผ่าน REST API (JSON) ที่กำหนดไว้ ดังนั้นจึงง่ายต่อทีมพัฒนาและ operation ไม่ต้องมานั่ง config บน server เอง อยากเปลี่ยนก็ทำผ่าน REST API ไปเลยเช่น

จำนวน worker ของ NGINX
Path ของระบบหรือ service ต่าง ๆ
Port หรือ Listener ของแต่ละ server ว่าจะเปิดให้เข้าถึงผ่าน port อะไร

อ่านไปก็งง มาลองใช้งานกันดูดีกว่า

จากเอกสารการติดตั้งดูแล้วเหนื่อย ดังนั้นเพื่อความง่ายเลยใช้ Docker ดีกว่า หลังจากนั้นค่อยมาสร้าง Image ไว้ใช้งานกัน !! มาเริ่มกันเลย สร้าง container ด้วย Ubuntu image มีคำสั่งดังนี้ [gist id="1cc7d811329f86cb642ca4f5311c3486" file="install.txt"] คำอธิบาย ติดตั้ง curl กับ vim ไว้ทดสอบกับแก้ไข config ทำการติดตั้ง NGINX Unit ตามเอกสารเลย เมื่อการติดตั้งเรียบร้อย ทำการตรวจสอบ service นิดหน่อยด้วยคำสั่ง [code] $service unitd status * unitd is running [/code]

โดยค่า default แล้วนั้น Unit API จะอยู่ในไฟล์ control.unit.sock

สามารถเรียกใช้งานและส่ง configuration ในรูปแบบ JSON เข้าไปได้ ซึ่งจะประกอบไปด้วย

Applications ทำการกำหนดแต่ละ application ใน Unit ว่าเป็นอย่างเช่น ภาษาโปรแกรม จำนวน worker process ที่ทำงาน Path หรือ directory ของ application และ ไฟล์ index และอื่น ๆ ตามภาษาโปรแกรม
Listeners สำหรับ application ที่ให้เข้าถึงผ่าน HTTP (ส่วน HTTPS ยังไม่สนับสนุนนะ) จะต้องกำหนด listenter ให้เสมอ หรือเปิด port นั่นเอง เพื่อให้ผู้ใช้งานเรียกใช้งานได้

เพื่อความเข้าใจมาลองใช้งานกันดีกว่า

เริ่มจากการดูว่าตอนนี้มี applicaition และ listener มีอะไรบ้าง ? แน่นอนว่าต้องไม่มีอะไรเลยดังนี้ [gist id="1cc7d811329f86cb642ca4f5311c3486" file="check.txt"]

ดังนั้นเรามาสร้าง application แรกดีกว่า (Hello World)

ซึ่งความต้องการเป็นดังนี้

พัฒนาด้วยภาษา PHP
ทำการ run ด้วย port 8100
Path ของระบบอยู่ที่ /www/hello
ไฟล์ index ชื่อว่า index.php

สามารถทำการเขียนไฟล์ configuration ได้ดังนี้ [gist id="1cc7d811329f86cb642ca4f5311c3486" file="php_config.json"] ทำการ configuration หรือ re-configuration ผ่าน REST API ด้วยคำสั่งดังนี้ ง่ายสุด ๆ [gist id="1cc7d811329f86cb642ca4f5311c3486" file="php.txt"] ตรวจสอบการ configuration ด้วยคำสั่งเดิม แต่ผลที่ได้ต่างออกไปดังนี้ [gist id="1cc7d811329f86cb642ca4f5311c3486" file="check2.txt"] แน่นอนว่าก็ต้องเตรียม code ของระบบงานไว้ให้พร้อมด้วยนะ จากนั้นทดสอบผลการทำงาน ได้ดังนี้ [gist id="1cc7d811329f86cb642ca4f5311c3486" file="index.txt"] เพียงเท่านี้ก็สามารถ run php แบบง่าย ๆ บน NGINX Unit ได้แล้ว แต่งานจริง ๆ ก็เตรียมเยอะกว่านี้นะ !! คำถามต่อมา สร้างได้ก็ต้องลบได้สิ เท่าที่ดูสามารถลบ Listener ได้ดังนี้ ส่วนลบ application ยังหาไม่เจอ [gist id="1cc7d811329f86cb642ca4f5311c3486" file="delete.txt"]

เมื่อ PHP ผ่านไป ก็มาถึง Python และ Go กันบ้างสิ

มาดูว่า NGINX Unit มันสนับสนุนจริงไหม ? มาดูกันนิดหน่อย สามารถแก้ไข configuration นิดหน่อยดังนี้

Python จะมี path และ module ที่จะใช้ run ซึ่งใช้ wsgi
Go จะมี executable สำหรับ binary ของระบบ โดยต้องติดตั้ง go ด้วยนะ เพราะว่าในการพัฒนาต้องใช้ library ข อง Unit ด้วย

ตัวอย่างให้มี PHP และ Python ในเครื่องเดียวกัน หรือ Unit เดียวกัน [gist id="1cc7d811329f86cb642ca4f5311c3486" file="config.json"] โดยสำหรับ python จะสร้างไฟล์หลักชื่อว่า wsgi.py ใน path ที่กำหนดดังนี้ [gist id="1cc7d811329f86cb642ca4f5311c3486" file="wsgi.py"] จากนั้นสามารถเข้าถึงผ่าน port 8200 ได้เลยดังนี้ [gist id="1cc7d811329f86cb642ca4f5311c3486" file="python.txt"]

ปล. ทั้ง PHP และ Python นั้นผมยังไม่ได้ติดตั้งอะไรนอกจาก NGINX Unit นะ

มาถึงตรงนี้น่าจะพอเห็นภาพคร่าว ๆ ของ NGINX Unit กันบ้างนะครับ

น่าจะมีประโยชน์ต่อการพัฒนาระบบงานกันบ้าง แต่ทำไปทำมานี่มันแนวคิด container เลยนะ แถมยังทำให้การพัฒนาและการ deploy ระบบในลักษณะ Microservice ง่ายขึ้นไปอีก และสุดท้ายก็เอาไป integrate หรือทำงานร่วมกับ NGINX ต่อไปได้เลย มองไปมองมา มันคือการ lock technology หรือเปล่านะ ? ส่วนเรื่องของ performance นั้นยังคงต่ำกว่าวิธีการอื่น ๆ นะ แต่มันยังคง beta version เท่านั้น ดังนั้นต้องติดตามอย่างใกล้ชิดนะ ขอให้สนุกกับเขียน code ครับ Reference Websites https://www.nginx.com/blog/introducing-nginx-application-platform/ http://unit.nginx.org/docs-nginx-unit.html

ในเทอมนี้มีโอกาสไปสอน Mobile programming with Android กับทีม ที่คณะ IT ของสถาบันเทคโนโลยีพระจอมเกล้าเจ้าคุณทหารลาดกระบัง หนึ่งในเครื่องมือที่บังคับให้ใช้คือ GitHub สำหรับจัดเก็บ source code และ Wiki ต่าง ๆ ทั้งหมด แต่ว่า GitHub มันมีความสามารถอื่น ๆ ที่น่าสนใจดังนี้

1. สามารถ edit หรือแก้ไข source code ได้

ดังนั้นถ้าต้องการแก้ไขเล็ก ๆ น้อย ๆ ก็สบายเลย

2. ใน Issue และ comment นั้นสามารถทำการ copy-and-paste รูปภาพไปได้เลยนะ

โดยจะทำการ upload ขึ้น github ให้เองเลย มันสะดวกมาก ๆ เพียงแค่ลากมาวางเท่านั้นเอง !!

3. ในพวกไฟล์ Markdown, Issue, Comment สามารถทำ Code Formatting ได้นะ

เพียงแค่บอกว่า code เป็นภาษาอะไรเท่านั้นเอง ภาษาที่สนับสนุนทั้งหมดดูที่นี่ Gramma Index

ผลการทำงานเป็นดังนี้

4. รู้ไหมว่า เราสามารถปิด issue ต่าง ๆ ผ่าน git commit message ได้ ?

ตัวอย่างเช่นถ้าต้องการ close หรือ ปิด issue หมายเลข 1 สามารถเขียน commit message ได้ดังนี้ Fixed #1 ดูเพิ่มเติมได้จาก Closing issue with keywords

5. สามารถ copy link ไปยัง code หรือบรรทัดที่ต้องการได้เลย

จุดนี้ใช้บ่อยมาก ๆ เมื่อเราทำการ review หรือพูดคุยกัน ดังนั้นทำการ copy link มาคุยกันเลย

6. ถ้าต้องการเขียน checklist ใน Markdown ทำอย่างไร ?

เป็นอีกหนึ่งความสามารถของ Markdown นะ สามารถเขียนได้ดังนี้

จะแสดงผลดังนี้

7. ค้นหาไฟล์ต่าง ๆ ใน repository ด้วยการกดปุ่ม t

จากนั้นก็พิมพ์สิ่งที่ต้องการหาเลย แสดงดังรูป

8. มีอีกอย่างที่ถามบ่อยคือ Google Chrome plugin ชื่อว่า Octotree

สำหรับการแสดงโครงสร้างของ repository ในรูปแบบ tree แสดงผลดังรูป

9. มีอีกนิดเผื่อยังไม่รู้ ถ้าใครต้องการใช้รูป profile ก็ง่ายมาก ๆ

ให้พิมพ์ .png ต่อท้ายชื่อ username ดังนี้ github.com/up1.png

สุดท้ายแล้วยังมีความสามารถอื่น ๆ อีกมากมาย เช่น

ดูเพิ่มเติมเกี่ยวกับ Github

วันนี้นักพัฒนามี account ใน GitHub กันหรือยัง ?

Reference Websites https://hackernoon.com/12-cool-things-you-can-do-with-github-f3e0424cf2f0 http://solutionoptimist.com/2013/12/28/awesome-github-tricks/

ถ้าใครสังเกตุเกี่ยวกับตำแหน่ง Developer/Programmer นั้น มักจะมีอายุเฉลี่ยไม่สูงมาก ๆ เนื่องจากมีเหตุผลมากมายมารองรับ ทั้งเรื่องของคนรุ่นใหม่ Gen X, Y, Z ทั้งเรื่องทัศนคติต่อการทำงาน ทั้งเรื่องค่าตอบแทนและสวัสดิการ ทั้ง career path ของงานในสายของ Developer มันสั้น ถ้าอยากขึ้นไปสูง ๆ เงินเดินสูง ๆ ก็ต้องไปสาย management สิ ดังนั้นเรามักจะเสีย Developer เก่ง ๆ ไปทำงานสายการประชุม เอ้ย ไม่ใช่ !! สายการจัดการมากยิ่งขึ้น จากนั้นบริษัทก็ไปจ้าง Developer ใหม่เข้ามา จะหาคนเก่ง ๆ มีประสบการณ์ ก็มีค่าตัวสูง ดังนั้นจ้างเด็ก ๆ มาดีกว่า ราคาถูกกว่า แต่ความคาดหวังคือ มาทดแทนสิ่งที่ขาดไป !! แน่นอนว่า ได้เพียงแค่จำนวน แต่คุณภาพไม่ได้ ดังนั้น แต่ละบริษัทจึงต้องมีการ training และ สอนงานกันต่อไป เมื่อเวลาผ่านไปสักพัก Developer ใหม่ ๆ นั้นเริ่มมีประสบการณ์ เริ่มเรียนรู้และมองเห็นอนาคตอย่างชัดเจนว่า ทำต่อไปไม่รุ่งแน่ ๆ เพราะว่า career path มันไม่เอื้อ หรือสภาวะแวดล้อมไม่ส่งเสริมให้โต ดังนั้นทำอย่างไรดีละ ? ออกไหม ? ไปเรียนต่อไหม ? เปลี่ยนสายงานไหม ? ไม่ว่าจะทางไหน ก็เข้าวงจรเดิมคือ คนที่มีประสบการณ์และเก่ง ๆ ก็หายไปอีก เป็นแบบนี้ไปเรื่อย ๆ

ปล. ไม่ได้เป็นทุกที่หรอกนะครับ ที่ผมเจอน่าจะส่วนน้อย

เช้านี้เห็นการ share บทความเรื่อง 7 Circles of Developer Hell

เป็น infographic ที่อธิบายและแสดงให้เห็นว่า การพัฒนา software มันเป็นสิ่งที่ ... มาก ๆ น่าจะสะท้อนอะไรหลาย ๆ อย่าง ในโลกของการพัฒนา software นะ โดยแบ่งเป็น 5 กลุ่มคือ

People
Client
Management
Bad code
Interruption

มาดูรายละเอียดกันบ้างสิ

บริโภคกันแต่เอกสาร ทำเอกสารเยอะไปไหน
ฝ่ายที่จ้างคนไม่ใช่ทีม แต่เป็นอีกหน่วยงานที่ไม่ได้เข้าใจความต้องการของทีม
ทาง marketing/sales/business ก็จะขายอย่างเดียว ก็จะเอาอย่างเดียว
ลูกค้าก็เปลี่ยนบ่อยเหลือเกิน งานเข้า งานงอก
ลูกค้ารู้ปัญหาของระบบก่อนทีมพัฒนา
ฝ่าย management ก็ตามงาน จิกเป็นไก่เลย เสร็จยัง เสร็จยัง !!
ฝ่าย management ก็มีประชุมเยอะเหลือเกิน บ่อยครั้งเป็นการโยนความผิดไปมา ไม่มีใครกล้าตัดสินใจ
เมื่องานมันเยอะ เวลาน้อย Developer ก็เลยตัดสินใจว่า ทำให้เสร็จ ทำให้เสร็จ โดยไม่สนใจผลที่ตามมา
สิ่งที่ Developer ต้องไปสู้รบคือ Legacy code ที่ไม่มีใครกล้าเตะ เมื่อพังก็โดนเล่นงานไป
ถามถึงเอกสารของระบบที่ทำกันเยอะ มันก็ไม่ช่วย เพราะว่าไม่ตรงกับ code อีก !!
บ่อยครั้ง Developer ก็สร้าง Legacy code ขึ้นมาเองอีก เอาเข้าไป
สิ่งที่ Developer ชอบทำเวลาโดนเร่งคือ ทำทำไปก่อน แก้ปัญหาด้วย workaround แก้ผ้าเอาหน้ารอดไปก่อน
สิ่งต่าง ๆ ที่ Developer ทำนั้น ทาง management, marketing และฝ่ายต่าง ๆ ชอบอีกด้วย เพราะว่าเร็วทันใจ
ยังไม่พอ Developer คนหนึ่ง ๆ มักจะงานมากกว่า 1 project เพราะว่า เราต้อง utilize คน !!
สุดท้ายสิ่งที่สร้างขึ้นมา กลับมาทำร้าย business อย่างรุนแรง !!

ถ้าการพัฒนา software ยังเป็นเช่นนี้ ก็อย่าหวังว่า จะได้ software ที่มีคุณภาพออกมา

คนต้องพร้อม ระบบต้องพร้อม สภาวะแวดล้อมต้องพร้อม ผลที่ตามมามันก็ต้องดีแน่นอน แต่ต้องใช้เวลา

วันนี้ Developer ในบริษัทหรือทีมของเรา อายุสั้นหรือเปล่านะ ?

ขอให้สนุกกับการ coding นะครับ Reference Websites https://blog.toggl.com/seven-circles-of-developer-hell/

วันนี้เห็นมีคน tweet เกี่ยวกับ Sketchnotes สำหรับอธิบายการทำงานของ Git ประกอบไปด้วย

Git pull
Git merge
Git rebase

สิ่งที่น่าสนใจคือ อธิบายการทำงานด้วยรูปแบบซึ่งน่ารักดี เลยนำมาฝาก เผื่อจะทำให้การอธิบายเรื่อง Git ไม่น่าเบื่ออีกต่อไป มาเริ่มที่ Git pull

ต่อด้วย Git merge และ rebase

ขอให้สนุกกับการใช้งาน Git นะครับ