Hi, I’m STUPID

วันนี้อ่านเจอคำที่น่าสนใจคือ คำว่า 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 เข้ามาช่วยได้นะ !!

Tags:clean-code,SOLID,STUPID

อะไรคือ Minimum Viable Architecture

somkiat| November 11, 2014| Architecture |1 Comments

Like

68

3

Tweet

2

This page has been shared 2 times. View these Tweets.

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

News Feed

Follow

Twin Roofimon Panichsombat

• AgilePractitioner/KataMaru at Odd-e Thailand

 · 2 Mutual Friends

 · November 11 at 7:39am · Bangkok · 

เริ่มจาก ธรรมดาสามัญ จากนั้นค่อยๆเปลี่ยนไปตาม การใช้งาน "Minimum Viable Architecture" ของพวกเรา MVA ไหม http://www.infoq.com/news/2014/…/minimum-viable-architecture

An Introduction to 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 ครับ

Reference Websites
http://www.infoq.com/news/2014/11/minimum-viable-architecture
http://www.kavistechnology.com/blog/minimal-viable-architecture/
http://www.slideshare.net/RandyShoup/minimum-viable-architecture-good-enough-is-good-enough-in-a-startup
http://www.slideshare.net/johnb/minimum-viable-architecture-for-web-apps

Tags:architecture,mva