on 12/08/09 23:31
Tags:
สวัสดีครับทุกท่าน หลังจากที่เกรียนในนี้เรื่อง MS Windows มาแล้ววันนี้ขอมาเกรียนเรื่อง programing บ้างครับ จากหัวข้อเลยตอนนี้ผมกำลัลงรู้สึกว่ามีปัญหาในการพัฒนาโปรแกรมจากผู้ร่วมงานด้วยข้อหาอะไรที่เขาสรรหามาถาม แต่จากมุมมองของผมสรุป "เขียนโปรแกรมไม่ Geek"
ผมไม่แม่นสักเท่าไหร่ว่า Geek ต้องมีคุณสมบัติอย่างไร แต่มีข้อหนึ่งที่ผมเชื่อว่าเป็นหนึ่งในนั้นคือ "Geek ต้องทำอะไรที่ยุ่งยาก หรือถ้าไม่ยาก ก็มันให้มันดูยุ่งยาก"
เรื่องมันก็มากหรอกครับ ผมเป็นโปรแกรมเมอร์ผู้อ่อนด้อยคนหนึ่งรับฟังทุกความคิดเห็นครับ แต่แบบนี้รู้สึกว่าผมรับไม่ได้ 1. สมมุติว่าโปรแกรมมันมี Input 14 แบบ (ต่างกันแค่ parametor) มี Output 14 แบบ (ต่างกันแต่ผล query) ผมเขียนแค่ Class เดียว Method เดียว มันก็ได้ตามความต้องการ พระคุณท่านบอกเมนเทนยาก ตอนแรกบอกจะเอา 14 Method แต่หลังๆ บอกล่อมัน 14 Class เลย -> เขียนผิดที่เดียวอีก 13 ที่ไม่เสีย 555 แต่ update ทีต้องไล่วาง 14 รอบ แล้ว debug ล่ะ 2. สไตล์การเขียนโปรแกรมของผมเวอร์ชั่นแรกโค้ดจะดูยาวๆ ครับ แต่เวอร์ชั่นต่อๆ มา นอกจากการ debug แล้วโค้ดจะหดลงโดยที่ output ยังเหมือนเดิมอย่างล่าสุดลดโค้ดจากเกือบพันเหลือ 250 บรรทัด เถียงกันเป็นวรรคเวรเรื่องเมนเทนกับการต่อยอดอีกละ->ผมอยากว่าโค้ดสั้นกับโค้ดยาวอันไหนมันไล่ง่าย ต่อยอดง่ายกว่ากัน 3. ไม่รู้ว่าผม art หรือพวกเขา art กันแน่ จากสองข้อข้างบนตอนนี้อาจลามไปถึง Libraryของผมที่ตอนนี้ใช้แทนการไปไล่ copy แปะตอนจะใช้ช้ำกับและ function AJAX มันหดลงจากเป็น 10+ function เหลือแค่ 1 function แบบนี้ก็ยังเอามาเป็นเรื่องเป็นราวได้ ตอนโค้ดยาวผม debug แต่ละอันกินเวลาเป็นวันก็ด่า พอหดโค้ดลงก็ด่าว่าเมนเทนยาก ต้องแยกสิ ง่าย เอ่อ
ผมรู้สีกปวดหัวจริงๆ กับ geek แบบนี้หรือว่า geek เทพๆ หรือการเขียนโปรแกรมขั้นเทพต้องเขียนยาวหรือไง มีกี่ output แยกเป็น module ให้หมดทั้งที่มันต่างกันแค่ parametor เนี่ยนะบอก ถ้าจะบอกว่าออกแบบมาใหญ่ตั้งแต่แรก แต่ทำแล้วโปรแกรมมันเถอะทะ debug อ๊วก ไม่ได้ดูนานแล้วไล่ไม่ถูก กาง DFD,UML ก็รู้ว่าต่างกันแค่นิดเดียวจะแยกมันทำไม ผิดที่ไม่ทำตามที่ออกแบบ ก็ output มันก็ได้เหมือนกันนี่
อ่า... ไอ้โค้ดที่ผมพูดมานี่เป็นอันที่ผมดูแลนะครับ ไม่ใช่ไปไล่หดโค้ดของคนในทีมแบบนั้นก็ไม่ดี อยากทราบว่าผมผิดอย่างไรหรือครับ แล้วผมจะยืนจะตามแนวทางของผมต่อไปดีไหม?
- 3088 reads
Comments
เข้ามาบ่นใช่ไหม ?
ถูกครับ บางทีก็อยากบ่นออก twitter นะแต่ว่ามันไม่ยาวนี่สิ
http://twitter.com/darkleonic
พูดยาก ต้องเห็นตัวอย่างโค้ดด้วยครับ
เรื่องแยกคลาสนี่ถ้าใช้คุณสมบัติ oop ช่วยไม่น่ามีปัญหา "update ทีต้องไล่วาง 14 รอบ"
Sent from my computer
โปรแกรมเมอร์เก่งๆ เค้าพยายามเขียนให้สั้นที่สุด แล้วทำงานได้มากที่สุด
ยิ่งถ้าโค้ดมันทำอะไรซ้ำๆกัน ถ้าฉลาดพอต้องคิดได้ว่า ควรจะเอามันไปเขียนทีเดียว แล้วเรียกใช้มัน ไม่ใช่ก็อปแปะเป็นหลายๆอัีน ไม่งั้นมันจะมี คลาส อินเตอร์เฟซ เจเนริค ไว้ทำมวยอะไร
ผมเห็นเทพ ในทุกวงการ จะต้องทำเรื่องยากให้ง่าย และทำเรื่องง่ายๆให้มีประสิทธิภาพ ไม่ว่าจะวงการอาหาร ศิลปะ วิศวกรรม ออกแบบ
โปรแกรมเมอร์คงไม่ได้วิเศษแหวกแนวอยู่วงการเดียวหรอกมั้งครับ
ผมไม่เข้าใจเพื่อนคุณเลย
My Blog
+1
ผมก็ชอบโค้ดสั้น ๆ ครับ มันดูแลง่าย ต่อยอดง่าย ยกเว้นจะเขียนมาแบบพิศดารจริง ๆ ทำให้คนมาทำต่องง แต่พิศดารแล้วเจ๋ง เราก็ควรศึกษาจากเขา ทีนี้มันก็เป็นปัญหาของ Documentation แทน
แต่พอดีว่าในวงการซอพท์แวร์มันมีศาสนาที่ชอบให้คนเขียนโค้ดยาว ๆ คิดเคสรอบด้าน จนลืมความเป็นวิศวะกรไป : The simplest is the best.
BioLawCom.De
XimpleSoft
+1 ชอบเขียน code สั้นๆ เหมือนกันแต่ optimize แบบอ่านไม่รุ้เรื่องก็พยายามไม่เขียนครับ
+1 สั้น เข้าใจง่าย ก็ดีแล้วหนิ แล้วเกี่ยวอะไรกับ Greek ไม่ Greek งง?
<mOkin>ไม่รู้โลกกว้างไป หรือใจฉันแคบลง<mOkin/>
<@mOkin>Every thing that has a beginning has an end.<mOkin/>
ขอบ่นต่อหน่อยว่า จากสภาพแบบนี้ นี่ไม่มีการวางแผนออกแบบโปรแกรมเลยเหรอครับ ว่าจะทำคลาสยังไง จะมีคลาสอะไร ทำงานอะไรได้บ้าง
การออกแบบแล้วตกลงกันก่อนเขียนจริงก็เป้นเรื่องสำคัญนะ
My Blog
ของแบบนี้ไม่รู้นะ โค้ดจะยาวจะสั้นมันก็แล้วแต่ความเหมาะสมมากกว่าครับ ต้องว่ากันไปตามเหตุผลของแต่ละคน ก็ต้องคุยกันด้วยเหตุผลครับ แต่ถ้ามีคนไม่ฟังเหตุผล ไม่ยอมรับความคิดเห็นของผู้อื่น ก็วงแตกครับ
I will change the world, to the better day.
I will change the world, to the better day.
เขียนคลาสหลัก แล้วคลาสลูกไปใช้งานเวลาแก้ พยายามทางแก้ที่คลาสหลัก เคยเจอกรณีอย่างนี้มาบ้าง รำคาญมาก แต่ก็ช่างๆ เขียนไป ว่างๆจะกลับไปทบทวน oop + technic อีกรอบครับรู้สึกว่าห่างๆ มานานแล้วเขียนตามใจมากไป
คุณมีปัญหากับนิยามของคำว่า Geek มากกว่า
ผมว่า Geek = คนที่รู้ลึกรู้จริง
ดังนั้น ไอ้ที่คุณเจอ (หรือคุณเข้าใจไปเอง) นั้น
มันคือพวกปลอมตัวมาเป็น Geek มากกว่าครับ
(พวกปลอมตัวเป็น Geek จะมีอย่างนึงที่เหมือนๆ กัน
คือ ego จัด, ไม่ฟังความเห็นคนอื่น, กรูถูกของกรูคนเดียว
ก็ลองกลับไปอ่านที่คุณเขียนละกัน
ดูว่าใครที่เป็นแบบนั้นบ้าง)
Geek ก็มีความหมายในทางไม่ดีซะเยอะนะครับ
แต่บางคนก็ชอบที่จะถูกเรียกแบบนั้นนะ
LongSpine.com
LongSpine.com
ผมคนนึงล่ะที่ไม่ชอบ
ปล. ความหมายใน Dic
geek (กีค) n. นักเล่นปาหี่,บุคคล,เจ้าหมอนี่, บุคคลที่มีความรู้ทางคอมพิวเตอร์สูงมาก แต่ก็ไร้ประโยชน์ เพราะมักจะเป็นประเภทไม่ชอบให้ความช่วยเหลือใคร
+1 ไม่เคยเห็นว่า geek จะทำอะไรถึกๆ จำพวก copy + paste โดยเฉพาะการออกแบบ ที่จะดูหรูอย่างยิ่ง
Input 14 แบบ ถ้าเป็นผมจะเขียนให้มันเป็น 1 Class 14 Method อ่ะ ถ้ามันเจ๊งก็ไปดู Class เดียวเลยแล้วไล่เอา เขียนยัดลงไปได้ยังไง 1 Method เหอะๆ
แต่จนมาถึงตอนนี้ผมก็ไม่เข้าใจคำว่า Geek มันแปลว่าอะไรกันแน่ ตอนเรียนป.ตรี จนจบแล้วก็ยังไม่มีใครเรียกคนเขียนโปรแกรมเก่งกว่า Geek สักคน (สงสัยบ้านนอกเกินไป)
เหตุผลที่ Method เดียวก็ออกได้เพราะผมอ่านจากที่ออกแบบมามันต่างที่ parametor กับ sql ที่พ่วงท้ายเท่านั้นเองครับที่เหลือแทบจะโคลนกันเลย
http://twitter.com/darkleonic
ขึ้นอยู่กับว่าจะเขียนไห้ใครมากกว่ามั้งครับ ผมเขียนใช้เองก็เน้นสั้นๆ เร็วๆ อุ๊ป เอิ๊ป อะไร ไม่สนใจ
ใช้ OS หรือ mac เพื่อเข้าสังคม เป็นค่านิยมที่ผิด
ผมว่า ถ้าเป็นประเด็นเรื่อง "การมัวแต่เถียงประเด็นปลีกย่อยที่ไม่ได้สร้างมูลค่าเพิ่ม" การที่มาบ่นเถียงกับเพื่อนอย่างนี้ก็เป็น geek นะครับ
ถ้าเทียบกันกับเรื่องวุฒิภาวะ คนที่ด่าคนอื่น หรือบ่นคนอื่น ว่าไม่มีวุฒิภาวะ คนนั้นเองแหละครับที่ไม่มีวุฒิภาวะ (ถ้ามีวุฒิภาวะต้องรู้จักพูดคุย เจรจา ทำความเข้าใจซึ่งกันและกัน ไม่ใช่บ่นหรือด่าน่ะนะ)
ไว้เราเป็นหัวหน้างาน จะจัดการยังไงก็จัดการไป แต่ตอนนี้ ผมว่าเขาว่าไงถ้ามันไม่ได้เสียหายมาก ก็ตามเขาไปเถอะครับ มันก็ work เหมือนกันนี่ อย่ามัวแต่คิดเรื่องเล็กๆน้อยๆเลยครับ ไว้ถ้ามันจะำทำให้ล่มจริงๆค่อยว่ากันเถอะ การทำงานให้มีเอกภาพในทีม มันก็เป็นประเด็นที่มีผลเหมือนกันนะ ถ้าคุณทำไม่เหมือนเขา บางทีถ้าวันที่คุณไม่อยู่ คนอื่นมาดู เห็นว่ามันไม่ค่อยเหมือนคนอื่น มันก็ยุ่งยากได้เหมือนกันนะครับ นี่เป็นประเด็นหนึ่งของเรื่อง team work นะ เอ้า คุณเป็น team player หรือเปล่า ใจเย็นๆนะ ชิวๆบ้าง
หรือบางที เราอาจจะยังไม่เข้าใจตัวแปรบางอย่างก็ได้
ผมว่าเขาบอกให้ทำแยกเป็น 14 อันก็ดีนะ ถ้าว่ากันในเชิง risk management ถ้าตอนนี้มันต่างกันแค่ หัวท้าย มันก็ดีไป แต่ถ้าเกิดต่อไปวันหนึ่ง spec มันเปลี่ยน ทำให้แต่ละ case เกิดต่างกันอย่างมากขึ้นมาล่ะ? (spec เปลี่ยน เป็น risk อย่างหนึ่งที่พบบ่อยๆนะ ยังไงก็ต้องเตรียมรับไว้เสมอ) ถ้าเป็น method เดียว อาจจะปวดหัวในการทำความเข้าใจมาก จะแก้บรรทัดนึงเพื่อ case นึงก็ต้องมานั่งนึกว่า จะกระทบ case อื่นอีก 13 อันบ้างหรือเปล่า แยกเป็น 14 อันไปเลยง่ายดี ทนต่อความเสี่ยง ถ้า spec เปลี่ยนเฉพาะกรณี ก็แก้ได้สบายใจทีละอัน ไม่ต้องมาคอยระแวงว่าจะกระทบใคร
แบบนี้ก็ ok มะ? เอาน่า
+1
LongSpine.com
LongSpine.com
+2
ผมไม่พยายามเออออหม่อหมกกับเจ้าของกระทู้นะ จะเสนออะไรที่ต่างบ้าง จะได้ดูหลายๆมุม คิดเหมือนกันหมดมันน่าเบื่อ ถ้าตายก็ตายตามกันหมด มันไม่ใช่การยึดคำตอบใดคำตอบหนึ่ง แต่เป็นการมองให้รอบ
พระคุณท่านบอกเมนเทนยาก เราพยายามทำความเข้าใจสิ่งที่เขาพูดแล้วหรือยัง หรือยึดแต่ความคิดตัวเองตัดสินด้วยกรอบของตัวเองไปแล้วเลยไม่ฟัง ลองลดทิฎฐิแล้วนึกดูดีๆ แต่เราพยายามทำความเข้าใจ แล้วรู้ว่ามันใช่ แล้วได้รู้เรื่องใหม่ๆ มันก็ดี หูตากว้างไกลขึ้น เก่งขึ้น แต่ึถึงมันไม่ใช่ เราก็ควรเป็น 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 ของเราในอนาคตอยู่ก็ได้ ทีหลังควรฟังคนอื่นและรู้จักถามเขาให้มากกว่านี้ครับ
เห็นรู้สึกจะพยายามคิดตรงข้ามมาก ก็ไม่ว่าอะไรนะครับ แต่ขอเถียงข้อนึง
จากสภาพนี้เหมือนคนสั่งงานน่าจะอาร์ทตัวพ่อมากกว่านะครับ การดีบั๊กโค้ดยาวๆมันก็จะเสียเวลา ตัวเองเป็นคนสั่งให้เขียนโค้ดยาวๆ แต่พอคนอื่นดีบั๊กช้าก็บ่นก็ด่า จะแก้ให้สั้นลง ง่ายขึ้น ก็ไม่ได้
เห็นคุณมองว่าเจ้าของกระทู้งี่เง่า ไม่คิดจะเข้าใจเหตุผลเพื่อนร่วมงาน ผมสงสัยว่าคุณ "เชื่อ" จริงๆรึเปล่าว่าเจ้าของกระทู้ไม่ได้พยายามคิดและหาเหตุผลแล้ว และ "เชื่อ" จริงๆหรือว่าเพื่อนร่วมงานของเขา มีเหตุผลที่ชัวร์และแน่นอน
ผมเข้าใจว่าคุณพยายามคิดไปอีกทางนึงให้คานน้ำหนักสองด้าน แต่ขอพูดตรงๆว่าผมรู้สึกว่า คุณก็ดูถูกเจ้าของกระทู้เกินไปนิดนะครับ
My Blog
ก็คนละมุมครับ เราไม่รู้หรอกครับว่าความจริงเป็นไง คนนั้นผิด คนนี้ผิด หรือว่ามีส่วนผิดทั้งคู่ ในกระทู้นี้เราได้แต่ฟังด้านเดียว เวลาเราฟังใคร เขาก็จะพูดเฉพาะมุมของเขา ที่เขาได้ประโยชน์ เป็นปกติของมนุษย์ครับ
แม้แต่ความจริงเดียวกัน คนที่มีมุมไม่เหมือนกัน ก็จะมีความคิดเห็นที่ต่างกันได้
ก็แค่ตั้งคำถามเผื่อคิดในมุมตรงข้ามบ้าง ก็แค่นั้น เพราะพอดีเหมือนจะเทใจมาข้างเดียวหมดแล้ว ไม่ได้ตั้งใจจะดูถูกความเป็นมนุษย์ของเจ้าของกระทู้ครับ
ก็ถ้าเห็นว่าตรงไหนที่ใช่ ก็หยิบไปใช้ได้เผื่อจะเป็นประโยชน์ครับ แต่ถ้าเห็นไม่เหมือน ก็แล้วแต่มุมมอง เราก็แค่แลกเปลี่ยนความคิดเห็นกัน ไม่มีอะไรต้องโกรธหรือเกลียดกันครับ
ก็ไม่ได้จะโกรธหรือเกลียดอะไรครับ แต่ผมรู้สึกว่า ความหมายของคำที่คุณใช้ ออกจะแรงเกินไป(รึเปล่า?)
จึงอยากบอกให้ทราบ
My Blog
ไม่น่าเชื่อว่า Thaina จะพูดแบบนี้ได้ :O (เพราะเห็นว่านายก็เป็นคนพูดแรงไม่ไว้หน้าใครเหมือนกัน )
ผมว่าไม่ได้มีอะไรแรงนะ
ผมไม่ได้บอกว่าทุกอย่าง *ต้อง* เป็นตามที่ผมเขียนนะครับ แต่แค่ลองเสนอสิ่งที่ "อาจจะ" เป็นไปได้ ในอีกด้านหนึ่ง ให้ลองพิจารณาดู เพราะเราไม่รู้ว่าอะไรคือข้อเท็จจริงกันแน่ เราได้แต่ฟังความข้างเดียว เราไม่มีใครสามารถตัดสินฟันธงอะไรได้ทั้งนั้นแหละ
อีกอย่างหนึ่ง ผมไม่ได้บอกว่าเจ้าของกระทู้งี่เง่านะครับ อ่านดูดีๆ เป็นคำที่เขาใช้กับเพื่อนร่วมงานเขามากกว่า เพราะเขาพูดอย่างเดียวว่าเพื่อนร่วมงานไม่มีเหตุผลเลย เขาถูกคนเดียว คำที่ผมใช้กับเจ้าของกระทู้คือ อาจจะ "ไม่รู้"
ผมว่าคำว่า "ไม่รู้" มันไม่ได้มีความหมายดูถูกอะไรมาก ผมว่ามันเป็นแง่ดี ถ้า *สมมติ* มันเป็นกรณีที่ผมว่าจริงๆ (ใช่ เราแค่เสนอสิ่งที่ *อาจจะ*เป็นไปได้ เพราะเราไม่รู้ว่าข้อเท็จจริงคืออะไร เราไม่ได้อยู่ในเหตุการณ์) เราไม่ต้องรู้สึกอาย หรือสิ้นหวังว่า ฉันผิด ฉันควรตาย นั่นไม่ใช่เป้าหมายของคำนี้ เราแค่ไม่รู้ เราไม่ได้ชั่วร้ายโดยเจตนา นั่นหมายความว่า เราสามารถแก้ผิดให้เป็นถูกได้ นี่เป็นโอกาสที่ดีที่เราจะได้เรียนรู้ และเติบโตขึ้น เป็นเรื่องน่ายินดี
แต่ก็แล้วแต่มุมมองครับ เรามีสิทธิ์จะคิดกันได้ตามแต่มุมของละคน และส่วนตัวก็คิดว่า มันก็ไม่ได้เป็นประเด็นที่จะต้องเถียงเอาเป็นเอาตายอะไรกัน ไม่ได้มูลค่านัก
มาศึกษาวิธีการตอบครับ และผมไม่คิดว่าคุณ bossalove พูดจารุนแรงและดูถูกเจ้าของกระทู้แต่อย่างใดเลยครับ เป็นการแสดงความคิดเห็นอย่างหนึ่ง ซึ่งเป็นการให้เกียรติกับคุณ darkleonic ซึ่งเป็นเจ้าของกระทู้ และบุึคคลที่สามที่คุณ darkleonic พูดถึง
เมื่อเกือบสิบปีก่อน ผมเคยรู้สึกแบบคุณ darkleonic เวลาทำงานกับทีมใหญ่ๆ (ผมไม่ทราบว่าคนในทีมที่คุณ darkleonic กล่าวถึงมีบทบาทอย่างไร ซึ่งอาจจะคนละกรณีกับผม) ในทีมจะมีบุคคลที่เป็นหัวหลักหัวตอของทีมไม่กี่คนซึ่งกำหนดวิธีการหลายๆอย่างในการดำเนินงาน หลายอย่างผมไม่เห็นด้วย และแม้กระทั่งผมเสนอความคิดเห็นของผมแล้วเขาไม่รับฟัง หรือแม้แต่รับฟังแต่เขาก็ไม่เอาไปใช้ ซึ่งอาจจะเป็นเรื่องทางจิตใจก็ได้ว่า หากเราทำในสิ่งไม่ชอบหรือไม่เห็นด้วย ย่้อมทำให้ไม่มีความสุขในการทำงาน
แต่หากมองในอีกมุมก็คือ เขามีประสบการณ์มากกว่าผม แม้คนประสบการณ์มากกว่่าใช่ว่าจะถูกไปทั้งหมด แต่อย่างน้อยที่สุด เขามีเทคนิคต่างจากผมและผมก็ได้เรียนรู้เทคนิคใหม่ๆจากพวกเขามาไม่มากก็น้อยครับ และได้เปรียบเทียบกันให้เห็นกันว่าวิธีที่ผมมีและวิธีที่เขามีต่างกันเช่นไร อีกกรณีคือ เรื่องธรรมเนียมและวิธีที่บริษัทหนึ่งๆใช้มานมนาม สร้างความสำเร็จให้กับพวกเขา พวกเขาก็ไม่อยากเปลี่ยน อีกทั้งคนในทีมสามารถเข้าใจร่วมกันได้ทำให้คุยภาษา(งาน)เดียวกัน
เมื่อถึงคราวที่เราได้ก้าวไปในจุดที่พวกเขายืนอยู่ ได้เป็นหัวหลักของทีม ตอนนั้นแล้ว เราก็มีบทบาทได้โชว์ฝีมือบ้างแล้วครับ หรือไม่ก็มีบริษัทของตัวเองก็เป็นอีกวิธีครับ ดูแบบ @sugree ก็ได้ครับ ได้ทำอะไรที่ตนเองอยากทำครับ :)
My Blog / hi5 / Facebook / Follow me
My Blog / Follow me
พยายามคิดรอบด้าน คนละประเด็นกับการเชื่อหรือไม่เชื่อ เคารพหรือไม่เคารพนะครับ ยิ่งในกรณีนี้เรามีข้อมูลด้านเดียวด้วย
ผมเป็นศิลปินทำงานศิลปะด้วยการเขียนโปรแกรม
เขียนตั้งนาน ตามท่านนี้ดีกว่า ผมก็ยังไม่ใช่ผู้ชำนาญ แต่ผมมองว่า มันเป็นข้อโต้แย้งระหว่าง OOP กับ Struct Progamming มากกว่า
"ผิดที่ไม่ทำตามที่ออกแบบ ก็ output มันก็ได้เหมือนกันนี่"
อันนี้ผิดแน่นอน ออกแบบแล้วก็ต้องทำตามที่ออกแบบ ยกเว้นแบบนั้นทำไม่ได้หรือทำแล้วเกิดปัญหา(ออกแบบผิด)ซึ่งก็ต้องไปแก้แบบก่อน แล้วทำตามแบบใหม่อีกที เหตุผลอะไรลองนึกดู
คนหนุ่ม ใจร้อน ทำไปสักพักก็จะเย็นลง
+1 อันนี้เห็นด้วย บางครั้งถึงเราจะไม่เห็นด้วยกับการออกแบบ แต่มันออกแบบมางี้ ก็ต้องทำตาม ไม่งั้นมันก็ไม่ตรงกับเอกสาร หรือไม่งั้นก็ต้องไปคุยก่อนว่าเราอยากเปลี่ยน ก็ต้องเปลี่ยนเอกสารตามด้วย ถ้าเค้ายอมถึงทำได้
เดี๋ยวการเขียนโปรแกรมก็เป็น 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
http://jiramot.info
ความคิดเห็นผมต่อเรื่องนี้ครับ โค้ดสั้น vs โค้ดยาว
BioLawCom.De
XimpleSoft
เป็นผม ก็เขียน method แล้วทำ Overload เอาโดยรับตัว input ทั้ง 14 ตัวเป็น Object แล้ว parse object เวลาจะใช้งาน ขี้เกียจไปตามแก้หลายที่
แต่ยังสงสัยเหมือนกันว่า เอาอะไรมาวัดว่าเป็น Geek หรือไม่ มันไม่มีหน่วยวัดแหะ ที่บริษัทผมถ้าไม่มีหน่วยวัดอะไรชัดเจน ก็จะไม่สนแล้วแหล่ะ เก่งไม่เก่งไม่สน ทำงานส่งทันเวลาก่อน ม่ายงั้นโดนค่าปรับอาน
เล็ก..
สั้น..
เร็ว..
อือม์ ผมว่า ใหญ่ ยาว กะ นานๆ หน่อย ก็ดีนะ :P
กำเนิดที่ขา ควบคุมโดยเอว......
สำหรับผมไม่เคยสนใจวิธีการสนใจแต่ Output แต่ที่สำคัญที่ใช้มาตลอดต้องง่าย ใครดูก็เข้าใจสำคัญที่สุด เผื่อคนที่เขียนมันมีอันเป็นไปคนอื่นจะได้เอามาดูต่อได้แบบไม่งง
ขอดูโค้ดหน่อยครับ ถ้าเอามาโชว์ได้ก็จะดีมาก มาพูดโค้ดสั้นโค้ดยามดูง่ายไม่ง่าย มันแล้วแต่คนจริง ๆ เรื่องนี้
เอาเป็นว่าถ้ามีโค้ดมาดู ผมจะได้คอมเม้นต์ให้ บางทีคุณอาจจะถูก หรือเพื่อนรวมงานคุณอาจจะถูกก็ได้