Tour de France #3: Object-Oriented #1

Software Development Life Cycle

    มาถึง Tour de France เรื่องสุดท้าย เรื่อง Object-Oriented เรื่องนี้ค่อนข้างยาว มันเป็นแนวคิดในการเขียนโปรแกรมที่มีมานานแล้ว แต่ดูเหมือนว่าคนที่รู้จักมันจริงๆ มีค่อนข้างน้อย ผมเลยถือโอกาส แนะนำให้รู้จักก็แล้วกัน

    ก่อนที่เราพูดถึง Object-Oriented ผมว่าเราน่าจะมาย้อนดูพัฒนาการของมันซักเล็กน้อย

ศาสตร์ในแก้ปัญหาความซับซ้อนของโปรแกรม

    เราเริ่มต้นที่ Digital Computer ที่มีมาตั้งแต่ยุคปี 40 ในยุคนั้นนับว่าเป็นจุดเริ่มของการเขียนโปรแกรม แนวคิดแรกในการจัดการความซับซ้อน นั่นก็คือ Function และนั่นเป็นที่มาของ Funtional Decomposition

1) Functional Decomposition (Algorithmic Decomposition)

    Functional Decomposition ใช้แนวคิดของฟังก์ชันมาเป็นประโยชน์ เมื่อเจอความซับซ้อนเกิดขึ้น ก็จะแบ่งเป็นฟังก์ชันย่อย ถ้าฟังก์ชันย่อยนั้น ยังซับซ้อน ก็จะแบ่งย่อยของย่อยอีก ไปเรื่อยๆ จนกระทั่งสามารถควบคุมมันได้ เราเรียกวิธีนี้ว่า Divide and Conquer ซึ่งภาษา Pascal ถือได้ว่าเป็นแม่แบบของแนวคิดแบบนี้ แนวคิดนี้โด่งดังมากในยุคปี 70 ครับ

    เครื่องมือที่ช่วยในการพัฒนา Software แบบนี้คือ Flowchart ครับ

2)  Data Flow Approach

    ในงานที่ซับซ้อนขึ้น การใช้ Functional Decomposition เป็นสิ่งที่ไม่เพียงพอแล้ว แนวคิดใหม่ ในการพัฒนาแทนที่มอง Code เป็นหลัก กลับมองที่การไหลของข้อมูลเป็นหลัก เราแบ่งงานออกเป็นหน่วยๆ โดยดูจากข้อมูล จากนั้นก็เชื่อมแต่ละหน่วยเข้าด้วยกัน โดยดูจากการไหลของข้อมูล ดังนั้นเครื่องมือที่ใช้เป็นหลักนั้นก็คือ Data Flow Diagram (DFD) แนวคิดนี้มีการใช้กันมากในยุคปี 80 ครับ

3) Information Approach (Data-Oriented Decomposition)

    ในยุคปี 90 เครื่องคอมพิวเตอร์ตามบ้านมีความสามารถมากขึ้น ดังนั้นฐานข้อมูลขนาดใหญ่ จำพวก SQL Server ซึ่งเคยใช้แต่บนเครื่องขนาดใหญ่ กลับสามารถใช้งานได้บนเครื่องราคาถูกๆ ดังนั้น Data Flow Approach อาจจะไม่สามารถรองรับงาน ได้อย่างเพียงพอ ดังนั้นจึงมีการนำเอา Entity-Relationship Diagram (ER Diagram) มาปัดฝุ่น แล้วนำมาใช้เป็นตัวหลักในการ Decomposition

4) Object-Oriented Decomposition

    แนวคิดของ ER Diagram ถูกนำไปปรับปรุง โดยแทนที่จะรองรับเพียงข้อมูลแต่อย่างเดียว กลับเพิ่ม Code เข้าไปหุ้มตัวข้อมูลด้วย ซึ่ง มันก็เป็นเรื่องที่เราจะมาคุยกันในบทความนี้ แนวคิดนี้เริ่มนิยมมากในกลางยุค 90 ครับ

พิจารณาแนวคิดของการ Decomposition ทั้ง 4 แบบ

    ก่อนอื่นผมคงต้องพูดว่า แนวคิดที่ใหม่ขึ้นในการ Decomposition ไม่ใช้ว่าจะมาทดแทนแนวคิดเดิม แต่หากแนวคิดใหม่ ใช้เป็นด่านหน้าในการชนความซับซ้อน จากนั้นก็ใช้วิธีเดิมๆ ในการแบ่งระดับที่ละเอียดขึ้น  ยกตัวอย่างเช่น เมื่อเราใช้ Data Flow Approach ในการแบ่งเป็นส่วนๆ แล้ว แต่ละส่วนก็จะถูกแบ่งโดยใช้ Functional Decomposition อีกที ดังนั้นแนวคิดใหม่กว่า จึงใช่การปฏิวัติแนวคิด แต่หากเป็นการพัฒนาที่สั่งสมมานั่นเอง

    ตามประสบการณ์ของผมที่ได้พูดคุยกับคนที่รู้จัก พบว่า มีไม่น้อยที่ยังใช้ Data Flow Approach อยู่ และใช้ ER Diagram เป็นตัวทำ Decomposition ที่ 2 ผมแทบไม่เห็นใครใช้ ER Diagram ยุคปรับปรุงเป็น Decomposition หลัก (ตามประสบการณ์ของผมเองเท่านั้นนะครับ)

วิวัฒนาการ Object-Oriented

    ดูเหมือนว่าแนวคิดของ OO เพิ่งได้รับความนิยมภายใน 4-5 ปีที่ผ่านมานี้เอง แต่ที่จริงแล้วกำเนิด OO นั้นมีมากว่า 30 ปีแล้วครับ แต่โชคร้ายหน่อย ที่แนวคิดเชิง OO นั้นเป็นแนวคิดที่เข้าใจไม่ได้ง่ายนัก เท่านั้นยังไม่พอ OO เองก็ไม่ค่อยมีมาตรฐาน ทำนองว่าสำนักใครสำนักมัน ยิ่งทำให้เรียนรู้ยากเข้าไปอีก แต่พอมาปี 1995 มาตรฐานเริ่มก็ตัว ทำให้การเรียน Object-Oriented นั้นง่ายขึ้น เรามาลองดูพัฒนาการของ OO กันหน่อยดีกว่า

กำเนิด Object-Oriented

    Object-Oriented เกิดมานานมากแล้ว ตั้งแต่ปี 1967 อาจจะก่อน Data Flow Approach เสียอีก ในปีนั้น ที่สถาบัน Norwegian Computing Centre (NCC) ของ Norway นักวิทยาศาสตร์ 2 คนคือ Ole-Johan Dahl และ Kristen Nygaard สร้างภาษาคอมพิวเตอร์ที่ชื่อว่า SIMULA I เสร็จแล้ว ภาษานี้เป็นภาษาที่ออกแบบมาเพื่อการทำ Simulation มีใช้กันพอสมควรที่ยุโรปตอนบน

    ในปี 1967 นั้นเองทั้ง 2 เริ่มมีฝันใหม่ ฝันที่จะออกแบบภาษาคอมพิวเตอร์ที่ไม่ผูกติดกับการใช้งาน สามารถรองรับงานได้ทั่วไป ซึ่งในยุคนั้น การออกแบบภาษาหนึ่งภาษาใดต้องผูกกับเป้าหมายในการใช้งานนั้นยังไม่มี มีแต่ผูกกับเป้าหมายเช่น FORTRAN และ ALGOL สำหรับงานคำนวณทางวิทยาศาสตร์, COBOL ใช้ทางธุรกิจ หรือ LISP ใช้ในด้าน AI เป็นต้น ทั้งสองนำเอาภาษา SIMULA I มาปรับปรุงโดยมองว่าสิ่งต่างๆ เป็นวัตถุ และไม่ใช้วัตถุธรรมดา วัตถุต่างๆ สามารถจัดกลุ่มได้อีกซึ่งเป็นสิ่งที่ Generic กว่า ซึ่งมันก็คือแนวคิดของการทำ Inheritance นั่นเอง ผลลัพธ์ออกมาคือ SIMULA 67 ซึ่งสอนให้โลกรู้จัก class, Inheritance และ Dynamic Binding แต่น่าเสียดายที่ภาษานี้ไม่ได้รับความนิยม ถึงแม้ว่าทั้งสองจะปรับปรุง SIMULA 67 สร้างเป็นภาษาใหม่ที่ชื่อว่า BETA แล้วก็ตาม ก็ไม่ได้รับความนิยมอยู่ดี

Smalltalk กับ OO เต็มรูปแบบ

    ที่ Xerox ประมาณปลายยุค 70 มีการออกแบบภาษาใหม่ที่รองรับ OOP เต็มรูปแบบ โดยภาษาใหม่นี้ เอาแนวคิดของ SIMULA 67 มาผสมกับ LISP ผสมกับความสามารถของ Graphics ซึ่ง Graphic แบบ Smalltalk นี้เองเป็นต้นแบบให้กับ GUI OS ของ Apple Lisa และ Gui OS ของ Apple Lisa ก็เป็นต้นแบบของ Microsoft Windows ที่เราใช้อีกที

    ภาษา Smalltalk จัดได้ว่าเป็นภาษาที่มี Productivity สูงมาก เขียนสั้นกระทัดรัด และ OOP เต็มรูปแบบ แต่ในยุคนั้น ภาษา SmallTalk ไม่ค่อยดังเพราะว่ามันต้องการกำลัง Hardware ที่สูงมาก เพราะทุกอย่างเป็น Graphics แต่ปัจจุบันมีคนใช้อยู่ไม่น้อย บรรดาปรมาจารย์ด้าน OO ในยุคปัจจุบัน มีไม่น้อยครับที่เป็น Programmer ภาษา SmallTalk มาก่อน ภาษา Smalltalk สอนให้โลกรู้จัก Garbage Collection ด้วยครับ

    หลังจากภาษา Smalltalk แล้ว ก็มีภาษา ดังๆ ออกมาหลายตัวเช่น C++, CLOS, Eiffel เป็นต้น แต่ตัวที่ดังที่สุดคือ C++ ซี่งเป็นต้นแบบของ Java และ C# ที่เราใช้ในยุคปัจจุบัน

วังวนของ OO

    OOP นั้นเริ่มสมบูรณ์ตั้งแต่ต้นปี 80 จาก SmallTalk แต่ในยุคนั้น OOP มันเป็นเพียงแค่ของเล่นใหม่เท่านั้นครับ ยังไม่ค่อยมีคนที่สามารถดึงเอาความสามารถของมันออกมาใช้ได้ แต่พอมายุคกลางปี 80 แนวคิดทาง OO ได้เริ่มพัฒนาขึ้นอีกก้าวหนึ่ง ไม่ใช่เป็นเพียงแค่ของเล่นแล้วนะครับ มีผู้เชี่ยวชาญหลายคน ที่พยายามหาหลักการในการออกแบบโปรแกรมโดยใช้ภาษาทาง OOP หลังจากค้นคิดกันมาตั้งแต่ปลายปี 70 พอมายุคกลางปี 80 นี้ทฤษฏีต่างๆ ก็เริ่มเป็นรูปเป็นร่าง แต่ความนิยมก็ยังน้อยอยู่ครับ เพราะ OO มีความซับซ้อนสูง ไม่ง่ายเหมือน Dataflow Approach

    พอมาถึงต้นปี 90 เราจะเห็นว่ามีหลายสำนักเลยครับที่เกิดขึ้น ที่ดังๆ ก็มี Coad-Yourdon, Booch, Jacobson, Shlaer/Mellor, Rumbaugh และ Martin/Odell เป็นต้น ต่างคนต่างหาสูตรในการพัฒนา OO ไม่เหมือนกัน แต่สิ่งหนึ่งที่เห็นตรงกันก็คือ นอกจาก OOP ซึ่งหมายถึงการรองรับ OO ของภาษาโปรแกรมแล้ว ยังน่าจะต้องแบบออกมาเป็นอีก 2 ส่วนคือ OOA และ OOD ครับ (แต่รายละเอียด OOA และ OOD ของแต่ละคนก็ต่างกันครับ)

OOA

    OOA หรือ Object-Oriented Analysis คือหลักการที่เราใช้ในการเก็บ Requirement ของ ผู้ใช้ ซึ่งอย่างหนึ่งที่ต้องกล่าวถึงก็คือ ทีมพัฒนาโปรแกรมทั่วไปมีจุดอ่อนที่เหมือนๆ กันก็คือ ไม่เข้าใจในเนื้องานที่ตัวเองกำลังสร้างขึ้น ถ้าในแง่การเขียนโปรแกรมก็คงเก่งครับ แต่ถ้าเนื้องานที่ต้องพัฒนาก็คงไม่เก่งนัก ยกตัวอย่างเช่น ถ้าเกิดจับผลัดจับผลูต้องไปทำงานเขียนโปรแกรมติดต่อกับดาวเทียม จะมีซักกี่คนครับที่เคยเขียนโปรแกรมแบบนี้มาก่อน ดังนั้นการเก็บข้อมูลจึงถือว่าเป็นศาสตร์อย่างหนึ่ง ซึ่ง OO เข้าไปช่วยได้มากครับ

OOD

    OOD หรือ Object-Oriented Design เมื่อเราผ่านขั้นตอน OOA มาแล้ว เราเอาผลลัพธ์ที่ได้มาออกแบบ ซึ่งศาสตร์นี้เรียนกันไม่จบครับ ลำพังการเขียนโปรแกรมแบบ OOP นั้น ที่ยากไม่ใช่อยู่ที่การเขียนครับ มันยากที่ตอนออกแบบ ถ้าออกแบบพลาด ก็เสียหายไปเลย แต่ OO มีหลักการหลายอย่างที่ช่วยให้เราไม่บาดเจ็บขนาดนั้นครับ

    ปรมารย์บางคนก็คิดเฉพาะขั้น OOA, OOD อย่างใดอย่างหนึ่ง แต่บางคนกลับคิดวงจรการพัฒนา Software แบบ OO กันแบบครบวงจร แต่ปัญหามีอยู่ว่า ต่างคนต่างคิดครับ ทำให้ OO ซึ่งเป็นเรื่องเดียวนี้ แต่ออกได้เป็นหลายแบบ ขึ้นอยู่กับว่าเราจะอ้างอิงอยู่กับสำนักไหน ซึ่งเรื่องนี้วุ่นวายมาก

กำเนิด UML

    ในปี 1989 บริษัท Hardware ต่างๆ เช่น Sun และ HP รวมตัวกันสร้าง OMG ขึ้นมาเป็นหน่วยงานอิสระในการกำหนดมาตรฐาน ซึ่งมุ่งเน้นไปที่การเชื่อม Software กันผ่าน Network โดยให้เป็นอิสระต่อ Platform ผลลัพธ์ก็คือ CORBA ครับ ในระหว่างนั้นก็มีการพยายามวางมาตรฐานสำหรับแผนภูมิที่ใช้ในการออกแบบ Object-Oriented ซึ่งถ้าทุกคนวาดแผนภูมิออกมาแนวเดียวกัน จะทำให้การสื่อสารเป็นไปได้โดยง่ายครับ

    ในยุคนั้นอย่างที่ผมเล่าให้ฟังว่า มีหลายสำนักมากครับ แต่ละสำนักก็คิดค้นแผนภูมิของตัวเอง ลองหาหนังสือเก่าๆ อ่านดูสิครับ ปวดหัวน่าดูเลย OMG เลยประกาศแข่งขันหามาตรฐาน (ทำนองเดียวกันกับ NSA ประกาศแข่งขันหา Algorithm ในการเข้ารหัสทดแทน DES) ซึ่งบรรยากาศในยุคนั้นค่อนข้างเครียดครับ มีครั้งหนึ่งที่ Grady Booch จากบริษัท Rational แอบล๊อบบี้ OMG ให้ยอมรับรูปแบบของตัวเองเป็นมาตรฐาน ซึ่งก็ไม่สำเร็จ และครั้งนั้นเองที่เป็นที่มาของสำนวนที่ว่า "Methodologist กับผู้ก่อการร้ายต่างกันตรงที่ว่า ผู้ก่อการร้ายนั้นต่อรองได้" ผมเองก็ไม่ทราบว่า ในวันนั้นเขาคุยอะไรกัน แต่ลองวิเคราะห์เล่นๆ ดูนะครับ แผนผังของ Booch นั้นยืมมาจาก Intel ครับ Intel เคยออกแบบ CPU และใช้แผนผังเป็นรูปเมฆ ผมเองก็เคยใช้แผนผังแบบ Booch ในบางบทบน Web Site นี้เหมือนกัน จุดอ่อนของ แผนผังแบบ Booch คือเน้นที่ช่วง OOD ต่อกับ OOP ไม่ได้เน้นช่วง OOA ผมว่านี่คือจุดอ่อน ที่ OMG อาจจะไม่รองรับเพราะความไม่ครบถ้วนนี้ก็ได้

    จากนั้น Booch จึงรวมตัวกับ James Rumbaugh ผู้คิดค้น OMT  (หน้าตาของ OMT บางส่วนก็คล้ายกับ ER Diagram) ซึ่งถ้ารวมกันสำเร็จก็น่าจะครบถ้วนมากขึ้นพอส่งประกวดได้ Booch ประกาศกลางงานสัมมนา ถ้าผมจำไม่ผิดคือ OOPSLA ปี 94 ว่า "สงครามสิ้นสุดแล้ว เราชนะ" เรื่องนี้ยังความไม่พอใจให้กับสำนักอื่นค่อนข้างมาก ถึงขนาดรวมตัวกันเป็นกลุ่ม "Anti Booch" ยิ่งประธานของ OMG ก็เป็น Methodologist ด้วยเหมือนกัน อยู่ในกลุ่มต่อต้าน Booch ด้วย ก็ยิ่งไปกันใหญ่ เจ้าอื่นเขาก็รวมตัวกันเหมือนกันนะครับไม่ใช่ Booch ทำได้คนเดียว ที่สำคัญคือ OML ที่รวมตัวกันหลาย Methodology เข้าด้วยกัน แต่สุดท้ายก็สู้ Booch ไม่ได้ครับ

    แต่ Booch กับ Rumbaugh ก็ไม่สนใจครับ พยายามรวม 2 รูปแบบเข้าด้วยกัน ใช้เวลา 1 ปีเต็มครับ ออกมาตั้งชื่อใหม่ว่า Unified Modeling Language โดยที่ Booch กล่าวว่าแผนภูมิเหล่านี้ มันดูเหมือนเป็นภาษา ที่ประกอบด้วยคำศัพท์และกริยา ตามใจครับ มองเป็นภาษาก็ภาษา แต่ก่อนที่จะส่งเข้าประกวดกับ OMG ก็ได้รวมตัวกับ Ivar Jacobson ซึ่งคิดค้น OOSE ซึ่งเน้นในการทำ Use Case ซึ่งเน้นช่วง OOA ครับ ดังนั้นจึงถือว่า UML นั้นค่อนข้างครบถ้วนครับ และเมื่อส่งไปให้ OMG แล้ว OMG ก็รับไว้ปรับปรุงครับ ซึ่งการปรับปรุงในรอบนั้นมีหลายบริษัท Software, Hardware เลยครับที่เข้ามาร่วมด้วย จากนั้น จนปลายปี 1997 UML ก็ได้รับการประกาศให้เป็นมาตรฐานโดย OMG

    ส่วนทั้ง 3 คนที่ทำ UML ปัจจุบันก็ทำงานอยู่ที่ Rational ครับ ยังเป็นทีมเดียวกันอยู่และเรียกตัวเองว่า 3 สหาย (The Three Amigos)

    ตั้งแต่ UML เริ่มเป็นที่แพร่หลาย อะไรๆ ในโลกของ OO มันก็ง่ายขึ้นเยอะ ในยุคปัจจุบัน OO เริ่มเป็นทางเดียวกันแล้วครับ

วิวัฒนาการของวงจรการเขียนโปรแกรม

    ในการเขียนโปรแกรมใดๆ ก็ตาม เราต้องมีหลักการที่ยึดไว้ แน่นอนครับสำหรับ OO นั้นเราใช้หลักการ OOA -> OOD -> OOP แต่นั่นก็ดูหลวมเกินไปครับ ดังนั้นจึงมีผู้คิดค้นหลักการขยายหลักการนี้ออกไปสร้างเป็นกติกาอย่างชัดเจนเป็นขั้นเป็นตอน เรามาลองดูว่ามีอะไรบ้าง

1) Crash and Burn

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

2) Waterfall

    หลักการนี้นิยมในยุคตั้งแต่ปี 70 ทุกวันนี้ก็ยังมีคนใช้อยู่ แต่คงน้อยลงไปเรื่อยๆ วิธีนี้ใช้หลักการทางวิศวกรรม แบ่งงานออกเป็นขั้นๆ ในการพัฒนา Software โดยยึดหลักการว่า ถ้าเราทำในขั้นแต่ละขั้นให้ครบถ้วน งานที่ได้ออกมาจะดี แต่พอเอาเข้าจริง วิธีนี้ก่อให้เกิดปัญหามากครับ เพราะ มีการคาดกันว่า ถ้าต้องการให้ประสบผลสำเร็จ ต้องใช้เวลากับขั้น การเก็บข้อมูล (Analysis) ไม่น้อยกว่า 50% ของงานทั้งหมด ถ้าทำอย่างนั้นจริง ผู้ใช้โปรแกรมจะรู้สึกแย่ เพราะไม่เห็นอะไรเลย และการทำอย่างนี้ก็ยังไม่สามารถทำให้ครบถ้วนได้อยู่ดี เพื่อลดเวลาขั้นตอนนี้ บริษัทต่างๆ ต้องหาผู้ออกแบบ (System Analyst) ฝีมือดีมาออกแบบ แต่หายากมากครับ ส่วนมากไม่เก่งจริงทั้งนั้น

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

3) Increment / Iteration

    แบบนี้เป็นแบบที่นิยมในปัจจุบันครับ คือ OOA->OOD-OOP->Test แล้วก็ไปให้ผู้ใช้ดู มีอะไรแก้ก็เริ่มวนวงจรนี้ใหม่ โดยทั่วไปวงละ 2 ถึง 6 อาทิตย์ ข้อดีก็คือ การไม่จำเป็นต้องเก็บข้อมูลให้ครบถ้วน เก็บแค่หยาบๆ ก่อน แล้วก็ออกแบบ จากนั้นก็เขียนโปรแกรมเลย เมื่อทดสอบเสร็จก็ไปให้ผู้ใช้ดี ว่าตรงหรือไม่ ถ้าไม่ตรงก็จะได้รีบไปรื้อใหม่ ถ้าตรงก็จะได้ขยายความสามารถเพิ่ม กว่าโปรแกรมจะสำเร็จคงต้องหมุนวงจรนี้ไปหลายสิบรอบครับ บริษัท Software ใหญ่ เกือบทุกบริษัทใช้แนวนี้ครับ ถึงแม้ว่าจะเขียน Software เป็นโปรแกรมสำเร็จรูปขายก็ตาม

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

 

วงจรการเขียนโปรแกรมที่นิยมใช้ในยุคปัจจุบัน

    ถนนสายหลักของการเขียนโปรแกรม ไปอยู่ที่ Increment / Iteration ดังนั้นจึงมีผู้ตั้งกฎกติกาข้อบังคับต่างๆ ในรายละเอียด เพื่อให้การพัฒนาเป็นรูปเป็นร่างไม่ใช่แค่เพียงทฤษฎี วิธีใดที่มีกฎน้อย เราเรียกว่า Light-Weight  ส่วนวิธีการใดๆ ที่ตั้งกฎมาก เราเรียกว่า Heavy-Weight นั่นเอง เรามาลองดูวิธีการที่นิยมใช้กันในยุคปัจจุบัน

1) Extreme Programming (XP)

    ผู้คิดค้นก็คือ Kent Beck เขาเบื่อมากกับที่วันๆ ที่โปรแกรมเมอร์ไม่ได้เขียนโปรแกรม กลับต้องใช้เวลาบางส่วนไปทำเอกสาร ดังนั้น Kent Beck จึงปฏิวัติการเขียนโปรแกรมเสียใหม่ โดยทำให้ทีมเบาที่สุด ทำเอกสารเฉพาะที่จำเป็นเท่านั้น การทดสอบโปรแกรมก็เป็นสิ่งน่าเบื่อ ดังนั้นเขาจึงคิดค้นวิธีการทดสอบโปรแกรมแบบใหม่โดยการที่เขียนตัวทดสอบก่อนเขียนโปรแกรม ซึ่งก็ตั้งชื่อว่า XUnit, จากนั้นถ้าให้ได้งานก็ต้องเขียนโปรแกรมกันเป็นคู่ คำว่าเป็นคู่นี้หมายถึงคน 2 คน จอเดียวและ Keyboard เดียว และให้ผู้ใช้เป็นผู้เลือกเลยว่าอยากให้ทำตัวไหนก่อน

    แนวคิดแบบสุดขั้วแบบนี้ ถ้าคุณเป็นโปรแกรมเมอร์คงต้องชอบครับ ก็ Kent Beck เป็นโปรแกรมเมอร์ ถึงออกแบบอย่างนี้ ปัจจุบันมีคนที่เห็นด้วยกับวิธีนี้จำนวนมาก ถ้าคุณสนใจ ลองดูจากหนังสือ Extreme Programming  Explained หรือถ้าคุณตกลงใจแล้วว่าใช้วิธีนี้ ก็ลองอ่าน Extreme Programming Installed น่าสนใจมากครับ

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

    XP ไม่ใช่เจ้าเดียวนะครับที่เห็นว่าการพัฒนา Software แบบนี้เป็นสิ่งที่เหมาะสม ยังมี Methodology อื่นๆ ที่คล้ายๆ กับ XP ที่น่าจะเอยนามก็คือ Alistair Cockburn ผู้คิดค้น Crystal Method ผมชอบ Cockburn นะครับ เพราะวิธีการที่เขาสร้าง Methodology นั้น เขาใช้วิธีไปคุยกับทีมพัฒนา Software แต่ละเจ้า ดูว่า โครงการไหนสำเร็จหรือล้มเหลว และอะไรเป็นปัจจัยทำให้เกิดขึ้น ลองอ่าน Surviving Object-Oriented Project น่าสนใจมากครับ

    อีกเจ้าหนึ่งที่น่าจะกล่าวถึงคือ Scott Amber ครับ เขาเขียนหนังสือหลายเล่ม ผมเองก็ไม่เคยอ่านเลยบอกไม่ได้ว่าดีหรือไม่ดี แต่ที่ต้องกล่าวถึง เพราะ เขาคนนี้เป็นผู้รวบรวมเอา Methodology เข้าด้วยกัน รวมเป็น Agile Modelling ซึ่งทั้ง XP และ Crystal ก็รวมในกลุ่มนี้ด้วย

2) Rational Unified Process

    RUP เป็น Methodology แบบ Heavy-weight คือมีกฎกติกาเยอะ ได้สามารถ Customize ได้ทำให้เป็นตระกูล Agile ได้เหมือนกัน โดยการตัดเอาบางส่วนออก ต้นแบบของ RUP นั้นได้มาจาก Objectory ของ Ivar Jacobson ผมเองก็ได้แต่ดูผ่านๆ ครับ ไม่มีงบประมาณไปซื้อ (ไม่ต้องแปลกใจครับ แนวคิดของ RUP มันมาพร้อมกับ Software ที่ Implement มัน แบบ Web-based ครับ) เลยไม่อยากจะวิจารณ์อะไรมาก แต่สิ่งหนึ่งที่น่าสนใจก็คือ RUP ถูกออกแบบให้รองรับ UML เต็มที่ครับ ก็เพราะทีมออกแบบคือทีมเดียวกันนั่นเอง

    ยังมีอีกหลายเจ้านะครับ เช่น KrobA ก็อยู่ระหว่าง XP และ RUP แต่ผมยังไม่มีเวลาไปศึกษามัน

    อีกเรื่องที่น่าสนใจ นั่นก็คือ SW-CMM  ประวัติมีดังนี้ครับ   กระทรวงกลาโหมสหรัฐเสียหายเงินปีหนึ่งถ้าผมจำไม่ผิดเป็นหลักหมื่นล้าน เพราะจ้าง Software House ข้างนอกมาเขียนโปรแกรม และก็ทำไม่เสร็จตามเวลา หน่วยงานนี้จึงจ้าง มหาวิทยาลัย CMU เพื่อวิจับที่มาและหาทางแก้ ผลลัพธ์ที่ได้มาก็คือ บริษัทต่างๆ ใช้ Methodology ที่ไม่เหมาะสม ไม่ได้ทำในสิ่งที่จำเป็นต้องทำ ดังนั้น CMU จึงวางกติกาออกมาเป็น 5 ระดับ และมีการสอบ ระดับที่ 1 คือบริษัททั่วไปที่ยังไม่ดี ส่วนระดับสูงๆ ขึ้นไป ก็มีกติกาเข้มงวดขึ้น ต้องทำสิ่งต่างๆ เยอะไปหมด ถ้าทำได้ก็ค่อนข้างมั่นใจว่าบริษัทมีคุณภาพ (แนวทางของ CMM ก็คล้ายกับ ISO9000) ซึ่งทางกระทรวงกลาโหมสหรัฐ ถือเอา SW-CMM เป็นเงื่อนไขในการรับงานของ Software House ต่างๆ

     Rational คุยว่า ถ้าทำใช้ RUP เต็มรูปแบบ ก็จะสามารถสอบผ่าน CMM ระดับ 3 ได้ ส่วนถ้าใครใช้ XP อาจจะไม่ผ่าน Level 2 ด้วยซ้ำไป

เอาหละครับ วันนี้ผมปูพื้นการพัฒนา Software มาพอสมควรแล้ว ในบทความคราวหน้าเรามาดู OO แบบเต็มๆ กันครับ