Fanboi Channel

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

Last posted

Total of 199 posts

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 แล้วลองดูกัน

185 Nameless Fanboi Posted ID:J+X0H4d8PM

อยากตั้งคำถามให้วงการไอทีไทยอีกที นี่เป็นรอบที่เท่าไหร่ก็ไม่รู้แล้ว ทำไม Programmer ต้องโปรโมทไปเป็น SA แล้วไปเป็น PM/Mgr ทำไมเราไม่เห็น Growing Path ที่สนับสนุน Individual Contributors ในไทยนะ

ผมเห็น engineer อายุรุ่นราวคราวเดียวกัน (+/- 5 ปี) พอถึงอายุ 35 จะต้องเริ่มคิดว่าแล้วกูจะทำอะไรต่อดี เพราะอายุ 35 แล้วเนี่ยบริษัทไทยไม่ค่อยมี Path ให้ คุณต้องเลือกไป Management สักทาง ในขณะที่ใน ตปท เค้ามีโอกาสให้ Engineer โตจนเก๋าๆ อายุ 50 ปีเยอะแยะเลย
พอเราต้องแข่งกับระดับโลก เราก็ถามอยู่นั่นแหละ คนเก่งเราเยอะแยะ แล้วทำไมเราสู้เค้าไม่ได้ ก็เพราะคนเก่งเราเปลี่ยนจากเรื่องที่เค้าเก่งมาทำเรื่องที่เค้าเก่งน้อยกว่ากันหมด เพราะระบบและสังคมมันบังคับไง ด้วยความที่ไทยเราเป็นสังคมอำนาจนิยม ใครอายุ 3x ไม่ได้เป็น manager เราก็จะมองว่าเค้าไม่ประสบความสำเร็จแล้วล่ะ เราไม่ได้ให้คุณค่ากับ individual contributor มากพอ สุดท้ายถ้าเค้าไม่ยอมแพ้ให้กับระบบ เค้าก็จะพาตัวเองออกจากระบบไปเลย

อยากแข่งกับโลกต้องทำไง ดูจีนครับ เค้าให้ value กับ IC มาก มากพอๆกับ management แหละ #ช่วยตัวเองกันไปก่อนนะครับ

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

186 Nameless Fanboi Posted ID:iiWV5+IkmP

แอปเกมสนุกๆ เล่นได้ง่ายๆ ทำกำไรมากมายได้ตลอด 24 ชั่วโมงพิเศษสมัครใหม่วันนี้รับโบนัสทันที 50%
หากสนใจการทำเงินที่มีแต่ความสนุกสนานกดเลย!
https://www.ballinw.com/ดาวน์โหลด-live22/

187 Nameless Fanboi Posted ID:N8yR2iPBQ7

ขอจดอัพเดทความรู้ Technical ที่เก็บได้เด็ดๆช่วงนี้หน่อย

1. การวาง Structure Code แบบ "Functional Core, Imperative Shell"
ไปเรียน Testable Web API กับพี่คริส (Taskworld, Omise) มา สะดุดกับ Concept นี้มากๆ เพราะส่วนตัวชอบความ Resilience ของ OO ในส่วนของ IO ต่างๆ แต่พอมาเป็น Business Logic เราใช้ต่อ บางทีมันรู้สึกขัดความรู้สึก ไม่ว่าจะ Test ยากเอย เขียนเสร็จชื่อ Object ไม่ค่อย Make Sense เอย มีความขี่ช้างจับตักแตนอยู่ พอมาฟังพี่คริส Demythify เรื่องนี้ Concept มันดู Eureka จริงๆ

2. ด้วยเหตุข้อ 1 Typescript มันดูหล๊อหล่อขึ้นมาทันที ด้วยความที่มันลดความบ้านป่าเมืองเถื่อนของ Javascript ในจุดที่เราต้องการได้

3. ขึ้น Project ใหม่ ยุคนี้ หาข้ออ้างไม่ทำ CI/CD ยากละน้า นั่งลองเล่น Cloudbuild ต่อเข้า Github แล้ว Deploy ลง App/Kubenetes Engine กดๆแปปเดียวเสร็จ เข้าใจง่าย Integration Test ก็ทำไว้ใน Cloudbuild ได้หมด และ Infra as a code มันชีวิตง่ายขึ้นจริงระบุ Instance เอาขึ้น เอาลง Scale ไป Size เท่าไร ชีวิต Dev Happy

4. เช่นเดียวกันทำ Web / App ให้ Scalable ก็มาในยุคที่ Cost ถูกลงมาก (ทั้ง Cost Infra / Operation) เครื่องไม้เครื่องมือพวก Queue, Message พวกนี้ Cloud Provider มีให้ใช้ง่ายๆทุกเจ้าแล้ว

5. Concept ของพวก Distribution System อย่าง At least/Exactly Once semantic,Idempotent, Redundancy หรือกระทั่งการทำ Event Storming อันนี้น่าศึกษาไว้ Even กับ Role อย่าง Product Owner / Manager ก็ตาม

188 Nameless Fanboi Posted ID:rN.oRvueE4

ตอบในฐานะ SA นะครับ เรื่อง Set สำคัญกับการออกแบบระบบมาก เพราะปัจจุบันการเขียน Software จะให้ความสำคัญกับ Bussiness Rule มากกว่าการ Modeling ถ้าคุณอยากเขียนซอฟแวร์ในระดับลึกมันไม่ใช่การใช้ Api ชาวบ้านอีกต่อไป มันคือการสร้าง Architect ครับ
.
Set มีบทบาทยังไง การที่จะเขียนโปรแกรมให้ตอบโจทย์ Bussiness เราจะต้องมี Context กับ Operation ให้เหมาะสม ดังนั้นการเขียนโปรแกรมที่ Generic มาก ๆ ที่ชอบทำกันเนี่ย มันไม่ใช่ผลดีกับระบบ เราต้องแบ่ง Context ของระบบให้แก้ปัญหา Bussiness ให้ได้
.
แล้วอะไรจะใช้คำนวณว่าเราออกแบบ Class ได้ตรงความต้องการของระบบไหม คำตอบคือ Set ครับ
.
เช่น
A { x | ILoginService }
หมายความว่า เราสนใจ Elements ของ ILoginService
.
ทีนี้เรา Specific ได้แล้วว่าอะไรคือ Service ที่กำลังพัฒนา ต่อมาที่เราต้องเช็คคือสิ่งที่อยู่ใน Set มีความสำพันธ์กันอย่างไร
.
สมมติ A { LineLogin, FacebookLogin }
สมมติมี Service อยู่สองตัว ทีนี้เราหาความสำพันธ์ของมัน
.
ถ้ามันเป็น Isolation เคสเพราะนี้เป็น A+B ก็คือ
ต่อมาเราก็สนใจที่ตัว Elements ของ set ค่อยๆ ไล่ไปทีละตัว
.
การออกแบบ Class เราต้องนึกถึง 1. Relationship, 2. Multiplication, 3. Communication
.
ทีนี้เราสนใจลึกลงไปอีก step
เช่นผมสนใจ A { x | FacebookLogin }
.
ทีนี้ Set ของเราจะเป็น Aggregation ของ FacebookLogin
.
ดังนี้ FacebookLogin { TokenValidator, SendValidRequestEvents } ( ของจริงเยอะกว่านี้ นี่แค่ยกตัวอย่างมา 2 อัน )
.
ทีนี้ความสัมพันธ์มันเป็น AB คือ Existence Dependency ถ้าตัวไหนพังก็พังทั้ง Service
.
Event ของสองตัวนี้เป็นแบบ Sequence คือต่อกัน
คือ Validate input แล้วค่อยส่งไป Server
ทีนี้เราก็มาวิเคราะห์ว่าจะใช้ Pattern ไหนในที่นี้ใช้ Middleware Pattern เพราะ Flow input เป็นแบบ Sequence
.
เราก็ไล่ออกแบบไปเรื่อยๆ ตามนี้ ซึ่งความยากคือ Entity ของระบบมันมี Invariant ต่างกัน Aggregate ต่างกัน Concurrency ก็ต่างกันอีก
.
ในโลก Software คือความยากมันไม่ใช่แค่คณิตศาสตร์ มันคือ Concept มหาศาล หลากหลาย Principal แต่ที่ผมจะบอกคือเรื่อง Set เนี่ยมันทำให้เรามองเห็น Domain ที่กำลังจัดการอยู่ให้ชัดขึ้น ทีนี้เราจะมอง Dependency ออก มอง Communication ออก ที่เหลือก็ไปว่ากันที่ Pattern กับ Persistence
.
ถ้าคุณแยก Domain ไม่ออก อย่าพูดถึง Design Pattern เลย ปนกันมั่วแน่นอน
ไอ้สูตร Set ที่คุณเรียนกันตอนม. ปลายนี่แหล่ะ เคสที่มันได้ใช้
.
Cohesion กับ Coupling ก็ Set
ถ้าระบุ Set ไม่ได้ Object มันก็คุยมั่วไปหมด หา Boundary ไม่เจอ
.
จริงๆ ยังมีมากกว่านี้อีก ผมยกตัวอย่างแค่ Service เดียวเอง เผื่อพอเป็นไอเดียว่าคณิตศาสตร์มันไม่ใช่แค่ผูกกับการแก้สมการอย่างเดียวมันมีมุมมองอื่น ๆ ด้วย
.
Code ที่แก้สมการในระบบมันคือ Behavior ของ Class กับของ Service ที่เราสนใจแค่นั้นเอง ว่าจะแก้ยังไง ไม่ใช่แค่หน้าที่ของ Dev แต่หมายถึงการสื่อสารระหว่าง Dev กับ Domain Expert ในด้านนั้น ๆ เพื่อร่วมกันแก้ปัญหา
.
สุดท้ายกับคำถามที่ว่า “เป็นโปรแกรมเมอร์ใช้คณิตศาสตร์กี่ %”
1. Empirical Expression
2. Numerical Expression
นี่แหล่ะสองสิ่งที่คุณจะใช้

189 Nameless Fanboi Posted ID:H.2gEPSKN8

ปริญญาโทด้านคอมพิวเตอร์มันจำเป็นมากป่าววะ หรือไปหางานทำดี

190 Nameless Fanboi Posted ID:kKPvrhZOLi

>>189 ถ้าจะมาเป็น dev ทำงานจริงจำเป็นกว่า

191 Nameless Fanboi Posted ID:2IjyEbqevB

ปรึกษาหน่อยค่ะ

192 Nameless Fanboi Posted ID:On/WDCA26e

หนึ่งในเรื่องสำคัญที่หลายต่อหลายคนมองข้าม ก็คือ "พิมพ์ดีด"

ต้องฝึกให้คล่องนะ อย่างน้อยๆ นี่ 30 คำต่อนาทีขึ้นไปควรจะได้ ไม่งั้นจะ inefficient มากในการทำงาน

และแน่นอนว่าการพิมพ์ที่ดี ควรพิมพ์ได้โดยไม่ต้องมองแป้นพิมพ์เลยแม้แต่นิดเดียว

ไม่เช่นนั้นก็จะมี interruption ของกระบวนการคิดเกิดขึ้นตลอดเวลา ... สมองจะต้องทำ context switching ระหว่างคิดสิ่งที่จะต้องพิมพ์ และการมองคีย์บอร์ดตลอด ทำให้คิดอะไรซับซ้อนและต่อเนื่องลำบาก .... คิดอะไรได้ไม่เท่าไหร่ ก็ต้องเปลี่ยนโหมดมาดูแป้นพิมพ์แล้ว ...

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

โปรแกรมฝึกพิมพ์ดีดดีๆ นี่ช่วยได้เยอะมากเลย

โปรแกรมที่ผมชอบมาก ก็คือ GNU Typist (gtypist) .... ที่มีลำดับในการสอนที่ดีมาก และมีปรัชญาในการสอนที่ดีเลย ก็คือแทนที่จะเน้นไปที่พิมพ์เร็ว .... เขาจะเน้นที่จังหวะการพิมพ์ (rhythm) และความถูกต้อง .... ถ้าพิมพ์ข้อความแล้วผิดเกิน 3% นี่จะไปต่อไม่ได้ (และผิดแล้วผิดเลย แก้ไม่ได้)

พิมพ์เร็วนี่ไม่ยากหรอก ถ้าพิมพ์เป็นจังหวะที่ดีและคงที่ได้ .... พิมพ์รักษาจังหวะไว้ จากนั้นมันจะค่อยๆ เร็วขึ้นเอง

อ่อ แล้วการคิด WPM (Words-per-Minute) ของมัน จะเอาจำนวนที่เราพิมพ์ผิดมาคิดด้วย ว่าจริงๆ แล้วเราพิมพ์ได้กี่คำต่อนาทีกันแน่

จะเห็นว่าในรูปแรก ผมพิมพ์ถูกหมด WPM ก็เป็นไปตาม Raw speed (95 WPM) แต่รูปที่สองนี่มีผิดอยู่หน่อย (2%) ทำให้แม้ว่าจะพิมพ์ที่ Raw speed 83 WPM ก็ถูก adjusted เหลือ 75

ที่สำคัญที่สุด คือมันทำบทเรียนหรือแบบฝึกหัดเองง่ายมาก ..... อย่างรูปสุดท้าย นี่ผมเอาโค้ด Haskell ที่ผมเขียนไว้สอนใน Workshop หนึ่งมาเป็นแบบฝึกหัดเลย

เอาไว้ให้พวกเด็กฝึกงานหรือพนักงานใหม่ฝึกพิมพ์ดีดไปกับสไตล์การเขียนโค้ดที่ใช้ในทีมได้เลย

193 Nameless Fanboi Posted ID:mEaJ6TxBLG

Redis ได้เงินลงทุนรอบใหม่ มูลค่ากิจการเกิน $1 billion แล้ว unicorn ของจริงช่วงนี้มีแต่สาย technical

ในไทยหาคนยังหาที่เคยใช้เยอะๆคุยด้วยได้ไม่กี่คน มันดีมากจริงๆ ยิ่ง module ที่ทำจริงจังช่วง 3-4 ปีหลังนี้ ทั้ง graph, timeseries, search คือดีทั้งหมด ถึง feature จะไม่เยอะเท่าคู่แข่งแต่ใช้ง่ายกว่ามาก เสียดายยังไม่มีโอกาสได้ลองใช้ redisAI ที่เพิ่งออกมาใหม่ไม่นาน เพราะงานตอนนี้ไม่ได้ทำเรื่อง ML, AI หรือ Data โดยตรงแล้ว

194 Nameless Fanboi Posted ID:Z0x2Ht2SpO

>>193 quote เก่าแล้วป่าววะ กูเห็นใครๆก็ใช้

195 Nameless Fanboi Posted ID:NUAlkwJ4cO

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

อนาคต ทุกคนก็จะเขียนโปรแกรมเป็นหมด แต่โปรแกรมเมอร์ที่เขียนได้ดี ก็จะยังมีงานทำอยู่ดี

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 ผิด เลือกภาษาผิด แบบคนละเรื่องเลยนะ พวกนั้นไม่ทำให้โปรเจ๊กต์พัง แค่ทำให้เหนื่อยเฉยๆ อ่ะครับ