ตีความ “หนัง” สะท้อนชีวิตจริง

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

ว่ากันเป็นเรื่องๆ ไป

  1. “Brazil” เรื่อง Management by number (รวมถึงการตัดสินใจ), KPI & QA, ข้อมูลและความเป็นจริง
  2. “Fight Club” เรื่องการเป็น Entrepreneur การตั้ง startups การเป็นตัวของตัวเอง
  3. “Pirates of Caribbean” โดยเฉพาะการตีความเรือ “Flying Dutchman” กับองค์กรที่ไร้เป้าหมาย
  4. “Inception” ความเป็นจริง สุดท้ายแล้วคือสิ่งที่เราเลือกจะคิดว่าจริง

ถ้ามีเวลาทำนะ …. จริงๆ อยากจะเขียนมันรวมเล่มเป็นหนังสือสักเล่มไปเลย ให้มันละเอียดกว่าบน blog แต่ว่าหาเวลาเขียน blog และเขียนหนังสือ iOS development ที่กำลังเขียนอยู่ให้เสร็จก่อน

การทำ Proof-of-Concept กับการพัฒนาโปรแกรม

มีเรื่องนึงที่อยากจะฝากบอกน้องๆ ทั้งนักศึกษาและคนที่กำลังหัดเขียนโปรแกรมใหม่ๆ ที่จะต้องพัฒนาโปรแกรม ไม่ว่าจะใช้เอง เป็นโปรเจค ทำขาย หรือว่าอะไรก็แล้วแต่ ก็คือเรื่องของการทำ Prototyping และ PoC (Proof-of-Concept)

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

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

ลองแบ่ง phase การทำงานเป็นแบบนี้ครับ

  1. นั่งคิดคร่าวๆ ว่าโปรแกรมจะมีการใช้งานอย่างไร ต้องทำอะไรได้บ้าง ไม่ต้องมากไม่ต้องมาย
  2. จากนั้นนั่ง list มันออกมาเล่นๆ ว่าจะทำแบบนั้นได้นี่ ภายในโปรแกรมจะต้องมีความสามารถอะไรบ้าง (ไม่ใช่ความสามารถที่ผู้ใช้งานจะได้ใช้นะ หมายถึงว่าต้องเขียนให้มันทำอะไรได้บ้าง)
  3. ดูว่าอะไรที่เราทำเป็นแล้ว อะไรที่ยังทำไม่เป็น checklist ง่ายๆ
  4. เปิดโปรเจคใหม่หลายๆ โปรเจค ตามเรื่องที่เรายังทำไม่เป็น หัดเล่นเป็นเรื่องๆ ไป เล่นโน่นเล่นนี่ เล่นให้มันพังไปเลยก็ได้ ไม่เป็นไร เพราะว่านี่คือการลองเล่นกับโปรเจคที่ไม่เกี่ยวกับงานเราสักนิด จะเขียนโค้ดให้มันเละแค่ไหนก็ได้ อีกสามสี่วันอ่านไม่รู้เรื่องก็ได้ ไม่ต้องมีโครงสร้างอะไรมากมาย ลุยมันไปเลยไม่ต้องคิดมาก
  5. แต่ว่าเป้าหมายของโปรเจคเล็กๆ ที่เปิดใหม่เหล่านั้นต้องชัดเจนนะ ว่าจะเรียนรู้เรื่องอะไร กำหนดเวลาให้ตัวเองไว้ด้วย กำหนดผลลัพธ์ที่ชัดเจนไว้ด้วย
  6. เมื่อ checklist เต็มแล้ว (คือ ทุกตัวทำเป็นหมดแล้ว) ค่อยมาวาง architect ของโปรแกรม/โปรเจคที่อยากได้ ว่าจะออกมายังไง เพราะว่าตอนนี้เราน่าจะมีประสบการณ์แล้วว่าอะไรมันทำได้ทำไม่ได้ อะไรมันต้องทำงานร่วมกับอะไรยังไง รับค่าอะไร รีเทิร์นอะไร ประสิทธิภาพเป็นยังไง ฯลฯ

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

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

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