ในโลกของ Agile เรากำหนดว่า PO หรือ Product owner มีหน้าที่แค่ระบุปัญหาและความสำคัญของปัญหา ส่วนการออกแบบ Solution จะเป็นหน้าที่ของ Cross-functional team ที่จัดการตั้งแต่ต้นจนจบ

ทีนี้ในการระบุปัญหา เราก็สามารถระบุได้หลายรูปแบบ แต่ทำไม Agilist ถึงมักจะแนะนำเลือกให้เป็นรูปแบบ User story

ทีนี้ User story ที่มีความหมายควรจะเป็นอย่างไร ผมขอตอบว่า

User story ที่มีคุณค่า ควรจะสามารถตอบได้ว่า อะไรควรมีและอะไรไม่ควรมีใน Product

ส่วน User story ที่ไม่ดีเป็นอย่างไร ผมตอบว่า

User story ที่ไม่ดี คือ User story ที่ตอบได้แค่เพียงว่า อะไรควรมีใน Product

มาถึงจุดนี้อาจจะงง ผมขอยกตัวอย่างการออกแบบเว็บ Google ว่า ถ้าเขียน User story ให้ Google ควรจะเขียนแบบไหน

Story ที่ดีจะเป็น

“ในฐานะ User ผมต้องการค้นหาเว็บไซต์ที่มีข้อมูลการซื้อขายบ้าน เพื่อเข้าไปอ่านราคาบ้าน”

ส่วน Story ที่ไม่ดีก็จะเป็น

“ในฐานะ User ผมต้องการค้นหาข้อมูลเว็บไซต์ที่เกี่ยวข้องกับหัวข้อที่ผมสนใจ เพื่ออ่านเว็บไซต์ที่ผมสนใจ”

ถ้าสมมติผมเริ่มเขียน Google ใหม่จาก 0 และผมกำลังทำ MVP ลองตลาด

Story แรกผมจะรู้ว่า ผมต้องทำให้ค้นหาเว็บไซต์ขายบ้านเจอ อย่างอื่นช่างมัน ไม่จำเป็นต้องมีใน Product ก็ได้

ส่วน Story หลัง ผมจะไม่รู้ว่าผมต้องทำให้หาได้ดีขนาดไหนใน 1 Sprint กันแน่ อะไรคือข้อมูลที่เกี่ยวข้อง ต้องทำขนาดไหน

Story แรกผมจะตอบได้ทันทีว่า อะไรที่ไม่เกี่ยวกับการซื้อขายบ้าน ไม่อยู่ใน Sprint

ส่วน Story หลัง ผมแทบจะตอบไม่ได้เลยว่า อะไรบ้างที่ไม่ควรอยู่ใน Sprint

มีหน้า Advance Search ให้เลือกค้นหา ก็อยู่ใน Story นี้ได้

มีระบบ Predicate ก็อยู่ใน Story นี้ได้

มีระบบ Categorize ก็อยู่ใน Story ได้

มีระบบค้นหาด้วยรูปภาพ ก็อยู่ใน Story นี้ได้

จะเห็นว่า Story อันแรก มันบอกได้ทั้งที่ว่าอะไร “ใช่” และอะไรที่ “ไม่ใช่”

ส่วน Story หลัง มันเป็น Story ที่ มีของที่ใส่แล้วใช่เต็มไปหมด แทบจะเรียกได้ว่าใส่อะไรก็ “ใช่” ได้ทั้งนั้น

เป็น Unbound story ที่ไม่มีทางสามารถสร้าง Scope ที่ทำสำเร็จเกิดเดโมใน 1 Sprint ได้

ผมพบว่าในความเป็นจริง หลายครั้งเราจะชอบเขียน Story แบบหลัง

เราอาจจะคิดว่า “จะบ้าเหรอ เขียน Story แบบแรกมันก็แย่เกิน เราทำระบบค้นหาเว็บไซต์ แต่หาได้แค่บ้านเนี่ยนะ?”

ความคิดแบบนี้แหละที่มักจะนำมาสู่การเขียน Story ที่กว้าง

เพราะเราเชื่อว่า ถ้าเขียนเล็กเกินไป ระบบที่ออกแบบมาสุดท้าย มันจะไม่สมบูรณ์

ผมเห็นด้วยนะ จะเอาแค่ค้นหาบ้านได้แบบนั้นมันก็ไม่ใช่ระบบค้นหาเว็บพอดี

ถ้า PO เดินมาบอก ผมก็เห็นด้วย ว่ามันไม่พอที่จะเรียกได้ว่า “ระบบค้นหาเว็บไซต์”

แต่ถึงกระนั้น เราก็ไม่ควรเขียน Story แบบหลังอยู่ดี

เพราะถ้าเขียน Story แบบหลัง ยังไงเวลาออกแบบ Solution ก็จะบานปลายมาก แทบจะบอกไม่ได้เลยว่าอะไรควรอยู่อะไรไม่ควรอยู่

มีระบบ Predicate ก็อยู่ใน Story นี้ได้ มีระบบ Categorize ก็อยู่ใน Story ได้ มีระบบโน่นนี่นั่นก็อยู่ใน Story นี้ได้อีกมากมายเหลือเกิน

แล้วมันก็จะกลายเป็น “เอาตามคนที่มีอิทธิพลคิด” หรือไม่ก็เป็น “เอาตามที่มันง่ายที่สุด”

อ้าว แล้วจะทำยังไง ถ้าจะทำระบบนึง เขียน Story เล็กก็ไม่ครอบคลุม เป็นระบบที่ไม่สมบูรณ์ ดูกากกรัง แต่พอเขียนแบบกว้างๆ ก็กลายเป็น Unbound ใส่อะไรก็ได้หมดจน Scope ใหญ่เกิน

ผมพบว่าเรื่องนึงที่เรามักจะลืมคิดกันคือ

1 Feature-set สามารถ Solve ได้ หลาย Story พร้อมกันนะ

ใช่ครับ ให้เราเพิ่ม Story ลงไปให้เยอะๆ แทน

กลับมาที่ Google

Google เป็นระบบค้นหาเว็บไซต์ที่มีแค่ Textbox 1 อันกับ Search result ตามมา

แต่ผมคิดว่า แค่ 2 หน้าจอนี้ มันตอบ Story น่าจะเกินล้าน User story ได้

ซึ่งก็ไม่ผิดอะไร

ไม่มีใครกำหนดนี่ว่า 1 User story ต้องทำ 1 Feature หรือ 1 หน้าจอมาตอบ

ผมว่าเป็นความเคยชินที่น่ากังวลมาก

ตอนนี้สิ่งนึงที่ผมกำลังพยายามวางไว้เป็น Policy ใน Taskworld คือ

1. พยายามหา Solution ที่เล็กและง่ายที่สุดที่จะตอบ User story ทั้งหมดที่เขียนไว้ได้
2. ถ้ามี 2 Solution ที่สามารถตอบ User story ได้เหมือนกัน ให้เลือกอันที่สามารถสร้างได้ง่ายกว่าและเล็กกว่าเสมอ (Occam’s Razor)
3. เนื่องจากข้อแรก มันเอียงไปทางพยายามปั่น Solution ที่เล็กที่สุด หลายๆ ครั้งก็อาจจะรู้สึกว่า “เห้ย มันน้อยไป มันไม่ครบ มันดูกากเกิน” ถ้ารู้สึกว่า Solution ที่ออกแบบมาไม่ครบถ้วน ยังขาดบางสิ่งบางอย่าง แต่มันดันตอบ Story ได้ครบทุก Story แปลว่าเราอธิบาย Story ไม่หมด ให้เขียน Story เพิ่ม แล้วออกแบบ Solution ใหม่ให้ตอบทุก Story รวมถึงที่เขียนเพิ่มด้วย

เมื่อทำแบบนี้ User story ก็จะมีความหมาย เพราะมันบอกได้ว่า เราทำแค่ไหน “พอ”

และถ้า Business ยังรู้สึกว่าเราทำน้อยไป Solution ที่ออกแบบมามันยังขาดมันดูไม่สมบูรณ์ ก็เขียน Story ใหม่มาเพิ่ม เพราะมันสะท้อนว่า Define ปัญหามาไม่ครบถ้วน

แล้วเราก็เพิ่ม หาจุด “พอ” จุดใหม่ ออกแบบเล็กที่สุดและง่ายที่สุดที่ครอบคลุม Story ใหม่ด้วย

ถ้ายังเห็นว่ามันเล็กไป ก็วาง Story เพิ่ม แล้วก็วนแบบนี้ไปจนกว่าจะเห็นว่า “โอเค ดูดีแล้ว”

แต่ถ้าเราเขียน Unbound user story มันจะไม่มีอะไรบอกว่า “แค่ไหนพอ”

ซึ่งมันทำให้เราจะจบที่ Application ที่เต็มไปด้วย Feature ที่ไม่มี Concrete story รองรับ เป็นแค่อะไรลอยๆ มาเฉยๆ แล้วแต่ไอเดียใคร ใคร Convince เก่งกว่า แต่ตอบไม่ได้ว่า Concrete Story เป็นใคร User ที่จะมาใช้ เขาตั้งใจจะทำอะไรกันแน่

ถ้าเป็นแบบนี้เป็นไปไม่ได้หรอกที่เราจะสร้าง Demo ทุก Sprint ได้ครับ เพราะ Solution จะบานแน่นอน

ใช้ User story อย่างไรให้มีความหมาย was originally published in Taskworld Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Otherwise, it just become status update. That would be tedious and I prefer just continue with my work.

This does not mean you should always change the plan, but you need to change the plan when new information arise and there are more optimal way to work.

If you do standups without changing any plan, let’s say for 1 month, that would mean your team plan is always perfect from the start.

That mean in your business, you do not need any agility. Planner always get it right from the start.

If that is the case, then so be it. You should considering stop doing standups and any Agile activity. It has no use.

Common problem is, it is hard to admit that initial plan is have probability of about 80% to be wrong.

It is hard to admit that, according to information today, we got it wrong in the start of the sprint.

It is hard to just say “I got it wrong at the start, let’s change”, very frequent, almost twice a week at average.

But that was initial assumption of the Agile. If we human are able got software plan right from the start, then why bother do Agile at all?

Agile culture need to allow everyone, including self, to be truthful and accept underlying assumption that human has limitation when it comes to planning ahead in software development. Planning incorrect and changing a plan in the middle should be accept as nature of software industry, without being interpreted as being incompetency.

This go both way, from the way management see software development team and expect to have everything planned and worked out, also the way software development team see business team and expected to have everything planned for multiple years.

Both need to be viewed differently. Both need to accept that there is no such things as perfect plan.

Otherwise, why bother being Agile. Waterfall and traditional way of management does have its place and can work pretty well too.

You cannot become Agile without accepting the most fundamental assumption of Agile Methodology, that’s no one, engineer, developers, management, etc, can have perfect plan.

Every plan will have a pretty high chance to goes wrong.

Once you accept this assumption, You will be comfortable to say “Hey team, I think we got it wrong, today let’s change something to make it less wrong” every single day in every single standup meeting.

And that is when daily standups have a meaning. It actually improve the way team work. Team will be very enthusiastic to have standup meeting.

Another common problem is, even if we know something fishy coming up, and plan is not going as expected, we do not know what to act differently.

That would come with experience, but at least, Standup meeting allow team to be aware first that something is not going as expected. Hence we can retro and make it better.

In traditional way of management, we neglect these problem as “accountability”, which basically mean, let the people who accountable for it deal with it.

That is still ok in Agile, to let the one who accountable handle the case.

What is not ok is, we should be transparently talk about this issue, instead of just buried those in the hand of the one who responsible for it quitely.

Talk about it in standups, retro, etc.

That is when standup have meaning, to surface a problem.

Meaningful Standups was originally published in Taskworld Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

ถ้า Requirement แรกบอกว่าทุกๆ “รายการ Transaction ทุกอันต้องหักเงินในบัญชีลูกค้า”

account.debit(transaction.amount);

แล้วพอทำไปซักพักเขาบอกว่า “รายการทุกรายการนั่นแหละ ยกเว้น Transaction ประเภท X ต้องหักเงินลูกค้า”

หลายๆ ครั้ง ฟังแล้วเราอาจจะ Implement เป็น

if (transaction.type == TransactionType.X) return;
account.debit(transaction.amount);

แล้วถ้าตรงข้าม Stakeholder บอกว่า “รายการประเภท Y,Z ให้หักบัญชีลูกค้านะ ส่วนรายการประเภท X ไม่ต้องหักบัญชี”

หลายๆ ครั้งเขาบอกแบบนี้ เราก็จะ Implement กันแบบนี้

switch (transaction.type) {
   case TransactionType.X: break;
   case TransactionType.Y:
   case TransactionType.Z:
      account.debit(transaction.amount);
      break;
}

สิ่งที่น่าคิดคือ Requirement 2 ตัวนี้ จริงๆ เหมือนกันทุกประการ ต่างกันแค่วิธีการบอกของลูกค้า

คำถามคือ

• แบบแรกกับแบบหลัง อันไหนอ่านง่ายกว่ากัน และ Maintain ง่ายกว่ากัน
• ทำไมสิ่งที่เหมือนกันเราถึง Implement เป็น 2 แบบ
• ความง่ายของการ Maintain software ของเราขึ้นอยู่กับลำดับและวิธีเล่าเรื่องของลูกค้า หรืออยู่ในกำมือเรากันแน่

ทุกคนอาจจะตอบคำถามว่าแบบไหนดีกว่ากันไม่เหมือนกัน และผมจะไม่ขอกล่าวถึงว่าอันไหนดีกว่าอันไหนในบทความนี้

เพราะไม่ว่าคุณจะคิดว่าอันแรกดีกว่าหรืออันหลังดีกว่าก็ตามแต่

สิ่งที่ต้องระวังที่ผมอยากสื่อคือ

เราต้องมีสติรู้ว่า Implement แบบไหนทำให้ Maintain ง่าย

มิใช่ปล่อยให้ Implementation มันไหลไปตามการเล่าเรื่องของลูกค้า

ถอยหลังออกมาดูภาพรวมบ้างนะครับ

Step back from requirement was originally published in Taskworld Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Based on article here, I just want to add that internal frameworks, rules and tech stack do play same effect as standard/framework, maybe even worse. This is one of the biggest trap.

Abstract away outside framework with internal framework only have benefit when in-house framework is easier to understand and be communicated than third-party framework.

This normally can be achieved by using domain-specific word and vocabulary among internal devs, and simplify functionality of third-party to just only minimal and specific usage.

จากบทความที่ลงตะกี้เกี่ยวกับที่ว่า Architecture ที่ดีจะต้องไม่ขึ้นอยู่กับ Interface ของ Framework, tech stack, 9ล9มีเรื่องนึงที่คิดได้และอยากเขียนถึง

สิ่งนึงที่ต้องระวังและตกหล่มได้ง่าย คือ Framework, Library, Tech stack ในที่นี้มันไม่ได้หมายถึงแค่ Framework ภายนอกเท่านั้น แต่มันรวมถึงสิ่งที่เราคิดกันเองภายในด้วยนะ

คือ ถ้าเราคิด Structure ของเราเอง in-house เพื่อไปครอบ Framework ข้างนอกเพื่อให้โค้ดเราไม่ขึ้นกับ Framework ภายนอก โอเค ก็ดี แต่มันไม่ได้แปลว่าโค้ดของเราไม่ขึ้นกับ Framework เป็นอิสระจาก Framework อย่าพึ่งเข้าใจไปทางนั้น

มันแปลว่าโค้ดของเราขึ้นอยู่กับ Structure และ Framework ที่เราคิดกันเองใน in-house ต่างหาก!!

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

แต่มันไม่ใช่ Benefit เสมอไป ถ้าเราไม่ได้ใช้ Benefit ของมันเต็มที่

ยกตัวอย่างง่ายๆ สมมติเราบอกว่าเราไม่อยากขึ้นกับ Redux, React เราก็ต้องคิดหาอะไรซักอย่างมาครอบ ให้โค้ดของเราขึ้นอยู่กับสิ่งที่ครอบนั้น ซึ่งวิธีนี้ มันจะมีประโยชน์ต่อเมื่อสิ่งที่ครอบนั้น มันเข้าใจง่ายกว่าตัว Redux, React เอง หรือถ้าตัว React, Redux เองมี Breaking changes บ่อยๆ

แต่ถ้าเราไม่เข้าใจและออกแบบมันซะซับซ้อนกว่าตัว Redux, React เอง ก็กลายเป็นว่าให้โค้ดเรา Depends on React, Redux อาจจะยังดีซะกว่า

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

อย่างแรก เราใช้คำศัพท์ที่ Domain-specific เกี่ยวกับ Business problem ที่เรากำลังแก้โดยตรง หรือไม่ก็หันไปใช้ศัพท์ที่ใช้กันภายในบ่อยๆ จนคนทำงานในทีม อ่าน Requirement บ่อยๆ คุยกับเพื่อนบ่อยๆ เข้าใจได้ทันทีโดยแทบไม่ต้องศึกษา Document เพิ่มเติม แทนที่จะไปใช้ศัพท์ที่มัน Generic แบบ Standard framework พวก Controller, Component, Factory, etc.. ที่ต้องไปนั่งอ่าน Reference มากมายก่อนที่จะเริ่มใช้

อย่างที่สองคือเราตัด Functionality ที่ไม่จำเป็นที่เราไม่ใช้ทิ้งไปให้หมด ให้เหลือทางเลือกน้อยจนเพื่อนร่วมทีมไม่สับสน และตัด Use-case ให้ตรงกับสิ่งที่เราใช้งาน

ข้อแรกทำให้ผมมักจะบ่นบ่อยๆ ว่า Code ที่ Architecture ดี จะมีศัพท์เทคนิคน้อย

แน่นอนในโค้ดที่ใหญ่และซับซ้อนมากๆ เราหลีกเลี่ยงการสร้าง Concept เฉพาะบางอย่างไม่ได้ และหลีกเลี่ยงการใช้ศัพท์เฉพาะทางไม่ได้หรอก แต่ก็ควรจะพยายาม Minimize ให้มากที่สุด

ประเด็นหลักที่ผมอยากจะชี้คือ ถ้าเราจะ Abstract 3rd-party dependency ออกไปโดยการสร้างอะไรครอบ มันจะเวิร์คและมีประโยชน์ก็ต่อเมื่อของที่ครอบมันดีกว่าในบริบทของโจทย์ที่เรากำลังแก้ เราแลกความ Generic ของมันไปแล้วทำตัวครอบให้มัน Specific มากขึ้น เพื่อให้เข้าใจง่ายขึ้น ใช้ง่ายขึ้น

(ถ้ามันดีกว่า In general ก็ Open-source ซะแล้วเตรียมดังได้เลย)

นั่นคือสิ่งนึงที่น่าพิจารณาเป็นอย่างมาก

On framework dependencies was originally published in Taskworld Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

แล้วจังหวะที่เจ็บเพราะโค้ดซ้ำ มันเจ็บไม่เท่า Abstract โค้ดผิดแล้วต้องรื้อทิ้ง อันนี้โหดร้ายมากๆ

แต่สิ่งนึงที่เรียนหนักมากคือ Data structure เนี่ย อย่าพยายาม Reuse มากเกินไป เรามักจะมีหล่มนี้

เช่น ถ้าฟอร์มนึงต้องการแค่ Firstname, Lastname และ Avatar เพื่อเขียนข้อมูล User เล็กๆ ว่าเขาเป็นใคร สิ่งที่ดีที่สุดคือการส่งไปแค่นั้นจริงๆ ไม่ใช่ส่ง User Object ไปทั้งก้อน

เพราะอะไรถึงควรส่ง Data structure ที่ minimal แบบนั้นเสมอ คือถ้าเราส่ง User Object ทั้งก้อน ส่วนมากแล้วพอฟอร์มตรงนั้นต้องการอะไรเพิ่มเติม (เช่น Link website) Intuition แรกของเราก็คือ “ก็เพิ่มลงใน User object สิ”

ซึ่งลองนึกดูว่าถ้าเราส่ง User object ไปหลายๆ ที่ทั่วทั้งแอพ แล้วแต่ละส่วนของ UI เติบโตต่างกันมี Requirement changes แตกต่างกัน แปลว่าการเติบโตทั้งหมดที่ไปคนละทิศคนละทางจะมา Reflect ลง User object หมดเลย แล้วถ้าเป็นแบบนี้ สุดท้าย Model เราจะบวมมากๆ กลายเป็น Super class

แต่ถ้าเราส่ง Minimal data structure เราจะเริ่มคิดละว่า เห้ย เราต้องเติมลงตรง Data structure เล็กๆ ตัวนั้นตัวเดียวเองนี่ แล้วมันอาจจะ Map มาจาก Model หลายๆ ตัวได้ รวมถึงคิดว่าจำเป็นต้องสร้าง Model ใหม่มั้ย เราจะพิจารณาความเป็นไปได้ในการเติมของในที่อื่นๆ อย่างเป็นกลางมากขึ้น

ทำได้สองอย่างคือ

1. ส่งให้เล็ก แต่เขียนโค้ดเยอะขึ้นมากๆ ยิ่งถ้า Static type language คือต้องประกาศ Class/Struct เยอะแยะไปหมดเลยเพื่อให้มี Data structure ที่พอดีใช้ ก็มีความน่ารำคาญนะ ผมก็เป็น

2. ส่งใหญ่ก็ได้ แต่ต้องเท่าทัน Intuition ของตัวเองเวลาคิดว่าต้องเติมของลง User object ต้องแบบ จริงเหรอวะใช่เหรอวะบ่อยๆ ถามตัวเองเยอะๆ เท่าทันว่าเราสร้าง Bias ให้ตัวเองตั้งแต่แรก

การ Reuse data structure ผิดที่ผิดทางแล้วสร้าง Data structure ตัวนึงที่ถูกใช้หลายที่เกินไป จนมันเริ่มเติบโตพร้อม Requirement changes ทุกทิศทาง นี่คือแบบ สุดยอดของความยากที่จะแก้ไขมากๆ เจ็บหนักมาก

และเป็นสิ่งที่ต้องระวังเพราะเป็นหล่มที่ตกลงไปได้ง่ายเหลือเกิน

Avoid reusing data structure was originally published in Taskworld Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

function doSomethingA() {
  // ............ Some statements

  step2()

  // ............ Another many statements
}

เขาต้องแก้สร้าง doSomethingB ซึ่งยังทำทุกอย่างเหมือนเดิม เปลี่ยนแค่ step2

Intuition แรกที่คิดขึ้นมาคือ ในเมื่อ มันต่างกันแค่ Step 2 เราก็ Inject step 2 สิ

function createDoSomething({ step2Injected }) {
  // ............ Some statements

  step2Injected()

  // ............ Another many statements
}

function doSomethingA() {
   const doSomething = createDoSomething({ step2Injected = step2 })
   return doSomething()
}

function doSomethingB() {
   const doSomething = createDoSomething({ 
     step2Injected = step2Special 
   })
   return doSomething()
}

ซึ่งมันก็ตรงไปมาแหละ

พอผมอ่าน ผมบอกว่า อ่านยากนะ คือในทางทฤษฎีมันก็ถูกว่าทุกอย่างเหมือนกัน ต่างกันแค่นี้ เราก็ If แล้ว Inject มาสิ

แต่ มันเสีย “ความต่อเนื่องของเรื่องราว” ไป

ผมแนะนำให้

1. ตั้งชื่อตั้งความหมายให้สิ่งที่ทำก่อน Step2
2. ตั้งชื่อตั้งความหมายให้สิ่งที่ทำหลัง Step2
3. เล่าเรื่องราวของมันเป็นเรื่องสั้นๆ 3 บรรทัด

ผลออกมาแบบนี้

function step1 () { 
   ... // Refactor from original doSomethingA
}

function step3 () {
   ... // Refactor from original doSomethingA
}

function doSomethingA () {
  step1()
  step2()
  step3()
}

function doSomethingB () {
  step1()
  step2Special()
  step3()
}

พอเรา Refactor จน doSomethingA, doSomethingB มันเหลือแค่ 3 บรรทัดแล้วแบบนี้ เราเห็นชัดเจนว่ามันต่างกันที่นึง ในระยะ 6 บรรทัด จากเดิมที่เราต้อง Navigate ไประหว่างชุดโค้ดยาวๆ (ในชุดโค้ดแรก createDoSomething มันมีความยาวประมาณ​ 40 บรรทัด)

ถึงแม้ว่าถ้าดู Requirement และสิ่งที่จะทำคือ “ทำทุกอย่างเหมือนเดิมยกเว้นขั้นตอนที่ 2” การแก้ไขที่ตรงไปตรงมาที่สุดคือ Inject ขั้นที่ 2 เข้าไปผ่าน Dependency injection ก็ตาม

ผมมองว่าแบบหลังอ่านง่ายกว่าและแก้ง่ายกว่า

Moral of story

1. ระวังเรื่องการยึดติดกับ Status quo คือถ้าเรามองว่าเราอยากทำ Requirement ใหม่โดยไม่ Refactor ของเดิม หรือ Refactor ให้น้อยที่สุด ไม่อยากไปทำลายของเก่า เราจะมองไม่เห็นว่ามันสามารถ Breakdown ได้
2. โค้ดที่เล่าเรื่องราวได้ใน 3–4 บรรทัด ถึงแม้จะไม่ Systemmatically Precise ว่า “ต่างกันแค่นี้” แต่ก็จะสบายตาและเข้าใจง่ายกว่า ส่งผลให้แก้ไขง่ายกว่า มีโปรแกรมเมอร์อยากแก้เยอะกว่า (ซึ่งทั้งหมดที่เราคุยเรื่อง Software architecturing คือเราต้องการให้โค้ดแก้ง่าย)
3. เมื่อใช้ท่ายากทุกครั้งต้องมองเห็นว่ามันสร้าง Learning curve ดังนั้นมอง Trade-off ดีๆ ถ้ามีสองสิ่งที่มีคุณค่าพอๆ กัน ผมมักจะสนับสนุนให้ Prefer code ที่อ่านได้ง่ายและทำความเข้าใจได้ตั้งแต่ Beginner มากกว่าโค้ดที่ยาก

Code that tell a story was originally published in Taskworld Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

สมมติว่าเราได้รับ Requirement มาว่า

“ตาราง User จะแสดงเฉพาะ User ที่ Active เท่านั้น”

ถ้าเราใช้ React เราอาจจะเขียนแบบนี้

render () {
   const activeUsers = this.props.user.filter(c => c.active)
   return activeUsers.map(user => (
     <UserRow user={user} />
   ))
}

ซึ่งจริงๆ มันก็ง่ายดีนะและมันแค่บรรทัดเดียวด้วย

แต่ผมจะบอกว่าไม่ควรทำแบบนี้ในการทำงานเป็นทีม

ผมแนะนำให้เราสร้าง File ชื่อ User.js ที่รวม Business logic ของ User โดยเฉพาะไว้เลยไฟล์นึง แบบนี้

export const isUserActive = (user) => user.active

เราก็จะได้ Render หน้าตาแบบนี้

import { isUserActive } from './user'
render () {
   const activeUsers = this.props.user.filter(isUserActive)
   return activeUsers.map(user => (
     <UserRow user={user} />
   ))
}

เพราะอะไร ทำไมแค่ของสั้นๆ บรรทัดเดียวผมถึงแนะนำให้ต้องทำเรื่องยุ่งยากอย่างสร้างไฟล์ใหม่ที่มีบรรทัดเดียว import เข้ามา แล้วก็ใช้ด้วย

เพราะในการทำงานเป็นทีม Application ของเราจะใหญ่มาก แล้วเพื่อนๆ เราก็มีสิทธิ์ที่ได้รับ Requirement ส่วนอื่นๆ ที่ต้องตอบคำถามว่า “เอาเฉพาะคนที่ Active เท่านั้น” เช่นกัน

สมมติเพื่อนอีกคน ทำอีกส่วนของ Application บอกว่าให้แสดง Avatar ของ User ที่ Active เขาก็จะเขียนแบบนี้

render () {
   const activeUsers = this.props.user.filter(c => c.active)
   return activeUsers.map(user => (
     <UserAvatar user={user} />
   ))
}

ลองนึกถึงว่าถ้ามีแบบนี้ซ้อนๆ กันหลายๆ ที่ มีเพื่อนหลายๆ คนต้องทำ Feature ที่ต้องตอบคำถามว่า “ใคร Active อยู่” เราก็จะมี user.filter เต็มไปหมด

เพื่อนๆ ทุกคนในทีมก็ เขียนแบบนี้แยกกัน โดยที่ไม่รู้ว่าอีกคนเขียนอยู่

แล้วถ้าวันนึง นิยามของ “ใคร Active อยู่” เปลี่ยนไปล่ะ เช่น เรามีวันหมดอายุแล้ว ใครที่หมดอายุแล้วก็ถือว่า ไม่ Active เช่นกัน

ถ้าเราทำแบบแรก รวมไว้ที่เดียว เราก็แค่แก้

export const isUserActive = (user, now = new Date()) => user.active && user.expiry.getTime() > now.getTime()

แต่พอเราทำแบบหลัง เราต้องตามแก้ไขกันจนตามไม่หมดทีเดียว

เรื่องนี้เหมือนเป็นเรื่องเบสิค แต่ผมคิดว่าสำคัญมาก

ความรู้และคำถามที่เกิดขึ้นใน Application เรา ไม่ว่าจะตอบที่ส่วนไหน ก็ต้องตอบคำถามเหมือนๆ กัน ในกรณีนี้คือ ความรู้ที่ว่า “User คนนี้ Active อยู่มั้ย” ต้องตอบได้เท่ากันหมดทั้ง Application

การที่จะบรรลุข้อ 1 ได้ เราก็ควรจะรวม “ความรู้และคำถาม” ทั้งหมดที่เกิดขึ้นได้ใน Application ไว้ที่ไหนซักที่นึง หรือตามหลัก DRY ก็จะบอกว่า

“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”

อันนี้คือจุดตายจุดแรกที่มักเจอกัน คือ เรามองไม่ออกว่า “User active อยู่มั้ย” เป็นองก์ความรู้ของ Application ที่ควรจะรวมไว้ เพราะมันเปลี่ยนได้ หรือภาษาทางเทคนิคหน่อยจะเรียกว่า Business logic (จริงๆ มันก็คือ If โง่ๆ อันนึงแหละ)

แต่ด้วยความเป็นมนุษย์ขี้เหม็น ต่อให้เราบอกว่า Centralized แต่ถ้าจุดที่หามันหาเจอยาก หาไม่เจอ ไม่รู้อยู่ตรงไหน มันก็จะเหนี่ยวนำให้เพื่อนร่วมทีมเขียนใหม่ เพราะ .filter แบบนี้ เขียนใหม่ใช้ 5 วิก็เขียนเสร็จ

ถ้าเวลาที่ต้องใช้ ในการค้นหาให้เจอ ใช้เวลาถึงขั้น 10–20 นาที ต้องเดินไปถามคนนั้นคนนี้ ในขณะที่เขียนใหม่ใช้แค่ 5 วินาที

ก็มีความเป็นไปได้สูงมากที่ Programmer จะเขียนใหม่ และ Duplicate code

นี่คือจุดตายจุดที่สอง ที่เราโปรแกรมเมอร์มือฉมังหลายคนจะมองว่าปัญหานี้เกิดจากความ “ไม่ใส่ใจคุณภาพ” แต่ลืมมองไปว่าบางทีเขาอาจจะไม่รู้ว่าต้องหาที่ไหน หาเจอช้า อาจจะมีปัญหาเชิงโครงสร้างและการสื่อสาร

เพราะโปรแกรมเมอร์มือฉมังจะจำโครงสร้าง Application ได้ แล้วหลายๆ ครั้งเขาจะลืมมองเห็นจากมุมคนอื่นว่า บางคนยังจำไม่ได้ บางคนนึกไม่ออก

ดังนั้นวิธีที่เราใช้กันที่ Taskworld คือ เรา Group business logic เข้าด้วยกันตามชื่อ Business entity แล้วก็บอกว่า เราตั้งชื่อพวกนี้ใน Format xxx.js เช่น user.js ไปเลย

ส่วนไฟล์พวก React component หรือไฟล์อื่นๆ เราก็ตั้งชื่อให้มันแตกต่างกันอย่างเห็นได้ชัด เช่น มีลงท้ายด้วย .react มี suffix ว่า Reducer

เมื่อเราตั้งแบบนี้การ Navigate เจอง่าย แนวโน้ม Probability ที่คนจะเขียนใหม่ก็มีน้อยกว่าการที่คนจะ Reuse ของเก่า

แต่หลายๆ ครั้ง เราก็มีปัญหาว่าการเปลี่ยนแปลง Structure บางอย่างสื่อสารไม่ทั่วทั้งทีมก็เกิดขึ้นได้เป็นระยะๆ ผมเชื่อว่าทุกที่ก็มีอะไรแบบนี้อยู่บ้าง

ก็เป็นสิ่งที่เรากำลังพัฒนาให้ดียิ่งขึ้นต่อไป

ในเรื่องนี้ ผมมองว่ากระบวนท่าไม่สำคัญ คุณจะแบ่ง Folder structure หรือชื่อไฟล์ยังไงผมว่ามันก็มีหลายท่ามากๆ จะใช้ Architecture แบบไหนเลียนแบบ Facebook, Google, Netflix หรือใช้ Standard framework จะเป็น MVC, VIPER, Idiomatic React, Angular หรืออะไรก็ตาม ก็ไม่ได้เป็นประเด็นที่สำคัญที่แท้จริง

จุดสำคัญในการทำงานเป็นทีมในเรื่องนี้คือ

รวม Business logic เข้าไว้ในที่ๆ นึงที่ Intuitive พอที่คนทั่วไปในทีม จะติดนิสัยว่า “เห้ย หาตรงนี้ก่อนนะ ไม่เจอค่อยเขียนใหม่” ก่อน Implement if ซักตัว

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

ผมชี้ประเด็นที่มักจะเป็นจุดตายในการ “แยก Business logic ให้เป็นระเบียบ”

1. ไม่ยอมรวมเพราะมองไม่ออกว่านี่เป็น “องก์ความรู้” ประจำระบบ
2. รวมในที่ๆ หายากสำหรับคนทั่วไป มีการแบ่งโครงสร้างที่ซับซ้อน มีคนเข้าใจวิธีการค้นหา Business logic ที่ต้องการเพียงไม่กี่คน
3. รวมเสร็จแล้วไม่สามารถสื่อสารให้ทุกคนรู้อย่างทั่วถึงได้ว่าต้องหาตรงไหนก่อน Implement ของใหม่ สื่อสารไม่ทั่วถึง

Framework Dependant Architecture

เรื่องนึงที่ผมมีความ Skeptic ต่อแนวโน้มทั่วไปของ Developer คือการที่หลายๆ คนเวลาพูดถึง Software architecture ให้ความสำคัญกับการใช้ Framework หรือ Practices ที่เขาเล่าลือกัน แล้วมีน้อยคนจริงๆ ที่เริ่มพูดคุย (อย่างน้อยก็กับผม) ใน Term ของผลลัพธ์ว่า ใช้แล้วกระทบกับทีมอย่างไร ทำไมทีมถึงทำงานดีขึ้น ทำไม Workflow ของ Developer ถึงสบายขึ้น ทำไมโค้ดแก้ไขง่ายขึ้น ต่างจากเดิมยังไง

จริงๆ การใช้ Framework ที่เป็น Standard มันก็แค่ช่วยลดปัญหาข้อ 2, 3 เท่านั้นเอง เพราะเราสามารถบอกได้ว่า “ลองอ่านคู่มือแถวนี้นะ” แทนที่จะต้องอธิบายเองทุกรอบ ก็ช่วยให้บรรลุเรื่องการสื่อสารได้ง่ายขึ้น

แล้วคนทำ Framework เขาก็มี Pain ที่เขาเจอมาเยอะ แน่นอนโอกาสที่เขาคิดรอบด้านกว่าเราก็มีสูงเพราะเขาทุ่มเวลาสร้างมันขึ้นมาโดยเฉพาะเลยนี่

แต่ทว่า ปัญหาฐานจริงๆ มันคือเรื่องของ “ไม่มีความรู้” ครึ่งนึง และ “สื่อสาร” ครึ่งนึง

ต้องมองตรงนี้ให้ออกครับ ผมพบว่า แทบทุกครั้งที่นำ Framework มาใช้แล้วพังก็เพราะสาเหตุพวกนี้ ตรงข้าม ถ้ามีความรู้และสื่อสารดีมากๆ บางทีคิด Framework กันเอง ใช้กันเองภายใน ยังเวิร์คได้เลยครับ

Why should we separate business logic out of view? in Layman term was originally published in Taskworld Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

สมมติวันนี้เราบอกว่าเราออกฟีเจอร์ตัวนี้ออกไปเพื่อทดสอบตลาด เราควรมี Assumption ที่เคลียร์มากๆ เช่น

• ฟีเจอร์นี้ถือว่าสำเร็จก็ต่อเมื่อ คนที่สมัครกับเรา 10 License ขึ้นไป ใช้ฟีเจอร์นี้อย่างน้อยสัปดาห์ละ 2 ครั้ง
• ฟีเจอร์นี้จะสำเร็จก็ต่อเมื่อ เราได้รับความพึงพอใจใน NPS Survey เกิน x คะแนน

Assumption ควรจะตั้งไว้ให้ชัดเจนและตีผลอะไรไม่ได้นอกจาก “ผ่าน” หรือ “ไม่ผ่าน” เท่านั้น อย่างเช่นสองประโยคด้านบน

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

ที่ฟีเจอร์ไม่สำเร็จ เราอาจจะทำผิดคิดผิดแต่แรกเลยก็ได้ ไม่โดนใจเลยก็เป็นได้

ที่ฟีเจอร์ไม่สำเร็จ จริงๆ เราอาจจะทำโดนใจแล้ว แต่เราดีไซน์สีไม่สวยหรือเปล่า

ที่ฟีเจอร์ไม่สำเร็จ จริงๆ เราอาจจะทำโดนใจแล้ว แต่กระบวนการเก็บ NPS Survey มีปัญหาหรือเปล่า คะแนนเลยน้อย

พวกนี้มันตีความได้หลายอย่างมาก

ส่วนว่า Test result ผ่านมั้ย ไม่ผ่านก็คือไม่ผ่าน ไม่มีเร้าหรือ มีแค่ได้หรือไม่ได้เท่านั้น

ส่วนเหตุผลอะไรถึงไม่ผ่าน ยัง Open for interpretation เสมอ

ข้อสำคัญที่สุดเลยคือเราต้องไม่กลัวที่จะบอกว่า “ไม่ผ่าน”

ถ้าเรากลัวที่จะทดสอบไม่ผ่านมากๆ เราจะตั้งสมมติฐานที่ไม่เคลียร์

เช่น

“User กลุ่มนี้จะต้องชอบฟีเจอร์นี้”

แล้วเมื่อไหร่ถึงจะถือว่าชอบ เมื่อไหร่ถึงจะถือว่าไม่ชอบ

ถ้าคนชอบ 50.01% ถือว่าผ่านมั้ยนะ?

แต่ตรงข้าม เพื่อให้เกิดกระบวนการการทำงานที่ดี เพื่อให้ทุกคนกล้าที่จะตั้งสมมติฐานที่เคลียร์ เราก็ต้องสร้าง Environment ที่พร้อมจะรับผลอย่างกล้าหาญด้วย

กระบวนการ MVP, Assumption testing, Lean จึงเกิดไม่ได้ในองค์กรที่ไม่ยอมให้ใครล้มเหลว ไม่ยอมให้มีคำว่า “ไม่ผ่าน” เกิดขึ้น

สิ่งที่ยากที่สุดสำหรับผมในกระประยุกต์กระบวนการพวกนี้ คือการอธิบายให้เข้าใจว่า

“ตั้งสมมติฐานให้มันเคลียร์และชัดเจนไปเหอะ ถ้าสุดท้ายไม่ผ่านขึ้นมา ก็แค่ทำให้ดีขึ้นรอบหน้าเอง แค่นั้น มันก็แค่สมมติฐานนะเว้ย ไม่ใช่ KPI อะไร”

แล้วถ้าคนทำงานเขาไม่เชื่อว่า ไม่ผ่านได้ ไม่เป็นไร ค่อยว่ากันรอบหน้า

มันก็มักจะจบที่ว่า คนทำงานจะตั้งสมมติฐานให้ไม่เคลียร์ เผื่อไม่ผ่านขึ้นมา จะได้มีทางลง

ซึ่งวิธีแบบนั้นมันไม่นำพา

ทางลงมันมีตอนตีผลข้อมูลตอนตีความ เวลาผลสุดท้ายสิ่งที่เราทำมันไม่ผ่าน Assumption ที่ตั้งไว้ มันไม่จำเป็นต้องตีความว่าที่ไม่ผ่านเพราะผลงานมันห่วยไม่ได้เรื่อง คนทำงานมันห่วยไม่ได้เรื่องเสมอไปนี่ครับซะที่ไหน

แต่ผลการทดสอบ ต้องชัดเจนที่สุดครับ

MVP & Clear assumption was originally published in Taskworld Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

I have face a lot of programmer, who when refactoring, tends to optimize for number of typing strokes, at the cost of understandability

When we talk about reduce code duplication, we not try to optimized key stroke. The main concept is to centralized the domain knowledge and make changes easier.

I will give you an example where refactor based on optimizing keystroke can be harmful.

Class MyComponent extends React.Component {
  render () {
    //.... 
  }
}

We could refactor to:

function createReactComponentRender (renderFunc) {
  return Class ThisComponent extends React.Component {
     render = renderFunc
  }
}

and we can reduce both number of line and number of characters tremendously.

Fully-React version for 3 components:

Class Component1 extends React.Component {
  render () {
    //.... 
  }
}

Class Component2 extends React.Component {
  render () {
    //.... 
  }
}

Class Component3 extends React.Component {
  render () {
    //.... 
  }
}

Refactored-React version for 3 components:

const Component1 = createReactComponentRender(() => { ... } )
const Component2 = createReactComponentRender(() => { ... } )
const Component3 = createReactComponentRender(() => { ... } )

Wow!!! new version look lot shorter. It should be says cleaner and more precise right?

I don’t agree at all.

I would considered Fully-React version to be better code than new version.

Readability:

In term of readability, I would say any React developer can understand code in Fully-React, just by looking at the code. It simple, it is the one that you exactly see on tutorial.

While in Refactor-React version, one would have to look at definition of createReactComponentRender first to be sure what does it do.

Maintainability:

In term of maintainability, which I perceived as “how easy to make changes in code”

In this case, most obvious possible changes is to add some lifecycle method to some of components.

So what changes needs to be made in this case?

Fully-React

Class Component1 extends React.Component
  shouldComponentUpdate () {

  }

  render () {
    //.... 
  }
}

Class Component2 extends React.Component {
  render () {
    //.... 
  }
}

Class Component3 extends React.Component {
  render () {
    //.... 
  }
}

Refactored-React

Option 1:

Class Component1 extends React.Component
  shouldComponentUpdate () {

  }

  render () {
    //.... 
  }
}
const Component2 = createReactComponentRender(() => { ... } )
const Component3 = createReactComponentRender(() => { ... } )

In this option, the code that needs to be changes become 6 lines, which I would say this become little bit harder to changes than Fully-React version.

Option 2:

function createReactComponentRenderAndShouldUpdate (renderFunc, shouldComponentUpdateFunc = null) {
  return Class ThisComponent extends React.Component {
     shouldComponentUpdate = shouldComponentUpdateFunc 
     render = renderFunc
  }
}

const Component1 = createReactComponentRender(() => { ... }, () => { ... } )
const Component2 = createReactComponentRender(() => { ... } )
const Component3 = createReactComponentRender(() => { ... } )

This option need exactly 3 lines changes, which is same number of line as Fully-React version.

But I would say now we bloat createReactComponentRenderAndShouldUpdate , and we reduce readability by great magnitude.

This is why I think that Fully-React version is the best one, even if it takes more lines and keystrokes to write than Refactor-React one

(Actually, we can just snippet)

Moral

1. Refactor code for shortest one, for less typing keystrokes one, can hurt maintainability and readability of the code
2. Sometimes, duplications of big chunk of code is better handle by snippet rather than refactor to function or even meta-programming.
3. When Refactor, try to be less biased toward keystrokes. I know that when we as a programmer, have to type same long boilerplate all the time. we tends to think of refactor and reduce the typing workload. No, we do not refactor for that. We refactor code for readability and maintainability over ease of typing. (Hint: Typing workload can be reduce greatly by just a simple snippet and scaffolding)

Refactor for readability, not for keystrokes was originally published in Taskworld Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

สมมติว่าเราต้องการส่ง email ปกติเรามักจะเห็นโค้ดแบบนี้

var emailSender = new EmailSender()
emailSender.to = "ace@taskworld.com"
emailSender.body = "Hello ace"
emailSender.send()

โค้ดลักษณะนี้เห็นได้ทั่วไปมากๆ

คำถามคือแล้วถ้าเกิดว่าอยู่ดีๆ มีคนอุตริส่ง email.send() โดยที่ลืมใส่ email.to ล่ะ

ผมพบว่าปกติระบบก็จะฟ้อง Exception ว่าอย่าลืมใส่ว่าส่งอีเมล์ให้ใคร

ก็ฟังดูปกติเนอะ เราก็เคยชินกับระบบแบบนี้คลาสแบบนี้กัน ก็ยังดีกว่าอยู่ดีๆ เงียบไปเลยแล้วส่งเมล์ไม่ได้ หรือทำอะไรแปลกๆ อ่ะนะ

แต่ผมคิดว่ามันดีไม่พอ

สิ่งที่ดีกว่านั้นคือออกแบบให้โปรแกรมเมอร์ไม่สามารถเขียนโค้ดที่เกิด Runtime exception ได้ตั้งแต่แรกเลย!!!

“Making illegal states unrepresentable”

หา เราทำถึงขนาดนั้นได้ด้วยเหรอ?

ผมตอบว่าในกรณีนี้ทำได้ครับ

การเขียนโค้ดแล้วไปมี Exception ที่หลังมันให้ความรู้สึกที่แย่มากๆ ผมจะหงุดหงิดเสมอเวลาที่เขียนโค้ดที่คิดว่าเวิร์คแล้วแล้วอยู่ดีๆ ก็ไปเกิด Runtime exception ตรงที่ไม่น่าจะเกิดเพราะลืมนั่นลืมนี่

เป็นความรู้สึกที่แย่มากๆ ผมเกลียดมัน ดังนั้น ผมจะพยายามออกแบบให้คนที่ใช้โค้ดของผมไม่สามารถมีหนทางไปเจอ Runtime exception ได้ (หรือถ้าต้องเจอจริงๆ ก็ขอให้น้อยที่สุด)

ในกรณีนี้ทำได้สองแบบครับ

Object-Oriented approach

var emailSender = new EmailSender("ace@taskworld.com", "Hello ace")
emailSender.send()

ในกรณีนี้ ผมออกแบบ Class EmailSender ไม่ให้มี Empty Constructor ดังนั้นไม่ว่าใครใช้ก็ต้องใส่ข้อมูลให้ครบก่อนเสมอ

พอเราบังคับให้ Constructor ต้องมีครบ ก็จะไม่มีใครสามารถสร้าง EmailSender ที่พอกด emailSender.send() แล้วจะเกิด Exception ได้อีกแล้ว

Functional Approach

send(emailServer, "ace@taskworld.com", "Hello ace")

ง่ายและตรงไปตรงมา ผมส่ง Function บอกว่าต้องใส่ข้อมูลให้ครบ แค่นี้ก็เป็นการยากมากแล้วที่ Developer จะสร้าง Runtime error ได้

นี่คือเหตุผลนึงที่ผมชอบ Functional programming เนื่องจากมันไม่มี State mutation มีแค่คำสั่งกับ Data transformation ดังนั้นเราสามารถบอกได้ทันทีว่าเราต้องการอะไรบ้าง ส่งมาให้ครบ เราไม่สามารถสร้าง Invalid state ได้แต่แรกแล้ว

Common Popular Anti-Pattern

เรื่องที่น่ารำคาญใจสำหรับผมคือ ถึงแม้ Anti-pattern แบบนี้จะเป็นอะไรที่เข้าใจง่ายและหลีกเลี่ยงง่าย แต่เราก็พบ Anti-pattern แบบนี้ได้ทั่วไปมากๆ แม้แต่ระบบที่ออกแบบด้วยบริษัทใหญ่ๆ ก็ตาม

(ผมถึงได้บอกทุกคนตลอด อย่าเชื่อว่านี่มันเป็น Best practice ออกแบบมาดี เพียงเพราะบริษัทใหญ่ๆ อย่าง F…., G…, M… หรือใครก็ตามออกแบบมาให้เรา ตั้งคำถามด้วยว่าเขาทำมาดีหรือเปล่า)

ORM

user = new User()
user.email = "ace@taskworld.com"
user.name = "Chris"
user.password = Hash("WeirdPassword")
user.optionalTelephone = "0000000"
user.save() // *** Throws if some required fields missing ***

นี่คือ Orm ทั่วไปที่พบได้ในเกือบๆ ทุกภาษา

ถ้าในกรณีนี้ user นั้นต้องการ email, name, password แน่นอนในการสร้าง (คงไม่มี User คนไหนที่ไม่มีอ่ะนะ)

แทนที่เราจะบอกว่า user.save() คุณไปทำ Validation ด้วยนะ ใครส่งข้อมูลมาไม่ครบให้ Throw runtime exception นะ จะดีกว่ามั้ยถ้าเราออกแบบยังงี้

user = new User("ace@taskworld.com", "Chris", Hash("WeirdPassword")
user.optionalTelephone = "0000000"
user.save()

ถ้าเราออกแบบยังงี้ ไม่ว่าเราจะกด user.save() ตอนไหน ไม่ว่า Programmer จะมาซนยังไง ตราบใดที่เขาไม่เปลี่ยน Interface ของ Class user ก็ไม่มีทางเกิด Runtime exception จากการใส่ฟิลด์ที่ต้องการไม่ครบได้เลย

นี่เป็นหลักการที่เข้าใจง่าย แต่ก็พลาดกันบ่อย แม้แต่ผมเองก็ใช้เวลาหลายปีกว่าจะมองเห็นหลักการง่ายๆ ตรงนี้

สิ่งที่ผมอยากให้จำคือ ครั้งถัดไปที่เราใช้ Library หรือใช้ Class ของคนอื่น หรือใช้ Function ของคนอื่น แล้วมัน Throw runtime exception ขึ้นมาเพราะเรา Config อะไรบางอย่างไม่ครบ

อย่ามองแต่แค่โทษตัวเองว่าเราโง่เองไม่ยอมอ่านให้ครบก่อนใช้เพียงอย่างเดียว พี่เขาก็บอกแล้วใน Doc แต่ไม่อ่านอย่างเดียว

แต่อยากให้มองให้เห็นไปถึงว่าการดีไซน์คลาสที่เกิดสิ่งนี้ได้ มันเป็น Code smell แบบนึงด้วยครับ

Basic code smell#1: Method ที่ขึ้นกับ Mutation was originally published in Taskworld Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.