Oz’s Blog

กรกฎาคม 27, 2007

Practice Makes Perfect, Part I: The Cause

Filed under: Art of Software Engineering — siroz @ 3:40 pm

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

แน่นอนว่าครั้งนี้ของผม ก็เป็นไปตามกรณีที่อธิบายมา (เหมือนเช่นครั้งอื่นๆ ที่เจอมา)
โปรแกรมที่ผมต้องเข้าไปทำนั้น เป็น Web Application ที่ทำด้วยเทคโนโลยี Java ซึ่งก็ฟังดูปกติดี
เพียงแต่ว่าครั้งนี้ พิเศษตรงที่ logic ทั้งหมด รวมทั้ง UI ทั้งหมด สามสี่หน้าจอ ถูก implement ลงไปใน JSP ตัวเดียว ขนาดประมาณพันแปดร้อยกว่าบรรทัด

สิ่งแรกที่ผมคิด ในตอนที่ผมเปิด source code ขึ้นมาดู คือ “อะไรของมันวะ”
ภายใน source code ของ JSP ตัวนี้ ประกอบไปด้วย logic สำหรับ initialization (เช่น การอ่านไฟล์ property)
UI form ในรูปแบบของ HTML ซึ่งถูกครอบด้วย condition เต็มไปหมด (อย่างที่บอกว่า สามสี่จอ ถูกใส่ลงลงมาใน JSP ตัวเดียว ดังนั้นจึงต้องมี condition มากำหนดว่า ตอนนี้จะให้แสดงจอไหน ส่วนไหน)
และ logic ที่ใช้ในการทำงานจริงๆ
ส่วนประกอบที่ว่า นี้ อยู่ปนเป สลับกันไปสลับกันมา ในไฟล์ขนาดพันแปดร้อยกว่าบรรทัดนี้ ดังนั้น วิธีเดียวที่จะเข้าใจว่า โปรแกรมนี้ทำงานยังไง คือ ต้องอ่าน source code ทั้งหมดเท่านั้น

หลังจากผมใช้เวลาเกือบหนึ่งวัน ทำความเข้าใจ source code ตัวนี้ ซึ่งนับว่าโชคดีที่มี application ตัวนี้ ที่ deploy ไว้ให้ผมสามารถเข้าไปลองใช้ได้
… ก็ถึงเวลาตัดสินใจ
การที่จะแก้ไข code ตัวนี้ เพื่อจะเพิ่มหน้าที่บางอย่างเข้าไปนั้น ไม่ใช่ทางเลือกที่ดีแน่นอน
เว้นเสียแต่ว่า จะมีการ refactor กันขนานใหญ่ .. การเพิ่มเติ่มอะไรเข้าไปใน code ตัวนี้ มีแต่จะยิ่งทำให้มันแย่ลงไปอีก
นอกจากนั้น ผู้ที่ดูแลงานส่วนนี้อยู่ ก็ยังไม่อยากให้ใครไปทำอะไรกับ code ตัวนี้ เพราะ ไม่อยากจะเสี่ยง และลงทุน(เสียเวลา) ไปแก้ไขอะไรที่มันใช้งานได้ดีอยู่แล้ว
ดังนั้น ทางเลือกที่เหลืออยู่คือ การสร้างโปรแกรมชุดใหม่ขึ้นมา เพื่อ implement งานที่ต้องการเพิ่มเติม โดยเลียนแบบการทำงานของโปรแกรมเดิม แต่ไม่ได้ใช้ code เดิมที่มีอยู่
ในกรณีนี้ อาจจะเรียกได้ว่า reinventing the wheel .. แต่ครั้งนี้ “ล้อ” ของเราจะต้อง flexible กว่าเดิม สามารถดัดแปลง เพิ่มเติม และแก้ไขได้

เมื่อตัดสินใจได้แล้ว ผมก็ลงมือทำ
ขณะนี้ ถึงแม้จะยังไม่เสร็จสมบูรณ์ (เนื่องจากโดน interrupt ด้วยงานอื่นที่สำคัญกว่า) แต่ก็เป็นรูปเป็นร่าง และพอจะเห็นจุดหมายปลายทางแล้ว
เนื่องจาก ประเด็นเรื่อง Understandability ค่อนข้างสำคัญ และในทีมไม่ได้มีการใช้งาน framework หรือ library ใดๆ เฉพาะเจาะจง
จึงมีความจำเป็นที่จะต้อง ลดการใช้งาน framework หรือ library ที่ไม่ได้เป็น standard ที่คนทั่วไปรู้อยู่แล้ว ให้เหลือน้อยที่สุด
ผลลัพธ์ที่ได้ จึงกลายเป็น Servlet หนึ่งตัว ที่ทำหน้าที่เป็น composite controller … class จำนวนหนึ่งที่ implement business logic
และ template (ใช้ FreeMarker) 4-5 ไฟล์ สำหรับเป็น view
เพียงเท่านี้ การพัฒนาซอฟต์แวร์ ก็ไม่ต้องเจ็บปวด ทุกข์ทรมาน จนเกินไปนัก!!
ซึ่ง solution นี้อาจจะไม่ได้เป็น MVC ที่สมบูรณ์ แต่ก็แยก logic เป็น module ตามประเภทการทำงาน ด้วย solution และ technology ที่เรียบง่าย (เหมาะสมกับขนาดของงาน)
สามารถ implement ได้ในเวลาที่จำกัด และไม่มีปัญหาเรื่อง learning curve ในตอน maintenance

สิ่งที่น่าสนใจจากกรณีนี้ คือ อะไรคือ แรงดลใจ ให้ผู้ที่เขียนโปรแกรมตัวนี้ ตัดสินใจสร้างสปาเก็ตตี้จานใหญ่ จานนี้ขึ้นมา
(code ที่เขียนวนไปวนมา พันกันอีรุงตุงนัง เรียกกันว่า spaghetti code)
พอดี ผมมีโอกาสได้ สอบถาม (หรือจะเรียกว่า สืบสวนดี?) เกี่ยวกับต้นตอของโปรแกรมตัวนี้ เล็กน้อย
(ถึงตรงนี้ ผมไม่แน่ใจว่า เขียนแบบนี้ จะทำให้ “เจ้าตัว” รู้ไม่ดีหรือเปล่า .. แต่คิดๆ ดูแล้ว ผมมั่นใจว่ามีกรณีแบบนี้หลายครั้ง ผมก็ไม่ได้ตั้งใจจะตำหนิอะไร นอกจากนั้น ถ้าคุณเป็นคนที่เขียน code พันกันเป็นสปาเก็ตตี้ .. คุณควรที่จะเริ่มรู้สึกไม่ดี กับตัวเองได้แล้ว!!)
สิ่งที่ผมได้รู้คือ .. โปรแกรมนี้ ตั้งใจจะให้สร้างมาเพื่อเป็นเครื่องมือ เพื่อให้ใช้ช่วยทำงานในการพัฒนาซอฟต์แวร์ในทีมเท่านั้น ดังนั้น จึงไม่มีการส่งมอบให้กับผู้จ้าง หรือลูกค้า
นี่จึงเป็นเหตุผลว่า โปรแกรมตัวนี้ ไม่มี specification ไม่มีเอกสารอื่นๆ ประกอบ
นอกจากนั้น เนื่องจากโปรแกรมตัวนี้ ไม่ได้เป็นส่วนหนึ่งของการส่งมอบ ดังนั้น จึงไม่ได้วางแผนเพื่อใช้งบประมาณ (เวลา) ในการพัฒนา .. ซึ่งกลายเป็น requirements ที่ว่า
“จะเขียนยังไงก็ได้ ขอให้ใช้งานได้ .. ขอให้เสร็จเร็วที่สุดเป็นใช้ได้”

ความคิดที่ว่านี้ จะผิดหรือไม่ อาจจะไม่มีใครตอบได้ เพราะในข้อจำกัดด้านเวลา และงบประมาณ อาจจะไม่มีคำตอบที่ดีที่สุดในกรณีนี้
แต่ ในฐานะ ผู้ปฏิบัติ ควรจะทำอย่างไร?
ในกรณีนี้ ผู้เขียนโปรแกรมนี้ (และคนที่เขียนโปรแกรมแบบนี้) “เลือก” ที่จะใช้วิธีที่ตัวเค้า และ developer ส่วนใหญ่ (ในความเห็นของผม) “เชื่อ” ว่าง่ายที่สุด และจะทำให้ทำงานได้เร็วที่สุด
ผมใช้คำว่า “เลือก” เพราะ นี่เป็นเพียงวิธีหนึ่งเท่านั้น .. ยังมีวิธีอื่นๆ อีกมากมาย
ผมใช้คำว่า “เชื่อ” เพราะ วิธีนี้ อาจจะไม่ใช่ วิธีที่ทำให้ทำงานได้เร็วที่สุดก็ได้!!
ต้องบอกว่า น่าเสียดาย เพราะ ตามความเป็นจริงแล้ว ผมเชื่อว่า developer คนหนึ่ง แม้ว่าจะอยู่ใต้ความกดดันเรื่องเงื่อนไขเวลา ควรจะสร้างงานออกมาได้ดีกว่านี้ ได้ดีกว่า solution ที่ผมทำ .. ได้ดีกว่า spaghetti code

ในเบื้องต้น ต้องยอมรับว่า ความเชื่อที่ว่า การเลือกทำวิธีที่ง่ายที่สุดนี้ ฟังดูมีน้ำหนักมากทีเดียว ซึ่งถ้ามองจากในกรณีนี้ …
การ implement logic ทั้งหมดใน JSP ตัวเดียว ทำให้ขั้นตอนการทำงานสะดวกมาก เพราะ JSP server/container สามารถ recompile source code ทันที หลังจากเรา save และเรียกใช้งาน
ต่างกับวิธีของผม ที่ใช้ทั้ง class ธรรมดา .. Servlet .. และ FreeMarker template .. นอกจากนั้น ยังมีไฟล์ configuration อีก
ผมต้อง compile .. build .. และ redeploy บน server ก่อน ถึงจะใช้ทดสอบหรือใช้งานได้
ซึ่งผมก็ชดเชยด้วย การทำ build script ซึ่งทำให้ขั้นตอนเหล่านี้ ทำได้โดยอัตโนมัติ
แต่ .. ถ้ามองย้อนอีกมุม คือ ผลในระยะยาว .. เราสามารถตอบได้ทันทีว่า solution แบบไหน ดีต่อการ maintenance มากกว่า

มองแล้วอาจจะเหมือนเป็น Trade-Off
การจะทำ code ให้มีคุณภาพดีระดับหนึ่ง (อาจจะไม่ต้องดีเลิศ สวยงามที่สุด แต่ดีพอสำหรับการ maintenance) อาจจะต้องใช้เวลาในการคิด วางแผนว่าจะแบ่ง module อย่างไร จะต้องเขียน logic อย่างไร ให้ยืดหยุ่น และแก้ไขได้ง่าย
ดังนั้น การทำงานที่ถูกจำกัดด้วยเงื่อนไขของเวลานั้น ไม่สามารถจะทำอย่างนี้ได้ จึงต้องจำยอมสร้าง code ที่มีปัญหาบ้าง ทั้งๆ ที่รู้ ที่เห็นอยู่ซึ่งๆ หน้า เพื่อที่จะประหยัดเวลา เพื่อให้งานเสร็จเร็วขึ้น

อยากจะตะโกนดังๆ ว่า ผิด!!
ต้องย้อนถามว่า developer ที่มีประสบการณ์ในระดับหนึ่งนั้น จะสามารถสร้าง solution หรือ code ในระดับที่ “ดีพอ” นั้น ได้ไหม??
ผมเชื่อว่า คำตอบ คือ ได้ แน่นอน
แต่ถามว่า ทำไมในการทำ solution หรือ code แบบนี้ ถึงต้องใช้เวลามากกว่าอย่างมีนัยสำคัญ เมื่อเทียบกับการเขียน spaghetti code ??
ใครพอจะหาคำตอบที่มีเหตุผล ได้บ้างไหมครับ?

สำหรับผมแล้ว .. ผมมองว่า เรา ในฐานะ developer ถูกฝึกมาให้สร้างงานที่ดี ดังนั้น มันควรจะง่ายและถนัด ที่จะสร้างงานที่ดี (เพราะเราฝึกมาอย่างนั้น) มากกว่า ที่จะสร้างงานที่ไม่ดี จริงไหมครับ
ปัญหา คือ ความเป็นจริง (อันแสนโหดร้าย) ไม่ใช่อย่างนั้น
หลายๆ ครั้ง ผมเห็นว่า developer หลายๆ คน มีความรู้ มีความสามารถ มีศักยภาพที่ดี สามารถสร้างงานออกมาได้ดี ออกแบบมาได้ดี งานมีคุณภาพดี .. แต่ทว่า ใช้เวลานานเกินกว่าที่ควร ในการสร้างงานออกมา
การที่ใช้เวลามากอย่างนั้น เป็นการผลักตัวเองให้ไปติดมุม ให้ไม่มีทางเลือก เมื่อมีข้อจำกัดเรื่อง “เวลา” เข้ามาบีบบังคับ .. และท้ายที่สุด ก็จะต้องจำใจยอมลดคุณภาพของงานตัวเอง เพื่อชดเชยกับเงื่อนไขเวลา

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

ซึ่งจากคำถามเหล่านี้ จะเห็นว่า ผมไม่ได้หมายถึง ความรู้ทางด้านเทคโนโลยี ซึ่งนับวันจะมีใหม่เข้ามาเรื่อยๆ จนเราตามไม่ทัน .. แต่ผมหมายถึงความรู้พื้นฐานทั่วไป ที่เป็น “ทุน” ติดตัว developer ไปตลอด
เช่น ความรู้พื้นฐานด้าน programming ความรู้ด้านการออกแบบโปรแกรม และ Object-Oriented Design

คำถามเหล่านี้ เหมือนกับถามว่า … คุณรู้คำศัพท์ และสำนวนภาษาอังกฤษ มากน้อยแค่ไหน
แล้วย้อนกลับไปถามอีกครั้งว่า .. คุณสามารถใช้ความรู้ที่มีสื่อสารได้ดีแค่ไหน
การรู้คำศัพท์ สำนวน และไวยกรณ์มากมาย จะไม่มีประโยชน์อันใดเลย ถ้าคุณไม่สามารถใช้งานมันสื่อสารได้จริง และ ต้องทำได้ทันท่วงทีด้วย
(การตอบคำถาม หลังจากเลือกคำที่เหมาะสม และเรียบเรียงประโยคในใจสามนาที ไม่ถือว่าเป็นการสื่อสารที่ได้ผลเท่าไรนัก ในทางปฏิบัติ)
ตัวอย่างนี้ ค่อนข้างชัดเจน .. ถ้าคุณตกอยู่ในกรณีนี้ สิ่งที่คุณต้องทำ คือ “ฝึกฝน”

และแล้ว ผมก็เขียนยาว(เกินไป) อีกแล้ว
ผมทิ้งคำถามไว้ให้คุณและผม สำรวจตัวเอง ..
แล้วเราจะมาต่อกันในตอนหน้าครับ

15 ความเห็น »

  1. Django: The Web framework for perfectionists with deadlines

    ความเห็น โดย กานต์ — กรกฎาคม 31, 2007 @ 10:05 am

  2. งง งง

    ความเห็น โดย siroz — กรกฎาคม 31, 2007 @ 5:53 pm

  3. มาลงชื่อว่าอ่านจบครับ

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

    ความเห็น โดย deans4j — สิงหาคม 6, 2007 @ 5:04 am

  4. 😀

    ความเห็น โดย siroz — สิงหาคม 6, 2007 @ 6:07 pm

  5. ถ้าฝึกตัวแล้วฝึกเร็วไป ธาตุไฟอาจจะเข้าแทรกได้ ครับ🙂

    ความเห็น โดย idome — สิงหาคม 6, 2007 @ 9:50 pm

  6. อ่านจบแล้วครับ ชอบครับ

    ความเห็น โดย Spanky — สิงหาคม 28, 2007 @ 11:43 am

  7. ขอบคุณครับ

    ความเห็น โดย siroz — สิงหาคม 28, 2007 @ 8:35 pm

  8. ผมเคยรื้อ code คนอื่นอยู่ หลายครั้ง
    รู้สึกปวดหัว เพราะคนส่วนใหญ่ (ที่ผมเจอ)
    ชอบเขียน code ในแบบที่ “อ่านเข้าใจคนเดียว”

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

    อย่าว่าแต่คนอื่นเลย บางทีอ่านของตัวเองผมก็รู้สึกแบบนั้นเหมือนกัน
    (ฮา) แต่หลัง ๆ ก็พยายามปรับปรุงให้ code ตัวเองมี readbility
    ที่ดีขึ้น ยังไงก็คงต้องปรับปรุงอีกเรื่อย ๆ

    ผมคิดว่า ตอนที่เราเขียนโปรแกรมไป ใน project นึง พอเขียนไปซักพัก มันจะเริ่มเห็น design ที่เหมาะสม จะเขียนอะไรยังไงไว้ตรงไหน ให้เรียกใช้ได้ง่าย หรือดู make sense อะไรที่เขียนไปแล้วมันมีจุดอ่อนตรงไหนแล้วควรแก้ไขยังไง แต่ที่คนส่วนใหญ่(ที่ผมเจอ)ไม่แก้ก็คือ ข้ออ้างที่ว่า ” อ๊ะ ก็เนี่ย เขียนมาตั้งเยอะแล้ว ขี้เกียจไปรื้อ” บ้างหล่ะ
    “โอยเขียนแค่นี้ก็ใช้ได้แล้ว” บ้างหล่ะ ฯลฯ สิ่งนึงที่ผมคิดเลยเมื่อเห็นสิ่งเหล่านี้ก็คือ คนเหล่านี้ไม่มี motivation ถ้าจะพูดให้แรงขึ้น ผมว่าไม่มี ethic ( ฟังแล้วอยากจับพวกนี้ไปเรียน software engineer ซักคอร์ส จะได้รู้อะไรมากขึ้นซะมั้ง )

    ความเห็น โดย taiko — มกราคม 8, 2008 @ 8:39 pm

  9. ethic หรือ จรรยาชีพสำหรับวงการ software development (ผมชอบเผลอเรียกเป็น “จรรยาบรรณ” อยู่เรื่อย ซึ่งผิด เพราะคำนี้ใช้กับวงการหนังสือเท่านั้น .. “บรรณ” แปลว่า หนังสือ)
    เป็นสิ่งที่ไ่ม่ค่อยมีคนพูดถึงนัก ซึ่งอาจจะเป็นเพราะ ไม่มีใครมานิยมมันให้ชัดเจนก็ได้
    ผมมองว่า เรื่องนี้เป็น common sense ระดับนึง คือ คนทำงานทุกคน ควรจะ “ใส่ใจ” ในงานที่ตัวเองรับผิดชอบ ไม่ว่าจะเป็นงานประเภทใดก็ตาม

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

    ความเห็น โดย siroz — มกราคม 10, 2008 @ 5:00 pm

  10. โอ ถ้าพูดแบบนี้นี่ ผิดกันหลายคนเลยครับ อย่างเช่นที่ผมได้ยินบ่อย ๆ ก็ จรรยาบรรณความเป็น…(ครู ตำรวจ …)
    สำหรับผม ผมแปล ethic ว่าศึลธรรม เอ้อ เพี้ยน แปลว่าคนที่ไม่ได้
    นับถือพุทธ ก็ใช้คำนี้ไม่ได้ซิเนี่ย(ฮา) ล้อเล่นครับ ไม่เคยนิยามอ่ะ
    ทับศัพท์ลูกเดียว

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

    ออ ประเด็นนึง ที่ผมว่ามีผลมากเลยเหมือนกัน ในการไม่กลับมาแก้งานให้ดีขึ้น ก็คือ method ในการ develop
    ปฎิเสธไม่ได้ว่า waterfall ยังเป็นอะไรที่ใช้กันอยู่มากในไทย (และผมว่า approach อย่าง agile นี่ คงเป็นไปได้ยากมากๆๆๆๆๆๆๆ ที่จะเอามาใช้กับเมืองไทยได้อย่างมีประสิทธิภาพ) พอเป็นการ develop แบบนี้ กว่าจะกลับมาดูงาน design ของตัวเอง
    ก็พบว่า เฮ้ย ชิ้นงานมันใหญ่แล้ว เริ่มแกะไม่ได้ละ จะแคะยังกลัว ๆ เลย
    นี่ยิ่งถ้า design ที่ทำไปมี coupling สูงอีกนี่ จบเลยชีวิต
    ไม่ต้องยุ่งแล้ว code ตรงนั้น กลายเป็นกล่องดำสมบูรณ์แบบ

    เรื่อง maintain code นี่ ผมจะรอคุณ siroz เปิดประเด็นนะครับ จะได้มาแลกเปลี่ยนความเห็นอีก ^^

    ความเห็น โดย taiko — มกราคม 10, 2008 @ 10:48 pm

  11. อุย เขียนไม่ละเอียด ขยายความเรื่อง method
    คือ ผมคิดว่า ในบางลักษณะ เรายังเขียน codeกัน
    isolate มาเกินไป แล้วไม่มีการตรวจสอบ จากคนอื่น
    (บางที่ไม่มี qa ) เพราะงั้นผมเลยคิดว่า
    เออ ถ้าเราใช้ pair programming มันน่าจะเข้าท่านะ
    ช่วยกันเขียน ช่วยกันดู

    ความเห็น โดย taiko — มกราคม 10, 2008 @ 10:51 pm

  12. ethic ถ้าความหมายกว้างๆ น่าจะแปลว่า จริยธรรม นะครับ .. แต่ในที่นี้คุยกันเรื่องวิชาชีพ ผมเลยว่าน่าจะหมายถึง จรรยาชีพ (จรรยาบรรณ จรรยาแพทย์ ฯลฯ)

    ผมได้ยินมาว่า ในเมืองไทย ก็มีหลายๆ ที่ ที่ใช้ agile practice แล้วครับ (ปรับใช้ตามองค์กร) เท่าที่ฟังมา ก็ค่อนข้างได้ผลดีด้วย

    ผมมองว่า เรื่องของ process หรือ approach คงไม่มีตัวไหนที่ดีที่สุด หรือแก้ปัญหาได้ทุกอย่าง เราคงต้องเลือกตัวที่เหมาะสมกับงานมาใช้ แม้แต่ waterfall เอง ก็มีประโยชน์ในมุมของมันเหมือนกัน
    ประเด็นปัญหาน่าจะอยู่ตรงที่ .. เราหวังว่า เราเลือกใช้อะไรซักอย่าง ไม่ว่าจะเป็น process, technology, หรือ standard แล้วปัญหาที่มีมันจะหมดไปทันที
    แต่ในความเป็นจริงแล้ว ไม่ว่าเราจะใช้ development approach แบบไหน ปัญหาอย่าง “scope creep” หรือ bad design มันก็จะยังมีอยู่ เพียงแต่เราจะใช้สิ่งที่เราเลือกมาป้องกันหรือว่าแก้ไขมันได้หรือเปล่า
    ผมคิดว่า ตัวอย่างที่ชัดเจนคือ ก่อนที่จะมี software development process กัน เรามีปัญหาอยู่หลายอย่าง
    พอมีคนคิด waterfall model ซึ่งทำให้การทำงา่นเป็นกระบวนการชัดเจน มีการแบ่งขั้นตอน มีการตรวจสอบ .. เราก็หวังว่า เราจะใช้ waterfall แล้ว ปัญหาทุกอย่างมันจะหมดไป
    เช่นเดียวกับปัจจุบันที่เราหวังว่าเมื่อใช้ CMMI หรือ Agile หรือ (..จงเติมคำในช่องว่าง..) แล้วปัญหาทุกอย่างมันจะหมดไป

    ความเห็น โดย siroz — มกราคม 11, 2008 @ 11:08 pm

  13. อ่านจบนะคะ………แต่เมื่อวัดความเข้าใจ3/100 เหอ ๆ
    พอดี search คำว่า software engineering แล้วมาเจอบล็อคนี้เลยลองอ่านดูสรุปไม่รุเรื่องเลย คือตอนนี้จะไปสัมภาษณ์ตำแหน่ง Software Test แต่ไม่มีความรู้เลยเพราะตอนนี้เพิ่งจะทำงานเป็น web master อ่อนหัดอ่ะ

    ความเห็น โดย vovavex — มกราคม 16, 2008 @ 10:44 am

  14. ถ้าคุณไม่เคยเรียนหรือศึกษา Software Engineering มาก่อน มีแนวโน้มว่าเวลาฟังคนอื่นคุยกันเรื่องนี้แล้ว อาจจะไม่เข้าใจเลยว่าเค้าพูดกันเรื่องอะไร
    แม้แต่บางคนที่เคยเรียน แต่ไม่เคยทำงานจริง บางทีก็ไม่เห็นภาพเหมือนกันครับ
    มีคนเคยพูดกับผมว่า Software Tester นั้น สำคัญคือต้องมี attitude (ทัศนคติ) ที่ดีต่องาน … ประเด็นนี้ไม่สามารถแย้งได้เลย
    ขอให้โชคดีในการสัมภาษณ์งานครับ

    ความเห็น โดย siroz — มกราคม 17, 2008 @ 5:55 am

  15. อ่านจบแล้วครับ

    developer exp.5-10 year ผมก็เคยเจอโค๊ดก๋วยเตี๋ยวมาแล้ว ไม่ว่าจะไทย หรือเทศ
    ผมว่า มี dev ส่วนหนึ่งที่เขาไม่เรียนรู้ความเจ็บปวดในอดีต หรือไม่เค้าก็ไม่เคยมาแก้โค๊ดตัวเอง

    ย้ำนะครับ ว่าทั้งไทย ทั้งเทศ ผมเจอมาเป็นหมื่นบรรทัด netbeans syntax highlight ไม่ทำงานเลย

    ความเห็น โดย comx — กันยายน 23, 2008 @ 9:32 pm


RSS feed for comments on this post. TrackBack URI

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s

บลอกที่ WordPress.com .

%d bloggers like this: