Tag Archives: book

รีวิวหนังสือ 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

Advertisements

QA first and Specification by Example Book

เมื่อหลายเดือนก่อน เกิดตะหงิดๆ ใจ กับอาการตีปิงปอง story ระหว่างทีม Dev กับ QA คือ มีหลายๆ ครั้งที่ story เปลี่ยนสถานะ จาก กำลังทำ -> เสร็จ -> reject -> กำลังทำ -> … วนไปวนมาอยู่หลายรอบ

ปัญหามักไม่ได้เกิดจาก bug ในการ implement แต่เกิดจากทีม dev ไม่สามารถเก็บครบทุก edge case, corner case ของ story นั้นได้

ด้วยความรู้นิดหน่อยของไอเดีย outside-in และคิดว่ามันน่าจะเป็นคำตอบของปัญหานี้ เลยไปหาหนังสือเกี่ยวกับเรื่องนี้มาอ่าน ก็ได้ Specification by Example มา

คอนเซปของเรื่องนี้ มีหลายชื่อเรียกมาก ทั้ง Acceptance Test Driven Development(ATDD), Behavior Driven Development(BDD), User Story Driven Development และ Specification by Example (เชื่อว่ายังมีอีกแต่ได้ยินมาแค่นี้)

หลักการของมันคือ ถ้าเราเอาการตรวจสอบคุณภาพไปอยู่หลังการพัฒนา สิ่งที่มักเกิดขึ้นคือเราพัฒนาไปผิดทาง เพราะฉะนั้นแล้ว ก็กลับเอาการตรวจสอบคุณภาพ (QA process) มาอยู่ข้างหน้าซะ

สิ่งที่เกิดขึ้นคือ แทนที่เราจะตีปิงปองกับการ manual test ของ QA เราก็ไปตีปิงปองกับ acceptance test ที่ QA เขียนไว้แทน

ผลที่ได้คือ

  • Dev หลงทางน้อยลง
  • QA มีเวลาไปทำการ test ท่าประหลาดๆ มากขึ้น

มากไปกว่านั้นแล้ว ยังมีการพยายามนำฝ่าย business เข้ามาร่วมในขั้นตอนการเขียน test ของ QA ด้วย เพื่อให้ตรงความต้องการมากขึ้น

สำหรับตัวหนังสือ มีเรื่องราวที่น่าสนใจดังนี้

  • เค้าใช้วิธีการสร้างตัวอย่าง(ตามชื่อหนังสือ)ในการคุยกับฝ่าย business เช่น ยกตัวอย่าง input นี้มา ต้องการ output แบบนี้ใช่มั้ย
  • มีตัวอย่างสถาณการณ์เยอะมาก แต่ละสถานการณ์ก็แนะนำต่างวิธีไป เช่น ถ้ามี TOR ก็เอา TOR นั่นแหละมาสร้าง example
  • ผลจากการทำ เค้าเน้นว่าการได้ living document เป็นประโยชน์มากกว่า automate validation เสียอีก
  • ไม่แนะนำให้ใส่ workaround ไปใน example ให้ใส่เฉพาะ business requirement
  • เน้นให้เขียน example ไม่ผูกกับการ implement test เพราะจะทำให้ example ถูกต้องตลอดการ และไม่มีผลต่อการเปลี่ยน test, implementation หรือเปลี่ยน platform
  • เราควรเข้าใจถึงความต้องการตั้งต้นของฝ่าย business ที่เป็นที่มาของ feature ที่เค้าให้เราทำ เพราะบางครั้งเราอาจเสนอวิธีทำที่ง่ายกว่า และตรงความต้องการกว่าได้

วิธีการนี้ใช้ได้กับทุก process นะครับ ไปลองกันดูได้

กำลังจะเริ่มอ่านหนังสือเล่มนึง

ผมกำลังจะเริ่มอ่านหนังสือเล่มนี้ The Passionate Programmer (2nd edition): Creating a Remarkable Career in Software Development พอดีอ่านคำนำแล้ว รู้สึกโดนใจ

ในคำนำของหนังสือเล่มนี้ กล่าวถึงการทำงานให้มีความสุข เพราะเราหลีกเลี่ยงไม่ได้ที่จะต้องมีงานเป็นส่วนหลักในชีิวิตของเรา ซึ่งตรงกับสิ่งที่ผมคิดมาตลอดช่วง 2-3 ปีหลังมานี้

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

หนังสือเล่มนี้มีตัวอย่างให้อ่านด้วย ผมเลยแปลส่วนของคำนำ (ตั้งแต่หน้าที่ 4 ย่อหน้าที่ 2 ของไฟล์นี้ ถึงหน้าที่ 5 ย่อหน้าที่ 3) ไว้ให้ลองอ่านกันว่าคุณจะคิดแบบเดียวกับผมหรือเปล่า ถ้าอ่านแล้วงงๆ แนะนำให้อ่านต้นฉบับนะครับ บางส่วนตอนแปลก็รู้สึกไม่มั่นใจว่าเข้าใจถูกหรือเปล่า

คนจำนวนมากใช้เวลาที่ตื่นนอนของชีวิตในช่วงผู้ใหญ่ไปกับการทำงานมากกว่าสิ่งอื่นใด จากการสำรวจในปี ค.ศ. 2006 โดย U.S. Bureau of Labor Statistics พบว่าครึ่งหนึ่งของเวลาตื่นของชาวอเมริกันโดยเฉลี่ยถูกใช้ไปในการทำงาน การพักผ่อนและออกกำลังกายนั้นเพียงแค่ 15% นี่เป็นสิ่งที่แสดงให้เห็นว่างานแทบจะเป็นชีวิตของพวกเรา

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

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

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

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