Quantcast
Channel: cc :: somkiat
Viewing all 1997 articles
Browse latest View live
↧

เมื่อ Elasticsearch 6.0.0 ออกมา มีอะไรเปลี่ยนแปลงบ้าง ?

December 2, 2017, 12:28 am
$
0
0

ทาง Elastic ได้ปล่อย Elasticsearch 6.0.0 ออกมา ต้องบอกว่า Elastic Stack สินะ เพราะว่า product ทุกตัวจะปล่อยออกมาพร้อมกันทั้งหมด เช่น Elasticsearch, Kibana และ Logstash (ELK) ดังนั้นมาดูกันหน่อยว่ามีอะไรเปลี่ยนแปลงไปบ้าง

เริ่มต้นด้วยหัวใจของระบบคือ Apache Lucene 7.0.1

มันคือ Full-text seach engine นั่นเอง ตั้งแต่ 6.x ขึ้นมาทำการปรับปรุงเรื่อง performance ทั้งการจัดเก็บ การบีบอัดและการดึงข้อมูล ทำให้ทำงานเร็วขึ้น ใช้ storage น้อยลง

ส่วนเรื่องที่น่าสนใจคือ Breaking Change ใน 6.0.0

คิดว่าจะจะกระทบเยอะพอควร นั่นก็คือ ในแต่ละ index มีได้เพียง type เดียวเท่านั้น !! หรือพูดง่าย ๆ คือใน 1 database สามารถมี table ได้เพียง 1 table เท่านั้น เหตุผลหลักคือ ข้อมูลใน index เดียวกันนั่นมีการจัดเก็บที่กระจัดกระจายเกินไป ส่งผลต่อประสิทธิภาพการทำงานของ Apache Lucene นั่นก็คือ การบีบอัดข้อมูล อีกอย่างเมื่อแยกข้อมูลตามแต่ละ index แล้ว ทำให้จัดการและ configuration ค่าต่าง ๆ ได้ง่ายขึ้น ตัวอย่าง error message เมื่อสร้าง type มากกว่า 1 type ใน index

การ migrate ข้อมูลมายัง Elasticsearch 6.0.0

ถ้าใช้งาน Elasticsearch 2.x หรือก่อนหน้า สามารถใช้ reindex API ได้ แต่ผมแนะนำให้ export และ import data ดีกว่านะ

เรื่องสำคัญคือ Operation ต่าง ๆ

โดยใน version หลัง ๆ จะเน้นเรื่องของ Zero-downtime สำหรับการ upgrade node ต่าง ๆ ใน cluster ใช้การ rolling upgrade รวมทั้งการ restart และ recovery จะรวดเร็วขึ้นด้วย Sequence IDs ทำให้สามารถ replay การทำงานที่ขาดหลายไปในแต่ละ shard ได้

มีอีกหนึ่งความสามารถที่น่าสนใจมั้ง

คือการค้นหาข้อมูลข้าม cluster ได้ ยกตัวอย่างเช่น cluster A ใช้ elasticsearch 5.x cluster B ใช้ elasticsearch 6.x สามารถใช้ความสามารถชื่อ Cross Cluster Search ได้ ทำให้ cluster B ไม่จำเป็นต้อง migrate มาเป็น elastic search 6.x

ปรับปรุงประสิทธิภาพของการ query ข้อมูล

ในการ query ข้อมูลใน Elasticsearch ใช้ resource เยอะพอควร ยิ่งมีการเรียงลำดับข้อมูลยิ่งกินเพิ่มอีกมากมาย ดังนั้นใน 6.0.0 จึงเปลี่ยนด้วยการสร้าง index sorting ขึ้นมา นั่นคือในแต่ละ segment ของ Apache Lucene จะมีข้อมูลที่ถูกเรียงลำดับตามที่เราต้องการไว้ตั้งแต่การทำ indexing ทำให้ได้ผลลัพธ์จากการ query เร็วขึ้น การทำงานภายในน้อยลง เนื่องจากใน version ก่อนหน้าต้องทำการดึง document มาจากทุก ๆ segment เพราะว่าแต่ละ document จะถูกสร้างและเรียงลำดับตาม id ของ document และกระจายแต่ละ document ไปในแต่ละ segment จากนั้นจึงนำมาเปรียบเทียบ ก่อนได้ผลที่ต้องการ ซึ่งใช้เวลาและ resource สูงมาก ๆ ดังนั้นสิ่งที่ต้องทำในการสร้างและ configuration index คือ กำหนดไปเลยว่า index จะทำการเรียงลำดับด้วย field/property อะไรบ้าง นั่นคือ ต้องคิดหรือตั้งคำถามก่อนเลยว่า แต่ละ index จะทำอะไรบ้าง ไม่ใช่เพียงเก็บ ๆ ไปเถอะนะ ตัวอย่างของ scores index ต้องการดึงข้อมูลมาแสดงใน leaderboard นั่นคือ แสดงข้อมูลคนที่ได้คะแนนสูง ๆ มาแสดง ทำได้ดังนี้ [gist id="6c6cff73a024ed156856aa03a8b15dc8" file="1.txt"] การเก็บข้อมูลของ Elasticsearch จะเป็นดังรูป สุดท้ายอย่าลืมดู log การทำงานด้วยว่ามีอะไรที่ Deprecated บ้างนะครับ สามารถดูการเปลี่ยนแปลงต่าง ๆ ได้ที่ Release notes
จะรออะไรกันละ ไป Download กัน
↧
Search

สรุปบทสัมภาษณ์ของ Uncle Bob จาก TypeMock

December 2, 2017, 6:41 am
$
0
0

ช่วงเย็น ๆ เห็นบทสัมภาษณ์ของ Uncle Bob จากเว็บของ TypeMock อ่านครบ 3 จบ จึงสรุปเรื่องที่น่าสนใจไว้นิดหน่อย อ่านไปขำไป อ่านไปยิ้มไป ลองมาดูกันว่ามีคำถามคำตอบอะไรบ้าง

ภาษาโปรแกรมที่ยังใช้อยู่ มีอะไรบ้าง ?

  • Java
  • Clojure
  • Go
  • Python
  • Ruby
  • C, C++
ส่วนเหตุผลลองไปอ่านกันดู แต่ที่น่าสนใจคือ การเขียนหลากหลายภาษานั่นเอง วันนี้ developer เขียนกี่ภาษา และ ทำไมถึงเขียน ? ลองตอบกันดูนะ

Passion ใน programming มีอะไรบ้าง ?

  • Keeping the code simple
  • Keeping the code clean
  • Keeping the code well structured
  • Keeping the code well tested
ไม่น่าจะต้องแปลอะไร แล้ว developer แต่ละคนมีอะไรบ้าง ?

อะไรที่ไม่ควรมีใน programming เลย ?

ตอบสั้น ๆ ว่า SQL ถ้าจะให้หนักกว่าก็ต้อง Store procedure นะ

สิ่งสำคัญที่ developer ต้องมีคืออะไร ?

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

จะโน้มน้าวให้ Manager เข้าใจหรือยอมรับกับ TDD ?

ตอบแบบตรง ๆ คือ ไม่ต้องทำ เพราะว่ามันไม่ใช่หน้าที่อะไรของ Manager เลย ต้องมาเข้าใจ หรือ รู้ว่าคุณทำอะไร แต่มีคุณเท่านั้นที่รู้และเข้าใจว่า ถ้าต้องการให้งานหรือ code ออกมาดี จะต้องทำอะไรบ้าง
คำถามจริง ๆ ที่ต้องถามคือ จะโน้วน้าวคนในทีมหรือเพื่อร่วมงานของคุณมาเขียน unit test หรือปฏิบัติตามแนวคิด TDD อย่างไรมากกว่า ?
ถ้าคุณเชื่อและลงมือทำแล้ว แต่ไม่มีใครเชื่อหรือทำตามคุณเลย หลาย ๆ คนก็จะเลิกทำ !! แต่สิ่งที่คุณต้องทำคือ อย่าละทิ้งแต่ให้ทำต่อไปเรื่อย ๆ ถ้าคุณอยู่ในทีมที่ไม่เขียนและไม่เห็นคุณค่าของมัน สิ่งที่ควรทำคือ เปลี่ยนทีมดีกว่า แต่ถ้าคนส่วนใหญ่ในทีมเห็นคุณค่าและปฏิบัติแล้ว คนบางส่วนไม่สนใจ สิ่งที่ควรทำคือ เอาคนที่ไม่สนใจออกไปจากทีม

สำหรับการฝึกฝน TDD ชอบโจทย์หรือ Kata อะไรบ้าง ?

  • Video Store
  • Bowling game
  • Prime factor
  • Word wrap
  • Stack

สิ่งที่ขาดไม่ได้สำหรับการทำงานในแต่ละวัน ?

Unit testing framework ดี ๆ กับ IDE แจ่ม ๆ เช่น Jetbrains

มีคำแนะนำแจ่ม ๆ อะไรบ้างที่เคยได้รับ ?

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

สุดท้ายแล้ว เหตุใดคุณภาพในอุตสาหกรรมการพัฒนา software มันจึงแย่เอามาก ๆ ?

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

Java :: จัดการกับ Null Pointer Exception (NPE) กันอย่างไร ?

December 2, 2017, 11:11 pm
$
0
0

เมื่อวานเห็น code ที่น่าสนใจเกี่ยวกับเรื่อง Null Pointer Exception (NPE) มีทั้งทำให้เกิด หรือ ไม่เกิด แต่ประเด็นเหล่านั้นไม่น่าสนใจเท่ากับว่า วันนี้ Java Developer ทำการจัดการกับ NPE กันอย่างไร ?

โดยปกติแล้ว NPE จะถูกโยนออกมาเมื่อ

ทำการเรียกใช้งานหรือเข้าถึง object ที่อ้างอิงไปยัง null ที่สำคัญ NPE มันคือ RuntineException ด้วย (Unchecked Exception) นั่นหมายความว่าจะไม่เกิดตอน compile time ดังนั้น compiler จะไม่ทำการเตือนนะ จะเกิดตอน runtime หรือตอนที่ทำงานจริง ๆ !! น่ากลัวมาก ๆ
ใครบ้างที่เจอ NPE บน production ? แต่น่าจะเป็นคำถามที่ผิด น่าจะต้องถามใหม่ว่า ใครไม่เคยเจอบ้าง ? คำถามที่น่าสนใจกว่าคือ จัดการกับ NPE กันอย่างไร ?

วิธีการที่ 1 เห็นได้ทั่วไป มันดักทุกสิ่งอย่าง

บางครั้งไม่รู้ด้วยซ้ำว่าจะดักอะไร แต่เพื่อความสบายใจใส่ไว้ก่อน [gist id="092191a351aec1a7e75b10a1b1a13d68" file="1.java"]

วิธีการที่ 2 ตรวจสอบก่อนใช้งานเสมอ

เราจะพบเจอ code เหล่านี้ได้เกลื่อนกลาดในระบบ เรียกว่าลูกอีช่าง if [gist id="092191a351aec1a7e75b10a1b1a13d68" file="2.java"]

วิธีการที่ 3 บางคนบอกว่า if-else มันยาวไป ดังนั้นใช้ Ternary operator ก็แล้วกัน

ไม่รู้ว่ามันจะแถไปไหน !! [gist id="092191a351aec1a7e75b10a1b1a13d68" file="3.java"]

วิธีการที่ 4 รู้ไหมว่า method equals() ถ้าใช้ถูกวิธีมันจะไม่โยน NPE ออกมานะ

ตัวอย่างของการใช้ที่ผิด ก่อให้เกิด NPE ได้ ถ้าไม่ระวัง [gist id="092191a351aec1a7e75b10a1b1a13d68" file="4.java"] ตามจริง compiler มันจะด่านะ ถ้าตอน compile เพิ่ม -Xlint:all เข้าไป หรือถ้าใช้ IDE ดี ๆ มันก็แสดง warning เหลืองด่าอีกด้วย แต่เท่าที่เจอ Developer จะหน้ามึน ทำเป็นมองไม่เห็น แสดงดังรูป ดังนั้นแก้ไขใหม่ซะ จะเป็นดังนี้ [gist id="092191a351aec1a7e75b10a1b1a13d68" file="5.java"] แต่ถ้าใช้ IDE ดี ๆ มันก็จะแนะนำวิธีการแก้ไขให้เพียบนะครับ เอาที่สบายใจกันได้เลย ดังรูป

วิธีการที่ 5 รู้ไหมว่า String.valueOf() มันไม่โยน NPE ออกมานะ !!

แต่ส่งค่า String “null” ออกมาแทนนะ แต่ถ้าใช้งาน toString() ก็บ้านใครบ้านมัน [gist id="092191a351aec1a7e75b10a1b1a13d68" file="6.java"]

วิธีการที่ 6 สำหรับ method ที่ต้อง return ค่ากลับ จะส่ง null กลับมาทำโล่ห์ทำพระแสงอะไร ?

คนเรียกใช้ต้องมาเสียเวลาตรวจสอบ null อีก ไม่รู้สึกเบื่อหน่ายกันบ้างเลยหรือไง ? ตัวอย่าง ถ้า method ต้อง return ค่าเป็น Collection ออกมา ถ้าไม่มีค่าก็ส่งเป็น Collection ว่าง ๆ กลับมาสิ [gist id="092191a351aec1a7e75b10a1b1a13d68" file="7.java"]
สำหรับข้อมูลที่เป็นพวก Map ก็ให้ใช้ containsKey() ก่อนจะดึงข้อมูลนะ ไม่งั้นเดี๋ยวจะเกิด NPE เอาอีกได้

วิธีการที่ 7 ถ้าสาย Java 8 ก็ Optional สิครับ

ว่าแต่ที่ไหนยังไม่ใช้ Java 8 กันบ้างนะ ? หรือ Java Developer บางคนอาจจะถามว่า ใครเขาใช้กัน ? [gist id="092191a351aec1a7e75b10a1b1a13d68" file="8.java"]

เรื่องพื้นฐานผ่านไป แล้วมันมีวิธีการอะไรอีก ?

  • Assertion ไปเลย
  • ใช้ Library ต่าง ๆ เพิ่ม ที่เห็นใช้บ่อย ๆ ก็เช่น StringUtils จาก Apache Common และ Guice เป็นต้น
  • ใช้ singleton pattern !!
  • ไปเขียน Kotlin กัน
  • อื่น ๆ อีกมากมาย

ขอปิดท้ายด้วยวิธีการที่ขาดไม่ได้เลยคือ เขียน Unit test สิครับ

เพื่อตรวจสอบว่า code ที่เราเขียนขึ้นมา มันโยน NPE ออกมาหรือไม่ ตามที่คาดหวัง รออะไรไปเขียน code กัน วิธีการเยอะนะ เพราะว่าด้วยตัวภาษานั่นเอง แต่ในฐานะของนักพัฒนาก็ต้องเรียนรู้ในภาษาที่เราใช้งานเป็นอย่างดีนะครับ แล้วชีวิตจะดีขึ้นอีกเป็นกองครับ อ่าน ลงมือฝึกฝนและเรียนรู้อยู่ตลอดเวลาครับ พื้นฐานมันสำคัญมาก ๆ ขอให้สนุกกับการเขียน code นะ
↧

ทำการ import ข้อมูลจาก CSV เข้า Elasticsearch ด้วย Logstash แบบง่าย ๆ

December 3, 2017, 7:52 pm
$
0
0

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

เป้าหมายทำการ import ข้อมูลจากไฟล์ CSV เข้า Elasticsearch

ถ้าจะเขียน code ไปเลยก็เกรงใจ ELK stack ซึ่งเขามี Logstash ให้ใช้งานอยู่แล้ว ดังนั้นการ import ข้อมูลก็จะใช้งาน Logstash

การใช้งานก็ไม่ยาก เพียงทำการสร้างไฟล์ configuration ขึ้นมา

เพื่อระบุว่า input มาจากไหน ? filter ขั้นการแปลงข้อมูลเป็นอย่างไร ? output ผลลัพธ์นำไปจัดเก็บที่ไหน ?

จากข้อมูลสรุปได้ว่า

input อ่านจากไฟล์ CSV filter ใช้ csv filter และทำการรวม field ของ Latitude กับ Longitude เข้าด้วยกัน output จัดเก็บลง Elasticsearch และ แสดงผลออกทาง console เพื่อให้เห็นผลการทำงานนิดหน่อย สามารถเขียนไฟล์ configuration ได้ดังนี้ [gist id="a51b9bcc6cd22f6f9de67b57fe39b3da" file="thai.conf"] คำอธิบายเพิ่มเติม เหตุผลที่ต้องรวม field ของ Latitude กับ Longitude เข้าด้วยกัน เนื่องจากรูปแบบข้อมูลที่นำเข้า field ชนิด geo_point ใน Elasticsearch นั้น ต้องการเป็น Latitude, Longitude (ผมเลือกใช้รูปแบบ Geo point as String เพราะว่าง่ายดี) ซึ่ง field ใหม่จะชื่อว่า localtion จากนั้นก็ลบ field ทั้งสองทิ้งไป

สิ่งที่ต้องทำก่อนการ import ข้อมูลจาก CSV ด้วย Logstash คือ

กำหนด mapping ของ field location ก่อน เนื่องจาก Elasticsearch มันไม่สามารถแปลงให้แบบอัตโนมัติ [gist id="a51b9bcc6cd22f6f9de67b57fe39b3da" file="1.txt"] เมื่อทุกอย่างพร้อมก็ run Logstash เลย [code] $logstash -f thai.conf [/code] ได้ข้อมูลจำนวน 7,767 documents มันถูกไหมนะ ?
สุดท้ายส่ง Pull Request ไปแล้ว หวังว่าจะมีประโยชน์ต่อคนใช้งาน Elasticsearch บ้างนะครับ
↧

ว่าด้วยเรื่องความกำกวมของ Requirement

December 5, 2017, 1:15 am
$
0
0

จากหนังสือ Timeless Laws of Software Development นั้น ในส่วนแรกอธิบายถึงเรื่องการวางแผนก่อนที่จะเริ่มพัฒนาระบบงาน (Plan before implementing) เป็นสิ่งสำคัญมาก ๆ ถ้าไม่วางแผนแล้วจะไปกันอย่างไร แต่ปัญหาอย่างหนึ่งของการวางแผนคือ ความกำกวมหรือคลุมเครือของ requirement โดยในหนังสือมีบทสนทนาเรื่อง requirment ที่น่าสนใจ เลยแปลเก็บไว้นิดหน่อย ไม่แน่ใจว่าใครเคยเจอบ้าง คำถาม ช่วยบอกหน่อยว่าคุณอยากได้ระบบอย่างไร ? ลูกค้าตอบว่า ระบบงานเดิมนั้นพัฒนามาประมาณ 12 ปีแล้ว ซึ่งมันล้าสมัยมาก ๆ เราต้องการที่จะพัฒนาใหม่ ทั้งเรื่องของ software และ hardware คำถาม ดีเลย ช่วยอธิบาย requirement และเอกสารของระบบปัจจุบันให้หน่อย ? ลูกค้าตอบว่า เราไม่มีนะสิ ถึงมีก็ไม่น่าจะใช้ได้ เพราะว่าไม่ได้ update เลย แต่เราต้องการพัฒนาระบบใหม่ที่มีความสามารถเหมือนเดิม และเพิ่มความสามารถใหม่ ๆ เข้าไปด้วย ที่สำคัญเรามี source code ของระบบให้นะ คุณเอาไปดูได้เลย มาถึงตรงนี้ คุณจะพูดอย่างไรต่อดี ? ก่อนที่จะวางแผน ก่อนที่จะออกแบบระบบใหม่ ก่อนที่จะวาง architecture ของระบบใหม่ เราต้องเข้าใจระบบเดิมก่อน ซึ่งระบบมีอายุถึง 12 ปี น่าจะเป็นระบบที่ซับซ้อนมาก ๆ ดังนั้นเราของทำความเข้าใจระบบปัจจุบันก่อนนะครับ น่าจะใช้เวลาอย่างน้อง X สัปดาห์ หลังจากนั้นถึงจะบอกได้ว่าต้องใช้เวลา ค่าใช้จ่ายเท่าไรในการพัฒนาระบบใหม่ เมื่อลูกค้าได้ฟังแล้วก็พูดขึ้นมาว่า อะไร ? ทำไม ? เราให้ source code คุณไปนะ น่าจะคิดได้ วางแผนได้ ออกแบบได้ พัฒนาได้เลยนะ มันรีบ มันด่วนมากเลยนะ
มาถึงตรงนี้เห็นปัญหาอะไรกันบ้าง ?
เรื่องที่ตลกร้ายกว่าคือ มีหลาย ๆ บริษัทกลับประเมินให้อีกด้วย ทั้งเวลา ทั้งค่าใช้จ่าย ตลกร้ายกว่านั้น คนที่ประเมินไม่ใช่คนทำ ส่วนคนทำก็ ... ต่อไป ไม่พอนะ รู้ได้อย่างไรว่า source code ที่มีมันคือ สิ่งที่อยู่บน production ?
คำถามคือ แล้วเราทำการวางแผนได้อย่างไร ? ถ้าเจอ requirement แบบนี้ !!
↧
↧

BizDevOps คืออะไร ?

December 6, 2017, 5:53 am
$
0
0

การพัฒนา software ในปัจจุบัน สิ่งที่สำคัญมาก ๆ คือ
  • Fast คือความเร็วของการเปลี่ยนจากความต้องการไปเป็นสิ่งที่อยู่ในมือลูกค้า
  • Innovation product มันคือการเรียนรู้
  • Low cost of change คือค่าใช้จ่ายในการเปลี่ยนแปลงที่ต่ำ
ลองจินตนาการดูสิว่า ถ้าคุณสามารถส่งมอบ software ให้ถึงมือผู้ใช้งานได้ทุกวินาที หรือ นาทีแล้ว มันจะช่วยลดความกลัวต่าง ๆ ลงไปได้เยอะไหม มันจะช่วยทำให้เราเรียนรู้ได้เร็วเพียงใด มันจะช่วยลดค่าใช้จ่ายได้มากเท่าไร

หรือลองคิดสิว่า

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

เราจะเห็นว่าหลาย ๆ องค์กร หลาย ๆ ทีม

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

แต่ปัญหามันก็ยังมีอยู่อีก (เยอะ)

ตัวหลัก ๆ คือ DevOps ยังเน้นในส่วนของการพัฒนาเท่านั้น ซึ่งหลายสิ่งอย่างมักจะขัดแย้งกับฝ่าย Business เสมอ (โยนปัญหากันไปมา) ยกตัวอย่างเช่น KPI (Killer Performance Indicator) !!
ฝ่าย Business ก็บ่นว่าทำไมช้าจัง ไม่เสร็จสักที มี bug อีกแล้ว ฝ่าย Developmeny ก็บ่นว่าทำไม requirement เปลี่ยนบ่อยจัง ไม่ clear เลย เวลาบีบมาก ๆ

มาดูตัวอย่างของปัญหากัน

Business ต้องการได้เร็ว ๆ ทีมพัฒนามีทั้งเรื่องพัฒนาให้เสร็จเร็ว ๆ เรื่องความปลอดภัย เรื่อง performance การทำงาน ถ้าทีมพัฒนาเลือกตาม Business ต้องการคือ ความเร็ว แล้ว ผลที่ตามมามันคือ หายนะล้วน ๆ ได้เร็ว แต่ bug เพียบ ได้เร็ว แต่มีช่องโหว่ในการโจมตีเพียบ ได้เร็ว แต่ performance ห่วย ได้เร็ว แต่ support ห่วย คำถามคือ มันส่งผลดีต่อ Business หรือไม่ ?

ดังนั้นสิ่งเหล่านี้มันคือ ปัญหา หรือ ความท้าทายนั่นเอง

จะทำอย่างไรให้ฝ่าย Bussiness และฝ่ายพัฒนาไปในทิศทางเดียวกัน ? ต้องให้แต่ละฝ่ายมีความสมดุลกัน นั่นคือ Business ต้องสนใจใส่ใจ Technology นั่นคือ Development ต้องสนใจใส่ใจ Business ทั้งสองส่วนมีเป้าหมายร่วมกัน ลดการ rework ลง ร่วมกันจัดเรียงความสำคัญของงานทั้ง Business requirement และ Technical requirement ถ้าสำเร็จก็สำเร็จร่วมกัน ถ้าผิดก็ผิดร่วมกัน เมื่อนำมารวมกันจึงเรียกว่า BizDevOps

BizDevOps Lifecycle

แสดงให้เห็น workflow การพัฒนา software ตั้งแต่ business strategy, requirement, develop, test, deploy ไปจนถึงการ maintenance แน่นอนว่าต้องมีเป้าหมายร่วมกันหรืออย่างเดียวกัน สิ่งที่สำคํญมาก ๆ คือ ในแต่ละรอบนั้นมันเร็วเพียงใด แนวคิดนี้เอื้อให้เกิดขั้นตอนการทำงานแบบอัตโนมัติ ผลที่ตามมาคือ ความเร็วและประสิทธิภาพของระบบงานน นั่นคือองค์กรหรือทีมของคุณนั่นเอง แสดงดังรูป
สุดท้ายแล้ว Collaboration, Communication และ Trust คือหัวใจที่สำคัญครับ
มาเขียน code กัน
↧

ว่าด้วยตำแหน่งใน Software Development

December 7, 2017, 3:31 am
$
0
0

ในโลกของการพัฒนา software นั้น พบว่ามีตำแหน่งที่ไม่เกี่ยวกับการเขียน code หรือ programming เยอะมาก ๆ ดังนั้นมาช่วยบอกหน่อยสิว่า มีตำแหน่งอะไรบ้าง ?
  • Product Manager และ X Manager
  • Business Analyst
  • Software Analyst
  • Graphics Designer
  • UX
  • Quality Control
  • Quality Assurance
  • Operation and Support
  • Technical Writing
  • Sales
  • Marketing
  • Technical Lead
  • Architect
  • Meeting recorder
ส่วนฝ่ายที่เขียน code มี Programmer กับ Developer สุดท้ายแล้ว ไม่ว่าจะมีตำแหน่งอะไรก็ตามในโลกของการพัฒนา software ล้วนมีหน้าที่สำคัญและจำเป็นมาก ๆ แต่สิ่งหนึ่งที่ควรต้องเข้าใจคือ รู้บางอย่างเกี่ยวกับ programming บ้าง เนื่องจากเราไม่สามารถสร้าง software ที่ดีออกมาได้ ถ้าไม่รู้เรื่องอะไรเกี่ยวกับโลกของมันเลย รู้เพื่อจะเข้าใจ รู้เพื่อที่จะคุยกันรู้เรื่อง รู้เพื่อการตัดสินใจ รู้ว่ามันยากแต่ว่าเป้นสิ่งที่จำเป็น
ดังนั้นมาเขียน code กันเถอะครับ
Reference Websites https://dev.to/mortoray/non-programming-roles-in-software-development-6e6 https://mortoray.com/2017/07/03/im-proud-to-be-a-programmer/
↧

ถ้าจะทำ feature ใหม่ น่าจะเขียน User manual ก่อนเลยนะ

December 9, 2017, 3:41 am
$
0
0

มีแนวคิดหนึ่งที่น่าสนใจเกี่ยวกับการพัฒนา Software ลองคิดดูสิว่า ถ้าเราต้องการทำ feature ใหม่ขึ้นมาสักตัว สิ่งแรกที่ต้องทำก่อนคือ เขียน Document หรือเอกสารต่าง ๆ ก่อนนะ ตัวที่สำคัญมาก ๆ คือ User manual document !! คำถามที่น่าสนใจ คือ ยังไม่เริ่มพัฒนาเลย จะเขียนได้อย่างไร ? คำตอบคือ นั่นแหละคือปัญหาของ requirement ที่คุณยังไม่รู้แม้กระทั่งว่าจะใช้งานกันอย่างไร ? เริ่มขั้นตอนการทำงานตรงไหน ? จะจัดการต่อไปอย่างไร ? ที่สำคัญแสดงว่า คุณไม่ได้สนใจอะไรเลย มีแค่จะเอานั่นเอานี่ สุดท้ายมันก็เจอปัญหาเดิม ๆ กันใช่ไหม ? ยิ่งคนที่อยู่ปลายน้ำ ที่ต้องโดนด่าตลอดคือใคร ? บางที่อาจจะเป็น Call center ที่ ไม่รู้แม้กระทั่งว่า มันมี feature นี้ด้วยหรอ !!

ดังนั้นเขียน User manual ก่อนเริ่มพัฒนาเลย

เพื่อทำให้เข้าใจสิ่งที่ต้องการชัดเจน ไม่ใช่เอาเหมือนเดิม ทั้ง business, development, test, infra, operation นะ ถ้ายังไม่เข้าใจก็อย่าเริ่มพัฒนา เพราะว่าจะเกิดการ rework เยอะมาก แต่ถ้ารวยก็ทำไป ใน User manual จะมีขั้นตอนการใช้งานที่ชัดเจน มันคือสิ่งที่สามารถนำมาทำ automation process ได้
ถ้ามันยากต่อการเขียน ถ้ามันยากต่อการอธิบาย ดังนั้นกลับมาคิดและออกแบบใหม่เถอะนะ
เน้นย้ำว่าทำในแต่ละ feature ที่กำลังจะทำนะครับ เพื่อให้เห็นว่า feature มันพร้อมที่จะพัฒนาจริง ๆ ถ้ายังไม่พร้อมก็มาคิดมาคุยมาวางแผนมาออกแบบกันใหม่ ขอให้สนุกกับการ coding ครับ
↧
Search

วันว่าง ๆ มาดู code ที่น่าจะต้องปรับปรุง

December 11, 2017, 12:41 am
$
0
0

เนื่องจากเพิ่งผ่านการ review code มากว่า 41 project ก็ได้เห็นรูปแบบของ code ที่น่าสนใจหลาย ๆ อย่าง ทั้งเรื่องความซับซ้อน ทั้งเรื่องของ indent ทั้งเรื่องของการ hard code ทั้งเรื่องของการ comment ทั้งเรื่องการ debug code ทั้งเรื่องของการตั้งชื่อ ทั้งเรื่องของ code ที่ไม่ใช้งานหรือมีมากเกินความจำเป็น จึงทำการสรุปไว้ใน slide นิดหน่อย [slideshare id=83835878&doc=sck-example-171211082038&h=640&w=480] คำถามที่น่าสนใจคือ เรารู้หรือไม่ว่า code เหล่านี้มันไม่ดี ? เรารู้หรือไม่ว่า code เหล่านี้มันไม่ดีอย่างไร ? ถ้าเราสามารถตอบได้ คำถามที่จำตามมาคือ จะทำการแก้ไขได้อย่างไรบ้าง ? เพื่อทำให้ code มันดีขึ้น
ดังนั้นช่วงวันหยุดลองมา review code เพื่อทำการปรับปรุงต่อไปครับ การเขียน code มันสนุกนะ
↧
↧

Kotlin :: หัดใช้งาน Reflection กันหน่อย

December 15, 2017, 2:22 am
$
0
0

ไปงาน Kotlin meetup 1.2 มา มีทั้งเรื่องของ Kotlin reflection และ PWA with Kotlin ซึ่งเป็นเรื่องที่ไม่เคยใช้งานเลย ดังนั้นจึงลองศึกษาเรื่องของ Reflection ก่อนว่ามันใช้งานอน่างไรบ้าง มาเริ่มกันเลย

Reflection ช่วยให้เราเข้าถึงส่วนต่าง ๆ ของ code ในช่วง runtime ได้

โดยที่ไม่ต้องรู้รายละเอียดต่าง ๆ จากการ compile เลย ยกตัวอย่างเช่น
  • การสร้าง instance ของ class
  • การเข้าถึง function หรือดูชื่อ function ของ class
  • สามารถเรียกใช้งาน function ได้
  • ดูว่ามี field อะไร ชื่ออะไร ค่าอะไร
  • ดู parameter ต่าง ๆ
  • เข้าถึงพวก Generic และ Annotation ได้อีก
สามารถนำ Reflection มาใช้ประโยชน์ได้เช่น กรณีที่เราต้องการจัดการข้อมูลในฐานข้อมูล แน่นอนว่าต้องมี Entity class/type แน่นอน และในระบบจะมี Entity มากมายหลายชนิด ถ้าเราต้องการให้ทำการ generate SQL จาก Entity class เหล่านี้ สามารถนำ Reflection มาใช้ได้ เพื่อทำการดึงชื่อและชนิดของ field/property จาก Entity class ออกมาในขณะ Runtime ทำให้ชีวิตของนักพัฒนาง่ายขึ้น หรือในระบบแบบ plugin เมื่อทำการเพิ่ม plugin เขามาใหม่ ต้องทำการสร้าง instance ใหม่ในขณะ runtime เราสามารถใช้ Reflection สร้าง instance ใหม่ขึ้นมาได้ โดยรวมจะทำงานกับ
  • Class
  • Function
  • Property
  • การทำงานร่วมกับ Java
  • Constructor

มาลองใช้งานกันหน่อย

เริ่มจากตัวอย่างง่าย ๆ ดีกว่า เพราะว่าผมก็มือใหม่ อยากลองทำระบบ plug-in โดยทำการกำหนด class ของ plug-in ไว้ในไฟล์ จากนั้นทำการสร้าง instance ของ plugin แต่ละตัว โดยเราจะใช้ความสามารถของ Reflection นั่นเอง มาเริ่มกันเลย ขั้นตอนที่ 1 ทำการกำหนดโครงสร้างของ plug-in รวมทั้งสร้าง plugin แต่ละตัวขึ้นมา ตัวอย่าง code นั้น plug-in แต่ละตัวจะมีโครงสร้างดังนี้ [gist id="4efca850d31a1ae3198bf242022afa76" file="plugin.kt"] ขั้นตอนที่ 2 ทำการสร้างไฟล์ property สำหรับกำหนดค่าของ plug-in ที่ต้องการ [gist id="4efca850d31a1ae3198bf242022afa76" file="plugins.properties"] ขั้นตอนที่ 3 เขียน code สำหรับสร้าง instance ของ plug-in แต่ละตัวด้วย Reflection [gist id="4efca850d31a1ae3198bf242022afa76" file="Main.kt"] เพียงเท่านี้เราก็สามารถสร้างระบบ plug-in อย่างง่ายได้แล้ว

หรืออีกตัวอย่างคือ การเขียน log ของ data class

สามารถนำ reflection เข้ามาช่วยได้อีก ดังนี้ [gist id="4efca850d31a1ae3198bf242022afa76" file="log.kt"] แต่ reflection นั้นมันจะส่งผลให้ performance การทำงานแย่ลง ดังนั้นการใช้งานต้องมาดูข้อดีและข้อเสียด้วยนะครับ ขอให้สนุกกับการเขียน code
↧

ว่าด้วยเรื่องการนำ pair programming มาใช้งานในทีม

December 16, 2017, 8:25 pm
$
0
0

เรื่องเล่าที่น่าสนใจเกี่ยวกับการนำ Pair programming มาใช้ในทีมพัฒนา มีอยู่ว่า เริ่มต้นได้แนะนำให้ทีมมาลองทำ Pair programming กัน ซึ่งสมาชิกส่วนใหญ่ก็เห็นด้วยว่า ลองทำดูสักพักก็ได้ แต่ก็มีคนไม่เห็นด้วยและปฏิเสธที่จะทำ แน่นอนว่า ถ้าปฏิเสธก็ไม่เป็นไร ทำงานเช่นเดิม ส่วนคนที่สนใจก็ทำงานแบบ Pair programming ไป แต่ก่อนที่จะเริ่มต้นนั้น ทีมได้มีข้อตกลงในการทำงานร่วมกัน (Team Agreement) ว่าจะทำการจดสถิติของ bug/defect ไว้บน board หรือกระดานที่ทุกคนเห็น (Transparency) ประกอบไปด้วย
  • ชื่อและรายละเอียดของ Bug
  • ชื่อคนเขียน code ในบรรทัดที่มี bug
  • บรรทัดของ code ที่มี bug
เมื่อได้ข้อตกลงร่วมกันก็ลงมือทำงานกันได้ คน Pair ก็ Pair กันไป คนไม่ Pair ก็ทำงานของตัวเองกันไป หลังจากนั้นไม่ถึงเดือนก็ได้เจอสิ่งที่น่าสนใจคือ จำนวน bug และชื่อของคนที่ไม่ทำ Pair programming เยอะมาก ๆ กลายมาเป็นมือหนึ่งสำหรับการสร้าง bug เมื่อเทียบกับคนอื่น ๆ จนทำให้ชีวิตเริ่มลำบากขึ้นอย่างมาก ไม่พอนะ สิ่งที่ไม่คาดคิดก็เกิดขึ้นมาคือ กลุ่มสร้าง bug เยอะ ๆ เริ่มมาถามสมาชิกในทีมว่า ช่วยมา Pair programming ด้วยได้ไหม คำตอบที่ได้คือ จะรอทำไมละ มาทำกันเลย
คำถามคือ bug จะหายไปหรือไม่ ? ตอบได้เลยว่า ไม่ แต่มันช่วยลดจำนวน bug ลงไป
อีกทั้งการนำแนวปฏิบัติต่าง ๆ มาใช้นั้น เราเพียงแค่แนะนำ เชิญชวนให้ทำ อย่าไปบังคับ ถ้าไม่จำเป็น !! เพื่อให้ทุกคนในทีมได้ทดลอง ว่ามันดีหรือไม่ เหมาะหรือไม่ ช่วยหรือไม่ รวมทั้งสิ่งต่าง ๆ ที่เกิดขึ้นต้องแสดงออกมาอย่างชัดเจนอีกด้วย (สำหรับการวัดผล) ขอให้สนุกกับการ coding ครับ
↧

Golang 1.10 :: รู้หรือยังว่า go test มันเปลี่ยนไป

December 17, 2017, 2:18 am
$
0
0

จากเอกสารของภาษา Golang 1.10 (beta 1) นั้น ในส่วนของ go test มีการเปลี่ยนแปลงที่น่าสนใจมาก ๆ จึงนำมาสรุปและลองใช้งานกันหน่อย ประกอบไปด้วย
  • การทำ caching ของ test result
  • ทำการทดสอบเฉพาะส่วนที่มีการเปลี่ยนแปลงเท่านั้น
  • ทำการ run go vet โดย default
  • go test -coverpkg สามารถใส่ชื่อเป็น pattern ได้
  • go test -failfast หยุดการทดสอบทันทีถ้ามี test case ที่ไม่ผ่าน
  • go test -json ทำการสร้าง test result ในรูปแบบ JSON
เริ่มใช้งานกันนิดหน่อย

เรื่องของการทำ caching ของการทดสอบ

จะทำ caching เฉพาะการทดสอบที่ผ่านเท่านั้น ที่สำคัญคือ
ถ้ามีการแก้ไข production code แล้ว จะทำการทดสอบเฉพาะ test ที่เกี่ยวข้องกับ production code ที่เปลี่ยนเท่านั้น เป็นความสามารถที่มีประโยชน์มาก ๆ เพราะว่า ทำให้การทดสอบมีประสิทธิภาพสูงขึ้นอย่างมาก
มาดูตัวอย่างการใช้งาน [gist id="be411c7dc31e6d644c3e5f3a4c897832" file="1.txt"]

เรื่องของ code coverage

สามารถเลือก package ที่ต้องการดู code coverage ได้เลย รวมไปถึงการสร้าง report อีกด้วย [gist id="be411c7dc31e6d644c3e5f3a4c897832" file="2.txt"]

เรื่องของ failfast

จะหยุดการทดสอบทันทีเมื่อมี test case ไม่ผ่าน ที่สำคัญไม่ทำ caching ด้วยนะ !! [gist id="be411c7dc31e6d644c3e5f3a4c897832" file="3.txt"] ดังนั้นจะรออะไรกัน ทำการ download Golang 1.10 beta 1 มาลองใช้งานได้แล้วนะ
ว่าแต่เขียน test กันหรือยัง ?
ขอให้สนุกกับการ coding นะครับ
↧

ว่าด้วยเรื่องของการวัดผลของ DevOps

December 18, 2017, 8:40 am
$
0
0

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

เป้าหมายหลักของ DevOps คือ

  • Velocity
  • Quality
  • Performance
นั่นคือต้องส่งมอบ software ได้เร็วและบ่อย พร้อมคุณภาพและประสิทธิภาพที่สูง โดยที่จะเร็ว และ ดีเพียงใด ขึ้นอยู่กับระบบ ขึ้นอยู่กับทีมงาน ขึ้นอยู่กับความเสี่ยง จะดีเพียงใดมันตอบยาก จะเร็วเพียงใดมันตอบยาก จะมีคุณภาพสูงเพียงใดมันตอบยาก ดังนั้นมาลองพิจารณาตัวเลขเหล่านี้หน่อยว่า มันเพียงพอสำหรับการวัดเกี่ยวกับ DevOps หรือไม่ ?
ก่อนที่จะวัดอย่าลืมวัดค่าต่าง ๆ เหล่านี้ก่อนที่จะเปลี่ยน หรือนำแนวคิด DevOps มาใช้ด้วยนะครับ จะได้มีค่าที่เป็น based line เอาไว้วัดผล

ขนาดของการ deploy ในแต่ละครั้งใหญ่เพียงใด

ยกตัวอย่างเช่น จำนวนของ feature จำนวนของ story/flow จำนวนของการแก้ไข bug แต่สิ่งที่ต้องกำหนดดี ๆ คือ ขนาดของ feature/story/bug ต้องเท่า ๆ กันนะ

มีการ deploy บ่อยเพียงใด

ซึ่งมันสัมพันธ์กับขนาดของที่จะ deploy ในแต่ละครั้ง ถ้าขนาดของการ deploy มีขนาดเล็กแล้ว การ deploy ก็จะเร็ว การทดสอบก็ง่ายขึ้น ซึ่งควรวัดความถี่ทั้ง QA, Pre-Prod และ Production กันเลย เพื่อทำให้เราค้นหาข้อผิดพลาดได้รวดเร็วขึ้น ยิ่ง development ได้เลยยิ่งดี เป็นแนวทางหนึ่งในการลดข้อผิดพลาดอีกด้วย

ค่า Lead time

เพื่อใช้วัดผลการทำงานว่าเร็วหรือช้าลง สิ่งที่สำคัญคือ ต้องกำหนดจุดเริ่มต้นและสิ้นสุด ยกตัวอย่างเช่น จุดเริ่มต้นคือ การคุย requirement กับลูกค้า จุดสิ้นสุดคือ การ deploy บน production และลูกค้าใช้งาน

จำนวน feedback จากผู้ใช้งานและลูกค้า

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

จำนวนของ Automation test ที่ผ่าน

ถ้าทีมคุณต้องการที่จะเร็ว สิ่งหนึ่งที่ต้องทำก่อนคือ automation test ทั้ง unit test, integration test และ functional test โดยที่แนวคิด DevOps เน้นกระบวนการแบบอัตโมัติอย่างมาก หนึ่งสิ่งที่สำคัญคือ การทดสอบ ดังนั้นจำนวนของ automation test จึงต้องสูง แต่สิ่งที่สำคัญกว่าคือ จำนวน automation test ที่ผ่าน ยังไม่พอนะ ถ้า automation test มันดีแล้ว จะบอกได้ว่า เมื่อทำการแก้ไข code แล้ว จะมี automation test พังจำนวนเท่าไร

จำนวน defect ที่เจอบน production

ถ้าคุณเจอ defect/bug บน production จำนวนสูงขึ้น นั่นหมายความว่า สิ่งที่คุณกำลังทำอยู่นั้นมันไม่น่าจะดี ทั้งการทดสอบแบบ manual และ อัตโนมัติ ดังนั้นจำเป็นต้องทำการปรับปรุงให้ดีขึ้น

Availability และ Downtime ของระบบ

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

จำนวน Error rate ของระบบ และประสิทธิภาพการทำงานของระบบ

เป็นค่าที่สำคัญมาก ๆ ของ software เพื่อทำให้เห็นว่า สิ่งที่ deploy ไปนั้นมีคุณภาพหรือไม่ ดังนั้นสิ่งที่ software ควรมีคือ ระบบ tracing เพื่อดูการทำงานของระบบ ว่ามีข้อผิดพลาดเกิดขึ้นหรือไม่ ทั้งการเกิด exception ต่าง ๆ ทั้ง production issue เช่น ปัญหา database connection ปัญหา query timeout

จำนวน Usage และ Traffic ต่าง ๆ ของระบบ

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

ยังมีค่าอื่น ๆ อีกนะ เช่น

เมื่อเกิดปัญหาบน production แล้วคุณใช้เวลาเท่าไร ในการค้นหา root cause และ แก้ไข นั่นคือ Mean Time to Detection (MTTD) Mean Time to Recovery (MTTR) ดังนั้นเรื่องของ application monitoring จึงสำคัญมาก ๆ โดยรวมแล้วอย่าลืมว่า DevOps นั้นคือ การทำงานร่วมกันของแต่ละฝ่ายที่เกี่ยวข้อง ทั้ง business ทั้งทีมพัฒนา ทั้งขั้นตอนการ deploy ทั้งการ monitoring application
มิใช่ต่างฝ่ายต่างทำกันไป !! อย่าลืมว่า ทุกอย่างมันเริ่มที่คน คนคิด process จากนั้นทำการปรับปรุง process ให้ดีด้วยเครื่องมือ
↧
↧

คำถาม :: เราวิเคราะห์ code ด้วยอะไรกันบ้าง ?

December 19, 2017, 11:28 pm
$
0
0

วันนี้เจอคำถามที่น่าสนใจคือ เราทำการวิเคราะห์ code ของระบบงานที่เราพัฒนากันอย่างไร ?
เพื่อทำให้รู้สถานะปัจจุบันของระบบ เพื่อทำให้เข้าใจโครงสร้าง เพื่อทำให้เห็นมุมมองต่าง ๆ เพื่อทำให้เห็นปัญหาต่าง ๆ หลังจากนั้นจึงนำข้อมูลเหล่านั้น มาปรับปรุง code ของระบบให้ดีขึ้น สิ่งที่น่าจะใช้ในการวิเคราะห์น่าจะประกอบไปด้วยอะไรบ้าง ?
  • ความซับซ้อนของ code ด้วย Cyclomatic complexity
  • ใช้ Lint
  • Static code analysis
  • Duplicate code
  • Dead code
  • Cohesion
  • Coupling
  • Testing
  • Code coverage
  • Dependency graph
  • Performance, Tracing และ Monitoring app
  • ดูด้วยตาคน ใจคน ประสบการณ์คน
  • และอื่น ๆ อีกมากมาย
คำถามคือ ในทีมพัฒนาใช้อะไรมาวัดบ้าง ? อย่างไร ? คำถามต่อมาคือ ทำการปรับปรุงแก้ไขหรือไม่ ? อย่างไร ?
↧

Developer ต้องหัดจัดการเรื่องของ Technical Debt นะ

December 22, 2017, 1:08 am
$
0
0

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

หรืออาจจะพบเจอว่า

ยิ่งเพิ่ม feature เข้าไป ทำไมมันยิ่งช้า ทำไมใช้เวลาพัฒนานานขึ้นเรื่อย ทำไมจำนวน bug เยอะ เหมือนว่ามะจะมีแต่สิ่งร้าย ๆ ตามมานะ แต่รู้ไหมว่า ในข่าวร้ายก็ยังมีข่าวดี นั่นคือ เราไม่ได้เป็นแบบนี้อยู่คนเดียว เกือบจะทุกที่เจอหรืออยู่ในสถานการณ์แบบนี้ !! ดังนั้น Developer น่าจะลองมาฝึก มาเรียนรู้ เพื่อลดจำนวนของ Technical Debt ลงไปบ้างนะครับ เช่นลดพวก shortcut solution หรือบางที่ก็เรียกว่า workaround หรือบางทีก็ทำให้มันผ่าน ๆ ไป เสร็จ ๆ ไป มาลองฝึกสิ่งเหล่านี้กันดู

สิ่งที่ทำอยู่ในทำงานได้เป็นปกติไหม ?

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

เราไม่สามารถควบคุมอะไรได้เลย ?

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

ทีมรู้ไหมว่า วิธีการที่คุณแก้ไขปัญหาของคุณหรือไม่ ?

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

สุดท้าย อย่ายึดติดกับเรื่องหนี้มากนัก

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

การทดสอบในมุมของ Developer คนหนึ่ง (Developer Testing)

December 22, 2017, 8:37 am
$
0
0

การทดสอบช่วยทำให้เห็นว่า สิ่งที่สร้างตามความต้องการมันเป็นอย่างไร ทำการอธิบายว่า การสร้างในแต่ละส่วนเป็นอย่างไร ทำงานอย่างไร โดยที่การทดสอบมีทั้ง Manual และ Automation เรื่องของ Automation test นั้นเป็นรูปแบบหนึ่งของ Risk management ซึ่งช่วยลดความเสี่ยงต่าง ๆ ของระบบงานลงไป แน่นอนว่า ต้องทำงานแบบอัตโนมัติ แต่สิ่งหนึ่งที่มักไม่พูดถึงกันคือ การสร้างชุดการทดสอบนั่นเอง ซึ่งมันไม่ง่ายเลย มีค่าใช้จ่ายสูงทั้งในแง่ของจำนวนคนและเวลาที่ใช้ ส่วน Manual testing มักจะทำในช่วยท้าย ๆ ของขั้นตอนการพัฒนา ซึ่งต้องการคนทดสอบจำนวนมาก ตามขนาดของระบบ อีกทั้งการทดสอบแต่ละครั้งต้องใช้เวลาและค่าใช้จ่ายสูง
จะเห็นได้ว่าการทดสอบทั้งสองแบบมีทั้งข้อดีและข้อเสีย ชีวิตมันยากจริง ๆ ต้องคิดเยอะหน่อยนะ คิดเยอะไปก็ไม่ดี ลงมือทำด้วยนะ

สิ่งที่สำคัญในการทดสอบคือ จะทดสอบ และ verify อะไร ?

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

มาดูในเรื่องการพัฒนาบ้าง

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

คำถามที่ถูกถามบ่อยมาก ๆ คือ ต้องทดสอบมากน้อยเพียงใด ?

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

ยังไม่พอนะ ถ้าไปทำงานกับระบบงานเก่า ๆ ที่ไม่มี Automation test ละ ?

จะทำกันอย่างไร แน่นอนว่าระบบเก่า ๆ ที่ไม่มีชุดการทดสอบแบบอัตโนมัติ ในหนังสือ Working Effectively with Legacy code จะเรียกว่า Legacy code หรืออาจจะมีก็มี code/test coverage ที่น้อยมาก ๆ ดังนั้นสิ่งที่ต้องทำก่อนคือ การทำความเข้าใจกับระบบ ในมุมของนักพัฒนาคือ ทำการ run และ ทดสอบส่วนการทำงานต่าง ๆ ด้วยการเขียน test ในส่วนการทำงานนั้น ๆ เพื่อเรียนรู้และเข้าใจมันมากขึ้น เพื่อทำให้มีความมั่นใจ ก่อนจะทำงานและแก้ไขต่อไป เช่น การ refactor หรือ แยกส่วนการทำงานออกมา เรียกการทดสอบลักษณะนี้ว่า Explorative testing อีกทั้งยังมีวิธีการอื่น ๆ อีก เช่น Snapshot testing หรือ Approval testing ช่วยให้เราเก็บสถานะต่าง ๆ ของการทำงานไว้ เพื่อนำกลับมาทดสอบซ้ำ

ถามว่าการทดสอบมันมีเยอะไหม ตอบเลยว่ามาก ดังรูป

จะเยอะไปไหน !! ไม่อธิบายดีกว่า

อธิบายมายาว ตัดจบดีกว่า

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

ฝึก ฝึก ฝึก จาก Programming Jokes

December 22, 2017, 8:52 am
$
0
0

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

Golang :: มาตรวจสอบความพร้อมของระบบกันหน่อย

December 23, 2017, 7:34 am
$
0
0

จากบทความเรื่อง How to ship production grade Go ? แนะนำสิ่งที่ควรต้องทำก่อนที่จะทำการ deploy code ขึ้นไปยัง production server ซึ่งมีหลายสิ่งอย่างที่ควรทำ มิเช่นนั้นอาจจะเจอปัญหาต่าง ๆ มากมาย ทั้งที่คาดหวังและไม่คาดหวังแน่นอน ดังนั้นเรามาเตรียมความพร้อมกัน จึงนำมาแปลและสรุปไว้นิดหน่อย ในบทความนี้จะยกตัวอย่างระบบที่พัฒนาด้วยภาษา Go มีเป้าหมายเพื่อส่งมอบ code ที่มีความน่าเชื่อถือ ที่สามารถระบุและบอกปัญหาได้ ซึ่งพร้อมสำหรับการ deploy

สิ่งที่นักพัฒนาระบบด้วยภาษา Go ต้องทำประกอบไปด้วย ( แบบ minimal สุด ๆ)

  • การจัดการ Error ต่าง ๆ
  • เมื่อเกิด Panic ขึ้นมา ควรทำการแจ้งให้รู้ทันที
  • กำหนดมาตรฐานของ logging message ให้ชัดเจน
  • ระบบงานต้องมีการเก็บ metric ต่าง ๆ เสมอ
  • ทำการทดสอบในระดับต่าง ๆ ทั้ง unit, integration และ acceptance test พร้อมตรวจดูค่า coverage ด้วย
มาดูรายละเอียดในแต่ละข้อกัน
ระบบงานที่พัฒนาด้วยภาษา Go นั้น เรื่องของ Error และ Panic จำเป็นต้องจัดการให้ดี

มาดูที่ Error กันก่อน

ภาษา Go นั้นในแต่ละ method จะทำการ return ค่า Error กลับมาเสมอ เพื่อบอกสถานะของการทำงานว่าเป็นอย่างไร ถ้า Error เป็น nil แสดงว่ามีสถานะเป็นปกติ แต่ถ้าไม่ nil หมายถึงเกิดเหตุการณ์ที่ไม่ปกติขึ้นมาแล้ว ดังนั้น developer สามารถจัดการกับ Error ได้ง่ายมาก ๆ โดยที่ package สำหรับการจัดการ Error ที่ใช้บ่อย ๆ คือ Errors มันใช้ง่ายและมีประโยชน์อย่างมาก ที่สำคัญ ควรดัก error เดิมเพียงครั้งเดียวหรือที่เดียวนะ ไม่ใช่โยนและ print error message ไปเรื่อย ๆ รวมทั้งถ้าจะ print error message ต้องมีรูปแบบที่เป็นมาตรฐานทั้งระบบนะ มิฉะนั้นจะหา error ยากมาก ๆ [gist id="3ef77e23a1db736bb3781872a8529ea0" file="error.go"]

ต่อมาเรื่องของ Panic ถ้าเกิดขึ้นมาต้องแจ้งหรือส่งข้อมูลออกมาทันที

ถ้าเกิด Panic ขึ้นมาในระบบงานแล้ว เราไม่สามารถจัดการได้เหมือน Error ดังนั้นถ้าจัดการหรือเรียกว่า recover ไม่ดีแล้ว ระบบงานก็จะหยุดทำงานได้เลย ซึ่งส่งผลเสียต่องานอย่างมาก สิ่งที่ควรทำคือ การ recover นั่นเอง ที่สำคัญคือ เมื่อเกิด Panic ขึ้นมาต้องแจ้งมายังทีมพัฒนาหรือผู้ดูแลด้วย เช่นผ่าน Email, Slack, Line หรืออะไรก็ตามที่ทำให้รู้ทันที เนื่องจาก Panic มันคือสิ่งที่สำคัญมาก ๆ อย่าปล่อยให้หลุดมือไปเด็ดขาด มาดูตัวอย่างกัน [gist id="3ef77e23a1db736bb3781872a8529ea0" file="panic.go"]

เรื่องของ Logging ต้องกำหนดรูปแบบมาตรฐานขึ้นมา

ปัญหาของการจัดเก็บ log คือ รูปแบบที่ไร้ซึ่งมาตรฐาน ใครอยากเขียนแบบไหนก็ทำไป !! ซึ่งยากต่อการดูแล ซึ่งยากต่อการนำมาใช้งาน
โดยมี library ช่วยจัดการเยอะมาก ยกตัวอย่างเช่น Logrus, Zap และ Log15 เป็นต้น
ตัวอย่างที่ดี เช่น การจัดการในรูปแบบ key-value ด้วย Logrus [gist id="3ef77e23a1db736bb3781872a8529ea0" file="log.go"] เมื่อ log มีโครงสร้างที่ดีและมีมาตรฐานแล้ว ก็อย่าเขียนลงไฟล์อย่างเดียวนะ ให้ไปจัดเก็บในระบบอื่น ๆ บ้าง เพื่อช่วยให้วิเคราะห์ได้ง่ายขึ้น ยกตัวอย่างเช่น การใช้งาน ELK stack เป็นต้น

ต่อมาต้องจัดการเรื่องของ Metric ต่าง ๆ ด้วย

สิ่งที่มักจะมีเสมอคือ Monitoring สำหรับ Server เพื่อดูการใช้งานต่าง ๆ และ performance ของ server เช่น CPU, Memory, Disk และ Network เป็นต้น แต่สิ่งที่มักขาดหายไปเสมอคือ Metric ของระบบงานหรือ application นั่นเอง !! แต่คำถามที่เกิดขึ้นคือ จะเก็บ metric อะไรบ้างละ ? ตอบได้ยากมาก ๆ เพราะว่าแต่ละระบบมันแตกต่างกัน ความต้องการต่างกัน ยกตัวอย่างเช่น ระบบ REST APIs สิ่งที่อยากรู้น่าจะประกอบไปด้วย
  • จำนวน request และ response ในแต่ละช่วงเวลา เช่น นาที ชั่วโมง วัน เป็นต้น
  • จำนวน success และ error ของ response
  • Response time ของแต่ละ request รวมไปถึงค่าทางสถิติต่าง ๆ เช่น Max, Min, Average และ Percentile เป็นต้น
  • แยกข้อมูลในแต่ละ endpoint
  • เรื่องของ rate limit การใช้งานของผู้ใช้แต่ละคน
ถามว่าเยอะไหม ? ตอบเลยว่ามาก แต่สิ่งเหล่านี้น่าจะเป็นคำถามที่ต้องเกิดขึ้นมาตั้งแต่ต้น มันคือสิ่งที่ทำให้เราเข้าใจระบบ และ ความต้องการ รวมไปถึงการทำงานของระบบมากขึ้น ยกตัวอย่างเช่น เคยตั้งคำถามไหมว่า ทำไมคุณต้อง deploy ระบบในช่วงหลังเที่ยงคืน ? ทำตาม ๆ กันมา หรือนำข้อมูลจาก Metric ที่เก็บไว้มาใช้ในการตัดสินใจ คำถามต่อมา คือ เก็บที่ไหนละ ? ตอบได้เลยว่า มีให้เพียบ ใช้ทั้งเก็บข้อมูลในรูปแบบ time serie ใช้ทั้ง aggregation ใช้ทั้งแสดงผลในรูปแบบกราฟสวย ๆ และเข้าใจง่าย ยกตัวอย่างเช่น แน่นอนว่ามี library ที่เขียนด้วยภาษา Go ให้ใช้งานแน่นอน
คำถามสุดท้ายคือ ระบบของคุณมีแล้วหรือยัง ?

เรื่องสุดท้ายคือ การทดสอบแบบอัตโนมัติ

ในฐานนะของ developer code ที่เขียนขึ้นมานั้น ถูกทดสอบหรือไม่ ? code ที่เขียนขึ้นมานั้น มีชุดการทดสอบแบบอัตโนมัติหรือไม่ ? การทดสอบมีทั้ง
  • End-to-End test
  • Integration test
  • Unit test
โดยที่ภาษา Go นั้นมี package testing มาให้อยู่แล้ว ถ้าทดสอบทำงานเกี่ยวกับพวก HTTP ก็มีให้ใช้อีกคือ testing/httptest ถ้าทดสอบการทำงานเกี่ยวกับ io.Reader และ io.Writer ก็มี testing/iotest ถ้าระบบมี input ที่ซับซ้อนแนะนำให้ใช้งาน go-fuzz ดังนั้นถามระบบไหนที่พัฒนาด้วยภาษา Go แล้วไม่เขียนชุดการทดสอบ ถือว่าบาปมาก ๆ ถ้าไม่อยากบาป ก็เขียนเถอะนะ
ถ้าคุณกำลังจะ deploy ระบบ ที่ไม่มีชุดการทดสอบขึ้น production แล้ว แนะนำว่าให้หยุด !! แล้วมาเขียนชุดการทดสอบก่อนเถอะนะ เพื่อทำให้มั่นใจก่อน deploy
ที่สำคัญ Go มีตัวช่วยในการดูค่า test coverage อีกด้วยนะ โดยที่ไม่ต้องติดตั้งอะไรเพิ่มเลย ดังนั้นใช้มันซะ มันคือเพื่อที่ดีมาก ๆ ของคุณ
แนะนำให้ทำการทดสอบบ่อย ๆ และทำตั้งแต่เริ่มต้นนะครับ ชีวิตจะดีขึ้นกว่าเดิมแน่นอน แค่เขียน ชีวิตก็เปลี่ยน
จากนั้นถ้ามีชุดการทดสอบแบบอัตโนมัติแล้ว ก็ให้ทำการ run ทุกครั้งแบบอัตโนมัติเมื่อ code เปลี่ยนแปลงกันไปเลย

สุดท้ายแล้ว ที่อธิบายมาคือ checklist แบบ minimal สุด ๆ

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

Git :: เลือก Branch Strategy อะไรดี ?

December 25, 2017, 8:47 am
$
0
0

ปัญหาหลักที่มักเจอเกี่ยวกับการจัดการ source code ด้วย VCS (Version Control System) เช่น Git คือ เราจะเลือก branch strategy แบบไหนดี ? ยกตัวอย่างเช่น
  • TBD (Trunk-Based Development)
  • Integration branch (Master และ Develop)
  • Feature branch/ Git flow
  • Pull Request

จากสิ่งที่พบเจอมานั้น มีสิ่งที่น่าสนใจคือ

TBD ไม่เหมาะกันงานของเรา Integration branch ดีเลยนะ แต่งานของเราขึ้นไม่พร้อมกัน Feature branch/ Git flow มันใช่เลย แต่ ไป ๆ มา ๆ จำนวน branch เยอะมาก แต่ ไป ๆ มา ๆ แต่ละ branch มีอายุที่ยามนานมาก ๆ กว่าจะ merge ไปยัง branch หลัก Pull request ก็มีปัญหาเยอะ ในการ review อีกทั้ง code แย่และไม่ถูกต้อง ประเด็นคือ ทำไมแต่ละแนวทางมีแต่ปัญหานะ ? ทั้งที่เราทำงานเป็นรอบสั้น ๆ นะ ทั้งที่เราทำงานแบบ feature-based นะ

แต่เมื่อเราลงไปดูในรายละเอียด

ของแต่ละ branch แต่ละ feature พบสิ่งที่สะเทือนใจมาก ๆ คือ จำนวน commit เยอะมาก ๆ บางทีมบอกว่า แต่ละ commit มันคือแต่ละ task เลยนะ จำนวน commit มันบอกให้เรารู้ว่า มี task ที่ต้องทำเยอะมากมาย เมื่องานเยอะเกินไป ปัญหาจึงตามมา นั่นคือ ทำการ merge code กับ branch หลักก็ยาก conflict เพียบ ทดสอบก็ยาก การ deploy แต่ละครั้งจึงเจ็บปวดรวดร้าว
ดังนั้นสิ่งที่ควรทำเป็นอันดับแรกเลย คือการกำหนดจำนวนและขนาดของงานที่ทำก่อนเลย
ยกตัวอย่างเช่น ทำทีละงาน กำหนดเวลาหรืออายุของ feature branch ที่สร้าวขึ้นมา เมื่อสิ้นสุดเวลาที่กำหนด หรือ งานที่ทำเสร็จแล้ว ให้ทำการ merge, test และ deploy กันเลย ที่สำคัญคือ ลบ branch เมื่อทุกอย่างมีสำเร็จ โดยวิธีการนี้ มันช่วยทำให้เราเห็นว่า สิ่งที่เราทำนั้นเป็นอย่างไร การทำงานของเราเป็นอย่างไร เพื่อปรับปรุงและแก้ไขต่อไป ที่สำคัญจะทำให้เราเห็นว่า feature หรือ story ที่พัฒนานั้น ควรมีขนาดเล็กเท่าไรดี และไม่มี branch ที่มีอายุนาน ๆ อีกต่อไป

สุดท้ายแล้วการ Pull Request ก็จะง่ายขึ้น

ถ้า feature นั้นมันเล็ก กำหนดจำนวนและขนาดของแต่ละ task ที่ทำ คือ การแก้ไขปัญหาที่ต้นเหตุ ไม่ใช่ไปแก้ไขที่ปลายเหตุ เช่น ถ้า code มัน conflict กันมีเครื่องมืออะไรช่วยไหม !! เป็นต้น
คำถามคือ วันนี้คุณมีปัญหาเรื่องนี้อยู่หรือไม่ ? ถ้ามี คำถามคือ คุณแก้ไขที่ต้นเหตุหรือปลายเหตุกันแน่ ?
↧

สรุปเรื่อง Prevent Bugs จากหนังสือ Timeless Laws of Software Development

December 27, 2017, 3:56 am
$
0
0

ช่วงนั่งรอขึ้นเครื่องบินกลับบ้าน ได้อ่านเรื่อง Prevent Bugs เป็นบทที่ 5 จากหนังสือ Timeless Laws of Software Development จึงนำมาสรุปไว้นิดหน่อย น่าจะพอมีประโยชน์สำหรับนักพัฒนากันบ้าง
เริ่มต้นด้วยคำถามคือ นักพัฒนาชอบการสร้าง feature ใหม่ ๆ หรือทำการแก้ไข bug ? คิดว่าส่วนใหญ่ น่าจะชอบการสร้าง feature ใหม่ ๆ มากกว่านะ
แต่โชคไม่ดีเท่าไร ที่ bug มันเกิดขึ้นได้ตลอดเวลา ไม่พอนะ นักพัฒนาชอบซ่อน bug ไว้ เมื่อเวลาผ่านไปนาน ๆ จำนวน bug สะสมยิ่งเยอะ การมาแก้ไข bug ในภายหลังเป็นเรื่องที่ไม่สนุกเลย บางทีมมีช่วงเวลาสำหรับการแก้ไข bug เป็นสัปดาห์ด้วยนะ หรือถ้าทำงานเป็นรอบ ก็มักจะมีรอบของการแก้ไข bug ซึ่งคิดว่ามันไม่น่าจะเป็นทางที่ดีนะ !!

สาเหตุที่ทำให้มี bug จำนวนสูง ประกอบไปด้วย

  • เน้นความเร็วในการพัฒนามากกว่าความถูกต้อง (Deadline-Driven Development)
  • ชอบแก้ไข bug มากกว่าป้องกัน ยิ่งที่ไหนมีทีม tester/QA ยิ่งไม่ต้องสนใจเลย เดี๋ยวมีคนทดสอบให้
  • ไม่รู้ และ ไม่เรียนรู้วิธีการป้องกันไม่ให้เกิด bug
  • ขาดการวางแผนที่ดี
  • ขาดเทคนิคการทดสอบที่ดี
  • สถาปัตยกรรมของระบบงาน เอื้อต่อการสร้าง bug อย่างมาก
  • ขั้นตอนการพัฒนาที่แย่
  • การจัดการ priority ของงานที่ห่วย
  • สุดท้ายคือนักพัฒนานั่นเอง
ทำไมเราไม่ทำการป้องกันเพื่อไม่ให้เกิด bug หรือเกิดน้อย ๆ นะ ? การตามแก้ไข bug มันไม่สนุกเลย แถมไม่ได้เพิ่ม value และ productivity กันเลย
ดังนั้นมาเปลี่ยนแนวคิด แนวปฏิบัติกัน โดยเริ่มต้นด้วยการเรียนรู้วิธีการป้องกัน bug กันดีกว่า (Prevent Bugs)

1. เริ่มที่ตัวนักพัฒนาเองก่อน

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

2. นักพัฒนาไม่สนใจ warning ต่าง ๆ จากเครื่องมือที่ใช้งานเลย

ยกตัวอย่างเช่น IDE หรือ build tool มักจะทำการแจ้ง warning หรือคำเตือนต่าง ๆ ของ code ที่เราเขียนขึ้นมา พบว่านักพัฒนาส่วนใหญ่จะไม่สนใจ ปล่อยมันไป เพราะว่าแค่เตือน มันไม่ได้พังหรือ fail นะ แต่รู้ไหมว่า warning เหล่านั้นมันคือ error ที่จะเกิดขึ้นในอนาคตอันใกล้ !! ดังนั้นจงแก้ไขซะ
แต่ก็มีนักพัฒนาจำนวนไม่น้อย แก้ไขด้วยการ ignore/suppression ไป !! ไม่น่าจะดีเท่าไรนะ
บางทีมดีขึ้นมาคือ ตั้งค่า warning เป็น error ไปเลย แต่ทำอยู่ได้ไม่นานก็เปลี่ยนกลับ เพราะว่ามันเยอะเหลือเกิน !!

3. จัดการตรวจสอบ inputให้ดี

น่าจะเป็นสิ่งสำคัญมาก ๆ ของทุกระบบงาน เพื่อตรวจสอบว่า input ที่เข้ามาเป็นอย่างไร ตรงตามที่ต้องการหรือไม่ อาจก่อให้เกิดความเสียหายหรือไม่ แต่การตรวจสอบนั้น แนะนำให้ตรวจสอบตรง boudary ของระบบเท่านั้น ยกตัวอย่างเช่น REST API ในส่วนที่รับ request จากผู้ใช้งานนั้น อาจจะเป็นส่วนของ controller ดังนั้นก็ตรวจสอบในส่วนของ controller พอ ถ้า controller ไปเรียกส่วนอื่น ๆ เช่น service, model, repository แล้ว ก็ไม่จำเป็นต้องไปตรวจซ้ำอีกนะ มันเปลืองเวลา และ code ระหว่างการแจ้ง error ของ input กับป้องกัน input error เลือกอะไรดี ? เลือกยากนะ ถ้ามีทั้งส่วนของ Frontend และ Backend ดังนั้นทำทั้งสองส่วนเลย ระบบที่ดี user interface มันต้องใช้งานง่าย เป็นมิตรต่คนใช้งาน แถมต้องทำการตรวจสอบ input ให้อีกด้วย

4. ลด condition logic ต่าง ๆ ใน code ของระบบลงไปบ้าง

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

5. เน้นเรื่องของ user-define type หรือ abstraction layer ใน code

เน้นเรื่องของ readability เน้นเรื่องการลดข้อผิดพลาดจากความเข้าใจผิด รวมถึงการระมัดระวังการใช้งาน premitive data type ของภาษาโปรแกรมด้วย ในหนังสือยกตัวอย่าง code ชุดนี้ [code] double computeHydrostaticPresure() { } [/code] คำถามคือ method นี้ทำการ return ข้อมูลเป็นหน่วยอะไร ? ซึ่งก่อนให้เกิดความผิดพลาดจากความเข้าใจผิดได้ ขึ้นอยู่กับผู้นำไปใช้งานเลย ที่สำคัญ code ชุดนี้มาจากระบบงาน The NASA Mars Climate Orbiter และคนนำไปใช้งานแบบเข้าใจผิด ก่อให้เกิดความผิดพลาดตามมา ดังนั้นแทนที่จะเป็น double ก็ให้สร้าง user-defined type ขึ้นมาแทนดีกว่านะ อาจจะทำให้ code เยอะขึ้น มีความซับซ้อนมากขึ้น แต่สิ่งที่ได้มา code ที่อ่านเข้าใจได้ง่าย แถมลดความเข้าใจผิด หรือ สิ่งที่จะทำให้ผิดพลาดลงไปได้ มันก็น่าทำนะ
ลองทำไปปฏิบัติกันดูนะครับ น่าจะมีประโยชน์สำหรับนักพัฒนากันบ้าง
↧
Viewing all 1997 articles
Browse latest View live
Search