Review: di-lite.js Dependencies injection ใน javascript แบบเบาๆ

ใน Javascript มีคนทำ Dependencies injection อยู่หลายเจ้า อาทิเช่น
wire.js
inverted
di-lite.js
หรือใน angular.js ก็ได้ข่าวว่ามีให้ใช้เหมือนกัน แต่เนื่องจากงานในปัจจุบันมันเกาะติดกับ Backbone อย่างแนบแน่นจนแงะไม่ออกไปเสียแล้ว เป็นอันว่าตัดทิ้งไป

ลองคุ้ยเขี่ยอยู่นาน ก็ตัดสินใจเอาเจ้าตัว di-lite นี่ล่ะมาใช้ เพราะตัวอื่นมันมากับ dependency พ่วงมาอีกประมาณหนึ่ง แถมต้องเขียนโมดูลแบบ AMD ซึ่งผมก็เพิ่งจะรู้เนี่ยแหละว่าเดี๋ยวนี้เขานิยมเขียนแบบนี้กัน

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

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

• Constructor arguments
• กำหนด Strategy ได้ (Singleton, Prototype) 
• ทำ Circular reference ก็ได้
• เรียก function อัตโนมัติหลังจากที่ initialize เสร็จแล้วได้

ซึ่งเท่านี้ก็เพียงพอสำหรับความต้องการ(ในตอนนี้นะ)

ที่นี้มาดูข้อเสียกันบ้าง

ข้อเสียที่เด่นๆเลยก็คือ วิธีประกาศ Dependencies มันแนวไปหน่อย ลองไปดูก็ได้ครับ ถ้าเราตัดสินใจจะใช้เจ้าตัวนี้ มันก็มีตราบาป (this.dependencies) ติดอยู่กับ Class ของเราไปตลอดกาล
แถมยังมีผลข้างเคียง ถ้ามีเพื่อนร่วมทีมมาดูโค้ดก็จะงง ว่า ไอ้ property ตัวนี้มันมาจากไหน (ซึ่งปกติ Javascript ก็ดูโค้ดยากด้วยตัวมันเองอยู่แล้ว ในระดับหนึ่ง)

ต่อมาคือเขียน Configuration แยกออกมาต่างหากไม่ได้ ต้อง Register เอาเองล้วนๆ ต่อไปถ้ามีของเยอะๆ อาจจะต้องเขียน Module สำหรับเอาไว้ Register โดยเฉพาะเลยก็เป็นได้

ยังทำ reference ไม่ได้ อย่างเช่นจะเอา module ที่ register ไปแล้วมาเป็น Constructor argument แบบนี้ยังทำไม่ได้ (แต่ set หลังจาก initialize แล้วได้นะ ต้องซิกแซกเอาหน่อย)

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

สรุปว่าก็นำมาใช้งานได้ในระดับหนึ่ง อย่างน้อยมันก็ดีกว่ามานั่ง new แล้ว assign ให้เอาเองล่ะนะ แล้วก็ทำให้เขียน Class กับ Test ได้ง่ายขึ้นด้วย ตัวอื่นๆอาจจะเจ๋งกว่านี้ แต่มันต้องเปลี่ยนเยอะ เหนื่อย เอาไว้มีโอกาสทำอะไรเล่นอาจจะเอาตัวอื่นๆมาลองอีกครับ

ทำไมมันขายไม่ออกวะ

ครับ หลังจากที่ผมเอาTDDไปขายแล้วเกิดอุบัติเหตุดราม่าขึ้นมาจนเซ็งไปหลายวัน
พอจิตใจเริ่มสงบ + ไประบายใน Testing Wednesday มา ก็ได้มุมมองและข้อคิดกลับมา (ดราม่าจนเสียการเสียงานแล้วต้องได้อะไรกลับมาบ้างเนอะ :)))) ถ้ามีโอกาสก็ไปกันนะครับ อิอิ

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

ก่อนอื่นเลย มันเกิดอะไรขึ้นกับการขายของผม?

เออ เราว่าเราเข้าใจมันนะ ข้อดีมันก็เห็นๆกันอยู่ ก็รู้อยู่ว่าจะเก็ตมันไม่ใช่เรื่องง่าย
แต่มันดีจริงๆนะ ทำเถอะครับ

เอาล่ะครับ ถึงเวลา อ่ะ มาทำกัน เอาน้องๆมาทำด้วย เริ่มแรกก็ดีครับ ไปได้เรื่อยๆ

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

กำลังจะทำต่อไป ตรงนี้แหละครับ
ยกตัวอย่าง สมมติว่าผมกำลังทำ undo/redo command ถ้าเราจะทำ undo ได้ เราก็ต้องเก็บ state ก่อนหน้าเอาไว้ใช่มั้ยครับ ผมก็บอกว่า ให้เพิ่มเทสลงไปอีก 1 ข้อ นั่นคือ ตัว command ต้องเก็บ state เอาไว้
อันที่จริงผมวางแผนเอาไว้ว่า ตรงนี้เทสมันเริ่มเยอะแล้วใช่มั้ยล่ะ ควรจะแตกคลาสที่เป็นตัว operation ออกไปดีมั้ย

แต่..

กลับถูกแย้งมาว่า ไม่เห็นต้องเทสข้อนี้เลย แค่ do แล้ว undo ได้ก็น่าจะพอแล้วนี่

โอ้พระเจ้า พี่พูดอะไรออกมาน่ะ(นึกถึงเสียงพากย์ในละครเกาหลีไว้นะฮะ)

นี่มัน unit test นะ สิ่งที่กำลังขอให้ทำมันไม่ใช่แล้ว โลกแตกแน่ถ้าทำอย่างที่ว่า

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

• ท่าเยอะไปไหน กว่าจะทำเสร็จ Performance/Efficiency ทั้งทีมไม่หายไปหมดเหรอ
• ทำไมต้องแตก Class มั้นเปลืองมั้ย
• Function ยาวๆ ไม่ extract ได้มั้ยล่ะ เขียน comment เอา
• Static method มันบาปยังไง
• Code quality มันคืออะไร? ไม่ใช่ว่าเขาไม่เข้าใจนะ แต่ขอให้ผมอธิบาย ตอนนั้นก็อธิบายออกไปไม่ได้เลย
• เอาบทความนี้มาให้ดู http://37signals.com/svn/posts/3159-testing-like-the-tsa
• วิธีถ่ายทอดของผมห่วยแตกมาก พาเพื่อนเซ็ง
• ใช้คำพูดไม่ดี เวลาไม่ได้ดั่งใจ
• ตกลงมึงอยากทำงาน หรือทำ TDD!!!
• มีอีกนะ แต่นึกไม่ออก มันเบลอไปหมดตอนนั้น

ข้อรองสุดท้ายมันสะเทือนใจผมมาก มันอะไรกัน ที่ขวนขวายหาวิธีการอะไรต่างๆเยอะแยะก็เพราะอยากให้งานมันดีขึ้นนะเฮ้ย!

แต่ดูเหมือนจะไม่มีใครมองอย่างนั้น

ผมดูเป็นคนบ้าตำรา ประณีประนอมไม่ได้ ไม่ได้สนใจทีมหรืองานเท่าไหร่หรอก

นี่มันยิ่งกว่าโดน Stun 10วิ หรือโดนรุมตุ๋ยกลางป่าอีกครับ ผมแทบอยากจะออกจากเกมเสียเดี๋ยวนั้นเลย

เสีย Self ครับ บอกตรงๆ

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

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

แน่นอน ผมไม่ได้อยากให้เป็นอย่างนี้เลย

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

ถ้ามันวอดวาย เราก็ค่อยรอตบทีหลัง

สวัสดีครับ
OK bye

อยู่ดีๆมันก็หายไป

ผมหงุดหงิด รู้สึกเซ็งๆมาหลายวันติดๆกันแล้ว

จนกระทั่งวันนี้ตลอดทั้งวันก็ยังเป็นอยู่ จนถึงเย็นนี่ล่ะ รู้สึกดีขึ้นมาเฉยๆ

ลองมานั่งพิจารณาว่าเป็นเพราะอะไร เพราะเรื่องที่ทำให้เซ็งช่วงนี้มันก็มีอยู่ลหลายเรื่อง เยอะแยะไปหมด

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

แต่ที่ดีกว่านั้นคือ ความเซ็งที่มันเกาะกินจิตใจมาเป็นอาทิตย์ๆ เหมือนมันจะเบาบางลงไป เยอะเลย

หรือว่าเราเองที่ไม่ชอบให้เถียง

ผมไม่ชอบเถียงกับใคร
ด้วยความที่เป็นคนคิดอะไรช้า เวลาเถียงกับใครก็คิดไม่ทันเขา เลยพยายามเลี่ยงอย่างที่สุด

วันนี้ได้คิดไปคิดมาอยู่หลายตลบ ผิดที่เขาที่มาเถียงผม หรือเป็นผมเอง ที่หงุดหงิดเวลาโดนเถียง

คิดไปคิดมายังไม่ได้คำตอบ จบไว้ดื้อๆเท่านี้แหละ

fail() ใน jasmine

วันนี้พยายามหาว่าใน jasmine มันมี fail() เหมือนกับใน junit มั้ยนะ คือหาในหน้าหลักแล้วไม่ยักจะมี

ลองไปคุ้ยๆดูก็พบว่า อ้าว ก็มีเหมือนกันนี่ แต่มันมีวิธีการใช้นิดหน่อย ตามนี้ ( ทำไมในหน้าหลักไม่มีก็ไม่รู้แฮะ หรือฉันตาถั่ว หรือมันกั๊ก หรือเป็นเพราะรัฐบาล ... ช่างมันเถอะ)

it("Should do something", function(){

     this.fail(new Error('Not yet implemented'));

});

• เราไม่สามารถเรียก fail เฉยๆ ได้ ต้องเป็น this.fail(Error)
• Argument ที่โยนให้ต้องเป็น Error เท่านั้น ใช้ String เหมือน Junit ไม่ได้

ตอนแรกไม่ได้ใช้เลย แต่นั่นเพราะขี้เกียจจะคิด Spec ออกมาก่อนมากกว่า ยังติดนิสัยเดิมๆอยู่บ้าง ซึ่งพอลองใส่สเปคก่อนแล้วค่อยเขียนตามมั้นไป ก็พบว่าดีขึ้นพอสมควร

ยังคงต้องฝึกฝนอีกเยอะล่ะ

เจอจากที่นี่ https://github.com/mhevery/jasmine-node/issues/81