Modifiability Tactics

หากถามใครต่อใครว่า “อยากให้ระบบมีคุณภาพอะไรบ้าง?” เกือบ 100 เปอร์เซ็นต์จะตอบเป็นเสียงเดียวกันว่า “ประสิทธิภาพ” ซึ่งภาษาอังกฤษคือคำว่า performance ซึ่งคุณภาพด้าน performance มุ่นเน้นที่ความเร็ว อันเกิดจากการประมวลผลที่เร็วและการใช้ทรัพยากรได้ดีเยี่ยม เพราะผู้คนสนใจกันแต่ความเร็ว อยากได้ความเร็ว อยากให้ระบบทำงานเร็ว แต่ถ้ามันไม่เร็วดั่งใจล่ะ? อย่างน้อยกรณีที่เลวร้ายที่สุดก็ยังแก้ปัญหาทำให้มันเร็วได้ด้วย…เงิน…ใช่ไหม? ด้วยการทุ่มเงินลงไปที่ infrastructure… แบบที่องค์กรจำนวนมากนิยมชมชอบใช้วิธีการมักง่ายเช่นนี้

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

ผลกระทบระดับสถาปัตยกรรมเรียกว่า ‘Ripple Effect’ เหมือนการโยนหินลงน้ำ ผลกระทบจะแผ่เป็นวง กระทบไปยังส่วนต่างๆ มากมายหลายระดับชั้นได้ เปรียบเทียบเช่นการทุบกำแพงห้องตึกไม่พัง แต่ถ้าทุบเสาหลักของตึก…ตึกพัง! แก้หน้าจอระบบไม่พัง แต่ถ้าแก้ core mechanism หรือ core process ระบบ…บรรลัย!

หากอยากให้ระบบยืดหยุ่น เปลี่ยนแปลงได้สะดวก รวดเร็ว เท่าทันกับภาคธุรกิจที่เปลี่ยนแปลงไปมาเร็วปรู๊ดปร๊าด โดยเฉพาะองค์กรขนาดใหญ่ที่มักเกิดปัญหา ‘IT Bottle Neck’ เพราะภาคธุรกิจวิ่งไปไกล หรือจะเริ่มวิ่งแล้ว แต่ไอทียังต้วมเตี้ยม เทอะทะ ยุ่งเหยิง แก้นี่กระทบนั่น แก้นั่นกระทบโน่น เพราะระบบไอทีในองค์กรจำนวนมากก็เหมือนผังเมืองกรุงเทพฯ ที่วางไม่ดีมาตั้งแต่ต้น หลากหลายทั้งยี่ห้อ เทคโนโลยี เก่า ใหม่ ทำเอง ซื้อมา จ้างเขาทำ เอามาจากในโอเพ่นซอร์ส ไปจนถึงซื้อบ้าง เช่าบ้าง โอ้ย แค่คิดก็ปวดหัวละ

การออกแบบสถาปัตยกรรมซอฟต์แวร์หรือระบบไอที นั้นต้องมองไปยังอนาคตให้มากๆ ให้สอดคล้องกับแผนองค์กร และต้องเข้าใจธุรกิจองค์กรให้มาก จะได้ทราบว่าควรออกแบบสถาปัตยกรรมซอฟต์แวร์อย่างไรให้มันรองรับการเปลี่ยนแปลงทั้งปัจจุบันและโดยเฉพาะในอนาคตได้

tactic ด้าน modifiability นั้นถือว่าค่อนข้างยากมาก ผู้ออกแบบจำเป็นต้องมีพื้นฐานการออกแบบที่ดีมากๆ และเข้าใจเทคโนโลยีกับภาษาโปรแกรมที่จะใช้อย่างดี เพราะหากไม่ชำนาญจริง ประเภทรู้นิดๆ หน่อยๆ งูๆ ปลาๆ จะทำให้งานออกแบบ ‘หลุด’ ได้ง่าย หมายถึงเกิดช่องโหว่ด้าน modifiability นั่นเอง หลายคนอาจไม่ทราบว่าสิ่งเหล่านี้สำคัญ และหลายคนมักข้ามสิ่งเหล่านี้ไป…ไปสู่วิธีการที่ (มัก) ง่าย รวดเร็ว แก้ปัญหาเฉพาะหน้าได้เร็ว แต่อาจสร้างภาระในอนาคตมหาศาล… และหลายต่อหลายสถานการณ์ในหลายองค์กรจำนวนมากที่ผมพบเจอ… มีเงินก็แก้ไม่ได้… หลายองค์กรจึงจบโศกนาฎกรรมด้าน modifiability ด้วยการ replace… ซื้อใหม่ ทำใหม่ ติดตั้งใหม่… แล้วก็วนเป็นวัฎจักรน้ำเน่าซ้ำซาก หลายระบบผมเสียดายเงินแทนมาก บางระบบหลักร้อยล้าน หลักพันล้าน โดยเฉพาะระบบไอทีในองค์กรภาครัฐและรัฐวิสาหกิจ…เงินพวกกรูทั้งน้านนนน……..

มาดู modifiability tactic กันดีกว่าครับ…

Localize Modification คือ การ modify แบบจำกัดขอบเขตที่มีอิลิเม้นต์ที่คล้ายกันหรืออยู่ภายในกลุ่มเดียวกัน ได้แก่

Maintain Semantic Coherence

  • Maintain Semantic Coherence คือ การจัดการความหมายหรือหน้าที่ให้ชัดเจน อาทิ
    • การใช้ภาษา เช่น log in, log on, sign in, sign on ก็ควรเลือกใช้ให้เหมือนๆ กัน ไม่สร้างความสับสน
    • การกำหนดหน้าที่ เช่น create, persist, insert, delete, remove, update, edit ก็ควรระบุให้ชัดเจนว่าแต่ละ operation ทำหน้าที่ใดและควรใช้ในกรณีใด
    • เป็นต้น

Anticipate Expected Changes

  • Anticipate Expected Changes คือ การวางแนวทางรับมือกับการเปลี่ยนแปลงใดๆ ที่อาจเกิดขึ้นในอนาคต อาทิ หากมีการเปลี่ยนเวอร์ชั่นของไลบรารี่/เฟรมเวิร์กที่ใช้, การเปลี่ยนยี่ห้อ database server, การเปลี่ยน business logic เป็นต้น

Generalize the Module

  • Generalize the Module คือ หากมีหลายโมดูลที่ทำงานคล้ายกันให้แยกสิ่งที่เหมือนกันออกมาเพื่อลดความซ้ำซ้อน และนำโมดูลเหล่านั้นมาวางโครงสร้างแบบ Generalization-Specialization ที่เป็นแบบลำดับขั้น (Hierarchy)

Limit Possible Options

  • Limit Possible Options คือ การจำกัดทางเลือกที่อาจเพิ่มขึ้นในอนาคต ซึ่งนำมาซึ่งความหลากหลายจนจัดการยากกลายเป็นความซับซ้อนยุ่งเหยิง อาทิ จำกัดช่องทางในการเรียกใช้เซอร์วิส, จำกัดการอิมพลีเม้นต์ เป็นต้น นอกจากนี้เทคนิค Limit Possible Options ยังช่วยด้านความปลอดภัยด้วย เพราะหากมีทางเลือกเกิดขึ้นมากในอนาคต อาจกลายเป็นช่องโหว่ทางความปลอดภัยได้

 

Prevent Ripple Effects คือ การป้องกันผลกระทบที่อาจแพร่ไปยังส่วนต่างๆ ได้แก่

Syntax of Data and Service

  • Syntax of Data and Service คือ การกำหนดไวยากรณ์ของข้อมูลและเซอร์วิสให้ชัดเจนเป็นมาตรฐาน อาทิ data format, data type, operation specification เป็นต้น

Semantic of Data and Service

  • Semantic of Data and Service คือ การกำหนดความหมาย/หน้าที่ของข้อมูลและเซอร์วิสให้ชัดเจนเป็นมาตรฐาน อาทิ กำหนดความของคำว่า ‘ผู้ใช้’, ‘ลูกค้า’, ‘maintainXXX’ ให้ชัดเจน

Sequence of Data and Service

  • Sequence of Data and Service คือ การกำหนดลำดับขอข้อมูลและเซอร์วิสให้ชัดเจนเป็นมาตรฐาน อาทิ data flow ในการทรานแซกชั่น, ลำดับการประมวลผลทรานแซกชั่น เช่น 1) validation 2) prepare resource 3) begin transaction 4) execute transaction 5) commit/rollback transaction

Identity of an Interface of A

  • Identity of an Interface of A คือ อินเตอร์เฟสใดๆ ต้องมีแค่ตัวเดียว มีหน้าที่หลักเพียงหนึ่งเดียว (Modularity & Unity) ไม่ใช่มีคล้ายๆ กันหลายตัว มี operation ที่คล้ายคลึงกัน ทำให้ไคลเอ็นต์และทีมพัฒนาสับสนได้

Location of A

  • Location of A คือ อิลิเม้นต์ใดๆ ต้องมีที่อยู่แค่ที่เดียว อาทิ architectural layer, package, namespace, path ไม่ใช่มีหลายที่ทำให้เกิดความซ้ำซ้อน, ซับซ้อนส่งผลให้จัดการยาก และทำให้ไคลเอ็นต์และทีมพัฒนาสับสนได้

Existence of A

  • Existence of A คือ ความพร้อม (availability) ของอิลิเม้นต์ใดๆ ที่ควรระบุให้ชัดเจนว่าเมื่อใดมีหรือเมื่อใดไม่มี อาทิ เวอร์ชั่น 1 มีอิลิเม้นต์ A แต่เวอร์ชั่น 2 ไม่มี, checkout service ทำงานในช่วงเวลา 05:00-02:00 ปิดทำงาน 02:00-05:00 เป็นต้น เพื่อให้ไคลเอ็นต์ทราบจะได้ไม่เกิดความสับสน

Quality of Service/Data Provided by A

  • Quality of Service/Data Provided by A คือ ควบคุมระดับคุณภาพของการให้บริการและข้อมูลของอิลิเม้นต์ A อาทิ ทุกวันสุดท้ายของเดือนทรานแซกชั่นถอนเงินและฝากเงินจะมี response time ช้าลงจากเฉลี่ย 1 วินาที เป็น 2 วินาที, เมื่อ modify อิลิเม้นต์ A แล้วความพร้อมของข้อมูลจะเพิ่มสูงขึ้นและจะสามารถให้บริการข้อมูลปริมาณมากๆ ได้ดีกว่าเดิม เป็นต้น

Resource Behavior of A

  • Resource Behavior of A คือ การจัดการพฤติกรรมของทรัพยากร อาทิ database table A ให้บริการเฉพาะ insert กับ select เท่านั้น ห้าม update กับ delete เด็ดขาด, database table A ใช้สำหรับเก็บข้อมูลที่เกิดจากทรานแซกชั่นเป็นหลัก ห้าม process ใดเข้ามา query ข้อมูลเพื่อไปออกรายงานแบบ batch ในช่วงเวลา 08:00-17:00 เป็นต้น

Hide Information

  • Hide Information คือ ซ่อนสิ่งที่ไม่มีประโยชน์และไม่จำเป็นต่อไคลเอ็นต์ รวมถึงสิ่งที่ไม่ต้องการให้ไคลเอ็นต์ (รวมถึงทีมพัฒนาส่วนไคลเอ็นต์ด้วย) ได้รับรู้ อาทิ เทคโนโลยี, การอิมพลีเม้นต์, business logic, อัลกอริธึม เป็นต้น

Restrict Communication Paths

  • Restrict Communication Paths คือ จำกัดและเข้มงวดกับเส้นทางการสื่อสารระหว่างอิลิเม้นต์ต่างๆ ภายในระบบ ไม่ใช่จะพัฒนาอิลิเม้นต์ไหนให้ call อิลิเม้นต์ไหนก็ได้ตามใจ จะทำให้ไม่มีมาตรฐานและไม่มีระเบียบ อันจะก่อให้เกิดความซับซ้อนยุ่งเหยิง นำมาซึ่งการแก้ไขที่ยุ่งยาก อาทิ กำหนดว่าผู้ใช้ให้ติดต่อระบบผ่าน presentation layer ส่วนระบบภายนอกให้ติดต่อผ่าน service layer, request ที่ส่งมาจากส่วนหน้าจอฝั่งผู้ใช้ต้องผ่าน intercepting filter ทั้งหมดก่อนแล้วค่อยผ่าน front controller ก่อนถึงจะไปส่วนประมวลผล application logic เป็นต้น
  • Restrict Communication Paths คือ หลักการสำคัญมากสำหรับระบบขนาดใหญ่ ให้นึกถึงผังเมืองจังหวัดกรุงเทพฯ เมืองฟ้าอมรที่ผังเมืองเละเทะแย่มาก ยุ่งเหยิงมากๆ เพราะไม่ได้วางให้เป็นระเบียบและมีการควบคุมที่ดีมาตั้งแต่ต้น (ทั้งที่สมัย ร.5 ทรงเริ่มต้นมาอย่างดีแล้ว เช่น ถนนหนทางในสมัยนั้น) ด้วยความมักง่ายและการชอบแก้ปัญหาเฉพาะหน้ากรุงเทพฯ จึงมีตรอกซอยและถนนน้อยใหญ่เต็มไปหมด ท้ายที่สุดเมื่อแน่นมากก็เกิดสะพานน้อยใหญ่จนไปถึงทางด่วนมากมายพาดตัดกันไปมาอิรุงตุงนัง…

Use Intermediary

  • Use Intermediary คือ การใช้ตัวกลางเพื่อไม่ให้อิลิเม้นต์ติดต่อกันโดยตรง ซึ่งอาจมีการทำ mapping ระหว่างกัน มีหลายประเด็นได้แก่
    • Data (syntax) คือ การมีไวยากรณ์กลางของข้อมูล อาทิ format กลางสำหรับ customer id เพื่อให้ทำ mapping ระหว่างระบบต่างๆ ที่อาจใช้ format ของ customer id ต่างกัน
    • Service (syntax) คือ การมีไวยากรณ์กลางของเซอร์วิส อาทิ เมธอดกลางสำหรับเข้าสู่ระบบใช้ชื่อ ‘login’ ระบบใดไม่ใช้ก็ต้องทำ mapping
    • Identity of an interface คือ การมีอินเตอร์เฟสกลางที่มีหนึ่งเดียว อาทิ มีอินเตอร์เฟส CustomerService แค่ตัวเดียว จะเรียกใช้ operation อะไรเกี่ยวกับลูกค้าให้เรียกอินเตอร์เฟส CustomerService เท่านั้น
    • Location of A คือ อิลิเม้นต์ใดจะเรียกใช้อิลิเม้นต์ A ให้เรียกผ่านอิลิเม้นต์กลาง โดยอิลิเม้นต์กลางค่อยมาเรียกอิลิเม้นต์ A ให้
    • Existence of A คือ การตรวจสอบการมีอยู่ของอิลิเม้นต์ A ผ่านตัวกลาง
    • Resource behavior of A or resource controlled by A คือ การมีตัวกลางตรวจสอบพฤติกรรมของทรัพยากรหรือการควบคุมทรัพยากรของอิลิเม้นต์ A

 

Defer Binding Time คือ การเลื่อนการทำ Binding ออกไปจากซอร์สโค้ดหรือจากจุดที่ยังไม่เหมาะสม ซึ่งทำให้เมื่อต้องการ modify การ Binding จะได้ไม่ต้องแก้ไขซอร์สโค้ดหรือการทำงานในจุดนั้น ได้แก่

Runtime Registration

  • Runtime Registration คือ การทำ Binding ตอน runtime

Configuration

  • Configuration คือ การทำ Binding ในคอนฟิกกุเรชั่น

Polymorphism

  • Polymorphism คือ การออกแบบให้จุดนั้นเป็นแบบ Polymorphism อาทิ การเชื่อมโยงระหว่างไคลเอ็นต์กับอิลิเม้นต์ที่ต้องการเรียกเป็นแบบ Polymorphism ทำให้ไม่ต้องเรียกกันตรงๆ, การ Binding ให้ type ของตัวแปรเป็นคนละ type ของอ็อบเจ็คต์

Component Replacement

  • Component Replacement คือ การไม่ให้ไคลเอ็นต์เรียกใช้อิลิเม้นต์หรือส่วน implementation ของอิลิเม้นต์โดยตรง ทำให้เมื่อมีการ modify อิลิเม้นต์หรือส่วน implementation ของอิลิเม้นต์ก็จะไม่กระทบไคลเอ็นต์

Adherence to Defined Protocols

  • Adherence to Defined Protocols คือ การปฏิบัติยึดมั่นตามข้อกำหนดที่ระบุไว้ โดยไม่ทำ Binding ในช่วงเวลาที่ไม่อนุญาตให้ทำ อาทิ กำหนดให้ database username และ password ต้องระบุในไฟล์คอนฟิกกุเรชั่นเท่านั้น ห้ามระบุในซอร์สโค้ด, กำหนดให้ระบบเลือก child class ที่เหมาะสมกับประเภทไคลเอ็นต์เพื่อสร้างเป็นอ็อบเจ็คต์มาประมวลผลตามอินเตอร์เฟสที่ไคลเอ็นต์เรียก

 

Advertisements

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s