ดูเหมือนว่าประเด็นถกเถียงจะร้อนแรงพอสมควรจน Anders Hejlsberg เข้ามาคอมเมนต์ด้วยตัวเองเลย

https://github.com/microsoft/typescript-go/…

ใช่ครับ อันนั้นแหละ!

คนหนึ่งที่อยากให้คอมไพล์ด้วย TypeScript แล้วได้ผลลัพธ์ออกมาเป็นไบนารีได้ทันที

ขอบคุณสำหรับการแนะนำข้อมูลดี ๆ ครับ

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

ความรู้สึกคล้ายกับประสบการณ์ของผมเลยครับ

• เวลาต้องเขียนโค้ดที่เรียบง่ายแต่จำได้ยาก (เช่น การจัดการไฟล์อินพุต/เอาต์พุต, การจัดการคอนเทนเนอร์ เป็นต้น)
• ตอนที่เกิดข้อผิดพลาดตอนคอมไพล์หรือรันไทม์ แล้วอยากรู้ว่านี่คือ error อะไรและโค้ดส่วนไหนเป็นสาเหตุ
• เวลาที่อยากเขียนฟังก์ชันใหม่โดยอิงจากฟังก์ชันที่เขียนไว้แล้วและคล้ายกัน แต่เพิ่มความสามารถที่ต่างออกไปเล็กน้อย
• เวลาที่อยากเปลี่ยนโค้ดที่พึ่งพาไลบรารีหนึ่งไปใช้อีกไลบรารีหนึ่ง หรือแทนที่ด้วยฟังก์ชันที่เขียนเอง
• เวลาที่ต้องการไกด์ว่าควรพัฒนาอย่างไรเพื่อสร้างฟีเจอร์บางอย่าง หรือทำงานในสภาพแวดล้อมเฉพาะ

ในเคสแบบข้างต้นช่วยประหยัดเวลาไปได้มากทีเดียวครับ หลายครั้งก็หาไม่ค่อยเจอด้วยชุด Google+Stack Overflow และโดยเฉพาะใน Stack Overflow พอมีคำตอบหนึ่งมา ก็มักจะมีคอมเมนต์โต้แย้งตามมาเยอะเสมอ แถมบางทีก็เป็นวิธี implement ของเวอร์ชันเก่าที่ไม่ควรใช้แล้ว อะไรทำนองนั้น เลยมีหลายครั้งที่น่าหงุดหงิดมาก...

ถ้าแบ่งเป็นช่วงละ 1-2 สัปดาห์ ดูเหมือนว่าโดยธรรมชาติแล้วจะมีเพียงคนจำนวนจำกัดเท่านั้นที่เข้าใจภาพของฟีเจอร์หนึ่ง ๆ ได้ อย่างความแตกต่างระหว่าง process กับ thread นั่นแหละครับ เพราะเป็นการจำกัดขอบเขตความสนใจเพื่อเพิ่มผลิตภาพ

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

ไม่ใช่ว่าควรแชร์ภาพรวมใหญ่ ให้ทุกคนเข้าใจตรงกัน แล้วค่อยแบ่งงานออกเป็นทาสก์เล็ก ๆ เหรอครับ??

ขอบคุณสำหรับบทความดีๆ

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

โมเมนตัมของวิศวกรได้รับอิทธิพลอย่างมากจากการที่ผู้นำกำลังชูธงไปในทิศทางไหนเช่นกัน ยังดูเหมือนว่าควรคิดให้มากขึ้นอีกหน่อยถึงวิธีสื่อสารว่าอยากส่งมอบคุณค่าอะไรให้ลูกค้า และ output กับ delivery outcome ของแต่ละสปรินต์คืออะไร แน่นอนว่านี่เป็น soft skill ที่ยาก จึงหาได้ยากทั้งผู้นำที่ทำได้ดีจริง ๆ และบทความที่เขียนเรื่องนี้ดี ๆ เช่นกัน

ผมไม่ค่อยรู้เรื่องฝั่งฟรอนต์เอนด์เท่าไร.. มันต่างจาก swc ไหม?

ตอนนี้เวลา 8:40 น. ตอนเช้า แต่พอเผลอไปดู มันดันเป็น 7:40:28 PM EST พอดีเลย... น่าทึ่งจัง

การไป McDonald's น่าจะเป็นเรื่องง่าย น่าจะเป็นประสบการณ์ที่สนุก

เข้าใจฝั่ง .NET นะ แต่รู้สึกว่า Rust น่าจะอยู่ตำแหน่งเดียวกับ Go มากกว่า ไม่ว่าอย่างไรก็ตาม ดูเหมือนว่าโปรเจกต์และไลบรารีฝั่ง JS ที่มีอยู่เดิมซึ่งทำด้วย Go ก็น่าจะมีอิทธิพลต่อการตัดสินใจเหมือนกัน

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

ดูเหมือนว่าคุณกำลังหมายถึงรันไทม์อย่างเช่น Node แต่สิ่งที่พูดถึงกันที่นี่คือตัวคอมไพเลอร์ของภาษา TS เอง

> หากโค้ด TypeScript ไม่ได้เขียนด้วย TypeScript อีกต่อไป ทีมก็อาจเลิกใช้ TypeScript โดยตรง ซึ่งในระยะยาวอาจส่งผลต่อประสบการณ์ในการพัฒนา

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

แต่เวลาจะนำเทคโนโลยีใหม่ล่าสุด(?) มาใช้ JUnit4 ก็มักจะกลายเป็นตัวถ่วงอยู่บ่อย ๆ เลยส่วนตัวก็มีความหวังเล็ก ๆ ว่าอยากให้ย้ายไป JUnit5 กันได้แล้ว
https://docs.gradle.com/develocity/test-distribution/

ถ้าใช้ junit-vintage-engine ก็พอจะรันเทสต์ junit4 บน junit5 ได้โดยแทบไม่ต้องแก้อะไรมาก แต่โอเวอร์เฮดค่อนข้างสูงทีเดียว (ช้าลงราว ๆ 20%)

ในฐานะคนที่ลงเอยมาเป็นวิศวกร build ของแอป Android แบบไม่รู้ตัว ขอลองฝากความเห็นไว้หน่อย..

> ระบบ build : gradle

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

• https://docs.gradle.org/current/userguide/configuration_cache.html
• https://docs.gradle.org/current/userguide/isolated_projects.html

> โครงสร้างโมดูล : แยกตาม feature

ส่วนตัวผมมองว่าไม่มีเหตุผลจำเป็นที่จะต้องเปิดเผย architectural layer ออกมาที่ระบบ build
ในกรณีของแอปที่ผมดูแลอยู่ ผมทำให้ build system มองเห็นโมดูลเป็น feature-api / feature-impl

• feature-app :
  • data model หรือ interface ที่เชื่อมกับโมดูลอื่น
• feature-impl:
  • implementation จริงของ feature

ถ้าจัดแบบนี้ การเปลี่ยนโค้ดใน feature-impl จะไม่ส่งผลต่อโมดูลอื่นที่อ้างอิง feature-api (แยก dependency ออกจากกัน) จึงช่วยได้มากทั้งกับ incremental build และการเพิ่ม build cache hit rate

> unit test - junit 4

เรื่องนี้ดูเหมือนว่าการตัดสินใจของ Google จะมีบทบาทค่อนข้างมาก

• https://issuetracker.google.com/issues/127100532
• สำหรับ Android Platform นั้น JUnit3 (ที่ดูเหมือน JUnit4) และ framework ทดสอบของเครื่องมือ build Android ทำงานบนพื้นฐาน JUnit4 โดย Google ระบุชัดว่าไม่มีแผนจะย้ายไป JUnit5
  แต่ screenshot testing plugin ที่เพิ่งเปิดตัวล่าสุด กลับ อิงกับ JUnit5 ครับ.

น่าจะเป็น Clubhouse นะครับ ผมเองก็นึกถึงอันนั้นขึ้นมาพอดีเหมือนกัน