- เขียนโปรแกรมครั้งหนึ่ง จงเขียนให้เล็กที่สุดเท่าที่จะเป็นไปได้
- จงโปรแกรมโดยคิดว่าจะมีคนมาเขียนต่อจากเรา เพราะอย่างน้อยที่สุดหลังจากเรามาเปิดดูมันอีก1ปีต่อมาเราจะได้อ่านมันรู้เรื่องอยู่
- clearance (ความชัดเจน) กับ extensibility (การขยายต่อได้)...เราเลือกได้อย่างเดียว ต้องตัดสินใจดีๆ
- อย่าไว้ใจ output จากfunctionอื่น แม้functionนั้นเราเป็นคนเขียนเองก็ตาม เพราะมีโอกาสที่เราจะทดสอบfuncที่เราเขียนขึ้นมาไม่ดีพอ
- ถ้าโปรแกรมเมอร์เขียนเองแล้วยังไม่เข้าใจว่าตัวเองทำอะไรอยู่ ก็อย่าไปขอให้คนอื่นช่วยเลย ขอไปเขาก็ไม่เข้าใจอยู่ดี ทางที่ดีลองพักสักครู่หนึ่ง กลับไปทำความเข้าใจมัน ถ้ายังไม่ได้อีก...ก็ตั้งสติแล้วเริ่มเขียนใหม่ดีกว่า อย่าเสียเวลากับอะไรที่แก้ไขไม่ได้แล้วเลย
- หาข้อมูลสามวันก่อนลงมือทำหนึ่งวัน หรือจะลงมือทำเลยแล้วแก้บั๊กสามวันก็เลือกเอา ข้อมูลในที่นี้รวมไปถึงการขั้นตอนการออกแบบตัวโปรแกรม flowchart data structure ที่จะใช้อะไรพวกนั้นทั้งหมดเลยนะ
- เตรียม tools framework program-environment ก่อนลงมือทำงาน ไม่เช่นนั้นคุณจะหงุดหงิดเวลาจะทำอะไรแล้วไม่ได้อย่างใจเมื่อเคย
- อย่าโทษหรือโยนความผิดให้functionหรือclassอื่นก่อน โดยเฉพาะเมื่อพวกมันมาจาก OS และ compiler
- พยายามทำตามกฎอย่างเคร่งครัด แต่ถ้าทำไม่ได้ก็เลี่ยงให้น้อยที่สุดพร้อมกับประกาศไว้ให้เด่นที่สุด
- High cohesion, Loose coupling ตามหลักของSoftware Engineering-โมดูลและฟังก์ชั่นต้องยึดเกาะให้แน่นที่สุดในตัวของมันเอง และผูกกับโมดูลอื่นให้น้อยที่สุด
- เก็บ หรือวางสิ่งที่คล้ายๆ หรือเหมือนกันไว้ให้ใกล้กันที่สุด แม้ในแง่ของการเขียนโปรแกรมที่ลำดับไม่สำคัญต่อการรันผลก็ตาม เพราะคนเขียนนั่นแหละที่จะงงเมื่อเขียนไปเป็นพันๆ บรรทัดแล้ว ไม่ใช่คอมหรอกที่จะงง
- พิสูจน์ก่อน...แล้วค่อยเชื่อ
- กระจายความรู้ออกไปให้มากที่สุดเพราะนั่นคือการทำ Unit Test ระดับล่างที่สุด
- อย่าเอาทุกอย่างใส่ลงไปในUI เพราะUIคือส่วนที่ทำ Unit Test ได้ยากมาก
- โปรเจคทั้งโปรเจคควรไปในทางเดียวกัน (ต้องมีConsistency)
- ถ้ามีสิ่งดีๆ ให้ใช้อยู่แล้วก็จงใช้มัน แต่ถ้าจำเป็นต้องเขียนเอง...ก่อนจะเขียนก็ควรศึกษาความผิดพลาดในอดีตของคนอื่นก่อน
- อย่ามั่นใจว่า code ชุดนี้ใช้ได้ดีจนกว่าจะTestเพียงพอ (ขนาดTestพอแล้วยังเจอบั๊กได้เลย)
- มีการ edit version ของโปรแกรม ให้รันUnit Testใหม่ทุกครั้ง
- แต่ก็อย่าเชื่อ Unit Test ให้มากนัก บางครั้งมันก็ผิดได้
- ถ้าคุณเขียน code อะไรซ้ำกันมากกว่า1ครั้ง มันก็เพียงพอแล้วล่ะที่จะหาวิธีลดรูปหรือแยกชุด code นั้นออกมาเขียนเป็น function
- อย่าเขียนโปรแกรมไปโดยคิดว่าจะoptimizeมันไปด้วย เขียนให้มันใช้งานได้ก่อนแล้วค่อยลงมือทำ แล้วถ้าไม่จำเป็นก็อย่าไปoptimizeมันเลย
- ประสิทธิภาพของโปรแกรม แปรผกผันกับความเข้าใจง่าย...ถ้าโปรแกรมทำงานได้ดีมากเชื่อเถอะว่า code จะเริ่มอ่านยากแล้ว
- เวลาเขียน จงใช้ pattern ที่ชาวบ้านเขาใช้กัน เวลาเอาไปคุยกับคนอื่นจะได้คุยรู้เรื่อง
- MutiThreading เป็นการเพิ่มประสิทธิภาพ แต่มันจะมาพร้อมกับ Concerency, Deadlock, IsolationLevel, Hard to debug, Undeterministic Errors.และอื่นๆ อีกมากมาย
- อย่าไปเพิ่มtechnologyโดยไม่จำเป็นให้โปรแกรมเรา เพราะคนเป็นโปรแกรมเมอร์จะวุ่นวายมากขึ้น
- โปรเจคทำอะไรอยู่คิดซะว่าอาจจะมีความเปลี่ยนแปลงได้ตลอดเวลา (เช่น requiementเปลี่ยน)
- อย่าย่อชื่อตัวแปรโดยไม่จำเป็น มันจะทำให้คุณงงในตัวเอง ตอนนี้โปรแกรมIDEมันฉลายขึ้นเยอะแล้ว แค่พิมพ์ตัวแรกมันก็ขึ้นhintมาให้เลือกแล้ว
- ถ้าโปรเจคใหญ่มากอย่าใช้ i, j, x, y, result, name, param เป็นชื่อตัวแปรยกเว้นคุณจะมีหลักการเขียนที่ตัวเองจำมันได้แน่นอนว่า พวกมันเก็บค่าอะไร
- แบ่งแยกดีดี ระหว่าง Exception message ในแต่ละเลเยอร์ ว่าต้องการบอกผู้ใช้ หรือ บอกโปรแกรมเมอร์
- ที่ระดับ UI ต้องมี catch all exception เสมอเพื่อกรอง Exception ที่ลืมดักจับ
- เวลาทำงานกับdatabase ระวังcolumnที่เป็นnullให้ดี เรื่องนี้ทำโปรแกรมเมอร์เจ็บมากหลายต่อหลายคนแล้วเพราะค่าnullมันconvertไม่ได้
- อย่าลืมว่า Database เป็น global variable ประเภทหนึ่ง แต่ละโปรแกรมที่ติดต่อเปรียบเหมือน MultiThreading ดังนั้นกฏของ Multithreading ต้องกระทำเมื่อทำงานกับ Database
- ระวังอย่าให้ ฟอร์มของif then else ที่ซ้อนกันมากมาก...สมองคนไม่ใช่ CPU จินตนาการไม่ออกหรอกว่ามันอยู่ตรงไหนเวลา Debug ถ้าเจอมันซ้อนกันสัก4-5ชั้นก็restructureใหม่เถอะ
- ด้วยเหตุผลเดียวกัน...อย่าทำnested loopให้มากนัก ไม่ใช่แค่เครื่องจะหน่วงอย่างเดียว ถ้าเจอบั๊กขึ้นมาเราก็คิดตามมันไม่ทันเหมือนกัน
- อย่าเขียนcodeแบบใช้magic number (คืออยู่ๆ ก็มีตัวเลขนี้โผล่ขึ้นมา เช่น if(type==18) คนอ่านอ่านมันไม่รู้เรื่องหรอก ดีไม่ดีคนเขียนจะมึนเองด้วยซ้ำ...เปลี่ยนไปใช้Enumแทนดีกว่า แบบif(type==Connection.OPEN) อย่ารู้เรื่องกว่ากันเยอะ
- ถ้าจะเปรียบเทียบstring ให้trim เจ้าwhite spaceออกไปก่อนจะปลอดภัยกว่า
- คิดให้ละเอียดก่อนเขียนTrigger แล้วเขียนเสร็จแล้วอย่างลืมว่ายังมีมันอยู่ ไม่งั้นเป็นเรื่องแน่
- เมื่อโปรแกรมเมอร์มาอยู่รวมกันเยอะ แน่นอนมันจะเกิดสิ่งที่เรียกว่ามลพิษทางความซับซ้อน ทางแก้คิดหาproject managerเก่งๆ สักคนมาคุมอีกที
- คนฉลาดกว่าคอม เพราะฉะนั้นอย่างให้มันคุมเราได้ เราต้องเป็นคนคุมมัน
- รับฟังผู้อื่นเสมอ แต่อย่าเสียความเป็นตัวของตัวเอง (หมายถึงเวลาโปรแกรมด้วยนะ)
อันนี้แถมท้ายให้...
ปุ่มsaveกดไว้เสมอ
ไม่ได้เสียตังค์ ไม่กดบ่อยๆ ไฟดับ แบตหมด เจอerror เกิดblue
screenแล้วจะไม่มีใครช่วยได้นะ
[อันนี้เป็นข้อคิดที่เราหาๆ มา มาจากที่ไหนบ้างก็ไม่รู้นานมากแล้วเอามารวมๆ
กัน บางข้อก็เขียนเองด้วยแหละ แต่ถ้าพูดถึงว่าคนเขียนเองทำได้หมดทุกข้อมั้ย
ขอตอบเลยว่าไม่ ข้อคิดแต่ละข้อจะดีเมื่ออยู่ในสถานการณ์ของมัน
ต้องเลือกใช้ให้ถูกทางนะครับ ^ __ ^]
*