นักพัฒนาโปรแกรมยอมรับปรัชญา "โค้ดโง่ๆ" เพื่อเอาชนะอาการเป็นอัมพาตในการเขียนโปรแกรม

ทีมชุมชน BigGo
นักพัฒนาโปรแกรมยอมรับปรัชญา "โค้ดโง่ๆ" เพื่อเอาชนะอาการเป็นอัมพาตในการเขียนโปรแกรม

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

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

การฝ่าฟันอาการเป็นอัมพาตจากการวิเคราะห์มากเกินไป

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

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

การเปรียบเทียบแนวทางการเรียนรู้การเขียนโปรแกรม

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

การเรียนรู้ผ่านปริมาณมากกว่าคุณภาพ

การอภิปรายนี้เปรียบเทียบกับการทดลองถ่ายภาพที่มีชื่อเสียง ซึ่งนักเรียนถูกแบ่งออกเป็นสองกลุ่ม - กลุ่มหนึ่งให้คะแนนตามปริมาณภาพที่ถ่าย และอีกกลุ่มหนึ่งตามคุณภาพของภาพเดียว น่าแปลกที่กลุ่มปริมาณผลิตผลงานที่ดีกว่า เพราะพวกเขาใช้เวลาทดลองโดยไม่มีแรงกดดัน

กลุ่มนี้ไม่เคยกังวลเกี่ยวกับคุณภาพของงาน ดังนั้นพวกเขาจึงใช้เวลาทดลองกับแสง องค์ประกอบ และอื่นๆ

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

ความสมดุลในระดับมืออาชีพ

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

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

เทคโนโลยีที่กล่าวถึงสำหรับการทดลอง

  • JavaScript/TypeScript
  • Node.js runtime
  • Deno runtime และการคอมไพล์ไบนารี
  • Streams API
  • VB.NET (บริบทการเรียนรู้ในอดีต)
  • เฟรมเวิร์กการพัฒนาเกมต่าง ๆ

การประยุกต์ใช้ในยุคปัจจุบัน

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

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

อ้างอิง: Go Ahead - Write the stupid code