Agile,Agile Tour,Coach,Design,Uncategorized

Legacy Code for Management

จบไปแล้วครับกับงาน Agile Tour Bangkok 2016 เป็นครั้งแรกเหล่าที่ Staff แห่ง agile66 ตัดสินใจทำอะไรใหม่ ๆ ในหลาย ๆ เรื่อง ทั้งเรื่อง International Conference 2 วัน การผสมรูปแบบการจัดงานให้มีทั้ง Fixed Session และ Open space ในงานเดียว (ถึงแม้จะมี Comment ว่ามันอาจจะไม่ใช่ Open space แต่มันคือ Un-conference ก็ตาม ก็ปรับกันไป) รวมถึงการมี Speaker จากหลาย ๆ มุมมอง และการมี Workshop ทั้งก่อนและหลังงาน Conference ซึ่งแต่ละอย่าเป็นสิ่งที่ต้องใช้ Effort สูงขึ้นเยอะมาก แต่สุดท้ายหลาย ๆ อย่างก็ผ่านไปได้ด้วยดี คงต้องขอขอบคุณทุกคนที่เกี่ยวข้องมาไว้ ณ ที่นี้ด้วย จริง ๆ แล้วมีหลาย ๆ อย่างที่อยากเก็บเป็นความรู้สึกที่ดีไว้แต่ ผมมันพวกซาดิส ชอบเก็บอะไรที่ฟังแล้วมันเจ็บแปล๊บ อาจจะเป็นเพราะผมอยากจะได้เตือนตัวเองว่า นี่คือสิ่งที่เราเคยเจอนะ เราก็เคยคิดหรือเคยเจออะไรแบบนี้นะ เวลาไปเจอเหตุการณ์แบบเดียวกัน เราจะได้ไม่ลืมว่าการอยู่ตรงนั้นเรารู้สึกยังไง หรือเราอยู่กับมันยังไง ซึ่งงานนี้ก็ไม่ทำให้ผมผิดหวังเลย และคนที่ทำให้ผมสามารถสมหวังทุกครั้งก็ไม่ค่อยจะพ้นพี่คนนี้ครับ … พี่ @roofimon แห่ง Odd-e Thailand นั่นเอง

presentation1

เริ่มต้นก็ฮาหล่ะ

คำถามแรกหลังจากที่พี่เขาพร้อมสำหรับการแชร์คือ มีฝรั่งในห้องไหม ขอพูดเป็นภาษาไทยได้ไหม (ผมนี่ลุ้นเลยว่าจะมีฝรั่งอยู่ในห้องไหม) ซึ่งทุกคนมองซ้ายมองขวาแล้วไม่มี จึงออกมากลายเป็น Session ภาษาไทย (ถ้ามีฝรั่งอยู่สงสัยถูกเชิญออก 555+) หลังจากนั้นก็เป็นเกริ่นและแนะนำกันเล็กน้อยเกี่ยวกับทั้งตัวแกและ Odd-e ที่แกดูแลอยู่ ที่ทำทั้งในส่วนของ Training, Coaching และ Delivery Team #แอบขายของตลอด บวกกับเล่าให้ฟังว่าเคยมาพูดใน Agile Tour ครั้งที่แล้ว แล้วก็กลายเป็นเรื่อง Talk of The Town กับคำพูดนี้

14753334_10154626000935682_3212200140833958650_o

หลังจากที่เล่าที่มาที่ไปของตัวพี่เขา และสิ่งที่พี่เขาสร้างความฮือฮาไว้แล้ว ก็มาเริ่มที่หัวข้อจริง ๆ สักที โดยเริ่มจากที่แกให้เราดู Code อยู่ 2 หน้า แล้วถามว่า Code แต่ละอันที่ให้ดูไม่ดียังไง แต่มันไม่จบที่แค่ตรงนั้น คำถามที่สำคัญคือ ทำไมเราถึงต้องรู้หล่ะว่า Code เราดีหรือไม่ดี เพราะยิ่งถ้าเราอยู่กับสิ่งไม่ดี โดยที่เราไม่รู้ตัว มันก็ไม่ต่างกับนั่งทำงานอยู่ข้างกองขยะ ซึ่งพี่เขาเล่าให้ฟังถึงประสบการณ์ในการไปเรียนในที่ ๆ นึง ซึ่งเป็น รร ที่อยู่ข้าง ๆ กองขยะ การย้ายไปที่นั่นในครั้งแรก และต้องทนอยู่กับลมที่พัดพา กลิ่มเหม็น และความสกปรกมาอยู่เป็นประจำ ทำให้เด็ก ๆ ที่ไปเรียนป่วยกันไปตาม ๆ กัน แต่หลังจากพ้นไประยะนึง เมื่อมีหน่วยงานอะไรสักอย่างมาสำรวจความรู้สึกของเด็ก ๆ ที่มี รร อยู่ข้างกองขยะ กลับกลายเป็นว่าเด็ก ๆ กลับตอบว่าก็ไม่มีอะไรนี่ มันก็เป็นแบบนี้แหละ เป็นแบบนี้มานานแล้ว ไม่เห็นจะเป็นไรเลย ซึ่งมันคล้ายกับเรื่อง Boiling Frog ของเมืองนอกที่สุดท้ายกว่าจะรู้ว่าที่ ๆ เรา อยู่นั้นเป็นอันตรายกับเราก็สายไปแล้ว ไม่สามารถออกจากวังวนนั้นได้แล้ว

Legacy Code คืออะไร ?

ย้อนกลับมานิดนึงกับคำถามที่ว่า “แล้ว Legacy Code มันคืออะไรหล่ะ” หลาย ๆ คนพอได้ยินคำว่า Legacy … ทุกคนมักจะเข้าใจว่ามันคืออะไรที่เก่า ๆ ไม่ว่าจะเป็น Legacy Code หรือ Legacy System ในส่วนของ Legacy System ก็มักจะหมายถึง ระบบเก่า ๆ เช่น ระบบที่สร้างจาก COBOL, VB, C หรือ C++ หรือแม้กระทั้ง ที่เขียนด้วย Java แต่เป็น Java สมัยแรก ๆ แต่จริง ๆ แล้ว System ที่ทำอยู่ปัจจุบัน Code ที่พึ่งเขียนเมื่อวาน มันก็กลายเป็น Legacy ได้อย่างง่าย ๆ ซึ่งในความหมายนั้น การเขียน Code ที่ไม่ดี การเขียน Code ที่ยากต่อการ Maintenance ก็ Legacy Code (หรือตามที่ผมเคยได้ยินบ่อย ๆ มันก็คือ Code ที่ไม่มี Unit Test) ดี ๆ นี่เอง ทำให้ผมเองก็ไปเข้าใจว่า Legacy Code = Bad Code มาตลอด จนพี่รูฟมาเล่าให้ฟังว่า Bad Code นี่ถึงแม้จะเลวร้าย แต่ก็ยังไม่เท่าที่แกไปเจอมา

4 สัญญาณ ที่ หยุดคุณไว้

เนื่องจากประสบการณ์อันยาวนานทั้งเขียน Code มาเอง เป็น Architecture ในองค์กรที่เป็น Enterprise รวมถึงช่วงหลังที่เข้าไป Coaching ตาม Site ลูกค้า แกจับ Pattern บางอย่างในองค์กรระดับ Enterprise ที่ทำให้การทำงานต่าง ๆ ไม่สามารถตอบสนองได้ทัน และเป็นตัวที่ฉุดให้พวกเราเหล่า Developer ไม่สามารถพัฒนาตัวเองได้ อยู่ 4 เรื่อง ดังนี้

  • Dude Decompile : เฮ้ … เอาจาก Production มา Decompile ดูสิ Source Code หน่ะเหรอ ไม่มีหรอก
  • The Holy Laptop : นุ่น ๆ จะ Compile/Build ?? ต้องไปที่เครื่องนุ้นเท่านั้น ไปขอร้องไอ้ … ให้ Build ให้หน่อย
  • Magic Version : อะไรนะตอนนี้บน Production เป็น Version ไหน ??? ไม่แน่ใจเหมือนจะ Copy มารวม ๆ กันนะ
  • Bad Code : #อันนี้เล่าแล้ว

Dude Decompile : No Source Code

จริง ๆ ตอนที่พี่แกพูดเรื่องนี้ครั้งแรกผมนี่สะอึกเลย ความทรงจำอันเลวร้ายสมัยละอ่อน เหมือนนตามมาหลอกหลอนผมเลย Pattern ของปัญหานี้เป็น Pattern ที่ถือว่าเลวร้ายที่สุดแล้วกับการ Due กับ Legacy Code/Legacy System เพราะคุณแทบจะไม่มีสิ่งที่สำคัญที่สุดในการพัฒนา Software หรือก็คือ Source Code ที่มั่นใจว่าใช่ได้ในมือเลย เหตุที่ผมสะอึกกับข้อนี้เป็นเพราะผมเคยเจออารมย์แบบนี้ในองค์กรน้อย/ใหญ่ มาเหมือนกัน ระบบที่ผมเจอเป็นระบบที่ส่งต่อกันมาเป็นทอด ๆ โดยเริ่มต้นมาจากที่ ทางบริษัทจ้าง Outsource ให้มาทำระบบนี้ และสัญญาว่าจะส่งมอบ Production System พร้อม Source Code ของระบบ แต่ที่สุดแล้วเราแยกทางกันโดยที่มี Production Code ที่ Compile พร้อมใช้ระดับนึงบน Production แต่ไม่มี Source Code หรือถึงจะมี ตอนนั้นก็ไม่รู้ว่า Source Code ที่เขาส่งมาให้ใช้งานได้จริงไหม ประมาณว่ามีก็ให้คิดซะว่าไม่มีแล้วกัน

สิ่งที่ผมเข้าไปตอนนั้นแล้วเจอคือ เวลาที่มี Change หรือ Issue อะไรที่ต้องแก้ไขระบบ ก็จะต้องทำตามขั้นตอนดังนี้

  • การประเมิณด้วยประสบการณ์ว่าน่าจะต้องแก้ที่ File ไหน Class ไหน (เป็น Java Project รันบน Web) แล้วไปหยิบ File นั้นลงมา (.class)
  • ทำการ Decompile แล้วดูว่าใช่จุดที่เราต้องแก้ไหม ถ้าไม่ใช่ก็วนเลือกจนกว่าจะเจอจุดที่เราคิดว่าจะแก้ไข
  • เอา File Class นั้นมาวางทับ Source Code ที่อยู่ในเครื่อง Local ของ Development (Source Code บนเครื่อง Local เป็น Source Code ที่มาพร้อมกันตอนส่งงาน แต่ไม่มีใครกล้าให้ความมั่นใจ ว่ามันเหมือน Production)
  • แก้ Code #ทนกับอะไรบางอย่างที่ Decompiler แปลงมา #ลุ้นไปด้วย
  • หลังจากแก้ตามความต้องการของลูกค้าแล้ว ก็จะทำการ Compile/Build เพื่อให้ได้เป็น File .class แล้วเอา Class ที่ได้ไปวางทับบนเครื่อง QA (ที่ซึ่ง Copy ทุกอย่างจาก Production มายังเครื่องที่จะใช้ในการทดสอบ เพื่อให้มั่นใจว่าเรามีที่ให้เราทดสอบหลังแก้)
  • แล้วทำการทดสอบว่าระบบทำงานได้ไหม ซึ่งก็ไม่รู้หรอกว่ามันนกระทบตรงไหนบ้าง เพราะ Source Code ที่จะใช้วิเคราะห์ Impact ก็มีไม่ครบ จะให้ Decompile ทุกตัวก็ใช่ที่
  • เมื่อเกิดปัญหาอะไรที่ QA ก็จะเอา File .class จาก Production มาวางทับแล้วเทสดูว่า File ที่เราแก้ไปทำให้มี Bug ไหม หรือจริง ๆ เป็น Bug เก่า #นรกทั้งคู่ และจนวนอยู่ แถว ๆ นี้จนพอจะมั่นใจ #บางครั้งงานเร่งก็…
  • เมื่อมั่นใจก็จะเอา Class ไปวางบน Production แล้วทำการ Restart เพื่อ Release
  • อะ ๆ ๆ ๆ อย่าลืมเอา File เก่ามา Backup เก็บไว้ด้วยนะฮะ #แล้วมาบอกอะไรบรรทัดนี้
  • โดยที่ถ้าจะไม่ผิดตอนนั้นจะเริ่มมีเก็บ Version ของ File Class ที่ถูก Backup ก่อน Release อยู่เหมือนกัน โดยสร้าง Folder backup ไว้แถว ๆ นั้น แล้ว Copy File Class เก่าไปวาง โดย Copy เป็น someclass.class.1, someclass.class.2, someclass.class.3 … someclass.class.lastest

คุณมองเห็นไหมครับ รู้สึกเหมือนผมไหมครับ ว่าทุก ๆ Step ในการทำงานมีแต่ความเสี่ยง ความไม่รู้ และมีความน่ากลัว ซ่อนอยู่เอาไว้ในนกระบวนการทำงาน ตั้งแต่ Decoompiler ก็จะสามารถทำได้แบบ 100% การแก้บน Source Code ที่ไม่มีใครรู้เลยว่าใช่ไหม ยังไม่รวมพวก Static Class/Method ต่าง ๆ รวมถึงเรื่องการเอาขึ้นไปเทสบน QA และการ Deploy บน Production ถ้าคุณยังเจออะไรแบบนี้อยู่ ถ้าคุณยังทำงานโดยไม่มี Source Code ที่ใช้ได้จริงอยู่ คุณกำลังอยู่ในเรื่องแรก Dude Decompile

The Holy Laptop : Source Code with only one machine, can ฺcompile/build.

Pattern นี้เป็น Pattern ที่ดีขึ้นมาหน่อย คือคุณมี Source Code ที่สามารถเชื่อถือได้แล้วว่า นี่แหละคืออันเดียวกับสิ่งที่อยู่บน Production System เพียงแต่ มันจะมีเครื่อง Laptop เพียงเครื่องเดียวในโลกนี้เท่านั้นที่สามารถจะ Compile/Build เพื่อเปลี่ยนจาก Source Code เป็น Executable Product ได้ เครื่องอื่น ๆ ในโลกนี้อย่าได้หวัง และเครื่อง Laptop นี้มักจะเป็นมรดกตกทอดจากรุ่นสู่รุ่น ห้าม Upgrade OS/Software ภายในเป็นอันขาด ห้ามแม้กระทั้งติดตั้งหรือ Remove Application บางตัว เพราะไม่รู้ว่าจะกระทบกับการ Compile/Build ที่ทำได้อยู่ไหม เราเรียก Laptop เครื่องนี้ว่า The Holy Laptop โดยปกติ The Holy God มักจะได้รับดูแลเป็นอย่างดี มีที่ประจำให้อยู่ แถมคนที่จะสามารถทำงานกับเครื่องดังกล่าว จะต้องเป็น The God ที่มี Skill ในระดับที่สยบพลังของ The Holy Laptop ได้ และส่วนมากในทีมใด ๆ มักมี The God เพียงผู้เดียวเท่านั้น การจะที่ใครในทีมจะ Compile/Build เพื่อเอา Executable Product ไปทดสอบ หรือใช้งานต่อ จะต้องมาสักการะ The Holy Laptop และขอร้อง The God เพื่อดำเนินการให้ ถ้าเราถามว่าเกิดเครื่อง The Holy God เจ๊งไป เราจะทำยังไง สภาวะเงียบงันจะเกิดขึ้นทันที …

Magic Version : Production System that deployed unknown version into.

มาถึงจุดที่เรามี Source Code แล้ว เครื่องของพวกเราก็สร้าง Compile/Build ได้ด้วยตัวเองแล้ว สิ่งสำคัญอีกเรื่องคือการเอา Source Code ไป Deployed บน Production การที่แต่ละคนมี Source Code แล้วต้องส่ง Source Code ที่แก้เสร็จ เสียบ Thumb Drive Copy จากเครื่องนนึงไปยังอีกเครื่องนึง ก็จะทำให้เราไม่มีทางรู้ได้เลยว่า Build ล่าสุดเกิดที่ไหน หรือใครเป็นคนทำ มี Source Code แต่ก็ไม่รู้ว่าบน Production ที่ Deploy ไปมี Source Code ที่แก้เรื่องอะไรมาจากไหนบ้าง

Bad Code : เรื่องสุดท้ายคือ Bad Code ซึ่งพูดถึงตอนต้น ๆ แล้ว

คำถามคือ ทำไม Manager หรือคนที่อยู่ระดับ Management ควรเข้าใจ ? เพราะ Legacy Code มีผลกับองค์กรหน่ะสิ 

  • ไม่มีใครได้เรียนรู้กับการอยู่กับ Legacy ลักษณะนี้ นำพาไปสู่ปัญหา Turnover Rate ของพนักงานที่มีความรู้สึกว่า อยู่ไปก็ไม่เห็นได้อะไร ยาวไปถึงนี่มันเป็นงานที่ไม่ใช่ แล้วก็หันเหออกจากวงการพัฒนา Software ในที่สุด
  • ค่าใช้จ่ายในการเปลี่ยนแปลงสูงมาก
  • มันมักจะเป็นบ่อเกิดของ Legacy System ใหม่ ๆ และกลายเป็นวงจรอุบาทว์

เพราะฉะนั้นสิ่งสำคัญคือ ทำอย่างไรใช้ Change ที่เกิดขึ้นนมันจ่ายน้องลง เวลาหรือ Effort ในการทำ Regression ให้ถูกกว่า และกลับมาให้ความสำคัญกับ Technical Excellence เพื่อเพิ่มความคล่องตัวในการทำงาน

รู้แล้วยังไงหล่ะ ก็มันเป็นแบบนี้มาแต่แรกนะ

แนวคิด Agile ไม่ได้ Focus ว่าเราจะทำอะไรครับ แต่เริ่มจากเราเองอยู่ตรงไหน เป้าหมายปลายทางคืออะไร และเราจะดีขึ้นหรือเข้าถึงเป้าหมายมากขึ้นได้อย่างไร เพราะฉะนั้นการที่เรารู้ตัวเองว่า System ที่เราดูแลอยู่ตกอยู่ใน Pattern ไหน ก็จะเป็นตัวตอบโจทย์ว่าสภาวะปัจจุบันของเราเป็นอย่างไร เราจะไปยังจุดไหน แล้วเรามองว่าเราจะพัฒนาตัวเองต่อไปในเรื่องใด ถ้าคุณยังอยู่ในสภาวะที่ 1-3 อย่าหวังจะมี Continuous Integration/Continuous Delivery เลย ดับไฟพวกนี้ก่อน เพื่อให้ชีวิตของเราดีขึ้น ซึ่งจริง ๆ แล้ว Pattern ทั้ง 4 ที่กล่าวมาสามารถพัฒนาต่อยอดได้ประมาณดังนี้

  • Dude Decompile : ตามหาแหวนแห่งมอร์ดอร์ เย้ย … ตามหา Source Code ที่แท้จริงของระบบนนี้ให้เจอ อาจจะต้องรวบรวมจากหลาย ๆ ทีม หรือแม้กระทั่ง Decompile ใหม่หมด (ผมเคยใช้เวลา 3-5 ปี ในการค่อย ๆ ปรับ ค่อย ๆ  Test จากที่ไม่มี Source Code ให้ค่อย ๆ กลายเป็นมี Source Code ที่สามารถใช้งานได้จริงบน Production ขึ้นมา)
  • The Holy Laptop : ศึกษา Tools ประเภท Project (Compile/Build) Management เช่น Marven, Gradle หรือ Tools อื่น ๆ เพื่อให้เครื่องที่จะ Compile/Build เป็นเครื่องที่ Lean ที่สุด และมีผลทำให้ทุก ๆ เครื่องในทีมสามารถ Compile/Build โดยใช้ Command Line เพียง Command เดียว
  • Magic Version : ศึกษา Source Code Management Tools เช่น Git, SVN หาทางสร้าง Build Pipeline เพื่อเตรียมสำหรับ Continuous Integration/Continuous Delivery
  • Bad Code : Refactoring, Clean Code

ในส่วนของ Programmer/Developer คุณอยู่ในโลกของการพัฒนา Software คุณเองมีพลังอันยิ่งใหญ่ที่จะสร้างอะไรก็ได้จากมือของคุณ คุณแทบจะเหมือนกับเป็นเทพเจ้าผู้สร้างโลกก็ปาน Software ทุกตัวที่ออกมาบนโลกนี้ และคอยควบคุมทุกอย่างอยู่ในตอนนี้ เกิดจากฝีมือของ Programmer/Developer ทั้งนั้น แต่แน่นนอน “พลังอันยิ่งใหญ่ มาพร้อมความรับผิดชอบอันใหญ่ยิ่ง” #ลุงเบน เพราะฉะนั้นสิ่งสำคัญคือการควบคุมพลังของคุณเอง ไม่ให้ไปทำความเดือดร้อนให้ใคร รู้จักที่จะช้าลง รู้จักที่จะหยุดดูสิ่งที่ทำอยู่ แล้วหาทางพัฒนาตัวเองให้เก่งขึ้นเรื่อย ๆ เก่งขึ้นไปกว่านี้อีก

สุดท้ายสามารถเข้าไปดู Slide ได้ที่ Slideshare นะครับ

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