Make a better with clean code

Editor's Notes

• #3: 1. ผมอยากให้ ทุกคนเข้าใจก่อนว่า ภาษาผมไม่ค่อยแข็งแรง ดังนั้น ถ้ามีอะไรผิดพลาด ต้องอภัยล่วงหน้าไว้ ณ ที่นี้ 2. ถ้าคุณฟังแล้วมีความรู้สึกว่าไม่เข้าใจ ให้กลับไป ดูข้อ 1 3. Session นี้อาจจะมีคำไม่สุภาพ อย่าไปซีเรียสนะ 4. สิ่งที่ผมพูดใน Session ยังไม่ถือว่าเป็นของดี คุณไม่ควรเชื่อมันเพราะผมบอกว่าดี แต่น่ารับฟัง พิจารณา และลองด้วยตัวคุณเอง First of all, I want you all to understand that I’m not fluent in English. I apologize for any mistake that might occur. If you have trouble understand my presentation, please refer to previous one. This session may contains strong language, please don’t mind it. What I said might not correct or suit your need entirely, please use you own judgement when listening.
• #6: ในห้องนี้ มีใครรู้จัก Clean code บ้างไหม ? ทีนี้ก่อนที่เราจะมาคุยกันเรื่อง Best Practice ผมอยากจะมาคุยว่า ทุกวันนี้ Developer เจออะไรกันบ้าง ซึ่งผมจะแนะนำให้คุณรู้จัก Code Smell Does anyone in this room familiar with “Clean Code”?Now, before we are going to talk about “Best Practice”, I want to discuss what developer encountered everyday. In which I will introduce you to “Code Smell”.
• #7: เคยไหม ที่อยู่ๆ ก็ต้องเข้าไปแก้งานคนอึ่น ซึ่งภายนอก นั้นดูสวยงาม ทุกอย่าง Product Owner/ PM อยากให้เราช่วยแก้ ซึ่งบางที มันดูเป็นการแก้ง่ายๆ แต่ความเป็นจริงแล้ว Have you ever need to work on someone else’s project? It look nice and neat from the outside and Product Owner/PM just want you to fix/change a minor stuff. Should be a piece of cake, right?
• #8: คุณกลับพบแต่ code ขยะเต็มไปหมด และไม่เป็นระเบียบ ไม่มีการแบ่งหรือจัด code ให้คุณอ่าน คุณต้องเสียเวลาอย่างมาก ในการที่จะหา สิ่งที่คุณจะแก้ และเมื่อมองดู Dependency However, what you found is an unorganized code, full garbage. You have to spend lot of time just to understand the code and find what you needs to fix. Then when you look at the dependency….
• #9: คุณก็พบว่า มันมีความซับซ้อน มากๆ คุณต้องเสียเวลา นั่งไล่ code ยาวๆ คุณเริ่มรู้สึก อยากจะไปเรียก dev คนเก่ามาแก้แทนคุณ ผมคิดว่าคุณน่าจะอารมณ์เสียแบบนี้ You found that it’s so complex and you need to spend long hours going through the code. Then you start to feel like getting the owner of the code to fix the mess instead. I’m sure you’ll be upset if this ever happen to you.
• #10: ทีนี้ เมื่อ code มันแย่อย่างนี้ แน่นอน สิ่งที่เรียกว่า Bug มันจะตามเป็นเงาตามตัวคุณ จนคุณปวดหัว Now, when the code is such mess. It’s inevitable that there will be a heap load of thing called “Bug”. An endless headache for you.
• #12: สิ่งที่น่ากลัว อีกอย่างก็คือ เพื่อนในทีม เพิ่งลาออกไป แล้วคุณต้องรับมาดูแลแทน คุณโอเคแค่ไหนที่จะรับ code ของเค้ามาดูแลแทน ? One thing that is scary is when your colleague resign and you have to takeover his/her works. Is it going to be OK?
• #13: ซึ่งเวลาคุณแก้ คุณคงเคยมีอารมณ์เหมือนในรูปนี้ ทำไมมันถึง ทำงานได้ หรือ ทำไม มันทำงานได้ ? นั้นแสดงว่า คุณไม่เข้าใจ code นั้นแหละ นั้นน่ากลัวมาก หมายถึงว่า code ที่อ่านนั้น มันอ่านยาก !!! Now, once you start working on the code you might run into a moment like this. “It’s working…why?, It doesn’t working….why?” This indicate that you don’t understand the code. Which mean that the code is hard to read and understand!!
• #14: มันมีคำพูดติดตลก ว่า มันไม่ใช่ Bug มันคือ Feature มันอาจฟังดูตลก แต่สำหรับผม มันน่ากลัวมาก เพราะว่าเค้าละเลยสิ่งที่เรียกว่า Test There’s this catch phase “It’s not a bug. It’s a feature!” Now, it might sound funny but for me it’s scary because that mean his/her ignore a process called “Test”.
• #15: หลายๆ คนคงเคยได้ยินสิ่งที่เรียกว่า Unit Test, TDD, BDD แต่ Dev ส่วนใหญ่ มักไม่สนใจ ที่จะทำมัน เพราะอะไร ? เพราะมันเสียเวลา ? หรือ เพราะไม่รู้จะทำยังไง ? Many of you might have heard about Unit Test, TDD, BDD. But why does most developer ignore these thing?Is it because it’s time consuming? Or because they don’t know how to do it?
• #16: ทีนี้ เมื่อ code คุณอ่านยากมาก เข้าใจมาก แถมไม่มี Test พอ deploy ขึ้น production และเกิด bug นี่คือสิ่งที่จะเกิดขึ้นกับคุณ คุณมี SLA ที่คอยบีบคุณ คุณแก้แต่ปัญหาเฉพาะหน้า ให้ผ่านพ้นไป จนละเลย สิงที่จะตามมาในอนาคต Here is what will happen to you when you have a messy and untested code deployed to production. You’ll have SLA which force you to keep fixing these issue the came up to the point where you ignore the consequences.
• #17: สุดท้ายแล้ว คุณทำสำเร็จ สามารถแก้สถานการณ์ไปได้ คุณกลายเป็น HERO คุณรู้สึกดี ทุกคนต่างชื่นชมคุณ In the end, if you made it. Everyone will hail you as a “HERO”
• #18: คำถาม คือ มันจริง หรือ ? การทำแบบนี้ เป็นสิ่งที่ควรทำจริงๆ หรือ ? But the question remain. Are you really a hero? Is this how it should be done?
• #19: Dev บางคน อาจจะบอกว่า แบบนี้ถูกต้องแล้ว เพราะเราก็ทำกันแบบนี้มาตลอด Some developer might say that it’s alright. We always do it like this.
• #20: ทีนี้ มีคน เมื่อคุณได้เห็น สิ่งที่มันแย่ๆ มาแล้ว มีคนที่ประสบพบเจอ เรื่องแบบนี้ มากมายในโลกของ Software Developer และนิยาม สิ่งเหล่านี้ว่า Code Smell Now many people which has ran into these situation in the development world has define and called it “Code Smell”.
• #21: คุณ Martin Fowler Programming Coach, นักเขียน และ Software Architect อันดับต้นๆ ของโลก ได้กล่าวไว้น่าสนใจเกี่ยวกับ code smell ว่า “Code Smell คืออาการของ สิ่งที่เรียก ดีไซน์แย่ๆ หรือ การทำอะไรแย่ๆ” Martin Fowler, a programming coach, author and world class software architecture has something interesting to say about code smell: “CODE SMELL ARE SYMPTOMS OF POOR DESIGN OR IMPLEMENTATION CHOICES”
• #22: คุณเข้าใจไหมว่า code ชุดนี้ทำงานยังไง? ผมเชื่อว่าหลายคนไม่เข้าใจ มันทั้งอ่านอย่าง ไม่มี code format ที่สบายตา ตั้งชื่อแบบไม่ใส่ใจ และแลดู สับสนมากๆ Can you understand this code? I’m sure that most don’t. It’s difficult to read, no format, no proper naming. So confusing.
• #23: หลายๆ คนมักชอบเขียน เงื่อนไข ในโปรแกรม แบบนี้ ผมเรียกมันว่า “Hell Condition Stage” คำถาม คุณเข้าใจ ไหมว่า เงื่อนไขนี้ ต้องการทำอะไรกันแน่ ? Many programmer like to implement a condition in program like this. I called it “Hell Condition Stage” Here a question! Do you understand what’s the purpose of these conditions?
• #24: แน่นอนละ คุณไม่เข้าใจ Of course, you don’t understand.
• #25: เราลองมาดู code ชุดนี้ คุณจะเห็นว่า code นี้ มี context ที่กำกวม มี code ที่ทำงานคล้ายๆ กันจำนวนมาก Code ยากต่อการอ่านและทำความเข้าใจ และ code แลดู complex Now take a look at this code. You will see that the context is so ambiguous. There are many duplication in the code. The code seem complex, hard to read and understand.
• #26: คุณอาจจะบ่น เหมือนที่ Bug Lightyear บ่น You might have the same complain as Bug Lightyear
• #27: ถึงขนาด โอบีวัน ทนไม่ไหว จนต้องตะโกนว่า Even Obi-wan cannot stand it and have to shout!!!
• #28: ทีนี้เราลองมาดู ลักษณะของ Code Smell อันนี้เป็นส่วนหนึ่ง ของ code smell แต่ผมขอหยิบยกมาเฉพาะสิ่งที่เข้าใจง่ายๆ ก่อน คุณสามารถ ลองหาใน google คุณจะพบ code smell อีกเป็นจำนวนมาก Now, let’s take a look at characteristic of code smell. What I list here is just a simple one. If you google “Code Smell” you will find many more.
• #29: เราลองมาดูว่า ทำไม Comment ใน Code ถึงเป็น Code Smell สิ่งที่ผมจะบอกก็คือ การที่คุณมี Comment มากๆ นั้นไม่ได้ช่วย ให้ Code อ่านง่าย กลับกัน มันทำให้ ยิ่งอ่านยาก มันแสดงถึงว่า code คุณนั้น เข้าใจยาก คุณถึงต้องมี comment !! Now let’s take a look as to why comment in the code is considered “Code Smell”? What I want to tell you is that a lot of comment doesn’t necessary make code easier to read. Instead it just an indication that you code is hard to understand. That’s why you need comment!
• #30: คุณคงเคยเขียน method หรือ function ที่มันยาวๆ แต่ทำไมมันถึงเป็น code smell ล่ะ เพราะว่า มันอ่านยาก เข้าใจยาก และมัน complex และมันอยากต่อการ test ด้วย You might have implement a long function or method before. But why does it considered a “Code Smell”? That’s because long function/method are complex, hard to read and understand. It’s also difficult for testing.
• #31: การที่ method หรือ function require parameter จำนวนมาก แสดงให้เห็นว่า method นี้มีความ complex สูง Test ยาก และ เข้าใจยาก เหมือนกับ Long Method Same as long method/function. A function/method that require a lot of parameter has a high complexity. It’s hard to understand and test.
• #32: Duplicate code เป็นสิ่งที่ ควรใส่ใจ เพราะ การที่คุณมี code ที่ทำงานเหมือนกัน ซ้ำๆ จำนวนมาก มันส่งให้คุณ maintain ได้ยาก เพราะคุณจะต้อง ตามไปแก้ ทุกๆ ส่วนที่มัน duplicate You should be mine of duplicate code. The more duplication you have, the harder it is to maintain. If you need to fix/update the portion of the code that has duplication then you will need to go and update all of the duplicate one as well.
• #33: อันนี้คุณคงเคยเห็นแล้ว We already talk about this one.
• #34: Large class สิ่งที่น่ากลัวขอบมันคือ God Class มันคือ class ที่มีการทำงานหลายๆ อย่าง ด้วยกัน โดยอาจจะทำนอกเหนือ context ที่มันควรจะเป็น มี dependency ซับซ้อน ซึ่งจริงๆแล้ว แต่ละคลาสควรมีการทำงานที่ชัดเจน A large class a.k.a god class is a class that contains many functionality. It may even contains a function that is out of its context, has a complex dependency. A class should have a clearly define functionality.
• #35: สิ่งสำคัญของการอ่าน คือ ชื่อจะต้องสื่อความหมาย ดังนั้น การเขียน ชื่อตัวแปร method class แล้วมีการใช้ ชื่อย่อ หรือ การตั้งชื่อไม่เป็นไปตาม naming convention เป็นสิ่งที่ควรใส่ใจ It’s important to have a meaningful name for a variable. Using abbreviation or not following proper naming convention could lead to confusion.
• #36: สุดท้าย code ที่ไม่มี test คุณมั่นใจได้อย่างไรว่า code ที่คุณเขียน จะทำงานได้ตามที่คุณคิด ? How can you be sure that your code is working as design when you have never test it?
• #37: Code smell คือหนทางสู่ Dark side การออกแบบแย่ๆ นำไปสู่ ความซับซ้อน ความซับซ้อน นำไปสู่ การบำรุงรักษษที่ลำบาก การบำรุงรักษาที่ลำบาก นำมันไปสู่ Bug CODE SMELL IS THE PATH TO THE DARK SIDE. POOR DESIGN LEADS TO COMPLEXITY. COMPLEXITY LEADS TO UN-MAINTAINABLE. UN-MAINTAINABLE LEADS TO BUGS.
• #38: ทีนี้ เราจะทำยังไงกับ code smell กันดี Now, what should we do with code smell?
• #39: My suggestion is to become “Jedi Clean Coder” ผมขอแนะนำให้ทุกคน มาเป็น Jedi Clean Coder
• #40: First of all let be introduce you to the book for people who want to know about clean code. อันดับแรก ผมขอแนะนำหนังสือ สำหรับคนที่ต้องการรู้เกี่ยวกับ clean code
• #41: The Father of C++ Programming has to mention to clean code like this Elegant and efficient. It mean your code should clean and easy to maintain ?
• #42: Grady Booch an author of “Object Oriented Analysis” has mention about clean code: Clean Code is simple and direct. Clean code reads like well-written prose. It mean you care everyone in team. คุณ กราดี้ บูช ผู้เขียนหนังสือ Object Oriented Analysis ได้กล่าวถึง clean code ไว้ว่า “Clean code คือ สิ่งที่เรียบง่าย และ ตรงไปตรงมา” “Clean code เหมือนนิยาย ที่ถูกเขียนมาอย่างสวยงาม”
• #43: Michael Feathers an author of Working Effectively with Legacy Code has said: Clean code always looks like it was written by someone who cares. คุณ ไมเคิล เฟทเทอ ผู้เขียนหนังสือ Working Effectively with Legacy Code ได้กล่าวไว้ว่า มันเกี่ยวกับ ความใส่ใจ clean code คือ การที่เรา ใส่ใจในสิ่งที่เราเขียน เพื่อให้คน ที่คุณใส่ใจ
• #44: Robert C Martine or Uncle Bob, Programmer and author Say something about clean code inspire from boy scout rule Whenever you find your source code dirty. You should clean them up all It’s all about clean code concept สุดท้าย Robert C’ Martin หรือที่เรารู้จักกันในชื่อ Uncle Bob นักเขียน และ software engineer ชื่อดัง และเป็นผู้เขียนหนังสือ Clean code A handbook of Agile Software Craftsmanship ได้เล่าถึงแรงบัลดาลใจ ของ clean code เค้าพูดไว้ว่า มันเหมือนกฎของ ลูกเสือ เวลาเราไปตั้งแคมป์ในป่า ลูกเสือจะต้องรักษาความสะอาดของแคมป์ และจัดการมันทุกครั้งที่พบมัน มันฟังดู ทำให้เราเห็นภาพของ clean code มากยิ่งขึ้นไหม
• #45: Jedi has principle to force you to solve problem not making a problem
• #46: ส่วนหนึ่งของ Clean code ให้ความสำคัญอย่างมากคือ การตั้งชื่อ ให้นึกว่าเวลาคุณอ่านนิยาย ถ้านิยายเรื่องนั้น มีการใช้ศัพท์ ที่เข้าใจยาก และ มีการจัดเรียงตัวอักษร ที่สะเปะสะปะ คุณคิดว่านิยายเรื่องนั้น น่าอ่านหรือไม่? เช่นเดียวกันกับ software มันคือการเขียนนิยาย ในรูปแบบของ code เพื่อให้มันทำงานตามที่เราต้องการ แล้วเพื่อให้มันอ่านรู้เรื่อง ดังนั้น Developer ส่วนใหญ๋ มักใช้เวลากับการคิด ชื่อ เป็นส่วนใหญ่
• #47: ลองดูที่กราฟตัวนี้ คุณจะเห็นได้ว่า Programmer มีสิ่งที่ต้องทำจำนวนมาก และสิ่งหนึ่งในนั้น ที่กินเวลาเกือบครึ่งคือ “Naming things” แปลว่า จริงๆ แล้วการคิดเชื่อมีความสำคัญอย่างมาในการพัฒนา software
• #48: So take care with your names and change them when you find better ones. Everyone who reads your code (including you) will be happier if you do. Uncle Bob กล่าวเอาไว้ในหนังสือ Clean code ไว้ว่า คุณควรใส่ใจกับการตั้งชื่อต่างๆ ใน Software ของคุณ ให้เหมือนกับที่ นักแต่งเพลง ใส่ใจกับ ผู้ฟังที่จะได้ฟังเพลงของเค้า ทีนี้ อีกหนึ่งสิ่งที่จะขาดไม่ได้ ในการเขียน code ให้อ่านง่ายคือ การจัด Formatting ของ code
• #49: Code formatting เป็นสิ่งที่ควรใส่ใจเป็นอย่างมาก ทุกวันนี้ จึงเป็น Practice ที่แต่ละภาษามีข้อกำหนด ทั้งนี้ ถ้ามองให้ละเอียด มันคือ ข้อตกลงของทีม ในการทำงานร่วมกัน ดังนั้นทุกครั้ง ที่คุณเขียนโค๊ดคุณต้องใส่ใจเรื่อง Format ด้วย
• #50: ตัวอย่างนี้ โชว์ให้คุณเห็นถึง Good และ Bad Format คุณจะเห็นว่า Good Format มีการจัดเรียงที่สวยงาม สะอาด และอ่านง่าย ไม่เดือนด้านขวา ที่แลดูรก และไม่เป็นระเบียบ แต่ code ชุดนี้ ยังไม่ถือว่าดีพอ เพราะยังมีปัญหาเรื่องการตั้งชื่อ และการใช้ Comment มากเกินไป
• #51: แหล่งที่คุณจะหาตัวอย่างของ Code Style Guide ได้คือ Google Code Style ทั้งนี้ เมื่อได้ข้อสรุป ให้จัดทำเป็น file config เพื่อไปใช้กับ IDE เพื่อให้ทุกคนใช้ Format เดียวกันทั้งทีม
• #52: การทำให้ code นั้นอ่านได้ เข้าใจได้ง่าย นั้นเป็นสิ่งสำคัญมาก มันเป็นสิ่งที่บอกว่าคุณสนใจทีม
• #56: S > Single Responsibility Principle (SRP) Class, Method ควรจะมีหน้าที่เพียงอย่างเดียว โดยมีคุณสมบัติ เล็ก, ทำงานแบบเจาะจง O > Open/Close (OCP) เราสามารถทำการเพิ่มความสามารถต่างๆ เข้าไปในระบบ โดยที่ไม่กระทบกับส่วนอื่นๆ หรือ กระทบให้น้อยที่สุด L > Liskov Substitution : Sub class หรือ class ลูก ควรมีพฤติกรรมการทำงานตาม Base class หรือ class แม่ I > Interface Segregation (ISP) : Client หรือ User ควร depend on interface ของตัวเอง D > Dependency Inversion (DIP) : Code แต่ละส่วนควร depend on abstraction layer มากกว่า implementation
• #57: "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system“ หลักการ DRY เกิดขึ้นจากปัญหา Duplicate ยิ่งมี Duplicate ใน code มากเท่าไหร่ คุณยิ่งต้องเสียเวลา ในการ Maintain มากเท่านั้น หลักการก็ง่ายๆ คุณพยายาม จับรวมสิ่งที่ สามารถใช้ด้วยกันได้ ให้เป็น service ที่ reuse ร่วมกัน โดยที่คุณยังสามารถ maintain มันได้อย่างง่ายดาย
• #58: Concept สร้างเฉพาะสิ่งที่จำเป็น ลดการสร้างขยะ เมื่อลดเวลาสร้างขยะ ทำให้ประหยัดเวลา ประหยัดงบประมาณ ทุกสิ่งที่คุณทำมี Cost
• #59: Developer ส่วนใหญ่มักจะมีข้ออ้างที่ว่า “ฉันยุ่งและไม่มีเวลาจะเขียนเทส” แล้วผลลัพธ์ ล่ะ ? สุดท้ายคุณก็ต้องไปนั่งเทสมืออยู่ดี ซึ่งมันใช่วิธีการที่ดีหรือไม่?
• #60: บางคนถึงขั้นบอกว่า ผมไม่สนเรื่อง Test หรอก แต่จริงๆ แล้วคุณควรสนใจมัน
• #61: TDD คือ หลักการพัฒนา software โดยมีสิ่งที่เรียก Test Cover เอาไว้ทุกส่วน เพื่อ ? ให้ developer มั่นใจในสิ่งที่เขียน และเข้าใจเข้าในสิ่งที่ทำมากยิ่งขึ้น TDD มีข้อดีมากมาย เช่น ลดเวลาการ Debug, การระบุ Bug และทำให้ code ชัดเจนมากขึ้น แต่มันก็มีข้อเสีย คือ ยิ่งคุณใช้ TDD Development Time คุณจะต้องเพิ่มขึ้นเป็น 2 เท่า เพราะคุณจะต้อง คิด Test Case ให้ครอบคลุมมากที่สุด และต้อง maintain test เพิ่มเติมด้วย มันต้องอาศัยความเข้าใจจาก Management ในการที่จะประยุกต์ใช้ TDD ในแต่ละ Project
• #62: เรามาดู Level ของ TDD คุณจะเห็นได้ว่า ยิ่งคุณทำ Test ในระดับสูงมากเท่าไหร่ คุณจะยิ่งต้องใช้เวลา และ cost จำนวนมาก กลับกัน ถ้าคุณทำ Unit Test ในระดับของ code คุณประหยัดเวลา และ ทำได้เร็วกว่า มาก ลองคิดดู การจะ Test หน้า Screen UI สัก 1 page ซึ่งมี ความเป็นไปได้จำนวนมาก หมายความว่า จำนวน Test case ก็สูงเป็นเงาตามตัว ดังนั้นมันจึงกินเวลามาก เมื่อมันกินเวลามาก มันจึงใช้เงินมากตามไปด้วย กลับกัน ยิ่งคุณทำ Test ในระดับ Unit Test คุณสามารถเขียนมันเสร็จภายใน 10 นาที โดยเคสคลอบคลุมตามที่คุณคิดได้ และการทำในระดับนี้ อยู่ในขั้นตอนของ Development ทำให้ปรับเปลี่ยนได้ง่าย
• #65: BDD เป็นหลักการที่ขยายต่อจาก TDD โดย เริ่มมองใน Level ที่สูงกว่า Unit Test มันมองระดับ API หรือ service เราต้องการจะเทสว่า api หรือ service ที่ทำขึ้นมา ตอบสนองต่อ business จริงหรือเปล่า?
• #66: BDD จะมี keyword สำคัญ 3 ตัว ซึ่งคล้าย TDD คือ Given, When and Then Given สิ่งที่เรากำหนดให้ทำ When และเมื่อเกิดเหตุการณ์นี้ Then แล้วจึงเป็น ซึ่งถ้ากลับไปดู TDD จะเห็นว่ามันเหมือน 3A Pattern คือ Arrange, Act, Assert
• #68: อันที่จริงแล้ว มันไม่ได้ต่างกัน มันมี Cycle ที่เหมือนกัน ถ้าจะต่างก็คงจะเป็นคำว่า B และ T มันคือเรื่องของมุมมองที่จะ Test TDD มักจะเป็นมุมมองของ Developer มอง Code ควรจะเป็นอย่างไร แต่ BDD เป็นของ ทุกๆคน ในทีม ที่จะสามารถเข้าใจ ในสิ่งที่ทำ มันเหมือนกัน ดังนั้น เลือกว่า อะไรตอบสนองคุณและทีมจะดีกว่า The difference between BDD and TDD is that BDD begins with a B and TDD begins with a T. But seriously, the gotcha with TDD is that too many developers focused on the "How" when writing their unit tests, so they ended up with very brittle tests that did nothing more than confirm that the system does what it does. BDD provides a new vocabulary and thus focus for writing a unit test. Basically it is a feature driven approach to TDD. http://programmers.stackexchange.com/questions/135218/what-is-the-difference-between-writing-test-cases-for-bdd-and-tdd
• #69: สิ่งที่เป็น code quality คุณอาจจะถามว่า แล้วเราควรจะเขียน test อะไรก่อน ผมแนะนำอย่างนี้ ทุกครั้งที่คุณจะเขียน Test service ใหม่ๆ ให้คุณเขียน ในสิ่งที่คุณ Expect ก่อน มันช่วยให้คุณคิด Test Scenario ได้ง่าย จากนั้น ค่อยมาคิดถึง Worst Scenario test เพราะนั้นถือเป็น Optional
• #70: ทีนี้ สิ่งที่ผมอยาก ให้คุณกลับไปทำก็คือ Commit Clean code ที่มี Test
• #71: คุณ Kent Beck ผู้คิดค้น extreme programming ได้กล่าวไว้ว่า การทำให้ software มันทำงานได้ เป็นการครึ่งทางของงานที่คุณต้องทำ ดังนั้น จงเขียน Test ซะ
• #72: Code review มีใครรู้จักบ้าง ? บางคนอาจจะรู้จัก บางคนอาจจะไม่รู้จัก บางคนอาจจะเกลียด หรือ อาจจะไม่ชอบ เพราะการทำ code review มันเหมือนการ เอาการบ้านไปให้ ครูที่โรงเรียนตรวจ เสียแต่ว่า การตรวจการบ้าน นี้ถ้า ทำด้วย ความคิดที่ถูกต้อง จะเกิดสิ่งที่เรียก อคติ (bias) และสุดท้าย ทั้งคน review และ developer ก็จะเกลียดกันในที่สุด แล้วควรจะต้องทำอย่างไร ?
• #73: อันดับแรก code review จะต้องมี test ถ้าไม่มี test ไม่ควร review
• #74: ถ้า code ยังไม่ clean หรืออ่านยาก ควรให้กลับไปแก้หรือ refactor ก่อน
• #75: วิธีวัด code quality ถ้าคน review แล้วเกิดอาการอยากด่าว่า WTF มากเท่าไหร่ นั้นหมายความว่า code คุณแย่เท่านั้น
• #76: สิ่งที่ review ดูเป็นอันดับแรก คือ clean code การตรวจ code เบื้องต้น โดยหลักๆ แล้วสิ่งที่ Reviewer ใช้เป็น สิ่งชี้วัด ในการ review Code clean or not ? Code can readable ? Class, Method too big? Have duplicate ? Percentage of test coverage ? Follow team standard guide ?
• #77: ทีนี้จะมีการ code review ในระดับสูง ซึ่งจะสนใจในระดับของ Design และ Architecter
• #78: สุดท้าย แล้วการทำ code review มีข้อดียังไง มีข้อดีมหาศาลมาก มันช่วยให้ ให้ developer ที่เป็น junior กว่า เห็นข้อผิดพลาด และ แนวทางที่ควรแก้ ซึ่งจริงๆ แล้ว มันเหมือนการ ชี้แนะของ อาจารย์และลูกศิษย์ อย่างกับ Jedi และ Padawan ซึ่งการทำ code review จะนำไปสู่ อีกขั้นของการ พัฒนา skill ของ developer ในทีม นั้นคือการทำ Pair Programming
• #79: คุณเคยดูหนังเรื่อง Star Wars ไหม คุณรู้ไหมา การที่จะเป็น Jedi ได้นั้น จะต้องผ่านการฝึกจนถึงขั้นหนึ่ง และเมื่อ เติบโต จนสามารถทำภารกิจได้ จะถูกเลือกโดย Jedi Knight/Master เพื่อรับเป็นศิษย์ โดยมีเงื่อนไขว่า ณ เวลาหนึ่ง Jedi หนึ่งคน สามารถมี Padawan ได้เพียงคนเดียวเท่านั้น ไม่มาก ไม่น้อยไปกว่านี้ ทั้งนี้ เพื่อให้การถ่ายทอด ผ่านการทำ ภารกิจร่วมกัน หล่อหลอม Padawan ให้เติบโตจน สามารถเป็น Jedi Knight ได้
• #80: ในชีวิตของ Developer เรามีหลายสิ่งที่ต้องเรียนรู้ เหมือนที่ โยดา พูดในว่า “มีหลายสิ่งที่เจ้าต้องเรียนรู้ พาดาวันน้อย”
• #81: ทีนี้ สิ่งที่ Pair Programming ทำคือ สามารถทำได้หลายรูปแบบ ไม่ว่าจะเป็น Senior-Junior จะเป็นการสอน แชร์ แนะนำ Junior Senior-Senior จะเป็นการช่วยกันแก้ปัญหา โดยแบ่งปัน มุมมองที่แตกต่างกัน Junior-Junior จะเป็นการช่วยกันปัญหาเช่นกัน หลักๆ คือการ ชี้แนะ แชร์ประสบการณ์ ให้กันและกัน มันจึงเป็นวิธีการที่ทรงพลังมาก ว่าแต่ ทำไมไม่ค่อยมีใครใช้กัน ? อันนี้ น่าคิดนะ ?
• #82: หลายคน โดยเฉพาะ Management มักบอกว่า “เราไม่มีเวลา หรือ มี resource พอที่จะทำ Pair Programming หรอกนะ” มันเป็นความจริงที่ว่า การทำ Pair Programming ในช่วงแรก Productivity มันจะต่ำลงมาก เพราะสองคนทำงานเดียวกัน แต่ในระยะยาว มันจะทำให้ ทีมสามารถทำงานได้เร็วขึ้น เพราะช่องว่างที่เป็น Technical Debt จะลดลง ทำให้ ทุกคนในทีม สามารถทำงาน แทนกันได้ นั้นคือ ลดการเกิดสิ่งที่เรียกว่า HDD Hero Driven Development นั้นขึ้นอยู่ว่า คุณมองสั้น หรือ มองยาว
• #83: ทีนี้ pair programming เกี่ยวอะไรกับ clean code การทำ pair คือการทำช่วยให้เกิด clean code ทั้งทางตรงและทางอ้อม มันช่วยให้เรา ให้เราคิดก่อนสร้างทุกครั้ง มีการถกเถียง กับ buddy เกี่ยวกับการแก้ปัญหา เราจะได้วิธีการที่ดีขึ้น พัฒนา skill ได้เร็วขึ้น จำไว้ว่า “ถ้าช้าไม่เป็น ก็เร็วไม่ได้”
• #84: สรุป สุดท้ายแล้ว ทุกสิ่งที่ผมได้พูด และ คุณ ดวงกมล แนะนำใน Session นี้ จริงๆ มันคือ เราโฟกัส ที่เรื่องๆ เดียว คือ การร่วมมือกัน ในทีม เพราะสุดท้าย คุณคือ Team ที่มีคนหลากหลายมารวมกัน ดังนั้น มันจึงมีกฎ เพื่อช่วยให้ทีมสามารถอยู่ร่วมกัน การใส่ใจ ใน code ที่คุณเขียน มันบ่ง่บอกว่า คุณใส่ใจ เพื่อนคุณขนาดไหน คุณใส่ใจทีมคุณมากน้อยเพียงใด ไม่ว่าคุณจะมี Tools มากมายแค่ไหน มีสุดยอด Framework ยังไงก็ตาม วิธีการ develop มันก็ยังคงตั้งอยู่บนพื้นฐานสิ่งที่เรียก Team work and Take care together ขอจบแต่เพียงเท่านี้
• #85: May the force be with you all, Thanks you