เห็นว่าน่าสนใจและดีมาก ๆ เลยนำมาลง (ช่วงนี้รู้สึกว่าตูไม่ได้เขียนเองเท่าไหร่เลยนะ -_-")
- โปรแกรมแบบพอเพียง (ทำอะไรให้เล็กที่สุดเท่าที่เป็นไปได้)
- ทำสิ่งธรรมดาให้ง่าย ทำสิ่งยากให้เป็นไปได้
- จงโปรแกรมโดยนึกว่าจะมีคนมาทำต่ออย่างแน่นอน
- ระเบียบ กฎข้อบังคับ เชื่อถือไม่ได้ถ้ามีเพียงหนึ่งโมดูลไม่ปฏิบัติตาม
- ตัดสินใจให้ดีระหว่างความชัดเจน (Clearance) กับการขยายได้ (Extensibility)
- อย่าเชื่อมั่น Output จากโมดูลอื่น ถึงแม้เราจะเป็นคนเขียนเอง
- ถ้าคนเขียนยังเข้าใจได้ยาก แล้วคนอ่านจะเข้าใจได้ยากกว่าแค่ไหน
- ค้นหาข้อมูลสามวันแล้วทำหนึ่งวัน หรือจะทำสามวันแล้วแก้บั๊กตลอดไป
- จงสร้างเครื่องมือ ก่อนทำงาน
- อย่าโทษโมดูลอื่นก่อน โดยเฉพาะถ้าโมดูลอื่นเป็น OS และ Compiler
- พยายามทำตามกฎ แต่ถ้ามีข้อยกเว้น ต้องมีอย่างหลีกเลี่ยงไม่ได้ ให้ประกาศและตะโกนให้ดังที่สุด
- High Cohesion Loose Coupling (ยึดเกาะให้สูงสุดในโมดูล และเกาะเกี่ยวกับโมดูลอื่นให้น้อยที่สุด)
- ให้สิ่งที่เกี่ยวข้องกันยิ่งมากอยู่ไกล้กันมากที่สุด
- อย่าเชื่อโดยไม่พิสูจน์
- อย่าลองทำแล้วคอมไพล์ดู ถ้าเราไม่ได้คาดหวังผลลัพธ์อะไรไว้ (อย่างเช่นปัญหา index off by one)
- จงกระจายความรู้เพราะนั่นคือการทำ Unit Test ระดับล่างสุด (ระดับความคิด)
- อย่าเอาทุกอย่างใส่ใน UI เพราะ UI คือส่วนที่ Unit Test ได้ยาก
- ทั้งโปรเจ็กต์ควรไปในทางเดียวกันมากที่สุด (Consistency)
- ถ้ามีสิ่งที่ดีอยู่แล้ว จงใช้มัน อย่าเขียนเอง ถ้าจำเป็นต้องเขียนเอง ให้ศึกษาจากข้อผิดพลาดในอดีตก่อน
- อย่ามั่นใจเอาโค้ดไปใช้จนกว่าจะ Test อย่างเพียงพอ
- เอาโค้ดที่ Test ไว้ที่เดียวกันกับโค้ดที่ถูก Test เสมอ
- ทุกครั้งที่แก้ไขโค้ดให้รัน Unit Test ทุกครั้ง
- จงใช้ Unit Test แต่อย่าเชื่อมั่นทุกอย่างใน Unit Test เพราะ Unit Test ก็ผิดได้
- ถ้าต้องทำอะไรที่ซ้ำกันมากกว่าหนึ่งครั้ง ก็เพียงพอแล้วที่จะแยกโค้ดส่วนนั้นออก
- ทำให้ใช้งานได้ก่อน แล้วค่อย Optimize และถ้าไม่จำเป็น อย่า Optimize
- ยิ่งประสิทธิภาพเพิ่ม ความเข้าใจง่ายจะลดลง
- ใช้ Design Pattern ที่เป็นที่รู้จักจะได้คุยกับใครได้รู้เรื่อง
- อย่าเก็บไว้ทำทีหลัง ถ้ายังไงก็ต้องทำ
- Multithreading ไม่ใช่แค่การเพิ่มประสิทธิภาพ แต่มันมาพร้อมกับ Concurrency, Deadlock, Isolation Level, Hard to Debug, Undeterministic Errors
- จงทำอย่างโจ่งแจ้ง
- อย่าเพิ่มเทคโนโลยีโดยไม่จำเป็น เพราะนั่นทำให้โปรแกรมเมอร์ต้องวุ่นวายมากขึ้น
- จงทำโปรเจ็กต์ โดยคิดว่าความเปลี่ยนแปลงเกิดขึ้นได้เสมอ
- อย่าย่อชื่อตัวแปรถ้าไม่จำเป็น เดี๋ยวนี้ IDE มันช่วยขึ้นเยอะแล้ว ไม่ต้องพิมพ์เอง แค่ dot มันก็ขึ้นมาให้เลือก
- อย่าใช้ i, j, k, result, index, name, param เป็นชื่อตัวแปร
- ทำโค้ดที่ต้องสื่อสารผ่านเครือข่ายให้คุยกันน้อยที่สุด
- แบ่งแยกดีๆ ระหว่าง Exception Message ในแต่ละเลเยอร์ ว่าต้องการบอกผู้ใช้ หรือ บอกโปรแกรมเมอร์
- ที่ระดับ UI ต้องมี Catch All Exceptions เสมอ เพื่อกรอง Exception ที่ลืมดักจับ
- ระวังคอลัมน์ Allow Null ใน Database ให้ดี ค่ามัน Convert ไม่ได้
- อย่าลืมว่า Database เป็น Global Variable ประเภทหนึ่ง แต่ละโปรแกรมที่ติดต่อเปรียบเหมือน Multithreading ดังนั้นกฎของ Multithreading ต้องกระทำเมื่อทำงานกับ Database
- ระวังอย่าให้ logic if then else ซ้อนกันมากๆ เพราะสมองคนไม่ใช่ CPU จินตนาการไม่ออกหรอกว่ามันอยู่ตรงไหนเวลา Debug (ถ้ามากกว่าสามชั้นก็ลองคิดใหม่ดูว่าเขียนแบบอื่นได้มั้ย)
- ระวังอย่าให้ลูปซ้อนกันมากๆ ไม่ใช่แค่เรื่องความเร็วอย่างเดียว เวลา Debug เราคิดตามมันไม่ได้ (ถ้าเกินสามชั้นก็ไม่ไหวแล้ว)
- อย่าใช้ Magic Number ในโค้ด เช่น if( controlingValue == 4 ) เปลี่ยนไปใช้ Enum ดีกว่า เป็น if( controlingValue == ControllingState.NORMAL ) เข้าใจง่ายกว่ามั้ย
- ถ้าจะเปรียบเทียบ String ให้ Trim ซ้ายขวาก่อนเสมอ
- คิดหลายๆ ครั้งก่อนใช้ Trigger
- โปรแกรมเมอร์คือห่วงโซ่สุดท้ายของมลพิษทางความซับซ้อน ดังนั้นหา Project Leader ดีๆ แล้วกัน
- มนุษย์ฉลาดกว่าคอมพิวเตอร์ การเขียนโปรแกรมก็คือการสอนให้คอมพิวเตอร์ฉลาดได้เหมือนเรา (มนุษย์ฉลาดกว่าคอมพิวเตอร์จริงๆ นะ)
- จงควบคุมคอม มิใช่ให้คอมควบคุมเรา เราต้องสั่งให้คอมทำงาน ไม่ใช่ให้เราทำงานตามคอมสั่ง
- อย่าปล่อยให้ข้อจำกัดของคอม มาจำกัดความคิดของเรา (คอมไม่ดีเปลี่ยนเครื่องเลย :-D)
- ยอมรับความคิดของผู้อื่น แต่อย่าออกจากกรอบของตนเอง
- หมั่น Save โปรแกรมไว้อย่าสม่ำเสมอ ก่อนที่จะไม่มีโอกาส Save (จะให้ดี Save เป็นแต่ละ Version เลย)
อ้างอิง
