Fanboi Channel

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

Last posted

Total of 179 posts

150 Nameless Fanboi Posted ID:l7gjDlZ9Af

โค้ดสตาร์ทำให้กูต้องมานอนตอนนี้

151 Nameless Fanboi Posted ID:.BrhVtl6PZ

>>150 มึงรอเล่นมุกนี้มานานมั้ยเนี่ย

152 Nameless Fanboi Posted ID:dgPoGmed5u

>>151 ไม่นานเพราะไอเหี้ยโค้ดสตาร์นี่แหละ

153 Nameless Fanboi Posted ID:l4YnjwzBB5

รถติดก็เพราะโค้ดสตาร์มอมเมาคนมาเรียน

154 Nameless Fanboi Posted ID:l4YnjwzBB5

รู้ไหมว่าขนาดพระเยซูยังนับถือศาสนาโค้ดสตาร์เลย

155 Nameless Fanboi Posted ID:l4YnjwzBB5

พระแม่อุมาหน้าหีไปเรียนกับโค้ดสตาร์แล้วมาปิดถนนสีลม

156 Nameless Fanboi Posted ID:Dd8heMKoaN

โค้ดสตาร์ทำให้ประชาชนคนไทยยากจน

157 Nameless Fanboi Posted ID:HtSfFE/JRk

ทำไมมีการปิดถนนที่อนุเสาวรีย์ตอนเช้า กับสีลมตอนเย็น ๆ เมื่อวันก่อน พอรู้บ้างไหม

158 Nameless Fanboi Posted ID:/DjWmyGu27

เรื่องขำๆของเซเลปท่านนึง

เท่าที่จำได้
โตนเตะรอบแรกเพราะสั่งลบกลุ่ม แต่เฟสบุ๊ค รออนุมัติ 14 วัน ก็เลยยังมีกลุ่มนี้อยู่ทุกวันนี้
แล้วก็สถาปนาตัวเองเป็นสตีฟจ๊อปเมืองไทย

รอบสอง บอกว่าจะไม่ยุ่งกะกลุ่ม level 1 แต่เข้ามายังไงไม่รู้ ก็มีดราม่าตามคาด แล้วรอบนี้ ออกเอง แอตมิน แคบไว้ แต่บอกชาวโลกว่า แอตมินเตะออก

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

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

มีน้องที่ทำงานด้วยบอกเคยไปเรียน PHP yii ด้วย แล้วเหมือนติด config ก็เลยไปช่วยดู กลับโดนตวาดใส่ “เก่งแล้ว มาเรียนทำไม” อีหยังวะ ยังงี้ก็ได้เหรอ

แยกย้ายทำงานๆ

159 Nameless Fanboi Posted ID:fLJEn7Z5Db

>>157 เพราะอีพระอุมาหน้าหีมาเรียนโค้ดสตาร์เลยต้องปิดถนน

160 Nameless Fanboi Posted ID:I2P6cl4lEI

วันนี้นั่งอ่านว่าผิดหวังจาก Blazor แล้วจะไปลองเล่นอะไรดีสำหรับโฮมเพจเกม (คงไม่ interactive มาก แต่อย่างน้อยอยากทำเว็บที่ประกอบจาก component) ตอนแรกว่าจะลองศึกษา React Hooks แต่ใน documentation ก็ได้รู้จักกับ Svelte https://svelte.dev/

อันนี้มันเท่ตรงที่ UI Framework ปกติจะให้เราเป็นคนเขียนโปรแกรมตามกติกาแล้วเราจะพอดูออกว่า จังหวะนี้นั้นนี่เองที่ framework รู้ว่าเราอยากจะอัพเดทชิ้นส่วนไหน แต่ก็ไม่ได้รู้หมดเด๊ะๆขนาดนั้น ก็เลยต้องควบคู่กับการ diff DOM + อาจจะมีตัวช่วยอย่าง ID ประจำ element นิดหน่อยจะได้เปลี่ยน DOM ถูกที่ เช่นถ้า React ก็จะมีจังหวะตอน set state

แต่ Svelte ก้าวข้ามไปอีกขั้นคือเป็น compiler ซะเลย คือเว็บสุดท้ายที่ออกมาไม่มี framework ให้โหลดมาคู่กันด้วยซ้ำ เพราะโค้ดที่เราเขียนนั่นแหละกลายเป็น DOM manipulation ด้วยตัวเองไปแล้ว! (ประมาณว่าออกมาเหมือนเหมือนเราทนเขียน web app แล้วมาแก้ DOM ด้วยมือแบบไม่มีเครื่องมืออะไรเลย)

เขาก็เลยสร้าง syntax ภาษาใหม่ .svelte ขึ้นมาที่หลุดจากบ่วง JS ได้เลยไหนๆก็เป็น compiler แล้ว ทีนี้ก็ไม่ต้องมีพิธีที่รู้สึกได้ว่ากำลังครอบอยู่บน JS อีกต่อไป assignment เปล่าๆอย่าง foo = 50 อะไรงี้ compile กลายเป็น DOM change ซะงั้นได้ครับ ที่สำคัญไม่มีการ diff เกิดขึ้นด้วยซ้ำเพราะโค้ดสุดท้ายมันกำลังแก้หน้าเว็บสดๆจริงๆ เขาวิจารณ์ไว้ว่า Virtual DOM is pure overhead (https://svelte.dev/blog/virtual-dom-is-pure-overhead)

ตอนนี้ยังไม่ถึงไหนเท่าไหร่ แต่ syntax เขียนค่อนข้างสนุกดี ดูเหมือนโล่งๆไม่มีอะไรแต่ component ก็พร้อมใช้งานแล้ว ยากแค่ต้องมาทำความเข้าใจ bundler อย่าง Rollup / Webpack อีกหน่อยครับถ้าจะ extend (แต่อีกมุม มันก็คือความโปร่งใสดีว่าเว็บเราออกมาเป็นก้อนๆนี้ ไม่เหมือน Blazor ที่เป็น .dll วุ่นวายไปหมด)

*Angular ก็เป็น compiler เหมือนกัน ที่เขียนขึ้นมาสดๆยังใช้จริงไม่ได้ https://angular.io/guide/aot-compiler ไม่เหมือน React ที่เป็นสั่ง JS lib จริงๆ (แต่ก็ต้อง compile จาก JSX ก่อนอยู่ดี) แต่ทั้งคู่ไม่ได้ฉีกห่างออกจาก JS เว่อร์เหมือน Svelte

*แปลว่า ผอมเพรียว

161 Nameless Fanboi Posted ID:WZqtoxmmK9

ตระหนักไว้เสมอว่ามีคำว่า "Engineer" ในชื่อตำแหน่งของ "Software Engineer"
.
เป็นสิ่งนึงที่เรียนรู้มาจากอาจารย์ที่เคารพมากตอนป.ตรี อาจารย์ท่านถามว่า
.
"... รู้มั้ยทำไมงานพวกเราถึงถูกเรียกว่า Software Engineer ? ..."
.
"... ก็เพราะสิ่งที่เราต้องทำมันเป็นงาน *วิศวกรรม* ยังไงหละ ..."
.
สีหน้าสงสัยปนสนใจของเราทำให้ยังไม่ทันที่จะเอ่ยปากถาม อาจารย์ก็เดาออกทันทีว่าเราจะถามอะไร อาจารย์เลยตอบคำถามที่เรายังไม่ทันถามได้ทันที
.
"... วิศวกรซอฟต์แวร์หนะ เราไม่ได้แค่เขียนโปรแกรมให้ใช้งานได้นะ แต่หน้าที่ของเราคือต้องแก้ปัญหาทางคอมพิวเตอร์โดยคำนึงถึง *ความคุ้มค่าที่สุด* ให้ได้ด้วย ..."
.
ตั้งแต่นั้นเป็นต้นมา คำว่า "คุ้มค่าที่สุด" ก็ถูกฝังไว้ในหัวและกลายเป็นแกนกลางของการแก้ปัญหาใด ๆ ในทุกงานของเรา ความเข้าใจเพียงเบาบาง ณ ตอนนั้นก็ค่อย ๆ ถูกประสบการณ์หล่อหลอมให้เข้าใจมากขึ้นจนรู้แล้วว่ามันไม่ใช่แค่เรื่องของการพัฒนาซอฟต์แวร์ แต่กับทุกเรื่องในชีวิตเลย
.
อาจจะสงสัยว่าความคุ้มค่าที่สุดที่ว่าคืออะไร ? คำตอบคือ "เราต้องรู้ว่าจุดประสงค์ของงานนั้น ๆ คืออะไร สิ่งที่ได้กลับมามีมูลค่ามากน้อยแค่ไหน และเราต้องลงทุนลงแรงไปมากน้อยเพียงใดถึงจะคุ้มกับสิ่งที่ได้มา"
.
งานที่ทำแล้วใช้ครั้งเดียวทิ้ง ทำ Big-O แย่ ๆ โดยใช้เวลา 30 นาทีในการเขียนแล้วปล่อยให้มันรัน 1 ชั่วโมงเต็มก็ยังคุ้มค่ากว่าเขียนโปรแกรม 3 วันเต็มด้วย Big-O เทพ ๆ แต่รัน 1 นาทีเสร็จ ... แล้วก็โยนทิ้งไป
.
งานที่รันตลอดเวลา ลงทุนเขียนโปรแกรมเป็นเดือนให้ทำงานได้ ≤ O(log n) นี่แหละคือความเหมาะสมและคุ้มค่ากับสิ่งที่ได้มา
.
แต่ถ้างานมีเวลากระชั้น การนั่งทำ Big-O เทพ ๆ แล้วส่งงานไม่ทันก็อาจจะส่งผลเสียต่อธุรกิจ ก็ต้องสามารถบาลานซ์ได้ว่าจะต้องทำด้วย Big-O เท่าไหร่เพื่อให้ประสิทธิภาพยอมรับได้และส่งงานทัน แล้วค่อยมา Optimize ให้ดีขึ้นทีหลัง
.
Code Quality เทพเนียนกิ๊กแต่ Deliver งานตามกำหนดไม่ได้ รันโปรดักชั่นไม่สำเร็จ สเกลไม่รอด ธุรกิจพังไม่เป็นท่า บริษัทเจ๊ง ถ้าเทียบกับ Code Quality พอดี ๆ เขียนเทสต์ในส่วนที่จำเป็น ส่งงานทัน บริษัทกำไรเพิ่มแล้วค่อยมาปรับ Code Quality ให้สมบูรณ์ทีหลัง
.
งาน Software Engineer กับธุรกิจจึงเป็นเรื่องเกี่ยวข้องกัน หน้าที่นึงของ Software Engineer คือจะต้องสามารถนิยามคำว่า "ความคุ้มค่า" ของงานที่ตัวเองทำให้ได้
.
และการจะทำสิ่งนี้ได้นั้น เราจะต้อง "ประเมินมูลค่าของสิ่งที่ทำและสิ่งที่ตัดสินใจไม่ทำให้ได้"
.

162 Nameless Fanboi Posted ID:WZqtoxmmK9

การเขียนโปรแกรมดีเลิศ Code Quality ดี โค้ดดูแลง่าย - มีมูลค่าบวก
.
การเขียนโปรแกรมดีเกินไปจนสิ่งที่รับกลับมามีค่าน้อยกว่าแรงที่ลงลงไป (Overengineer) - มีมูลค่าลบ
.
การเขียนโปรแกรมแย่ แก้ทุกอย่างแบบ Quick & Dirty จนโค้ดดูแลไม่ได้ในระยะยาว (Technical Debt) - มีมูลค่าลบ
.
การเขียนโปรแกรมด้วยภาษาที่หาคนร่วมทีมได้ง่าย - มีมูลค่าบวก
.
การเขียนโปรแกรมด้วยภาษาที่ต้องควานหาคนทั้งปฐพีถึงจะเจอคนทำเป็นสักคน - มีมูลค่าลบ
.
การส่งงานทัน - มีมูลค่าบวก
.
การส่งงานไม่ทัน - มีมูลค่าลบ
.
การจะทำงานสักงานนึงก็ต้องเอาค่าด้านบนพวกนี้มาบวกกัน ดิฟนิดหน่อย อินทิเกรดนิดนึง (เพราะมันมีเรื่องเวลามาเกี่ยวข้อง ความคุ้มค่าระยะสั้น ความคุ้มค่าระยะยาว ล้วนมีผลต่อการตัดสินใจ) แล้วถึงตัดสินใจกันว่าจะเดินไปทางไหน
.
จะเห็นว่างานของ Software Engineer ไม่ใช่แค่เขียนโปรแกรมให้จบ ๆ ไป ไม่ใช่การเขียนให้ Code Quality ดีเลิศที่สุดในปฐพี ไม่ใช่การเขียนโค้ดที่ประสิทธิภาพล้ำจนเอาคนไปแข่ง ACM ได้ แต่เป็นการ "หาจุดคุ้มค่าที่สุดแล้วทำอย่างเหมาะสม" ต่างหาก
.
บ่อยครั้งมากที่มีคนถกเถียงกันเรื่อง Code Quality เอย เรื่องประสิทธิภาพการทำงานของโค้ดเอย เรื่องการเขียน Test เอย แล้วผลก็คือเสียงแตก จะบอกว่าไม่มีทางหรอกที่แต่ละคนจะให้คำตอบเหมือนกัน เพราะเรายังไม่ได้นิยามคำว่า "คุ้มค่า" ร่วมกันเลยนี่
.
เมื่อความคุ้มค่าไม่เหมือนกัน แล้วจะคาดหวังให้การตัดสินใจของแต่ละคนเหมือนกันได้ยังไงอ่ะ ?
.
ไม่ต้องไปถึงขั้นคนไม่รู้จักกันมาคุยกันใน Facebook Group หรอก แค่ในบริษัทตัวเอง ฝ่าย Business กับฝ่ายเขียนโปรแกรมก็ไม่สามารถคุยกันรู้เรื่องได้แล้วถ้าไม่สามารถคุยด้วยจุดมุ่งหมายเดียวกันได้
.
แล้วอะไรคือจุดมุ่งหมายร่วมกันของบริษัทหละ ?
.
"ธุรกิจก็คือธุรกิจ" ไม่ว่าจะทำอะไร ยังไงก็ต้อง Business-Driven อยู่แล้ว ถ้าไม่มีกำไรบริษัทแล้วจะไปต่อยังไง ถ้าสิ่งที่ทำกลับทำให้บริษัทขาดทุนแล้วจะเปิดบริษัทต่อไปทำไม หน้าที่ของ Software Engineer คือต้องประเมินมูลค่าออกมาเป็นตัวเลขและความคุ้มค่าให้ได้ เพื่อเอาสิ่งเหล่านี้ไปคุยกับฝ่าย Business หาจุดคุ้มค่าร่วมกันแล้วมุ่งหน้าสู่ทางนั้นเต็มอัตรา
.
ถ้ายังทำไม่ได้ นั่นแปลว่าคุณยังทำให้คนอื่นมองเห็นมูลค่าของงานที่คุณทำไม่ได้นั่นเอง
.
เป็นสกิลนึงที่อยากให้คนสาย Software Engineer ฝึกไว้ อย่าเอาแต่เขียนโปรแกรมไปวัน ๆ แต่เมื่อได้โจทย์อะไรมา เราจะต้องสามารถวิเคราะห์สถานการณ์ วางแผนไว้หลาย ๆ แบบ ประเมินมูลค่าของแต่ละแบบแล้วเลือกแผนที่ "คุ้มค่า" ที่สุด
.
เพราะมันไม่มีหรอกคำตอบที่ดีที่สุดสำหรับทุกสถานการณ์ มันมีแค่ "ทางที่เหมาะสมที่สุด" เท่านั้นแหละ
.
เหมือนที่เธอกับเราเหมาะสมกันไง 😳😳😳

163 Nameless Fanboi Posted ID:WZqtoxmmK9

พี่โดมพูดเรื่องนึงได้น่าคิด

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

Line ก็มาหลัง MSN หลัง Pirch หลัง ICQ
Gmail มาหลัง Hotmail
Booking Agoda พวกนี้ก็มีมานานแล้ว
Kapook มาหลัง Yahoo

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

164 Nameless Fanboi Posted ID:Xwx2VBLIQm

At my (now former) company, we use a metric called SHOT to track the performance within a portfolio. It's some in-house calculation no one else uses, but it's been around for like 20 years even though no one remembers what the acronym is supposed to mean. My task was to average it over a time period, with various user-defined smoothing parameters... to accumulate it, in essence.

So, I don't like long variable names like "accumulated_shot_metric" or "sum_of_SHOT_so_far" for what is ultimately just the cumulated SHOT value. So I gave it the short name, "cumShot", not thinking twice about it, and checked it into the code. Seeing that it passed all tests, I went home and forgot about it.

Two months later, today, my boss called me into a meeting with HR. I had no idea what was going on, but apparently, the "cumShot" variable had become a running joke behind my back. Someone had given a printout to the CEO, who became angry over my "unprofessional humor" and fired me. I didn't even know what anyone was talking about until I saw the printout. I use abbreviated variable names all the time, and I'm not a native speaker of English so I don't always know what slang is offensive.

I live in California. Do I have any legal recourse? Also, how should I explain this in future job interviews?

165 Nameless Fanboi Posted ID:.ioNbtqt3s

อันนี้ผมเคยบอกแล้วว่า เงินเดือน ไม่เกี่ยวกับ skill เลยซะทีเดียว มันมีปัจจัยหลายอย่าง
หลักๆคือ มันคือความพอใจของคนจ่าย ที่เค้าได้ผลประโยชน์ตามที่เค้าต้องการครับ
คนเก่งมากๆ เขียนได้วันนึงหลายอย่าง แต่อาจจะได้เงินเดือนน้อย ไม่ใช่เพราะเค้าไม่เก่ง แต่เค้าอาจจะอยู่ในจุดที่บริษัทไม่ได้ให้ความสำคัญ
กลับกันคนที่เขียนโปรแกรมเก่งระดับหนึ่ง อาจจะได้เงินเดือนมากกว่าคนแรกสองเท่า เพราะเค้าทำงานในจุดที่ spotlight สาดแสง เลยทำให้มีความสำคัญ
คนที่สาม อาจจะเขียนโปรแกรมได้น้อยกว่าสองคนแรก แต่เค้าทำงานในบริษัทที่รายได้มากกว่าสองบริษัทแรก 50 เท่า เลยได้เงินเดือนมากกว่าคนแรก 10 เท่า
ทั้งหมดจึงขึ้นอยู่กับปัจจัยต่างๆ ซึ่งส่วนตัวผมเรียงลำดับความสำคัญดังนี้
- สถานะทางเศรษฐกิจของบริษัท
- ความสามารถในการแก้ปัญหาทางธุรกิจ(ไม่ใช่แค่แก้ปัญหาในการเขียนโปรแกรม)
- ความจำเป็นของงานต่อธุรกิจ
- มาตรฐานทางเงินเดือนของประเทศ
- ความเก่งในการ code ของคนคนนั้น
จะเห็นว่าในมุมมองส่วนตัวผม สิ่งที่สำคัญคือ คุณทำงานให้ใคร และคุณมีคุณค่าทางธุรกิจให้เขาไหม มากกว่าความสามารถในการเขียนโปรแกรมเพียวๆ
อย่าลืมว่าทุกบริษัทต้องการผลกำไร ไม่ใช่ product ที่โคตรเจ๋ง 100% code coverage แต่ไม่มีผลกำไรเลย

166 Nameless Fanboi Posted ID:9d3UIqdxmc

ถามเหตุการณ์สมมติกับเพื่อนโม่งหน่อยครับ

สมมติมี Startup ด้านการเงินสัญชาติยุโรปมาตั้งบริษัทในไทยแห่งหนึ่งเพื่อ develop software ให้บริษัทแม่แล้วไม่จ่ายเงินเดือนพนักงานมา 2 เดือน รวมถึงค้างค่าใช้จ่ายต่าง ๆ เช่น ประกันสังคม (ไม่ได้ส่งมาหลายเดือน), AWS, Jira, Bitbucket, ค่าเช่าออฟฟิศ ฯลฯ เพราะอ้างว่าเงินทุนก้อนใหญ่มากกำลังจะเข้ามา (ซึ่งไม่น่าจะจริง) แต่ติดปัญหาเรื่องการเดินเอกสาร และให้พนักงานทำงานฟรีมา 2 เดือนจนขึ้นเดือนนี้ถึงให้หยุดอยู่บ้านไปก่อน และในระหว่างนี้พนักงานหลายคนก็เดือดร้อนเรื่องเงินเพราะมีภาระต้องผ่อนหนี้ค่าบ้าน/คอนโด/รถ หรือส่งลูกเรียนแบบนี้

เพื่อนโม่งจะตัดสินใจยังไงครับ ลาออกและเงินเดือนที่ค้างอยู่จะเป็นไงก็ช่างมัน? เชื่อมั่นในบริษัทและทนรอเงิน? จะฟ้องกรมแรงงานมั้ย? หรือจะทำอะไรบ้างครับ?

ย้ำว่านี่เป็นเหตุการณ์สมมตินะครับ

167 Nameless Fanboi Posted ID:uq2L9xGw2Y

ไปอ่านบล็อกนึงใน Reddit ที่ Github บอกว่าเขาไม่ใช้ Foreign key constraint เพราะอะไร

มีคนอ่านบอกว่า ปัญหานี้มันเฉพาะตัวของ Github ไม่ใช่ปัญหาที่คนทั่วไปเจอ

ผมตอบว่า No one tasked to solve generic problem, ever. แล้วผมก็แชร์บล็อกนี้เลยใน Tech Articles Group

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

ผมอยากชวนคิดว่า เราอยากจะหา Generic solution หรือมักจะเรียกอีกชื่อหนึ่งว่า "Best practice" ที่ใช้ได้ในกรณีทั่วไปเพื่ออะไร

ถ้าระบบหรือที่ไหนเจอ Generic problem เขาก็ไปอ่าน Generic solution แล้วก็ทำตามนั้นก็จบ จะจ้างเรามาทำงานทำไม คนเขียนวิธีอย่างละเอียดในการแก้ไข Generic problem มีเยอะแยะไปหมด

ทุกคนทุกระบบ เจอ Specific problem ที่จำเป็นต้องใช้ Specific solution ในการแก้ไขทั้งนั้น ดังนั้น ในแง่นี้ การที่เรารู้จัก Generic solution หรือ AKA. Best practices ไม่ได้การันตีเลยว่ามันจะแก้ไขปัญหาของเราได้ ต้องบอกว่าส่วนมากจะไม่ได้ด้วยซ้ำไป

อ้าว แล้วถ้างั้นเราควรจะทิ้ง Best practice ไปมั้ย ไม่สนใจเลยเหรอ? เราจะเรียน Best practices ไปทำไม

เพราะเวลาพัฒนาระบบเนี่ย มันไม่มีใครรู้ว่า Solution คืออะไรไงล่ะ ถ้ามีคนรู้จริงๆ แล้วเนี่ย งานมันไม่มาถึงเราหรอก

ทีนี้พอมันไม่รู้ว่าวิธีแก้ปัญหาที่ถูกต้องเป๊ะๆ คืออะไร มันก็ต้องลองอะไรซักอย่างใช่มั้ย ไม่ใช่ปล่อยให้ปัญหาคงอยู่ ต่อให้สิ่งที่ลองแก้ปัญหาไม่ได้เป๊ะๆ บรรเทาได้ก็ยังดี

ทีนี้ประโยชน์ของ Best practices มันก็คือตรงนี้ คือคุณลอง Apply best practices ไปในตอนที่ยังหา Solution ที่เป๊ะๆ ไม่เจอ โอกาสที่มันจะใกล้เคียงกับ Solution มีเยอะกว่า Apply อะไรก็ไม่รู้มั่วซั่วเยอะ ดังนั้น เวลาไม่รู้อะไร ผมก็แนะนำ Best practices ก่อนเสมอ เป็น Bet ที่ดีกว่าลองมั่วซั่วแน่ๆ คุณควรจะรู้แล้วใช้มันเป็นฐานตั้งต้นเสมอ

แต่คุณจะไปสรุปว่ามันเป็นคำตอบถาวรของระบบไม่ได้ คุณยังต้องสังเกตและ Iterate ต่อจากตรงนั้นไปด้วย แล้วถ้าจะปรับเปลี่ยน ก็ต้องเปรียบเทียบว่าทางออกที่ไม่ได้ตรงกับ Best practice นั้นในบริบทของเรามันดีกว่าหรือแย่กว่า ก็ต้องค้นหากันต่อไปเรื่อยๆ ตราบที่ระบบยัง Evolve อยู่ยังต้องดูแลกันอยู่

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

จุดที่ยากที่สุดคืออะไร คือเราต้องเผชิญหน้ากับความจริงว่า ไม่มีใครรู้คำตอบของระบบเราทั้งนั้น ถ้ามีคนรู้ ทุกวันนี้มันจะมีปัญหาเหรอ?

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

ทุกวันนี้ ทุกคนอยากให้มีคนรู้คำตอบ แต่ไม่มีใครอยากผ่านขั้นตอนในการ "ค้นหาคำตอบ" ตัว Business อยากให้มีคนรู้คำตอบ Investor คาดหวังว่าจะมีคนรู้คำตอบ Junior คาดหวังว่าจะมีคนรู้คำตอบ Senior คาดหวังว่าคนอื่นจะรู้คำตอบ แต่ไม่มีใครอยากผ่านขั้นตอนการค้นหาคำตอบ

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

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

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

168 Nameless Fanboi Posted ID:uq2L9xGw2Y

>>166 ฟ้องกรมแรงงานก่อนได้เปรียบ

169 Nameless Fanboi Posted ID:3jb8hqnwz8

ผมเห็นด้วยที่ว่า Agile ไม่ได้แปลว่า เร็ว (ใน Absolute Term/Sense) ... ทุกอย่างมันขึ้นกับ Frame of Reference ว่าเราเอาอะไรไปเทียบกับมัน และมันเหมาะสมหรือไม่ มัน Overkill เกินไปหรือเปล่า ในทุกเรื่อง

ผมเห็นว่าทุกกระบวนการ มันมี Scale ที่เหมาะกับมันเอง สิ่งที่จะทำให้มันยากลำบากและช้าลง ไม่ใช่ที่ตัวกระบวนการ แต่เป็นการไม่เหมาะสมกันระหว่าง Process และ Scale ต่างหาก

นี่ยังไม่รวมถึงลักษณะงาน และเป้าหมายนะ ... เช่น ถ้าเป็นงานแบบ "ใช้แล้วทิ้ง" ใน Scale ที่เล็กพอที่จะ Cowboy-Developer ได้ตรงๆ แบบดุ่มๆ ไปเลย เดี๋ยวก็เสร็จ และการันตีได้ว่าไม่ต้องดูแลต่อ (ไม่ว่าจะโดยใครก็ตาม) การทำ Agile ก็ Overkill ไม่ต่างอะไรกับการใช้ Process อื่น ...

แต่กับอีกหลายงานมันก็ไม่ใช่แบบนั้น

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

ประเด็นมันไม่ใช่ Agile เร็วหรือไม่เร็ว เพราะตัวมันเองไม่ใช่ความเร็ว เพียงแต่ว่าเมื่อนำมันไปใช้กับ "งานบาง Scale" แล้วมัน "เร็วกว่า Waterfall-based ในระยะสั้นและระยะกลาง" และ "เร็วกว่า Cowboy-Develop ในระยะกลางและระยะยาว"

ซึ่งพอเรา "เคยชิน​" กับ Frame of Reference บางอย่าง (พูดอีกอย่าง คือเรามี Implicit Frame of Reference) เราอาจจะรู้สึกว่ามัน "เร็วขึ้น"​ เสมอ แต่ถ้าเราเคยชินกับอีก Frame หนึ่ง เราอาจจะรู้สึกว่ามัน "ช้าลง" เสมอ เช่นกัน

การนำ Process ไปใช้ ถ้าเรารู้สึกว่ามันเร็วขึ้น แปลว่า Scale ของงานที่เราทำ และ Process มันมี matching ที่ดีกว่า แต่ในขณะเดียวกันถ้ามันช้าลง แปลว่า matching มันไม่ดี

ประเด็นสำคัญคือ ... ทีมงานหลายทีม ใช้ Process ผิด Scale .... ส่วนหนึ่งก็เพราะว่าตอนเรียน เรียน Process for Enterprise มา .. แต่ตอนทำโปรเจ็คจบ หรืองาน Freelance แรกๆ ดันทำแบบ Cowboy ....

ต้องยอมรับกันนะ ว่างานบ้านเราที่ต้องใช้ Scale ระดับ Enterprise มันไม่ได้มีเยอะขนาดนั้น แต่งานส่วนมากมันเกิด Scale ของ Cowboy Coding ไปเยอะอยู่

Agile จึงเป็นทางออกที่ดี และผมเห็นว่ามันเป็น Bootstrapping Platform ที่ดี สำหรับการ Rescale Enterprise ให้เป็น Smaller Units ในการทำงานต่างๆ

แต่ที่แน่ๆ คือ เราต้องแยกแยะให้ออกระหว่างตัวปรัชญา (Philosophy) ของแต่ละอย่าง กับ "Implementation" ของมันทั้งหลาย ไม่ว่าจะเป็นการ Implement แบบไหนก็ตาม

หลายอย่าง Philosophy ดีมาก เช่นพวก CMMi แต่ตัวปรัชญามันเอาไปทำอะไรไม่ได้ มันก็ต้องมี Implementation ... ซึ่งแน่นอนว่า Implementation ทุกตัวมันจะเหมาะกับบางรูปแบบ (เช่น บางตัวเน้นการใช้เอกสาร) ... แต่ถ้าเราถอดเปลือกของ Implementation กลับไปมองที่ประเด็นของปรัชญาของมัน เราอาจจะสร้าง Process ใหม่ๆ ได้โดยไม่อิงกับ Implementation บางแบบที่ไม่เหมาะสม ได้ทั้งนั้น

ก็เช่นเดียวกันกับ Agile .... ณ วันที่ผมลงชื่อใน Manifesto เมื่อประมาณ 15 ปีก่อน ....​ ณ วันนั้นมันยังไม่มี Agile Methodology หรือ Agile Process มากมายดังเช่นทุกวันนี้ ยังไม่มี Scrum ไม่มี Kanban ไม่มีอะไรทั้งนั้น ... พวกนี้เกิดจากการเอาปรัชญาไปใช้สร้าง Process ของตัวเอง จนมันเวิร์กขึ้นมา และทำจนเชี่ยวชาญ จนมันเร็ว

บางที กลับไปหาปรัชญามันซะบ้าง แล้วก็คิดบ้าง ว่ามันไม่มี one size fit all ... และทุกอย่างมันไม่มี absolute term

ผมจะลบโพสท์นี้ในอีก 1 ชั่วโมง

170 Nameless Fanboi Posted ID:e+6VmtQKo9

>>169 ในนี้มันลบไม่ได้ไอสัส

171 Nameless Fanboi Posted ID:STBXBlb+JA

>>166 หางานใหม่เหอะ เป็นกุเดือนเดียวก็ไม่อยู่แล้ว ดูทรง เจ้าของลอยแพ แน่นอน อยากได้ไปฟ้องเอา

172 Nameless Fanboi Posted ID:hBLAW2aEjn

Gartner ทำนายเอาไว้ในปี 2017 ว่าภายในปี 2019 จะมีแบรนด์ราว 20% ถอดใจกับ mobile app ของตัวเอง

ไม่รู้ว่าตอนนี้ตัวเลขมันไปถึงไหนแล้ว แต่ส่วนตัวคิดว่าการทำ mobile app มันจะถูกลดความนิยมในอีกไม่นาน และถูกแทนที่ด้วย web technology มาตรฐานใหม่ ๆ ที่สามารถทำงานได้ในทุก ๆ อุปกรณ์มากกว่า

มีงานวิจัยจาก Forrester ที่ให้บทสรุปออกมาแม้ว่าคนส่วนใหญ่จะใช้เวลาในแต่ละวันเกือบ 85% หมดไปกับมือถือ แต่ก็มีแค่ราว ๆ 5 apps เท่านั้นแหละที่ถูกเรียกใช้งานถี่ที่สุด

ผมมานั่งนับดูของตัวเอง.. เออ จริง ๆ ก็ใช้หลัก ๆ แค่นี้แหละ facebook, line, gmail, youtube และที่ขาดไม่ได้คือ chrome

คุณมีกี่ app ในมือถือของคุณ?
คุณใช้วันละกี่ app?
app ละกี่ครั้งต่อวัน?

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

แต่ผมก็ไม่ได้หมายความไม่ควรมีใครทำ app เลย.. ไม่ใช่นะ.. app ยังมีความจำเป็นในบางสินค้า/บริการ ทั้งนี้ทั้งนั้นต้องดูว่าแต่ละองค์กรมีแผนการใช้งาน mobile app อย่างไรมากกว่า

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

ถ้าธุรกิจของคุณกำลังสนใจอยากจะทำ mobile app ไว้ใช้สักอัน.. ลองพิจารณาดูให้ถี่ถ้วนก่อนนะครับว่า.. ไหวหรอ? 😅

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

REF:
- https://www.gartner.com/en/marketing/insights/articles/gartner-predicts-2017-marketers-expect-the-unexpected

- https://techcrunch.com/2015/06/22/consumers-spend-85-of-time-on-smartphones-in-apps-but-only-5-apps-see-heavy-use/

173 Nameless Fanboi Posted ID:WYMdlczbsy

คอมติดไวรัส .zobm ทำไงถึงกู้ไฟล์ได้คับ

174 Nameless Fanboi Posted ID:wZhk2CE1aB

หนึ่งใน "หนังสือที่ผมอยากให้โปรแกรมเมอร์ทุกคนอ่าน" ....

The Elements of Programming Style โดย Brian Kernighan และ P.J. Plauger

หนังสือตั้งแต่ปี 1974 (2nd edition ปี 1978) ที่ยังคงคลาสสิคและ "core content", "messages", "philosophy", "wisdom" มันยังคง relevant ในปัจจุบัน

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

ไม่ว่าจะเป็นเรื่องพวก test-driven, unit-testing, readable code, clean & clear code, SOLID, etc ..... โดยเ​ฉพาะอย่างยิ่งเรื่องอย่าบ้ากับเรื่อง performance มากนักในกรณีทั่วไป ..... (ถ้าต้องบ้าขนาดนั้น ส่วนมากต้องมาดู algorithm ของตัวเองใหม่แล้วล่ะ -- ซึ่งในเล่มนี้เขียนว่า "Don't diddle code to make it faster. Find better algorithm") .... หรือต้อง measure/profile ก่อน optimize ... อย่าเชื่อความคิดตัวเองเรื่อง performance มากกว่าตัวเลขจริง​ (และ algorithm complexity) ฯลฯ

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

ผมยังคงต้องบอกโปรแกรมเมอร์สมัยใหม่เรื่องแบบนี้อยู่ (และหลายคนก็ยังคงดื้ออยู่ คิดว่าที่ตัวเองทำมันดีแล้ว -- พวกนี้ก็ต้องปล่อยไป)

พูดง่ายๆ คือมันเป็น Timeless Wisdom

ผมแปะ snapshot จากหนังสือเล่มนี้ให้อ่านครับ เป็นตัวอย่าง ว่าทำไมมันน่าอ่าน

175 Nameless Fanboi Posted ID:Vop6Qp206C

>>172 แอพ พวกที่รอดต้องแบบที่รวดเร็ว ไม่เหมาะกับใช้บนบราวเซอร์ ใช้บนเว็บยิ่งไม่สะดวก แป๊บๆคือเข้าใช้งานได้เลย หรือไม่ก็ต้องออกแนวที่เชื่อมต่อกับอุปกรณ์บนมือถือ , IoT ต่างๆ

176 Nameless Fanboi Posted ID:S1YqZW4nc+

หนังสืออีกเล่ม ที่อยากให้โปรแกรมทุกคนอ่าน ..... ด้วยเหตุผลเดียวกับเล่มเมื่อวาน คือ Timeless Wisdom .....

"The Art of UNIX Programming" ..... โดย Eric S. Raymond (ESR)

ชื่อหนังสืออาจจะทำให้คนคิดว่าเป็นการสอนเขียนโปรแกรมบน UNIX หรือหัดใช้ UNIX API (System Calls) อะไรพวกนี้ .... แต่จริงๆ มันคนละเรื่องเลย .... Very far from that ด้วยซ้ำ

มันคือปรัชญาและ Wisdom เบื้องหลังการสร้าง UNIX (และโปรแกรมใน UNIX Ecosystem) ที่ผมถือว่าเป็น very-well-designed และ stood the test of time มากๆ .... จนกระทั่งปัจจุบัน

ทุกอย่างในนี้ยังคง relevant ..... ทุกวันนี้เราก็ยังคงต้องสอนเรื่องแบบนี้กันอยู่

ลองอ่านตัวอย่างบางหน้าดูได้ครับ

ป.ล. ... ผมอยากจะจัดคลาส based on เล่มนี้ และ The Elements of Programming Style มากๆ เลยนะ :D

177 Nameless Fanboi Posted ID:UDieycegAL

ผมคิดว่าเวลาเราจะใช้อะไรควรดูให้รอบด้านครับ ความเร็วเป็นแค่มิติหนึ่งที่ใช้ประกอบการตัดสินใจ ร่วมกับว่า

1. ใช้ง่ายไหม
2. เครื่องมือที่ใช้ถนัดไหม
3. Library ที่ต้องใช้มีครบไหม
4. เขียนไปแล้วเพื่อนอ่านออกไหม (4.1 เขียนไปแล้วตัวเองกลับมาอ่านออกไหม)
5. เทสง่ายไหม -- ถ้าสนใจจะเทส
6. ดีพลอยง่ายไหม

ยกตัวอย่าง คือ ผมไม่ชอบ syntax ภาษา go เอาซะมากๆ เลย แต่ถ้าต้องเขียน command line tool ผมก็เลือกใช้ go เพราะมันเป็น binary ไฟล์เดียว คอมไพล์เสร็จโยนไปใช้ได้เลย ไม่ว่าภาษาไหนจะมีรันไทม์ลงง่ายแค่ไหนก็สู้ go 1 binary ไม่ได้ กรณีนี้ไม่ได้ขึ้นกับว่าภาษานี้เร็วแค่ไหนเลย เพราะไม่สำคัญ

ทั้งนี้ พึงระลึกถึงคำสอนปราชญ์โบราณ ท่านกล่าวไว้ว่า Only a sith deals in absolute ครับ

178 Nameless Fanboi Posted ID:gnQrcYIBbR

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

คนที่เห็นประโยชน์เราตอนเราดีก็มีเต็มไปหมด
ตอนเราร้ายก็ด่าเราลับหลัง
ความโกหกตอแหลมันโผล่ออกมาชัดเจน

สิ่งที่อยากได้จาก Community คือความจริงใจเป็นอันดับแรก
มันเป็นวิธีการกรองคนที่ได้ผลดีอย่างที่ตั้งใจไว้

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

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

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

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

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

ผมเจ็บแทนคนใน Community มาเยอะกว่าที่หลายคนรู้ ไม่แฉก็ดีแล้วครับ แต่ละคนแสบๆทั้งนั้น

ก็อยากจะ Filter ให้เหลือน้อยๆ เหลือแต่คนที่ลำบากไปด้วยกันลุยไปด้วย

Set to Zero ถ้าไม่ทิ้งบางอย่าง เราก็ยากจะก้าวผ่าน ใครจะดราม่าก็ดราม่าไปนะครับ มีไรทำเยอะ

เอาเวลาไปทำงานสร้าง Value ให้ Community ที่คุณคิดว่าดี ดีกว่าครับ

ทำไมฝั่ง business เขาชอบมาคุยกับผมมากกว่าคุยกับ Dev และ Community ก็ลองคิดเองว่ามันยังมีปัญหาอะไรอยู่ ทำไมอีกหลายๆที่เขาไม่อยากสนับสนุน

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

179 Nameless Fanboi Posted ID:gnQrcYIBbR

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