25 ตุลาคม, 2554

ข้อคิดดีๆ เวลาคุณจะเขียนโปรแกรม

  1. เขียนโปรแกรมครั้งหนึ่ง จงเขียนให้เล็กที่สุดเท่าที่จะเป็นไปได้
  2. จงโปรแกรมโดยคิดว่าจะมีคนมาเขียนต่อจากเรา เพราะอย่างน้อยที่สุดหลังจากเรามาเปิดดูมันอีก1ปีต่อมาเราจะได้อ่านมันรู้เรื่องอยู่
  3. clearance (ความชัดเจน) กับ extensibility (การขยายต่อได้)...เราเลือกได้อย่างเดียว ต้องตัดสินใจดีๆ 
  4. อย่าไว้ใจ output จากfunctionอื่น แม้functionนั้นเราเป็นคนเขียนเองก็ตาม เพราะมีโอกาสที่เราจะทดสอบfuncที่เราเขียนขึ้นมาไม่ดีพอ
  5. ถ้าโปรแกรมเมอร์เขียนเองแล้วยังไม่เข้าใจว่าตัวเองทำอะไรอยู่ ก็อย่าไปขอให้คนอื่นช่วยเลย ขอไปเขาก็ไม่เข้าใจอยู่ดี ทางที่ดีลองพักสักครู่หนึ่ง กลับไปทำความเข้าใจมัน ถ้ายังไม่ได้อีก...ก็ตั้งสติแล้วเริ่มเขียนใหม่ดีกว่า อย่าเสียเวลากับอะไรที่แก้ไขไม่ได้แล้วเลย
  6. หาข้อมูลสามวันก่อนลงมือทำหนึ่งวัน หรือจะลงมือทำเลยแล้วแก้บั๊กสามวันก็เลือกเอา ข้อมูลในที่นี้รวมไปถึงการขั้นตอนการออกแบบตัวโปรแกรม flowchart data structure ที่จะใช้อะไรพวกนั้นทั้งหมดเลยนะ
  7. เตรียม tools framework program-environment ก่อนลงมือทำงาน ไม่เช่นนั้นคุณจะหงุดหงิดเวลาจะทำอะไรแล้วไม่ได้อย่างใจเมื่อเคย
  8. อย่าโทษหรือโยนความผิดให้functionหรือclassอื่นก่อน โดยเฉพาะเมื่อพวกมันมาจาก OS และ compiler
  9. พยายามทำตามกฎอย่างเคร่งครัด แต่ถ้าทำไม่ได้ก็เลี่ยงให้น้อยที่สุดพร้อมกับประกาศไว้ให้เด่นที่สุด
  10. High cohesion, Loose coupling ตามหลักของSoftware Engineering-โมดูลและฟังก์ชั่นต้องยึดเกาะให้แน่นที่สุดในตัวของมันเอง และผูกกับโมดูลอื่นให้น้อยที่สุด
  11. เก็บ หรือวางสิ่งที่คล้ายๆ หรือเหมือนกันไว้ให้ใกล้กันที่สุด แม้ในแง่ของการเขียนโปรแกรมที่ลำดับไม่สำคัญต่อการรันผลก็ตาม เพราะคนเขียนนั่นแหละที่จะงงเมื่อเขียนไปเป็นพันๆ บรรทัดแล้ว ไม่ใช่คอมหรอกที่จะงง
  12. พิสูจน์ก่อน...แล้วค่อยเชื่อ
  13. กระจายความรู้ออกไปให้มากที่สุดเพราะนั่นคือการทำ Unit Test ระดับล่างที่สุด
  14. อย่าเอาทุกอย่างใส่ลงไปในUI เพราะUIคือส่วนที่ทำ Unit Test ได้ยากมาก
  15. โปรเจคทั้งโปรเจคควรไปในทางเดียวกัน (ต้องมีConsistency)
  16. ถ้ามีสิ่งดีๆ ให้ใช้อยู่แล้วก็จงใช้มัน แต่ถ้าจำเป็นต้องเขียนเอง...ก่อนจะเขียนก็ควรศึกษาความผิดพลาดในอดีตของคนอื่นก่อน
  17. อย่ามั่นใจว่า code ชุดนี้ใช้ได้ดีจนกว่าจะTestเพียงพอ (ขนาดTestพอแล้วยังเจอบั๊กได้เลย)
  18. มีการ edit version ของโปรแกรม ให้รันUnit Testใหม่ทุกครั้ง
  19. แต่ก็อย่าเชื่อ Unit Test ให้มากนัก บางครั้งมันก็ผิดได้
  20. ถ้าคุณเขียน code อะไรซ้ำกันมากกว่า1ครั้ง มันก็เพียงพอแล้วล่ะที่จะหาวิธีลดรูปหรือแยกชุด code นั้นออกมาเขียนเป็น function
  21. อย่าเขียนโปรแกรมไปโดยคิดว่าจะoptimizeมันไปด้วย เขียนให้มันใช้งานได้ก่อนแล้วค่อยลงมือทำ แล้วถ้าไม่จำเป็นก็อย่าไปoptimizeมันเลย
  22. ประสิทธิภาพของโปรแกรม แปรผกผันกับความเข้าใจง่าย...ถ้าโปรแกรมทำงานได้ดีมากเชื่อเถอะว่า code จะเริ่มอ่านยากแล้ว
  23. เวลาเขียน จงใช้ pattern ที่ชาวบ้านเขาใช้กัน เวลาเอาไปคุยกับคนอื่นจะได้คุยรู้เรื่อง
  24. MutiThreading เป็นการเพิ่มประสิทธิภาพ แต่มันจะมาพร้อมกับ Concerency, Deadlock, IsolationLevel, Hard to debug, Undeterministic Errors.และอื่นๆ อีกมากมาย
  25. อย่าไปเพิ่มtechnologyโดยไม่จำเป็นให้โปรแกรมเรา เพราะคนเป็นโปรแกรมเมอร์จะวุ่นวายมากขึ้น
  26. โปรเจคทำอะไรอยู่คิดซะว่าอาจจะมีความเปลี่ยนแปลงได้ตลอดเวลา (เช่น requiementเปลี่ยน)
  27. อย่าย่อชื่อตัวแปรโดยไม่จำเป็น มันจะทำให้คุณงงในตัวเอง ตอนนี้โปรแกรมIDEมันฉลายขึ้นเยอะแล้ว แค่พิมพ์ตัวแรกมันก็ขึ้นhintมาให้เลือกแล้ว
  28. ถ้าโปรเจคใหญ่มากอย่าใช้ i, j, x, y, result, name, param เป็นชื่อตัวแปรยกเว้นคุณจะมีหลักการเขียนที่ตัวเองจำมันได้แน่นอนว่า พวกมันเก็บค่าอะไร
  29. แบ่งแยกดีดี ระหว่าง Exception message ในแต่ละเลเยอร์ ว่าต้องการบอกผู้ใช้ หรือ บอกโปรแกรมเมอร์
  30. ที่ระดับ UI ต้องมี catch all exception เสมอเพื่อกรอง Exception ที่ลืมดักจับ
  31. เวลาทำงานกับdatabase ระวังcolumnที่เป็นnullให้ดี เรื่องนี้ทำโปรแกรมเมอร์เจ็บมากหลายต่อหลายคนแล้วเพราะค่าnullมันconvertไม่ได้
  32. อย่าลืมว่า Database เป็น global variable ประเภทหนึ่ง แต่ละโปรแกรมที่ติดต่อเปรียบเหมือน MultiThreading ดังนั้นกฏของ Multithreading ต้องกระทำเมื่อทำงานกับ Database
  33. ระวังอย่าให้ ฟอร์มของif then else ที่ซ้อนกันมากมาก...สมองคนไม่ใช่ CPU จินตนาการไม่ออกหรอกว่ามันอยู่ตรงไหนเวลา Debug ถ้าเจอมันซ้อนกันสัก4-5ชั้นก็restructureใหม่เถอะ
  34. ด้วยเหตุผลเดียวกัน...อย่าทำnested loopให้มากนัก ไม่ใช่แค่เครื่องจะหน่วงอย่างเดียว ถ้าเจอบั๊กขึ้นมาเราก็คิดตามมันไม่ทันเหมือนกัน
  35. อย่าเขียนcodeแบบใช้magic number (คืออยู่ๆ ก็มีตัวเลขนี้โผล่ขึ้นมา เช่น if(type==18) คนอ่านอ่านมันไม่รู้เรื่องหรอก ดีไม่ดีคนเขียนจะมึนเองด้วยซ้ำ...เปลี่ยนไปใช้Enumแทนดีกว่า แบบif(type==Connection.OPEN) อย่ารู้เรื่องกว่ากันเยอะ
  36. ถ้าจะเปรียบเทียบstring ให้trim เจ้าwhite spaceออกไปก่อนจะปลอดภัยกว่า
  37. คิดให้ละเอียดก่อนเขียนTrigger แล้วเขียนเสร็จแล้วอย่างลืมว่ายังมีมันอยู่ ไม่งั้นเป็นเรื่องแน่
  38. เมื่อโปรแกรมเมอร์มาอยู่รวมกันเยอะ แน่นอนมันจะเกิดสิ่งที่เรียกว่ามลพิษทางความซับซ้อน ทางแก้คิดหาproject managerเก่งๆ สักคนมาคุมอีกที
  39. คนฉลาดกว่าคอม เพราะฉะนั้นอย่างให้มันคุมเราได้ เราต้องเป็นคนคุมมัน
  40. รับฟังผู้อื่นเสมอ แต่อย่าเสียความเป็นตัวของตัวเอง (หมายถึงเวลาโปรแกรมด้วยนะ)
อันนี้แถมท้ายให้...

ปุ่มsaveกดไว้เสมอ ไม่ได้เสียตังค์ ไม่กดบ่อยๆ ไฟดับ แบตหมด เจอerror เกิดblue screenแล้วจะไม่มีใครช่วยได้นะ

[อันนี้เป็นข้อคิดที่เราหาๆ มา มาจากที่ไหนบ้างก็ไม่รู้นานมากแล้วเอามารวมๆ กัน บางข้อก็เขียนเองด้วยแหละ แต่ถ้าพูดถึงว่าคนเขียนเองทำได้หมดทุกข้อมั้ย ขอตอบเลยว่าไม่ ข้อคิดแต่ละข้อจะดีเมื่ออยู่ในสถานการณ์ของมัน ต้องเลือกใช้ให้ถูกทางนะครับ ^ __ ^]
*

1 ความคิดเห็น:

  1. อ่านละชอบจัง มีประโยชน์มากเลย เจ้าของบล๊อคจบปริญญายังหว่า ชอบๆ

    ตอบลบ