Fanboi Channel

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

Last posted

Total of 199 posts

196 Nameless Fanboi Posted ID:RjknmBsvAI

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

"เดี๋ยวนี้สงสัยไม่สอนเรื่องนั้นเรื่องนี้"
"ทำไมไม่สอนเรื่องนั้นเรื่องนี้"
"ต้องให้ความสำคัญกับเนื้อหานั้นนี้มากกว่านี้"

ฯลฯ

ผมว่าผิดทางครับ ..... ปัญหาไม่ใช่เนื้อหา หรือการมองเห็นความสำคัญว่าจะต้องสอนหรอกครับ ......

ปัญหาใหญ่กว่านั้นคือ "วิธีการสอน" และ "วิธีการเรียนรู้" ครับ

ถ้าเราคิดว่าปัญหาคือ "เนื้อหาการสอน" เราก็จะไปแก้ที่เนื้อหา ต้องยัดเรื่องนั้น ต้องมีเรื่องนี้ ฯลฯ

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

ส่วนหนึ่งก็เพราะคนสอนก็จะถูกบังคับให้ต้องสอนเรื่องนั้นเรื่องนี้ให้มีเนื้อหาเรื่องนั้นเรื่องนี้อย่างเร่งด่วน ปีนี้ยัดเนื้อหา ปีหน้าต้องสอน อะไรแบบนี้เป็นต้น ....

คนสอนก็ทำอะไรไม่ได้ นอกจากสอนตามตัวอักษรและวิธีการในเนื้อหาแบบเป๊ะๆ เพราะตัวเองก็ไม่ได้เล่น ไม่ได้ตั้งคำถามอะไรเหมือนกัน ....

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

ยิ่งเราบอกว่าต้องสอนเรื่องนั้นเรื่องนี้เพิ่มเข้าไปไม่มีที่สิ้นสุด ปัญหานี้ก็ยิ่งหนักขึ้นทุกวัน

ถ้าดูจากเนื้อหาและปริมาณ ผมว่าเราก็ให้ความสำคัญกับทุกเรื่องนะ ... คณิตศาสตร์ ภาษาอังกฤษ ประวัติศาสตร์ วิทยาศาสตร์ .... อีกหน่อยก็จะโค้ดดิ้ง และวิทยาการคำนวน ......

ปัญหาคือ "วิธีการสอน" และ "วิธีการเรียน" แหละครับ

มีแค่นี้จริงๆ

============

[Slide Story] น้องๆ และสหายหลายต่อหลายคน ที่มาเรียนเรื่อง Maths for Working Programmers และ Functional Programming กับผม หลายคนที่ยังใกล้ชิดมหาลัยอยู่ก็พยายามจะไปบอกให้มหาลัยสอนเรื่องพวกนี้บ้าง ...

ผมก็ต้องเตือนน้องๆ และมิตรสหายเหล่านี้เสมอว่า "สอนเรื่องนี้แบบผม เรียนเรื่องนี้แบบที่น้องเรียนกับผม น้อง/คุณก็อินแล้วก็สนุกแหละครับ" ....​ "เนื้อหาพวกนี้ มีในหลักสูตรนะ เรื่องนี้อยู่ตรงนี้ เรื่องนั้นอยู่ตรงโน้น ฯลฯ" .... เห็นไหม มีนะ ไม่ใช่ไม่มี ฯลฯ

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

============

รูป: นกแก้วบนเครื่องถ่ายเอกสาร ..... รูปที่อยู่ใน presentation slide ที่ผมเคยใช้บ่อยมาก เดี๋ยวนี้ไม่ค่อยได้พูดเรื่องนี้แล้ว

197 Nameless Fanboi Posted ID:/D5kF8KFla

ใน reddit มีคนเอามาแปะ ก็เล่าไปใน reddit แล้วเอามาเล่าให้คนไทยฟังบ้าง

ที่ Wongnai ใช้ ArgoCD อยู่มันจะเป็น step แบบนี้ครับ

1. project build & push docker ใน gitlab ci
2. step สุดท้ายของ ci เรามี tool มา clone ceylon (deploy manifest) repo, create branch, update image tag, push branch แล้วเปิด merge request (MR)
3. tool มันจะ mark MR ให้ auto merge on pipeline success เป็นอันจบ pipeline ของ project
4. pipeline ของ MR ที่เข้า ceylon มี tool validate (หวังว่าจะมีเวลา open source ให้) มันจะ run ArgoCD template ได้ JSON มาแล้วโยนเข้า kubeval
(แปลว่ามี check 2 ที่ คือ Jsonnet assert สำหรับ best practice check + kubeval เช็คว่า valid)
5. MR merge เสร็จแล้ว argocd auto sync ยกเว้น prod ต้องกด sync เอง

ฉะนั้นจากในบทความนี้เราเลยไม่ค่อยเจอปัญหาเหมือนเค้า

1. ผมเข้าใจว่าเค้า clone แล้ว push master แข่งกัน มันเลย race แต่เราเปิด MR แล้วให้ gitlab merge มันเลยไม่ต้องแย่งกันเพราะเราไม่ได้ตั้งให้ rebase ก่อน merge
จะมี race ก็คือ MR project เดียวรัน 2 อันพร้อมกัน อันนี้ช่วยไม่ได้นอกจากไปตั้ง Gitlab ว่าให้ยกเลิก pipeline เก่าเมื่อมีอันใหม่กว่า (ซึ่งเราไม่ได้เปิด)
2. เราใช้ deployment monorepo แถม branch เดียวทุก env ด้วย เลยไม่มีปัญหาว่า repo เยอะ งง
ทีมบ่นอยู่บ้างว่าอยากได้ branch เพิ่มจะได้ทดลองของได้โดยไม่กระทบ prod อันนี้ยังมองๆ อยู่ว่าจะทำยังไงไม่ให้มันระเบิดแบบเค้า
3. Visibility ยากนี่เรื่องจริง มี git log ก็จริงแต่ไม่รู้ว่ากด sync ใน ArgoCD ตอนไหนต้องไปค้น ArgoCD log
4. Validation เรามี validate tool เลยชิล

ปัญหาที่ผมเจอจริงๆ น่าจะเป็นว่า

1. Rollback ยากมาก คือต้องถอย commit ออก แต่พอ change มันเป็นแค่ปรับ image tag มนุษย์ทั่วไปเข้าใจไม่ได้ว่าถอยเท่าไรถึงจะหายบั๊ก (ถอยโค้ดยังอ่าน commit message พอได้) แล้วมันหลายขั้นตอนมาก คนเลยชอบไปกดใน ArgoCD ซึ่งมันทำให้ decouple cluster state ออกจาก git state หรืออีกทีคือถอย commit ในแอพเลยแล้วรอ build ซึ่งนานมากกกกก
2. Post deploy step ทำยากมาก เช่น deploy dev เสร็จแล้วรัน automate test ไม่รู้จะเช็คยังไงเลยว่า deploy ยังไง (MR merge แล้วแต่ก็ต้องรอ sync + pod rollout) ที่ทีมทำกันอยู่มีแต่ท่า hackๆ

198 Nameless Fanboi Posted ID:0yCFcOKe8j

>>197 wongnai ไปทำไรใน reddit

199 Nameless Fanboi Posted ID:m4O69XJjXm

สองสัปดาห์ที่ผ่านมาประชุมเยอะขึ้นมากๆ แต่รู้สึกว่าได้ทำงานเป็นชิ้นเป็นอันจากการประชุม ไม่ได้รู้สึกว่ามัวแต่ประชุมไม่ได้งาน

ทำให้เข้าใจอย่างนึง เวลาประชุมแล้วไม่มีประสิทธิภาพมันไม่ได้เกิดจาก Format ในงานประชุมเสมอไป แต่เรื่องนึงที่ทำให้ไม่มีประสิทธิภาพ รู้สึกว่าไม่ได้งาน คือ เวลาประชุมเพื่อ "สร้างความมั่นใจให้ผู้เกี่ยวข้อง"

ผมเริ่มเห็นว่าการประชุมแบบนี้ Effective ต่ำและกินพลังงานเยอะ ไม่ได้แปลว่าควรเลิก แต่แปลว่ามีช่องให้พัฒนาได้เยอะ

ในโดเมนการพัฒนาซอฟต์แวร์ เครื่องมือที่สร้างความมั่นใจที่ดีที่สุดคือ Working software รองลงมาคือ Demo ส่วนการทำสไลด์หรือการพูดคุยย้ำๆ ว่า โปรเจ๊กต์ยังไปได้ งานยังดี อันนี้สร้างความมั่นใจได้น้อยกว่าอย่างมาก แถมยังต้องพูดย้ำบ่อยๆ แล้วเปลืองเวลา

จะพบว่าเวลาคุณรัน Agile, Scrum, etc. แล้วคุณต้องสร้างความมั่นใจทุกๆ สองอาทิตย์ มันจะบังคับให้คุณต้องมี Demonstratable Progress ในเลเวลนั้น

และมันจะกระทบไปถึงวิธีเขียนโค้ด Process การทำงาน การวางโครงสร้าง

พอมาถึงหัวข้อนี้ ผมไม่ Buy เลยว่าพอทำ Scrum แล้วจะทำให้ Architecture ห่วย แต่มันต้องใช้ Architecture style และ Mindset ที่ต่างกัน

เช่น หลายคนเชื่อว่าคุณสมบัติของ Fundamental Architecture ที่ดีคือสิ่งที่ทำครั้งเดียวแล้วทนทานใช้ได้ตลอดกาล ซึ่งพอเปลี่ยนวิธีทำงาน คุณสมบัติที่สำคัญกว่าในการทำงานแบบ Agile (ที่มี Feedback loop สั้น) ถ้าต้องแก้ แก้ง่าย ทุกคนแก้ได้หมด เป็นคุณสมบัติที่มี Priority สูงกว่าความทนทานใช้ได้ไม่มีวันพังไม่ต้องแตะ ในโลกแบบ Agile

เขียนไปเขียนมาแตกหัวข้อไปหลายเรื่องแฮะ ขอสรุปหน่อยว่า Reflect อะไรได้บ้าง

- การประชุมเป็นเครื่องมือที่คนนิยมใช้เมื่อต้องการ "สร้างความมั่นใจให้ผู้เกี่ยวข้อง" แต่ มันเป็นเครื่องมือที่ Effective ต่ำมาก ถ้าประชุมอันไหนมีหน้าที่แค่ "รายงานให้คนเกี่ยวข้องสบายใจ" แปลว่ามี Room for improvement เยอะมาก อย่างเลเวลแรก จากสไลด์ 30 นาที คุณเปลี่ยนเป็นทำเป็นเดโม 5 นาที ได้ความมั่นใจมากกว่าโดยใช้เวลาน้อยกว่าเยอะ ถ้าเปลี่ยนเป็นแค่ Deploy working software แล้วบอกให้คนเกี่ยวข้องมาลองเล่นเองได้ ยิ่ง Effective เลยใช่มั้ย และสิ่งที่ Effective ที่สุดคือ ทำให้เขาเชื่อมั่นจนเขาบอกเองว่า "ไม่ต้องอัพเดทพี่แล้ว พี่ไว้ใจทีม มีอะไรให้พี่ช่วยมั้ย ถ้าไม่มี พี่เอาเวลาไปทำอย่างอื่นดีกว่าว่ะ" อันนี้คือ End game และตราบใดที่ยังไม่ถึงตรงนี้ เรายังสามารถหาทางดิ้นเพื่อพัฒนาได้เรื่อยๆ

- พอพัฒนาข้อแรกมันจะมากระทบ Process การทำงาน ไปจนถึงโค้ดที่เขียนแต่ละบรรทัดเลยนะ ซึ่งไม่เป็นไร กระทบก็กระทบ ผมไม่เห็นว่าเสียหายอะไร แต่ต้องเข้าใจว่ามันกระทบ ซึ่งบางครั้งกระทบไปลึกซึ้ง ถึงนิยามว่า Practice ที่ดีไม่ดีคืออะไร Architecture ที่ดีไม่ดีคืออะไร นิยามและความเข้าใจมันจะเปลี่ยนได้

เอาจริงๆ ผมขอบคุณประสบการณ์ตัวเองและอาจารย์ที่สอนสั่งมาหลายท่านว่าธุรกิจเขาคิดอะไรกัน คือผมมีประสบการณ์ในวงการ Startup ที่มี Exposure โดยตรงกับผู้เกี่ยวข้องมาตลอด ทำให้เวลาผมเรียงลำดับความเสี่ยงที่ทำให้โปรเจ๊กต์ล้มเหลวได้ ผมเรียงว่า
1. ทำไม่ได้ทรัพยากรไม่พอ อันนั้นลำดับหนึ่ง
2. ทำไปทำมา ระหว่างทางคนลงทุนขาดความมั่นใจจนถอนทุนแคนเซิลโปรเจ๊กต์ อยู่ลำดับสอง

แล้วปัญหาที่แบบวางโครงสร้างไม่ดี วางโค้ดไม่ดี ใช้ Tech stack ผิดแล้วล้มเหลวต้องแก้ไข ผมมองว่าเป็นความเสี่ยงลำดับล่างๆ อาจจะเกิน 10 ด้วยซ้ำไปมั้งถ้าแตกหัวข้อจริงๆ

ผมเลยไม่มีปัญหากับการ Bend ตัวโค้ด สถาปัตยกรรม โครงสร้าง เพื่อแก้ความเสี่ยงข้อ 2 ทำไงก็ได้ให้ทำให้คนเกี่ยวข้องมั่นใจไม่ถอนทุน ถ้าต้องมี Automated test ก็ต้องมี ถ้าต้องมี Evolutionary architecture ก็ต้องมี ถ้าวางอะไรลงไปแล้วต้องแก้ทีหลัง ก็ต้องทำ (ตรงนี้มันเถียงกับความเข้าใจผิดของหลายๆ คนได้อีกว่า การทำ Engineering practice ห่วยๆ จะทำให้ปั่นงานเร็วกว่า มีอะไรไปอัพเดทสร้างความมั่นใจบ่อยกว่า ซึ่ง ผมว่าไม่ใช่)

ซึ่งผมมองว่ามันเสี่ยงกว่าเรื่องที่ว่าเลือก Tech stack ผิด เลือกภาษาผิด แบบคนละเรื่องเลยนะ พวกนั้นไม่ทำให้โปรเจ๊กต์พัง แค่ทำให้เหนื่อยเฉยๆ อ่ะครับ