พักเบรคจากบทความเรียนโค้ดเพียวๆ มาเป็นเล่าประสบการณ์การรับงานบ้าง หลายๆ คนคงจะสงสัย ถ้ารับงานต้องรับยังไงบ้าง มีจุดไหนที่เราควรจะรู้เพิ่มเติมเพื่อที่จะได้เอาชีวิตรอดและไม่โดนเอาเปรียบจนเกินไป
Timeline.
- รับ requirement จากลูกค้า
- วางแผน
- Develop & Delivery
- แก้ไข requirement ใหม่ วนลูป 2 และ 3 อีกรอบ
- Production
1.Requirement
ในส่วนแรก Requirement เราไม่เพียงแต่ต้องรับฟัง requirement หรือความต้องการของลูกค้าเพียงอย่างเดียว แต่เราต้องมีความสามารถในการถามอย่างถูกวิธี เพราะบางที requirement ที่ได้มา แม่งน้อยเกินนน ไม่มีขอบเขตของงานแม่งแต่น้อย เพราะคนที่ให้ requirement เรามานั้น อาจจะไม่ใช่คนที่ทำงานฝั่ง IT เราก็ต้องทำการถามกลับไปถึงรายละเอียดปลีกย่อยต่างๆ ให้ชัดเจน
“พี่อยากได้ระบบค้นหาง่ายๆค้นหาผ่านเลขทะเบียน แล้วก็แสดงผลออกมาเป็น pdf ค่ะ”
“ส่วนข้อมูลที่จะค้นหามี address ให้ เข้าไปเอาข้อมูลตาม address เลยค่ะ”
ตามข้างต้น 2 ประโยค แค่นี้คือ requirement จากลูกค้าจริงๆ ซึ่งเมื่อรู้ว่าลูกค้าบอกได้แค่นี้ เราก็ต้องตั้งสมมุติฐานที่เลวร้ายที่สุดคือ ไม่ใช่คนจากฝั่ง IT แน่ๆ
ผมเลยถามกลับไป
“อยากให้ใช้ภาษาอะไรในการเขียนหรอครับ”
“ใช้ภาษาอะไรก็ได้ ไม่ซีเรียสค่ะ”
นี่ไงล่ะ ความซวยของแท้ ไอ้ประโยค “ใช้ภาษาอะไรก็ได้” นี่แหละ เหมือนถามคำถามแล้วได้คำถามกลับมา ไม่ได้ช่วยไรเลย 5555555
โอเค เรามาตั้งหลักใหม่ งั้นแสดงว่าคำถามที่ถามไปแม่ง ux ไม่ดีสินะ เราถามไม่ได้เรื่องเอง ฉะนั้น ตั้งคำถามใหม่แล้วยิงกลับไป
“อยากได้เป็นเว็บไซต์หรือโปรแกรมใช้งานบน windows หรอครับ”
“อยากได้เป็นเว็บไซต์ค่ะ”
“(เยสสสส แบบนี้สิโว้ยยย ที่ถามรอบแรกคือกูตั้งคำถามผิดสินะ)”
ในเมื่อเรารู้ละ ว่าลูกค้าอยากได้ ระบบค้นหาที่ export มาเป็น pdf ใช้งานบนเว็บ requirement ของเราก็เกือบสมบูรณ์ละ แต่ที่ยังไม่รู้คือแม่ง อยากให้ใช้ภาษาอะไรในการเขียน ฉะนั้น ถามเพิ่ม แต่จะถามยังไง นี่แหละยาก ก็เลยคิดไปคิดมา อ่อออ นี่เป็นงาน outsource บริษัทเค้าก็น่าจะมี server รึเปล่า ถ้า server เค้าใช้ภาษาอะไรเราก็ใช้ภาษานั้นละกัน
“อ่าาา ที่บริษัทมี server ใช้งานอยู่แล้วใช่มั้ยครับ”
“ไม่มีจ้าาาา”
“ใช้ cloud ได้มั้ย อะไรก็ได้”
“อ่ออ ใช้ได้ครับ แต่ก็จะมีค่าใช้จ่ายรายเดือนที่ลูกค้ารับผิดชอบเองนะครับ”
“ไม่มีปัญหาค่ะ”
เรียบร้อยยยยย โล่งงงง ในที่สุดก็ได้ requirement ครบซะที
ส่วนเรื่องเวลาก็ไม่บีบมาก ผมขอไป 1 เดือน เพราะมีเรียนซัมเมอร์บวกกับขี้เกียจทำ ก็เลยขอไป 1 เดือนเต็ม ฝั่งลูกค้าก็ไม่ได้รีบอะไร ก็เลยชิวๆ กันไปในเรื่องของเวลา
เรื่องเงิน คิดไปนิดๆหน่อยๆ หลักหมื่น ไม่มากมายนัก งานง่ายๆ
2.วางแผน
- ระบบค้นหาจากเลขทะเบียน และ export เป็น pdf
- ใช้งานบนเว็บ
- ใช้ cloud server
ในเมื่อได้ requirement มาแบบนี้ก็สบายเราละ ว่าจะเลือกใช้ tools ตัวไหนในการพัฒนา ที่ผมเลือกมาก็จะเป็นตามนี้
1.React
เพราะว่าเขียน React เป็นอยู่แล้ว และก็ search เจอตัว lib สำหรับทำ pdf เรียบร้อยแล้วและก็ไม่อยากให้ลูกค้าเสียค่า server แพง เนื่องจากตัว React มันเป็น client side ทำให้ server ไม่ต้องทำงานหนัก ค่า server จึงถูกลง
2.Digital Ocean
สำหรับ Cloud server ผมเลือกใช้ digital ocean เพราะไม่ต้องยุ่งยากเรื่องจ่ายเงินมากนักสามารถอธิบายกับลูกค้าเข้าใจง่าย จ่ายเป็นรายเดือนขั้นต่ำก็เพียงเดือนละ 5$
จากนั้นก็มาดูตัวข้อมูล ข้อมูลที่ได้มาจะอยู่ในรูปแบบของ xml จาก url หนึ่งที่เค้าให้มา มีขนาดอยู่ที่ 13 Mb นิดๆ ก็เลยใช้ solution ที่มักง่ายสุดๆ ก็ให้ตัว React ใน Client นี่แหละ ไป Fetch ข้อมูลมาให้หมดแล้วค่อยค้นหาบนเครื่องของ Client เลย ประหยัดเวลา develop ไปส่วนหนึ่ง
จริงๆ Solution นี้ไม่ค่อยดีเท่าไหร่ แต่เนื่องจากขี้เกียจเขียน API ล้วนๆ ก็เลยทำแบบนี้ไปเลยละกัน ถ้าจะให้แนะนำก็ควรจะทำ REST api สำหรับทำการดึงข้อมูลจาก address แล้วจึง search จากตัว server แล้วค่อย ส่ง Respones กลับมาให้ที่ตัว Client ทำแบบนี้จะดีกว่า ปลอดภัยกว่าด้วยในเมื่อเราวางแผนเสร็จสิ้นก็ได้เวลาลงมือพัฒนาเว็บในวันต่อๆไป ไม่ทำภายในวันนั้นหรอก ขี้เกียจมาก 5555555555
3.Develop & Delivery
ในส่วนของ Develop & Delivery จะมาเล่าปัญหาเล็กๆน้อยๆในการพัฒนา
สิ่งแรกที่เจอก็คือ XML หลังจาก fetch มาเสร็จแล้วมันมี method อะไรให้ใช้ใน Javascript บ้าง เนื่องจากส่วนตัวแล้วไม่ค่อยคุ้นชินกับการทำงานกับ XML ซักเท่าไหร่ก็เลยยัง งง อยู่แต่ก็เปิดหาตามพวก stackoverflow หรือตาม quora เปิดแปปๆก็เจอไม่ได้ยากเย็นอะไรมาก แค่ struture มันจะงงๆหน่อยแค่นั้นเอง
สิ่งที่สองที่เจอคือ pdfjs เพิ่งเคยหัดใช้เป็นครั้งแรกก็เลยเกิดอาการมึนๆ งงๆ หน่อยๆ แต่ก็ไม่ได้ยากอะไรมากมาย ใช้ learning curve ต่ำมากกกกกก
ทุกอย่างเหมือนจะเรียบร้อยงานง่ายๆ สบายๆ จนเราทำระบบ search เสร็จ จึงทำการ Delivery ส่งไปให้ลูกค้าดูงานเป็นครั้งแรก เหตุผลที่ต้อง Delivery ก่อนก็เพื่อที่จะให้ลูกค้าปรับแก้ Requirement ว่าสิ่งที่เราเข้าใจกับสิ่งที่เค้าเข้าใจมันเป็นสิ่งเดียวกันมั้ย ลูกค้าก็ทำการตรวจสอบดู ก็มีบางจุดที่ต้องแก้ไข แต่ไม่ใช่ปัญหาอะไรมาก เช่นเลขทะเบียน โดยเลขทะเบียน ตัวอย่างมันจะเป็น xx09321841 แต่เค้าอยากให้ใส่เฉพาะ 09321841 ไม่ต้องใส่ 2 ตัวอักษรข้างหน้าเลข เราก็โอเค ปัญหาเล็กๆ ถือว่าสอบผ่าน
4.แก้ไข requirement ใหม่ วนลูป 2 และ 3 อีกรอบ
เหตุมันเกิดการแก้ไข Requirement ใหม่ตรงที่ลูกค้าขอให้แก้ address ให้กลายเป็น Web Service อีกตัวหนึ่ง ซึ่งเราก็ไม่ได้คิดไรมาก จนกระทั่งลองเข้าไปดู Web Service ตัวนั้นจนพบว่า
ชิบหาย !!
ความรู้สึกตอนนั้นคือเหมือนเห็นภาพตัวเองที่โผล่ออกจากประตูไปที่ไหนก็ได้แล้วพบกับอารยธรรมของโลกยุคกลาง มีแต่สิ่งที่เราเคยเห็นแต่ในหนังสือประวัติศาสตร์ ไม่เคยคิดว่าจะได้มาพบกับของจริงก็วันนั้นแหละ และที่น่ามหัศจรรย์ก็คือยังมีคนดูแลและรักษาให้มันยังใช้การได้จนถึงทุกวันนี้ นี่มันยิ่งกว่าการค้นพบสิ่งมหัศจรรย์ของโลกใบนี้ !!!!
เอาละ ตัดกลับมา ที่ไปเจอก็คือ SOAP นั้นแหละ อธิบายง่ายๆ ก็คือเหมือนกับ REST API แต่มาก่อนตัว REST โดยจะส่งข้อมูลในรูปแบบของ XML เท่านั้นและก็จะมี schema เอาไว้กำหนดวิธีการใช้ SOAP ของแต่ละ Service
ดูๆ ไป Web Service Description แม่งก็เหมือนกับตอนเขียน GrahpQL เพียงแต่ GraphQL จะเป็นในลักษณะของ Modern มากกว่าและความชิบหายก็ยังไม่จบเนื่องจากเราค้นพบว่าข้อมูลที่มีทั้งหมดในตัว Web Service อันนี้มีขนาดทั้งสิ่ง 1.45Gb Record มีขนาดทั้งหมด 500k ซึ่งเราต้องทำการออกแบบระบบ Backend ใหม่ให้สามารถรองรับไฟล์ขนาด 1.45Gb รวมถึงกำหนดขอบเขตของเว็บไซต์และการดำเนินงานใหม่อีกครั้งหนึ่ง
แก้ไขงาน
สิ่งแรกที่เราตระหนักก่อนเรื่องแก้ไขระบบหลังบ้านก็คือ เงิน !! ใช่ครับ เงิน !! เพราะตอนแรกเราคิดเงินในเรทที่โปรแกรมไม่ได้มีความซับซ้อนมากขนาดนี้ เราจึงต้องทำการโทรไปหาลูกค้า เพื่อพูดคุยในส่วนของค่าใช้จ่ายที่ต้องเพิ่มมากยิ่งขึ้น
ระหว่างการโทรพูดคุยกับลูกค้า เราก็พบอีก 1 insight ซึ่งมีผลกระทบต่อเรื่อง เงิน !! ของเรานั้นก็คือ
“ขอไปคุยกับทางผู้ใหญ่ ก่อนนะคะ เดี๋ยวให้ทางผู้ใหญ่พิจารณาดูก่อน”
ชิบหายแล้วไงงงงง ถ้าฝั่งนู้นไม่ให้ผ่านแม่งจะทำไงวะ ตังก็ได้เท่าเดิม แทนที่จะได้เพิ่มขึ้น เอาไงดี เอาไงดี
ก็เลยปิ๊งไอเดียขึ้นมาว่า
“อ่ออ งั้นเดี๋ยวฝั่งนี้ จะเขียนเอกสารชี้แจงค่าใช้จ่ายแบบละเอียดพร้อมคำอธิบายแนบไปให้นะครับ”
เอกสาร
ใช่แล้วครับ เอกสาร สิ่งที่พวกเราเหล่าคนทำงาน IT พยายามหนีให้ไกลที่สุด มาวันหนึ่งเราก็ต้องกลับมาทำ เอกสารชี้แจงต่างๆ เพื่อที่งานของเราจะได้ไปต่อได้ อารมณ์ตอนที่นั่งทำเอกสาร จู่ๆ คำถามมากมายก็ไหลเข้ามาในสมองพร้อมกัน “นี่เราจะต้องทำเอกสารจริงๆหรอ” “เราต้องเขียนอธิบายให้ผู้บริหารอ่านหรอ” “มันคืองานของ Developer จริงๆหรอ” ตอนนั้นคือจะอะไรก็ช่างแม่ง เขียนให้เค้าอ่านเข้าใจในความจำเป็นของการเพิ่มค่าใช้จ่ายให้เข้าใจมากที่สุด เพื่อที่งานของเราเค้าจะได้เทเงินมาให้เราได้ซะที
สุดท้ายก็เขียนแนบไปให้ และ ได้คำตอบกลับมาว่าโอเค เข้าใจเรื่องค่าใช้จ่าย อนุมัติ
อ่าาา รอดไปอีก 1 เรื่อง
4.2 ออกแบบระบบ อีกครั้ง
หลังจากตอนแรกที่ผมใช้ความขี้เกียจล้วนๆ ในการออกแบบระบบทำให้เมื่อระบบใหญ่ขึ้นผมก็ต้องทำการรื้อระบบใหม่อีกครั้งหนึ่ง ซึ่งจะมีปัญหาหลายอย่างที่ทำให้งานออกแบบระบบยากขึ้น เช่น
- ตัว Web Service ไม่สามารถดึงข้อมูลออกมาทีเดียวทั้งหมดได้ แต่แบบพาร์ทย่อยๆ ออกไปประมาณ 150 พาร์ท
- เนื่องจากเราไปดึงข้อมูลมาจาก Web Service อีกทีหนึ่งทำให้ข้อมูลที่เราได้มา ไม่ Real Time ทำให้ต้องทำการอัพเดทระบบใหม่ตามเวลาที่กำหนดไว้
- เวลาในการ Update ข้อมูลรวมไปถึงสเปค server ของ Digital Ocean เป็นจุดหนึ่งที่ผมต้องค่อย trade off กับค่าใช้จ่ายของลูกค้าที่จะต้องเพิ่มมากขึ้น
หลังจากวิเคราะห์องค์ประกอบต่างๆ ก็ได้ระบบใหม่ดังนี้
- จะมี Server ทั้งสิ้น 3 ตัว ทั้ง 3 ตัวทำหน้าที่ Request ข้อมูลจากตัว Web Service โดยแบ่งพาร์ทสัดส่วนเป็น 60 60 30 โดย server ตัวที่ดึงข้อมูลมา 30 พาร์ทจะใช้สำหรับการ Deploy ตัว React server ด้วย
- ทำไมต้อง Server 3 ตัว คำนวณเวลาในการอัพเดทข้อมูลแต่ละรอบจะเฉลี่ยอยู่ที่ 15 — 20 นาที ไม่ได้นานเกินไป และลูกค้ายอมรับเวลาที่ใช้ Update ข้อมูลได้
- ข้อมูลที่ได้รับมาจะเอาไปเก็บลงในฐานข้อมูลของแต่ละ Server อีกรอบหนึ่ง เมื่อเก็บข้อมูลลงในฐานข้อมูลเสร็จ จึงทำการค้นหาภายในฐานข้อมูลอีกครั้งหนึ่ง โดยฐานข้อมูลที่เลือกใช้ก็หนีไม่พ้น MongoDB
- เพิ่มเติมระบบ Watchdog ทิ้งไว้ด้วย เนื่องจากเราไม่สามารถนั่ง Monitor ตลอดได้ จึงทำระบบ Watchdog ทิ้งไว้ เพื่อดูว่า Server ตัวไหน Down รึเปล่า ถ้า Down ก็ให้ส่งข้อความเข้ามาที่ Email แล้วค่อยทำการแก้ไข
4.3 Develop & Delivery Again !!!!!!
การ Develop งานครั้งนี้ยากยิ่งกว่าครั้งก่อนมาอีกหลายๆ step เพราะเราต้องคอยคุมไม่ให้เครื่อง server ของเรานั้นเกิดอาการ overload ซะก่อน ก็ต้องทำการ optimize
เนื่องจาก Nodejs ทำงานเป็น Non-Blocking ทำให้ระบบนั้นทำงานได้โดยไม่ต้องรอให้งานบางส่วนเสร็จก็ทำงานต่อได้
ซึ่งปัญหาจะเกิดเมื่อ insert ลงฐานข้อมูล เพราะว่าการทำงานซึ่งเป็น Non-Blocking จะทำให้การ insert ต่างๆ เกิดการ Write พร้อมๆกันลงไปใน Disk โดยไม่ต้องรอให้ตัวก่อนหน้า Write เสร็จจนทำให้ Disk overwrite และ CPU overload จนระบบ disconnect กับตัว MongoDB โดยอัตโนมัติ ถ้าจะ reconnect ใหม่ก็ต้อง Reboot เครื่องอีกรอบหนึ่ง
ซึ่งวิธีแก้ปัญหาก็คือทำให้ Nodejs ทำงานเป็น Blocking ซะ โดยใช้ตัว Promise และ Async/Await เข้ามาช่วยแก้ปัญหาในส่วนนี้ รวมถึงใส่ setTimeOut ในการ insert เพื่อเพิ่มช่องว่างในการพักการทำงานของ CPU และ Disk
ผลลัพธ์ที่ได้ก็คือสามารถ insert ข้อมูลได้ตามปกติ ไม่เกิดอาการ error แต่อย่างใด และเพิ่มเติม Non-blocking code สำหรับ Updating ไม่ให้ค้นหาในขณะที่กำลังทำการอัพเดทข้อมูล ถ้าตัว Server API กำลังทำการอัพเดทข้อมูลก็จะให้ Respones กลับไปว่า Updating แต่ถ้าค้นหาไม่เจอก็ส่ง Not Found Data ประมาณนี้
Delivery
ถึงช่วงให้ลูกค้าลองเทสระบบ เนื่องจากตัว Server API ของเราต้องทำการรัน Test ใน Enviroment จริง ก็คืออัพขึ้น Production ทิ้งไว้เพื่อความแน่ใจ ทิ้งไว้ประมาณ 2–3 วันขึ้นไป โดยต้องคอย Monitor เป็นช่วงๆ เพื่อดูความเสถียรของระบบ
ไหนๆ ก็เทสระบบส่งงานให้ลูกค้าดูด้วยเลยละกัน ในส่วนนี้ให้ลูกค้าเล่นได้เฉพาะระบบ search เพียงอย่างเดียวให้ดูว่าข้อมูลครบถ้วนมั้ย ขาดตกตรงไหนรึเปล่า ในรอบนี้ลูกค้าก็รับได้ ไม่ต้องแก้ไขงานแต่อย่างใด
ถือว่าสอบผ่านช่วง Delivery ก็เหลือแค่ระบบทำตัว PDF ออกมาให้ Client Download กลับไปใช้งาน
5.Production
ช่วงนี้เป็นช่วงทิ้งท้ายแล้วสำหรับการพัฒนาระบบต่างๆ ก่อนจะ Production ก็ต้องเก็บรายละเอียดให้เรียบร้อย log แต่ละที่เอาออกหมดรึยัง handle error ครบมั้ย ทำ UX ในส่วนของหน้าเว็บไซต์ชัดเจนพอรึเปล่า และก็ไม่มีไรมาก ก็ทำการอัพเว็บตัว Final ของเรา ไปแทนที่ตัวเทสที่อยู่บน Digital Ocean จบแล้วววว
เอกสาร ต้องบอกด้วยมั้ยอะ
ทิ้งไว้หน่อยละกัน
ก็ทำใบเสร็จรับเงินให้ลูกค้าด้วย และต้องเขียนลงไปด้วยว่าลูกค้าได้รับอะไรเป็นงานของลูกค้า เพราะมีข้อกฎหมายกำหนดถึงงาน freelance เกี่ยวกับเรื่องทรัพย์สินทางปัญญา
และก็ถ้าโดนหัก 3% ก็ขอเอกสารกลับมาเอาไว้ไปยื่นขอคืนภาษีตอนสิ้นปี ไม่งั้นก็กลางปี
ส่วนค่า Server และ Maintenance อันนี้จะทำเป็นสัญญาให้ลูกค้าเซ็นและกำหนดจ่ายเงินต่างๆ ก็อยู่ในสัญญา
/* ส่วนนี้จะไม่ทำเป็นหนังสือสัญญาก็ได้ เพราะยังไงเราก็จัดการ Server เองอยู่แล้ว แต่ถ้าจะให้ดีก็ทำเป็นหนังสือออกมา จะได้สบายใจทั้งสองฝ่าย แฮปปี้กันทั้งคู่ */
