เคยไปฟังในงานสัมมนาเรื่องของ Real-time Deepfake AI มา 2-3 ครั้ง
วันนี้ไปเจอบทความบอกว่า
มีนักพัฒนาสร้างเครื่องมือมาให้ทดลองใช้งานชื่อว่า Avatarify
โดยสามารถนำไปใช้ในโปรแกรม Zoom และ Skype ได้เลย

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

Project นี้จะใช้ source code จาก paper ชื่อว่า First Order Motion Model for Image Animation

มีรูปให้เลือกดังนี้

ตัวอย่างการใช้งานใน Zoom

ปล. เครื่องที่ run นั้นต้อง ๆ spec สูง ๆ นะครับ
เพราะว่า กิน resource มาก ๆ
นี่คือ requirement ที่แนะนำ

ถ้าใครอยากใช้รูปอื่น ๆ นอกจากที่มีให้
ก็เพียง copy รูปที่ต้องการไปใส่ใน folder avatars ได้เลย

โดยก่อนหน้าจะมีเครื่องมือนี้ ก็มี Audio DeepFake มาก่อนนี้แล้วอีกด้วย

Reference Websites

• https://thenextweb.com/neural/2020/04/21/watch-fake-elon-musk-zoom-bombs-meeting-using-real-time-deepfake-ai/
• https://www.vice.com/en_us/article/g5xagy/this-open-source-program-deepfakes-you-during-zoom-meetings-in-real-time

ได้รับ project ที่พัฒนาฝั่ง Frontend ด้วย Vue.js มาทำ
พอลองไปเปิดดูในส่วนของ Vue Routing
พบว่าเขียน code ซ้ำ ๆ และ import เยอะมากมาย
ก็เลยทำการ refactor code นิดหน่อย
กับไปเจอ comment webpackChunkName อีก ทำไปทำไมนะ ?

เริ่มแรกเจอ code ใน Routing แบบนี้ทนไม่ไหว เลยขอแก้ไขหน่อย

โดยที่ต้นฉบับจะมี 2 แบบให้เลือกเลย

แบบที่ 1 ทำการ import ก่อนใช้งาน

แบบที่ 2 ทำการ import แบบ inline หรือ lazy load ไปเลย

ทั้งสองแบบมีสิ่งที่เหมือนกันคือ  duplication นั่นเอง

เลยทำการยุบ duplication ลงไปหน่อย
แต่ยังคงความ lazy load อยู่
ก็จะได้ดังนี้

จากนั้นไปเห็นว่ามี comment แปลก ๆ คือ webpackChunkName

มันคืออะไรนะ ตอนสร้าง project เล่นใหม่ ๆ ก็มีนะ แต่ไม่ยอมดู

ตรงนี้ก็งง ๆ เพราะว่าไม่เคยทำ แต่พอไปอ่านดู
เขาบอกว่า feature ใช้ได้กับ webpack 2.6.0 ขึ้นมา
จะทำการใส่ชื่อของแต่ละ route ไปในชื่อไฟล์ที่สร้างออกมา หลังจากการ build

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

ไปอ่าน Slide เรื่อง Scripting Nginx with Lua Introducing OpenRestly
พบว่าน่าสนใจมาก ๆ แต่ไม่รู้เรื่องอะไรเลย
ก็เลยลองหัดทำดูบ้าง โดยสิ่งที่อยากจะเรียนรู้ประกอบไปด้วย

• OpenResty ต้องติดตั้งอะไรและ config อะไรให้ทำงานได้บ้าง
• ลองเขียนภาษา Lua ดูนิดหน่อย
• เชื่อมต่อกับ Redis ที่เป็น Key-value database เพราะว่าใช้งานอยู่แล้ว
• ลองทำการทดสอบสิ่งที่พัฒนาขึ้นมา

เริ่มต้นในการติดตั้ง เอาง่าย ๆ ก็ใช้ Docker Image ของ OpenResty เลย

โดยใน official image สามารถเขียนภาษา Lua ได้เลย
รวมทั้งมี luarocks สำหรับติดตั้ง module/package ต่าง ๆ เพิ่มเติมได้เลย
ดังนั้นชีวิตง่ายละ

จากนั้นทำการเขียน Hello World ด้วยภาษา Lua
โดยเริ่มง่าย ๆ ด้วยการสร้าง location ในไฟล์ nginx.conf
เพื่อให้รับ request ที่มี query string ชื่อว่า name
แต่ถ้าไม่ส่งมาจะมีค่า default คือ Somkiat.cc
เขียนง่าย ๆ ได้ดังนี้

จากนั้นก็เขียน Dockerfile เพื่อนำไฟล์ nginx.conf เข้าไปใช้งาน

ทำการ build Docker image และ run เป็นอันเสร็จพิธี
ใช้งานได้เลย แถม performance ก็ดีเลย
เขียนง่าย เริ่มง่าย ที่เหลือไปเรียนรู้ภาษา Lua ต่อ

ไปหาดูเอกสารว่า Lua + Nginx มันทำงานอย่างไร

ก็ได้รูปนี้มา

ต่อมาทำการเชื่อมต่อไปยัง Redis ซึ่งเป็น Key-value database

โดยที่ OpenResty ก็มี package lua-resty-redis ให้ใช้งาน
ซึ่งทำการติดตั้งผ่าน luarocks ได้เลย
ดังนั้นก็ไปเพิ่มใน Dockerfile จากขั้นตอนแรกดังนี้

จากนั้นก็เขียนในไฟล์ nginx.conf เพื่อเพิ่ม location ใหม่
สำหรับทำงานร่วมกับ Redis ไปดูในเอกสารก็ copy มาเลย
ทำการเชื่อมต่อไปยัง Redis server
ซึ่งผมสร้างเป็นอีก container หนึ่ง
ทำการรับ key และ value มา เพื่อจัดเก็บใน Redis แบบง่าย ๆ

จากการทดสอบแล้วนั้น performance ตกลงไป แต่ไม่มากนัก

ดีมาก ๆ แต่ไว้ต้อง tuning อีกรอบ
แต่คิดว่า มันเขียนง่ายดีนะ
จะให้ดีต้องแยก code ออกมาในไฟล์นามสกุล lua จะจัดการง่ายขึ้น
ถือว่าเป็นก้าวแรกที่น่าสนใจมาก ๆ  มันจบทุกอย่างในตัวเองเลย
น่าลองเอาไปใช้งานจริง ๆ วะแล้ว

จากการแบ่งปันเรื่อง TDD with Java and Spring Boot ของสถาบัน IMC
มีคำถามจากผู้เข้าร่วมฟังที่ผมยังไม่ได้ตอบ
จึงทำการตอบในแต่ละคำถามย้อนหลังให้
ตามนี้เลยครับ

1. X-functinal ทีมนี่เหมือน Scrum team ตามแนวคิด ของ Agile methodology ไหมครับ?

ต้องถามก่อนว่า ใน Scrum team
มีคนที่มี skill สำหรับการส่งมอบระบบงานหรือไม่
ถ้า Cross-functional team ในฝันคือ
เป็นทีมที่สามารถคุยและเลือก requirement มาทำได้
ทำการออกแบบ พัฒนา ทดสอบ และ deploy ได้เองเลย
มันคือแนวคิดของ Product team นะครับ
เพื่อลดเวลาการรอในเรื่องต่าง ๆ

2. การทำ automation test แบบต้องใช้ข้อมูลจาก System อื่นการใช้ Mockup จะถือว่าเพียงพอไหมครับ

ไม่เพียงพอ
เพราะว่าเรากำลังโกหกตัวเอง
เน้นว่าต้องทำ integration test ด้วยเสมอ
เช่นต้องทำทุก ๆ วัน ทุก ๆ 3 วัน หรือนานสุดทุก ๆ สัปดาห์เป็นต้น
รวมทั้งเรื่องของข้อมูลด้วย ควรมีรูปแบบเหมือนจริง 
แต่ไม่ได้ใช้ของจริง
เพราะว่าอาจจะมีปัญหาเรื่อง sensitive data หรือ policy ของการใช้ข้อมูล
ก็ต้องทำการ masking data ก่อนเสมอ

3. Tool ในการทำ REST API test โดยทั่วไปแล้วใช้อะไรครับ

มีการทดสอบแบบภายในและภายนอก
ถ้าจากภายนอกผมจะใช้พวก
Postman หรือพวก Robot Framework + HTTP client library

ถ้าจากภายในคือการเขียน code แล้ว
จะใช้ตาม framework หรือภาษาโปรแกรมที่ใช้เลยครับ
มีให้ใช้งานครบทุกภาษาสมัยใหม่

4. เราควรต้องทำเขียน unit test สำหรับทุก class ทุก method และ ทุก path ของ code รึเปล่าครับ

ไม่จำเป็นครับ

5. มีวิธีการเขียน file test ที่เป็น  best practice ไหมครับ แล้วถ้าอยาก refactor เราควรต้อง refactor อันไหนก่อนดีครับ

ยกตัวอย่างการเขียน unit test ในแต่ละ test case ควรมีแนวทางตามนี้

• ชื่อ test case ต้องสื่สารชัดเจนว่า ต้องการทดสอบอะไร มี input อะไร ได้ expected result อะไร
• ในแต่ละ test case ควรมีโครงสร้างที่ชัดเจน ยกตัวอย่างเช่น AAA (Arrange Act Assert) และ Given-When-Then เป็นต้น

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

ถามว่าควร refactor อันไหนก่อนดี
แนะนำให้ดูว่า test case ไหนที่สำคัญในเชิง business ครับ

6. สำหรับ mobile app นี่จะมีเครื่องมือในการ test  automation อย่างไรครับ

เครื่องมือการทดสอบ mobile app มีเยอะเลย
ทั้งการทดสอบในมุมมองคนภายนอก
นั่นคือได้  input เป็น app มาเลย เช่นได้ไฟล์ APK และ IPA มา เพื่อทดสอบ
ถ้าเป็นแบบนี้มักจะใช้งาน Appium หรือไปใช้ Katalon ซึ่งก็เป็น Appium เช่นกัน

แต่แนะนำให้ไปลองใช้งานการเขียน test เหมือนกับ developer เลย เช่น

• Android app ไปเขียน test ด้วย Android Studio ใช้งานพวก JUnit, Instrumentation test และ Espresso ได้เลย
• iOS app ไปเขียน test ด้วยภาษา Swift ใน Xcode เลย ใช้พวก XCTest และ UI Test ไปเลย

7. Test พวก การ generate file เช่น excel เราต้อง test ยังไงครับ

สนใจที่ input data และ output
จากนั้นต้องเขียน code สำหรับการตรวจสอบข้อมูลในไฟล์ Excel
แต่ละภาษาจะมี Library การจัดการข้อมูลในไฟล์ Excel

8. ทำอย่างไรให้ test repeate ได้บ่อยๆ

เริ่มจากการวางแผนก่อน
เพราะว่า การจะให้ทดสอบซ้ำ ๆ ได้นั้น
ระดับการทดสอบต่าง ๆ ก็ต่างกันไป

ยกตัวอย่างเช่น
Unit test อาจจะต้องเรียนรู้เรื่อง Test double เพื่อจัดการกับ dependency ต่าง ๆ

Integration test อาจจะต้องจัดการกับระบบรอบข้างที่ใช้งาน
ทั้ง External service และ Database ต่าง ๆ
ทำอย่างไรที่จะควบคุมสิ่งต่าง ๆ เหล่านี้
ให้มี state หรือข้อมูลเหมือนเดิมทุกครั้งที่ทดสอบ
ระบบ network ที่เสถียร

การทดสอบแต่ละตัวควรต้องเป็นอิสระ
ไม่ผูกมัดกับการทดสอบอื่น ๆ

ปล. ควร repeat ได่เสมอครับ เพราะว่าเป็นคุณสมบัติของ test ที่ดี

9. เมื่อ refactor code เสร็จ ต้อง test ซ้ำไหมครับ ?

ต้องทดสอบซ้ำครับ
แต่มีกรณีที่การ refactor ไม่ต้องทดสอบซ้ำด้วย
นั่นก็คือ ใช้เครื่องมือในการ refactor เช่นใน IDE ต่าง ๆ 
โดยที่เราไม่ได้ทำอะไร ให้เครื่องมือทำงานเอง

10. สมมุติว่าเรากำลังจะ Introduce agile process เข้าไปในทีม ระหว่างพยายามทำให้ทีมสามารถทำงานแบบ agile ได้คล่องก่อน กับพยายามทำให้ทีมเข้าใจเรื่องการทำ TDD ก่อน ในความคิดของพี่ปุ๋ยคือทำอะไรก่อน เพราะอะไรคับ

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

11. เทสกับ Database เรียกว่า unit test ไหมครับ

เป็น integration test ครับ

12. ช่วงนี้ซ้อมวิ่งยังไงครับ 555

มีช่วงนึงวิ่งอยู่ในห้อง กับออกกำลังกายพวก core body ในห้อง
ช่วงนี้ก็วิ่งรอบ ๆ ที่พักครับ พยายามออกกำลังกายทุกวัน

13. Spring Boot ใช้กับ S/W Project ที่เป็น monolithic ได้ไหมครับ?

ได้ครับ แต่อาจจะไม่เหมาะสมกับเป้าหมายของ Spring Boot

14. Consumer Driven Contract Testing จำเป็นไหม

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

15. เราต้องทำ unit test ให้ coverage เท่าไหร่ถึงจะพอดี

ค่า coverage ไม่สำคัญเท่ากับระดับความเชื่อมั่นในสิ่งที่พัฒนาขึ้นมา
เพราะว่า coverage สูง ๆ ไม่ได้บอกว่า bug จะน้อยหรือไม่มี

ถ้าเขียน unit test และ coverage สูง แล้ว แต่ bug ยังเยอะ แบบนี้ต้องกลับมาดูว่าทำไม

ถ้าเขียน unit test และ coverage ต่ำ แล้ว แต่ bug น้อยมาก ๆ แบบนี้ก็ต้องมาดูว่าทำไม

ถ้าไม่เขียน unit test แล้ว bug น้อย แบบนี้ก็ต้องมาดูว่าทำไม

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

สวัสดีครับ

วันนี้ลองไปดูการเชื่อมต่อจาก Google Cloud Run ไปดึงข้อมูล
ใน Google Sheets ผ่าน Google Sheets API ได้เลย 
พบว่ามันทำง่ายดี เพียงแค่ share เอกสาร
ให้กับ email ของ Google account ที่ใช้งาน Cloud Run
จากนั้นก็เขียน code เพื่อดึงข้อมูลมาใช้งาน
รวมทั้ง deploy บน Cloud Run ได้เลย
สรุปขั้นตอนไว้ดังนี้

ขั้นตอนท่ี 1 สร้าง Google Sheets ขึ้นมา

ยกตัวอย่างเช่น

เอกสารที่สร้างขึ้นมาจะมี ID ให้ ยกตัวอย่างเช่น
"https://docs.google.com/spreadsheets/d/xxxxxxx "

ดังนั้น ID ของเอกสารนี้คือ  xxxxxxx
จะเอาไว้ใช้ใน code ที่จะเขียนต่อไป

จากนั้นทำการ shared เอกสารนี้ไปยัง email ที่ใช้งาน Google Service ของเรา
ให้เพียงแค่ดูได้ก็พอ ไม่ต้องทำการ share แบบ public 

ขั้นตอนที่ 2 ทำการเขียน code ด้วยภาษาที่ชอบที่ชอบ

ต้องการสร้าง RESTFul API ไปดึงข้อมูลในวันที่ต้องการจากขั้นตอนที่ 1
ผ่าน Google Sheets API
พัฒนาด้วย Node.js

ขั้นตอนที่ 3 ทำการ deploy ไปยัง Google Cloud Run

แน่นอนว่าต้องสร้าง Dockerfile ไว้ก่อน

จากนั้นทำการ deploy ผ่าน gcloud CLI ดังนี้

เมื่อทุกอย่างเรียบร้อย ก็เรียกใช้งานผ่าน endpoint ของ Google Cloud Run ได้เลย

เพียงเท่านี้ก็สามารถนำมาข้อมูลจาก Google Spreadsheets มาใช้งานได้แล้ว

และอย่าลืมไปเปิด Google Sheets API ด้วยนะครับ เดี๋ยวจะใช้งานไม่ได้

มีงานต้องแก้ไขนิดหน่อย ซึ่งความต้องการเป็นเรื่องของ Rule-based
สำหรับตรวจสอบข้อมูล เพื่อให้ได้ผลตามที่กำหนดไว้
จากเดิมที่เก้บข้อมูลไว้ใน database และนำมาเปรียบเทียบใน code เยอะเลย
ยกตัวอย่างเช่น if-else if- else
แต่เมื่อไปอ่านเอกสารของ C# ก็พบว่า มันสามารถทำแบบนี้ได้เลย

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

หลังจากที่ปล่อย version RC ออกมาให้ลองใช้งานกันสักพัก
ตอนนี้ได้ปล่อยตัวเต็ม ๆ มาให้ใช้งานกันแล้ว
หลัก ๆ เป็นการเปลี่ยนแปลงพวก Test data parser ให้ทำงานดีขึ้น
รวมทั้งมีเรื่อง Backward Incompatibility ต่าง ๆ ที่ต้องระวัง

มาทำการ upgrade กันได้แล้ว

อ่านเพิ่มเติมได้ใน Release Note :: Robot Framework 3.2

การเปลี่ยนแปลงหลาย ๆ อย่างก็มาพร้อมกับผลกระทบอื่น ๆ

ยกตัวอย่างเช่น ทำให้ Library ต่าง ๆ ใช้งานไม่ได้
ทั้ง FakerLibrary และ AppiumLibrary
ซึ่งมีแผนไว้ว่าจะแก้ไขใน version 3.2.1 ที่จะปล่อยออกมาในวันจันทร์หน้า

นี่คือการแก้ไข

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

เหตุผลที่ 1 คือ ไม่มีเวลา หรือ เวลาไม่เพียงพอ

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

เหตุผลที่ 2 คือ code มันก็ทำงานได้ปกติดีนะ เขียนไปทำไม

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

เหตุผลที่ 3 คือ code ที่เป็นอยู่มัน test ยาก ดังนั้นต้องแก้ไขหรือ refactor code

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

เหตุผลที่ 4 คือ ไม่รู้จะ test อะไร

ต้องทดสอบทั้งหมดเลยไหม เป็นเหตุผลที่ดีนะ
เพราะว่า อยากจะ test แต่ไม่รู้จะ test อะไร
ดังนั้น test ให้หมดเลย เหมาะมากสำหรับการเริ่มต้น
เพราะว่าเป็นฝึกวินัยว่า ในการพัฒนาต้องมีการ test อยู่ในการทำงานเสมอ
หรือ coding === coding + testing

เหตุผลที่ 5 คือ requirement ไม่ดี หรือ ไม่ชัด หนักกว่านั้นคือ เปลี่ยนบ่อยมาก ๆ

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

เหตุผลที่ 6 คือ ทดสอบแบบ manual ง่ายและเร็วกว่า

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

เหตุผลที่ 7 คือ ลูกค้าไม่จ่ายเงินสำหรับการเขียน test

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

เหตุผลที่ 8 คือ code ชุดนี้นิดเดียวเอง ไม่ต้อง test ก็ได้

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

เหตุผลที่ 9 คือ เรามี Tester/QA อยู่แล้ว ให้เขาทำหน้าที่ของเขาไป ไม่ใช่หน้าที่ของเรา

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

เหตุผลที่ 10 คือ เขียนไม่เป็น

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

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

อย่าสร้างภาระให้แก่คนอื่นเลย

จากบทความเรื่อง Don’t Use Boolean Arguments, Use Enums
เป็นบทความที่อธิบายให้เห็นว่า การใช้ boolean นั้น
มีข้อดีและข้อเสียอะไรบ้าง
เป็นสิ่งที่นักพัฒนาควรเข้าใจว่า
ทำไมเราต้องใช้ และ ทำไมเราจึงต้องหลีกเลี่ยง
จึงทำการสรุปไว้นิดหน่อย รวมกับสิ่งที่เจอมาในระบบงานต่าง 

จากตัวอย่างในบทความว่าด้วยเรื่องของ การกำหนด argument ของ function เป็น boolean

ซึ่งถ้ามีแค่ตัวเดียวปัญหาอาจจะน้อย
แต่ถ้ามีเยอะ ๆ หรือบางคนบอกว่า ทำ Data type หรือ class/struct ครอบไว้
มันก็คือปัญหาเดียวกัน
ก่อให้เกิดความซับซ้อน
ก่อให้เกิดความเข้าใจที่ผิดพลาด
หรือมาอ่านทำความเข้าใจจะยากมาก ๆ

ผมขอยกตัวอย่าง code ที่เจอบ่อยมาก ๆ

เช่นตัวแปรชื่อว่า flag คำถามก็คือ flag = true คืออะไร หรือ false คืออะไร ?
ใครเคยเจอบ้าง รู้สึกว่า มันงง ๆ ไหม

ดังนั้นเรามักแก้ไขด้วยการเปลี่ยนชื่อ flag เป็นชื่ออื่นที่เข้าใจมากขึ้น
ในบทความยกตัวอย่างดังนี้

• isUserOnline
• isUserBlocked
• isUserExpired

ทำให้อ่านเข้าใจง่ายขึ้น ไม่งง
แต่ถ้ามีจำนวนที่มากขึ้น
การใช้งานก็ผิดพลาดได้ง่ายขึ้น
ซึ่งปัญหานี้ภาษาโปรแกรม และ Editor/IDE ก็ช่วยแก้ไขไปบ้าง
นั่นคือ การใช้ named parameter หรือ แสดงชื่อ parameter ที่ต้องส่งเข้าไปให้เห็นเลย

ก็ถือว่าช่วยให้ผู้ใช้งานเข้าใจง่ายมากขึ้น
แต่จะดีกว่าหรือไม่ ถ้าไปใช้ Data type รูปแบบอื่น ๆ
เช่นการนำ Enum มาใช้ เพื่อแก้ไขปัญหาเหล่านี้ไปในตัวเลย
ไม่ต้องไปพึ่งพา Editor/IDE ใด ๆ

จากเรื่องนี้ ก็เพิ่งคุยไปเรื่องของ Data type ใน Database เช่นกัน

เนื่องจากทำการเก็บข้อมูลสถานะของแต่ละ record/row/document ว่าเป็นอย่างไร
เช่น เปิด หรือ ปิด
มักจะใช้ data type เป็น number เช่น 0 หรือ  1 
หรืออาจจะใช้ boolean ก็ได้

แต่เมื่อเรา query ข้อมูลมาดู
ก็ต้องมาตีความอีกว่า 0, 1 หรือ  true/false คืออะไร
จะดีกว่าไหมถ้าใช้ Enum ใน database ไปเลย
ยกตัวอย่างเช่น Enum ใน MySQL database เป็นต้น

ลองปรับปรุงกันดูครับ เพื่อให้ code และระบบของเราดูแลง่ายขึ้น
ขอให้สนุกกับการ coding ครับ

Vite คือ No-Bundle Dev Server สำหรับ Single File Component
นั่นคือไม่ต้องการ webpack อีกต่อไป
แน่นอนว่าทำงานเร็วมาก ๆ และอาจจะนำมาใส่ใน Vue 3 เลยทีเดียว
แต่ project นี้ยังเป็นเพียง experiment หรือทดลองเท่านั้น
ไม่เหมาะกับการนำไปใช้บน production นะ
มาลองเล่นกันหน่อย

นี่คือ Tweet จากผู้สร้าง

ทำการสร้าง project และ run ดังนี้

แสดงผลการทำงานดังนี้

ลองทำการ Build เจอ error ดังนี้

ให้ทำการแก้ไขเล็กน้อย ด้วยการสร้าง folder ที่ไม่มีใน error message นั่นแหละ
เพียงเท่านี้ก็ใช้งานได้แล้ว

จากที่ทดลองใช้งาน

พบว่าง่ายต่อการเริ่มต้น รวมทั้ง hot reload เร็วจริงจังมาก
น่าจะทำให้ development flow ดีขึ้นอย่างมาก
และจาก commit history พบว่า กำลังพัฒนากันจริงจังมาก ๆ

เพิ่งเห็นว่าใน Google Cloud นั้นมีบริการที่ชื่อว่า Cloud Trace
สำหรับการจัดการเรื่องของ distributed tracing ให้ใช้งานแบบง่าย ๆ
ดูการทำงานในส่วนต่าง ๆ ว่าเป็นอย่างไร
รวมไปถึงการหาคอขวดของระบบงานอีกด้วย
ที่สำคัญสามารถสร้างกฏในการตรวจสอบปัญหาแบบอัตโนมัติให้อีกด้วย

ส่วน project ที่อยู่บน App Engine จะทำการจัดเก็บให้แบบอัตโนมัติ
รวมทั้งสามารถทำงานร่วมกับ Zipkin ได้เลย

ลืมบอกไปว่า ทำงานผ่าน StackDriver นั่นเองที่เก็บทั้ง logging, metric และ tracing
นี่มันคือ Observability system เลย

การใช้งานนั้นสามารถดูได้ที่ Document :: Cloud Trace

มาลองสร้างระบบงานตัวอย่างเพื่อใช้งานกันดีกว่า

เพื่อส่งข้อมูล tracing มายัง Cloud Trace
โดยตัวอย่างจะพัฒนาด้วยภาษา Go  + OpenTelemetry

เริ่มด้วยการ initial tracing ซึ่งผ่าน StackDriver library
Code ตัวอย่างจะเก็บข้อมูลทุก ๆ request (ไม่เหมาะกับ production)

จากนั้นทำการเขียน code ในส่วนของ Endpoint แต่ละตัวไป

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

ดูในรูปแบบของ Waterfall 

ลองใช้งานกันดูครับ ง่ายดี
ส่วนราคาดูที่ Pricing stack driver

อ่านบทความเรื่องการจัดการงานที่ทำ โดยหนึ่งในแนวคิดที่แนะนำคือ 

• YAGNI (You aren’t gonna need it)
• KISS (Keep it short and simple)

อธิบายแบบสั้น ๆ
ในบทความอธิบายสองแนวคิดนี้ด้วยรูปที่เข้าใจง่ายดังนี้

• YAGNI เลือกทำในสิ่งที่สำคัญ เพราะว่าเวลามันมีค่า หรือว่ามีแต่สิ่งที่สำคัญทั้งหมดเลย !! ดังนั้นตัดสิ่งที่ไม่สำคัญหรือน้อยออกไปก่อน
• KISS ทำสิ่งที่สำคัญจาก YAGNI ให้มันเรียบง่าย เข้าใจง่าย (แต่ไม่ง่ายนะ)

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

Reference Websites
https://medium.com/@vkhorikov/3-things-that-will-make-or-break-your-project-7d6f29cf7841

จาก Tweet ของคุณ Brad Fitzpatrick
บอกว่าไฟล์ binary ที่ได้จากการ build ของ Go 1.15
ที่จะออกมาใน release ต่อไป ขนาดของไฟล์ลดลงไปเกือบ 50%
เพื่อให้หายข้องใจก็ลองดูหน่อย ว่าเป็นจริงไหม ?

เริ่มด้วยการติดตั้ง Go จาก GoogleSource มีขั้นตอนดังนี้

จากที่ทดลองพบว่าถ้าเขียน Hello World ปกตินั้น ขนาดของไฟล์ไม่ได้เปลี่ยนแปลง

จะพบว่าลดลงนิดหน่อย ยังไม่ชัดมากนัก

เลยไปดูจากตัวอย่าง มีการใช้ package ต่าง ๆ ดังนี้

• net/http
• encoding/json
• archive/zip
• go/format
• text/template

มาดูตัวอย่างการใช้ net/http package นิดหน่อย
ซึ่งมีขนาดไฟล์ binary ลดลงไปเกือบ 50% กันเลยทีเดียว

เป็นการเปลี่ยนแปลงที่ส่งผลมาก ๆ ยิ่งการ deploy ก็จะรวดเร็วมากขึ้นอีกด้วย

โดยจาก Tweet ข้างต้นมาจากการเปลี่ยนแปลงตามการเปลี่ยนแปลง ๆ เหล่านี้

• https://go-review.googlesource.com/c/go/+/230544
• https://go-review.googlesource.com/c/go/+/231397
• https://go-review.googlesource.com/c/go/+/228111

ตั้งหน้าตั้งตารอคอยเลยครับ

ปกติเขียน test ในภาษาโปรแกรมบน JVM ก็มี library/framework ให้เลือกเยอะ
ทั้ง JUnit, Spock, Spek, Kotlin test
แต่มีอีกตัวที่น่าสนใจคือ Kotest 
(ก่อนหน้านี้จะใช้ชื่อว่า KotlinTest แต่ไปซ้ำกับ test ที่มากับภาษา Kotlin จึงเปลี่ยนชื่อ)
โดยมีความสามารถที่น่าสนใจมาก ๆ  รวมทั้งเขียนง่ายด้วย
ดังนั้นมาลองทำความรู้จักกันหน่อย

Kotest เป็น test framework ที่จบในตัว

มีรูปแบบการเขียนที่หลากหลาย ด้วย DSL ที่เข้าใจง่าย
มี matcher มาให้มากกว่า 300 แบบ
มี property-based testing ให้มาเลย
ด้านหลังก็คือ JUnit 5 นั่นเอง รวมทั้งมีเพื่อน ๆ มาอีกเพียบ !!!

เริ่มการใช้งานด้วยเพิ่ม library เข้ามายัง project

โดยตัวอย่างจะเป็น Gradle project

รูปแบบของการเขียน test เยอะมาก ๆ (Test Style)

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

• String spec
• Fun spec
• Should spec
• Word spec
• Feature spec (Feature และ Scenario เหมือนกับ cucumber)
• Behavior spec (BDD Style)
• Free spec
• Describe spec (มาจาก Spec หรือพวก Jasmine)
• Expect spec
• Annotation spec

เลือกได้ตามความชอบเลยครับ !!
ยกตัวอย่างเช่น StringSpec อ่านง่ายดีนะ

ต่อมามี Matcher หรือรูปแบบการตรวจสอบผลการทำงาน
มีให้ใช้งานมากกว่า 300 แบบเป้าหมายเพื่อให้ง่ายต่อการใช้งาน รวมทั้งอ่านง่ายและยืดหยุ่นสูง

ทดสอบแบบ Data-Driven Testing แบบง่าย ๆ

ยกตัวอย่างเช่น

สนับสนุน Property-based testing

นั่นคือ จะทำการ generate test data ให้เองเลยยกตัวอย่างเช่น

นี่คือ ความสามารถพื้นฐานของ Kotest
น่าจะเป็นอีกหนึ่งทางเลือกของการเขียน test ด้วยภาษา Kotlin
ขอให้สนุกกับการ coding ครับ

บ่อยครั้งที่นักพัฒนาต้องจัดการข้อมูลในรูปแบบ JSON
เท่าที่เห้นบางคนเขียน code เพื่อ mapping ข้อมูลในแต่ละ field/property เอง
บางคนก็ใช้ผ่าน website เช่น JSON to xxx
บางคนก็ใช้งานผ่าน plugin ของ browser หรือ Editor/IDE

สำหรับคนที่ใช้ VS Code ก็มี extension ชื่อว่า Paste JSON as Code ให้
ชีวิตง่ายขึ้นมาก ๆ เพียงนำข้อมูล JSON มา
จากนั้นก็เลือกได้เลยว่า จะให้ generate เป็นภาษาโปรแกรมอะไร
ไม่ว่าจะเป็น

• TypeScript
• Python
• Go
• Ruby
• C#
• Java
• Kotlin
• Swift
• Elm

ว่าง ๆ เลยมาลองเล่นตัว Spring WebFlux และ R2DBC (Reactive Relational Database Connectivity)
ซึ่งเป็นคู่ขวัญที่ทำงานแบบ non-blocking
นั่นหมายความว่า สามารถรองรับจำนวน concurrent user ได้เยอะขึ้น
รวมทั้งยังมีการใช้งาน CPU และ Memory ที่มีประสิทธิภาพกว่าด้วย
เมื่อเทียบกับ Spring boot + REST + JDBC/JPA ปกติ
ดังนั้นลองมาเล่นเพื่อทำความรู้จักกันหน่อย

โดยที่ Spring WebFlux น่าจะอธิบายด้วยภาพนี้

ความแตกต่างระหว่าง Reactive vs Servlet

ซึ่งทำงานแบบ Non-blocking
ดังนั้นถ้ามีการเชื่อมต่อไปยัง Database ก็น่าจะเป็น Non-blocking เช่นกัน
นั่นก็คือต้องทำงานผ่าน R2DBC นั่นเอง
โดยที่มี database ไม่กี่ตัวที่สนับสนุน
หนึ่งในนั้นคือ PostgreSQL จึงเป็นที่มาของการใช้ใน blog นี้นั่นเอง

เป้าหมายของ blog นี้คือ

• เรียนรู้เริ่มต้นกับ Spring WebFlux
• ลองใช้งาน Spring Data R2DBC

เริ่มด้วยการสร้าง project จากที่เดิม คือ  Spring Initializr

จากนั้นก็สร้าง Controller และ Repository ตามขั้นตอน

แต่เราจะใช้ Spring WebFlux + Spring Data R2DBC แทน
Code ตัวอย่างไปดูเพิ่มได้ที่ GitHub:: Up1

ตัวอย่างของ Controller ที่ใช้งาน Spring WebFlux

สิ่งที่เราเขียนใน Controller นั้นจะเรียกว่า Publisher

โดยจะมี implementation 2 ตัวคือ Mono กับ Flux จาก code ข้างต้น สำหรับผมจะงงว่า Mono มันต่างจาก Flux อย่างไร ? เพื่อให้เข้าใจง่าย ๆ คือ

• Mono สำหรับการ return ข้อมูล 0  หรือ 1 อย่าง
• Flux  สำหรับการ return ข้อมูล 0  หรือ มากกว่า 1 อย่าง เช่นพวก List อะไรพวกนี้

1. Mono

2. Flux

จากนั้นลองทำการ run
พบว่า start ได้แม้ยังไม่ได้ทำการ start database server !!
เพียงเท่านี้ก็ใช้งานได้แบบง่าย ๆ แล้ว

สุดท้ายมาดูผลการทำงานหน่อย

• R2DBC นั้นมี database ที่รองรับไม่เยอะ ตัวอย่างที่ใช้งานคือ PostgreSQL
• ใน Spring Data Reactive ทำงานกับ Spring WebFlux ได้เลย คือ MongoDB, Redis, Cassandra และ Couchbase เป็นต้น
• ที่สำคัญ JDK มี Loom project ที่น่าจะมาใน JDK 15 นั้นมี Java Fibers อาจจะทำให้อนาคตของ R2DBC เปลี่ยนไปก็ได้
• R2DBC ยังไม่สามารถทำงานร่วมกับ JPA ได้ จึงมี Spring Data R2DBC ให้ใช้งาน
• การทำงานของ Spring WebFlux + R2DBC จะทำงานได้ดี ใช้ resource มีประสิทธิภาพเมื่อจำนวน concurrent สูง จากการทดสอบจะแตกต่างเมื่อมี concurrent 200 ขึ้นไป ทั้ง response time, CPU/memory usage

เจอปัญหาในการเตรียมข้อมูลต่าง ๆ ในการพัฒนาระบบงาน
เช่น ข้อมูลที่ต้องใช้ในการทดสอบ
ทั้งชื่อ นามสกุล email เบอร์โทร
คำถามคือ ถ้าคิดไม่ออกจะทำอย่างไรดี ?
ใช้ กหฟด่าสว ดีไหม ?
ใช้ test test 1234 admin admin ดีไหม ?

ผมคิดว่าไม่ค่อยดี ดังนั้นเราน่าจะไปใช้แบบอื่น ๆ
ยกตัวอย่างเช่นการใช้ library ชื่อว่า Faker ในภาษาต่าง ๆ

การใช้งานอาจจะยากหน่อย
ก็ลองไปดูว่าใน VS Code มี extension ช่วยไหม
ไปเจอ extension ชื่อว่า Random Everything

โดย extension ตัวนี้ ช่วยให้เราสามารถ random ข้อมูลต่าง ๆ ได้เลย

ยกตัวอย่างเช่น

• ตัวเลข
• ตัวอักษร
• ชื่อ
• ชื่อเต็ม
• email
• เบอร์โทร
• วันที่
• IP v4, v6
• ประเทศ
• GUID

น่าจะมีประโยชน์กันนะครับ

มีคำถามว่า จะ import/export พวก Config Vars จากระบบที่ deploy บน Heroku อย่างไร ?

คำตอบง่าย ๆ เลยคือ ทำผ่าน CLI ของ heroku เลย

การใช้งานก็ไม่ยาก มาลองใช้งานกัน

การ Export Config Vars

ยกตัวอย่างของระบบที่ทำการ deploy บน Heroku มี Config Vars ดังนี้

จะทำการ export ก็ง่าย ๆ ด้วยคำสั่ง

จาก blog เรื่องสวัสดี Vite แปลว่า เร็ว อ่านว่า วิท (vit)
ในตอนนี้ได้ออก version 0.12.0 มาแล้ว
ซึ่งได้นำ esbuild เข้ามาใช้สำหรับการแปลง
TypeScript รวมไปถึง JSX และ TSX มาเป็น JavaScript code
แน่นอนว่า esbuild มันทำงานเร็วมาก ๆ

จากเอกสารของ Vite เขียนไว้ว่า
การนำ esbuild มาใช้งานทำการแปลง TypeScript มาเป็น JavaScript
เร็วขึ้น 20 ถึง 30 เท่า
โดยที่ esbuild เขียนได้ภาษา Go อีกด้วย

Vite uses esbuild to transpile TypeScript into JavaScript which is about 20~30x faster than vanilla tsc, and HMR updates can reflect in the browser in under 50ms.

เข้าไปดู code การใช้งาน esbuild ได้ที่ไฟล์ esbuildService.ts
project Vite ยิ่งติดตาม ยิ่งน่าสนใจมาก ๆ

จาก Hello World app นั้น
การ build จะเร็วขึ้นจาก 2.17 วินาทีเหลือเพียง 1.52 วินาที

vite v0.12.0
⠸ Building for production…
[write] dist/assets/index.js 35.44kb
[write] dist/assets/style.css 0.11kb
[write] dist/index.html 0.25kb
Build completed in 1.52s.

ลองไปดู performance test ของ esbuild เมื่อเทียบกับเครื่องมืออื่น ๆ

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

เมื่อเราเจอ Bug แล้ว จะทำอย่างไรบ้าง ?

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

ถ้าเจอในขั้นตอนของ Tester/QA แล้ว
ต้องมีการเก็บลง bug tracker system ใช่ไหม
จากนั้นทำการ assign ไปให้กับทีมพัฒนาหรือ ไปให้หัวหน้าก่อนของทีมพัฒนาก่อน
แล้วจากนั้นหัวหน้าก็ assign ให้คนที่ดูแลอีก !!

ถ้าเจอในขั้นตอนของการ deploy บน production
ก็แก้ไขบน production เลยใช่ไหม ?
หรือกลับมาเริ่มต้นใหม่ คือ Dev -> Test -> UAT -> Prod
ดูชีวิตมันวุ่นวายดีนะ ใครทำอยู่บ้าง ?

วิธีการที่ทำอยู่บ่อย ๆ  ในช่วงของการพัฒนา Dev -> Test -UAT คือ

เมื่อเจอก็แก้ไขทันที คำว่าทันทีอาจจะไม่ถูกนัก แต่แก้ไขให้เร็วที่สุด
มีขั้นตอนดังนี้

• Reproduce bug นั้นให้ได้ ว่าใช้ input อะไร process อะไร ได้ผลที่ผิดอย่างไร และผลที่ถูกคืออะไร
• อย่าลืมเรื่องของ system configuration ของการ reproduce bug ว่าเป็นอย่างไร เพื่อให้ระบบมันเหมือนกันมากที่สุด
• บันทึกการ reproduce bug ด้วยชุดการทดสอบใน level ต่าง ๆ ตาม bug นั้น ๆ
• ลงไปในรายละเอียดของปัญหา ว่ามี root cause มาจากอะไรบ้าง ทั้งการ debug, history จาก version control, test case
• บางปัญหาจำเป็นต้องมีแนวคิดตาม Architecture ของระบบด้วยว่าเป้นอย่างไร เพื่อไม่ให้ออกนอกลู่นอกทาง
• จากนั้นสรุปปัญหา และวิธีการแก้ไข
• ลงมือแก้ไข ทดสอบ สรุปผลการแก้ไข จากนั้นก็ deploy
• อย่าลืมทำในขอบเขตของเวลาที่จำกัดด้วย เพื่อไม่ให้เราจมกับปัญหานานไป
• ถ้าแก้ไขได้แล้ว สิ่งหนึ่งที่ต้องจำไว้คือ เราจะไม่ผิดซ้ำที่เดิม
• สุดท้ายถ้าแก้ไขไม่ได้จริง ๆ ก็ต้องหาคนอื่น ๆ เพื่อช่วยเหลือ

แต่จะดีกว่าไหม ถ้าเราไม่สร้าง Bug ขึ้นมา
หรือรู้ปัญหาให้รวดเร็วที่สุดเท่าที่จะทำได้
น่าจะมีประโยชน์กว่าการมาตามหาหรือไม่ ?

ปล. อีกเรื่องที่เจอบ่อยมากคือ เรื่องของ การใช้งาน Bug/Issue Tracker
เป็นสิ่งที่สำคัญมาก ๆ
เราต้องรู้และเข้าใจว่า ควรใช้หรือไม่ใช้ตอนไหน
ถ้าใช้แล้วมันมีประโยชน์ หรือมีไว้เก็บเท่านั้น
แต่ไม่ได้เอามาใช้ประโยชน์ในการปรับปรุงให้ดีขึ้น Bug/Issue Tracker
มันควรเป็น Knowledge ของระบบ ทีมและองค์กรมากกว่าหรือไม่