เทคนิคการเขียนโปรแกรม 50 ข้อ

• 1.โปรแกรมแบบพอเพียง(ทำอะไรให้เล็กที่สุดเท่าที่เป็น ไปได้)

• 2.ทำสิ่งธรรมดาให้ง่าย ทำสิ่งยากให้เป็นไปได้

• 3.จงโปรแกรมโดยนึกว่าจะมีคนมาทำต่ออย่างแน่นอน

• 4.ระเบียบ กฏข้อบังคับ เชื่อมั่นไม่ได้แล้ว ถ้ามีเพียงหนึ่งโมดูลไม่ปฏิบัติตาม

• 5.ตัดสินใจให้ดีระหว่างความชัดเจน(clearance) กับ การขยายได้(extensibility)

• 6.อย่าเชื่อมั่น output จากโมดูลอื่น ถึงแม้เราจะเป็นคนเขียนเอง

• 7.ถ้าคนเขียนยังเข้าใจได้ยาก แล้วคนอ่านจะเข้าใจได้ยากกว่าแค่ไหน

• 8.ค้นหาข้อมูลสามวันแล้วทำหนึ่งวัน หรือจะทำสามวันแล้วแก้บั๊กตลอดไป

• 9.จงสร้างเครื่องมือ ก่อนทำงาน

• 10.อย่าโทษโมดูลอื่นก่อน โดยเฉพาะถ้าโมดูลอื่นเป็น OS และ Compiler

• 11.พยายามทำตามกฏ แต่ถ้ามีข้อยกเว้น ต้องมีอย่างหลีกเลี่ยงไม่ได้ แล้วประกาศและตะโกนให้ดังที่สุด

• 12.High cohesion Loose coupling. (ยึดเกาะให้สูงสุดในโมดูล และ เกาะเกี่ยวกับโมดูลอื่นให้น้อยที่สุด)

• 13.ให้สิ่งที่เกี่ยวข้องกันยิ่งมากอยู่ไกล้กันมากที่ สุด

• 14.อย่าเชื่อโดยไม่พิสูจน์

• 15.อย่าลองทำแล้วคอมไพล์ดู ถ้าเราไม่ได้คาดหวังผลลัพธ์อะไรไว้ (อย่างเช่นปัญหา index off by one)

• 16.จงกระจายความรู้เพราะนั่นคือการทำ Unit Test ระดับล่างสุด(ระดับความคิด)

• 17.อย่าเอาทุกอย่างใส่ใน UI เพราะ UI คือส่วนที่ Unit Test ได้ยาก

• 18.ทั้งโปรเจ็คต์ควรไปในทางเดียวกันมากที่สุด( Consistency )

• 19.ถ้ามีสิ่งที่ดีอยู่แล้วจงใช้มัน อย่าเขียนเอง ถ้าจำเป็นต้องเขียนเอง ให้ศึกษาจากข้อผิดพลาดในอดีตก่อน

• 20.อย่ามั่นใจเอาโค้ดไปใช้จนกว่าจะ test อย่างเพียงพอ

• 21.เอาโค้ดที่ test ไว้ที่เดียวกันกับโค้ดที่ถูก test เสมอ

• 22.ทุกครั้งที่แก้ไขโค้ดให้ run unit test ทุกครั้ง

• 23.จงใช้ Unit Test แต่อย่าเชื่อมั่นทุกอย่างใน Unit Test เพราะ Unit Test ก็ผิดได้

• 24.ถ้าต้องทำอะไรที่ซ้ำกันมากกว่าหนึ่งครั้ง ก็เพียงพอแล้วที่จะแยกโค้ดส่วนนั้นออก

• 25.ทำให้ใช้งานได้ก่อน แล้วค่อย optimize และถ้าไม่จำเป็น อย่าoptimize

• 26.ยิ่งประสิทธิภาพเพิ่ม ความเข้าใจง่ายจะลดลง

• 27.ใช้ Design Pattern ที่เป็นที่รู้จักจะได้คุยกับใครได้รู้เรื่อง

• 28.อย่าเก็บไว้ทำทีหลัง ถ้ายังไงก็ต้องทำ

• 29.MutiThreading ไม่ใช่แค่การเพิ่มประสิทธิภาพ แต่มันมาพร้อมกับ Concerency, Deadlock, IsolationLevel, Hard to debug, Undeterministic Errors.

• 30.จงทำอย่างโจ่งแจ้ง

• 31.อย่าเพิ่ม technology โดยไม่จำเป็น เพราะนั่นทำให้โปรแกรมเมอร์ต้องวุ่นวายมากขึ้น

• 32.จงทำโปรเจ็คต์ โดยคิดว่าความเปลี่ยนแปลงเกิดขึ้นได้เสมอ

• 33.อย่าย่อชื่อตัวแปรถ้าไม่จำเป็น เดี๋ยวนี้ IDE มันช่วยขึ้นเยอะแล้วไม่ต้องพิมพ์เองแค่ dot มันก็ขึ้นมาให้เลือก

• 34.อย่าใช้ i, j , k , result, index , name, param เป็นชื่อตัวแปร

• 35.ทำโค้ดที่ต้องสื่อสารผ่านเครือข่ายให้คุยกันน้อยท ี่สุด

• 36.แบ่งแยกดีดี ระหว่าง Exception message ในแต่ละเลเยอร์ ว่าต้องการบอกผู้ใช้ หรือ บอกโปรแกรมเมอร์

• 37.ที่ระดับ UI ต้องมี catch all exception เสมอเพื่อกรอง Exception ที่ลืมดักจับ

• 38.ระวัง คอลัมภ์ allow null ใน database ดีดี ค่า มัน convert ไม่ได้

• 39. อย่าลืมว่า Database เป็น global variable ประเภทหนึ่ง แต่ละโปรแกรมที่ติดต่อเปรียบเหมือน MultiThreading ดังนั้นกฏของ Multithreading ต้องกระทำเมื่อทำงานกับ Database

• 40.ระวังอย่าให้ logic if then else ซ้อนกันมากมาก เพราะสมองคนไม่ใช่ CPU จินตนาการไม่ออกหรอกว่ามันอยู่ตรงไหนเวลา Debug (ถ้ามากกว่าสามชั้นก็ลองคิดใหม่ดูว่าเขียนแบบอื่นได้ มั้ย)

• 41.ระวังอย่าให้ลูปซ้อนกันมากมาก ไม่ใช่แค่เรื่องความเร็วอย่างเดียว เวลา Debug เราคิดตามมันไม่ได้ (ถ้าเกินสามชั้นก็ไม่ไหวแล้ว)

• 42. อย่าใช้ Magic Number ใน Code เช่น if( controlingValue == 4 ) เปลี่ยนไปใช้ Enum ดีกว่า เป็น if( controlingValue == ControllingState.NORMAL ) เข้าใจง่ายกว่ามั้ย

• 43.ถ้าจะเปรียบเทียบ string Trim ซ้ายขวาก่อนเสมอ

• 44.คิดหลายๆ ครั้งก่อนใช้ Trigger

• 45.โปรแกรมเมอร์คือห่วงโซ่สุดท้ายของมลพิษทางความซับ ซ้อน ดังนั้นหา project leader ดีดีแล้วกัน

• 46. มนุษย์ฉลาดกว่าคอมพิวเตอร์ การเขียนโปรแกรมก็คือการสอนให้คอมพิวเตอร์ฉลาดได้เหม ือนเรา (มนุษย์ฉลาดกว่าคอมพิวเตอร์จริงๆนะ) Reply With Quote

• 47. จงควบคุมคอม มิใช่ให้คอมควบคุมเรา เราต้องสั่งให้คอมทำงาน ไม่ใช่ให้เราทำงานตามคอมสั่ง

• 48. อย่าปล่อยให้ข้อจำกัดของคอม มาจำกัดความคิดของเรา [คอมไม่ดีเปลี่ยนเครื่องเลย 55+]

• 49. ยอมรับความคิดของผู้อื่น แต่อย่าออกจากกรอบของตนเอง

• 50. หมั่น Save โปรแกรมไว้อย่าสม่ำเสมอ ก่อนที่จะไม่มีโอกาส Save [จะให้ดี Save เป็นแต่ละ Version เลย]

ขอขอบคุณเป็นอย่างสูงที่เข้ามาเว็บไซล์ของเรา นะครับ/นะคะ