เข้ามาบ่นใช่ไหม ?

พูดยาก ต้องเห็นตัวอย่างโค้ดด้วยครับ

เรื่องแยกคลาสนี่ถ้าใช้คุณสมบัติ oop ช่วยไม่น่ามีปัญหา "update ทีต้องไล่วาง 14 รอบ"

โปรแกรมเมอร์เก่งๆ เค้าพยายามเขียนให้สั้นที่สุด แล้วทำงานได้มากที่สุด

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

ผมเห็นเทพ ในทุกวงการ จะต้องทำเรื่องยากให้ง่าย และทำเรื่องง่ายๆให้มีประสิทธิภาพ ไม่ว่าจะวงการอาหาร ศิลปะ วิศวกรรม ออกแบบ

โปรแกรมเมอร์คงไม่ได้วิเศษแหวกแนวอยู่วงการเดียวหรอกมั้งครับ

ผมไม่เข้าใจเพื่อนคุณเลย

ขอบ่นต่อหน่อยว่า จากสภาพแบบนี้ นี่ไม่มีการวางแผนออกแบบโปรแกรมเลยเหรอครับ ว่าจะทำคลาสยังไง จะมีคลาสอะไร ทำงานอะไรได้บ้าง

การออกแบบแล้วตกลงกันก่อนเขียนจริงก็เป้นเรื่องสำคัญนะ

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

I will change the world, to the better day.

เขียนคลาสหลัก แล้วคลาสลูกไปใช้งานเวลาแก้ พยายามทางแก้ที่คลาสหลัก เคยเจอกรณีอย่างนี้มาบ้าง รำคาญมาก แต่ก็ช่างๆ เขียนไป ว่างๆจะกลับไปทบทวน oop + technic อีกรอบครับรู้สึกว่าห่างๆ มานานแล้วเขียนตามใจมากไป

คุณมีปัญหากับนิยามของคำว่า Geek มากกว่า

ผมว่า Geek = คนที่รู้ลึกรู้จริง

ดังนั้น ไอ้ที่คุณเจอ (หรือคุณเข้าใจไปเอง) นั้น

มันคือพวกปลอมตัวมาเป็น Geek มากกว่าครับ

(พวกปลอมตัวเป็น Geek จะมีอย่างนึงที่เหมือนๆ กัน

คือ ego จัด, ไม่ฟังความเห็นคนอื่น, กรูถูกของกรูคนเดียว

ก็ลองกลับไปอ่านที่คุณเขียนละกัน

ดูว่าใครที่เป็นแบบนั้นบ้าง)

Input 14 แบบ ถ้าเป็นผมจะเขียนให้มันเป็น 1 Class 14 Method อ่ะ ถ้ามันเจ๊งก็ไปดู Class เดียวเลยแล้วไล่เอา เขียนยัดลงไปได้ยังไง 1 Method เหอะๆ

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

ขึ้นอยู่กับว่าจะเขียนไห้ใครมากกว่ามั้งครับ ผมเขียนใช้เองก็เน้นสั้นๆ เร็วๆ อุ๊ป เอิ๊ป อะไร ไม่สนใจ

ผมว่า ถ้าเป็นประเด็นเรื่อง "การมัวแต่เถียงประเด็นปลีกย่อยที่ไม่ได้สร้างมูลค่าเพิ่ม" การที่มาบ่นเถียงกับเพื่อนอย่างนี้ก็เป็น geek นะครับ

ถ้าเทียบกันกับเรื่องวุฒิภาวะ คนที่ด่าคนอื่น หรือบ่นคนอื่น ว่าไม่มีวุฒิภาวะ คนนั้นเองแหละครับที่ไม่มีวุฒิภาวะ (ถ้ามีวุฒิภาวะต้องรู้จักพูดคุย เจรจา ทำความเข้าใจซึ่งกันและกัน ไม่ใช่บ่นหรือด่าน่ะนะ)

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

หรือบางที เราอาจจะยังไม่เข้าใจตัวแปรบางอย่างก็ได้

ผมว่าเขาบอกให้ทำแยกเป็น 14 อันก็ดีนะ ถ้าว่ากันในเชิง risk management ถ้าตอนนี้มันต่างกันแค่ หัวท้าย มันก็ดีไป แต่ถ้าเกิดต่อไปวันหนึ่ง spec มันเปลี่ยน ทำให้แต่ละ case เกิดต่างกันอย่างมากขึ้นมาล่ะ? (spec เปลี่ยน เป็น risk อย่างหนึ่งที่พบบ่อยๆนะ ยังไงก็ต้องเตรียมรับไว้เสมอ) ถ้าเป็น method เดียว อาจจะปวดหัวในการทำความเข้าใจมาก จะแก้บรรทัดนึงเพื่อ case นึงก็ต้องมานั่งนึกว่า จะกระทบ case อื่นอีก 13 อันบ้างหรือเปล่า แยกเป็น 14 อันไปเลยง่ายดี ทนต่อความเสี่ยง ถ้า spec เปลี่ยนเฉพาะกรณี ก็แก้ได้สบายใจทีละอัน ไม่ต้องมาคอยระแวงว่าจะกระทบใคร

แบบนี้ก็ ok มะ? เอาน่า

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

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

เขียนผิดที่เดียวอีก 13 ที่ไม่เสีย 555 แต่ update ทีต้องไล่วาง 14 รอบ แล้ว debug ล่ะ - เรื่อง debug จะมี method เดียว หรือ 14 method ถ้ามันมี 14 case เราก็ต้อง test มัน 14 ทีอยู่ดี เพราะงั้น มี method เดียวไม่ได้ช่วย - การไล่วาง ทำครั้งเดียวจบไม่กี่นาที แต่เกิดมันเสียขึ้นมา จะเสียเวลาแก้เป็นวัน หรือถ้าแย่ๆเลยก็อาจจะงมเป็นเดือนแล้วก็ยังหาสาเหตุไม่เจอ แพงกว่ากันมาก

2. สไตล์การเขียนโปรแกรมของผมเวอร์ชั่นแรกโค้ดจะดูยาวๆ ครับ แต่เวอร์ชั่นต่อๆ มา นอกจากการ debug แล้วโค้ดจะหดลงโดยที่ output ยังเหมือนเดิมอย่างล่าสุดลดโค้ดจากเกือบพันเหลือ 250 บรรทัด เถียงกันเป็นวรรคเวรเรื่องเมนเทนกับการต่อยอดอีกละ->ผมอยากว่าโค้ดสั้น กับโค้ดยาวอันไหนมันไล่ง่าย ต่อยอดง่ายกว่ากัน โดยทั่วไปมันก็ใช่ เราก็ไม่ชอบ ยาวๆกันหรอก ดูแล้วตาลาย แต่ประเด็นของความอ่านง่าย และต่อยอดง่าย มันไม่ได้อยู่ที่จำนวนบรรทัดอย่างเดียว code สั้น แต่พิศดารเกินไป ไม่สื่อความหมายที่ตรงไปตรงมา เช่น a ^= b ^= a ^= b มันก็อ่านแล้วมึนกว่า temp = a; a = b; b = temp; ได้ การ organize โครงสร้างของ code ก็มีผลต่อความอ่านง่ายหรืออ่านยาก การที่มี dependency หรือ coupling มากไป อาจจะสั้นตรงนี้ แต่จะทำให้มันไปพันกับอย่างอื่นอีกมาก แทนที่จะอ่านจบตรงนี้ 250 บรรทัด กลายเป็นว่าอ่านตรงนี้ 100 บรรทัด แล้วต้องไปอ่านที่อื่นต่ออีก 10000 บรรทัด และเห็นภาพรวมยาก

ในกรณีนี้ที่คุณเจ้าของกระทู้เล่ามา ok เราได้ code สั้น อันนี้ดี แต่ไปเสียด้าน coupling อย่างมาก เรื่องความง่ายในการต่อยอด มันไม่ใช่แค่อย่างใดอย่างหนึ่ง แต่ต้อง weight ระหว่างกัน

ไม่รู้ว่าผม art หรือพวกเขา art กันแน่ จากสองข้อข้างบนตอนนี้อาจลามไปถึง Libraryของผมที่ตอนนี้ใช้แทนการไปไล่ copy แปะตอนจะใช้ช้ำกับและ function AJAX มันหดลงจากเป็น 10+ function เหลือแค่ 1 function แบบนี้ก็ยังเอามาเป็นเรื่องเป็นราวได้ ตอนโค้ดยาวผม debug แต่ละอันกินเวลาเป็นวันก็ด่า พอหดโค้ดลงก็ด่าว่าเมนเทนยาก ต้องแยกสิ ง่าย เอ่อ - คุณเจ้าของกระทู้ค่อนข้างไม่ยอมคนเหมือนกัน คนเขาพูดกันทั้งทีมแล้ว มีตัวเองแปลกแยกคนเดียว ไม่ลองฉุกคิดมั่งหรือครับ เขางี่เง่า หรือเรากันแน่ที่ไม่รู้อะไรเลย? คำตอบไม่ใช่การรีบด่วนตัดสินถูกผิด ไม่ใช่ฉันถูกเธอผิด แต่ให้ลองพยายามเข้าใจเหตุผลของเขาก่อน เราอาจจะได้เรียนรู้

กาง DFD,UML ก็รู้ว่าต่างกันแค่นิดเดียวจะแยกมันทำไม ผิดที่ไม่ทำตามที่ออกแบบ - ตอนนี้อาจจะเหมือนกัน แต่ถ้าเกิดมี spec เปลี่ยนขึ้นมาล่ะ? คือที่รวมกันนี่ รวมเพราะมันคือสิ่งเดียวกัน หรือเพราะเราชุ่ย เห็นมันหน้าตาคล้ายกันผิวเผินหน่อย ก็เหมารวมซะแล้ว ทั้งๆที่ความหมายมันต่างกัน มันจะทำให้เกิด relation/coupling ระหว่าง module ที่ผิดนะครับ - เราต้องทำตามที่ออกแบบ จะมาทำตามใจชอบไม่ได้ จะเป็นการสร้างปัญหาให้ผู้อื่น ทั้ง project manager, system analyst ฯลฯ เขาก็เขียนเอกสารอ้างอิงถึงสิ่งที่เราเขียนเหมือนกัน ถ้าเราไปทำไม่เหมือน มันก็จะกระทบเขา สร้างปัญหาให้เขานะครับ

อ่า... ไอ้โค้ดที่ผมพูดมานี่เป็นอันที่ผมดูแลนะครับ ไม่ใช่ไปไล่หดโค้ดของคนในทีมแบบนั้นก็ไม่ดี - อย่าลืมว่า เราอาจจะอยู่บริษัทนี้สักพักหนึ่ง อาจจะ 1-3 ปี แต่ project มันอาจจะเป็นปีๆกว่าจะเสร็จ และถึงส่งมอบแล้วผ่านไป 10 ปี อาจจะมีการขอร้องจากลูกค้าให้ช่วย update นิดหน่อย คนที่มาดูตอนนั้นอาจจะไม่เรา และอาจจะเปลี่ยนคนในทีมกันหลายรอบมาก ความเป็นเอกภาพและความสอดคล้องตามแผนระหว่างทุกฝ่าย เป็นเรื่องสำคัญมาก

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

"ผิดที่ไม่ทำตามที่ออกแบบ ก็ output มันก็ได้เหมือนกันนี่"

อันนี้ผิดแน่นอน ออกแบบแล้วก็ต้องทำตามที่ออกแบบ ยกเว้นแบบนั้นทำไม่ได้หรือทำแล้วเกิดปัญหา(ออกแบบผิด)ซึ่งก็ต้องไปแก้แบบก่อน แล้วทำตามแบบใหม่อีกที เหตุผลอะไรลองนึกดู

คนหนุ่ม ใจร้อน ทำไปสักพักก็จะเย็นลง

เดี๋ยวการเขียนโปรแกรมก็เป็น style แล้ว

แสวงหามิใช่เพราะรอคอย เชี่ยวชาญมิใช่เพราะโอกาส ชำนาญมิใช่เพราะโชคช่วย"ดังนี้แล้วลิขิตฟ้าหรือจะสู้มานะตน"chonlatee

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

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

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

ใจเย็น ๆ แล้วลองคิดใหม่ครับ

เวลาทำงานร่วมกันเป็นทีมขนาดแค่เรื่องการชื่อตัวแปร ชื่อคลาส เมธอด ยังมี Naming convention ที่ต้องตกลงกันก่อนเลย นับประสาอะไรกับ Coding style ที่ 10 คนเขียนก็ได้ 10 แบบ ถ้าไม่เป็นไปในแนวทางเดียวกันนี่ลำบากแน่ (โดยเฉพาะเมื่อคนเขียนไม่อยู่ซะแล้ว)

แล้วที่คุณกำลังพูดถึงนี่มันเป็นเรื่องระดับโครงสร้างเลยยิ่งต้องพิถีพิถัน

ถ้าทำงานคนเดียว One man show ก็คงไม่ต้องซีเรียสอะไร แต่ถ้าทำงานเป็นทีม ก็คงต้องทำใจ บางทีที่เราเขียนไปอาจไม่ได้เป็นแบบที่เราคิด คิดซะว่าลองเขียนด้วยรูปแบบอื่น ๆ เพื่อหาประสบการณ์ตรงน่าจะดีกว่า

ปล. จากที่อ่านที่คุณบ่นมาผมว่าเมื่อคุณได้เป็น senior ก็อาจจะมีคนมาบ่นคุณเหมือนกันนะผมว่า (^_^)

ลองไปดูพวก code ของโครงการ open source ดูครับว่าเขาเขียนกันแบบไหน เช่น พวก apache เป็นต้น ก็น่าจะได้ไอเดียลักษณะการเขียนที่เหมาะสม

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

http://jiramot.info

ความคิดเห็นผมต่อเรื่องนี้ครับ โค้ดสั้น vs โค้ดยาว

BioLawCom.De

เป็นผม ก็เขียน method แล้วทำ Overload เอาโดยรับตัว input ทั้ง 14 ตัวเป็น Object แล้ว parse object เวลาจะใช้งาน ขี้เกียจไปตามแก้หลายที่

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

เล็ก..

สั้น..

เร็ว..

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

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

เอาเป็นว่าถ้ามีโค้ดมาดู ผมจะได้คอมเม้นต์ให้ บางทีคุณอาจจะถูก หรือเพื่อนรวมงานคุณอาจจะถูกก็ได้