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

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

ยังมีอีกหลายปัจจัย เล่าเป็นวันๆ ก็ไม่จบ แต่ละคนก็เจอแต่ละเหตุการณ์แตกต่างกันไป แต่สิ่งหนึ่งที่เป็นส่วนที่สำคัญในการทำงานเป็นทีมที่แต่ละคนมองข้ามไป หรือไม่ทันสังเกต และเป็นสาเหตุให้เราไม่สามารถทำงานร่วมกันเป็นทีมได้ ก็คือ กระบวนการในการทำงานและเครื่องมือช่วยในการทำงานเป็นทีม (Working Process & Development Tools)

โปรดฟังอีกครั้งหนึ่งว่า “เราขาดกระบวนการในการทำงานเป็นทีม และ เครื่องมือที่จะมาช่วยในการทำงานเป็นทีม” (Working Process & Development Tools) และให้สังเกตว่าผมไม่ได้พูดถึง ทักษะการเขียนโปรแกรมเป็นทีม (Programming Skill) เลยนะ เป็นเพราะอะไรนะหรือ ค่อยดูตอนท้ายๆ ครับ ตอนนี้เรามาดูที่ละหัวข้อที่สำคัญกันก่อนว่า แต่ละหัวข้อมันคืออะไร ทำไมมันถึงสำคัญ

1.เครื่องมือในการพัฒนาเป็นทีม
เครื่องมือที่ว่านี้อาจจะแยกออกเป็นประเภทต่างๆดังนี้

1.1.เครื่องมือช่วยในการเขียนโปรแกรม (Editor / IDE)
เราลองสำรวจดูว่า ตอนนี้เราใช้โปรแกรมอะไรในการช่วยเขียนโปรแกรม เช่น Nodepage ++, Edit Plus, Dreamwever, Eclipse, NetBean, Sublime, Aptana, VIM หรืออื่นๆ

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

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

1.2.เครื่องมือการคอมไฟล์ไฟล์ต่างๆ หรือรวมไฟล์ต่างๆ เข้าด้วยกัน (Build Automation)
เครื่องมือนี้บางคนอาจจะมองข้าม หรือไม่เคยใช้เลยก็ได้ถ้าไม่ได้เขียนโปรแกรมเป็นทีมมาก่อน หรือใช้ CMS ในการพัฒนาเว็บไซด์

การใช้ Build Automation เข้ามาช่วยนี้ จะเอาไว้สำหรับการทำงานที่ซ้ำไปซ้ำมา หรืองานที่ต้องสั่ง run ซ้ำไปซ้ำมา เช่น การตรวจสอบไฟล์ CSS, JavaScript, การรวมไฟล์ CSS, JavaScript เป็นไฟล์เดียว การคอมไฟล์ LESS ไฟล์ การสั่ง Automation Test JavaScript  การ refresh หน้าเว็บไซด์เมื่อมีการแก้ไขโปรแกรม หรืออื่นๆ

งานเหล่านี้ เมื่อเรามีการเขียนโปรแกรม โดยปกติเราจะกด run เอง แต่ถ้าเราเลือกใช้เครื่องมือ Build Automation เข้ามาช่วย เราจะสามารถประหยัดเวลาในการทำงาน และสะดวกมากขึ้นอีกด้วย

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

1.3.เครื่องมือในการทดสอบ (Debug)
แน่นอน เมื่อเราเขียนโปรแกรม เราก็ต้องมีการทดสอบโปรแกรม ว่าทำงานได้ถูกต้องไหม โดยเฉพาะอย่างยิ่งการทำเว็บไซด์ การเขียนอะไรเข้าไป 1 บรรทัด ถ้าเราไม่ทดสอบ (Debug) ผ่านหน้าเว็บไซด์ อาจจะมีผลกระทบต่อหลายๆส่วนก็ได้ โดยเฉพาะอย่างยิ่งการเขียน HTML, CSS

เครื่องมือที่ช่วยในการ Debug เช่น Google Chrome Inspector (Google Chrome), Firebug (Firefox) เป็นต้น ซึ่งถ้าเราไม่ใช้เครื่องมือในการช่วย Debug เราอาจจะทำงานร่วมกับคนอื่นแล้ว เกิดข้อผิดพลาดขึ้นบ่อยๆ ถ้าพลาดบ่อยๆ คนที่แบกรับภาระก็คือทีมทุกคน ต้องมาคอยตามแก้ไขให้อยู่เรื่อยๆ

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

1.4.เครื่องมือในการแชร์โค้ด (Source Code Management)
สิ่งนี้สำคัญมาก ถ้าใครทำงานเป็นทีม แล้วไม่มี Source Code Management ก็ไม่ต่างอะไรกับการทำงานคนเดียวเลย นั้นก็คือ ต่างคนต่างทำ สุดท้ายแล้วค่อยเอามาประกอบกัน

ในการทำงานเป็นทีม เราจะต้องให้ทุกคนสามารถเห็นชุดคำสั่งที่เราเขียนได้ แก้ไขได้ ลบได้ รู้ว่าใครเขียนอะไรเพิ่มเข้าไปได้ ระบบการจัดการโค๊ดนี้ หลายคนอาจจะใช้อยู่เป็นประจำเช่น  GIT, SVN โดยปัจจุบันนิยมใช้ GIT ในการแชร์โค้ดร่วมกัน โดยอาจจะเลือกใช้ผู้ให้บริการ GIT Server โดยที่เราไม่ต้องติดตั้งเอง และใช้งานฟรีอีกด้วย เช่น Github.com, BitBucket.org

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

และการเก็บโค้ดไว้ใน Git Server นี้จะมีข้อมูล ตอนที่จะเอาโค้ดขึ้น Production จริงๆด้วย โดยใช้ Automation Deployment เข้ามาช่วย ซึ่งจะอธิบายในหัวข้อต่อไป

1.5.เครื่องมือในการติดตั้งขึ้นบนเครื่องจริง (Deploy to Production)
สมัยก่อน ผมก็เป็นคนหนึ่งที่เขียนโปรแกรมเสร็จแล้ว เมื่อจะขึ้นงานจริง (Production) ก็ทำการอัพโหลดไฟล์ทั้งหมดขึ้นโฮสติ้งผ่าน FTP ซึ่งก็สะดวกดี และก็เป็นวิธีที่หลายๆ คนก็ทำกันแบบนี้

ปัญหาอยู่ที่ว่า เมื่อเอางานขึ้นโฮสติ้งเรียบร้อยแล้ว ถ้ามีการแก้ไขเกิดขึ้น เราก็กลับมาแก้ไขที่เครื่องแล้วก็อัพโหลดเฉพาะไฟล์นั้นๆ ขึ้นไปทับไฟล์เดิม ซึ่งวิธีเหล่านี้ก็ใช้ได้ผลอย่างดีเยี่ยม (ในสายตาผมนะ ^^)

แต่เดี๋ยวก่อน ก่อนที่จะอัพโหลดไฟล์ใหม่ขึ้นไปทับ จะต้องสำรองไฟล์เดิมไว้ก่อน แล้วค่อยเอาไฟล์ใหม่ขึ้นไปทับ (กันพลาดว่างั้นเถอะ)

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

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

พูดมาก็ยาวแล้ว สรุปก็คือ Automation Deployment นี่เหล่ะจะเป็นพระเอก ขี่ม้าขาวมาช่วยในการนำโค้ดของเราขึ้นโฮสติ้งอย่างปลอดภัยที่สุด โดยหลักการคือ นำโค้ดที่เราเขียนใน GIT Server เช่น Github.com, BitBucket.org มาติดตั้งให้ที่โฮสติ้งอัตโนมัติเลยทีเดียว

สิ่งที่ตามมาก็คือ เมื่อเราเขียนโค็ดเสร็จเรียบร้อย เราก็ commit ขึ้น Github ให้เรียบร้อย เมื่อจะนำโค้ดที่พึ่งแก้ไขเมื่อกี้นี้ขึ้นโฮสติ้ง เราก็เพียงสั่งให้ระบบ Deployment นำโค็ดจาก Github ไปติดตั้งที่โฮสติ้งเองโดยอัตโนมัติ (เพียงแค่คลิกเดียว หรือ รันคำสั่งเดียวเช่น cap production deploy) ถ้ามีปัญหาเกิดขึ้น เราก็แค่สั่งให้ Rollback หรือถอยกลับไปเวอร์ชั่นก่อนหน้า ภายในเสี้ยววินาที

เห็นไหมล่ะครับว่า การมีระบบ Deployment เป็นสิ่งที่จำเป็นอย่างมาก แต่เชื่อไหมครับ ส่วนใหญ่เราก็ยัง FTP กันอยู่เหมือนเดิม ^^ เพราะการทำระบบ Deployment ต้องใช้ทักษะหลายๆอย่างผสมกัน กว่าจะสร้างระบบ Deployment ได้

The post การเขียนโปรแกรมเป็นทีม ต้องทำอย่างไร appeared first on PhalconHost Blog.

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

แล้วมันยังไงล่ะเนี่ย! โดยปกติแล้ว MVC เราจะแปลกันว่า รูปแบบการเขียนโปรแกรมแบบหนึ่งที่แยกการทำงานของ Model, View, Controller ออกจากกัน เพื่อให้แต่ละส่วนทำหน้าที่แตกต่างกันและทำงานสอดคล้อง ประสานกัน

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

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

แม้กระทั่งว่าเราใช้รูปแบบการเขียนโปรแกรมแบบ MVC หรือแยกโค้ดของเราออกเป็นส่วนๆแล้ว สุดท้ายก็ยังมีแอบแฝงคือ เป็น MVC แบบลูกครึ่ง เช่น Controller เอาไว้สำหรับ Data Validation & Flow Control  เราก็ยังเอาส่วนที่ไม่เกี่ยวข้องกับ  Data Validation & Flow Controller มาไว้ใน Controller อีกนั้นเอง แล้วอะไรล่ะที่ทำให้เราเขียนแบบลูกครึ่งกันอยู่

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

และมีอีกอย่างหนึ่งคือ เราไม่ค่อยได้ให้คนอื่นมาแก้ไขงานต่อจากเรายังไงล่ะ ถ้าเราเขียนดี มีระบบระเบียบ คนที่มาเขียนโปรแกรมต่อจากเราก็ง่าย แต่ส่วนใหญ่เรามักจะเขียนโปรแกรมแบบฉายเดียวด้วยซิ ไม่รู้ว่าจะมีใครมาอ่านโค็ดของเรา ^^

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

The post MVC คืออะไร ผมก็ใช้อยู่นะ appeared first on PhalconHost Blog.