เรื่องนี้มาจากสิ่งที่คุยกันใน Twitter หาจุดเริ่มต้นนานมาก เพราะคุยกันไม่ได้ติดต่อกันเท่าไหร่ ยกเว้นช่วงหลังที่ @visibletrap ปล่อยมาเป็นชุดเลย เรื่องก็น่าจะเริ่มจาก Tweet ชุดนี้มั้ง (22 กรกฎา)
- @visibletrap: “ตามคำขอ [Blog] Refactoring DOJO http://t.co/w6NQIW6 cc @teerapapc @m3rlinez
- @llun: @visibletrap อยากเห็น Agile ในบริษัทที่ทำ Product ของตัวเองอ่ะ (เรียกว่า Software House ป่าวหว่า) เพราะบริษัทเหล่านี้มักไม่มีการคุมเวลา
- @visibletrap: @llun น่าจะมีนะ แต่ยังไม่เคยรู้ข้างในจริงๆ อย่าง Pivotal เค้าก็มี product เค้า อย่าง google เคยได้ยินว่าทีม adwords ก็ทำ
- @llun: @visibletrap ใช่แต่บริษัทที่ทำ Agile และรู้จักตอนนี้ส่วนใหญ่คือทำ Product ตาม Requirement ของลูกค้า
- @visibletrap: @llun ก็บริเวณที่เราอยู่มันมีแต่บริษัทแบบนี้นี่หน่า แล้วในกลุ่มนี้บริษัทที่ทำ agile ก็คิดเป็น % น้อยมากอยู่แล้ว
- @llun: @visibletrap อยากรู้เค้าคุมขอบเขตของงานยังไงอ่ะ
- @visibletrap: @llun ถ้าในมุมของผมนะครับ ยุคนี้มันยุค release beta อะ ทำน้อยที่สุดให้สามารถ release ได้ แล้วทำระบบให้ตอบสนอง feedback ได้ดีๆ
- @llun: @visibletrap ใช่แต่คำว่าน้อยมันไม่สามารถบอกปริมาณที่แน่นอนได้อ่ะ มันต้องมีอะไรซักอย่างป่าวที่บอกได้ว่า สิ่งนี้ควรทำก่อน และกระจายงานออกมาได้
- @visibletrap: @llun ใ่ช่ครับ ในความคิดผมคือ feature ที่ง่ายที่สุด ที่ execute ผ่าน front-end ถึง back-end
-
@visibletrap: @llun Tracer bullet ใน Pragmatic programmer ที่ผมยืมพี่อ่านไง
- @llun: @visibletrap มันได้ผลกับ Project ที่ทำส่วนตัว แต่ไม่ได้ผลเวลาต้องทำกับคนอื่นแฮะ ฮ่า
-
@visibletrap: @llun เพราะคนอื่นไม่ทำด้วยอะดิ
อันนี้ชุดแรก จากนั้นก็ตามมาด้วย (26 กรกฎา)
- @teerapapc: 400+ syntax errors down to zero. Refactoring hurts even there’s a helper tools.
- @visibletrap: @teerapapc จริงๆ ถ้าทำตามขั้นตอนที่คัมภีร์ Refactoring เขียนเนี้ย จะไม่ค่อย error นะ แต่จะช้ามาก แล้วต้องฝึกมาจนชำนาญแล้วด้วย
- @llun: @visibletrap @teerapapc มีเป็นคัมภีร์ -*-
- @hybridknight: @llun @visibletrap @teerapapc ท่าจะเมพ -*-
- @llun: @visibletrap พวก dynamic type lang คงต้องใช้ test ช่วยมากกว่า
- @visibletrap: @hybridknight @llun @teerapapc ก็เล่มที่เคยๆเห็นกันนั่นแหละ ข้างในมันจะสอนให้ทำทีละขั้น เช่น decouple ในไฟล์เดียวกันก่อน แล้วค่อยแยกออกมา
- @visibletrap: visibletrap: @llun exactly!
- @visibletrap: @llun จริงๆ static type ก็ต้องใช้ เพราะไม่มี error ไม่ได้แปลว่ามันทำงานได้
-
@teerapapc: @llun @visibletrap btw, those syntax errors are 60%+ from test classes.
- @visibletrap: @teerapapc Nothing surprise because the test was write first but now you are leaving the test behind.
- @teerapapc: @visibletrap No matter what tests or the real code I modify first. The amount of code need to be modified is the same though.
- @visibletrap: @teerapapc Good broken tests should provide you checklist of which feature/component we need to cover
- @llun: @visibletrap @teerapapc What’s good broken tests and bad broken tests?
- @visibletrap: @llun test ที่ไม่ดีตัวอย่างนึง อย่างเช่น test ที่ test ซ้ำๆ เรื่องเดิม แบบไม่มีประโยชน์
- @llun: @visibletrap อือ แต่ปัญหาที่เจอกันส่วนใหญ่ไม่ใช่เรื่องการ test ซ้ำเรื่องเดิมป่าวหว่า
- @visibletrap: @llun แล้วปัญหาที่เจอนี้มันเกี่ยวกับ bad test ด้วยหรือเปล่าหละ
- @llun: @visibletrap ไม่รู้แฮะ เพราะมันมีหลาย module มากและเวลาคุยกันทีก็ปนๆ กันจนบอกไม่ถูก
- @visibletrap: @llun ตรงที่ผมพูดเรื่อง good bad ผมพูดรวมๆ อะครับ ถ้าพี่เจอ test ที่ไม่มีประโยชน์ ก็แปลว่ามัน bad คราวหน้าก็อย่าเขียนแบบนี้ ไรงี้
หมดก๊อกสอง ยังมีต่อๆ คราวนี้ใน G+ เนื่องจากอันนี้อ่านง่ายมี Thread ให้กดไปอ่านตาม Link ได้เลย (อยากให้ update G+ embed ลง blog ได้แฮะ)
วันนี้มีต่อ (3 สิงหา) แต่จริงๆ ก็เรื่องเริ่มซ้ำหละ
- @teerapapc: รู้สึกมากขึ้นเรื่อยๆ ว่า คนเขียน test กับ คนเขียน code ควรจะคนละคนกัน
- @visibletrap: @teerapapc อย่างงั้นมันก็จะเป็น black box อย่างเดียวอะดิ ซึ่ง black box ไม่เพียงพอต่อการ test ในหลายกรณี
- @llun: @visibletrap @teerapapc ถ้ากำหนดมาก่อนว่า code นั้นต้องทำอะไรบ้าง จะ black box ก็เพียงพอนะ
- @visibletrap: @llun @teerapapc ไม่พอครับ เช่น logic ที่รันเดือนละครั้ง ถ้า test black box พี่จะทำยังไง ให้ test ได้ง่ายๆ
- @llun: @visibletrap @teerapapc ก็อย่างที่บอก กำหนดมาว่า component นั้นต้องการอะไร ได้อะไรออกมา แต่ถ้าระดับ component มันใหญ่ไปก็ซอยออกมา
- @visibletrap: @llun ถ้าคิดกันจะละเอียดขนาดนั้นแล้ว ใครเขียน test ก็เหมือนกันหละครับผมว่า
- @llun: @visibletrap แต่ถึงจะไม่ทำ test ก็ต้องทำเพื่อให้ได้ scope ของงานและไม่ทำอะไรหลุดจากกรอบมากไป
- @visibletrap: @llun ครับ ถูกแล้วครับ ต้องเข้าใจ requirement ให้ชัดเจนก่อนทำสิ่งใดๆ จะได้ไม่เปลืองแรงเปล่า
- @visibletrap: @llun แต่อย่าลืม integrate กับ component อื่นบ่อยๆ เพราะสิ่งที่เข้าใจอาจจะเข้ากับ component อื่นไม่ได้
- @llun: @visibletrap อือ อันนั้นต้องทำ functional test ครอบทั้งหมดอีกที โดยเอา contact point ของ function มารันอีกรอบโดยเปลี่ยนเป็น comp จริง
- @visibletrap: @llun ลืมไป ว่าพี่เป็นด่านหน้าสุดให้ user มา interact แล้ว ไม่ต้องไปให้ component อื่น consumer อีก
คุยๆ เสร็จถึงวันนี้ก็รู้สึกว่าคุยเรื่องพวกนี้กับ @visibletrap เยอะขึ้นมากเลย ทั้งที่ก่อนหน้านั้นคุยเรื่องพวกนี้ด้วยน้อยมาก เสียดายอย่างเดียวที่ตัวเองน่าจะ Active ทำ Process พวกนี้จริงจังมาก่อนหน้านั้น ไม่ใช่พึ่งนึกได้เอาตอนนี้ นี่สินะเค้าเลยมี ป.โท สาขา Software Engineer ให้เรียน
