PROMPT>> init 6

Category: Software

  • 3 ข้อที่จะทำให้คุณเป็นนักพัฒนาที่ใครก็อยากได้ไปทำงานด้วย

    gotw

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

    เลยมีโอกาสได้นั่งคิดตอนอยู่บนเครื่องบินหลังจากกลับจากงาน อไจล์สิงคโปร์ ความยากคือเค้าไม่ต้องการนักพัฒนาธรรมดาแต่ต้องการนักพัฒนาที่ยอดเยี่ยม

    นอกเหนือจากคุณลักษณะพื้นฐานที่นักพัฒนาทุกคนควรมี โดยน้อง Weerasak

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

    1. ทำงานเป็นทีมได้ ฟังดูเหมือนง่าย แต่การทำงานเป็นทีม คือการยอมรับข้อแตกต่างของทีมให้ได้ และยอมที่สละจุดยืนของตัวเองบ้างเพื่อให้เพื่อนๆได้มีโอกาสนำเสนอผลงานที่ทกคนสามารถยอมรับได้ ในโลกทุกวันนี้หมดยุคของโคดที่ดีที่สุดเพราะเหตุว่า ความเร็วของฮาร์ดแวร์ที่ทำให้โคดที่เร็วและเจ๋งที่สุด ไม่ได้เร็วไปกว่าโคดที่ทุกคนในทีมยอมรับได้ และทำงานต่อเนื่องกันอย่างคล่องแคล่ว

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

     

    • ภาษาที่ต้อง Compile ให้ความเร็วสูง และสามารถสเกลได้ง่าย เช่น C/C++, C#, Java  ภาษาเหล่านี้จะทำคุณขยายขอบเขตความสามารถของ Application แบบก้าวกระโดดได้
    • ภาษาไดนามิค/ฟังชัน หรือ Scripting เช่น  PHP, Pearl, Python, Ruby ภาษาเหล่านี้เป็นภาษาที่เขียนได้เร็ว ใช้งานได้ง่าย และทำการทดลองไอเดียได้แบบกระดิกนิ้ว และภาษาเหล่านี้แหล่ะทีจะตอบสนอนตัณหาของ business เวลาที่เค้าอยากเป็นอะไรแบบไวๆ
    • ภาษา SQL หรือ ภาษาที่ใช้ในการทำงานบนฐานข้อมูล หลายคนอาจมองว่าแค่ Query ธรรมดาใครๆก็น่าจะทำได้ แต่ในความเป็นจริงแล้วการใช้ภาษาบนฐานข้อมูลต้องมีความสามารถในเรื่องการ Tuning Query ให้ทำงานได้เร็วและ ดูแลได้ง่ายอีกด้วย
    • ภาษา ที่ใช้ในการคิด Artificial Intelligence หรือภาษาที่เราใช้ในการเขียนอัลกอริทึ่มในการหาทางเดินของตัวละครในเกม หรือ การควานหาลักษณะเหมือนของสินค้าเพื่อแนะนำสินค้าที่เกี่ยวข้อง ภาษานี้ส่วนใหญ่เรียนแล้วโยนทิ้งเพราะว่าพอทำงานจริงไม่ค่อยได้ใช้ แต่หากเราจะเป็นนักพัฒนาที่ยอดเยี่ยม ภาษาเหล่านี้จะประหยัดเวลาเรามากเวลาที่ใช้ในการพิสูจน์ ภาษาเหล่านี้เช่น Lips, Prolog
    • ภาษาเวป เช่น  HTML, JavaScript, ASP  เป็นต้น (อันนี้คงไม่ต้องยกตัวอย่างเพราะว่าชัดมาก)

    3. นักพัฒนาที่ดีต้องโยนตัวเองให้ไปมองภาพรวมได้ว่าเราทำไปแล้วลูกค้าได้ประโยชน์อะไร หรือ เป็นคนที่ตะเกียกตะกายหาเหตุผลว่าทำไมทีมเราต้องทำมันด้วย

     

  • วิธีสร้างผลิตภัณฑ์ที่ใครๆก็อยากใช้ และบอกต่อ

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

    หนี่งในหัวข้อที่มีโอกาสได้รับเกียรติให้ไปแบ่งปันในงาน Thailand Practical Software Engineering ที่จะจัดขึ้นในวันที่ 2ๅ-22 พฤศจิกายน 2556 (ลงทะเบียนฟรี)

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

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

    รับรองหัวข้อนี้สนุกแน่!

  • การสร้างสถาปัตยกรรมบนพื้นฐานของความไม่แน่นอน

    สิ่งที่เรียนรู้จากงาน อไจล์สิงคโปร์ จาก Architecture of Uncertainty, Kevlin Henney พอจับใจความได้คร่าวๆคือ

    1. เริ่มออกแบบจากสิ่งที่ยากที่สุด หลายต่อหลายครั้งเรามักไปทำส่วนที่ง่ายที่สุด แล้วค่อยย้อนไปมองส่วนที่ยากที่สุด แต่ในมมของ Kevlin คือ ต้องสร้างสถาปัตย์เหมือนกับการสร้างบ้าน คือคิดในส่วนที่เป็นรากฐานของบ้านให้ดี แล้วค่อยไปโครงสร้างชั้นถัดไป
    2. ทุกคนที่มีส่วน ไม่ว่าจะเป็นคนสร้างโคด หรือ แม้แต่คนที่มีอิทธิพลต่อโครงสร้างไม่ว่าทางใด ทางหนึ่่งเป็นนักสถาปัตยกรรมหมด ตำแหน่งหรือว่าคนเป็นแค่ตัวแทนของคนที่รวบรวมเพื่อให้ทุกคนเห็นภาพเดียวกัน
    3. การสร้างสถาปัตยกรรมเหมือนกับปรากฏการณ์ทางวิทยาศาสตร์ที่เรียกว่า Big bang ตอนเริ่มต้น เริ่มจากเล็กๆมากแต่พอขยายมันกลายโลกอย่างที่เราเห็นทุกวันนี้ เช่นเดียวกับการเขียนโคด วันแรกเราอาจไม่ได้คิดอะไร แต่เราอาจกำลังสร้างกับดักให้กับตัวเองในอีกสิบปีถัดไป
    4. การทำสถาปัตยกรรมแบบที่เรารู้จักกันดี คือ วิเคราะห์ ออกแบบ เขียนโคด และ ทดสอบ ใช้ไม่ได้กับซอฟ์ตแวร์ (แต่อาจใช้ได้กับกลุ่มงานกลุ่มอื่นได้) และมีหลายคนมักโต้แย้งว่า ถ้าหากว่าเรา สามารถที่จะทำให้ทุกอย่างนิ่งได้ เราน่าจะใช้วิธีการดังกล่าวได้ แต่คนสอนบอกว่า ถึงแม้ว่าเราจะทำให้ทุกอย่างนิ่งได้ แต่ยังมีอีกหนึ่งปัจจัย คือตัวเราเอง นั้นไม่นิ่ง สิ่งที่เราเคยคิด ณ จุดหนึ่ง มักเปลี่ยนแปลงไปตามระยะเวลา
    5. ความเชียวชาญของนักสถาปัตยกรรมไม่ใช้ในระดับองค์ความรู้แต่หากเป็น ระดับในการเรียนรู้ที่แตกต่างกัน เช่น หนังเรื่องเดิม หากเราดูซ้ำๆหลายๆรอบ แต่ละรอบเราจะได้ความรู้ หรือข้อมูลที่แตกต่างกัน ฉะนั้นคนที่เป็น ในระดับผู้เชียวชาญ จะตั้งคำถามที่แตกต่างจาก ระดับเริ่มต้นเสมอ
    6. การออกแบบสถาปัตยกรรมที่ดีไม่ใช่การทำให้สมบูรณ์แบบ แต่หากเป็นการออกแบบให้เราสามารถเปลี่ยนแปลงสถาปัตยกรรมของเราให้ง่ายที่สุดด้วย
    7. สถาปัตยกรรมที่ดีต้องสร้างโคด แล้วทดสอบได้ทันที ไม่ใช่รอ หรือว่าทำใน power point/ key note
    8. ไม่มีสถาปัตยกรรมที่ สามารถรองรับได้ทุกสิ่ง General Purpose Architecture never exist!

    อยากรู้เพิ่มเติมดูเพิ่มได้ที่ 97 things every architect should know

    architect