ทำไม developer กลัวการ refactor code ?

October 19, 2016, 9:31 am

≫ Next: มาสร้างระบบ Continuous Integration สำหรับ Android app กันดีกว่า

fear_01

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

เหตุผลที่ developer กลัวการแก้ไข code ?

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

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

ถ้าไม่มั่นใจว่าระบบที่แก้ไขกระทบส่วนไหนบ้าง ? จะต้องถามใคร ? จะต้องดูเอกสารที่ไหน ? ใครที่จะบอกได้ว่าสิ่งใดถูก สิ่งใดผิด ? ใครจะอธิบายได้ ? ใครจะช่วยทดสอบได้ ?

Developer ลองถามตัวเองสิว่า เราจะลดความกลัวเหล่านี้ไปได้อย่างไร ?

↧

มาสร้างระบบ Continuous Integration สำหรับ Android app กันดีกว่า

October 20, 2016, 8:17 pm

≫ Next: Docker กับระบบ Legacy ที่พัฒนาด้วยภาษา COBOL

≪ Previous: ทำไม developer กลัวการ refactor code ?

android-ci

วันนี้นั่งสร้างระบบ Continuous Integration (CI) สำหรับ Android app นิดหน่อย เพื่อทำการ integrate ส่วนการทำงานต่าง ๆ เข้าด้วยกัน ทำการ build และ ทดสอบระบบแบบอัตโนมัติ ทำให้เรารู้ข้อผิดพลาด เพื่อทำการแก้ไขได้อย่างรวดเร็ว ดังนั้นมาดูกันว่าจะทำการสร้างระบบ CI อย่างไรกันบ้าง ?

เริ่มจาก CI Server มีอะไรให้ใช้บ้าง ?

ถ้าที่ผมใช้ประจำก็คือ Jenkins เป็น Opensource มัน Free มี plugin ให้ใช้เพียบ เอกสารเยอะ สามารถทำการติดตั้งที่ server ของเราเองได้ ถามว่ามีเครื่องมืออื่น ๆ อีกไหม ? ตอบได้เลยว่ามากมาย ตัวอย่างเช่น ถ้าเป็นระบบ opensource ก็ใช้ TravisCI ได้ ซึ่งเป็น Free cloud service หรือถ้ามีเงินก็ซื้อพวก TeamCity มาใช้ก็ได้ ซึ่งมีความสามารถที่เยอะกว่าและดีกว่าแน่นอน

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

สิ่งที่ต้องคิดและออกแบบเสมอคือ flow/process หรือขั้นตอนการทำงานของ CI ?

หรือบางครั้งจะเรียกว่า build pipeline หรือ build process ตั้งแต่การดึง source code ใน version ที่ต้องการ ไปจนถึงการ build, test และ deploy เพื่อทำให้เรามั่นใจในการทำงานของระบบ ว่ามีคุณภาพมากเพียงพอ ที่ทำให้เรามีความมั่นใจหรือไม่ ? แนะนำให้ทำการคิดและออกแบบก่อนสร้างเสมอนะครับ ตัวอย่างเช่น

ขั้นตอนที่ 1 ทำการดึง code จาก version control ใน brach ที่ต้องการ
ขั้นตอนที่ 2 ทำการวิเคราะห์ source code ด้วยเครื่องมือพวก Static Code Analysis
ขั้นตอนที่ 3 ทำการทดสอบ Unit test
ขั้นตอนที่ 4 ทำการทดสอบ User Interface test
ขั้นตอนที่ 5 ทำการทดสอบ End-to-End test
ขั้นตอนที่ 6 ทำการทดสอบStress test
ขั้นตอนที่ 7 ทำการสร้างไฟล์ APK สำหรับการ deploy
ขั้นตอนที่ 8 ทำการ deploy ระบบ

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

1. การวิเคราะห์ source code

Android Lint ทำการตรวจสอบทั้งไฟล์ java และ xml ต่าง ๆ ใน Android project ช่วยดูทั้งเรื่องจุดที่มีโอกาสจะเกิด bug การตรวจสอบความถูกต้องของการตั้งชื่อ การใช้งาน เรื่องของ security และ performance เรื่องของ usability และ accessibility อีกต่างหาก Facebook Infer ช่วยตรวจสอบเรื่องของ Null pointer exception และ resource leak เพื่อทำให้เรามั่นใจใน code มากยิ่งขึ้น และยังมีเครื่องมืออื่น ๆ ซึ่ง Java developer น่าจะรู้จักเช่น

2. การทดสอบ

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

Unit Testing ใช้ jUnit4
แต่ถ้าใน code ที่ทดสอบ Unit testing มี library ของ Android แล้วจะไม่สามารถทดสอบได้ ต้องใช้ Instrumentation test ของ Android แทนนะครับ
UI Testing ใช้งาน Espresso
End-to-End Testing สามารถใช้ได้ทั้ง Appium และ Calabash
Stress Testing ใช้งาน Monkey test ซึ่งเขียน shell script ง่าย ๆ ก็ใช้ได้แล้ว

โดยการทำงานตั้งแต่การ build, test, สร้างไฟล์ APK และ deploy นั้น จะทำงานผ่าน gradle ทั้งหมดเลย

แน่นอนว่าแต่ละขั้นตอนจะถูกกำหนดไว้ใน CI Server นั่นเอง

เมื่อใดก็ตามที่ code ใน version control มีการเปลี่ยนแปลง CI Server จะทำงานตามขั้นตอนต่าง ๆ เหล่านี้แบบอัตโนมัติ มันน่าจะทำให้ทีมพัฒนารู้สึกดีขึ้นมาบ้าง

↧

Docker กับระบบ Legacy ที่พัฒนาด้วยภาษา COBOL

October 21, 2016, 6:25 am

≫ Next: มาดูการเปลี่ยนแปลงของ Selenium 3 กัน

≪ Previous: มาสร้างระบบ Continuous Integration สำหรับ Android app กันดีกว่า

docker-cobol

วันนี้มีโอกาสเข้าไปยุ่งเกี่ยวกับระบบ Legacy ซึ่งพัฒนาด้วยภาษา COBOL (Common Business Oriented Language) เพียงแค่ฟังชื่อก็น่ากลัวแล้ว ยิ่งเป็นระบบงานใหญ่ ๆ ไม่ต้องพูดถึง น่ากลัวมาก ๆ ที่สำคัญระบบนี้กลับกลายเป็นปัญหาหลักของบริษัท แต่ดันเป็นระบบที่สร้างรายได้ให้บริษัท !! ดังนั้นเราลองมา run ระบบ Legacy ที่พัฒนาด้วยภาษา COBOL ด้วย Docker กันดีกว่า เพื่อทำให้เราเข้าใจ และ ศึกษาได้ง่ายขึ้น

ก่อนอื่นก็ต้องเริ่มจาก Hello World ภาษา COBOL แบบง่าย ๆ

[gist id="4967faea083439899f57247ab87a9053" file="helloworld.cbl"]

จากนั้นมาสร้าง Docker Image สำหรับ run COBOL กันหน่อย

ซึ่งต้องติดตั้ง open cobol นั่นเอง [gist id="4967faea083439899f57247ab87a9053" file="Dockerfile"] ทำการสร้าง image กันเถอะ [code] $docker build -t cobol-helloworld . [/code] ทำการ run ระบบ Hello world กันเลย [code] $docker run cobol-helloworld [/code] ผลที่ออกมาคือแสดงประโยค Hello world from COBOL เท่านี้ก็สามารถเริ่มต้นได้แล้วครับ

การทำงานกับระบบ Legacy ด้วย Docker

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

↧

มาดูการเปลี่ยนแปลงของ Selenium 3 กัน

October 21, 2016, 7:15 pm

≫ Next: รู้หรือไม่ว่า Git สามารถนำมาสร้าง NoSQL Database แบบ Key-Value ได้นะ

≪ Previous: Docker กับระบบ Legacy ที่พัฒนาด้วยภาษา COBOL

z13

เมื่อวันที่ 13 ตุลาคมนั้นทางทีมพัฒนาของ SeleniumHQ ได้ปล่อย Selenium 3 (Final version) ออกมา เป็นการเปลี่ยนแปลงครั้งยิ่งใหญ่ตั้งแต่ version 2.53.1 หรือในรอบ 5 ปีนั่นเอง !! โดยการเปลี่ยนแปลงประกอบไปด้วย

Selenium Core ซึ่งเป็นส่วนการทำงานหลัก
WebDriver API ซึ่งส่งผลกระทบทั้งหมดทั้ง Mozilla Firefox, Safari, IE และ Google Chrome แต่ก็ทำให้การทำงานเร็วขึ้น
SeleniumGrid ซึ่งไม่กระทบกับของเดิมเท่าไรนัก

สิ่งที่เห็นได้ชัดจากการเปลี่ยนแปลงจาก version 2 มา 3 คือ WebDriver

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

ผลที่ตามมาคือ การทดสอบใน browser ต่าง ๆ จะทำงานได้ดีขึ้น จะทำงานได้รวดเร็วขึ้น จะทำงานได้เสถียรมากขึ้น

โดยทาง SeleniumHQ ได้สรุปรายชื่อ WebDriver ไว้ดังนี้

ที่สำคัญทางทีม SEleniumHQ ไม่ได้ดูแลหรือพัฒนานะครับ selenium3

และที่น่าสนใจก็คือ Selenium WebDriver กำลัง implement

ให้เป็นไปตามมาตรฐาน WebDriver W3C อีกด้วย (Browser Automation) ซึ่ง roadmap น่าจะเป็นดังรูป selenium_roadmap_2

ผลกระทบต่าง ๆ ทั้งก่อนหน้านี้และที่ตามมา เช่น

สำหรับ Firefox 46 ขึ้นไป เนื่องจากเปลี่ยนมาใช้ Gecko driver
สำหรับ Google Chrome ก็ให้ทำการ download chrome driver ใหม่มานะ

สุดท้ายแล้วอย่าลืม upgrade กันนะครับ มันทำงานได้รวดเร็วขึ้นมากมาย น่าจะทำให้การทดสอบสนุกยิ่งขึ้น Reference Websites https://seleniumhq.wordpress.com/2016/10/13/selenium-3-0-out-now/ https://seleniumhq.wordpress.com/2016/10/04/selenium-3-is-coming/

↧

รู้หรือไม่ว่า Git สามารถนำมาสร้าง NoSQL Database แบบ Key-Value ได้นะ

October 23, 2016, 5:07 am

≫ Next: 5ส สำหรับการพัฒนา software

≪ Previous: มาดูการเปลี่ยนแปลงของ Selenium 3 กัน

git-nosql

ช่วงวันหยุดมีคำถามที่น่าสนใจเกี่ยวกับ Git ขึ้นมาคือ ถ้าต้องการเก็บข้อมูลต่าง ๆ ด้วย Git ล่ะ ให้เหมือนกับ NoSQL database ล่ะ จะทำอย่างไรดี ? ดังนั้นมาลองใช้งานกันหน่อยสิ

เริ่มด้วยวิธีการง่าย ๆ

ทำการบันทึกและอ่านข้อมูล [code] //บันทึกข้อมูล $ echo '{"id": 1, "name": "Somkiat", "age": 30}' > 1.json $ git add 1.json $ git commit -m "Add new data" //อ่านข้อมูล $ git show master:1.json {"id": 1, "name": "Somkiat", "age": 30} Raw [/code] ซึ่งเป็นการจัดการข้อมูลในรูปแบบ Key-value database โดย key คือ path เต็ม ๆ ของไฟล์ที่เราต้องการ ส่วน value คือ ข้อมูลที่อยู่ในไฟล์ แต่วิธีการนี้ก็มีข้อเสียคือ

ต้องทำการบันทึกข้อมูลลงไฟล์ก่อน จากนั้นจึงบันทึกข้อมูลเข้า git ซึ่งทำให้เสียเวลา
ขั้นตอนการบันทึกข้อมูลเยอะเกินไป
ถ้าไฟล์ที่ต้องการอยู่ใน path ลึก ๆ น่าจะแย่นะ

ดังนั้นถ้าต้องการแก้ไขปัญหานี้ล่ะ ทำอย่างไรดี ?

โดยใน Git นั้นสามารถทำการ hashing และจัดเก็บข้อมูลผ่าน standard input ได้เลย ซึ่งผลที่ได้คือ ขั้นตอนการบันทึกข้อมูลง่ายขึ้นมาก รวมทั้งผลที่ได้จากการบันทึกคือ key ที่ unique เพื่อใช้อ้างถึงเอกสารนั้น ๆ ได้เลย สามารถทำได้ดังนี้ [code] //บันทึกข้อมูล $ echo '{"id": 1, "name": "Somkiat", "age": 30}' | git hash-object -w --stdin f8d407f8880d3126c45cc38dee9f025ddcd816ad //อ่านข้อมูล $ git cat-file -p f8d407f8880d3126c45cc38dee9f025ddcd816ad {"id": 1, "name": "Somkiat", "age": 30} [/code]

เพิ่งรู้เลยว่า Git มันก็ทำแบบนี้ได้ด้วย

จากนั้นก็นำไปสร้างระบบแบบง่าย ๆ กันได้เลย อ่านข้อมูลเพิ่มเติมจาก Link ด้านล่างได้เลยครับ มีรายละเอียดเชิงเลิกอีกมากมายให้เราได้เรียนรู้กันต่อไป เช่น การ uddate ข้อมูล การจัดการ version ของข้อมูล Reference Websites https://www.kenneth-truyers.net/2016/10/13/git-nosql-database/

↧

5ส สำหรับการพัฒนา software

October 24, 2016, 1:19 am

≫ Next: สิ่งเน้นย้ำสำหรับ Developer ที่ดี

≪ Previous: รู้หรือไม่ว่า Git สามารถนำมาสร้าง NoSQL Database แบบ Key-Value ได้นะ

mess

คิดว่า developer หลาย ๆ คนน่าจะรู้จักกับ 5ส หรือ 5S

5S was developed in Japan and was identified as one of the techniques that enabled Just in Time manufacturing

ซึ่งประกอบไปด้วย

Seiri หรือ Sort/Clearing/Classify หรือ สะสาง
Seiton หรือ Systematic Arrangement/Streamline/Simplify/Configure หรือ สะดวก
Seiso หรือ Shine/Cleanliness/Clean and check หรือ สะอาด
Seiketsu หรือ Standardize/Conformity หรือ สร้างมาตรฐาน
Shitsuke หรือ Sustain the discipline/Custom and practice หรือ สร้างนิสัย

เมื่อนำ 5ส มาประยุกต์ใช้ในการพัฒนา จะเป็นอย่างไรนะ ? หรือบางที่อาจจะเรียกว่า 5C คือ

Clearing
Configure
Clean and Check
Conformity and finally
Custom and practice

เริ่มต้นด้วยสะสาง

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

การสำรวจตรวจดู
การแยกแยะ
การลบหรือขจัดทิ้งไป

ถ้ามองมาในการพัฒนา software มีอะไรบ้าง ?

การลบ code ที่ไม่ถูกใช้งานออกไป
การลบ library ที่ไม่ถูกใช้งานออกไป
การลบ software ที่ไม่ถูกใช้งานออกไป

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

ต่อมาคือ สะดวก

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

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

ถ้ามองมาในการพัฒนา software มีอะไรบ้าง ? ถ้าทำการเขียน script ต่าง ๆ บ่อย ๆ เช่น การ compile, build, test, run และ deploy ก็ให้ทำการสร้างไฟล์ build script ไว้ซะ สำหรับ developer ก็ควรศึกษาหรือฝึกใช้งาน shortcut ต่าง ๆ ของ Text editor และ IDE ที่ใช้งานไว้ด้วย เพื่อทำให้การเขียน code ไหลลื่นมากยิ่งขึ้น ดังนั้นการทำงานเข้าใจเรื่องของเครื่องมือที่ใช้งานมันสำคัญมาก ๆ นะ สำหรับ code ที่เขียนขึ้นมา ก็ควรจัดกลุ่มของ code ออกเป็น module แต่ละ class ควรทำงานเรื่องเดียวกัน ชื่อ method/function ก็ควรสื่สารได้ชัดเจน แน่นอนว่า code ใน method/function ก็ควรสอดคล้องกัน ถ้าต้องการลดความผิดพลาดและเสียเวลาไปโดยเปล่าประโยชน์ ก็ให้ทำการ review code และคุยกับคนอื่น ๆ ในทีมซะ ไม่เช่นกันสิ่งที่กำลังพัฒนาอาจจะออกทะเลไปแล้วก็ได้ ซึ่งมันเสียเวลามาก ๆ ให้ทำการสร้าง workflow หรือขั้นตอนการทำงานที่เรียบง่ายขึ้นมา หรือมันคือ KISS (Keep It Simple Stupid) เช่นขั้นตอนการ deploy ระบบงาน ลองคิดดูสิว่า ถ้ายอมเสียเวลามาสร้างระบบ one-click deploy มันจะมีประโยชน์มากเพียงใด

ต่อมาคือ สะอาด

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

ระบุพื้นที่
หาและกำจัดต้นเหตุของความสกปรก
ทำความสะอาด

ถ้ามองมาในการพัฒนา software มีอะไรบ้าง ? มันคือการทำความสะอาดโต๊ะทำงาน บางคนอาจจะสร้างบ้านหรืออาณาจักรขึ้นมาบนโต๊ะตัวเองก็ได้ !! รวมทั้งเครื่อง computer/notebook ที่ใช้งานด้วย การจัดการ files และ folders ก็สำคัยมาก ๆ นะ เนื่องจากบ่อยครั้งเรามักจะค้นหามันไม่เจอ เรื่องของการจัดการกับ email ก็เช่นกัน หรือการใช้งาน version control เช่น Git ก็ให้ลองใช้คำสั่ง git status ดูบ้าง ว่ามีอะไรที่ยังค้างอยู่บ้าง ว่ามีอะไรที่ยังไม่ commit บ้าง ว่ามีอะไรที่ต้อง push/pull บ้าง หรือก่อนกลับก็ git clean -f บ้างนะ

หรือ code ที่เขียนขึ้นมานั้นมัน clean หรือยัง ถ้ายังไม่รู้ห็ให้ไปอ่านเรื่อง Clean code เพิ่มเติมนะ

หรือ code ที่เขียนขึ้นมานั้น ทำการนำไปรวมกับคนอื่น ๆ ในทีมหรือยัง ดังนั้นเรื่องของ Continuous Integration จึงต้องถูกนำมาใช้งาน หรือ environment ต่าง ๆ ในการพัฒนา ทั้งเครื่องของ developer และ server ยังคงทำงานได้ดี มี software ตรงกัน

ต่อมาคือเรื่อง สร้างมาตรฐาน

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

การนำ framework/library มาใช้งาน
การนำ design pattern มาใช้งาน
การพูดคุยในภาษาที่ทุกคนเข้าในร่วมกัน
เอกสารต่าง ๆ ควรอยู่ในที่ที่ทุกคนรู้ และ เข้าใจตรงกัน เช่น Code branching, Wiki, Task, Bug เป็นต้น

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

สุดท้ายคือ สร้างนิสัย

ทุกสิ่งทุกอย่างมันจะยั่งยืนได้นั้น ไม่ใช่มาจากการบังคับหรือการทำตามกฏ แต่มันต้องออกมาจากนิสัยของคนจริง ๆ นั่นคือต้องออกมาจากจิตสำนึกที่ดี นั่นคือต้องออกมาทัศนคติที่ดี ถ้ามองมาในการพัฒนา software มีอะไรบ้าง ?

ก่อนเขียน code ต้องเขียนชุดการทดสอบก่อนเสมอ (Unit test และ TDD)
การทดสอบอย่างต่อเนื่องและรวดเร็ว เพื่อทำให้ได้ feedback กลับมาอย่างรวดเร็ว
การทำ code review อย่างต่อเนื่อง
การปรับปรุง code อย่างต่อเนื่อง
การเขียน Unit test สามารถดูค่า code coverage เพิ่มเติมได้อีกด้วย
มีการ training และแบ่งปันความรู้ภายในทีมและองค์กร

ยังไม่พอนะ ยังไม่สิ่งอื่น ๆ อีกเช่น Safety, Security และ Satisfaction อีก แต่พอเท่านี้ก่อนดีกว่า

มีคำถามว่าระหว่าง 5ส หรือ 7ส ดี ?

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

ปล. 5ส ไม่น่าจะเป็นการจัดเก็บโต๊ะและเอกสารเข้าตู้เมื่อมีคนมาตรวจนะ หรือต้องมีคนคอยเฝ้าต้นทางว่าผู้ตรวจจะมาหรือยัง แบบนี้มันคือ การทำแบบผักชีโรยหน้า ซึ่งมันไม่ยั่งยืนเลยนะ !!

↧

สิ่งเน้นย้ำสำหรับ Developer ที่ดี

October 25, 2016, 8:14 am

≫ Next: แนะนำการ review code ที่น่าสนใจมาก ๆ

≪ Previous: 5ส สำหรับการพัฒนา software

safety-first-26

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

1. Don’t Repeat Yourself (DRY)

ลองคิดดูสิว่าถ้า developer ต้องอยู่ในสถานการณ์ ที่ต้องเข้าไปเพิ่ม feature ที่เหมือนว่าจะมีอยู่แล้ว คำถามคือ คุณจะทำอย่างไร ระหว่างเขียน code ขึ้นมาใหม่ กับแก้ไข code เดิม ? ทางที่ดีกว่าคือ แก้ไข code เดิมสิ แต่ด้วยเหตุผลร้อยแปด ทั้งอ่าน code ไม่รู้เรื่อง ทั้งเวลาที่จำกัดซึ่งทาง project manager ได้กำหนดไว้แล้ว !! ทั้งต้องทำการ regression test อีก ดังนั้น developer มักจะบอกว่า เขียนใหม่เถอะ !! สิ่งที่ตามมาคืออะไร ? code เก่าและใหม่ทำงานคล้าย ๆ กัน ซึ่งทำให้เกิด code ที่เหมือนกัน หรืออาจจะ duplicate กันเลย (Code duplication is Evil !!) หนักไปกว่านั้น เราอาจจะพบว่า ทั้ง code เก่าและ code ใหม่ถูกใช้งานจากส่วนต่าง ๆ อีกด้วย ดังนั้นเมื่อมี requirement เปลี่ยน ปัญหาก็จะตามมาอีก !!

ดังนั้นสิ่งที่ developer ควรรู้และเข้าใจก็คือ การสร้าง duplication code อาจจะเป็นเส้นทางที่ง่ายและใช้เวลาน้อย แต่สิ่งที่ตามมาก็คือ ค่าใช้จ่ายสูงที่ตามมาในอนาคตอันใกล้

ดังนั้นสิ่งแรกที่ควรจำไว้คือ Don’t Repeat Yourself

2. งานอะไรที่มันต้องทำซ้ำ ๆ ก็ให้ทันทำงานแบบอัตโนมัติซะเถอะ

สิ่งใดที่ developer ต้องทำซ้ำ ๆ ซ้ำแล้วซ้ำอีก เช่น การทดสอบ และ การ deploy แน่นอนว่า เราต้องทำการทดสอบในทุก ๆ test case เสมอ เมื่อทำการเพิ่มและแก้ไข code หรือ feature ดังนั้นลดสิ่งเหล่านี้ด้วยระบบแบบอัตโนมัติซะ

ฟังดูเหมือนดีนะ แต่ทางหัวหน้าหรือทาง manager อาจจะไม่เห็นดีเห็นงามด้วย เพราะว่า ไม่มีทั้งเวลา ค่าใช้จ่ายให้หรอกนะ

แต่สิ่งที่ developer ต้องสื่อสารออกไปก็คือ เมื่อใดก็ตามที่ให้คนมานั่งทำงานเดิม ๆ ซ้ำซาก มักจะก่อให้เกิดข้อผิดพลาดได้เสมอ และมีแนวโน้มจะเกิดปัญหาขึ้นเรื่อย ๆ เพราะว่า ระบบงานยิ่งมากขึ้น feature มากขึ้น ความซับซ้อนมากขึ้น test case ก็มากขึ้นไปด้วย ดังนั้นเวลาที่ใช้ไปก็มากขึ้นตามเช่นกัน

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

ดังนั้น developer ที่ดี ไม่น่าจะทำแบบนี้ ไม่น่าจะเสียเวลาไปกับสิ่งที่ไม่เกิดประโยชน์ ไม่น่าจะเสียเวลาไปกับสิ่งที่ต้องทำซ้ำ ๆ ดังนั้นมาหาวิธีลดกันเถอะนะ ถ้าทำด้วยวิธีแบบเดิม ๆ ก็ได้ผลแบบเดิม ๆ นั่นแหละ

3. Safety First

สิ่งที่ developer ที่ดีต้องมีคือ Safety First หรือ ปลอดภัยไว้ก่อน ลองคิดดูสิว่า ถ้า developer เปรียบได้กับแพทย์รักษาคนไข้แล้ว ถ้าแพทย์ตรวจ วินิจฉัย และ รักษาผิดจะเกิดอะไรขึ้น อาจจะทำให้ผู้ป่วยไม่หาย เกิดผลข้างเคียง หรือ เสียชีวิตได้ เช่นเดียวกับกับ developer ถ้า code ที่เขียนไปนั้น โดยไม่ระมัดระวังก็อาจจะทำให้ code ส่วนอื่น ๆ ทำงานผิดพลาด หรือระบบพังได้เลย ดังนั้น developer ลองกลับมาดูสิว่า เราทำงานอยู่ในสภาวะแวดล้อมที่ปลอดภัยไหม ? เช่น มีชุดการทดสอบที่ดีและครอบคลุมหรือไม่ ? มี server ที่พร้อมหรือไม่ ? มีระบบการ deploy ที่ดีหรือไม่ ? มีระบบรอบข้างที่พร้อมหรือไม่ ? มี regression test ที่ดีหรือไม่ ? เนื่องจากเมื่อเกิดปัญหาขึ้นมาแล้ว เรามักอ้างว่า requirement ไม่ชัดบ้างล่ะ เรามักอ้างว่าการประเมินเวลาผิดพลาดบ้างล่ะ แต่มักไม่อ้างว่าสิ่งแวดล้อมมันไม่ปลอดภัยนะ หรือพูดไปแล้วไม่สนใจ เพราะว่า ปกติมันเป็นแบบนั้นอยู่แล้ว !!

ดังนั้นสิ่งที่ developer ที่ดีควรคำนึงคือ Safety First อย่างน้อยก็ต้องเขียนชุดการทดสอบบ้างล่ะนะ ไม่ใช่ debug กันทั้งวัน ทั้ง ๆ ที่ code เหล่านั้นเราก็เขียนขึ้นมาเอง !!

4. YAGNI

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

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

โดยข้อแนะนำต่าง ๆ เหล่านี้ใช่ว่าจะใช้ได้ในทุกสถานการณ์นะ !!

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

การรับมือต่อการเปลี่ยนแปลงของ requirement ที่ว่ารับมือยากแล้ว การเปลี่ยนแปลงนิสัยของ develooper ที่มีมาอย่างยาวนาน ยิ่งยากกว่า ดังนั้นลองมาปรับเปลี่ยนกันดูครับ

↧

แนะนำการ review code ที่น่าสนใจมาก ๆ

October 26, 2016, 7:29 am

≫ Next: เขียนโปรแกรมด้วยภาษาอะไรดี ?

≪ Previous: สิ่งเน้นย้ำสำหรับ Developer ที่ดี

traffic-jam

จากหนังสือ Programming Beyond Practices (Be more than just a code monkey) ได้แนะนำขั้นตอนการ review code ที่น่าสนใจดังนั้น ลองคิดดูสิว่า ถ้าเราเป็นลูกค้า หรือ ผู้ว่าจ้าง โดยที่รู้ด้วยว่าการเปลี่ยนแปลง code ต่าง ๆ จะเกิดผลกระทบ หรือ มีความเสี่ยงอะไรบ้าง ? เราน่าจะลดขั้นตอนการ review ต่าง ๆ ลงไป แล้วมาพยายามส่งมอบระบบงานให้ได้บ่อย ๆ ดีกว่าไหม ?

เป้าหมายคือลดขั้นตอนการ review code ลง

ทั้งวิธีการเขียน code ทั้งโครงสร้างของ code ทั้งชุดการทดสอบ ทั้งเรื่องของเอกสารต่าง ๆ สุดท้ายคือ ไม่มีสิ่งต่าง ๆ เหล่านี้เลย !! คำถามคือเริ่มอย่างไรดีล่ะ ?

เริ่มต้นด้วย Production Testing

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

ผลที่ได้รับคือ เรากล้าที่จะเปลี่ยนแปลงและแก้ไข feature ต่าง ๆ อีกด้วย รวมทั้งรู้ความเสี่ยงต่าง ๆ อีกด้วย เช่นจากการ deploy ระบบเป็นต้น

สิ่งที่ต้องเน้นคือ Product มากกว่าการ review code

ดังนั้นสิ่งที่ต้องพูดคุยกันก่อนจะมาดู issue ต่าง ๆ ของ code คือ คุณภาพของ product และความสามารถต่าง ๆ เช่น

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

คำถามเหล่านี้ มันจะช่วยให้เรารู้ปัญหาต่าง ๆ ก่อน ที่จะมาทำการ review code จริง ๆ ทั้ง code ดีหรือไม่ ? ทั้งโครงสร้างดีหรือไม่ ? ทั้งต้อง refactor code ไหม ? ทั้งการเขียน automated testing ? มันเป็นการวิเคราะห์ปัญหาแบบ outside-in นั่นคือการมองภาพของ product จากมุมมองของลูกค้าและผู้ใช้งาน

ดังนั้นเริ่มต้นด้วยความต้องการของลูกค้า

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

↧

เขียนโปรแกรมด้วยภาษาอะไรดี ?

October 26, 2016, 8:51 am

≫ Next: ทำความรู้จักกับ Elasticsearch Ingest Node

≪ Previous: แนะนำการ review code ที่น่าสนใจมาก ๆ

ways

จากบทความเรื่อง Which Programming Language Should I Learn First? ทำการสร้าง flow chart diagram เพื่อช่วยในการตัดสินใจว่า จะเริ่มเขียนภาษาโปรแกรมอะไรดี ? จะเลือกภาษาโปรแกรมอะไรในการพัฒนาระบบงานดี ? คิดว่า น่าจะพอช่วยเหลือได้บ้างนะครับ โดยที่ Flowchart จะเริ่มแยกทางเลือกด้วยความต้องการ

Web app
Mobile app
Game
หางาน
ศึกษาภาษาใหม่

มาลองดูกันครับ Flowchart แบบเต็ม ๆ

↧

ทำความรู้จักกับ Elasticsearch Ingest Node

October 27, 2016, 9:24 pm

≫ Next: มาดูความงามของ Kibana 5.0.0 กันหน่อย

≪ Previous: เขียนโปรแกรมด้วยภาษาอะไรดี ?

es5-01

ทาง Elastic เพิ่งปล่อย Elastic Stack 5.0 ออกมา ซึ่งประกอบไปด้วย

Elasticsearch 5.0.0
Kibana 5.0.0
Logstash 5.0.0
Beats 5.0.0
X-Pack 5.0.0
ES-Hadoop 5.0.0

แน่นอนว่ามีการเปลี่ยนแปลงมากมาย ทั้งความสามารถใหม่ ๆ และ breaking changes โดยสิ่งที่ขอแนะนำคือ Elasticsearch Ingest Node มาดูกันว่ามันคืออะไร ทำอะไรบ้าง ?

Elasticsearch Ingest Node คืออะไร ?

ตั้งแต่ Elasticseach 5.0 นั้นเราสามารถกำหนดขั้นตอนการจัดการข้อมูลได้เอง หรือเป็น pre-process data ก่อนที่นำผลลัพธ์ไปจัดเก็บใน Elasticsearch หรือ indexing ต่อไป ซึ่งเป็นการทำงานที่คล้ายกับ Logstash นั่นเอง โดยกระบวนการเหล่านี้เรียกว่า Ingest เปรียบเทียบการทำงานดังรูป es5-01

โดยค่า default ของ Elasticsearch นั้นทุก ๆ node จะเป็น Ingest node อยู่แล้ว ดังนั้นสามารถปิดได้นะ ในไฟล์ elasticsearch.yml ดังนี้ [code] node.ingest=false [/code]

ขั้นตอนการของ pre-process data ของ Ingest จะทำงานผ่าน Pipeline API

สามารถดู Ingest API เพิ่มเติมได้ ประกอบไปด้วย

Put Pipeline API
Get Pipeline API
Delete Pipeline API
Simulate Pipeline API

ปล. ชีวิตน่าจะดีขึ้นนะครับ แต่ก็แอบ configuration ยากนิดหน่อย !!

และทาง Sematext ได้ทำ performance testing ระหว่าง Ingest กับ Logstash

ไว้อย่างน่าสนใจที่ Elasticsearch Ingest Node vs Logstash Performance 23-rules-logstash-up-cpu

↧

มาดูความงามของ Kibana 5.0.0 กันหน่อย

October 29, 2016, 7:13 am

≫ Next: ความสนุกสนานใน Release note ของ App ต่าง ๆ

≪ Previous: ทำความรู้จักกับ Elasticsearch Ingest Node

kibana50dashboard

เมื่อ Kibana 5.0.0 ถูกปล่อยออกมา เรามาดูกันหน่อยว่า มี feature อะไรที่น่าสนใจกันบ้าง ทั้งการออกแบบ User Interface ใหม่ ทั้งการจัดการข้อมูลแบบ time serie ด้วย Timelion ทั้ง DevTool ที่ติดตั้ง sense มาให้ใช้กันเลย มาลองใช้งานกันเลย ปล. ต้องติดตั้ง Elasticsearch 5.0.0 ด้วยนะ

โดยสิ่งที่จำเป็นจะต้องรู้เกี่ยวกับ Kibana ประกอบไปด้วย

การกำหนด index pattern
การแสดงข้อมูลผ่าน Discover
การ Visualize ข้อมูลในรูปแบบของกราฟชนิดต่าง ๆ
การแสดงผลต่าง ๆ ใน Dashboard

1. ก่อนอื่นต้องกำหนด index pattern ที่ต้องการจะนำมาใช้งานก่อน

อยู่ในส่วนของ Management ซึ่งจากรูปจะมี index ที่ขึ้นต้นด้วยคำว่า logstash kibana_01

2. มาดูกันหน่อยว่าข้อมูลเป็นอย่างไรบ้างในส่วนของ Discover

ซึ่งสามารถกำหนด field ที่ต้องการแสดงและค้นหาข้อมูลได้ kibana_022

3. สร้างกราฟเพื่อแสดงข้อมูลกันหน่อย (Vizualize)3 ประกอบไปด้วย

Area chart
Data table
Line chart
Pie chart
Bar chart
Metric
Map
Time serie

ตัวอย่างของ Pie chart kibana_032

4. นำกราฟต่าง ๆ มาแสดงรวมกันใน Dashboard ซะ

5. แถม Dev Tools Console มาให้ด้วย

มันก็คือ Sense นั่นเองนะครับ ช่วยให้เรา query ข้อมูลได้ง่าย ๆ เลย kibana_05

6. มี Timelion มาให้ด้วย ซึ่งไว้แสดงข้อมูลแบบ Time serie

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

โดยรวม ๆ แล้วมีเสน่ห์ขึ้นมาอีกเยอะเลยครับสำหรับ Kibana 5.0.0 รออะไรกันอยู่อีกล่ะ ไป download กันเลยครับ

↧

ความสนุกสนานใน Release note ของ App ต่าง ๆ

October 31, 2016, 1:39 am

≫ Next: มาดูการเปลี่ยนแปลงของ Selenium 3 กัน

≪ Previous: มาดูความงามของ Kibana 5.0.0 กันหน่อย

release_note_00

ว่าง ๆ มาดูความสนุกของการเขียน Release note ของ Mobile app ต่าง ๆ กันหน่อย ยกตัวอย่างเช่น

Updates
Bug fixed
Yo GIFS !!
Fixed issues
New features
Minor improvement
Lorem ipsum dolar sit amet
Performance improvement
Jam packed full of Super Amazing Things
Basically, what Star Wars did for sci-fi, we’ve done to our app. But without Jar Jar Binks
Peter let a couple nasty bugs slip into our last release, these have been fixed, Fired Peter !!

Release note มันมีไว้ทำอะไรนะ ?

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

ลองไปดู Release note ของ app ใน App Store มานิดหน่อย

เป็น app ในกลุ่มธนาคารและโทรศัพท์ในไทยมานิดหน่อย แสดงดังรูป release_note_03

มาดูกันหน่อยสิว่า Release note ที่ดีมีประโยชน์น่าจะประกอบไปด้วยอะไรบ้าง ?

อธิบายพวก feature ใหม่ ๆ สำหรับผู้ใช้งาน
อธิบายการแก้ไข bug ต่าง ๆ ว่าเป็นอย่างไร และแก้ไขอย่างไร
อธิบายเกี่ยวกับ app/product ให้ผู้ใช้งานเข้าใจ
ควรเพิ่มข้อความเพื่อให้ credit แก่ทีมพัฒนาบ้าง
ควรมี style เป็นของตัวเอง ชัดเจน

ดังนั้นลองกลับมาดูสิว่า เราเขียน Release note เพื่ออะไร ? เราเขียน Release note ให้ใคร ? Release note มีประโยชน์อะไร ? ถึงแม้ว่ามันจะไม่ค่อยประโยชน์อะไรมากนัก ไม่รู้ว่ามีผู้ใช้คนไหนบ้างที่อ่าน ที่สำคัญใน App update ก็ไม่แสดงให้เห็นด้วยนะ

Release note ที่สนุก ๆ น่าจะเป็นของ Medium

สุดท้ายแล้วมีใครบ้างล่ะที่อ่าน Release note

หรือ What’s new ? ของ App ที่ใช้งานกันบ้าง ? เพื่อความสนุกลองไปดู Release note ของ app ที่คุณสิ !! ว่าเป็นอย่างไร ? release_note_01

↧

มาดูการเปลี่ยนแปลงของ Selenium 3 กัน

October 21, 2016, 7:15 pm

≫ Next: รู้หรือไม่ว่า Git สามารถนำมาสร้าง NoSQL Database แบบ Key-Value ได้นะ

≪ Previous: ความสนุกสนานใน Release note ของ App ต่าง ๆ

z13

Selenium Core ซึ่งเป็นส่วนการทำงานหลัก
WebDriver API ซึ่งส่งผลกระทบทั้งหมดทั้ง Mozilla Firefox, Safari, IE และ Google Chrome แต่ก็ทำให้การทำงานเร็วขึ้น
SeleniumGrid ซึ่งไม่กระทบกับของเดิมเท่าไรนัก

สิ่งที่เห็นได้ชัดจากการเปลี่ยนแปลงจาก version 2 มา 3 คือ WebDriver

โดยทาง SeleniumHQ ได้สรุปรายชื่อ WebDriver ไว้ดังนี้

ที่สำคัญทางทีม SEleniumHQ ไม่ได้ดูแลหรือพัฒนานะครับ selenium3

และที่น่าสนใจก็คือ Selenium WebDriver กำลัง implement

ให้เป็นไปตามมาตรฐาน WebDriver W3C อีกด้วย (Browser Automation) ซึ่ง roadmap น่าจะเป็นดังรูป selenium_roadmap_2

ผลกระทบต่าง ๆ ทั้งก่อนหน้านี้และที่ตามมา เช่น

สำหรับ Firefox 46 ขึ้นไป เนื่องจากเปลี่ยนมาใช้ Gecko driver
สำหรับ Google Chrome ก็ให้ทำการ download chrome driver ใหม่มานะ

↧

รู้หรือไม่ว่า Git สามารถนำมาสร้าง NoSQL Database แบบ Key-Value ได้นะ

October 23, 2016, 5:07 am

≫ Next: 5ส สำหรับการพัฒนา software

≪ Previous: มาดูการเปลี่ยนแปลงของ Selenium 3 กัน

git-nosql

เริ่มด้วยวิธีการง่าย ๆ

ต้องทำการบันทึกข้อมูลลงไฟล์ก่อน จากนั้นจึงบันทึกข้อมูลเข้า git ซึ่งทำให้เสียเวลา
ขั้นตอนการบันทึกข้อมูลเยอะเกินไป
ถ้าไฟล์ที่ต้องการอยู่ใน path ลึก ๆ น่าจะแย่นะ

ดังนั้นถ้าต้องการแก้ไขปัญหานี้ล่ะ ทำอย่างไรดี ?

เพิ่งรู้เลยว่า Git มันก็ทำแบบนี้ได้ด้วย

↧

5ส สำหรับการพัฒนา software

October 24, 2016, 1:19 am

≫ Next: สิ่งเน้นย้ำสำหรับ Developer ที่ดี

≪ Previous: รู้หรือไม่ว่า Git สามารถนำมาสร้าง NoSQL Database แบบ Key-Value ได้นะ

mess

คิดว่า developer หลาย ๆ คนน่าจะรู้จักกับ 5ส หรือ 5S

5S was developed in Japan and was identified as one of the techniques that enabled Just in Time manufacturing

ซึ่งประกอบไปด้วย

Seiri หรือ Sort/Clearing/Classify หรือ สะสาง
Seiton หรือ Systematic Arrangement/Streamline/Simplify/Configure หรือ สะดวก
Seiso หรือ Shine/Cleanliness/Clean and check หรือ สะอาด
Seiketsu หรือ Standardize/Conformity หรือ สร้างมาตรฐาน
Shitsuke หรือ Sustain the discipline/Custom and practice หรือ สร้างนิสัย

Clearing
Configure
Clean and Check
Conformity and finally
Custom and practice

เริ่มต้นด้วยสะสาง

การสำรวจตรวจดู
การแยกแยะ
การลบหรือขจัดทิ้งไป

ถ้ามองมาในการพัฒนา software มีอะไรบ้าง ?

การลบ code ที่ไม่ถูกใช้งานออกไป
การลบ library ที่ไม่ถูกใช้งานออกไป
การลบ software ที่ไม่ถูกใช้งานออกไป

ต่อมาคือ สะดวก

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

ต่อมาคือ สะอาด

ระบุพื้นที่
หาและกำจัดต้นเหตุของความสกปรก
ทำความสะอาด

หรือ code ที่เขียนขึ้นมานั้นมัน clean หรือยัง ถ้ายังไม่รู้ห็ให้ไปอ่านเรื่อง Clean code เพิ่มเติมนะ

ต่อมาคือเรื่อง สร้างมาตรฐาน

การนำ framework/library มาใช้งาน
การนำ design pattern มาใช้งาน
การพูดคุยในภาษาที่ทุกคนเข้าในร่วมกัน
เอกสารต่าง ๆ ควรอยู่ในที่ที่ทุกคนรู้ และ เข้าใจตรงกัน เช่น Code branching, Wiki, Task, Bug เป็นต้น

สุดท้ายคือ สร้างนิสัย

ก่อนเขียน code ต้องเขียนชุดการทดสอบก่อนเสมอ (Unit test และ TDD)
การทดสอบอย่างต่อเนื่องและรวดเร็ว เพื่อทำให้ได้ feedback กลับมาอย่างรวดเร็ว
การทำ code review อย่างต่อเนื่อง
การปรับปรุง code อย่างต่อเนื่อง
การเขียน Unit test สามารถดูค่า code coverage เพิ่มเติมได้อีกด้วย
มีการ training และแบ่งปันความรู้ภายในทีมและองค์กร

ยังไม่พอนะ ยังไม่สิ่งอื่น ๆ อีกเช่น Safety, Security และ Satisfaction อีก แต่พอเท่านี้ก่อนดีกว่า

มีคำถามว่าระหว่าง 5ส หรือ 7ส ดี ?

ปล. 5ส ไม่น่าจะเป็นการจัดเก็บโต๊ะและเอกสารเข้าตู้เมื่อมีคนมาตรวจนะ หรือต้องมีคนคอยเฝ้าต้นทางว่าผู้ตรวจจะมาหรือยัง แบบนี้มันคือ การทำแบบผักชีโรยหน้า ซึ่งมันไม่ยั่งยืนเลยนะ !!

↧

สิ่งเน้นย้ำสำหรับ Developer ที่ดี

October 25, 2016, 8:14 am

≫ Next: แนะนำการ review code ที่น่าสนใจมาก ๆ

≪ Previous: 5ส สำหรับการพัฒนา software

safety-first-26

1. Don’t Repeat Yourself (DRY)

ดังนั้นสิ่งที่ developer ควรรู้และเข้าใจก็คือ การสร้าง duplication code อาจจะเป็นเส้นทางที่ง่ายและใช้เวลาน้อย แต่สิ่งที่ตามมาก็คือ ค่าใช้จ่ายสูงที่ตามมาในอนาคตอันใกล้

ดังนั้นสิ่งแรกที่ควรจำไว้คือ Don’t Repeat Yourself

2. งานอะไรที่มันต้องทำซ้ำ ๆ ก็ให้ทันทำงานแบบอัตโนมัติซะเถอะ

ฟังดูเหมือนดีนะ แต่ทางหัวหน้าหรือทาง manager อาจจะไม่เห็นดีเห็นงามด้วย เพราะว่า ไม่มีทั้งเวลา ค่าใช้จ่ายให้หรอกนะ

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

3. Safety First

ดังนั้นสิ่งที่ developer ที่ดีควรคำนึงคือ Safety First อย่างน้อยก็ต้องเขียนชุดการทดสอบบ้างล่ะนะ ไม่ใช่ debug กันทั้งวัน ทั้ง ๆ ที่ code เหล่านั้นเราก็เขียนขึ้นมาเอง !!

4. YAGNI

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

โดยข้อแนะนำต่าง ๆ เหล่านี้ใช่ว่าจะใช้ได้ในทุกสถานการณ์นะ !!

การรับมือต่อการเปลี่ยนแปลงของ requirement ที่ว่ารับมือยากแล้ว การเปลี่ยนแปลงนิสัยของ develooper ที่มีมาอย่างยาวนาน ยิ่งยากกว่า ดังนั้นลองมาปรับเปลี่ยนกันดูครับ

↧

แนะนำการ review code ที่น่าสนใจมาก ๆ

October 26, 2016, 7:29 am

≫ Next: เขียนโปรแกรมด้วยภาษาอะไรดี ?

≪ Previous: สิ่งเน้นย้ำสำหรับ Developer ที่ดี

traffic-jam

เป้าหมายคือลดขั้นตอนการ review code ลง

เริ่มต้นด้วย Production Testing

ผลที่ได้รับคือ เรากล้าที่จะเปลี่ยนแปลงและแก้ไข feature ต่าง ๆ อีกด้วย รวมทั้งรู้ความเสี่ยงต่าง ๆ อีกด้วย เช่นจากการ deploy ระบบเป็นต้น

สิ่งที่ต้องเน้นคือ Product มากกว่าการ review code

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

ดังนั้นเริ่มต้นด้วยความต้องการของลูกค้า

↧

เขียนโปรแกรมด้วยภาษาอะไรดี ?

October 26, 2016, 8:51 am

≫ Next: แนะนำการใช้งาน Version Control ที่ดี

≪ Previous: แนะนำการ review code ที่น่าสนใจมาก ๆ

ways

Web app
Mobile app
Game
หางาน
ศึกษาภาษาใหม่

มาลองดูกันครับ Flowchart แบบเต็ม ๆ

↧

แนะนำการใช้งาน Version Control ที่ดี

November 1, 2016, 8:28 pm

≫ Next: แบ่งปันเรื่อง Developer ที่ดี

≪ Previous: เขียนโปรแกรมด้วยภาษาอะไรดี ?

version-control

ในการพัฒนา software นั้นสิ่งที่ขาดไปไม่ได้เลยก็คือ Version Control ใช้สำหรับจัดการการเปลี่ยนแปลงต่าง ๆ ทั้งการสร้าง การแก้ไข การลบ การ merge ตัวอย่างเช่น source code และ configuration แต่การใช้งาน Version Control ก็แตกต่างกันไป บางคนใช้เพื่อ backup code บางคนไม่เคย update ข้อมูลใน Version Control เลย บางคนนำ source code ของตัวเองไปทับคนอื่นเฉยเลย บางคนสร้าง branch เยอะมาก ๆ จนไม่รู้ว่า branch ไหนล่าสุด บางคนบอกว่าเลิกใช้มันแล้ว เพราะว่าเกิด conflict มากมาย บางคนบอกว่าใช้ไปทำไม ขอ thumbdrive มาแล้ว copy ไปสิเร็วกว่า

ดังนั้นจึงขอแนะนำว่าการใช้ Version Control นิดหน่อยดังนี้

ให้ทำการ update ข้อมูลต่าง ๆ ผ่านระบบให้บ่อยที่สุด หรือทุกครั้งที่เปลี่ยนแปลงเรียบร้อยแล้ว เพื่อทำให้ข้อมูลตรงกัน เพื่อลด conflict ของข้อมูลลงไป เพื่อลดความผิดพลาด อย่าดอง code หรือการเปลี่ยนแปลงไว้บนเครื่องตัวเองนาน ๆ นะ !! ถ้ามีการสร้าง branch ต่าง ๆ ขึ้นมา เช่นมี branch hot fix สำหรับแก้ไข bug ดังนั้นมีการแก้ไขใน branch hotfix แล้ว กรุณาทำการ merge code ไปยัง branch ต่าง ๆ ด้วยนะครับ มิเช่นนั้นในรอบการ deploy ต่อ ๆ ไป bug ที่เคยแก้ไขไปแล้วอาจจะกลับมาอีกครั้ง ดังนั้นจำนวน branch เยอะไม่น่ากลัวเท่าแก้ไขแล้วไป update ในทุก branch ที่เกี่ยวข้อง การ checkin/commit/push หรือการบันทึกการเปลี่ยนแปลงใน Version Control นั้น มันคือการพูดคุยของคนในทีมนั่นเอง ดังนั้นสิ่งที่ควรทำคือค่อย ๆ พูดทีละเรื่อง นั่นคือในแต่ละการเปลี่ยนแปลงควรมีขนาดเล็ก ชัดเจน รวมทั้งคำอธิบายต้องตรงกับสิ่งที่เปลี่ยนแปลงด้วย เนื่องจาก developer ชอบทำแบบนี้

การเปลี่ยนแปลงชื่อว่า fixed bug
ส่วนการเปลี่ยนแปลงมีไม่ต่ำกว่า 10 ไฟล์ !!
ซึ่งแบบนี้ไม่ควรทำนะครับ

สิ่งใดที่ไม่จำเป็นก็ไม่ต้องเอาขึ้น Version Control นะ บางคนอาจจะไม่รู้ แต่ว่าต้องเรียนรู้ เช่น

การ comment code ไว้ เอาขึ้นทำไม ?
Configuration ของ IDE แน่นอนว่า ตัวเราเองอาจจะรอด แต่คนอื่น ๆ ในทีมไม่รอด เนื่องจากแต่ละเครื่องมี environment ที่ต่างกัน
สิ่งที่เกิดจากกระบวนการ build
พวก library ต่าง ๆ
ไฟล์ขนาดใหญ่ ๆ

ให้จำไว้ว่า Version Control นั้นทำการเก็บประวัติต่าง ๆ ไว้นะครับ ดังนั้นรู้หมดว่า ใครทำอะไรลงไปบ้าง

โดยรวมแแล้วนั้น Version Control มันดีและมีประโยชน์มาก ๆ ยิ่งถ้าใช้งานอย่างถูกวิธีแล้ว ก็จะทำให้เกิดประโยชน์มากขึ้นไปอีก แต่ถ้าใช้แบบผิดวิธีมันก็เกิดโทษได้เช่นกัน

↧

แบ่งปันเรื่อง Developer ที่ดี

November 3, 2016, 3:20 am

≫ Next: มาดูรูปอธิบายเกี่ยวกับ Programmer ว่าทำอะไรบ้าง ?

≪ Previous: แนะนำการใช้งาน Version Control ที่ดี

bad-developer

มีโอกาสแลกเปลี่ยนแนวคิดเกี่ยวกับการเป็น developer ที่ดี (Good Developer) ซึ่งคำนี้มันไม่มีอยู่ในพจนานุกรมใด ๆ แต่เป็นสิ่งที่ developer ทุกคนต้องค้นหา เพื่อให้ประสบความสำเร็จและสนุกกับการพัฒนา มาดูกันว่ามีสิ่งใดบ้าง ?

1. ความรู้พื้นฐานมันสำคัญสุด ๆ

สิ่งที่ developer ต้องรู้และเข้าใจคือ ความรู้พื้นฐานของสิ่งที่ใช้ จงกลับไปที่พื้นฐานของสิ่งนั้น ๆ จงกลับไปที่พื้นฐานของภาษานั้น ๆ ว่าถูกสร้างมาเพื่ออะไร เนื่องจากของแต่ละอย่างมันมีเป้าหมายของมันอยู่ เมื่อเราเข้าใจความรู้พื้นฐานต่าง ๆ แล้ว มันจะช่วยทำให้สามารถออกแบบ และ สร้างระบบ ด้วยวิธีที่เรียบง่ายและเหมาะสมกับงาน ลดการสร้างแบบ over-engineer ไปได้เยอะมาก ๆ ถ้าพื้นฐานไม่แน่นแล้ว การจะต่อยอดไปยังเรื่องอื่น ๆ ก็ยากหรือไม่ยั่งยืน เหมือนกับการสร้างตึก ถ้าฐานไม่แข็งแรงก็จะถล่มได้ง่าย ๆ ตัวอย่างเช่น คุณใช้งาน ReactJS, Angular, Vue แล้ว คำถามคือ คุณเข้าใจ JavaScript, ES5, ES6 หรือไม่ ? คุณเขียน Ruby On Rails แล้ว คำถามคือ คุณเข้าใจ Ruby หรือไม่ ? คุณเขียน Reactive (Rx) แล้ว คำถามคือ คุณเข้าใจ Observer, Iterator หรือไม่ ? ดังนั้น back to basic และ review basic ของเราดูกันนะครับ หยุดเปรียบเทียบว่าอะไรดีกว่ากัน กลับมาเรียนรู้กันว่า แต่ละอย่างมันเหมาะสมกับอะไร ?

2. เรียนรู้จากการช่วยเหลือผู้อื่น

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

Give more than you take

3. เขียน code ที่ทำความเข้าใจได้ง่าย และ ไม่เยอะ

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

4. ให้เวลากับการวิเคราะห์และทำความเข้าใจกับปัญหามากกว่าการเขียน code

มีเป้าหมายคือ จะลดเวลาในการแก้ไข bug ลงได้อย่างไร ?

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

5. เรียนรู้มากกว่าเปลี่ยนตามเทคโนโลยี

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

6. อย่าจมอยู่กับปัญหาหนึ่ง ๆ นานจนเกินไป

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

7. อ่านเอกสารบ้างนะ !!

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

สุดท้ายคือ การเรียนรู้จากผู้อื่นทั้งจากคนในและนอกทีม

ซึ่งจะทำให้คุณได้รับประสบการณ์ที่ดี และ มีค่าอย่างมาก การพัฒนา software นั้นคือ Social networking นะครับ ทำคนเดียวไม่รอดหรอกนะ

ลองถามตัวเราเองสิว่าเป็นอย่างไรกันบ้าง ? เส้นทางล้วนแตกต่างกัน แต่สิ่งที่ควรจะเป็นคือ ต้องสนุกกับสิ่งที่ทำด้วยเสมอ

↧