วันอังคารที่ 9 ธันวาคม พ.ศ. 2557

Extreme Programming :: ว่าด้วยเรื่อง 4 Core values

Extreme Programming :: ว่าด้วยเรื่อง 4 Core values

| April 8, 2014| Practice |2 Comments
Like
28
0
This page has been shared 1 times. View these Tweets.
ช่วงนี้กลับมาอ่านหนังสือ Extreme Programming(XP) อีกรอบ
พบว่าการอ่านรอบนี้สนุกและเข้าใจอะไรหลายๆ อย่างมากขึ้นบ้าง
พบว่ามีหลายสิ่งหลายอย่างที่เรามองข้ามไปเยอะมาก
ดังนั้น จึงเอามาสรุปเพื่อดูสิว่า เราเข้าใจมันมากขึ้นบ้างหรือไม่
โดยในหัวข้อแรกที่เปิดมาเลยก็คือ 4 core value ของ XP เลยแล้วกัน
ถ้าแปล core value น่าจะแปลว่า คุณค่าหลัก มั้ง !!! แต่เรียก core value ดีกว่า

ประกอบไปด้วย 4 ข้อ (มันก็ต้อง 4 ข้อสิ)
  • Communication
  • Simplicity
  • Feedback
  • Courage
มาดูกันว่าคุณค่าที่จะได้รับจาก XP programming นั้นเป็นอย่างไรบ้าง
1. Communication
ปัญหาของ project ส่วนใหญ่มากจากคนทำงานไม่พูดคุยกันในสิ่งที่จำเป็น หรือ การพูดคุยที่แย่
ตัวอย่างเช่น programmer ไม่ได้บอกใครเลย เมื่อมีการเปลี่ยนแปลงในเรื่องของการออกแบบระบบ
บางครั้งถามลูกค้าด้วยคำถามที่ไม่ถูกต้อง ทำให้สิ่งที่ทำถูกทิ้งไป
บางครั้ง manager ก็ถาม programmer ด้วยคำถามที่ไม่ถูก ทำให้การรายงานสถานะของ project ผิดไป
ใน XP นั้นช่วยทำให้การพูดคุย สื่อสาร ให้อยู่ที่ทิศทางที่ถูกต้อง ไม่สะเปะสะปะ
โดยมีแนวปฏิบัติต่างให้ ซึ่งต้องพึ่งการพูดคุยอย่างมาก จึงจะได้ผลที่ดี
ตัวอย่างเช่น
unit testing
pair programming
task estimation หรือการประเมินงาน
จากแนวปฏิบัติดังกล่าวช่วยให้ลูกค้า programmer และ manager ต้องพูดคุยในสิ่งที่ถูกที่ควร
2. Simplicity
ความเรียบง่าย นั้นมันไม่ง่ายเลย
มันเป็นสิ่งที่ยากมากที่คุณทำงาน โดยไม่ต้องไปคิดถึงอนาคตมากนัก
เนื่องจากในหัวของทุกๆ คน มีความกลัวอยู่มาก
แต่เมื่อคุณคิดมาก แล้ว cost จากการเปลี่ยนแปลงก็สูงมากตามเช่นกัน
ดังนั้นถ้าคุณพยายามคิดและทำแบบเรียบง่าย มันจะทำให้คุณแก้ไขง่าย
และใช้ cost ในการแก้ไขตามการเปลี่ยนแปลงน้อยลงไป
คุณจะเริ่มต้นสร้างระบบที่มีความซับซ้อนตั้งแต่เริ่มต้นพัฒนา
โดยหลายๆ อย่างมันก็ไม่เคยถูกใช้เลย
หรือจะเริ่มต้นจากความเรียบง่าย
ความเรียบง่ายและการพูดคุยกันนั้น มีความสัมพันธ์ต่อกัน ดังนี้
ถ้าพูดคุยกันมากหรือดีพอ ก็จะทำให้เห็นถึงความต้องการของลูกค้าที่ชัดเจน
รู้ว่างานจะเสร็จเท่าไร อย่างไร รวมทั้งสร้างความเชื่อมั่นต่อกัน
และถ้าระบบมีความเรียบง่ายแล้ว เวลามนการพูดคุยก็จะน้อยลงไป
ส่งผลให้การพูดคุยมีประสิทธิภาพสูงขึ้น
3. Feedback
คือสิ่งที่บอกสถานะปัจจุบันของระบบว่าเป็นอย่างไร
คือสิ่งที่ช่วยดูและรักษาสิ่งที่เราสนใจ
ใน XP นั้นได้เตรียม feedback ในทุกๆ ช่วงเวลา คือ
ในทุกๆนาที ให้เขียน unit testing ของการทำงานต่างๆ ในระบบ
โดยจะได้ feedback มาในทุกๆ นาทีกันเลย ว่าระบบยังทำงานได้อย่างถูกต้องตามที่คาดหวัง
ในแต่ละวันลูกค้าอาจจะส่ง feature มาให้ทีมเพื่อดู
ทางทีมก็จะทำการประเมินและพูดคุย เพื่อบอกว่า feature ที่ส่งมานั้นมีรายละเอียดและคุณภาพที่ดีหรือไม่
ซึ่งเป็น feedback ที่ดีสำหรับลูกค้าเช่นกัน
ในแต่ละสัปดาห์มีการเขียน functional testing เพื่อทดสอบ feature ต่างๆ ในระบบ
ดังนั้นก็จะรู้อยู่เสมอว่า ระบบยังทำงานถูกต้อง
รวมทั้งการ deploy นั้นต้องทำการ deploy บน production server เสียแต่เนิ่นๆ
เพราะว่าจะทำให้เราเจอปัญหาต่างๆ ได้อย่างรวดเร็ว นี่คือ feedback รูปแบบหนึ่ง
ไม่เช่นนั้นจะเจอเหตการณ์ Hell Deployment
Feedback ที่มีคุณภาพ ยิ่งมีมากเท่าไร ก็ยิ่งทำให้การพูดคุยมีคุณภาพมากขึ้นเท่านั้น
และการพูดคุยจะง่ายยิ่งขึ้น
ส่วนการสร้าง feedback ที่ดี ก็มาจากการคิดและทำที่เรียบง่าย เช่น
ถ้าระบบมันเรียบง่ายก็จะทำการเขียนการทดสอบง่าย
ทำให้เราสนใจการทำงานของระบบมากขึ้น
4. Courage 
ความกล้า ?
คุณกล้าแก้ไขระบบของคุณในช่วงใกล้ deadline ไหม ?
โดยคุณมาพบว่า ถ้าไม่แก้ไขนะ ระบบพังแน่ๆ !!
ปัญหานี้มันสะท้อนว่า
ระบบคุณมี feedback ที่แย่
ระบบคุณมีความซับซ้อน
การพูดคุยในทีมแย่
ดังนั้นเมื่อเราพบว่า มีสิ่งใดที่แย่ ก็ต้องกล้าที่จะพูดและทำ
รวมถึงกล้าเข้าไปแก้ไขปัญหานั้นให้หมดไปซะ
กล้าที่จะโยนหรือลบ code ทิ้งไป
แล้วพบว่ามันไม่ดี
ถึงแม้คุณจะใช้เวลาทั้งวันสร้างมันขึ้นมา
หรือถ้าพบว่า ระบบที่กำลังทำนั้นมันมีความซับซ้อนที่สูงขึ้นมากๆ
ควรกล้าที่จะพูดให้คนอื่นๆ ได้ทีมได้รู้
เพื่อให้เห็นปัญหาและทางแก้ไขร่วมกัน
ดังนั้นจะพบว่า core value ทั้ง 3 ข้อ จะส่งผลให้เกิดความกล้าต่างๆ ได้อย่างดี
โดยสรุปแล้วคุณค่าทั้ง 4 ข้อของ XP นั้นสัมพันธ์กันอย่างมาก
ถ้าขาดอย่างใดอย่างหนึ่งไป ต้องเสียบางสิ่งบางอย่างไปเช่นกัน

วันจันทร์ที่ 24 พฤศจิกายน พ.ศ. 2557

Hi, I’m STUPID

Screen Shot 2557-11-24 at 10.09.25 PM

วันนี้อ่านเจอคำที่น่าสนใจคือ คำว่า STUPID จึงนำมาขยายความ

ในโลกของการพัฒนาด้วย Object-Oriented Programming นั้น
มีแนวคิดเพื่อที่จะทำให้ code ที่เขียนขึ้นมานั้นมันมีคุณภาพที่ดี
เช่น SOLID, DRY(Don’t Repeat Yourself), Separation of Concern เป็นต้น
แต่มีแนวปฏิบัติกลุ่มหนึ่งที่ผิดปกติ แต่เรามักพบเจอกันมากจนเป็นเรื่องปกติ
ซึ่งสามารถรวบรวมมาอยู่ในชื่อที่เรียกว่า “STUPID”

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

STUPID มันคืออะไร ?

ย่อมาจาก
  • S = Singleton
  • T = Tight Coupling
  • U = Untestability
  • P = Premature Optimization
  • I = Indescriptive Naming
  • D = Duplication
มาดูกันว่าแต่ละเรื่องมันคืออะไร อย่างไรกันบ้าง

1. Singleton

เป็น Design pattern หนึ่งที่ได้รับคงามนิยมในการใช้งานอย่างมากมาย
แต่โชคร้ายว่า developer ส่วนใหญ่ไม่เข้าใจมัน และใช้มันในทางที่ผิด
เคยเจออาการที่เรียกว่า Singleton Syndrome ไหม ?
คือไม่ว่าจะยังไง อะไร ก็ใช้ Singleton มันไปเถอะ …
ซึ่งแบบนี้มันไม่ดีแน่นอน
การใช้งาน Singleton pattern นั้นมันไม่ใช่ปัญหา
แต่มันเป็นอาการอย่างหนึ่งของปัญหา
ยกตัวอย่างเช่น
  • การใช้งานตัวแปร global นั้นมันทดสอบยากมาก
  • การใช้งานตัวแปร global นั้นมันจะซ่อน dependency ต่างๆ
ดังนั้นจึงอยากให้หลีกเลี่ยงมัน
ลองเปลี่ยนอะไรก็ได้มาแทน Singleton ดูสิ code คุณจะดูดีขึ้น
ยิ่งถ้าใช้ Singleton มากเท่าไร ตัวแปรที่เป็น static จะมาก
และนั่นคือการทำให้ code มันผูกติดกันมากขึ้นนั่นเอง ( Tight coupling )

2. Tight Coupling หรือ Strong Coupling

การผูกมัดของ code ที่แน่นมากๆ
แน่นอนว่า ปัญหานี้มันก็มาจาก Singleton ด้วยเช่นกัน
ดังนั้น สิ่งที่เราทำได้ก็คือ ลดการผูกมักของ code
ด้วยการแบ่งเป็น module แยกกันไป
แต่ละ module ก็ทำงานแยกกันเป็นอิสระ
ผลที่ตามมาก็คือ เมื่อคุณแก้ไข code ใน module หนึ่งแล้ว
มันจะไม่กระทบต่ออีก module หนึ่ง
ซึ่งสามารถนำแนวคิดของ Dependency Inversion Principle มาช่วยได้
สิ่งหนึ่งที่แสดงว่า code ในระบบของคุณมัน Tight coupling ก็คือ
  • ยากต่อการ reuse
  • ยากต่อการทดสอบ

3. Untestability

code ที่เราเขียนขึ้นมานั้น ควรที่จะทดสอบได้ง่าย
วัดง่ายๆ ว่า code คุณทดสอบยาก หรือ ง่าย  ดังนี้
เมื่อไรก็ตามที่คุณบอกว่า
ฉันไม่เขียน unit test หรอกนะ เพราะว่าไม่มีเวลา
นั่นคือ คุณกำลังสร้าง code ที่ทดสอบได้ยาก
… ถ้าไม่เชื่อลองกลับไปดู code ได้เลย !!
code ที่คุณเขียนขึ้นมา โดยไม่มี unit test นั้น
มันทดสอบยาก เพราะว่า code ที่เขียนมันผูกติดกันแน่นมากๆ (Tight coupling)

4. Premature Optimozation

เรื่องนี้มันคือต้นเหตุของปีศาจ ที่ developer มักจะสร้างขึ้นมา
มันเป็นเรื่องของ ค่าใช้จ่ายที่ต้องเสียไป มากกว่าจะได้รับผลประโยชน์ที่ดีกลับมา
ในการ optimize code ตั้งแต่แรกนั้น มันจะสร้างความซับซ้อนของ code ขึ้นมาตั้งแต่แรกเริ่ม
สุดท้ายมักจบลงด้วยการได้ code ที่อ่านไม่รู้เรื่อง หรือ ทำความเข้าใจได้ยากมากๆ
และบ่อยครั้งวิธีการมันมักจะ anti-pattern ต่างๆ ไปอย่างสิ้นเชิง
ดังนั้น ขอแนะนำกฎ 2 ข้อ ในการ optimize code ตั้งแต่แรกเริ่ม มีดังนี้
  • ข้อที่ 1 อย่าทำ
  • ข้อที่ 2 อย่าเพิ่งทำตอนนี้

5. Indescriptive Naming

ใน code นั้นเรื่องของการตั้งชื่อที่ไม่สื่อ พบเห็นได้บ่อยมากๆ
ทั้งชื่อ file, class, function/method, variable ต่างๆ
แนะนำง่ายๆ ว่าอย่าใช้ตัวย่อนะ
จำง่ายๆ ว่า คุณเขียน code ให้คนอ่าน ไม่ใช่ให้เครื่อง นะครับ
ดังนั้น developer/programmer คือการ programming สำหรับคน นะครับ
"
แนำนำให้อ่านเรื่อง Clean code ครับ

6. Duplication

code ที่มันซ้ำซ้อน คือ สิ่งที่แย่มาก
ดังนั้นสิ่งที่คิดไวเสมอในการเขียน code คือ
  • DRY (Don’t Repeat Yourself) อย่าทำซ้ำ
  • Keep It Simple Stupid (KISS) ทำในสิ่งที่เรียบง่าย
  • Once And Only Once
ให้หัดเป็นคนที่ขี้เกียจอย่างถูกทางและถูกต้อง
บางเรื่องก็ไม่ต้องขยันมากก็ได้ เช่นการเขียน code เดิมซ้ำๆ

มาถึงตรงนี้

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

วันพุธที่ 12 พฤศจิกายน พ.ศ. 2557

อะไรคือ Minimum Viable Architecture


อะไรคือ Minimum Viable Architecture

| November 11, 2014| Architecture |1 Comments
Like
68
3
This page has been shared 2 times. View these Tweets.
Screen Shot 2557-11-11 at 5.50.23 PM

บทความที่น่าสนใจซึ่งพี่ @roofimon ทำการ share มาที่ facebook

News Feed

เริ่มจาก ธรรมดาสามัญ จากนั้นค่อยๆเปลี่ยนไปตาม การใช้งาน "Minimum Viable Architecture" ของพวกเรา MVA ไหม http://www.infoq.com/news/2014/…/minimum-viable-architecture
This post describes the minimum viable architecture for developing minimum viable product. It includes the architecture specification in different phases of startup.
INFOQ.COM
Share · 1944
ดังนั้นในฐานะที่เป็น developer คนหนึ่ง จึงต้องทำการศึกษาหน่อยว่า มันคืออะไร
มีความน่าสนใจอย่างไร เพื่อจะได้ไม่ตกกระแส
และทำให้เข้าใจว่ามันเกิดขึ้นมาเพื่อแก้ไข หรือ ช่วยอะไรเราบ้าง

ทำความรู้จัก

คำที่มักได้ยินก็คือ MVP (Minimum Viable Product)
ช่วยให้สามารถเลือกได้ว่า จะต้องทำอะไรที่สำคัญและมีคุณค่าก่อน
เพื่อส่งมอบให้ลูกค้าหรือผู้ใช้งานให้รวดเร็วที่สุด
ทำให้ลดทั้งเวลาในการพัฒนา และ ค่าใช้จ่ายที่ต้องลงทุนไป
แต่สิ่งหนึ่งที่ต้องให้ความสนใจไม่น้อยกว่า MVP
นั่นคือเรื่องของ Architecture ที่จะต้องมีเท่าที่จำเป็นเท่านั้น
ซึ่งถูกเรียกว่า Minimal Viable Architecture (MVA)
เนื่องจากจะพัฒนา MVP ได้รวดเร็วได้อย่างไร
ถ้า architecture มันซับซ้อนตั้งแต่เริ่มต้น !!

แล้วทำไมต้องให้ความสำคัญด้วยล่ะ ?

เนื่องจากปัญหาที่มักพบเจอมากๆ สำหรับการพัฒนา product ที่เลือกมาจาก MVP นั้น
คือ การเลือก architecture ที่ไม่เหมาะสม
ตัวอย่างเช่น
ทีมมักจะใช้เวลาเป็นสัปดาห์ เป็นเดือน สำหรับการออกแบบ วางแผน และ พัฒนา
ในสิ่งที่ไม่ได้ลูกค้า และ ผู้ใช้งาน ไม่สามารถจับต้องได้
หรือตรงๆ คือ ไม่ได้มีประโยชน์โดยตรงนั่นเอง
ซึ่งทำให้ได้ feedback ที่ช้ามากๆ นั่นไม่น่าจะใช่แนวทางที่ถูกต้อง
ดังนั้น เราต้องสร้างความสมดุลระหว่าง speed to market และ architecture ของระบบงาน
นั่นคือเราต้องการ Minimal Viable Architecture (MVA) นั่นเอง
จาก blog เรื่อง Minimum Viable Architecture ได้ทำการแนะนำคำถาม
เพื่อใช้สอบถามเจ้าของ requirement หรือ Product Owne
เพื่อช่วยทีม และ architect  เตรียม MVA ได้ง่ายขึ้น มีดังต่อไปนี้
  • เมื่อระบบเปิดใช้งาน คาดว่าจะมีผู้ใช้งานเท่าไร
  • เมื่อเปิดระบบไป 6 เดือน คาดว่าจะมีผู้ใช้งานเท่าไร
  • เมื่อเปิดระบบไป 1 ปี คาดว่าจะมีผู้ใช้งานเท่าไร
  • คาดว่าจำนวน transaction ต่อ วินาที จะเป็นเท่าไร เมื่อทำการเปิดตัว ภายใน 6 เดือน หรือ 1 ปี
  • ระดับของความปลอดภัยที่ต้องการของระบบ
คำถามเหล่านี้เพื่อช่วยให้ทีมพัฒนาไม่ต้องไปทำอะไรมัน over เกินไป
หรืออาจจะเรียกว่า Over-engineering ตั้งแต่แรก
เนื่องจากการสร้างระบบที่มัน perfect ตั้งแต่แรกก็ไม่ใช่ทางที่ดีนัก !!
ตัวอย่างเช่น
เมื่อทำการพูดคุยรายละเอียดเรื่องจำนวนผู้ใช้งานแล้ว อาจจะได้ว่า
ในช่วงเดือนแรกมีผู้ใช้งานจากภายในเท่านั้น เพื่อทำการ setup ระบบต่างๆ
ช่วง 3 เดือนเริ่มให้ผู้ใช้งานกลุ่มแรกเข้ามาใช้งาน
ช่วง 6 เดือนทำการเปิดระบบให้ผู้ใช้งานทั่วไปใช้งาน
หรือจำนวน transaction การใช้งานจะค่อยๆ เพิ่มขึ้นในแต่ละเดือน
เช่น ใน ช่วงเดือนแรกจำนวน transaction จะยังน้อยมากๆ
แต่ในช่วง 3 เดือนจะสูงขึ้น
และในช่วง 6 เดือนจะสูงมากๆ
หรือในช่วงเดือนแรกคือ alpha release เพื่อทำการศึกษา และ เรียนรู้ ระบบและผู้ใช้งาน
ช่วง 3 เดือน เริ่มให้ผู้ใช้งานกลุ่มแรก เข้ามาใช้งานจริง
ช่วง 6 เดือน จึงเปิดให้ใช้งานทั้งหมด
หรือในช่วงเดือนแรกทาง IT จะเป็นฝ่ายเพิ่มข้อมูลผู้ใช้งานแบบ manual
ช่วง 3 เดือน เริ่มมี user interface สำหรับให้ฝ่าย operation ทำการเพิ่มผู้ใช้งานได้
ช่วง 6 เดือน ผู้ใช้งานสามารถสมัคร และ เพิ่มข้อมูลได้เอง
หรือในช่วงเดือนแรก อาจจะมีเรื่อง security บ้างแต่ยังไม่มาก (Basic security)
ช่วง 3 เดือนทำการเน้น security ในทุกๆ ส่วน
ช่วง 6 เดือนทำการ audit ระบบ security
จากคำตอบเหล่านี้ มันทำให้เรารู้ว่าในช่วงแรกๆ นั้นควรทำอะไรก่อน เน้นอะไร นั่นคือ สนใจการส่งมอบงานให้รวดเร็ว (time to market)
เพื่อสร้างความเชื่อมั่นของฝ่าย IT กับทางฝ่าย business
เมื่อมีความเชื่อมั่นซึ่งกันและกันแล้ว ต่อจากนั้นจึงเริ่มพัฒนาในส่วนอื่นๆ ต่อไปจะง่ายขึ้น
ลองคิดดูว่า ถ้าฝ่ายพัฒนา หรือ IT ไม่สามารถส่งมอบได้ตรงตามเวลา
เพราะว่า ติดปัญหาภายในกันเอง เช่น Architecture ของระบบยังไม่ดีพอ
แล้วอะไรจะเกิดขึ้น หนึ่งในนั้นคือ ความเชื่อมั่น และ ไว้ใจ ไม่มีเลย
ดังนั้น MVA จึงมีความสำคัญขึ้นมา พอสมควรนะ

หัวใจของ Minimum Viable Architecture ประกอบไปด้วย

  • YAGNI (You Ain’t Going to Need It) ทำเท่าที่จำเป็นเท่านั้น
  • เลือกใช้เครื่องมือให้เหมาะสมกับงาน และ ถูกที่ถูกเวลา
  • การเปลี่ยนแปลงต้องเกิดขึ้นตลอดเวลา แต่เป็นแบบเล็กๆ ไปเรื่อยๆ
เมื่อนำไปเทียบกับ phase ทำการงานของ Startup แล้วเป็นดังนี้
  • Search  คือ การทำ prototype ของ architecture ที่จะนำมาใช้งาน มีเป้าหมายเพื่อหาสิ่งที่สร้างได้อย่างรวดเร็ว ในราคาที่สมเหตุสมผล
  • Execution คือ การตรวจสอบเพื่อทำให้แน่ใจว่า architecture นั้นมันเพียงพอต่อความต้องการอันใกล้ และสามารถปรับปรุงไปตามความต้องการได้ นั่นคือ Just Enough Architecture นั่นเอง
  • Scaling เป้าหมายเพื่อให้สามารถรองรับการขยายตัวของธุรกิจได้ ซึ่งประกอบไปด้วย ทีม เทคโนโลยี และ ประสิทธิภาพการรองรับผู้ใช้งาน ซึ่งทำแบบค่อยเป็นค่อยไป ไม่ใช่ทำทุกอย่างเผื่อไว้ทั้งหมด ไม่ใช่เพียงให้ความสนใจกับเรื่องเทคโนโลยีอย่างเดียวนะ

สิ่งที่น่าสนใจ คือ Execution phase

คือ Just Enough Architecture มีลักษณะดังนี้
  • Modularity หรือ Monolithic Architecture ซึ่งทำให้ง่ายต่อการเพิ่มหรือลดความสามารถของระบบงาน
  • มีระบบ logging ทั้งในแง่ของพฤติกรรมการใช้งานของผู้ใช้งาน และ minitoing ของระบบ
  • มีระบบ Continuous Delivery เพื่อให้สามารถ deploy ระบบงานได้บ่อยตามที่ต้องการ
ซึ่งมี infrastructure ที่พอเพียงกับความต้องการ
และจำเป็นต้องมีระบบ Continuous Delivery
เพื่อให้สามารถ deploy ระบบงานได้บ่อยตามที่ต้องการ
โดย architecture แบบนี้มันมีข้อดีดังนี้
  • เริ่มต้นด้วยความเรียบง่าย อย่าเยอะ
  • ทำแบบค่อยเป็นค่อยไป
  • Single codebase และ ทำการ deploy แบบย่อยๆ หรือเป็นส่วนเล็กๆ ได้
  • ใช้งาน resource ต่างๆ อย่างมีประสิทธิภาพ
ง่ายๆ ลองกลับไปดูว่าระบบที่คุณพัฒนาหรือดูแลอยู่ว่าเป็นอย่างไร ?
ถ้าระบบของคุณมีลักษณะดังต่อไปนี้ ก็น่าจะได้เวลาปรับเปลี่ยน หรือ ปรับปรุงนะครับ
  • ในการขยายระบบ มีส่วนที่เกี่ยวข้องจำนวนมาก นั่นคือ overhead ที่เสียไป ทั้งเวลาและค่าใช้จ่าย
  • ระบบไร้ซึ่งความเป็น modularity นั่นคือระบบผูกกันไปหมด
  • แย่ต่อการขยายระบบ ส่วนใหญ่มักจะทำแบบ vertical เป็นหลัก
  • ใช้เวลาในการ deploy ระบบงานนานมาก ทั้งการ rollout และ rollback
  • ใช้เวลาในการ build นานมาก
และทางคุณ Martin Fowler ก็ได้เขียนเกี่ยวกับแนวคิดของ Sacrificial Architecture
ซึ่งมันยังคงอยู่ในบริบทของ Just Enough Architecture นั่นก็คือ
The best code you can write now is the code you will discard in a couple of years time.
"
แปลได้ว่า code ที่คุณคิดว่ามันสุดยอดในตอนนี้ มันอาจจะถูกเลิกใช้ไปในเวลา 1-2 ปีเท่านั้น

โดยสรุปแล้ว

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