Espresso :: การแก้ไขปัญหาเรื่อง permission บน Android M

February 29, 2016, 7:08 am

≪ Previous: ทำการติดตั้งภาษา Swift บน Docker กันดีกว่า

android-espresso-permission

วันนี้เจอปัญหาที่น่าสนใจสำหรับการทดสอบ Android app ด้วย Espresso มีอาการ คือ ไม่สามารถทำการทดสอบได้ และ ผลการทดสอบผิดพลาด ซึ่งเป็นปัญหาเกี่ยวกับ permission ของ Android app นั่นเอง โดยจะเจอปัญหานี้บน Android M หรือ Android 6 Marshmallow เนื่องจากรูปแบบของการจัดการ permission ที่เปลี่ยนไป มาดูวิธีการแก้ไขว่าทำอย่างไร ? ป.ล. สามารถอ่านเพิ่มเติมเรื่อง Working with Permission ได้ที่ Android Developer ขอขอบคุณผู้สร้างปัญหา คุณเก้อ

ปัญหาที่พบเจอเป็นดังนี้

ผลการทดสอบผิดพลาด
จำนวน test case ลดลง !!

ที่สำคัญจะมีปัญหาบน Android M เท่านั้น และใน Logcat จะเจอ exception แบบนี้เยอะมาก ๆ [code] java.lang.SecurityException: getDeviceId: Neither user 10340 nor current process has android.permission.READ_PHONE_STATE. [/code]

วิเคราะห์ปัญหากันหน่อย

ประเด็นหลักคือ เจอเฉพาะบน Android M เท่านั้น รวมทั้งมี exception ใน Logcat ซึ่งบอกปัญหาเรื่อง permission ทำให้นึกถึงสิ่งที่เปลี่ยนแปลงไปใน Android M คือ รูปแบบการจัดการ permission และ การขอ permission จากผู้ใช้งาน นั่นคือ จะทำการขอสิทธ์ทีละ permission ดังนั้นจึงลองทดสอบสมมุติฐาน ด้วยการติดตั้งไฟล์ APK ของ Android App ในเครื่องทดสอบ จากนั้นเข้าไปดู permission ของ app ก็พบว่า permission ที่กำหนดไว้ในไฟล์ AndroidManifest.xml นั้น ไม่ได้เปิด หรือ อนุญาตเลย เป็นที่มาของปัญหาข้างต้นนั้นเอง !!

เมื่อรู้ปัญหาเรียบร้อยแล้ว ต่อมาคือ เราจะแก้ไขอย่างไรดีล่ะ ?

เริ่มจากการทำความเข้าใจขั้นตอนการทำงานก่อน เนื่องจากใน Android Studio นั้นทำการ build และ deploy ด้วย Gradle ดังนั้น เราควรรู้ว่า tasks หรือ ขั้นตอนการทำงานต่าง ๆ ของ Gradle เป็นอย่างไรบ้าง สามารถดู task ต่าง ๆ ด้วยคำสั่ง [code] $gradlew tasks [/code] จากนั้นต้องรู้ขั้นตอนการทำงานของแต่ละ task ด้วย โดยขั้นตอนที่ต้องรู้ เพื่อแก้ไขปัญหาประกอบไปด้วย

ทำการสร้างไฟล์ APK ตอนไหน ?
ทำการติดตั้งไฟล์ APK ไปยัง device ตอนไหน ?
ทำการทดสอบด้วย Espresso ตอนไหน ?

ซึ่งเราต้องตอบคำถามเหล่านี้ให้ครบ โดยผมเน้นที่ส่วนของ Dev คือ

assembleDevDebugAndroidTest
installDevDebug
connectedDevDebugAndroidTest

ถ้าอยากรู้ว่าเราเข้าใจถูกหรือไม่ ก็ลองใช้คำสั่ง [code] $gradlew assembleDevDebugAndroidTest $gradlew installDevDebug $gradlew connectedDevDebugAndroidTest [/code]

ปัญหาต่อมาคือ เราจะเพิ่มสิทธิ์ permission ตรงไหนดีล่ะ ?

ตอบง่าย ๆ เลยก็คือ หลังจากที่ทำการติดตั้ง APK ไปยัง device ไงล่ะ

ปัญหาต่อมาคือ เราจะเพิ่มสิทธิ์ permission อย่างไรดีล่ะ ?

สำหรับ Android Devleoper ไม่น่าจะยากเท่าไร เพราะว่า เราจะทำการจัดการผ่านเครื่องมือที่ชื่อว่า adb (Android Debugging Bridge) ซึ่งมีอยู่แล้วใน Android SDK

ถ้า Android Developer คนไหนไม่รู้ ขอแนะนำให้ศึกษาเพิ่มเติมนะครับ

โดยเราสามารถทดสอบเพิ่มสิทธ์ permission ด้วยคำสั่ง [code] $adb shell pm grant "package name of app" "YOUR PERMISSION" [/code] ถ้าต้องการระบุ device ด้วย ใช้คำสั่ง [code] $adb -s "devicename" shell pm grant "package name of app" "YOUR PERMISSION" [/code] เมื่อทดลองเพิ่มสิทธิ์ไปแล้ว อย่าลืมไปลองเล่น app ใน device ด้วยนะ ซึ่ง app ของเราจะไม่ถาม permission อีกเลย แต่ถ้าเปิด app มาแล้วขึ้นหน้าจอแบบนี้ แสดงว่ายังทำไม่สำเร็จนะ !! request_permission_dialog_2x

ปัญหาต่อมาคือ แล้วจะเพิ่มขั้นตอนการเพิ่มสิทธิ์เข้าไปในขั้นตอนของ Gradle อย่างไร ?

เนื่องจากไม่อยากทำงานเดิมซ้ำ ๆ มันน่าเบื่อมาก ๆ ขั้นตอนการทำงานแบบอัตโนมัติต้องทำงานแบบนี้

ทำการ uninstall app ออกจาก device ที่ต้องการ
ทำการสร้างไฟล์ APK
ทำการติดตั้งไฟล์ APK ไปยัง device ที่ต้องการ
ทำการเพิ่มสิทธิ์ของ app ในแต่ละ device
ทำการทดสอบการทำงานของ app ด้วย Espresso

ใน Gradle นั้นอนุญาตให้เราสามารถเพิ่ม task เข้ามาเองได้เลย ดังนั้น ผมจึงทำการสร้าง task ใหม่ชื่อว่า grantPermissions มีการทำงานดังนี้

ให้ทำงานหลังจากที่ทำงานติดตั้งไฟล์ APK ไปยัง device หรือ ก่อนการทดสอบด้วย Espresso
เนื่องจากสามารถต่อ device ได้หลาย ๆ เครื่อง ดังนั้นต้องทำการเพิ่มสิทธิ์ไปยังทุกเครื่องด้วย

ขั้นตอนการเขียน task ชื่อว่า grantPermissions เป็นดังนี้ สร้าง task ในไฟล์ build.grade ของ app [gist id="9a26521e31f246afb849" file="build.gradle"] จากนั้นสร้างไฟล์ grant_permissions.sh ขึ้นมาเพื่อเพิ่มสิทธ์ให้ทุก ๆ device ดังนี้ [gist id="9a26521e31f246afb849" file="grant_permissions.sh"] เพียงเท่านี้ก็สามารถแก้ไขปัญหา และ ใช้งานได้แล้ว ด้วยคำสั่ง [code] $gradlew unInstallAll connectedDevDebugAndroidTest [/code] ขอให้โลกสงบสุขครับ Reference Websites http://www.savinoordine.com/grantrevoke-permission-with-adb-android-m/ http://testdroid.com/news/how-android-m-new-app-permissions-impact-on-existing-apps https://www.androidpit.com/android-m-release-date-news-features-name https://greenify.uservoice.com/knowledgebase/articles/749142-how-to-grant-permissions-required-by-some-features http://www.fulcrumapp.com/blog/automated-ui-testing-and-fulcrum-android-permissions/

↧

ว่าด้วยเรื่องของ Data Science

March 1, 2016, 11:37 am

≫ Next: แปลเรื่อง Performance Testing

≪ Previous: Espresso :: การแก้ไขปัญหาเรื่อง permission บน Android M

ในปัจจุบันเรื่องของ Data Science ถูกพูดถึงกันอย่างมาก มักจะมาพร้อมกับคำว่า Big Data ดังนั้น เราดูกันหน่อยว่า

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

มาเริ่มหาคำตอบกัน

ที่มาที่ไปของ Data Science

เริ่มถูกพูด และ เขียนขึ้นมาครั้งแรกในปี 1962 จาก paper เรื่อง The Future of Data Analysis โดยคุณ John W. Tukey ทำการอธิบายถึงแนวทางการวิเคราะห์ข้อมูล ว่าโปรแกรมคอมพิวเตอร์ จะเข้ามามีความสำคัญอย่างไรในอนาคต ทาง Forbes ได้สรุปที่ไปที่มาของ Data Science ในบทความเรื่อง A Very Short History of Data Science ซึ่งมันละเอียดอย่างมาก แนะนำให้อ่านเพิ่มเติมนะครับ โดยตั้งแต่ปี 1990 เป็นต้นมา Data Science เติบโตมาอย่างก้าวกระโดด และกลายมาเป็นงานที่มีความต้องการอย่างสูงตั้งแต่ปี 2000 ส่วนปัจจุบันหลายสำนักบอกว่า เป็นงานที่ sexy สุด ๆ ไปแล้ว !! แต่จำเป็นต้องมีทักษะความรู้ในหลากหลายแขนงเช่นกัน แสดงดังรูป

ปัจจุบัน Data Science เป็นอย่างไร ?

คำว่า Data Science กับ Data Analysis มันมักจะมาคู่กัน มีอัตราเติบโต และ ความต้องการจากบริษัทต่าง ๆ สูงมาก เนื่องจากค่าใช้จ่ายด้านที่จัดเก็บข้อมูล (Stoarge) นั้นถูกลงอย่างมาก เนื่องจากวิธีการประมวลผลข้อมูล (Processing) มีประสิทธิภาพสูงขึ้น ส่งผลทำให้แต่ละบริษัท สามารถทำการทำการ regression ค้นหาประโยชน์ และ แนวโน้มต่าง ๆ จากข้อมูลจำนวนมากที่จัดเก็บไว้ ทั้งข้อมูลจากภายในบริษัท และ ข้อมูลจากข้างนอก โดย Data Science จะเข้ามาช่วยเรื่องของ คุณภาพของข้อมูลก่อนที่จะนำมาประมวลผล

เนื่องจาก ถ้าข้อมูลเริ่มต้นมันห่วยแล้ว ผลการประมวลผลมันก็ห่วยเช่นกัน

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

สามารถแบ่งส่วนการทำงานออกไป 2 ส่วน คือ

ข้อมูลมาจากไหน ? (Data source)
จะใช้ข้อมูลเหล่านั้นอย่างไร ?

เริ่มจากข้อมูลมาจากไหน นั่นคือ Data Source

ในปัจจุบันนั้นที่มาของข้อมูลมันเยอะมาก ๆ แสดงตัวอย่างดังรูป datasource

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

โดยแหล่งข้อมูลสามารถแบ่งได้ 3 กลุ่มใหญ่ ๆ คือ

Database ประกอบไปด้วยข้อมูลที่มีโครงสร้าง และ ไม่มีโครงสร้าง
Third party data
Application data

คำถามที่น่าสนใจ คือ จะเริ่มนำข้อมูลมาจากแหล่งไหนดีล่ะ ? เนื่องจากแต่ละระบบมีแหล่งข้อมูลเยอะมาก ๆ รวมทั้งจากหลากหลาย vendor อีก ไหนจาก API ต่าง ๆ อีกมากมาย แน่นอนว่ามันเป็นงานที่ไม่ง่ายเลย และไม่มีใครอยากจะเข้ามาทำสักเท่าไร เนื่องจากต้องทำการ integration เข้ากับระบบ เนื่องจากต้องทำการแปลงข้อมูลให้อยู่ในรูปแบบที่ต้องการ เนื่องจากต้องกรองและทำความสะอาดข้อมูลก่อนทำการจัดเก็บ และอื่น ๆ อีกมากมาย !! คำตอบที่ดีก็คือ ให้ลองคิดคำนวณเรื่องของ Return on Investment (ROI) ของแหล่งข้อมูลแต่ละที่ ว่ามันมีคุณค่าและให้ผลตอบแทนในการลงทุนมากน้อยเพียงใด

ดังนั้นสามารถสรุปสิ่งที่ Data Scientists ต้องทมีดังนี้

การค้นหาข้อมูลที่ค้องการ
การจัดการโครงสร้าง จัดเรียงข้อมูล และ ทำความสะอาด (Cleansing data)
การวิเคราะห์ข้อมูล
เชื่อมโยงข้อมูลและผลการวิเคราะห์ในแต่ละส่วนเข้าด้วยกัน
แสดงผลการวิเคราะห์ให้อยู่ในรูปแบบที่เข้าใจง่าย

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

วันนี้คุณพร้อมกับ Data Science แล้วหรือยัง ?

Reference Websites https://github.com/okulbilisim/awesome-datascience http://www.forbes.com/sites/gilpress/2013/05/28/a-very-short-history-of-data-science/ https://dzone.com/articles/a-deep-dive-into-the-world-of-data-science https://www.facebook.com/DataScience101/ http://www.exploringdatascience.com/the-data-science-clock/

↧

แปลเรื่อง Performance Testing

March 2, 2016, 1:04 am

≫ Next: เพิ่มความเร็วของทีม ด้วยการช้าลง !!

≪ Previous: ว่าด้วยเรื่องของ Data Science

perf

ทำการแปลบางส่วนจากบทความเรื่อง Performance Testing in a Nutshell ซึ่งทำการอธิบายเรื่องของ Performance Testing ได้อย่างน่าสนใจ ทั้งแนวคิด และ แนวทางในการทดสอบ ทั้งการเตรียม environment ต่าง ๆ ทั้งการเขียน script เพื่อทดสอบ ทั้งการวิเคราะห์ผลการทดสอบ ทั้งการ monitoring ระบบ และ Lesson learn ต่าง ๆ ดังนั้น เรามาเริ่มเดินทางไปยัง Performance Testing กันเลย

เรื่องของ Performance testing เป็นสิ่งที่มักหลงลืมกันได้ง่าย

แต่มักจะมีความสำคัญเมื่อถึงเวลาส่งมอบระบบงาน (Deadline) เนื่องจาก เรามักทดสอบในช่วงท้ายของการพัฒนาระบบงาน ทำเหมือนกับว่า การทดสอบมันไม่จำเป็น หรือ เป็นชนชั้นที่สอง !! คำถามคือ ถ้าทดสอบแล้วไม่ผ่านจะต้องทำอย่างไร ? 1. ต้องแก้ไขให้ทดสอบผ่านให้ได้ บ่อยครั้งต้องรื้อ !! 2. ขยายเครื่องได้ไหม ? บ่อยครั้งมันคือการหนีปัญหา 3. ปล่อยมันไปก่อน พยายามพูดต่าง ๆ นานา เพื่อให้ลูกค้ายอมรับ 4. ??? ดังนั้น ความท้าทายหนึ่งที่ เราจะต้องทำก็คือ การทำ Performance testing ตั้งแต่เริ่มการพัฒนาระบบงาน แต่ว่าจะทำอย่างไรดีล่ะ ?

ก่อนจะเริ่มทำการทดสอบ ควรต้องทำความเข้าใจระบบ

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

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

ในการพัฒนาระบบงานนั้น

เรื่องการทดสอบ Performance ควรจะต้องเกิดขึ้นอยู่อย่างเสมอ และเป็นสิ่งที่ต้องการการทำงานเป็นทีม ทั้ง developer, tester, operation และคนที่เกี่ยวข้อง เพื่อทำการทดสอบ ดูแลรักษาระบบ และให้ผลการทดสอบมันใกล้กับสิ่งที่คาดหวังไว้ เนื่องจากการทดสอบมันต้องการคนที่มีความรู้มากมาย ไว้ว่าจะเป็นเรื่อง การเขียน test script ไม่ว่าจะเป็นเรื่อง การใช้เครื่องมือ ไม่ว่าจะเป็นเรื่อง การวิเคราะห์ผล ไม่ว่าจะเป็นเรื่อง การ monitoring ระบบ ไม่ว่าจะเป็นเรื่อง แผนการทดสอบ ไม่ว่าจะเป็นเรื่อง การทดสอบซ้ำ ซึ่งต้อง reset ระบบกลับไปยังจุดเริ่มต้นเหมือนกัน ไม่ว่าจะเป็น .... มันเยอะมาก ๆ ดังนั้นมาดูกันว่า เราจะต้องเตรียมอะไรกันบ้าง ?

1. เรื่องของ Environment

ถ้าเป็นแต่ก่อนเราจะใช้เครื่องภายในองค์กร แต่มันก็มีข้อจำกัดหลาย ๆ อย่าง ซึ่งปัจจุบันมีเรื่องของ Cloud เข้ามาช่วย ทำให้การทดสอบมันง่ายและสะดวกมากยิ่งขึ้น ที่สำคัญ การดูแลรักษาก็ง่ายกว่าเดิมอีก แต่ถ้าองค์กรไหนที่มีข้อจำกัดมากมาย เช่นการเข้าถึง server ต่าง ๆ จากภายนอกต้องผ่าน VPN, Firewall หรือบางที่ก็ไม่สามารถเข้าถึงได้เลย มีทางเดียวก็คือ ต้องซื้อเครื่องที่ใหญ่กว่าเดิม หรือ จำนวนเครื่องมากขึ้น เพื่อทำให้การทดสอบมันมากขึ้นนั่นเอง

มาถึงเรื่องของ configuration ต้องคล้ายหรือเหมือน production ให้มากที่สุด เพื่อลดความผิดพลาดต่าง ๆ จากการทดสอบ

2. เรื่องของ test script

ประกอบไปด้วย การจัดการเรื่อง session การจัดการเรื่อง caching และที่สำคัญมากคือ ควรทำการทดสอบในหลาย ๆ layer ตาม Pyramid testing ตัวอย่างเช่น การทดสอบระดับ functional การทดสอบในระดับ service การทดสอบในระดับ integration ระหว่าง service การทดสอบในระดับ system

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

3. เรื่องของระบบ Monitoring ระบบ

ในการทดสอบ performance ของระบบนั้น ระบบ monitoring มันมีความสำคัญอย่างมาก ขาดไม่ได้เลย คำถามแรก คือ ทำอย่างไรล่ะ ? การติดตั้งเครื่องมือสำหรับระบบ monitoring นั้น ควรให้อยู่ใกล้กับ application server ให้มากที่สุด เพื่อหลีกเลี่ยงปัญหาทางด้าน network เพื่อหลีกเลี่ยงปัญหาการสูญหายของข้อมูล แต่ไม่ควรติดตั้งไว้เครื่องเดียวกับระบบที่ถูกทดสอบโดยเด็ดขาด มิเช่นนั้น มันจะส่งผลกระทบต่อผลการทำงานของระบบ !! คำถามต่อมา เราจะวัดค่าอะไรจากระบบ Monitoring บ้างล่ะ ? แบ่งออกเป็นสองส่วนคือ 1. Application level สิ่งที่ต้องดูเลยก็คือ

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

2. Infrastructure level สิ่งที่ต้องดูเลยก็คือ การใช้งาน CPU และ Memory ของแต่ละเครื่อง และ service ซึ่งมีเครื่องมือในการแสดงผล และ วิเคราะห์ เช่น Graphite, Jemalloc และ JProfile เป็นต้น เมื่อทำการทดสอบเสร็จสิ้นในแต่ละครั้งควรทำการบันทึกผลไว้เสมอ มันจะทำให้เราเห็นว่า การทำงานของระบบมีแนวโน้มอย่างไร จากนั้นทำการวิเคราะห์เจาะเกมส์ เพื่อทำให้เรารู้ว่าต้องปรับปรุงและแก้ไขอย่างไร ว่าระบบส่วนไหนเกิดปัญหาคอขวดบ้าง ทั้งวิธีการทดสอบ และ ระบบงาน

4. เรื่องของเครื่องมือ

การเลือกเครื่องมือสำหรับการทดสอบ performace มันเป็นอีกเรื่องที่สำคัญ โดยมีคำแนะนำสำหรับการเลือกดังนี้

ง่ายต่อการสร้าง และ ดูแล user agent หรือไม่ ?
ง่ายต่อการสร้าง และ ดูแลการทดสอบหรือไม่ ?
มี log ไว้สำหรับการ debug และ ตรวจสอบผลการทดสอบหรือไม่ ?
สร้างจำนวน user session เยอะ ๆ หรือไม่ ?
สามารถจัดการเรื่องของ Ramp up/Ramp down ได้หรือไม่ ?
สามารถทดสอบแบบ Data-Driven ได้หรือไม่ ?
สามารถทำงานร่วมกับระบบ Web และ API ได้หรือไม่ ?
สามารถทำงานหลาย OS ได้หรือไม่ ?
สามารถจัดเก็บประวัติการทดสอบได้หรือไม่ ?
สามารถแสดงผลการทดสอบในรูปแบบต่าง ๆ ได้หรือไม่ ?
สามารถทำงานแบบอัตโนมัติร่วมกับระบบ Continuous Integration ได้หรือไม่ ?
สามารถทำงานบน mobile ได้หรือไม่ ?
สามารถทดสอบบน browser ชนิดต่าง ๆ ได้หรือไม่ ?
สามารถจำลองความเร็วของ network ได้หรือไม่ ? เช่น 2G, 3G เป็นต้น

ปิดท้ายด้วย Lesson learn ที่น่าสนใจ

1. หลีกเลี่ยงการทำงานแบบ backgroud process เนื่องจากเป้าหมายหลักของการทดสอบ เพื่อรองรับและให้บริการแก่ผู้ใช้งาน หรือ ลูกค้า ดังนั้น ถ้าแต่ละ request จากผู้ใช้งานมายังระบบงาน แล้วระบบไปทำงานเหล่านั้นแบบ background process มันคือการซ่อนปัญหาไว้ ข้อดีของการทำแบบนี้คือ ระบบทำงานได้อย่างรวดเร็ว ข้อเสียของการทำแบบนี้คือ เพิ่มความซับซ้อนของระบบขึ้นอย่างมาก การแก้ไข คือ ควรเพิ่มจำนวนเครื่องขึ้นมา เพื่อรองรับผู้ใช้งานดีกว่านะ 2. การทดสอบแต่ละครั้ง ควรเปลี่ยนค่าต่าง ๆ เพียงหนึ่งค่าเท่านั้น (One Parameter Principle ) ในการทดสอบนั้น เรามักจะทำการแก้ไขค่า configuration ต่าง ๆ แต่ขอแนะนำให้เปลี่ยนครั้งละ 1 ค่าเท่านั้น เพื่อทำให้เราเห็นว่า ค่าใดมันส่งผลดีผลเสียต่อระบบบ้าง ดังนั้น ให้ทำการทดสอบแบบ small step แบบนี้ไปเรื่อย ๆ ทำการวิเคราะห์ และ แก้ไขต่อไป 3. ให้คิดถึงพฤติกรรมการใช้งานจริง ๆ ของผู้ใช้งานเป็นหลัก Flow ของการทดสอบนั้น ควรเป็นสิ่งที่ผู้ใช้งานส่วนใหญ่ใช้จริง ๆ มิใช่การมโนขึ้นมาเอง ถ้าเป็นระบบงานเดิม หรือ Legacy system ก็ให้เอาข้อมูลจาก production server มาวิเคราะห์ซะ 4. ว่าด้วยเรื่องของการทำ Caching ในบางครั้งการทำ caching ขึ้นมาก็ช่วยทำให้ประสิทธิภาพของระบบดีขึ้น แต่ในบางครั้งก็ไม่ได้ส่งผลดีอะไรขึ้นมา ดังนั้น ตรงนี้ควรทำความเข้าใจเกี่ยวกับ caching ให้ดี แถม caching มันมีหลาย layer อีกด้วย

ไม่ว่าจะเป็นระดับ network
ไม่ว่าจะเป็นระดับ application
ไม่ว่าจะเป็นระดับ service
ไม่ว่าจะเป็นระดับ database

5. ระมัดระวังการ query ที่ใช้เวลา และ resource เยอะ ๆ ถ้า query สำหรับการดึงข้อมูลจาก database มันแย่ มันช้า หรือ ใช้ resource มากมาย จะส่งผลให้การทำงานของระบบช้าลงไปอย่างมาก ดังนั้นสิ่งที่ต้องมีก็คือ ระบบ monitoring สำหรับการทำงานของการ query หรือ Slow log เพื่อทำให้เรารู้ว่า มีจุดใจที่ต้องแก้ไขบ้าง 6. ลดจำนวนการเรียกใช้งานระหว่างระบบ มักพบว่าระหว่างฝั่ง frontend และ backend นั้น ในแต่ละ feature มักจะมีการเรียกใช้งาน backend จาก frontend จำนวนมาก บางครั้งมากจนเกินไป หรือ ถี่จนเกินไป ดังนั้น แนะนำให้ลดจำนวนการเรียกใช้งานลงซะ

วันนี้คุณทำ Performance testing กันหรือยัง ? วันนี้คุณทำ Performance testing กันอย่างไร ?

↧

เพิ่มความเร็วของทีม ด้วยการช้าลง !!

March 3, 2016, 2:33 am

≫ Next: Code ที่ developer ทำงานอยู่ด้วยนั้น มีอายุเท่าไร ?

≪ Previous: แปลเรื่อง Performance Testing

speed-up

คำพูดเกี่ยวกับทีมพัฒนาที่มักได้ยินจากฝ่าย Management, Team lead, Product Manager และ ... คือ ทีมพัฒนาทำงานช้า หรือ ทำงานยังไม่เร็วตามความต้องการ คำถามคือ ถ้าต้องการให้ทีมพัฒนาทำงานเร็วขึ้นต้องทำอย่างไร ? คำตอบที่มักจะได้รับคือ

ตัดเรื่องคุณภาพออกไป หรือ ลดลง
ทำ OT สิ
ทำให้มันเร็วขึ้นสิ
เพิ่มคนสิ

ผลที่ได้รับกลับมาเป็นอย่างไร ?

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

คำถามที่ต้องถามตัวเราเอง คือ แนวทางแบบนี้มันคือการเพิ่มความเร็วจริงหรือ ?

หรือว่า มันกลับทำให้เราช้าลงไปกว่าเดิม ? ทั้งในแง่คุณภาพของระบบ ทั้งในแง่คุณภาพของ code ทั้งในแง่การทำงานเป็นทีม ดังนั้น เรามาเรียนรู้จากความผิดพลาดเหล่านี้กัน เพื่อไม่ให้เราผิดซ้ำที่เดิมอีก ก่อนอื่นเราควรมาทำความรู้และเข้าใจกับคำว่า ความเร็ว (Speed) ทีมจะทำงานได้อย่างรวดเร็ว ก็ต่อเมื่อแต่ละคนในทีม

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

แต่ดูมันเยอะนะ ตอบได้เลยว่า ใช่

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

เรื่องของความเร็ว (Speed) มันประกอบด้วยหลาย ๆ สิ่ง แต่มีส่วนประกอบหลัก 2 อย่างคือ

Throughput
Cycle time

ถ้าเป็นความเร็วของการพัฒนา Softwate สามารถอธิบายได้ว่า

Throughput คือ จำนวนงานที่พัฒนาเสร็จในช่วงเวลาหนึ่ง ๆ
Cycle time คือ จำนวนเวลาของการพัฒนางานหนึ่ง ๆ ให้เสร็จ

คำเตือน !! เราสามารถทำการเพิ่ม Throughput และลด Cycle time ได้ก็ต่อเมื่อ เราเข้าใจมันดีพอแล้วเท่านั้น มิเช่นนั้น แทนที่จะทำให้ดีขึ้น กลับเลวร้ายลงกว่าเดิม หรือเกิดผลกระทบมากมายตามมา

Throughput

ส่วนใหญ่ชอบเทียบด้วยจำนวนรถยนต์ที่วิ่งบนถนน ซึ่งวิ่งจากที่หนึ่งไปอีกที่หนึ่งในเวลาที่กำหนด คำถามเราจะเพิ่มจำนวน Throughput ได้อย่างไร ? เพิ่มจำนวนรถเข้าไปให้ได้มากที่สุด เท่าที่ถนนจะรองรับได้ไงล่ะ ทำการวัดความเร็วจาก จำนวนรถที่วิ่งถึงเป้าหมายในเวลาที่กำหนด ดังนั้นรถทุกคันต้องวิ่งด้วยความเร็วที่สูงขึ้น แต่ลองคิดดูสิว่า รถก็เยอะ วิ่งก็เร็ว แล้วมันจะปลอดภัยหรือ ? จะเกิดอุบัติเหตุบ่อยไหม ? ถ้าเกิดอุบัติเหตุขึ้นมาสักจุดบนถนน การจราจรจะติดขัดมากน้อยเท่าไร ? ดังนั้น การเพิ่มความเร็วของรถ ไม่เพียงทำให้เรากลัวเท่านั้น ยังอาจจะทำให้เกิดการบาดเจ็บ ล้มตาย ยังอาจจะทำให้ระบบหยุดทำงานอีกด้วย สุดท้ายดันไปทำให้ค่าของ Throughput ลดลงไปอีก !! การพัฒนา Software ของทีมก็เช่นเดียวกัน เราต้องการกระบวนการการทำงานที่ปลอดภัย นั่นคือ ต้องมีคำว่าคุณภาพในระดับที่ยอมรับร่วมกันทุกฝ่าย แต่ถ้าตัด หรือ ลด สิ่งเล็ก ๆ ที่เรียกว่า คุณภาพลงไป คุณต้องพบเจอความน่าสะพรึงกลัวมากมายตามมา !! แต่เรากลับพบว่า สิ่งเหล่านี้ มันคือ ความปกติที่เกิดขึ้นอยู่ในทุกทีม ทุกองค์กร !! ดังนั้น เชื่อเถอะว่า คุณไม่ได้เดินอย่างเดียวดาย (You will never walk alone) กลับมาดูว่า สิ่งที่ทำให้เราช้ามีอะไรบ้าง ? ช่วยกันแก้ไข ช่วยกันปรับปรุง ช่วยกันหา way of work ใหม่ ๆ กัน บางคนถามว่า ถ้าเราหยุดเพื่อแก้ไข ปรับปรุง แล้ว มันจะไม่ช้าลงหรือไง ? ตอบได้เลยว่าช้าลงอย่างแน่นอน แต่เฉพาะในช่วงแรกเท่านั้น ต่อจากนั้นคุณจะเร็วขึ้นอย่างต่อเนื่อง

Cycle time

เป็นค่าที่บอกว่า คุณมีความเร็วเท่าไรต่อการทำงานงานหนึ่ง ๆ ให้เสร็จสิ้น หรือความเร็วของทีม ในการตอบสนองต่อสิ่งหนึ่ง ๆ เช่น bug !! ตัวอย่างง่าย ๆ ของ Cycle time คือ การเข้าคิวซื้อและรับของในร้านกาแฟ คุณใช้เวลาเท่าไรในการเข้าคิวกว่าจะได้กาแฟตามที่ต้องการ ถ้าใช้เวลาในการรอนาน ๆ นั่นหมายถึง คุณสร้างประสบการณ์ที่แย่ ๆ ให้กับลูกค้า มันย่อมไม่ใช่สิ่งที่ดีนัก !! ไม่ว่ากาแฟจะรสชาติดีเพียงใด ไม่ว่าคนชงจะเก่งขนาดไหน

ซึ่งการปรับค่าของ Cycle time ให้ลดลงนั้น ไม่สามารถทำได้ด้วยการเพิ่มคุณภาพ ไม่สามารถทำได้ด้วยการเพิ่มจำนวน Throughput เพราะว่ายิ่งเพิ่มสิ่งต่าง ๆ เหล่านี้เข้าไป ยิ่งทำให้เวลารอนานขึ้นไปอีก

แล้วทำอย่างไรดีล่ะ ?

คุณน่าจะรู้และเข้าใจว่า การเพิ่มจำนวน Throughput ไม่ได้ช่วยเพิ่มความเร็วเลย ดังนั้น สิ่งที่ต้องทำคือ รู้ก่อนว่าตัวเองมีความสามารถเท่าไร ? หรือจำนวนงานเท่าไร ที่สามารถทำให้เสร็จในช่วงเวลาหนึ่ง นั่นคือจงหาค่า Limit Work In Progress (WIP) ซะ

คำถามคือใครจะบอกได้ล่ะ ? ตอบง่าย ๆ ว่า ทีมที่ทำไงล่ะ จงเรียนรู้ไปด้วยกัน

ส่วน Cycle time ที่ดี ก็คือ ต้องสั้นที่สุดเท่าที่จะทำได้ ถ้าต้องการให้ชงกาแฟเร็วขึ้น วิธีการง่าย ๆ คือ ลดคุณภาพของการชง ซึ่งมันไม่ดีอย่างแน่นอน ทั้งต่อร้าน และ ลูกค้า !! ดังนั้นวิธีการที่เหมาะสมก็คือ

เพิ่มจำนวนคนชงสิ
แบ่งขั้นตอนการชงออกมาสิ

แต่สำหรับการพัฒนา Software แล้ว !! การเพิ่มคนเข้าไปในระหว่างการพัฒนา มันกลับทำให้ยิ่งช้าลง สิ้นเปลืองค่าใช้จ่าย และเพิ่มความซับซ้อนให้กับทีมอีก เพราะว่า คนเยอะขึ้นการพูดคุยก็เยอะขึ้นอีก !! มันยากเนาะ การพัฒนา Software ดังนั้นแทนที่จะทำการเพิ่มคนเข้ามา ให้กลับไปดูงานที่อยู่ในการพัฒนาดีไหม ว่ามันเยอะเพียงใด ? ทำการจัดเรียงลำดับความสำคัญ ทำการเลือกสิ่งที่สำคัญมาทำก่อน นั่นคือ การลดจำนวนงานลงไป จากสายการผลิต ตาม Limit WIP ของทีม จำนวนงานที่น้อยลงในแต่ละรอบการทำงาน มันยิ่งทำให้เราเข้าใจรายละเอียดของสิ่งที่จะทำมากขึ้น มันยิ่งทำให้เราพูดกันมากขึ้น ทั้งสิ่งนั้นคืออะไร ? ทั้งทำสิ่งนั้นไปทำไม ? ทั้งทำสิ่งนั้นไปเพื่ออะไร ? และที่สำคัญการรอของแต่ละ feature ก็น้อยลงนะ !!

แต่การจะทำสิ่งเหล่านี้ได้ ต้องสร้างสภาวะแวดล้อมที่เอื้อด้วย

ทั้งความเชื่อมั่นใจในทีม ทั้งทีมต้องทำให้เชื่อมั่น เมื่อต่างฝ่ายต่างเชื่อมั่นซึ่งกันและกัน เมื่อนั้นคุณจะเห็นความเร็วที่แท้จริง

↧

Code ที่ developer ทำงานอยู่ด้วยนั้น มีอายุเท่าไร ?

March 4, 2016, 7:38 am

≫ Next: การ Deploy Software คือการแก้ไขหรือสร้างปัญหากันแน่ ?

≪ Previous: เพิ่มความเร็วของทีม ด้วยการช้าลง !!

speak-code

จากบทความเรื่อง Longevity of Source Code ทำการวิเคราะห์ code ได้อย่างน่าสนใจ จึงนำมาสรุปบางส่วน ดังนี้ Developer ทุกคนลองกลับไปดู code ที่ทำงานอยู่ด้วยทุกวันดูสิว่า

Code เหล่านั้นมันอายุเท่าไร ?
Code เหล่านั้นมันเก่าแก่ไหม ?
ถ้ามีอายุ 6 เดือนมันเก่าแก่ไหมนะ ?
หรือต้องมีอายุ 5 หรือ 10 หรือ 15 หรือ 20 ปีขึ้นไป ถึงจะเก่าแก่ ?
มี code ชุดไหนที่มีอายุมากที่สุด ?
code ที่มีอายุเยอะ ๆ มีจำนวนกี่เปอร์เซ็นจากทั้งหมด ? 10% หรือ 50% หรือ 90%

จะหาคำตอบไปเพื่ออะไรกัน ดังนั้นลองมาหาคำตอบกันดีไหม

เริ่มต้นจากธรรมชาติของ Software

เมื่ออายุของบริษัทเพิ่มมากขึ้น เราพบว่าจำนวน code ที่มีอายุมากก็เยอะขึ้นตาม ซึ่ง code เหล่านั้นมันเหมือนกับของโบราณ บางคนอาจจะเรียกว่า Legacy code บางคนอาจจะเรียกว่า มรดกเลือด บางคนอาจจะบอกว่า เป็นของโบราณ บางคนอาจจะบอกว่า สิ่งที่น่าขยะแขยง อย่าไปยุ่งกับมัน และเมื่อคุณเข้าไปรายละเอียดการทำงานของ code เหล่านั้น คุณจะยิ่งรู้สึกว่า เหมือนการเข้ายังบ้านเมืองเก่า ๆ ที่มีแต่ซากปรักหักพัก แต่ละส่วนพร้อมที่จะถล่มลงมา !!

แนวความคิดแรก ๆ ที่ developer ส่วนใหญ่คิดคือ ?

If it ain’t broke, don’t fix it

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

เข้าใจ business domain ดีขึ้น
เข้าใจวิธีการออกแบบ และ สร้างดีขึ้น
ปรับเปลี่ยนสถาปัตยกรรมให้ดีขึ้น
ใช้เครื่องมือที่ดีขึ้น
มีแนวทางการทำงานที่ดีขึ้น
มีมาจรฐานการทำงานที่ดีขึ้น
มีแนวคิดใหม่ ๆ ออกมา
ที่สำคัญคือ code ที่คุณเขียนออกมานั้น ควรจะดีขึ้นเช่นกัน

แต่คำถามที่น่าสนใจ คือ คุณกลับไปปรับปรุงและแก้ไข code ให้ดีขึ้นบ้างไหม ?

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

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

กลับมาดูกันว่า code ของเรามันมีอายุเท่าไร ?

จากการวิเคราะห์ code จำนวนหนึ่ง จาก project จำนวนหนึ่ง พบว่า code กว่า 70% ที่เราเขียนในวันนี้ จะทำงานอยู่บน production โดยไม่ถูกเปลี่ยนแปลงไปประมาณ 12 เดือน และหลังจาก 12 เดือน จะพบว่า code เหล่านั้นเข้าสู่สถานะการ maintenence เพราะว่า จะเริ่มถูกแก้ไขกันบ้างแล้ว !! แสดงผลการวิเคราะห์ดังรูป code-stat

ลองคิดดูสิว่า กว่า 70% ของ code ที่เราเขียนไม่ถูกเปลี่ยนแปลงเลย มันหมายความว่าอย่างไร ?

code มันดีอยู่แล้ว ?
code มันทำงานได้ดีอยู่แล้ว ?
เราไม่กลับไปแก้ไข code ให้ดีขึ้นเลย ?
เราไม่เคยเปลี่ยน library ที่ดีกว่าเลย ?
เราไม่เคยจะปรับปรุงสถาปัตยกรรมของระบบให้ดีขึ้นเลย ?
เราไม่เคยเรียนรู้อะไรจากมันเลย ?
เราไม่มีเวลา ?

โดยสรุปแล้ว

Code ต่าง ๆ ถูกสร้างมาด้วยเหตุผลที่แตกต่างกันไป แต่ส่งมอบสิ่งที่มีคุณค่าทาง business อย่างแน่นอน แต่ code เหล่านั้นมันก็กลายมาเป็น หนี้สิน หรือเป็นตัวถ่วงของทีมพัฒนา ของ bussiness ของบริษัทอย่างรวดเร็วเช่นกัน ถ้าไม่ดูแลให้ดี หรือ ไม่ปรับปรุงให้ดีอยู่อย่างเสมอ เมื่อเวลาผ่านไปนานขึ้น code ก็ยากต่อการดูแลรักษามากขึ้นเรื่อย ๆ จากการวิเคราะห์ข้อมูลของ code ทำให้เราเห็นว่า code มันอยู่กับเราไปนานมาก ๆ ดังนั้น จึงเป็นเหตุผลที่สมเหตุสมผล ว่า ทำไมเราควรดูแลรักษา code ให้ดียิ่งขึ้นอย่างสม่ำเสมอ ดังนั้น ถ้าคุณไม่ทำการแก้ไข และ ปรับปรุง code ให้ดีขึ้นเลย คุณก็ต้องทนอยู่ หรือ อยู่ทนกับ code เหล่านั้นไปตลอด ซึ่งมันไม่สนุกเลย !! คำถาม แล้วจะเริ่มอย่างไรดีล่ะ ? คำตอบคือ ต้องยอมรับก่อนว่า code ที่เราดูแลอยู่นั้น มันยากต่อการแก้ไขนะ มันยากต่อการแก้ไขขึ้นเรื่อย ๆ จากนั้นจึงเริ่มหาวิธีการแก้ไขให้มันดีขึ้น ทั้งในระยะสั้น และ ระยะยาว

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

↧

การ Deploy Software คือการแก้ไขหรือสร้างปัญหากันแน่ ?

March 4, 2016, 10:59 pm

≫ Next: ทำความรู้จักกับ Fastlane กันหน่อย

≪ Previous: Code ที่ developer ทำงานอยู่ด้วยนั้น มีอายุเท่าไร ?

maxresdefault

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

สิ่งที่น่าสนใจสำหรับการ deploy software

เราพบว่าไม่ว่าจะใช้เครื่องมือที่ดีเพียงใด ก็ยังพบว่า การ deploy มักจะเกิดความผิดพลาดเสมอ จึงเกิดคำถามตามมามากมาย เช่น

ทำไมเกิดข้อผิดพลาด ?
ทำไมเรา deploy ระบบที่มี bug เพียบขึ้นไปล่ะ ?
ทำไมระบบมี downtime ด้วยล่ะ ?
สิ่งที่ deploy ขึ้นไปมันไม่น่าจะผิดพลาดนะ !!
ไม่ทดสอบระบบกันหรือไง ?

หรือว่าปัญหาจริง ๆ มันอยู่ที่ขั้นตอนการทำงานที่กำหนดกันขึ้นมาเอง หรือว่าปัญหาจริง ๆ มันอยู่ที่คน

ลองกลับไปดูที่ทีม และ องค์กรของเราสิว่า มีขั้นตอนการ deploy software อย่างไร ?

ทำการ deploy แบบใหม่ ๆ หรือ Big Bang หรือไม่ ? ทำการ deploy แบบเล็ก ๆ บ่อย ๆ หรือไม่ ? การ deploy แต่ละครั้งส่งผลกระทบมากหรือน้อย ? การ deploy มีปัญหาอะไรบ้าง ?

ลองตั้งคำถามสิว่า

เราต้องการ release manager หรือไม่ ?
เราต้องการการ deploy แบบพิเศษหรือด่วน ๆ ในทุก ๆ วันหรือไม่ ?
เราต้องอยู่เฝ้าในทุก ๆ การ deploy หรือไม่ ?

หรือ เราต้องการเพียงขั้นตอนการ deploy ที่ดี เราต้องการเพียงขั้นตอนการ deploy ที่มันมีคุณภาพ เราต้องการเพียงขั้นตอนการ deploy ที่รวดเร็ว เราต้องการการทำงานร่วมกันที่ดีของคนที่เกี่ยวข้อง ในบทความต่อ ๆ ไปจะอธิบายถึงเรื่อง

การเริ่มต้นที่ดี
การจัดการเรื่อง branch
การควบคุม
การ monitoring

↧

ทำความรู้จักกับ Fastlane กันหน่อย

March 6, 2016, 6:07 am

≫ Next: Emoji Programming :: เรื่องเล่น ๆ เราจริงจังมาก

≪ Previous: การ Deploy Software คือการแก้ไขหรือสร้างปัญหากันแน่ ?

fastlane

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

ขั้นตอนการ deploy และ release app
สร้างระบบการทำงานแบบอัตโนมัติ
สร้างระบบการพัฒนาระบบงานแบบอัตโนมัติ

ถูกสร้างมาตามแนวคิด Continuous Delivery (CD) นั่นเอง ซึ่งแต่ละขั้นตอนของทำงาน หรือ การ build นั้น เราสามารถจัดเรียงลำดับการทำงานได้เอง โดยจะเรียกว่า Lane แสดงดังรูป

ตัวอย่างการนำ Fastlane มาใช้งาน

สำหรับ iOS app เราสามารถทำการ deploy app ไปยัง Apple Store เพียงใช้คำสั่งเดียว
สำหรับ Android app เราสามารถทำการ deploy app ไปยัง Google Play Store เพียงใช้คำสั่งเดียว

ผลที่ได้รับคือ

ลดเวลาในการ deploy app ลงไปอย่างมาก
ทำให้มีเวลาไปปรับปรุงคุณภาพของ app มากขึ้น
ทำให้เราสามารถ deploy ระบบงานแบบเล็ก ๆ ได้ตลอดเวลา
ทำให้ใคร ๆ ในทีมก็สามารถ deploy ระบบงานได้

มาดูว่า Fastlane มีเครื่องมืออะไรให้ใช้งานกันบ้าง ?

โดยแบ่งออกเป็น 2 กลุ่มหลัก ๆ คือ กลุ่มที่ 1 สำหรับ iOS app

Deliver สำหรับการ upload screenshot และ metadata ขึ้นไปยัง App Store
Snapshot สำหรับการบันทึก screenshot ของ app ในแต่ละ device ซึ่งทำงานร่วมกับ UI Testing
Frames ช่วยทำให้การบันทึก screenshot ให้ถูกต้อง
PEM สำหรับจัดการ profile ของระบบ push notification
Sigh สำหรับจัดการ provisioning profile ต่าง ๆ ของ app
Produce สำหรับการสร้าง iOS app บน iTune Connect และ Apple Developer Portal
Cert สำหรับทำการ sign certificate ให้กับ app เมื่อทำงานสำเร็จ ก็เรียกใช้งาน Sign ต่อได้เลย
Scan สำหรับทำการ run test ต่าง ๆ ของ app ทั้ง Unit Test และ UI Test ทำให้ชีวิตง่ายขึ้นอย่างมาก เนื่องจากการใช้งาน xcodebuild มันยากมาก
Gym สำหรับการ build และ packaging iOS app ผลที่ได้คือไฟล์ ipa ที่ทำการ sign certificate เรียบร้อยแล้ว
Match สำหรับการ sync พวก certificate และ profile ต่าง ๆ ผ่าน git ทำให้ทุกคนในทีมใช้งานได้

กลุ่มที่ 2 สำหรับ Android app

Supply สำหรับการ upload screenshot และ metadata ขึ้นไปยัง Google Play Store
Screengrab สำหรับการบันทึก screenshot ของ app ในแต่ละ device ซึ่งทำงานร่วมกับ Esspresso หรือ UI Testing ซึ่งผมเคยเขียน blog อธิบายไว้แล้วที่นี่

Software ที่จำเป็นสำหรับ Fastlane

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

OSX 10.9 ขึ้นไป
Ruby 2.0 ขึ้นไป
Xcode
จ่ายเงินสำหรับ Apple Developer Account ซะ

ก่อนที่จะทำการติดตั้ง Fastlane ให้ทำการตรวตสอบดังนี้ เริ่มจากตรวจสอบเวอร์ชันของ Ruby ด้วยคำสั่ง [code]$ruby -v[/code] ต่อมาทำการตรวจสอบว่า ทำการติดตั้ง Xcode Command Line Tool (CLT) แล้วหรือยัง ด้วยคำสั่ง [code]$xcode-select --install[/code] เมื่อทุกอย่างเรียบร้อยก็ติดตั้ง Fastlane กันเลย ด้วยคำสั่ง [code]$gem install fastlane[/code] จะใช้เวลาในการติดตั้งนานนิดหน่อย ไม่ต้องกังวลนะครับ รอนิดหน่อย หรือ ไปหาข้าวกินก่อนได้เลย เมื่อติดตั้งเรียบร้อย เราสามารถใช้คำสั่งนี้ได้ [code]$fastlane[/code] เพียงเท่านี้ก็พร้อมสำหรับเริ่มใช้งาน Fastlane ได้แล้ว ซึ่งใน blog ต่อ ๆ ไป จะแสดงตัวอย่างการใช้งาน Fastlane สำหรับ iOS app กัน

สุดท้ายแล้ว

สำหรับ iOS Developer และ Android Developer ไม่ควรพลาดที่จะรู้จักและลองนำ Fastlane ไปใช้งานกันดูครับ น่าจะช่วยปรับปรุงขั้นตอนการพัฒนาและ deploy app ให้ดีขึ้นกว่าเดิม

↧

Emoji Programming :: เรื่องเล่น ๆ เราจริงจังมาก

March 7, 2016, 2:35 am

≫ Next: สรุปโครงสร้างข้อมูลของ NoSQL Database

≪ Previous: ทำความรู้จักกับ Fastlane กันหน่อย

emoji-programming

ภาษาโปรแกรมใหม่อีกตัวได้ถือกำเนิดมาอีกแล้ว แต่ว่ามันคือภาษาที่ประกอบไปด้วยชุดของ Emoji น่ารัก ๆ ซึ่งน่าจะเคยเห็นกันมาพอสมควรจากภาษา Swift แต่ตอนมีคนสร้างภาษาโปรแกรมใหม่ที่เรียกว่า EmojiCode ออกมา ดังนั้น เรามาลองดูหน่อยว่า มันทำอะไรได้บ้าง เขียนอย่างไร น่าจะทำให้ developer สนุกกับเขียน code มากขึ้นหรือเปล่านะ

EmojiCode คืออะไร

เป็นภาษาโปรแกรมระดับสูง ด้วยการใช้ Emoji เป็นหลัก ซึ่งสามารถทำงาน cross platform ได้เลย แน่นอนว่า open source และยังรวมเอาแนวคิดต่าง ๆ ของการเขียนโปรแกรมเข้าด้วยกัน ด้วยรูปต่าง ๆ ที่มากกว่าหน้ายิ้ม หน้าร้องไห้ !! เพื่อให้สื่อถึงหน้าที่การทำงานจริง ๆ ส่วนเบื้องหลังการทำงาน คือ ภาษา C และ C++ นะ โดยตอนนี้ได้ปล่อย Engine ออกมาแล้วเป็นเวอร์ชัน 0.2 beta 2 ซึ่งสามารถทำงานได้ทั้ง OSX และ Linux หรือสามารถนำไป source code ไป build ได้เองเลย ลองติดตั้งกันดูนะครับ สำหรับผมใช้ OSX ก็เพียง download binary มาก็ใช้ได้เลย ดังนั้นมาลองเขียนโปรแกรมด้วย Emoji กันดีกว่า สามารถดูการติดตั้งได้ที่นี่ EmojiCode Installation มีนง่ายมาก

โครงสร้างของโปรแกรมเป็นอย่างไร ?

เริ่มด้วยการสร้าง class และ method ซึ่งไฟล์ชื่อว่า first.emojic [gist id="167efde9b8694a2bd750" file="first.emojic"] คำอธิบาย

ในบรรทัดแรกคือ การประกาศ class จากตัวอย่างคือ class หมีแพนด้า
ในบรรทัดที่สองคือ การประกาศ method ของ class สังเกตุไหมว่าจะเริ่มด้วยกระต่าย และ ปิดด้วยองุ่น
🍇 คือบอกจุดเริ่มต้นของ class และ method
🍉 คือบอกจุดสิ้นสุดของ class และ method
🏁 คือ main method หรือ method ที่จะทำงานเมื่อ class นี้ถูกเรียกใช้งาน
➡️ คือบอกว่า method มีการ return
🚂 คือชนิดข้อมูลเป็นจำนวนเต็มหรือ integer มีค่าระหว่าง [-2^63+1, 2^63-1]
🍎 คือ การ return ค่า 0 ออกมาจาก method
😀 สำหรับแสดงข้อความ
🔤 สำหรับบอกว่าค่าที่อยู่ระหว่างของข้อความ

ต่อมาก็ทำการ compile ด้วยคำสั่ง [code]$emojicodec first.emojic[/code] ผลที่ได้คือไฟล์ binary ชื่อว่า first.emojib ดังนั้นให้ทำการ run ด้วยคำสั่ง [code]$emojicode first.emojib[/code] ได้ผลการทำงาน คือ แสดงคำว่า Hello World

ต่อมาลองเขียนโปรแกรมที่สอง คือ คิดเกรด

ซึ่งต้องใช้การตรวจสอบเงื่อนไข หรือ if/else นั่นเอง ดังนั้นมาดูกันว่า สำหรับ Emoji code ต้องเขียนอย่างไร [gist id="167efde9b8694a2bd750" file="grade.emojic"]

และยังมีความสามารถอื่น ๆ อีกมากมาย (Swift ชัด ๆ) เช่น

Optional
Class
Extension
Protocol
Enum
Generic

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

เครื่องมือเพิ่มเติม

สำหรับชาว Atom IDE นั้นมี plugin ให้ใช้นะ EmojiCode IDE รวมทั้ง Autosuggestion
สามารถร่วมแปลเอกสารได้ที่นี่ EmojiCode Documentation

↧

สรุปโครงสร้างข้อมูลของ NoSQL Database

March 8, 2016, 7:56 am

≫ Next: แนะนำเครื่องมือสำหรับการทำ Performance Testing

≪ Previous: Emoji Programming :: เรื่องเล่น ๆ เราจริงจังมาก

nosql-type

วันนี้ได้เริ่มอ่านหนังสือ Introducing to Data Science มีหนึ่งบททำการอธิบายเกี่ยวกับโครงสร้างข้อมูลของ NoSQL Database ไว้ได้อย่างน่าสนใจ และ เข้าใจง่าย จึงนำมาแปลไว้อ่านนิดหน่อยดังนี้

โครงสร้างข้อมูลของ NoSQL Database 4 ชนิด ประกอบไปด้วย

Column-Oriented
Key-value
Document
Graph

โดยแต่ละชนิดถูกคิดและสร้างขึ้นมาเพื่อแก้ไขปัญหาที่แตกต่างกันไป ซึ่งปัญหาเหล่านั้นไม่สามารถแก้ไขด้วยการใช้งาน RDBMS นั่นเอง และพบว่า NoSQL หนึ่ง ๆ มักจะมีรูปแบบการจัดเก็บข้อมูลที่หลากหลาย หรือเรียกว่า Multi-model database ตัวอย่างที่เห็นได้ชัดคือ OrientDB ซึ่งมันคือ Graph database โดยที่แต่ละ node มันมีรูปแบบเป็น Document

แต่ก่อนที่จะไปดูโครงสร้างข้อมูลทั้ง 4 ของ NoSQL

เราต้องมาดู RDBMS หรือ Relational Database ก่อนว่ามันเป็นอย่างไร ? เพื่อจะได้เห็นข้อแตกต่างได้ชัดเจนยิ่งขึ้น เราปฏิเสธไม่ได้ว่า RDBMS นั้นได้รับความนิยมอย่างสูง สามารถรองรับความต้องการต่าง ๆ ได้อย่างมากมาย คำหนึ่งที่เรามักจะได้ยินบ่อย ๆ ในออกแบบโครงสร้างข้อมูลบน RDBMS คือ การ Normalization คือ เป็นวิธีการลดความซ้ำซ้อนของข้อมูลนั้นเอง มีโครงสร้างข้อมูลที่อยู่รูปแบบของตาราง และแต่ละตารางก็จะมีความสัมพันธ์กัน เช่น

One-to-one
One-to-many
Many-to-many

เมื่อระบบมีขนาดใหญ่ขึ้น จำนวนตารางก็เยอะขึ้น รวมทั้งความสัมพันธ์ต่าง ๆ ก็มากขึ้นเช่นกัน แสดงความสัมพันธ์แบบ Many-to-many ระหว่าง Person และ Hobby ดังรูป 1334442-introducingdatascience1

มาดูว่าโครงสร้างข้อมูลของ NoSQL Database แต่ละชนิดเป็นอย่างไร

1. Column-Oriented Database

ถ้าเปรียบเทียบกับ RDBMS จะเห็นว่ามันเป็น Row-based oriented นั่นคือแต่ละ row ของข้อมูลประกอบไปด้วย ID ที่เป็น primary key และ field หรือ column ต่าง ๆ โดยแต่ละ row จะถูกจัดเก็บในตาราง ดังนั้นในการดึงข้อมูลจากตารางจะเป็นแบบ อ่านจากบนลงล่าง และ ซ้ายไปขวา โดยข้อมูลแต่ละ row จะถูก load ไปยัง memory ซึ่งมันทำให้เสียเวลา และ ใช้ memory อย่างมากมาก แสดงดังรูป 1378393-introducingdatascience3

ดังนั้น เพื่อเพิ่มความเร็วในการเข้าถึงข้อมูล เราจึงทำการสร้าง index ให้ตาม column ที่เราต้องการ แต่มันเป็นการเพิ่ม overhead ให้แก่ระบบ ลองคิดดูว่า ถ้าเราทำการ index ทุก ๆ column ล่ะ !! ดังนั้น Column-Oriented Database จึงสร้างมาเพื่อช่วยแก้ไขปัญหาเหล่านี้ โดยแต่ละ column จะถูกจัดเก็บแยกกัน ทำให้การเข้าถึงข้อมูลในแต่ละ column เร็วขึ้น รวมทั้งทำให้ง่ายต่อการบีบอัดข้อมูลอีกด้วย เนื่องจากในแต่ละตารางจัดเก็บข้อมูลเพียงชนิดเดียว แสดงดังรูป 1378395-introducingdatascience4

ตัวอย่าง product ที่มีโครงสร้างข้อมูลเป็น Column-Oriented เช่น

Apache HBase
Cassandra
Hypertable
Google BigTable

2. Key-Value Database

เป็นโครงสร้างข้อมูลที่เรียบง่าย และ ไม่ซับซ้อนที่สุดแล้ว จากความเรียบง่ายนี่เอง ทำให้ Key-Value มันสามารถรองรับการใช้งานจำนวนมากได้ สามารถรองรับข้อมูลจำนวนมากได้อย่างสบาย ๆ แสดงโครงสร้างดังรูป 1378402-introducingdatascience5

ตัวอย่าง product ที่มีโครงสร้างข้อมูลเป็น Key-Value เช่น

Memcached
Redis
Riak
Voldemort Amazon Dynamo

3. Document Database

เป็นโครงสร้างที่ซับซ้อนมาอีกหนึ่งชั้นจาก Key-Value database ทำการเก็บข้อมูลในรูปแบบของเอกสาร แน่นอนว่า ในแต่ละเอกสารต้องมีโครงสร้างข้อมูลเช่นกัน เรามักจะเรียกว่า Schema โดยโครงสร้างแบบนี้จะถูกนำไปใช้อย่างมาก เนื่องจากข้อมูลส่วนใหญ่จะอยู่ในรูปแบบของเอกสารอยู่แล้ว หรือถ้าเทียบกับ RDBMS เราอาจจะบอกว่าได้ มันคือข้อมูลที่ถูกทำการ Nomalization เพียงเล็กน้อย หรือบางคนบอกว่ามันคือ การ Denomalization นั่นเอง ทำให้ NoSQL ชนิดนี้เกิดมาเพื่อแก้ไขบางอย่าง ที่ RDBMS ไม่ตอบโจทย์นั่นเอง ลองคิดดูสิว่า ถ้าข้อมูลของเราเป็นหนังสืมพิมพ์ หรือ นิตยสาร เมื่อนำมาจัดเก็บใน RDBMS แล้ว พบว่า ต้องทำการแยกข้อมูลไปจัดเก็บในแต่ละตาราง !! ทั้ง ๆ ที่เราสามารถบันทึกข้อมูลในรูปแบบของเอกสารเพียงเอกสารเดียวได้ มันน่าจะช่วยลดงานต่าง ๆ ลงไปได้เยอะนะ ว่าไหม ? แสดงดังรูป 1378404-introducingdatascience7

ตัวอย่าง product ที่มีโครงสร้างข้อมูลเป็น Document เช่น

MongoDB
CouchDB

4. Graph Database

เป็นโครงสร้างข้อมูลที่มีความซับซ้อนสูงที่สุด เนื่องจากใช้จัดเก็บข้อมูลที่มีความสัมพันธ์ระหว่างกัน โดยมักจะใช้งานในเรื่องของ

Social Networking
Scientific paper citation
Capital asset cluster
Direction in map

โครงสร้งข้อมูลแบบ Graph จะประกอบไปด้วย

Node คือ ข้อมูลหรือ entity หนึ่ง ๆ ตัวอย่างเช่นใน Social Network คือ ผู้ใช้งาน
Edge เป็นความสัมพันธ์ระหว่าง entity ซึ่งแสดงอยู๋ในรูปแบบเส้น และ มีคุณบัติต่าง ๆ อยู่ด้วย รวมทั้งยังมีทิศทาง หรือ direction อีกด้วย

แสดงดังรูป 1378416-introducingdatascience8

ตัวอย่าง product ที่มีโครงสร้างข้อมูลเป็น Graph เช่น

Neo4j
OrientDB

↧

แนะนำเครื่องมือสำหรับการทำ Performance Testing

March 10, 2016, 3:58 pm

≫ Next: วิธีการแก้ไขข้อผิดพลาดจากการรวม Source code ของทีม

≪ Previous: สรุปโครงสร้างข้อมูลของ NoSQL Database

performance

คำถามที่น่าสนใจ สำหรับการพัฒนาระบบงาน

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

ลองตอบกันดูนะ แต่มีคำถามที่มักได้ยิน ได้ถามกันบ่อย คือ แล้วมีเครื่องมืออะไรบ้างสำหรับ Performance Testing หรือการทดสอบประสิทธิภาพการทำงานของระบบบ้างล่ะ ?

เริ่มด้วยเครื่องมือสำหรับการทดสอบ Web application

แน่นอนว่าเป็น Open source ประกอบไปด้วย

สำหรับการทดสอบฝั่งผู้ใช้งาน หรือ Client side

ซึ่งแนะนำให้เริ่มต้นด้วย Google Web Performance เลย ประกอบไปด้วย

ต่อมาเป็นพวก As as Service หรือมีให้บริการผ่าน web นั่นเอง

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

Blaze meter สามารถทำงานร่วมกับ Apache JMeter ได้เลย ทำให้ง่ายต่อการทดสอบ และ สามารถเพิ่มจำนวนผู้ใช้งานตามความต้องการ และตามจำนวนเงินทุน
Blitz
Apica Load Test
Soasta

สุดท้ายแล้ว

จะเห็นได้ว่า มีเครื่องมือมากมายพร้อมให้นำมาใช้งาน (ส่วนหนึ่งเท่านั้นนะ) ว่าแต่ ... วันนี้คุณทำ Performance Testing แล้วหรือยัง ? คุณทำ Performance Testing บ่อยเพียงใด ?

คำพูดที่ได้ยินบ่อยมาก ๆ คือ ... แต่ ... แต่ ... แต่

↧

วิธีการแก้ไขข้อผิดพลาดจากการรวม Source code ของทีม

March 12, 2016, 12:45 am

≫ Next: สรุปเรื่องของ Git Branching Strategy

≪ Previous: แนะนำเครื่องมือสำหรับการทำ Performance Testing

git-push

เมื่อเช้านี้เห็นมีการ share บทความเรื่อง 4 Simple Tricks to Avoid Merge Conflicts ทำการอธิบายถึงการแก้ไขปัญหาต่าง ๆ ที่เกิดจากการรวม source code ของทีม ซึ่ง developer มักจะเรียกว่า Merge conflict จึงนำมาแปลกันนิดหน่อย น่าจะมีประโยชน์บ้างนะ มาดูกันว่ามีวิธีการอะไรบ้าง ?

คำถามที่มักได้รับเสมอจากการแบ่งปันเรื่อง Version Control System

ไม่ว่าจะเป็น Git, Mercurial HG และ SVN นั่นก็คือ ถ้า source code รวมกันแล้วเกิด Conflict หรือ ข้อขัดแย้ง จะต้องแก้ไขอย่างไรดี ?

ก่อนที่จะหาวิธีการแก้ไขปัญหา เราต้องรู้และเข้าใจก่อนว่า ที่ไปที่มาของปัญหามันคืออะไรกันแน่

ในการพัฒนา software ส่วนใหญ่ต้องทำงานเป็นทีม นั่นคือต้องมีคนทำงานร่วมกันมากกว่า 1 คน ต้องทำงานบน source code ชุดเดียวกัน ดังนั้นมีบ่อยครั้งที่ทำการแก้ไข source code เดียวกัน พร้อม ๆ กัน ส่งผลให้เกิดปัญหา คือ Merge conflict ซึ่งมันรบกวนจิตใจของนักพัฒนาอย่างมาก !! เนื่องจากต้องทำการแก้ไข conflict หรือ ข้อขัดแย้งเหล่านั้นเอง บางครั้งก็แก้ไขผิด ๆ ถูก ๆ บางครั้งทำให้ bug ที่แก้ไขไปแล้ว กลับมาอีก บางครั้งทำให้ feature ที่เคยทำงานได้ ทำงานไม่ได้ นั่นคือ ความบอบช้ำ และ เจ็บช้ำที่นักพัฒนาได้รับ แต่ก็ยังทำแบบนั้นซ้ำแล้วซ้ำอีก !! จึงเกิดคำถามขึ้นมาว่า จะแก้ไขปัญหาเหล่านี้อย่างไรดี บางคนอาจจะพยายามหาเครื่องมือที่ช่วยรวม หรือ merge source code แบบ GUI เพราะว่า มันง่ายดี แต่ผมคิดว่า เราน่าจะทำการแก้ไขปัญหาที่ต้นเหตุดีกว่า เพื่อหลีกเลี่ยงปัญหาที่จะเกิดขึ้น นั่นคือ ป้องกันไว้ดีกว่าแก้นะครับ (Prevent) ซึ่งจากบทความข้างต้นได้แนะนำไว้ 4 วิธีตามลำดับดังนี้

1. ทำการ Merge บ่อย ๆ สิ

ปัญหาใหญ่ ๆ ของ Merge conflict เกิดจากจำนวน source code ที่ชนหรือขัดแย้งกันมากเหลือเกิน คำถาม คุณทำการ merge source code กันบ่อยเพียงใด ? 2-3 วัน ? หนึ่งสัปดาห์ ? สองสัปดาห์ ? ครึ่งเดือน ? หนึ่งเดือน ?

สิ่งที่หนึ่งที่บอกได้เลยก็คือ ยิ่งใช้เวลานานเพียงใด ความเสี่ยงก็ยิ่งมากขึ้นเท่านั้น ยิ่งก็ให้เกิดข้อขัดแย้งขนาดใหญ่ และ มากมาย

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

หัวใจคือ Fast feedback ครับ

2. เล็ก ๆ สิดี

ว่าด้วยเรื่องของ Single Responsibility Principle (SRP) เป็นหนึ่งในแนวทางการออกแบบระบบงานที่ดี คือ SOLID นั่นคือ ในหนึ่ง class ใน หนึ่ง method นั้น ควรจะมีหน้าที่การทำงานเพียงอย่างเดียวเท่านั้น หรือในแต่ละ class แต่ละ method ควรมีเหตุผลเดียวในการเปลี่ยนแปลงเท่านั้น ผลที่ได้ก็คือ นักพัฒนาจะไม่ทำงาน หรือ เปลี่ยนแปลง source code ที่เดียวกันอย่างแน่นอน ยกเว้นจะทำงานเดียวกัน หรือ ทำงานด้วยกัน ดังนั้น การออกแบบที่ดีมันช่วยให้ทีมทำงานร่วมกันได้อย่างดี ยิ่งแต่ละส่วนการทำงานเล็ก ๆ แล้ว ก็ยิ่งทำให้คุณภาพของการออกแบบระบบดี รวมทั้ง ลดความเสี่ยงจาก Merge conflict อีกด้วย

ลองกลับไปดู source code ของคุณดูสิว่า มีการแก้ไข source code อย่างไรกันบ้าง เช่น มี class ไหนที่ต้องแก้ไขบ่อยมาก ๆ จากทุก ๆ คน ทุก ๆ feature ?

3. การพูดคุย การสื่อสาร มันสำคัญอย่างมาก

Communication is a Key !!

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

แก้ไขการ Merge conflict ได้ง่าย ๆ มากเลยนะ เพียงแค่เราคุยกันในเรื่องที่ควรจะคุยกันมากขึ้น

4. Mob programming

เป็นวิธีการที่ทรงประสิทธิภาพอย่างมาก และเชื่อได้เลยว่า แก้ไขปัญหา Merge conflict ได้ 100% เนื่องจากทุกคนมานั่งทำงานด้วยกัน ใช้เครื่องทำงานเดียวกัน ดังนั้น ไม่มีทางที่ source code จะขัดแย้งกัน แต่มันมีค่าใช้จ่ายที่สูงมาก ๆ ดังนั้นจึงเป็นวิธีการสุดท้ายที่จะทำนั่นเอง

วันนี้คุณทำการ merge source code กันบ่อย ๆ หรือไม่ ? ถ้าไม่ ก็เริ่มได้แล้ววันนี้ !!

↧

สรุปเรื่องของ Git Branching Strategy

March 14, 2016, 12:51 am

≫ Next: มาดูที่มาที่ไปของ Six Stages of Debugging กันหน่อย

≪ Previous: วิธีการแก้ไขข้อผิดพลาดจากการรวม Source code ของทีม

branching

วันนี้อ่านหนังสือเรื่อง Git for Teams มีเรื่องที่น่าสนใจอย่างยิ่ง หนึ่งในนั้นคือเรื่อง Git Branching Strategy ซึ่งมีหลากหลายวิธีให้เลือกนำมาใช้งานมาก ดังนั้น ในการพัฒนา software แต่ละองค์กร แต่ละทีม ต้องทำการเลือกและตัดสินใจว่า จะใช้วิธีการไหน ที่เหมาะสมกับงานของคุณ มาดูกันว่ามีวิธีการอะไรบ้าง ? มีคำพูดที่น่าสนใจ คือ

ค่าจ้างของ Developer นั้นแพงกว่า การทำ branching อย่างมาก แต่การเลือกวิธีการ branching ที่ผิด ยิ่งก่อให้เกิดค่าใช้จ่ายที่มากกว่ายิ่งนัก !!

ดังนั้นสิ่งที่ทีม ต้องคุย ต้องเลือก ก่อนที่จะเริ่มพัฒนา software คือ Branching Strategy ถ้าใช้งาน Git จะเรียกว่า Git Branching Strategy

ลองกลับไปดูสิว่า Release software process ของคุณเป็นอย่างไร ?

ก่อนอื่นมาดูว่า มีรูปแบบพื้นฐานอะไรกันบ้าง ? เพื่อนำไปใช้พิจารณาต่อไป

1. Mainline Branch Strategy

เป็นวิธีการที่เรียบง่ายที่สุด แถมยังมีประสิทธิภาพอย่างมากสำหรับทีมที่ไม่ใหญ่มาก เนื่องจากจะทำงานบน branch หลักเดียวเท่านั้น โดยที่ branch หลักนี้ ต้องพร้อมที่จะ deploy/release อยู่ตลอดเวลา ในการทำงานนั้น developer แต่ละคน จะทำงานบน local branch ของตัวเอง เมื่อทำการพัฒนาเสร็จแล้ว ให้ทำการ merge code เขาไปยัง branch หลัก แสดงดังรูป

ข้อควรระวัง แต่ละงานที่ทำนั้น ควรเป็นงานที่เล็ก ๆ ไม่เช่นนั้น จะทำให้ local branch ยาวนานเกินไป ก็จะทำให้เกิด merge conflict กันเยอะ แต่ละงานที่มำนั้น ควรเป็น code ที่แยกออกจากกันชัดเจน ไม่เช่นนั้น ก็จะทำให้เกิด merge conflict กันเยอะ อีกอย่างหนึ่งที่ควรพึงระวัง ถ้าทำการ merge แบบ manual เยอะ ๆ แสดงว่า คุณกำลังมาผิดทาง เช่น

Local branch ใช้เวลาพัฒนานานเกินไป
ไม่ทำการ merge code บ่อย ๆ
ไม่พูดคุยกัน

2. Feature Branch Strategy

ทำการจัดการ code แต่ละ branch แยกตาม feature ไป เมื่อ developer ทำการพัฒนา และ ทดสอบเสร็จแล้ว จะทำการ merge code จาก feature branch ไปยัง integration branch จากนั้นทำการทดสอบอีกครั้งบน integration branch เมื่อทุกอย่างเรียบร้อย ก็ทำการ merge กลับไปยัง branch หลักต่อไป แสดงดังรูป

ดังนั้นสถานะของ code บน branch หลัก คือพร้อมที่จะ dpeloy/release อยู่ตลอดเวลา อีกอย่างหนึ่งที่เห็นได้ชัดเจนก็คือ มีการทำงานแบบ manual เยอะมาก ๆ ดังนั้น เราสามารถลดด้วยการทำระบบทำงานแบบอัตโนมัติเข้ามาช่วย ทั้งการ merge การทดสอบ และ การ deploy ระบบงาน ตัวอย่างที่นำวิธีการนี้ไปประยุกต์ใช้งาน เช่น Github flow กล่าวคือ เมื่อ developer แต่ละคนทำการพัฒนา feature เสร็จแล้ว จะไม่สามารถ merge code กลับไปยัง integration branch และ branch หลักได้ แต่จะต้องส่ง Pull Request ไปยัง integration branch ซึ่งการจัดการ Pull Request ส่วนใหญ่จะเป็นแบบ manual เนื่องจากต้องทำการ review และ ทดสอบ code เมื่อผ่านทั้งหมดแล้ว จะทำการ merge ไปยัง branch หลักต่อไป ข้อควรระวัง ยิ่ง feature branch มีอายุ หรือ การพัฒนาที่ยาวนานเพียงใด การดูแลรักษาก็ยากมากขึ้นไปเท่านั้น ชื่อของ feature branch ควรดูดี มีสาระ !! นั่นคือ ต้องมีชื่อตรงตามความต้องการของระบบ ไม่ใช่อยากจะตั้งชื่ออะไรก็ตั้ง แถมยังต้องมีการจัดการ branch ต่าง ๆ อยู่เป็นประจำ เช่นการลบ branch ต่าง ๆ ที่ทำการ merge ไปยัง branch หลักต่อไปซะ ไม่เช่นนั้น จะมี branch อยู่มากมายก่ายกอง ซึ่งยากต่อการจัดการเป็นอย่างมาก

แต่สิ่งที่สำคัญมาก ๆ คือ branch หลักยังต้องพร้อม deploy/release อยู่เสมอ มันคือหัวใจหลักเลย

3. Environment Branch Strategy

เป็นอีกรูปแบบหนึ่งของการจัดการ branch ซึ่งจะทำการสร้าง branch ขึ้นมาตามจำนวนของ environment ของระบบ เช่น

Development
Testing
Staging
Pre-production
Production

ถ้าต้องการที่จะ deploy ไปยัง environment ไหน ก็ให้ทำการสร้าง merge request จาก branch หลักไปยัง branch นั้น ๆ ซะ ตัวอย่างเช่น

ในปัจจุบัน branch หลักทำการ deploy ไปยัง staging แล้ว
จากนั้นถ้าต้องการ deploy ไปยัง pre-production ก็ให้ทำการสร้าง merge request
ถ้าต้องการ deploy ไปยัง production ก็ให้สร้าง merge request จาก pre-production อีกที

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

4. Released Branch Strategy

หรือจะเรียกว่า Branch by release นั่นเอง ในแต่ละ branch คือ แยกไปตามแต่ละ version ของระบบงาน แต่ส่วนการทำงานหลักยังคงอยู่ที่ branch หลักนะ แต่ปัญหาที่ตามมาก็คือ การดูแลจัดการในแต่ละ branch หรือ แต่ละ release ซึ่งก่อนอื่นต้องทำการแก้ไขและ merge มายัง branch หลักก่อนเสมอ จากนั้นจึงใช้ความสามารถของ git ชื่อว่า Cherry Pick เพื่อหยิบการแก้ไขไปยัง branch หรือ release ต่าง ๆ ต่อไป รวมทั้งถ้าทำการแก้ไขในแต่ละ branch หรือ release แล้ว ต้องทำการ Cherry Pick มายัง branch หลักเช่นกัน โดยนโยบาย หรือ วิธีการทำงานแบบนี้ เรียกว่า Upstream First แสดงดังรูป branch-by-release[4]

สุดท้ายแล้ว ทีมลองคุยกันสิว่า วิธีการใดที่เหมาะสม ?

ลองพูดคุยกันในเรื่องของ ข้อดีและข้อเสีย ผมเชื่อว่า แต่ละงาน แต่ละ product ล้วนมีรูปแบบที่แตกต่างกัน ดังนั้น Branching Strategy ก็ย่อมแตกต่างกันไป อาจจะทำการเพิ่ม หรือ ลด กระบวนการลงไปอีกก็ได้ Reference Website https://www.javacodegeeks.com/2015/11/git-branching-strategies.html http://www.infoq.com/articles/no-hotfix-deployment http://www.kumaranuj.com/2015/11/gi-branching-strategies.html

↧

มาดูที่มาที่ไปของ Six Stages of Debugging กันหน่อย

March 14, 2016, 9:09 am

≫ Next: YAHOO! เปิดให้ download ฐานข้อมูลขนาดใหญ่กันแล้ว

≪ Previous: สรุปเรื่องของ Git Branching Strategy

debugging

เห็นใน Facebook มีการ share เรื่องราวของ Six Stages of Debugging ซึ่งเป็นปฏิกิริยาของ developer สำหรับการ debug code เพื่อทำการหาสาเหตุว่า ทำไม code ถึงทำงานไม่ถูกต้อง ประกอบไปด้วย

That can't happen
That doesn't happen on my machine
That shouldn't happen
Why does that happen ?
Oh, I see.
How did that ever work?

ลองแปลเป็นไทยสิ

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

ไม่รู้ว่าเป็นแบบนี้จริงไหม ? แต่คิดว่าไม่ใช่ก็ใกล้เคียงนะ

ยังมีเพิ่มเติมอีกข้อคือ ขอโทษด้วยนะ code ส่วนนี้ผมไม่ได้เขียนนะ !! ซึ่งมันบ่งบอกถึง วัฒนธรรมของทีม และ องค์กรได้ชัดเจนมาก ๆ

แต่ประเด็นหลักคือ อยากรู้ว่า มันมีจะเริ่มต้นจากที่ไหน ?

จึงทำการไปค้นหาที่ google และเข้าไปเรื่อย ๆ ก็พบว่าน่าจะมีที่มาจาก blog นี้ Geek :: Hard core Debugging ซึ่งเขียนมาตั้งแต่เดือนสิงหาคม ปี 2003 โน่นเลย (ผมยังไม่รู้จัก computer เลย)

แสดงว่า ต้องมีต้นฉบับมาอีก แน่ ๆ จึงไปค้นหาคำว่า Somebody taped this on their door at work ก็เลยพบคำตอบ ซึ่งเกิดหลังจาก Debug session นั่นเอง !! ก็ทำให้คลายความสงสัยไปได้บ้าง ... แต่ก็อาจจะมีที่มาก่อนหน้านั้นก็ได้นะ ไม่เข้าใจว่า จะรู้ไปทำ ... อะไร !!

สุดท้ายแล้ว

เมื่อทำการ debug เสร็จสิ้น นั่นแสดงว่ารู้ปัญหาแล้ว ก็ให้เขียนชุดของการทดสอบเสียนะ จากนั้นจึงเริ่มทำการแก้ไข และหวังว่า จะไม่กลับมา debug code ที่เดิมอีกนะ เพราะว่า มีชุดการทดสอบครอบคลุมไปแล้ว Reference Websites http://plasmasturm.org/log/6debug/ http://mwcremer.blogspot.com/2007/06/six-stages-of-debugging.html https://www.reddit.com/r/ProgrammerHumor/comments/1r0cw7/the_5_stages_of_debugging/

↧

YAHOO! เปิดให้ download ฐานข้อมูลขนาดใหญ่กันแล้ว

March 15, 2016, 2:13 am

≫ Next: สิ่งที่เปลี่ยนแปลงใน Swift 2.2 มีอะไรบ้างนะ ?

≪ Previous: มาดูที่มาที่ไปของ Six Stages of Debugging กันหน่อย

yahoo

วันนี้เพิ่งเห็นว่าทาง Yahoo ได้เปิดเผยฐานข้อมูลขนาดใหญ่ให้ใช้งานกันได้แล้ว ตามจริงประกาศออกมาตั้งแต่เดือนมกราคมแล้วนะ !! ตกข่าวสุด ๆ ดังนั้นจึงนำมาสรุปกันนิดหน่อย ทาง Yahoo ได้เปิดฐานข้อมูล Webscope ให้ทุกคนทำการ download เพื่อไปใช้งานกันฟรี ๆ แล้ว ซึ่งข้อมูลมีขนาดถึง 13.5 TB (Terabyte) โดยเป็นข้อมูลของผู้ใช้งานของ Yahoo กว่า 20 ล้านคน ที่เข้ามาอ่านข่าวสาร และ ข้อมูลต่าง ๆ นั่นเอง ข้อมูลจะประกอบไปด้วย

ลองเอาข้อมูลบางส่วนมาเปิดดูรายละเอียดหน่อยสิ อ่านจนตาลายกันไปเลย !! Yahoo-data-3

โดยข้อมูลเหล่านี้ น่าจะเป็นประโยชน์สำหรับ

นักวิจัยค้นคว้า
Data scientist
สายงาน Machine learning และ Recommendation system
ใช้สำหรับการทดสอบ model ต่าง ๆ ว่าจะเป็นอย่างไรกับข้อมูลจริง ๆ
และสำหรับผู้ที่สนใจทุกคน

รวมทั้งเข้ามาช่วยลดปัญหา เรื่องการขาดแคลนข้อมูลขนาดใหญ่ เพื่อนำมาศึกษา วิเคราะห์ และ ทดสอบลงไปได้บ้าง ว่าง ๆ ก็ไป Download กันได้ที่ Webscope project Reference Websites https://yahooresearch.tumblr.com/ https://dzone.com/articles/yahoo-open-largest-database-to-the-public

↧

สิ่งที่เปลี่ยนแปลงใน Swift 2.2 มีอะไรบ้างนะ ?

March 15, 2016, 9:22 am

≫ Next: ในขณะที่ Developer เขียน code นั้นเสียเวลาไปกับอะไรบ้าง ?

≪ Previous: YAHOO! เปิดให้ download ฐานข้อมูลขนาดใหญ่กันแล้ว

swift

หลังจากทำการ update Swift 2.2 ผลที่ได้คือ warning ใน code เพียบเลย !! ดังนั้นจึงทำการอ่าน และ สรุปสิ่งที่เปลี่ยนกันหน่อยสิว่ามีอะไรบ้าง ? ซึ่งพบว่า

มีกลุ่มของ feature ที่มันเปลี่ยนไปแบบหน้ามือเป็นหลังมือ
มีการเพิ่ม feature ที่ขาดหายไป
มี feature ที่ถูก deprecated บางตัวก็ออกจะดูแปลก ๆ อีกด้วย

มันดูกันว่ามีอะไรบ้าง ? ซึ่งสรุปมาจาก code ในงานที่ทำนิดหน่อย

เริ่มจากอย่างแรกเลยคือ ++ และ -- (เอาที่สบายใจ)

เป็นสิ่งที่ประหลาดใจสุด ๆ ซึ่งจะถูกนำออกจาก Swift 3.0 อย่างแน่นอน โดยแนะนำให้ไปใช้ +=1 และ -=1 แทนนะ

ดังนั้นจึงมีผลทำให้ for loop แบบ C-Style ได้รับผลกระทบไปด้วย แนะนำให้ใช้ loop over a range ซะ ดังนี้

สำหรับการใช้งาน range ก็อย่าไปทำแบบตัวเริ่มต้นมากกว่าตัวสิ้นสุดนะ ไม่งั้นจะเกิด Runtime error ( Compile ผ่านนะ ) แนะนำให้ใช้ method reverse() ซะ

ข่าวดีคือ Array และ Slice มี method removeFirst() แล้วนะ

น่าจะทำให้สบายมากขึ้น [gist id="184c5d5240d436ccc252" file="movefirst.swift"]

สามารถเปรียบเทียบข้อมูลใน Tuple แบบง่าย ๆ ได้ล่ะ

ทำให้การเขียน code สบายขึ้นมาก ๆ ซึ่งก่อนหน้านี้ไม่สามารถทำการเปรียบเทียบข้อมูลแบบนี้ได้ [gist id="184c5d5240d436ccc252" file="tuple.swift"]

อีกอันที่เจอมากับตัวเอง คือ Stringified selectors มันถูก deprecated แล้ว

โดยใน Swift 2.2 แนะนำให้เขียน #selector() แทนนะครับ น่าจะเจอมากในส่วนของ UI เช่น Button ต้องเขียนเป็น #selector(yourActionMethod()) ซึ่งถ้า method นี้ไม่มีจริง ๆ จะ compile ไม่ผ่านนะ

Initialized class ไม่ผ่าน !!

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

ถ้าเราต้องการเขียน code ภาษา Swift หลากหลาย version ในไฟล์เดียว !!

ก็สามารถทำได้ด้วย เนื่องจากได้เพิ่มการตรวจสอบ version ของ Swift ให้ ตัวอย่างเช่น [gist id="184c5d5240d436ccc252" file="checking.swift"]

สำหรับชาว debugging กันบ้าง

ถ้าต้องการแสดงค่าของ

ชื่อไฟล์
หมายเลขบรรทัด และ column
ชื่อ method/function

ก็เปลี่ยนไปใช้ # นำหน้าหมดเลย ดังตัวอย่าง [gist id="184c5d5240d436ccc252" file="debug.swift"]

สรุปเพียงเท่านี้ก่อนก็แล้วกัน

แต่จากเอกสารจะบอกว่าสิ่งที่เปลี่ยนแปลงไปนั้น จะทำให้นักพัฒนาเขียน code ได้รวดเร็วขึ้น !! ว่าง ๆ ลองไปอ่านเพิ่มเติมกันได้ที่ Swift Documentation นะ รวมทั้ง Changelog ของ Swift 3.0 กัน

↧

ในขณะที่ Developer เขียน code นั้นเสียเวลาไปกับอะไรบ้าง ?

March 17, 2016, 7:32 am

≫ Next: สวัสดีกับ Jenkins 2.0 Preview กันหน่อย

≪ Previous: สิ่งที่เปลี่ยนแปลงใน Swift 2.2 มีอะไรบ้างนะ ?

waste-time

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

1. คุณจัดเรียงลำดับความสำคัญของานหรือไม่ ?

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

ปัญหาหลัก ๆ ไม่ได้มาจากการทำงานได้มากหรือน้อย แต่เราไม่ได้ทำงานตามลำดับความสำคัญมากกว่า !!

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

2. คุณจัดการกับสิ่งรบกวนต่าง ๆ หรือไม่ อย่างไร ?

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

ความสะอาด หรือ รก ของโต๊ะทำงาน
บรรดา social media ต่าง ๆ
เกมส์
Email
Chat
Youtube
การใช้มือถือ

แต่ถ้าจะให้ดีก็ทำการปิด Internet, WIFI และ 3G/4G ซะ

3. ในระหว่างวัน คุณหยุดพักบ้างหรือไม่ ?

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

การนั่งนิ่ง ๆ
การออกไปเดินในที่ที่อากาศถ่ายเท
ดื่มชาร้อน ๆ
ออกกำลังกายหนัก ๆ

ปล. การหยุดเล่น Internet การหยุดมา chat การหยุดมาเล่นเกมส์ มันไม่ใช่การหยุดพักผ่อนนะ !!

4. คุณทำการกำหนดกรอบเวลาของแต่ละงานไว้หรือไม่ ? แล้วหยุดทำตามหรือไม่ ?

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

5. คุณทำงานโดยมีเป้าหมายหรือไม่ ?

ถ้า Developer ไม่มีเป้าหมายในการทำงาน มันก็จะมีงานเข้ามามากมาย ทั้งงานเร่ง งานด่วน งานด่วนมาก ๆ ทำให้มีงานจนล้นมือ สุดท้ายก็ไม่มีงานอะไรเสร็จสักอย่าง ดังนั้นให้กำหนดเป้าหมายหลักของการทำงานไว้ซะ จากนั้นก็ค่อย ๆ ทำงานทีละเล็กทีละน้อย เพื่อให้ไปถึงเป้าหมายเหล่านั้น ซึ่งควรอยู่ใน TODO list ของแต่ละวันไปด้วยเลย TODO list -> Success list -> Happy list

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

↧

สวัสดีกับ Jenkins 2.0 Preview กันหน่อย

March 18, 2016, 12:45 am

≫ Next: ผลการสำรวจเรื่องความปลอดภัยของ Mobile app จาก Arxan.com

≪ Previous: ในขณะที่ Developer เขียน code นั้นเสียเวลาไปกับอะไรบ้าง ?

my-jenkins

ตอนนี้ Jenkins 2.0 Preview ถูกปล่อยออกมาเพื่อให้ทดสอบใช้งานกันแล้ว โดยใน version ใหม่นี้ทำการปรับปรุงความสามารถหลายอย่าง ทั้งเรื่องของ

Delivery pipeline ซึ่งจัดการด้วย code กันเลย
การติดตั้งแบบใหม่ มีให้เลือก plugin ก่อนด้วย
ทำการปรับปรุง User Interface และ Usability ต่าง ๆ อีกด้วย
ยังทำงานกับ version เก่า ๆ ได้

ดังนั้นมาดูรายละเอียดในแต่ละข้อกันดีกว่า

ว่าด้วยเรื่องของ Delivery pipeline

เป็นปัญหาหลัก ๆ ของ Jenkins สำหรับจัดการเรื่อง Continuous Integration ไปจนถึง Continuous Delivery/Deployment เนื่องจากจัดการได้ยาก แถมยังต้องติดตั้ง plugin อื่น ๆ อีก ดังนั้นจึงต้องการรูปแบบการจัดการที่ง่ายและสะดวกมากยิ่งขึ้น รวมทั้งยังสามารถ visualize delivery pipeline ได้อีก โดยใน Jenkins 2.0 จึงทำการเพิ่ม Delivery pipeline เข้ามา สำหรับการสร้าง Job/Item กันไปเลย เรียกว่า Pipeline plugin ซึ่งจะเขียนด้วย DSL (Domain Specific Language) รวมทั้งเขียนด้วยภาษา Groovy ได้ด้วย ทำให้เราสามารถออกแบบ และ สร้าง pipeline การส่งมอบระบบด้วย code กันไปเลย มันง่ายหรือเปล่าต้องลองดูกันเอง ตัวอย่างของ Android project [gist id="6313e435bf53a6cc7b3e" file="Jenkinsfile"] มี Pipeline Stage View ให้ใช้งานกันอีก มันคือ visualize ของการทำงานนั่นเอง pipeline-stage-view.thumb

ยังไม่พอนะ สำหรับแฟน ๆ ของ Git และ Github ได้สบายกันล่ะ

เนื่องจากจะเป็น plugin ที่ build in มาให้กันไปเลย ทำให้จัดการได้ง่ายยิ่งขึ้นไปอีก

มาดูในส่วนของการปรับปรุง Usability กันบ้าง

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

อีกทั้งยังทำการปรับปรุง User Interface ในหน้าต่าง ๆ อีก ตัวอย่างเช่นหน้า Configuration ของแต่ละ Item/Job แสดงดังรูป j06

มาลองติดตั้งและใช้งาน Jenkins 2.0 Preview กันดีกว่า

ให้ทำการ Download จากที่นี่ หรือไปที่ Jenkins 2.0 preview จากนั้นก็เลือก package ตาม OS ที่ต้องการกันไปเลย ทำการ start Jenkins server ซึ่งผมใช้ war file ก็ทำดังนี้ [code]$java -jar jenkins.war[/code] เข้าใช้งานที่ http://localhost:8080 ก็จะเจอหน้านี้ ครั้งแรกน่าจะงงกันหน่อย เพราะว่า จะเอา security code มาจากไหนกัน ? แต่ไม่ต้องตกใจไปเอามาจาก log file หรือ console ของ Jenkins นั่นเอง j01

จากนั้นเข้าสู่หน้าแนะนำ plugin และ ติดตั้งกัน แนะนำให้เลือก Install suggested plugins แล้วจะมี feature ให้ใช้เยอะมาก ๆ ทำการติดตั้ง plugin j03

ต่อมาให้ทำการสร้าง username ที่เป็น Admin เพื่อจัดการระบบ ถือว่าเป็นการปรับปรุงเรื่อง security ของ Jenkins กันเลยทีเดียว j07

เข้าสู่หน้าหลักของ Jenkins พบว่ายังคงหน้าตาเหมือนกับ version ก่อนหน้า j09

จากการทดลองใช้งาน Jenkins 2.0 preview มา ก็หน้าตาดูดีขึ้นมา จัดการ plugin ได้ดี ส่วนเรื่องอื่น ๆ ต้องลองใช้งานกันต่อไป ส่วนแผนการพัฒนา feature ต่าง ๆ ดูเพิ่มเติมได้ที่นี่

↧

ผลการสำรวจเรื่องความปลอดภัยของ Mobile app จาก Arxan.com

March 20, 2016, 8:36 am

≫ Next: มาแบ่งกลุ่มของการทดสอบด้วย Five Ws กันหน่อย

≪ Previous: สวัสดีกับ Jenkins 2.0 Preview กันหน่อย

mobile-security

ได้อ่านผลการสำรวจเรื่อง ความปลอดภัยของ Mobile app จาก State of Application Security, Perception versus Reality มันทำให้เราเห็นว่า ผู้ใช้งานส่วนใหญ่คิดว่า app ที่ใช้มันปลอดภัย แต่ในความเป็นจริงกลับตรงกันข้าม !! ที่สำคัญคือ มันแย่กว่าที่เราคิดกันอย่างมากมาย ดังนั้นมาดูรายละเอียดเพิ่มเติมกันหน่อย

มาดูผลสำรวจเรื่องความปลอดภัยของ Mobile app ในฝั่งผู้ใช้งาน

โดยทำการสัมภาษณ์กว่า 1,100 คน จากประเทศใน US, UK, เยอรมัน และ ญี่ปุ่น จะเน้นไปที่ Mobile app เกี่ยวกับสุขภาพและการเงิน

ผลการสำรวจคือ ผู้ใช้งานกว่า 80% เชื่อว่า app ที่ใช้มีความปลอดภัยเพียงพอ

แต่เมื่อไปดูในความเป็นจริงกลับ Mobile app เหล่านั้นกลับพบว่าตรงกันข้าม !!

จากการทดสอบ Mobile app จำนวน 126 app ของ Arxan พบว่ามี app มากกว่า 90% นั้นมีความปลอดภัยที่ไม่เพียงพอ เนื่องจาก app ต่าง ๆ เหล่านั้นจะโดนโจมตีอย่างน้อย 2 เรื่องขึ้นไป จาก Open Web Application Security Project (OWASP) Top 10 Mobile Risks ประกอบไปด้วย

สิ่งที่น่าสนใจคือ App มากกว่า 98% ไม่ได้เข้ารหัส binary code เลย ทำให้สามารถนำไฟล์ต่าง ๆ ของ app เช่น APK และ IPA มาทำการ reverse-engineering หรือ decompile เพื่อดู source code และ แก้ไขได้อย่างง่าย ๆ ยังไม่พอนะมีมากกว่า 84% มีปัญหาเรื่อง การรับส่งข้อมูลผ่าน Network ซึ่งไม่ปลอดภัยเลย ทำให้โดนดักขโมยข้อมูลได้อย่างง่ายอีก !!

อีกผลการสำรวจที่น่าตกใจก็คือ องค์กรมากกว่า 50% บอกตรง ๆ เลยว่า ไม่มีงบประมาณ สำหรับจัดการเรื่องความปลอดภัยของ Mobile app

แสดงดังรูป Reality-of-Security

สามารถอ่านข้อมูลการสำรวจเพิ่มเติมจาก State of Application Security, Perception versus Reality

ดังนั้นในฐานนะของ Mobile developer

ลองถามตัวเองดูสิว่า App ที่ทำการพัฒนานั้น มันมีความปลอดภัยมากพอหรือไม่ ? โดยให้อ้างอิงจาก Open Web Application Security Project (OWASP) Top 10 Mobile Risks นะ Reference Website https://www.arxan.com/2016-state-of-application-security-infographic-consolidated-edition/ https://dzone.com/articles/app-security-its-even-worse-than-you-thought

↧

มาแบ่งกลุ่มของการทดสอบด้วย Five Ws กันหน่อย

March 21, 2016, 4:57 am

≫ Next: Developer ใช้ Coding Standard กันหรือเปล่านะ ?

≪ Previous: ผลการสำรวจเรื่องความปลอดภัยของ Mobile app จาก Arxan.com

RiskReduced-760x507

ในการทดสอบ Software นั้น มีวิธีการและแนวทางที่เยอะมาก ดังนั้น เรามาลองแบ่งกลุ่มของการทดสอบ ตามแนวทางของ Five Ws กันหน่อย ประกอบไปด้วย

Who ? ทดสอบเพื่อใคร
What ? ทดสอบอะไร
Where ? ทดสอบที่ไหน
When ? ทดสอบเมื่อใด
Why ? ทดสอบไปทำไม
How ? ทดสอบอย่างไร

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

1. Who ? Programmer vs. Customer

เราทำการทดสอบเพื่อทำให้มั่นใจว่า software ทำงานได้ตามที่คาดหวังนะ ทั้งในมุมมองของ Programmer และ Customer (ลูกค้า) ซึ่งแต่ละฝั่งต่างมีชุดการทดสอบ เพื่อสร้างความเชื่อมั่นให้ตนเอง ว่าได้ software ตามที่คาดหวังนะ

2. What ? Functionality vs. Performance vs. Security

ต้องบอกให้ได้ว่า เรากำลังทดสอบอะไรกัน ซึ่งโดยทั่วไปถ้าเราไม่ได้กำหนดแบบเฉพาะเจาะจง ก็มักจะบอกว่า เราทำการทดสอบ feature ต่าง ๆ นั่นเอง หรืออาจจะเรียกว่า Functional requirement แต่สิ่งที่มักจะลืมไปก็คือ Non-functional requirment เช่น Performance และ Security เป็นต้น

3. When ? ทำการทดสอบ หรือ สร้างการทดสอบเมื่อใด ?

ทำก่อน หรือ หลังจากการเขียน code ? ถ้าเราทำการสร้างและทดสอบหลังจากที่เขียน code เสร็จ จะเรียกว่า Test Last ถ้าเราทำการสร้างและระบุการทดสอบก่อนที่จะเขียน code จะเรียกว่า Test First จากทั้งสองแบบนั้น จะพบว่า Test First มันแปลก ๆ ดูไม่เป็นธรรมชาติเลย เนื่องจากจะทดสอบได้ยังไง ถ้าไม่เขียน code ให้เสร็จก่อน !! แต่มันกลับมีข้อดีต่าง ๆ ดังนี้

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

4. Where ? Unit test vs. Integration test vs. System test

การทดสอบนั้นมีหลายระดับเช่น Unit, Integration และ System เป็นต้น

Unit test คือการทดสอบส่วนทำงานหน่อยเล็ก ๆ เช่น class และ method
Integration test คือการทดสอบการทำงานระหว่างหน่วยการทำงานเล็ก ๆ ว่ามันเป็นอย่างไร
System test คือการทดสอบในภาพรวมของระบบ

คำถามคือ จะทดสอบในระดับไหนดีบ้าง ? จงตอบมาหน่อยสิ !!

ซึ่งจำนวนการทดสอบควรเป็นไปตาม Test Pyramid นะ ยิ่งเป็นการทดสอบในภาพใหญ่ หรือ ภาพรวมของระบบ จำนวนการทดสอบยิ่งต้องลดน้อยลงไป

5. Why ? Verification vs. Specification vs. Design

ทำการทดสอบไปทำไม ? ในแต่ละการทดสอบควรมีเหตุผลที่เหมาะสม ว่าจะทดสอบไปทำไม ? เพื่ออะไร ? เช่น

ตรวจสอบการทำงานของ code ของระบบว่า ทำงานได้ตรงตามความคาดหวังนะ
ตรวจสอบว่าทำงานตาม specification นะ
ตรวจสอบว่า code ของระบบทำงานตามที่ได้ออกแบบไว้นะ

คำถามที่น่าสนใจ คือ เราจะทำอย่างไร ? เพื่อให้เรารู้ได้อย่างรวดเร็ว ว่าแต่ละ feature ทำงานได้ถูกต้อง ว่าแต่ละ feature ทำงานได้ตรงตาม spec ว่าแต่ละ feature มีการทำงานตามการออกแบบ

6. How ? Automated test vs. Manual test

จะทำการทดสอบอย่างไรดีล่ะ ? ทดสอบแบบ manual หรือ แบบอัตโนมัติดี ? หรือทำการทดสอบด้วยคน หรือ เครื่องคอมพิวเตอร์ดี ? โดย Manual testing นั้นจะมีประโยชน์อย่างมาก ถ้าทำการทดสอบในรูปแบบ Exploratory testing แต่ถ้าระบบงานที่คุณดูแลนั้น ต้องทำการ deploy/release feature ใหม่ ๆ อยู่อย่างสม่ำเสมอ นั่นหมายความว่า คุณต้องทำการทดสอบซ้ำแล้วซ้ำอีกในทุก ๆ feature หรือเรียกว่าต้องทำ regression testing อยู่เสมอ ถ้าทำการทดสอบแบบ manual คงไม่น่าจะไหว ดังนั้นมาทำการทดสอบแบบอัตโนมัติน่าจะเหมาะสมกว่านะ หรือถ้าทนได้ก็ทำไป !!

มาดูตัวอย่างการนำ Five Ws มาคิด วิเคราะห์ แยกแยะ

ปล. ให้ลองเขียนด้วยตอนเองก่อน แล้วเอามาเทียบกันนะครับ TDD (Test-Driven Development)

Who ? => เพื่อ Programmer
What ? => Functionality
Where ? => Unit และ Integration test
When ? => ก่อนที่จะเขียน code
Why ? => ทำการออกแบบ และ กำหนดการทดสอบของสิ่งที่จะพัฒนา
How ? => Automated test

BDD (Behaviour-Driven Development)

Who ? => เพื่อ Customer
What ? => Functionality
Where ? => System test
When ? => ก่อนที่จะเขียน code
Why ? => ทำการออกแบบ และ กำหนดการทดสอบของสิ่งที่จะพัฒนา
How ? => Automated test

Exploratory test

Who ? => เพื่อ Customer
What ? => Functionality
Where ? => Unit และ Integration test
When ? => หลังจากที่เขียน code เสร็จแล้ว
Why ? => เพื่อทำการตรวจสอบความถูกต้องของระบบ
How ? => Manual test

Security test

Who ? => เพื่อ Customer
What ? => Security
Where ? => System test
When ? => หลังจากที่เขียน code เสร็จแล้ว
Why ? => เพื่อทำการตรวจสอบความถูกต้องของระบบ
How ? => Automated test

โดยทั้ง 6 ข้อนี้ น่าจะพอทำให้เราเห็นว่า

ทำการทดสอบในมุมมองของใครบ้าง ? ทำการทดสอบอะไรบ้าง ? เมื่อใดควรทำการทดสอบ ? ทำการทดสอบส่วนไหนบ้าง ? ทำการทดสอบไปทำไม ? และทำการทดสอบอย่างไร ? ซึ่งถ้าคุณสามารถตอบคำถามเหล่านี้ได้ น่าจะช่วยลดความเสี่ยงต่าง ๆ ลงไปได้ หรือทำให้เห็นว่า คุณมีความเสี่ยงอะไรบ้าง เพื่อจะได้ทำการแก้ไขต่อไปนั่นเอง Reference Website http://securesoftwaredev.com/2012/09/03/a-classification-of-tests/ http://martinfowler.com/bliki/TestPyramid.html

↧

Developer ใช้ Coding Standard กันหรือเปล่านะ ?

March 21, 2016, 7:09 pm

≫ Next: ปรับปรุงคุณภาพของ Software ด้วย Continuous Integration Process กันนะ

≪ Previous: มาแบ่งกลุ่มของการทดสอบด้วย Five Ws กันหน่อย

coding-standard

เป็นคำถามที่น่าสนใจมาก ๆ ดังนั้น Developer จงตอบกันหน่อยว่ามีข้อตกลง หรือ นำ Coding Standard มาใช้หรือไม่ ? ถ้าตอบว่า ใช้ เชิญข้อต่อไป แต่ถ้าไม่ ให้กลับไปคุยกับทีมซะ !! คำถาม แล้วใช้ Coding Standard ตัวไหน ? คำตอบที่น่าจะได้รับคือ ไม่มี Coding Standard อะไรหรอก เนื่องจากแต่ละระบบ แต่ละ project ก็ใช้แตกต่างกันไป ตามความต้องการของงาน ตามความต้องการของทีม

แต่สิ่งที่ควรทำคือ ทุก ๆ คนในทีมต้องใช้มาตรฐานเดียวกัน ใน project เดียวกันต้องใช้มาตรฐานเดียวกัน

คำถาม แล้วคุณทำการเลือก Coding Standard อย่างไร ?

บางคนอาจจะบอกว่า ก็พี่ ๆ ไงล่ะ !! ในแต่ละภาษาโปรแกรมจะมีกลุ่มของ community แน่นอนว่าย่อมเกิด Coding Standard หลัก ๆ ของภาษานั้นมากมาย แถมมีการโต้เถียงจนก่อให้เกิดลัทธิ หรือ กลุ่มย่อย ๆ ของแต่ละภาษาไปอีก ซึ่งมันเป็นเรื่องปกติ ไม่แปลกอะไร เช่น

ภาษา C อาจจะเลือกใช้ GNU Coding standard
ภาษา Java อาจจะเลือกใช้ Google Java Style
ภาษา ruby อาจจะเลือกใช้ Bozhidar Batsov’s community-influenced standard

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

คำถาม ในการพูดคุยมักมีความเห็นไม่ตรงกัน จะทำอย่างไรดี ?

เป็นปัญหาหลัก ๆ เลยของการเลือก มักจะมีความคิดเห็นไม่ตรงกัน ทั้งจากความชอบส่วนตัว ทั้งจากประสบการณ์ส่วนตัว ทั้งจากเขาบอกมา !!

แต่ส่วนใหญ่มักจะมีข้อขัดแย้งกันระหว่าง ความถูกต้อง vs. ความสวยงาม vs. ตามหลักหรือรูปแบบของภาษานั้น ๆ

ตัวอย่างเช่นปัญหาโลกแตกของ {} [gist id="4ce525243bc90c1ba6d1" file="first.php"] ไม่ว่าจะเป็น Tab vs Spacebar !! ไม่ว่าจะเป็นรูปแบบการตั้งชื่อ !! ไม่ว่าจะเป็นโครงสร้างของ code !! ไม่ว่าจะเป็น ... จะเลือกอะไรดีล่ะ ?

คำถาม คุณต้องเสียเวลา และ มีค่าใช้จ่ายมากเท่าไรในการเลือก ?

ลองถามตัวคุณเองและทีมสิว่า

เสียเวลาไปเท่าไรในการพูดคุยกัน แต่สุดท้ายไม่ได้ข้อสรุปอะไรเลย ?
พูดคุย และ เถียงกันผ่าน email มากน้อยเพียงใด ?
ทำให้ความสัมพันธ์ของคนในทีมแย่ลงไปอีกหรือไม่ ?
รู้สึกอย่างไรบ้าง เมื่อต้องเขียน code ในรูปแบบที่ไม่ชอบ ?

จงอย่าเสียเวลาไปกับการเลือกมากนัก เอาแต่พอดี แต่ให้ลงมือทำในรอบสั้น ๆ แล้วให้ทีมกลับมาพูดคุยกัน เพื่อดูว่าสิ่งที่เลือกไปนั้นมันได้ผลออกมาดีหรือแย่อย่างไร แล้วให้ปรับปรุงอยู่อย่างเสมอ (Continuous Improvement)

ดังนั้นจริง ๆ แล้ว ให้ลองกลับมาดูเป้าหมายของ Coding Standard กันหน่อยไหมว่าคืออะไร ?

เป้าหมายเพื่อให้แนวทางการเขียน code เป็นไปในทิศทางเดียวกัน เพื่อทำให้ทีมเดินไปข้างหน้าอย่างพร้อมเพรียงกัน เพื่อทำให้ทีมเดินไปข้างหน้าได้อย่างรวดเร็ว บางทีมอาจจะมี Team Lead ที่มากประสบการณ์ เป็นคนเลือกให้ทีมไปเลยก็เป็นได้ !! คำถามคือ คุณทำการเลือก Coding Standard กันอย่างไรบ้าง ? อย่าบอกนะว่า ไม่เคยใช้กันเลย เขียนตามอารมณ์ของตัวเองไปเรื่อย ๆ !! หรือว่ามีนะ แต่มันอยู่ในเอกสารและกระดาษ !! แต่ละคนในทีมเขียน code ที่มีรูปแบบเหมือนกันหรือไม่ ? แล้วรู้ได้อย่างไร ?

↧