Tag Archives: Software Design

รีวิวหนังสือ Understanding the Four Rules of Simple Design

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

Understanding the Four Rules of Simple Design

Screen Shot 2014-04-02 at 9.32.55 PM

หนังสือเล่มนี้เขียนโดย Corey Haines ผู้ซึ่งเป็นคนที่ริเริ่มกิจกรรมการเขียนโปรแกรมที่เน้นการเขียนโค้ดให้สวยงามที่มีชื่อว่า Coderetreat (เหล่าพี่ ๆ ทั้งหลายนำมาจัดที่ไทยหลายครั้งแล้วเหมือนกัน) ผู้เขียนเกริ่นนำถึงความเป็นมาเป็นไปและสไตล์การจัดกิจกรรม แนะนำถึงแนวคิด simple design และความสำคัญของมัน จากนั้นเค้าจึงนำตัวอย่างของโค้ดที่เขียนกันใน Coderetreat มาให้ดู ปรับให้มันสวยงามขึ้นพร้อมทั้งอธิบายสาเหตุว่าทำไมเค้าจึงทำแบบนี้ และทำไมโค้ดใหม่จึงดีขึ้นกว่าโค้ดเก่า

Continue reading

สรุป presentation: The Deep Synergy Between Testability and Good Design by Michael Feathers

The Deep Synergy Between Testability and Good Design.

ได้ลิงค์ talk นี้มาจาก pick ของ RubyRouges ตอนล่าสุด แปลใจว่า talk นี้มันประมาณ 2 ปีมาแล้ว ทำไมถึงไม่เคยเห็นผ่านตามมาก่อน ปกติ topic แบบนี้ โดยคนพูดที่รู้จักแบบนี้ จะไม่ค่อยพลาดเท่าไหร่

สาเหตุที่อยากจด talk นี้เอาไว้ เพราะมันมีอารมณ์คล้ายๆ เรื่อง smells ในเล่ม Refactoring คือ มีการพูดถึงปัญหาของการ test ในประเด็นต่างๆ แล้วชี้ให้เห็นว่า ส่วนใหญ่น่าจะเกิดจากปัญหาด้านการดีไซน์ในจุดใด ซึ่งสามารถนำไปเป็น guideline ในการเขียนโปรแกรมจริงๆได้อย่างดี

มาเริ่มกันจาก quote เท่ๆ กันก่อน

ดีไซน์ดีทำให้เทสง่าย เทสง่ายไม่ได้แปลว่าดีไซน์ดี

อีกอัน

เมื่อมันเทสยาก อย่าแก้เทสให้เทสง่าย ให้มองหาปัญหาของดีไซน์ แล้วแก้ดีไซน์ เทสก็จะง่ายไปเอง

ต่อมาๆ พูดถึงปัญหาในการเทสกัน

  • อยากจะ access  local variable ในเทส – method ทำหลายอย่างเกินไป
  • setup เทสยาก – coupling เยอะเกินไป
  • เทสตายแบบรันไม่เสร็จ – คลาสไม่ดูแลสิ่งที่ตนควรทำ (เช่น ไม่ release memory)
  • รันเทสเดี่ยวๆ ผ่าน, รันหลายๆ เทสพร้อมกัน ไม่ผ่าน – มี global state
  • เฟรมเวิร์คทำให้เทสยาก – โดเมนของงานเราปนอยู่ในเฟรมเวิร์คมากเกินไป
  • ต้อง stub ผลลัพธ์ของ stub ซ้อนกันหลายชั้น – คลาสรู้จักส่วน private  collaborator ของคลาสอื่น
  • stub หรือ mock dependency ยาก – code อิงกับ implementation ของคลาสอื่นมากเกินไป
  • เทสคลาสแล้วมีผลลัพธ์อื่นที่คาดไม่ถึง (เช่น อยู่ดีๆ ก็ส่งอีเมล์ออกไปจริงๆ) – คลาสใหญ่ไปเกินที่เราจะรู้ว่ามันทำอะไรบ้าง
  • ไม่มีช่องให้ใส่ parameter เพื่อจะทดสอบกรณีต่างๆ ง่ายๆ – คลาสทำหลายอย่างเกินไป
  • เวลาจะเทสต้องเตรียม parameter เยอะเกินไป – คลาสหรือเมท็อด ทำหลายอย่างเกินไป
  • อยากจะเขียนเทส private method – คลาสทำหลายอย่างเกินไป
  • แก้ code นิดหน่อย unit test พังเยอะ – แปลว่าเราดีไซน์ในลักษณะที่เข้าไปแก้คลาสง่ายกว่าเขียนต่อยอด

ตอนท้ายผู้พูดได้เสนอ แนวคิดว่าทำไมดีไซน์ดีถึงทำให้เทสง่าย ทำไมมันถึงเกี่ยวข้องกัน ว่าดังนี้

ดีไซน์ที่ดี คือ ดีไซน์ที่คนเข้าใจมันได้ง่าย การเขียนเทสในมุมหนึ่งคือการทำความเข้าใจโค้ด ซึ่งก็คือการทำความเข้าใจดีไซน์ ถ้าดีไซน์เข้าใจได้ง่ายแล้ว นั่นทำให้การทำความเข้าใจด้วยการเขียนเทสง่ายตามไปด้วย