Progrmmer ที่ดี 50 ประการ

Standard

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

2.ทำสิ่งธรรมดาให้ง่าย ทำสิ่งยากให้เป็นไปได้    //User บอกว่าจะเอา ไม่ว่ายากหรือง่าย ก็ต้องทำให้ได้

3.จงโปรแกรมโดยนึกว่าจะมีคนมาทำต่ออย่างแน่นอน   // 555 ไม่สน ไล่เอาเอง

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

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

6.อย่าเชื่อมั่น output จากโมดูลอื่น ถึงแม้เราจะเป็นคนเขียนเอง  //ถูก ไม่ค่อยไว้ใจเลย จนกว่าจะสิ้นเสียงบ่นจากภายนอก

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

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

9.จงสร้างเครื่องมือ ก่อนทำงาน  //อันนี้ หนูงง

10.อย่าโทษโมดูลอื่นก่อน โดยเฉพาะถ้าโมดูลอื่นเป็น OS และ Compiler   //ถูก แต่ก็แอบมีบาง ปลอบใจตัวเอง

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

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

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

14.อย่าเชื่อโดยไม่พิสูจน์   //ถูก แต่คนอื่นมักจะเชื่อใจ PA จัง ขนาด PA ยังไม่เชื่อใจตัวเองเลย

15.อย่าลองทำแล้วคอมไพล์ดู ถ้าเราไม่ได้คาดหวังผลลัพธ์อะไรไว้    // 55 คาดเสมอว่าจะไม่ Error, output ถูก ก็พอใจแล้ว

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.ถ้าต้องทำอะไรที่ซ้ำกันมากกว่าหนึ่งครั้ง ก็เพียงพอแล้วที่จะแยกโค้ดส่วนนั้นออก   //ถูก แต่ก็หยวนให้บ้างในบางที แต่ใจเราชอบจับแยกตลอดเลย ชอบคิดว่า เด๊ยวครั้งที่ 3 4 5 จะตามมา

25.ทำให้ใช้งานได้ก่อน แล้วค่อย optimize และถ้าไม่จำเป็น อย่าoptimize   //ถูก เด๊ยวจะ bug ไปใหญ่ ฉะนั้น ห้ามมาขอเพิ่ม Requirement นะ คิคิ

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

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

28.อย่าเก็บไว้ทำทีหลัง ถ้ายังไงก็ต้องทำ  //ขยันก็ต่อ ขี้เกียจก็เด๊ยวก่อนน่า

29.MutiThreading
ไม่ใช่แค่การเพิ่มประสิทธิภาพ แต่มันมาพร้อมกับ Concerency, Deadlock,
IsolationLevel, Hard to debug, Undeterministic Errors.   //โห ของแถมที่ไม่อยากได้

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

31.อย่าเพิ่ม technology โดยไม่จำเป็น เพราะนั่นทำให้โปรแกรมเมอร์ต้องวุ่นวายมากขึ้น  //อาจจะวุ่นช่วงแรกๆ แต่ก็อาจจะสบายปลายก็ได้ ขอดูซะหน่อยว่า work ป่าว

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 ดีดีแล้วกัน  //ต้องหา lead ที่เข้าใจรมณ์ PA

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

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

48. อย่าปล่อยให้ข้อจำกัดของคอม มาจำกัดความคิดของเรา //โลกข้างนอกมันใหญ่กว่าโลกอินเตอร์เน็ตเสมอ

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

50. หมั่น Save โปรแกรมไว้อย่าสม่ำเสมอ ก่อนที่จะไม่มีโอกาส Save //มักจะรู้ตัว เมื่อไฟตกครั้งแรกก่อนเสมอ

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s