ผมสงสัยว่าวิธีเขียนโค้ดของตัวเองถูกต้องตามหลักอนามัยหรือไม่
โดยเฉพาะเวลาที่ผมต้องกลับมาแก้พวกโค้ดที่ ใช้ซ้ำๆ หลายหน ให้กลายเป็น Method ที่ใช่ร่วมกัน
คือผมจะค่อยๆคิดถึงว่าเป้าหมายของสิ่งที่จะเกิดในขั้นตอนนั้นๆคืออะไร แล้วก็เขียนลงไปให้ทำงานได้
แต่พอมันทำงานได้แล้วบางทีก็พบว่า ตัวเอง Violate MVC pattern มั่ง
(เช่นเผลอให้ ViewController ไปเรียกค่า myModel.value แล้วแก้ไข value ใน ViewController)
หรือที่บ่อยที่สุดคือเขียนโค้ดให้สัมฤทธ์เป้าหมาย แต่พบว่ามันทำงานคล้ายๆเหมือนๆกับที่เราเคยเขียนไปแล้ว
-> ตอนผมเขียนโค้ดผมจะเขียน comment ลงเป็นนิยายกำลังภายในเล่าเรื่องว่ามีไรเกิดขึ้นมั่งเป็นภาษาคนก่อน
เขียนแบบนี้ลง method กลวงๆจนครบ
-> แล้วทำให้ method เป็นตัวละคร ว่านู่นไปทำอะไรตัวอื่น เช่น updateUI เกิดเมื่อยาม pickCard ถุกกด
-> แล้วก็ค่อยๆ implement method ตามนิยายกำลังภายในให้กลายเป็นโค้ดที่ทำงานได้
-> พอจบปุ๊ป ทำงานได้
-> พบว่าโค้ดซ้ำ ทำงานซ้ำ
-> พบว่า vilate pattern
-> ต้องกลับมาเขียนใหม่
-> บางทีลืมเขียนให้เป็น Public API กลายเป็น object ปิดตายต้องมาแก้
สงสัยว่าปรกติเขียนโค้ดกันเจอเรื่องพวกนี้เป็นปรกติรึปล่าวหรือผมมีปัญหาในการวางแผนเขียนโค้ดกันแน่
บางทีโค้ดไม่เป็น Abstract แต่พอมีการแตกแขนงคลาสออกไปผมมาแก้ใหม่ให้เป็น Abstract
ทีหลัง เป็นวิธีที่ถูกต้องหรือไม่
ผมว่า เป็นปกตินะครับ
figgaro Sat, 19/07/2014 - 12:41
ผมว่า เป็นปกตินะครับ โปรแกรมเมอร์ที่ดีเมื่อพบว่าจุดไหนที่เราเคยเขียนไปไม่ดีหรือ ควรย่อหรือทำซ้ำแล้วนำมารวมกันได้ก็ควรจะทำการ Refactor Code ซึ่งผมทำอยู่เป็นประจำ ทำไมหนะหรือ เพราะว่าบางครั้งที่เราเขียนโค๊ดไปสมาธิเราก็จดจ่ออยู่กับแต่ เรื่องวัตุประสงค์ของฟังก์ชั่นการทำงานนั้นจึงทำให้บางทีไม่ได้คิดให้มันครอบคลุม อาจจะด้วยเรื่องของเวลา และอื่นๆ แต่เมื่อใดที่กลับมา ตรวจพบแล้วเห็นว่าผิดหรือทำอีกแบบจะดีกว่า ก็ควรทำ ส่วนคนที่เห็นแล้วปล่อยผ่านไปผมถือว่าชุ่ย
Refactor Code บ่อย ๆ ครับ
adente Sat, 19/07/2014 - 22:13
Refactor Code บ่อย ๆ ครับ เพราะตอนเวลาที่เราเขียนนั้น โค้ตตรงนั้นมันแก้ปัญหาได้ดี แต่พอในอนาคต business model เปลี่ยน โค้ตเดิมดันใช้ไม่ได้ คนในทีมก็ดันเขียนโค้ตอีกชุด(เพราะอาจไม่อยากยุ่งโค้ตชาวบ้าน หรือไม่รู้ว่าแก้แล้วจะกระทบตรงใหนบ้าง หรืออะไรก็แล้วแต่)มาเพื่อรองรับซึ่งไม่ต่างอะไรมากกับโค้ตเก่าๆเลย ถ้าลูปแบบนี้เกิดขึ้นบ่อยๆ ก็จะกลายเป็นปัญหาแน่นอนในอนาคต
ถ้าเป็นโค๊ดโปรเจคตัวเองนี่ทำแ
mr_tawan Sun, 20/07/2014 - 16:10
ถ้าเป็นโค๊ดโปรเจคตัวเองนี่ทำแทบจะตลอดเวลาครับ แต่ไม่ใช่ว่าเปลี่ยนไปเปลี่ยนมาไร้หลักเกณฑ์ไปเรื่อยๆ นะ ต้องมีหลักเกณฑ์กับโปรเจคตัวเองประมาณนึงด้วยเหมือนกัน
ส่วนถ้าเป็นที่ทำงานจะทำเฉพาะส่วนที่ได้รับมอบหมายในขณะนั้นครับ (ดูหมดก็ไม่ไหวหรอก โค๊ดเป็นร้อยเม็กเลย) เพราะว่าโค๊ดไม่มี Unit Test ถ้าไปแก้อะไรมากแล้วมันไม่มีเครื่องยืนยันได้ว่ามันจะกลับมาทำงานได้เหมือนเดิม
ปกติครับ และคุณเป็นคนนิสัยดี
waroonh Mon, 21/07/2014 - 11:05
ปกติครับ และคุณเป็นคนนิสัยดี ระดับนึงเลยหล่ะ ถ้าตามแก้แล้วใส่ comment จริง ๆ จัง ๆ นะครับ
จริง ๆ เรื่อง code กลางที่ทุกคนใช้รวมกันนะครับ
ทำมาร่วม 10 กว่าปีเนี่ย อยากฝากไว้นิดนึงว่าถ้าไม่ได้ขึ้น version 2 หรือมันเป็น package มาแล้ว
ผมว่า design - code แยกหน้าไปเลย ดีกว่านะครับ ให้มันมีปัญหาเป็นหน้า ๆ ไป code กลาง มีแค่ต่อ database พอแล้ว
ที่เจอปัญหาทุกวันนี้ ส่วนใหญ่คือ ตอน design ก็นึกไม่ออก กว่ากลางไม่กลาง
เอา business โยนใส่ code กลางบ้างอะไรบ้าง แก้ทีนึงไปโดนหน้าอื่นหรือเปล่าไม่รู้ เอกสารก็(ขี้เกียจ)ไม่มีเวลาเขียน ยุ่งวุ่นวายไปหมด
สุดท้ายก็เละ ทั้ง project
แล้วพอเละทั้ง project คราวนี้ ใครเจอ bug ก็จะ assign ให้คนนั้น เป็นคนแก้
หลายครั้งเข้า คราวนี้ใครอยากจะ report bug .. กันหล่ะครับจริงมั้ย ?
ท้ายสุด ก็ตัวใครตัวมัน ตลอด ...
จริงจังเลยนะ ช่วยๆกันหน่อยครับ โลกจะได้น่าอยู่ขึ้น
ถ้ามี Code สำหรับ Unit Test
Zew Tue, 22/07/2014 - 11:49
ถ้ามี Code สำหรับ Unit Test คุม
ก็ Refactor ไปเถิดจะเกิดผล :P
มาถูกทางแล้วครับ การเขียนโค้ด
bow_der_kleine Wed, 23/07/2014 - 23:36
มาถูกทางแล้วครับ
การเขียนโค้ดที่ดี ไม่ใช่เขียนมาปุ้บดีปั้บ แต่รู้ว่าอะไรดีไม่ดี หากรู้ว่าไม่ดีต้องรีบแก้ เอาเข้าจริง การแก้โค้ดไม่นานอย่างที่คนส่วนมากกังวล มันใช้เวลาน้อยมาก เมื่อเทียบกับการกลับมาไล่อ่านโค้ด
ส่วนเรื่องคอมเมนต์ ผมใช้หลักที่ว่า โค้ดที่ดีไม่ต้องคอมเมนต์ อ่านแล้วเข้าใจเลย หากเขียนแบบยังต้องมีคอมเมนต์คนอื่นถึงจะเข้าใจ แสดงว่ายังเขียนไม่ดีพอ เรื่องนี้ convention ที่ดีช่วยได้มาก