Fanboi Channel

มิตรสหายนักพัฒนาซอฟต์แวร์ท่านหนึ่ง

Last posted

Total of 184 posts

180 Nameless Fanboi Posted ID:3KN+X4F3sH

เห็นพี่ที่เคารพท่านหนึ่งพูดเรื่องเข้าใจ พื้นฐาน OOP ผิดกันเยอะ

ทั้งหมดโพสต์นี้เป็นความเห็นส่วนตัวของผมนะ แต่ก็เป็นวิธีที่ผมใช้มอง OOP แล้วยังคง Sanity ไว้ได้

- OOP ตัวตั้งต้นของ Alan Kay พูดถึงเรื่อง State encapsulation ซึ่งผมเข้าใจว่าเขาต้องการแบ่งปัญหาออกเป็นปัญหาย่อยๆ และจัดระเบียบและแบ่งสันปันส่วนว่าระบบตรงไหนเข้าถึง State ตรงไหนได้บ้าง ซึ่งเขาไม่ได้สนใจเรื่อง Code reuse เลย ไม่มี Polymorphism ด้วย ไม่ต้องพูดถึง Inheritance เลย

- ยุคหนึ่ง การทำ Dynamic link เพื่ออัพเดทโค้ดผ่านการวาง DLL หนึ่งไฟล์ หรือ Class 1 ไฟล์เป็นอะไรที่โอ้โหเจ๋งมาก ผมคิดว่ามันเกิดในยุคที่คนยังส่งมอบซอฟต์แวร์ผ่าน Floppy disk จำนวนมากอยู่ แล้วคอนยเซปต์ Dynamic link ที่สามารถสับเปลี่ยน Class ได้ตลอด ไม่ต้องส่ง Floppy disk 40 แผ่นผ่าน EMS เพื่ออัพเดทซอฟต์แวร์หนึ่งชิ้นแล้ว โคตรเจ๋งเลย!!! ในยุคนั้นสิ่งนี้เป็นเรื่องสำคัญ ส่วนสมัยนี้เหรอ ทำ Patch ทั้ง App ผ่าน Internet ง่ายกว่าเยอะ ซึ่งบนข้อจำกัดนี้ ไม่แปลกใจที่ Inheritance เป็นคอนเซปต์ที่มีพลังมาก ผมจำได้ว่าผมอ่าน Polymorph ครั้งแรกช่วงที่ยังใช้ Floppy disk กันอยู่ เดาว่าคอนเซปต์มันเกิดช่วงนี้

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

- เวลาเราเข้าใจ OOP ถ้าเราเข้าใจว่าเรื่อง Separation of concern, State encapsulation มันเกิดคนละยุคกับช่วงที่เขาโปรโมตเรื่อง Code reuse, Inheritance, Polymorph เราจะเก็ตว่าทำไมพอพยายามใช้งานจริง บางทีคอนเซปต์มันขัดกันเองแปลกๆ บางทีพอพยายามจะ Encapsulate แล้ว Reuse ยากจังวุ้ย แล้วตรงข้าม พอพยายามจะ Reuse ให้ได้เยอะๆ ทำไมโดเมนบางทีมันผสมกันไปหมดเลยวุ้ย พอเรารู้แบบนี้ เราไม่ต้องไปหาทาง Justify ครับ แค่เข้าใจว่ามันเกิดคนละยุค Practice ที่เกิดมันเลยอาจจะไม่เป็นเนื้อเดียวกันหมด (แต่เราเรียนบนหัวข้อเดียวกันคือ Object-oriented programming ทำให้หลายคนเข้าใจว่าทุกอย่างเป็นเนื้อเดียว Well-thought มาทั้งหมดแล้วถูกออกแบบมาดีแล้วแค่ทำตามพอ ซึ่งผมว่าไม่ใช่) ตรงนี้มันเป็นช่องว่างที่เราต้องใส่ไอเดียของตัวเองเข้าไป

ที่ผมแซวเรื่อง Original OOP เยอะเพราะอยากให้เห็นว่า Object-oriented มันมีหลายมุมที่เกิดในหลายยุคนะ

พอเรารู้ว่ามันมีหลายยุคแล้วได้ประโยชน์ยังไง? ตัวผมเองใช้แบบนี้

- ผมมองว่าจังหวะที่เราเริ่มสเกลทีมแล้วแบ่ง Cross-functional การมองไปมองที่ Original OOP ที่เน้นเรื่อง Domain encapsulation เป็นอะไรเหมาะสมกับโจทย์กว่า

- Code reuse strategy อาจจะประยุกต์เอาคอนเซปต์ของ Functional programming เข้ามาใช้ได้ครับ ซึ่งผมสนใจการผสมผสานตรงนี้ เพราะผมไม่ชอบ Inheritance by default เวลาคิดอะไรไม่ออก ส่วน Reuse by composition ผมว่า Function composition มัน Concise และมี Expressive power มากกว่า Object composition ครับ

181 Nameless Fanboi Posted ID:KUE.FNg5rK

วันนี้เพิ่งไปทำความรู้จักกับ Redis มาเลยจะมาแนะนำให้ฟัง https://redis.io/ (บทเรียนแบบสนุกลองไปหน้านี้ http://try.redis.io/ ครึ่ง ชม. ก็จบแล้วครับ)

มันคือ service ที่รันบนคอมแล้วเหมือนเรามีตัวแปร Dictionary, HashSet, ... มหัศจรรย์ให้ใช้ที่สามารถรุมใช้จากหลายๆ client ผ่านเน็ตได้อย่างสวยงาม ซึ่งถึงตัวแปรที่ว่าจะอยู่บน memory ไม่ได้เซฟแต่ก็มีฟังก์ชั่น replay คำสั่งให้ถึงเครื่องพังพอเปิดมาใหม่ก็มีตัวแปรสภาพเดิมได้แบบนั้นก็มีครับ เลยเอามาใช้เป็น database กันก็ดูไม่เลวไม่แคร์ความ RAM กันเลย

ความ in memory ไม่ต้องเซฟทำให้ความเร็วสูงพอที่จะใช้ algorithm ที่ไม่ค่อย scalable ใน DB ปกติได้ เช่นการ count หรือ sort (ไม่ใช่ indexing) อัตโนมัติทุกครั้งที่เพิ่มข้อมูลใหม่เข้าไป ใครเคยใช้ Firebase Cloud Firestore / RDB จะรู้สึกว่ามันน่าจะทำ scoreboard ลำบากไม่ก็เปลืองเงินมาก ส่วนมากปัญหาจะอยู่แถวๆที่ว่าอยากรู้ว่าเรา rank เท่าไหร่หลังจากเพิ่งอัพเดทคะแนนไป ซึ่ง count ก็เปลือง ถ้าจะเซฟเลขเก็บไว้เดี๋ยวมีคนแซงก็เลขเลื่อนกันหมดอีก ถ้า Firestore อัพเดทเสียเงินเป็นหน่วย document แล้วน่าจะเจ็บหนักครับ ต้องดีไซน์แผนดีๆเพื่อให้เสียเงินน้อยลงแล้วทีนี้ structure ก็จะดูไม่สวยงามอีก (เช่นต้องมี document เดียวที่มี bake คะแนน top 100 กองอยู่ด้วยกัน แล้วปัญหาอื่นอาจจะตามมา เช่นต้องคอย sync ข้อมูลหน้า avatar ที่ฝังอยู่ในนั้น ฯลฯ)

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

อยากศึกษาว่าทำไม leaderboard ถึงเป็นปัญหายาก https://redislabs.com/redis-enterpr…/use-cases/leaderboards/

ถ้าอยากลองเล่นสามารถลอง Tier ฟรีของ Redis Labs ที่สปอนเซอร์คนทำ Redis อยู่ได้ สามารถเปิดคอมกับ AWS/GCP/Azure ได้สามที่ เปิดมาแล้วมี RAM ให้ 30MB ซึ่งดูเหมือนน้อยแต่สมมติถ้า record นึง 32 bytes (~ GUID + float) ก็เก็บได้ตั้งประมาณ 900,000 คะแนนแน่ะ ถ้า trim ไว้ให้ rank แค่ top 10000 อะไรงี้ก็คิดว่าเหลือเฟือได้หลายบอร์ดเลยครับ

https://redislabs.com/

ของฟรีไม่มี data persistence ให้ ถ้าคอมรีสตาร์ทแล้วของใน RAM จะหายหมดไม่มี replay แล้วก็ connection ได้ถึง 30

แต่ถ้าไม่ใช้เป็น DB แล้วใช้เป็นตัวแปรจริงๆก็น่าจะพอไหวครับ เช่น ใช้ Cloud Firestore ในการเก็บคะแนนของแต่ละคนเป็นส่วนตัวอันนี้แบบกลัวหาย แล้ว export ไป Redis ที่ไม่กลัวหายเพื่อให้เป็นคอมที่เปิดไว้ ranking หรืออื่นๆที่ต้องยุ่งกับผู้เล่นอื่นแบบ active หน่อยโดยเฉพาะ

คิดๆไว้ว่าอาจจะสร้าง record ไว้ใน Redis ประมาณว่า "exported" เวลาอพยพไปแล้ว + trim เสร็จแล้ว ทีนี้ถ้าคอมพัง ฝั่ง Firebase ก็จะได้ถาม Redis เจอว่าไม่มี record นั้นแล้วดังนั้นอพยพอีกรอบ ถ้าอพยพเสร็จแล้วทีนี้ทุกครั้งที่มีคะแนนใหม่ก็แค่แถมไปใส่ฝั่ง Redis ด้วยจะได้ถาม rank กลับมาได้

เท่าที่ดูคร่าวๆนอกจาก Sorted Set แล้วมีฟีเจอร์เท่นึงที่ชอบคือสามารถสร้าง record ที่นับเวลาถอยหลังแล้วหายไปเองเมื่อถึงเวลาได้ครับ (EXPIRE) ดูน่าจะเอาไปเล่นได้หลากหลายดี (เช่น ทำ ranking ที่จัดอันดับทุก ชม. แทนเพื่อให้ไม่ต้อง connect ไป Redis ทันทีที่ใครซักคนทำคะแนนได้ ทำ timed challenge ในเกม ฯลฯ)

182 Nameless Fanboi Posted ID:m9KixmgCXW

"Don't underestimate the power of survival of the fittest. And don't ever make the mistake that you can design something better than what you get from ruthless massively parallel trial-and-error with a feedback cycle. That's giving your intelligence much too much credit."

Linus Torvalds

183 Nameless Fanboi Posted ID:tjmmFZ5Rv2

GildedRose Kata นี่เป็นแบบฝึกหัดที่ดีมากเลยนะ

คือ Engineer จำนวนมากพยายามแก้ไขปัญหา Technical Debt ด้วยการที่บอกว่า "อย่าสร้างสิ เขียนให้ดีสิ" แต่ในโลกความเป็นจริงแล้วเรามีโค้ดที่เละยังงี้เต็มไปหมด บางทีเราก็สร้างเองเพราะงานเร่ง มันเป็นอะไรที่หลีกเลี่ยงไม่ได้เลย

คำถามคือเราจะทำยังไง เวลาเจอโค้ดยังงี้

ถ้าใครบอกว่าจะ Refactor นี่ก็เป็นโจทย์ที่ดีที่จะได้ฝึก

หรือแม้แต่ถ้าใครบอกว่าเจอ Tech debt เยอะๆ ฉันจะไม่แตะแล้ว จะ Rewrite แม่งอย่างเดียว คุณก็ลอง Rewrite GildedRose ขึ้นมาดู ก็เป็นแบบฝึกหัดที่ดีอีก

คุณจะได้เข้าใจว่าการ Rewrite ในทางปฏิบัติ ที่ Requirement ส่วนมากจะไม่ครบ มันต่างกับในอุดมคติเยอะ เอาแค่ Rewrite ระบบเล็กๆ อย่าง GildedRose นี่แหละให้รอดก่อน ค่อยไปลองขอ Rewrite ระบบใหญ่ๆ

(ผมต้องเน้นเสมอว่างาน Rewrite != งาน Green field ระดับความยากมันต่างกันแบบคนละเลเวลกันเลย Engineer หลายคนคิดว่าเวลาที่ได้ใบอนุญาตให้ Rewrite ระบบที่เละๆ ใหม่จากศูนย์ มันจะให้อารมณ์สวยงามเหมือนทำ Greenfield Project ซึ่ง ขอบอกเลยว่าโคตรจะไม่ใช่)

ผมคิดว่าการจัดการกับ Legacy code เป็นสกิลที่สำคัญมาก คือผมมองว่ามันมีเส้นแบ่งที่ใหญ่มากระหว่างคนที่เขียนโค้ดสวย กับเปลี่ยนโค้ดไม่สวยเป็นโค้ดสวยได้ (ไม่ว่าจะด้วยวิธีใดๆ) คือถ้าสมมติแบ่งเป็น 10 Grade ผมว่าคนที่ทำได้กับไม่ได้ฝีมือต่างกันอย่างน้อย 2 Level แน่ๆ

และ GildedRose เป็นแบบฝึกหัดที่คุณจะได้ลองจัดการกับ Legacy Code ของจริง ไม่ว่าคุณจะเลือกจัดการมันยังไง ค่อยๆ แก้ หรือเขียนโครงใหม่จากศูนย์ก็ตาม

Repo นี้มีให้เกือบทุกภาษาให้เล่น ใครสนใจลองเล่นดูได้ครับ

184 Nameless Fanboi Posted ID:9HOuboPpuT

ใน Javascript, Typescript ผมชอบที่จะเขียน OOP ด้วย Higher-order function มากกว่า Class keyword
ผมพบว่าถ้าคุณรู้จักและใช้ Higher-order function (HOF) ตัวเดียว มันสามารถทำได้หมดเลยทั้ง Inheritance, Decorator, Annotation, Implements, Private, Public และอีกหลายๆ Keyword ที่ในหลายๆ ภาษา OOP คุณต้องเรียนทีละตัวว่าแต่ละตัวคืออะไร Inherit คืออะไร ทำงานยังไง Decorator คืออะไร ทำงานยังไง
ถ้าใช้ HOF คุณเรียนแค่ว่ามันคืออะไรตัวเดียวพอ แล้วแต่ละสิ่งข้างบน มันทำงาน Conceptually เหมือนกันหมด ส่วนในรายละเอียด อ่านโค้ดเองได้เลย ขอแค่เข้าใจ HOF
หรือแม้แต่สิ่งที่หลายๆ ภาษา OOP ไม่มีอย่าง Multiple Inheritance คุณก็ทำด้วย HOF ได้และสามารถบอกได้หมดว่าแต่ละ Conflict แก้ไขยังไง
เราเขียนโปรแกรมแบบ OOP Paradigm โดยไม่ต้องมีคำว่า "Class" ได้นะ เผื่อไม่รู้
แล้วส่วนตัว ผมคิดว่าโค้ด HOF สวยเพราะมี Language construct เดียวแต่ทำได้ทุกอย่างอย่าง Concise โค้ดก็ไม่ได้บวมด้วย และไม่ต้องจำอะไรเยอะแยะว่าไอ้นั่นคืออะไรไอ้นี่คืออะไรมากมาย ซึ่งอันนี้มักจะเป็นความเห็นที่ต่างกับหลายคนที่บอกว่าโค้ดที่ทำ HOF อ่านไม่รู้เรื่อง อ่านยาก พอมีคำว่า Class สวยกว่า
ปล. จริงๆ ผมเข้าใจได้นะว่าทำไมคำว่า Class สวยกว่าในแง่นึง และผมก็เลือกใช้กับหลายๆ ทีมที่เขา Familiar กับสิ่งนี้ไปแล้วเหมือนกัน มันก็ง่ายที่จะอ่านมากกว่ามาเรียนรู้ใหม่ล่ะ แต่ไม่อยากให้ปิดใจกับ HOF แล้วลองดูกัน