จากกับดัก Agile ที่ level 1 (ทั้งเก่าและใหม่) ผมพยายามดันให้ลดการเผื่อ แล้วค่อยมา refactor architecture ทีหลัง ซึ่งหลายๆท่านก็เป็นห่วงว่า “ความพอดี” ของแต่ละคนไม่เท่ากัน จะรู้ได้อย่างไรว่าเมื่อไหร่เรา”เผื่อ”มากเกินไป?
ในบางกรณี โทษจากการไม่เผื่อ (ขาด) มันรุนแรงมาก เช่น ออกแบบ field address ไว้เป็น text area อันเดียว แล้วต้องมาแยกที่หลังว่าใครอยู่จังหวัดอะไร ถนนไหน แก้ structure ไม่เท่าไหร่ แต่แก้ข้อมูลที่ลงไปแล้วนี่จุกครับ (ใครเคยทำจะซึ้งว่ามันทรมาณขนาดไหน T-T) ถึงอย่างนั้นก็ตาม วันนี้ผมยังกลับมาอีกครั้ง พร้อมกับเชียร์ดังๆว่า อย่าไปเผื่อครับ ค่อย refactor เอา สำหรับท่านที่เคย design แล้ว”ขาด”มาแล้ว จะฝังใจมากๆว่า”เหลือดีกว่าขาด” แต่นั่นมันไม่ Agile ครับ
พี่ Bomber พูดไว้ว่า process เหมือนรถแข่ง ถ้า scope คำว่า process ลงมาเป็น personal process แล้ว คน หรือ person ก็คือคนขับนั่นเอง ถ้าไม่กล้าเหยียบคันเร่งพุ่งใส่โค้ง ก็ไม่มีวันจะได้สัมผัสความรู้สึกของดริฟท์หรอกครับ (-__-+) หลายท่านที่เคย design ขาดมาแล้ว ต้องคิดว่าหมอนี่มันบ้าแน่ๆ แต่เพราะประสบการณ์ตามล้างตามเช็ดผลที่เราตัดสินใจพลาดมา ทำให้วันนี้เราเร็วขึ้น ท่านว่าจริงไหมครับ?
ขอบเขตของพอดีนั้นบางเหมือนปลายมีด นิดนึงมากกว่านั้นคือเผื่อ นิดนึงน้อยกว่านั้นคือขาด ขาดก็เจ็บ เผื่อก็ช้า
แต่ถ้าอยาก maximize agility ก็ต้องหาขอบนั้นให้เจอ ประสบการณ์กว่าจะถึงตรงนั้นมันทรมาณ แต่ความทรมาณนี้แหละที่ทำให้ผมเร็วขึ้นครับ
ถ้ามีคนลองทำตามผมจริงๆ (พวกบ้าพนัน 
) ณ วันนี้ ท่านจะเริ่มรู้สึกว่า refactoring == rotation
red-black tree คือ binary tree แบบหนึ่งครับ เก็บข้อมูลเอาไว้ค้นง่ายๆ สิ่งที่ทำให้ red-black tree มันพิเศษคือ มันจะคอย maintain โครงสร้างตัวเอง โดยการจับตาดู node สีแดงครับ ถ้าเมื่อไหร่ที่มี node สีแดงอยู่ติดกัน red-black tree จะได้กลิ่น bad smell ทันที แล้วจะเริ่ม rotate โครงสร้างของมันเพื่อการันตีว่า เวลาในการค้นจะไม่นานเกิน O(log n)
rotation คือ action หนึ่งที่ red-black tree จะทำอยู่เรื่อยๆ ถ้าเมื่อไหร่ที่ node ใหม่ที่เพิ่มเข้ามามันทำให้ structure เริ่มไม่สวย red-black tree ไม่เคยรู้หรอกว่าสำหรับ input node ซัก set หนึ่ง มันต้อง rotate ซักกี่ครั้ง รู้แค่เมื่อไหร่ไม่สวย ก็ต้องตบให้มันเข้าที่ซะ ไม่เคย”ทิ้งไว้ก่อน” หรือ “ค่อยทำ” บางครั้งมันก็ซื่อบื้อครับ เพราะ rotate ไป rotate มา มันอาจจะกลับมาเหมือนหน้าตาก่อนหน้านี้ก็ได้
พูดเฉยๆไม่เห็นภาพ มาดูตัวอย่างกันดีกว่า Prof. Zitterbart’s Red-black tree example
demo ทำด้วย applet นะครับ จะเริ่มต้นด้วยการ เพิ่ม node 1, 2, 3, .. 14 นั่งดูไปเรื่อยๆ ไม่ต้องคิดมาก แค่สังเกตุนิสัยของ red-black tree ที่ไม่ยอมปล่อยให้ architecture มันหนักขวาจนเกินไป เมื่อไหร่ที่เริ่มหนักขวา มันจะตบกลับซ้ายตลอด หลังจากมันหยุดที่ 14 เราจะเริ่มเลือกที่จะเพิ่ม node ใหม่เองได้ครับ ทำโดยการเลือก node ซักอันแล้วกด insert
ลองเลือกขวาล่างสุด (node 14) แล้วกด insert ดูครับ ถ้าเป็นไปตามที่ผมกะไว้ node 15 (หรือ 14.5) จะเพิ่มเข้ามา (drop down 3 อัน เอาไว้ปรับ display ลองปรับเล่นได้ตลอดนะครับ เลือกเอาตามชอบใจ) ถ่วงทางขวาสุดอีกซัก 3 อัน จะเห็นว่างานเข้า red-black tree ต้อง rotate กันยกใหญ่เลย (สมน้ำหน้า งานเข้าๆ 
)
คราวนี้ลองมาถ่วงซ้ายให้ red-black tree เจ็บใจเล่นดีกว่า (แกล้งมัน) ลองถ่วงซ้ายให้มันต้อง rotate 8 กลับไปข้างล่างเหมือนเดิม แล้วเสียใจว่า ตะกี้ไม่น่า rotate 8 ขึ้นมาเลย… (>.< “)
เอาล่ะครับ ไม่ว่าท่านจะแกล้งมันสำเร็จแล้วกำลังนั่งเสียดายเวลา หรือกำลังหัวเสียที่แกล้งมันไม่ได้ซะที ทำใจร่มๆครับ ถึง climax แล้ว ลองกลับไปอ่านข้างบนใหม่ (โดยเฉพาะใน quote) แล้วลองเปลี่ยน node -> requirement, red-black tree -> architect, rotate -> refactor
นี่คือชีวิต architect ในสายตาผม เรามี discipline ในการ maintain architecture ครับ เราไม่มีทางรู้ว่า requirement อะไรจะเข้ามาในอนาคต เราอยู่กับปัจจุบัน ถ้า architecture มันเริ่มไม่สวย เราก็ต้อง refactor มันทันทีเพราะอย่าปล่อยให้มันกลายเป็นปราสาทแก้ว เพราะถึงตอนนั้นก็ไม่มีใครกล้า refactor แล้ว แต่บางครั้ง refactor ไปแล้วก็ต้อง refactor กลับครับ architecture ที่สวยวันนี้ พรุ่งนี้อาจจะห่วยก็ได้ แต่เดือนอาจจะกลับมาสวยอีกก็ได้ ไม่มีใครรู้
แต่โลกเรามันไม่เลวร้ายขนาดนั้นครับ architecture มันก็มี maturity (วัยวุฒิ) ของมันเอง แรกๆอาจจะต้อง refactor whole architecture บ่อยๆ เพราะโครงสร้างมันยังเล็ก มันเสียสมดุลย์ง่ายครับ แต่พอพัฒนาไปเรื่อยๆ architecture จะเสถียรขึ้นเรื่อยๆ แล้วหลังๆโอกาสที่จะปรับทั้งโครงสร้างจะน้อยลงๆ ชีวิตจะสบายขึ้นๆครับ
สำหรับ architect ที่ keep discipline ตรงนี้ จะ guarantee ว่า architecture ที่มีอยู่มันต่อยอดได้ตลอดเวลา (big-O ของการ insert ของ red-black tree คือ O(log n) เหมือนตอน search นะครับ) ไม่ใช่มี requirement ใหม่เข้ามาแล้วก็ทำสองวันบ้าง สองอาทิตย์บ้างแล้วแต่ดวง มันจะมีขอบเขตของมัน ไม่แกว่งมาก เมื่อทำ planning ได้แม่นขึ้น ผิดแผนน้อยลง Project Manager ก็จะ agile ได้มากขึ้นครับ
สรุปแล้ว อย่าไปกลัวว่าต้อง refactor ครับ อยากเร็วต้องกล้าที่จะไม่เผื่อ ต้องไม่กลัวขาด โยนคำว่าเหลือดีกว่าขาดทิ้งไป มีแต่คนบ้าที่ห่วงความเร็วมากกว่าความปลอดภัยเท่านั้นแหละครับ ที่จะเร็วแบบบ้าคลั่งได้
ชอบตอนที่เปรียบเทียบกับ Red-Black tree ครับ เห็นภาพชัดมากๆ เลย
ว่าแต่การ Refactor เนี่ย ถ้าระบบใหญ่ขึ้นๆ แล้วไม่ทำให้ Refactor ยากขึ้นไปเรื่อยๆ หรอครับ เพราะนอกจากจะต้อง Refactor ตัวโค้ดแล้ว ยังต้อง Refactor ตัว Test ด้วย แบบนี้เวลา Planning จะมีปัญหามั๊ยครับ ว่าทาง Product Owner ไม่ค่อยเห็นคุณค่าของกิจกรรมการทำ Refactor ซักเท่าไหร่
จุดประสงค์ที่เราทำ refactoring เพราะว่าเราเข้าใจปัญหามากขึ้น เราเลยปรับ code ให้นำเสนอ domain ของปัญหาอย่างตรงไปตรงมามากขึ้น expressive มากกว่าเดิม
เพราะฉะนั้นเวลา requirements มีการเพิ่มหรือเปลี่ยนแล้ว effort ที่ใช้เพิ่มหรือเปลี่ยนควรจะ scale ตามกันไปสอดคล้องกันตาม
โดยส่วนใหญ่ใน agile project การเปลี่ยนแปลงมักไม่ค่อยจะมาทีละใหญ่ๆ (ถ้าเราไม่ได้ไปพอกมัน) แต่จะเกิดขึ้นทีละนิด เราก็เขียน test ปรับ design ไปทีละนิด
refactoring ถ้าทำอยู่ตลอดและทำอย่างถูกต้อง เวลา requirements มีการเพิ่มเติมปรับเปลี่ยนมันจะ scale ในตัวมันเองอยู่แล้วครับ
เมื่อ requirements เปลี่ยนนิดเดียวแล้ว effort ที่ใช้ก็ควรจะนิดเดียวสัมพันธ์กันไป
ถ้ามันจะไม่ scale ก็เป็นเพราะทำอย่างไม่ถูกต้อง เช่น เขียน code + test แต่ไม่ชอบทำ refactoring หรือทำก็ทำแต่ production code ไม่ได้ทำ refactoring test code ด้วย
สังเกตเอาง่ายๆ ว่า ถ้าแก้ที่ production code นิดเดียวเองก็ทำงานถูกต้องแล้ว แต่มันทำให้ต้องรื้อ test code ซะยกใหญ่ แปลว่า test code ไม่ค่อยได้ถูก refactoring ไปพร้อมกัน และนั่นเป็นสัญญาณปัญหาแล้ว
เวลา planning เราก็ plan กันโดยเอา effort มาคิดอยู่แล้วครับ ตราบใดที่ยังทำมันถูกวิธี effort มันจะ scale ตาม requirements เองครับ
หากทำ Refactoring อยู่อย่างต่อเนื่อง พร้อมทั้งการทำ TDD จะทำให้การ Refactoring ระบบใหญ่ๆไม่ใช่เรื่องยากครับ
เวลา estimate task ต้องคิดถึงเวลา Refactor อยู่แล้ว และมีอะไรเกิดขาดคิดจริงๆก็จะกลายเป็น unplanning task ซึ่งแปลว่า sprint นั้นอาจจะเกิด delay ได้ ซึ่งจะเป็นทบเรียนทำให้คร่าวหน้า estimate ได้ดีขึ้น
Product owner เห็นคุณค่าในทางอ้อมครับ คือจะพบว่าระบบมี Bug น้อยนั้นเอง
ดีใจจริงๆที่ยังมีคนอิน! \(^-^)/ เห็น post แล้วเงียบ นึกว่าจะกริบซะแล้ว ( >.< ) ยอมรับว่า red-black tree มันยาก แต่เห็นมันโดนมากๆ เลยเอามา blog ;P
สำหรับคำถาม…
product owner สนใจด้วยเหรอครับ ว่าเรา refactor หรือเปล่า? ถ้าเป็น project manager ยังนึกภาพตามทัน แต่ product owner ตามความคิดผม น่าจะสนใจแค่ตัว product และคุณภาพของมันหรือเปล่า?
test ช่วยเพิ่ม quality ของ product ได้โดยตรง ส่วน refactor น่าจะเพิ่มโดยอ้อม การมี architecture ที่ดี เพียงทำให้มันไม่มีหลืบให้ bug หลบเท่านั้น แต่ที่จะเห็นผลมากที่สุด น่าจะเป็น product ที่มีอนาคต ต่อยอดได้มากกว่า ไม่ใช่ปราสาทแก้วที่ไม่มีใครกล้าแต่งเติมอะไรอีก ได้แต่วางไว้ให้มันทำงานเดิมๆของมันไป เด๋วแตก
แต่สำหรับ project manager แล้ว refactor ช่วยเยอะเลยครับ เพราะก่อนหน้าเราเรียกเสร็จแบบ architecture เบี้ยวๆว่าเสร็จ ฉะนั้น พอหลังๆถึงคราวที่มันต่อยอดไม่ได้ ก็ต้องมารื้อกัน ยิ่งโครงสร้างแย่เท่าไหร่ จะเพิ่มอะไรเข้าไปยิ่งใช้เวลาเท่านั้น ผลคืองานที่เคยกะว่าสองวัน ก็กลายเป็นสองอาทิตย์ ถ้าทำอย่าง red-black tree จะช่วงแรกช่วงหลังก็ไม่เกี่ยว insert ยังไงก็มี big-O คือ O(log n) เพราะเวลาในการ insert = insert + maintain architecture เสมอ
อีกอย่างที่จะช่วยให้สบายใจได้อีกนิด software architecture ก็เหมือน tree architecture แหละครับ หลังๆมันจะไม่ต้อง refactor ใหญ่ๆหรอก เพราะโครงสร้างมันงวดแล้ว
แสดงว่า จริงๆ แล้วก็ต้องมีทักษะนั่งทางในในการที่จะหยั่งรู้ Scale ของ Architecture ที่เหมาะสมกับระบบตั้งแต่ช่วงแรกๆ ด้วยรึเปล่าครับ ถึงจะยังรักษาความสัมพันธ์ของ cost แบบ O(log(n)) สำหรับแต่ละ operation
ผมเข้าใจว่าถ้ามี Requirement ที่เปลี่ยนขนาดของการออกแบบเนี่ย ค่าใช้จ่ายการทำ Refactor ทั้งในแง่ของเงินและแง่ของmanmonth มันจะไม่ได้เป็น O(log(n)) รึเปล่าครับ เช่นถ้าตอนแรกเขียน shell script ทำงานโง่ๆ ชิ้นนึง ตอนหลังไปๆ มาๆ กลายเป็น UI-based app อย่างนี้ตัว Requirement มันใหญ่เกินที่การออกแบบเดิมจะรับไหว ก็แทบจะทำใหม่กันเลยทีเดียว
ส่วนเรื่อง Product Owner นี่เข้าใจว่ามีปัญหามันมีเพราะว่าสุดท้ายคนกลุ่มนี้เป็นคนเลือกว่ารอบถัดไปต้องทำอะไรบ้าง แต่เขาไม่เข้าใจว่าการ Refactor มันสร้างคุณค่าเชิงธุรกิจให้กับเขาได้อย่างไร
คิดว่าก็คงต้องตีค่าหนี้เชิงเทคนิคออกเป็นค่าใช้จ่ายกันเห็นๆ แล้วมากางดูว่าถ้าทำ Refactor มันชดใช้หนี้ไปได้เท่าไหร่ แต่ปัญหาก็จะเกิดอีกว่าแล้วมันจะตีความกันยังไงดี – -”
ปัญหา shell script -> UI based app นี่เป็นปัญหาเพราะความต้องการเปลี่ยนใช่มั้ยละครับ เมื่อมันเป็นสิ่งที่ต้องเปลี่ยนก็ต้องเปลี่ยน ซึ่งตอนแรกลูกค้าเองที่ต้องการแค่นั้น แต่พอเค้าเข้าใจเห็นคุณค่ามากขึ้นเลยขอปรับเป็นแบบหลัง
เราต้องการส่งมอบสิ่งที่ตรงใจเค้ามากที่สุดไม่ใช่หรือ?
เราเขียน test เพื่อรองรับการเปลี่ยนแปลงต่างหาก เอามันมาใช้เป็นเครื่องมือเพื่อยืนยันสร้างความมั่นใจว่าของที่เคยทำงานได้มันจะยังคงทำงานได้ต่อไป
ถ้าเปลี่ยน shell script -> UI based app แล้วถามว่า business logic มันยัง flow เดิมอยู่หรือเปล่าละ?
ถ้าใช่ ปัญหาต่อมาคือทั้ง test code + production code มันมีความขึ้นกันอยู่กับ shell script เดิมอยู่จริงมั้ย ?
เพราะฉะนั้นเราเลยต้องทำ refactoring ไงละครับ
เริ่มจาก refactor ส่วน test case ของเราที่ทำงานได้ดีอยู่แล้วให้เอาส่วนที่ขึ้นกับ shell script ออกไปเหลือไว้แต่แก่นเท่านั้น แล้วมันจะส่งผลกระทบให้เราต้องไป refactor ตัว production code ไปในตัวด้วย
ผลลัพธ์ เราจะได้ design ของ production code + test code ที่สวยขึ้น reuse ได้มากขึ้น และพอเพียง
เห็นด้วยกับพี่ deans4j ครับ requirement ชิ้นเล็กๆ เหมือนกับ node 1 node ที่เข้ามาพอดี
อีกอย่าง ทักษะหยั่งรู้ scale ของ architecture คงไม่มีครับ
- ถ้าเราเชื่อว่า scale ของ architecture สัมพันธ์กับ scope ของ requirement
- และเราเชื่อว่า scope ของ requirement (ที่มีคุณภาพดี) สะท้อน business strategy และสถานการณ์ทางธุรกิจ
- เราจะรู้ว่า ไม่มีใครรู้สถานการณ์ทางธุรกิจล่วงหน้าครับ และใน context นั้น การทายผิดเป็นเรื่องปรกติ ฉะนั้น ย้อนสายกลับมา จะเห็นว่าใน project ใหญ่ๆ ไม่มีใครเห็น final architecture ตั้งแต่แรกหรอกครับ หรือเห็นก็ไม่มั่นใจหรอก ว่ามันถูก
ในเมื่อมันมี project ใหญ่ๆ (ไม่มีใครเห็น, เชื่อ final architecture ตั้งแต่ต้น project) ที่ประสบความสำเร็จได้ แสดงว่าการมองเห็น final architecture นั้นไม่จำเป็นครับ
เพิ่มเติมครับ การพยายาม final architecture ตั้งแต่แรก นำไปสู่ heavy design up-front ครับ ไม่ได้แปลว่าจะไม่ดีนะครับ แต่มันอาจจะไม่เหมาะกับ TDD หรือเปล่า? หรือไม่เหมาะกับ agile? ชักไม่แน่ใจละ ^ ^”
ถ้าใช้ TDD และทำ heavy design up-front test cases ที่เกิดขึ้นจะเป็น architectural tests ซึ่ง evolve ไปพร้อมๆกันกับ architecture ของระบบ แต่ว่า architecture เหล่านั้นจะไม่สะท้อน business value เลย (ไม่เข้ากับ story ใดเพราะ leads benefit ไม่ได้) แต่อาจจะเป็นการซื้อเวลาในอนาคตที่คุ้มค่า (ถ้า insight ของเรานั้นแม่น) โดยเชื่อว่า ในภายหลังเราจะไม่ต้อง refactor บ่อยๆ…. อืมม.. ได้คำตอบละครับ ผมว่ามันไม่ agile แหละ ^ ^”
ผมว่ามันเหมือน programmer ที่บ่นว่าผมเขียน code ที่ละห้าบรรทัดเป็น ทำไมต้องทำทีละบรรทัดสลับเขียน test? ซึ่งการเขียนทีละ 5 บรรทัดมันเสี่ยงที่จะเสีย quality ของ code บางส่วนไป แล้วสุดท้ายมันก็มักจะกลับมาแว้งกัดเราเอง ผมว่า heavy design up-front ก็เสี่ยงจะเกิด waste เหมือนกัน เลยคิดว่ามันไม่ agile ครับ ในการวิ่งระยะยาว เราไม่สนเรื่องวิ่งเร็วหรือช้าครับ เรากลัวหลงทางมากกว่า
ผมยัง design high level architecture อยู่นะ ส่วน low level architecture ไม่มี เช่น ต้องแตก class อย่างไร structure class เป็นอย่างไร ไม่ได้ design ก่อน แต่โครงสร้างระบบเช่นจะใช้ caching จะใช้ text file หรือ db พวกนี้ design ไว้ก่อน อะลืมไปผมไม่ได้ใช้ TDD นี่นา 555+
การ design high level architecture อาจจะไม่เป็น heavy design up-front ก็ได้ (-__-)a แต่ฟังๆพี่ bomber แล้ว ชวนให้รู้สึกว่าการ design high level architecture ไม่ขัดกับ agile
ที่ design high level architecture นี้ ผมเข้าใจว่าแค่วาดรูปคร่าวๆว่าควรจะต้องออกมาประมาณนี้ตาม non-functional requirement ที่มีในปัจจุบัน ถูกไหมครับ? หรือว่ามีการ code high level architecture (ส่วนใหญ่น่าจะเป็น interface ของ class) ขึ้นมาด้วยครับ? ถ้ามีการ code จะทำ TDD ก็น่าจะเป็นการเขียน architectural test ก็น่าจะทำได้เหมือนกัน
ตอนนี้ผมคิดว่า
- design high level architecture ไม่ขัดกับ agile
- design high level architecture ไม่ขัดกับ TDD (architectural test)
ผมยังคงสงสัยว่า
- design high level architecture ถือเป็น heavy design up-front ไหม? คิดว่าไม่น่าจะเป็น แต่ไม่มั่นใจ
ท่านอื่นๆคิดเห็นอย่างไรบ้างครับ?
ไม่รู้จะกด Reply ยังไงดี ลองมารวมๆ กันไว้โพสเดียวเลยนะครับ
>> Product Manager
ที่ผมเป็นห่วงก็คือว่า เวลาเราบอกหัวหน้า ว่าเราจะ Refactor (เวลาผมพูด ผมพูดว่า Cleanup code) แกก็จะบอกว่า แล้วทำไปทำไมล่ะ มันก็ใช้ได้นิ อย่าไปเสียเวลากับมันเลย เดี๋ยวต้องมีโปรเจคมาใหม่อีก สรุปคือ หัวหน้าไม่เห็นภาพล่ะครับว่า ระยะยาวมันจะดีกว่าน่ะ บางทีอาจจะต้องรวมเวลาเข้าไปกับ Task ที่ estimate ขึ้นมาใหม่อย่างที่พี่ bomber บอกก็ได้มั๊งครับ (เหมือนกับว่าแอบทำ ^_^)
>> TDD
ที่เป็นห่วงคือ TDD มันผูกติดกับตัวโครงสร้างของโค้ดที่เขียนอยู่เยอะเหมือนกันนะครับ หลายๆ คนก็คงเขียน 1 test class ต่อ 1 class ใช่ไหมครับ ถุ้าคลาสมันปรับนิดหน่อย เช่น มี public method เพิ่ม ก็คงเขียน test ตามไม่ยาก แต่เวลา architecture เปลี่ยน คลาสมันก็กระจายไปหมดเลย ก็ต้องเปลี่ยน test class เยอะเหมือนกัน
>> Architecture
Heavy Design Up front ของผมคือ การที่เราพยายามจะเข้าใจ ทุกอย่าง ทุกสิ่งอัน เกี่ยวกับ โปรเจคก่อนแล้วค่อยลงมือ Design หมายถึงเราพยายามจะกำจัดความเสี่ยง “ทั้งหมด” ออกไป ซึ่งบางทีความเสี่ยงนี้ มันอาจจะไม่เกิดขึ้นก็ได้ครับ ก็คือ เสียเวลาโดยใช่เหตุนั่นแหละ แนวทางการแก้ของ Agile คือ “อย่าไปเผื่อ” ซึ่งก็คือ เรายินดีรับความเสี่ยงที่จะเกิดขึ้นกับการไม่ได้คิดตอนนี้ แล้วไปแก้ปัญหาเอา (ถ้ามันเกิดปัญหาขึ้นจริงๆ)
ถ้าเรายังไม่รู้ ก็อย่าไปคิดว่ามันจะเกิดขึ้น เช่น เค้าบอกให้เราทำโปรแกรมแบบไม่มี UI แต่เราเดาว่าต่อไปมันควรจะต้องมีชัวร์ๆ เลยนะ ใครจะไปอยากใช้ถ้ามันไม่มี อันนี้เรียกว่าเผื่อเกินไป
ถ้าเรามีแผนมาชัดเจนว่า เราจะทำ shell ก่อนนะ เป็นรีลิสแรก แล้วเราก็จะค่อยทำเป็น UI เป็นรีลีสที่สอง อันนี้ถ้าเราไม่ได้ออกแบบเผื่อไว้ ก็ดูจะเป็นการไม่ใช้ข้อมูลที่มีอยู่ให้เป็นประโยชน์ครับ
สรุปก็คือ ถ้าออกแบบ Architecture (สำหรับผมอะไรที่ใหญ่เกินกว่า 1 whiteboard ถือว่าไม่ใช่ architecture ละนะ) โดยคำนึงถึงแผนการ Release กว้างๆ ทำเสร็จภายใน 2-3 ชม. ก็ไม่ถือว่า Heavy เกินไปนะ เวลาที่มาใช้ Refactor อะไรที่เป็นภาพใหญ่ขนาดนี้ คงนานแน่ๆ เลย ส่วนมากการทำ Architecture ที่ได้ก็ไม่ใช่ Architecture สุดท้ายหรอกครับ (อ่านดูใน OpenUP เค้าก็ให้ใช้หลักการ Evolvable Architecture นะ) แต่สิ่งที่ได้คือ จะได้ให้เรารู้ตัวว่า ตอนนี้เรากำลังจะทำโปรเจคไปในแนวนี้ ทำให้เราเห็นว่าส่วนไหนที่มันเป็นจุดอ่อน / จุดแข็งของ Architecture ของเรา เวลามี story ที่มันอาจจะทำให้ architecture พัง เราจะได้รู้ตัวก่อนครับ แล้วก็วางแผน refactor กันไป
[...] comment จากเรื่องเกี่ยวกับ Refactor เห็นถกกันเรื่อง Architecture กับ Agile [...]
Hi!
Re-twit you post: to my
@qfiieogr twitter