คุณจะรู้ได้อย่างไรว่าคุณเขียนโค้ดที่อ่านได้และบำรุงรักษาง่าย


336

เราจะรู้ได้อย่างไรว่ารหัสที่สร้างนั้นสามารถอ่านเข้าใจและบำรุงรักษาได้ง่าย? แน่นอนจากมุมมองของผู้เขียนรหัสสามารถอ่านได้และบำรุงรักษาได้เนื่องจากผู้เขียนเขียนและแก้ไขมันเพื่อเริ่มต้นด้วย อย่างไรก็ตามจะต้องมีมาตรฐานวัตถุประสงค์และเชิงปริมาณที่วิชาชีพของเราสามารถวัดรหัสได้

เป้าหมายเหล่านี้จะเกิดขึ้นเมื่อผู้ใช้อาจทำสิ่งต่อไปนี้ด้วยรหัสโดยไม่มีคำแนะนำจากผู้เชี่ยวชาญของผู้เขียนต้นฉบับ:

  • มันเป็นไปได้ที่จะอ่านโค้ดและทำความเข้าใจกับการไหลของตรรกะในระดับพื้นฐาน

  • เป็นไปได้ที่จะเข้าใจในระดับที่ลึกยิ่งขึ้นว่าโค้ดทำอะไรเพื่อรวมอินพุตเอาต์พุตและอัลกอริธึม

  • ผู้พัฒนารายอื่นสามารถทำการเปลี่ยนแปลงที่มีความหมายกับรหัสต้นฉบับเช่นการแก้ไขข้อบกพร่องหรือการปรับโครงสร้างใหม่

  • หนึ่งสามารถเขียนรหัสใหม่เช่นคลาสหรือโมดูลที่ใช้ประโยชน์จากรหัสเดิม

เราจะหาปริมาณหรือวัดคุณภาพของรหัสเพื่อให้สามารถอ่านเข้าใจและบำรุงรักษาได้อย่างไร


154
การเชื่อมโยงบังคับ (ครั้งไม่ได้ที่จะ xkcd): osnews.com/images/comics/wtfm.jpg
เจอร์รี่โลงศพ

3
ฉันเพียงแค่พูดอย่างตรงไปตรงมาว่าคุณรู้เมื่อคุณเห็นมันแต่ข้อโต้แย้งนี้มีข้อบกพร่องพื้นฐานและน่าอายแม้จะอยู่ในรูปแบบเดิมไม่เคยรังเกียจที่จะใช้กับซอร์สโค้ด
Konrad Rudolph

6
"แน่นอนในมุมมองของคุณรหัสของคุณสามารถอ่านได้" - ไม่ชัดเจน!
UncleZeiv

24
ฉันจะบอกว่าคุณรู้ว่าเมื่อคุณเห็นมันไม่กี่เดือนหลังจากที่คุณเขียนมัน
JeffO

2
@asfallows: ฉันแสดงรหัสให้ภรรยาของฉันและเธอคิดว่ามันเป็นรหัสที่ไม่ดีจริงๆเพราะเธออ่านได้! (มีคำในภาษาอังกฤษมากเกินไปและไม่เพียงพอ @ [! ^ $ & *) อักขระ ... )
gnasher729

คำตอบ:


370

เพียร์ของคุณบอกคุณหลังจากตรวจสอบรหัส

คุณไม่สามารถระบุได้ด้วยตัวเองเพราะในฐานะผู้เขียนคุณรู้มากกว่ารหัสที่บอกด้วยตัวเอง คอมพิวเตอร์ไม่สามารถบอกคุณได้ด้วยเหตุผลเดียวกันกับที่ไม่สามารถบอกได้ว่าการวาดภาพนั้นเป็นงานศิลปะหรือไม่ ดังนั้นคุณต้องมีคนอื่นที่มีความสามารถในการบำรุงรักษาซอฟต์แวร์ - เพื่อดูสิ่งที่คุณเขียนและแสดงความคิดเห็นของเขาหรือเธอ ชื่ออย่างเป็นทางการของกระบวนการดังกล่าวเป็นการทบทวน


6
ไม่มีอะไรจะดีกว่าการทดสอบเชิงประจักษ์
วิศวกรโลก

25
+1 ผู้ชมที่สำคัญที่สุดของคุณคือเพื่อนของคุณที่ดื่มด่ำกับคุณในการรับรู้ปัญหาและปัญหาที่คุณกำลังทำและวิธีแก้ปัญหา รหัสที่ดีสะท้อนถึงความเข้าใจในปัจจุบันของกลุ่มเพื่อนของคุณเกี่ยวกับเรื่องนี้ สมมติว่าทีมมีความสามารถมีน้ำใจและเปิดรับความคิดใหม่ ๆ "เพื่อนของคุณบอกคุณว่ามันเป็นสิ่งที่ดี / ดูแลได้" คือจากประสบการณ์ของฉัน
Doug T.

69
จากประสบการณ์ของฉันสิ่งนี้ใช้ได้เฉพาะเมื่อเพื่อนร่วมงานของคุณรู้ว่าอะไรดีและอะไรไม่ดี มิฉะนั้นจะฟังดูเหมือนว่า: "คุณควรเขียนโค้ดเหล่านั้นในวิธีเดียวกันมันหารหัสได้ง่ายกว่า"
Rangi Lin

12
@ RangiLin เพื่อนร่วมงานของคุณอาจถูกต้อง

11
@ Rangi คุณต้องทำงานกับเพื่อนร่วมงานที่คุณมี หากพวกเขาพบว่ารหัสของคุณยากที่เป็นปัญหากับรหัสของคุณ ในระยะยาวคุณสามารถให้ความรู้แก่พวกเขาหรือพยายามที่จะรับเพื่อนร่วมงานที่ดีกว่า (คุณสามารถย้ายหรือคุณสามารถมีอิทธิพลต่อกระบวนการจ้างงาน) ... โอ้ใช่และทำเสมอจำได้ว่าพวกเขาอาจจะถูกต้อง
MarkJ

220

บางครั้งวิธีที่ดีที่สุดที่จะรู้ก็คือกลับไปที่โค้ดที่คุณเขียนเมื่อหกเดือนที่แล้วและลองทำความเข้าใจกับสิ่งที่มันถูกเขียนขึ้นมา

หากคุณเข้าใจเร็ว - อ่านได้


28
ใช่ว่าเสียงดี (และเป็นความจริง) แต่ก็ไม่ได้เป็นวิธีการที่ดีมากสำหรับการตัดสินใจว่า / วิธีการทำวันนี้ ...
ไมเคิลแรนต์

10
ผ่าแสดงให้เห็นว่ามันใช้เวลาสักครู่และคุณจะต้องทำอย่างระมัดระวัง ...
deworde

3
ฉันอาจลดกรอบเวลาสำหรับการเยี่ยมชมลงไปหนึ่งเดือนหรือน้อยกว่าสำหรับการเยี่ยมชมครั้งแรก ฉันคิดว่ามันขึ้นอยู่กับความซับซ้อนของโครงการและโดเมนรวมถึงวิธีการทางจิตของคุณ ฉันพบว่าในหกเดือนฉันรู้สึกสับสนเพราะเห็นโอกาสในการปรับโครงสร้างใหม่หรือการเพิ่มประสิทธิภาพโดยใช้เครื่องมือหรือเทคนิคที่ฉันได้เรียนรู้ตั้งแต่ฉันเขียนโค้ดครั้งแรกแทนที่จะอ่านง่าย
Chris Bye

1
@MichaelDurrant ทุกครั้งที่คุณตรวจสอบโค้ดเก่าคุณจะพบชิ้นส่วนที่ควรจะเขียนแตกต่างกันไปจากนั้นคุณจะต้องคำนึงถึงรหัสที่คุณเขียนว่า "วันนี้" ใช่ใช้เวลาในการเรียนรู้วิธีเขียนโค้ดที่ดี
dj18

1
@Michael เกิดขึ้นมันยังคงเป็นเพราะคุณสามารถเรียนรู้สิ่งที่ไม่ชัดเจนที่คุณทำเมื่อหกเดือนที่แล้วและไม่ทำสิ่งเหล่านั้นในวันนี้
djechlin

94

มันคือ:

  1. การบำรุงรักษาถ้าคุณสามารถรักษามัน
  2. สามารถบำรุงรักษาได้ง่ายถ้าคนอื่นสามารถดูแลได้โดยไม่ต้องขอความช่วยเหลือจากคุณ
  3. สามารถอ่านได้ถ้าคนอื่นบนอ่านมันอย่างถูกต้องมีความเข้าใจในการออกแบบรูปแบบและความตั้งใจ

การทดสอบที่แท้จริงสำหรับ 1. คือ (อย่างที่Alex ในปารีสและquant_devพูด) ว่าคุณสามารถเลือกมันได้หลังจากผ่านไปสองสามเดือนทำอย่างอื่น

การทดสอบสำหรับ 2. และ 3 คือบุคคลอื่นสามารถหยิบมันขึ้นมาและหาวิธีการขยายหรือแก้ไขรหัสของคุณในขณะที่ติดตามการออกแบบของคุณ หากพวกเขาไม่สามารถเข้าใจการออกแบบวิธีการที่เกี่ยวข้องกับพื้นที่ที่เป็นปัญหาหรือวิธีการรหัสของคุณตั้งใจที่จะใช้พวกเขาจะตัดการแก้ปัญหาทั่วเมล็ดข้าวแทน

มีกฎของหัวแม่มือหลักการ (เช่นกฎของหัวแม่มือที่มีคนเขียนขึ้นอย่างดีและให้ชื่อ) และคำแนะนำทุกประเภทที่อาจนำคุณไปในทิศทางที่ถูกต้องหรืออยู่ห่างจากหลุมพรางทั่วไป ไม่มีใครในพวกเขาที่จะรับประกันคุณสมบัติที่คุณต้องการ


2
วิธีการเกี่ยวกับการพิจารณาระยะเวลาที่จะใช้ในการแก้ไขข้อผิดพลาดหรือปรับเปลี่ยนพฤติกรรมที่มีอยู่เป็นปัจจัยของการบำรุงรักษา? ชิ้นส่วนของรหัสที่ต้องใช้เวลาน้อยลงในการเปลี่ยนแปลงแบบเดียวกันควรจะมีการบำรุงรักษามากขึ้นใช่ไหม
VCD

1
ขึ้นอยู่; บางครั้งการปรับเปลี่ยนที่ดีจะต้องมีการ refactoring (ซึ่งคุณสามารถบอกได้ว่าเป็นสิ่งที่จำเป็นเพราะรหัสที่ชัดเจนทำให้ชัดเจนว่าไม่ได้มีเจตนาที่จะใช้เช่นนั้น) ซึ่งใช้เวลานานกว่าการแฮ็คในกรณีพิเศษ )
ไร้ประโยชน์

30

หากรหัสของคุณเป็นไปตามหลักการของSOLIDและDRYและมีชุดการทดสอบที่ดีรอบ ๆ มันอาจจะรักษาได้

มันอ่านได้หรือไม่ อ่านมัน ชื่อเมธอดและตัวแปรเหมาะสมหรือไม่? คุณสามารถติดตามตรรกะของโปรแกรมโดยไม่มีปัญหาได้หรือไม่? หากคำตอบคือใช่จะสามารถอ่านรหัสได้


8
... และหลังจากที่คุณอ่านให้มอบให้คนอื่นเพื่อลองอ่าน
jcmeloni

19
นี่ไม่ใช่การทดสอบที่ดีโดยเฉพาะ แอปพลิเคชันหลายตัวของกฎเหล่านั้นเป็นแบบอัตนัยและคุณสามารถอ่านรหัสของคุณเองได้ทันทีหลังจากเขียนเสร็จ
DeadMG

1
"ถ้าคำตอบคือใช่แล้วโค้ดสามารถอ่านได้" ... โดยคุณ หากต้องการดูว่าผู้อื่นสามารถอ่านได้หรือไม่ผู้อื่นต้องลองอ่าน

2
IMO, SOLID overrated โดยเฉพาะ 'S. ' นั่นหรือทุกคนเข้าใจผิด
Erik Reppen

ฉันใช้เวลานับไม่ถ้วนในรหัสที่แห้งและแข็งและยังน่ากลัว หลักการดังต่อไปนี้สามารถสร้างความประทับใจที่ผิดพลาดได้ว่าสิ่งที่คุณกำลังเขียนไม่ใช่อึ
Jakub Arnold

24

การอ่านวิธีการเขียนรหัสที่ไม่สามารถทำได้ - สร้างความมั่นใจให้กับชีวิตโดย Roedy Green หัวเราะและเรียนรู้

... วิธีการเขียนโค้ดที่ยากเกินกว่าที่จะรักษาคนที่มาหลังจากคุณจะต้องใช้เวลาเป็นปี ๆ ในการเปลี่ยนแปลงแม้แต่น้อยที่สุด นอกจากนี้หากคุณปฏิบัติตามกฎเหล่านี้อย่างเคร่งครัดคุณจะรับประกันตัวเองตลอดชีวิตของการจ้างงานเนื่องจากไม่มีใคร แต่คุณมีความหวังในนรกในการรักษารหัส ...

บทความนี้ให้ตัวอย่างมากมายเกี่ยวกับวิธีการเขียนโค้ดที่ไม่ดีโดยใช้ตัวอย่างตลก ๆ มากมาย มันยังคงที่จะอธิบายวิธีการใช้ความคิดสร้างสรรค์นางสาวสะกด , Reuse ชื่อเทคนิคการชื่นชมอย่างมากของการใช้ซ้ำชื่อทั่วโลกเป็นส่วนตัว

เรียงความตลกสอนวิธีหลีกเลี่ยงตัวอย่างทั้งหมดของโค้ดที่อ่านไม่ได้และไม่สามารถเข้าใจได้

ที่จริงแล้วฉันพบว่ามันยากที่จะเชื่อว่าทุกคนจะเขียนโค้ดที่มีความคล้ายคลึงกับตัวอย่างในข้อความ นั่นคือตอนที่ฉันยังสดจากโรงเรียน แต่หลังจากทำงานไปสองสามปีฉันเห็นรหัสจากข้อความทุกวัน ...


ดูเพิ่มเติมWaterfall2006.com/gorman.html Refuctoring เป็นกระบวนการของการออกแบบโค้ดที่ดีและผ่านการเปลี่ยนแปลงเล็ก ๆ ที่กลับด้านได้ทำให้ทุกคนไม่สามารถกำจัดได้โดยสิ้นเชิงยกเว้นตัวคุณเอง
Sjoerd

22

แม้จะดูเหมือนว่ามีบางมาตรการที่เป็นธรรมที่คุณสามารถพิจารณาได้ หนังสือเช่นC ++ มาตรฐานการเข้ารหัส , Refactoringและรหัสสะอาดมีรายการยาวของเกณฑ์ในการตัดสินรหัสของคุณโดยการมองไปที่สิ่งที่ต้องการชื่อที่มีความหมายขนาดฟังก์ชั่นหลักการเช่นการมีเพศสัมพันธ์และการทำงานร่วมกัน, การออกแบบวัตถุทดสอบหน่วยการปรับแต่งต่อเนื่อง ฯลฯ

รายการมีขนาดใหญ่เกินกว่าที่จะคล้อยตามรายการตรวจสอบได้ แต่คุณอ่านหนังสือและเลือกสิ่งสำคัญสองสามข้อที่จะใช้งานได้หลังจากนั้นหลายเดือนอ่านอีกครั้งเพื่อปรับปรุงเพิ่มเติม


4
+1 เพื่อการเรียนรู้ที่เพิ่มขึ้นและไม่พยายามที่จะสมบูรณ์แบบในชั่วข้ามคืน
dj18

19

หลักฐานอยู่ในพุดดิ้ง ดูสิ่งที่เกิดขึ้นหลังจากส่งมอบให้กับบุคคลที่มีความสามารถพอสมควร หากพวกเขาไม่จำเป็นต้องถามคำถามมากมายเกี่ยวกับความยากของรหัสคุณทำได้ดีมาก

นี่เป็นบทเรียนแรกในอาชีพของฉัน ผู้ให้คำปรึกษากล่าวว่า "บันทึกเอกสารทุกอย่างเพื่อให้คุณสามารถหนีออกจากโปรแกรมในภายหลังได้หากคุณไม่คาดหวังคำถามเมื่อคำตอบนั้นสดใหม่ในใจคุณจะต้องคิดออกเมื่อไม่มี


10
ระวังว่าผู้คนอาจละเว้นจากการถามคำถามเนื่องจากกลัวที่จะเปิดเผยความไม่รู้ คุณอาจรู้สึกว่าคนเหล่านี้มีความสามารถพอสมควรในตอนแรกเนื่องจากพวกเขามีแนวโน้มที่จะละเว้นจากการเปิดเผย ดังนั้นการไม่มีคำถามอาจไม่ใช่สิ่งที่ดีถ้าคุณรู้ว่าคุณทั้งคู่มีความจริงใจ
Hermann Ingjaldsson

1
@ HermannIngjaldsson - ยุติธรรมเพียงพอ แน่นอนถ้าพวกเขาไม่เก่งและมีอะไรบางอย่างหยุดพักคุณจะได้ยินเกี่ยวกับเรื่องนี้เร็วพอ "ช่วยด้วย!!!!"
MathAttack

ดูเหมือนว่าจะทำซ้ำสิ่งที่ระบุไว้ในคำตอบที่ดีที่สุด
gnat

17

ฉันอ่านคำตอบทั้งหมดและสังเกตว่าไม่มีใครพูดถึงความซับซ้อนของรหัส

มีความสัมพันธ์ระหว่างความซับซ้อนของรหัสกับความสามารถในการอ่าน / บำรุงรักษา มีอัลกอริธึมการให้คะแนนความซับซ้อนของรหัสจำนวนมาก แต่ฉันจะพูดถึงวิธีการให้คะแนนความซับซ้อนของ McCabe

โดยทั่วไปการให้คะแนน McCabe จะอ่านรหัสของคุณและคำนวณจำนวน "เส้นทาง" ที่ไม่ซ้ำกันซึ่งมีอยู่ในนั้น ถ้าคุณใช้ McCabe เป็นตัวเศษและบรรทัดของโค้ดเป็นตัวส่วนคุณจะได้ "การอ่าน" ที่ดีเช่นกัน

หากคุณมีรหัส 10 บรรทัดและมี 300 เส้นทางผ่านรหัสนั้นนั่นคือรหัสที่ไม่สามารถเข้าใจได้ (ยากที่จะเปลี่ยนอย่างปลอดภัยและง่ายดาย) และอาจไม่สามารถอ่านได้มาก ในทางกลับกันถ้าคุณมีโค้ด 300 บรรทัด แต่มีเพียง 1 พา ธ เท่านั้น (ไม่มีเงื่อนไข) ทั้งคู่สามารถอ่านได้และบำรุงรักษาได้ง่าย

ที่ McCabe ตกลงไปอย่างไรก็ตามในตัวอย่างหลังนั้น หากฉันมีรหัส 300 บรรทัดโดยไม่มีเงื่อนไขมีโอกาสที่ดีจริง ๆ ที่ฉันได้ทำ "คัดลอก / วางกลับมาใช้" และเห็นได้ชัดว่าไม่ใช่สิ่งที่ดี ดังนั้นจึงมีตัวชี้วัดทั้งระบบที่คุณใช้นอกเหนือจาก McCabe เช่นการตรวจจับรหัสที่ซ้ำกันหรือใกล้เคียงกัน


2
นี่ควรเป็นคำตอบ วัด. คำตอบอื่น ๆ มีความคิดเห็นมากกว่าความจริงถ้าฉันเข้าใจได้มันต้องดีไหม มาตรการแรกโดยใช้การวิเคราะห์ความซับซ้อนจากนั้น refactor ของมนุษย์เพื่อค้นหาการทำซ้ำ ฯลฯ
Jon Raynor

1
ย่อหน้าสุดท้ายของคุณพูดถึงข้อเสียของคะแนน McCabe หารด้วย LOC ค่อนข้างมีแนวโน้มที่จะทำให้ความคิดทั้งหมดเป็นโมฆะ หากคุณต้องการ 300 เส้นทางผ่านรหัสของคุณทำไมคุณคิดว่ามันจะทำให้รหัสสามารถบำรุงรักษาได้มากขึ้นในการใช้บรรทัดมากขึ้น? นั่นคือการพูดว่าถ้าหนังสือนำเสนอแนวคิดที่ซับซ้อนมันควรเป็นหนังสือเล่มใหญ่จริง ๆแทนที่จะพยายามสื่อสารให้รัดกุม -1
สัญลักษณ์แทน

8

สิ่งหนึ่งที่ฉันจะแบ่งปันคือถ้ารหัสนั้นสร้างขึ้นใน "โมดูล" และเมื่อฉันบอกว่าฉันหมายความว่าคุณสามารถเปลี่ยนแปลงสิ่งหนึ่งในโมดูลและทำให้มันทำงานได้โดยง่าย มันลดผลกระทบระหว่างสิ่งที่ไม่เกี่ยวข้อง นอกจากนี้:

  • รหัสนี้ง่ายต่อการใช้ซ้ำ
  • รหัสของคุณมีความยืดหยุ่น (ซึ่งสัมพันธ์กับการสร้างในโมดูล)
  • แห้ง - อย่าทำซ้ำตัวเอง

ฉันขอแนะนำให้อ่าน The Pragmatic Programmer


8

การทดสอบ / ตัวชี้วัดบางอย่าง:

  • ปิด IDE คุณยังสามารถอ่านรหัสของคุณเองได้หรือไม่? เมื่อมีข้อผิดพลาดมันค่อนข้างง่ายที่จะติดตามมันด้วยมือและหาว่าคุณจะต้องเรียนเบรกพอยต์เพื่อเรียนรู้ว่าปัญหานั้นอยู่ที่ไหน หรือเมื่อคุณใช้ IDE คุณไม่รู้สึกรำคาญและแค่ก้าวผ่านตั้งแต่แรก?

  • การดีบั๊กมักจะกลายเป็นเกมที่แปลกประหลาดซึ่งการแก้ไขบั๊กหนึ่งอันจะสร้างมากกว่า 2+

  • จากทริกเกอร์ดึงไปสู่สิ่งที่มีประโยชน์เกิดขึ้นจริงมันใช้วิธีเรียกหลายวิธี? วิธีการส่งผ่านวิธีที่แน่นอนเดียวกันหรือมากที่สุดของพารามิเตอร์ที่แน่นอนเดียวกันไปยังการเรียกวิธีการอื่น?

  • คุณต้องเปิดไฟล์กี่ไฟล์เพื่อเพิ่มวิธีการใหม่ ๆ ในการเรียน?

  • คิดเกี่ยวกับรูปแบบและวิธีปฏิบัติที่คุณนำมาใช้ คุณทำอย่างนั้นเพราะพวกเขามีเหตุผลที่สมบูรณ์แบบหรือเพราะมีคนเชื่อว่าคุณ "เป็นวิธีเดียวที่จะทำมันได้หรือ" หรือเพราะคุณต้องการมันในประวัติส่วนตัวของคุณหรือเพราะนักพัฒนา rockstar บางคนพูดอย่างนั้น


3
การอ่านโค้ดที่ไม่มี IDE ดูเหมือนว่าบ้าคลั่งโดยเฉพาะการวัดความสามารถในการอ่าน การวัดประเภทนี้ส่งผลให้เกิด "วิธีแก้ปัญหา" รูปแบบสัญกรณ์ฮังการีซึ่งส่งผลกระทบต่อความสามารถในการอ่านในท้ายที่สุด
rubenvb

8

จะรู้ได้อย่างไรว่ารหัสที่เขาสร้างนั้นสามารถบำรุงรักษาและอ่านได้ง่าย?

คุณสามารถมองเห็นรหัสที่ง่ายต่อการบำรุงรักษาและอ่านได้โดยค้นหาคุณสมบัติเหล่านี้:

  1. วัตถุวิธีการและ / หรือฟังก์ชั่นทำสิ่งหนึ่งเสมอ
  2. วิธีการและ / หรือฟังก์ชั่นมีความกระชับ (ดังใน "สั้น ๆ แต่ครอบคลุม")
  3. วัตถุวิธีการและ / หรือฟังก์ชั่นทำสิ่งที่คุณคิดว่าพวกเขาควรจะทำตามชื่อของพวกเขา
  4. รหัสที่กำหนดไว้สำหรับการใช้ซ้ำจริง ๆ แล้วสามารถนำมาใช้ซ้ำได้
  5. ท้ายสุด แต่ไม่ท้ายสุดถ้าคุณสามารถทดสอบโค้ดได้ในทันทีคุณมีความเป็นไปได้ที่จะเขียนโค้ดโมดูลเดี่ยวอย่างน้อยที่สุด

เราจะรู้ได้อย่างไรว่าเราเขียนโค้ดที่ยุ่งเหยิงและไม่สามารถกำจัดได้ มีโครงสร้างหรือแนวทางที่จะรู้หรือไม่ว่าเราพัฒนาซอฟต์แวร์ที่ยุ่งเหยิง?

  1. หากคุณกำลังอ่านวิธีการ แต่ไม่ชัดเจนว่าเจตนาคืออะไรนี่คือสิ่งที่ไม่เหมาะสมที่สุดและอาจไม่สามารถทำได้อย่างเลวร้ายที่สุด
  2. ถ้ามันดูไม่ง่ายมันอาจจะไม่ง่ายเลยและนั่นเป็นสัญญาณของรหัสหรือรหัสที่ไม่สามารถรักษาได้
  3. หากมีการขาดความสมมาตร (ความสอดคล้อง) ข้ามโค๊ดเบสคุณอาจมองไปที่โค้ดที่ไม่สามารถทำลายได้

ฉันไม่เห็นด้วยว่าตัวอย่างการปรับโครงสร้างของคุณชัดเจนขึ้น ฉันเห็นด้วยกับรหัสต้นฉบับที่ต้องการการทำงาน แต่ในแง่ของความชัดเจนและการสื่อสารเจตนาฉันคิดว่าต้นฉบับนั้นดีกว่ามาก ฉันสงสัยว่าการเปลี่ยนโครงสร้างใด ๆ ที่อ้างว่ามันช่วยปรับปรุงความชัดเจนในขณะที่แนะนำ regex
Roy

1
@ ROY, ใช่ยุติธรรมพอ ฉันอาจไม่เคยเพิ่มตัวอย่างโค้ดนั้น จริงอยู่ที่มันเกือบ 3 ปีที่แล้ว แต่ถึงอย่างนั้นฉันก็ไม่ควรใช้ PHP (ตอนนี้ฉันกำลังดูอยู่ตอนนี้) และฉันไม่ควรใช้ regex เพราะมันเป็นสิ่งหนึ่งที่คนบางคน สามารถดูและรับได้ทันที แต่สำหรับคนอื่น ๆ ไม่ว่าจะรวบรัด regexes จะปิดทันที ฉันจะแก้ไขคำตอบแล้วปล่อยตัวอย่างโค้ด ขอบคุณสำหรับความคิดเห็น
Wil Moore III

วัตถุสามารถทำสิ่งหนึ่งได้อย่างไร
Koray Tugay

@KorayTugay ลองคิดแบบนี้สิ หากวัตถุอธิบายมากกว่าแนวคิดที่เป็นหนึ่งเดียวคุณจะได้กลิ่น
Wil Moore III

6

ในคำเดียวประสบการณ์

ในการเริ่มต้นคุณต้องทำงานหนักดังนั้นฉันจึงไม่สามารถแนะนำได้มากนักว่าโปรแกรมเมอร์ควรใช้เวลาอ่านหนังสือเช่นRefactoringซึ่งจะให้เครื่องมือที่จำเป็นยิ่งขึ้นในคลังแสงของโปรแกรมเมอร์ที่จะปรับปรุง ความสามารถของคุณในการรักษารหัสและรหัสทำความสะอาดซึ่งเขียนโดยความสามารถที่เป็นที่รู้จักมากที่สุดในสาขาของเราและซึ่งอธิบายเกือบทุกอย่างที่คุณต้องเข้าใจเพื่อให้แน่ใจว่ารหัสของคุณสะอาดและสามารถอ่านได้

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

นอกจากนี้ยังช่วยให้มีที่ปรึกษาที่ดีหรือเพื่อนที่มีประสบการณ์เพื่อยืนยันว่าคุณกำลังพยายามเขียนโค้ดให้มีมาตรฐานสูง นี่เป็นเพียงเหตุผลหนึ่งว่าทำไมการตรวจสอบโค้ดจึงมีประโยชน์มาก การใช้การตรวจสอบรหัสและเครื่องมือการจัดรูปแบบอาจเป็นประโยชน์อย่างมากในการตรวจสอบให้แน่ใจว่าคุณรักษาความสะอาด อย่างไรก็ตามไม่มีสิ่งใดเทียบกับประสบการณ์ที่ได้รับจากการเขียนซอฟต์แวร์เป็นเวลาหลายปีเช่นคุณจะพบว่าตัวเองเขียนโค้ดที่สะอาดอ่านง่ายและมีโครงสร้างเพื่อความสะดวกในการบำรุงรักษาและทั้งหมดนี้เพราะคุณทำให้มันเป็นนิสัย ยาว.


3

ไม่เป็นคนเจ้าระเบียบ: ชอบสไตล์การใช้งาน ภาษาส่วนใหญ่ในปัจจุบันนี้ (. NET, Ruby, Python, Javascript และอื่น ๆ ) สนับสนุนและส่งเสริม (เช่น LINQ, underscorejs)

อ่านง่ายเหลือเกิน

var recentTopCustomers = OrderList
    .Where(o => o.Date >= DateTime.Now.AddDays(-5))
    .Where(o => o.Amount > 1000)
    .OrderBy(o => -o.Amount)
    .Take(10)
    .Select(o => o.Customer);

มันบังคับให้แต่ละโหนดมีการให้ยืมแบบเจตนาเดียวที่มุ่งเน้นเพื่อความชัดเจนของวัตถุประสงค์ และเนื่องจากแต่ละงานที่แยกออกมาถูกแยกออกมาโผล่ออกมาเสียบและจัดเรียงโหนดใหม่ วิธีนี้ช่วยให้ง่ายต่อการบำรุงรักษา


2

รหัสที่อ่านได้และบำรุงรักษาได้: รหัสที่เมื่อแรกพบโปรแกรมเมอร์สามารถเข้าใจได้ดีพอที่จะสามารถ:

  • ใช้ซ้ำผ่านทางส่วนต่อประสานหรือ
  • แก้ไขข้อบกพร่องหรือ
  • เปลี่ยนพฤติกรรมของมัน (เพิ่ม / ลบสถานที่) หรือ
  • เพิ่มประสิทธิภาพมัน
  • ทดสอบมัน

สิ่งนี้จะลดลงไปถึง 'ความชัดเจน' เช่นโปรแกรมเมอร์มีคำถามกี่คำถามที่ต้องถามถึงส่วนของรหัสเฉพาะก่อนที่จะแน่ใจว่าพวกเขา 'เข้าใจในสิ่งที่มันทำได้ดีพอ' เพื่อให้งานปัจจุบันสำเร็จโดยไม่ก่อให้เกิดผลข้างเคียงที่ไม่คาดคิด

หนังสือ 'Code Complete โดย Steve McConnell' มีรายละเอียดมากมาย

เขาต้องผ่านการวัดต่างๆที่คุณสามารถใช้ตรวจสอบว่ารหัสมีคุณภาพดีหรือไม่

ดูตัวอย่างได้ที่นี่: http://books.google.co.th/books?id=3JfE7TGUwvgC&lpg=PT376&pg=PT389#v=onepage&q&f=false


นี้ดูเหมือนจะไม่เพิ่มอะไรที่สำคัญกว่าจุดทำและอธิบายในคำตอบก่อน
ริ้น

ฉันคิดว่าหนึ่งในสิ่งที่สำคัญที่สุดที่เพิ่มเข้ามาคือการอ้างอิงถึง Code Complete ซึ่งไม่มีคำตอบก่อนหน้านี้ที่กล่าวถึง หนังสือเล่มนั้นเป็นหนึ่งในหนังสือที่มีความสำคัญและมีอิทธิพลที่สุดซึ่งมุ่งเน้นการเขียนรหัสที่สามารถอ่านได้และบำรุงรักษาได้ ใครก็ตามที่ได้อ่านหนังสือเล่มนั้นไม่จำเป็นต้องถามว่า 'คุณจะรู้ได้อย่างไรว่าคุณเขียนโค้ดที่อ่านได้และสามารถบำรุงรักษาได้ง่าย?'
JW01

... ดังนั้นในความคิดของฉันฉันเชื่อว่าสิ่งที่ดีที่สุดที่ทุกคนจะได้รับหากพวกเขามีความสนใจในการเขียนรหัสที่สามารถรักษาได้คือการอ่านหนังสือเล่มนั้น ดังนั้นมีหลายนาทีของการคิดอย่างรอบคอบ (ซึ่งมักจะเป็นหลายนาทีคิดมากกว่าผู้ดูแล SO) ผมคิดว่านี่คือไม่เพียง แต่คำตอบที่เพียงพอที่จะคำถาม OP แต่ที่ดีที่สุด
JW01

2

ลดผลข้างเคียงให้น้อยที่สุด (ไม่ควรมีใคร)

ฟังก์ชั่นที่ทำให้เกิดการเปลี่ยนแปลง 3 ครั้งในสถานะที่อยู่นอกขอบเขตของตัวเองนั้นยากกว่าที่จะให้เหตุผลและการบำรุงรักษามากกว่าหนึ่งซึ่งเพียงแค่อินพุตบางสิ่งและแสดงผลอย่างอื่น คุณไม่สามารถรู้ได้ว่าฟังก์ชั่นนี้ทำอะไรคุณต้องจำไว้ว่ามันทำอะไรและมีผลอย่างไรต่อฟังก์ชั่นอื่น ๆ ที่เกี่ยวข้องทั้งหมด

สำหรับ OOP การย่อขนาดผลข้างเคียงหมายถึงคลาสที่มีสมาชิกน้อยลงและโดยเฉพาะอย่างยิ่งสมาชิกที่สามารถปรับเปลี่ยนสถานะของคลาสได้เนื่องจากฟังก์ชั่นสมาชิกสามารถปรับเปลี่ยนสถานะของตัวเองและมีผลข้างเคียง (สามารถจัดการภายในของชั้นเรียนเป็นต้น) นอกจากนี้ยังหมายถึงคลาสที่มีข้อมูลสมาชิกของตนเองน้อยลงเพื่อให้มีวิธีการที่น้อยลงในการแก้ไขปัญหาและผลข้างเคียงที่อาจเกิดขึ้นน้อยลง

ตัวอย่างง่ายๆลองจินตนาการถึงการออกแบบโครงสร้างข้อมูลแฟนซีที่สามารถรักษาsortedสถานะที่ใช้ในการพิจารณาว่าจะทำการค้นหาแบบไบนารี่หรือแบบเชิงเส้น ในกรณีเช่นนี้อาจเป็นประโยชน์ในการแยกการออกแบบออกเป็นสองคลาส การเรียกsortedคลาสที่ไม่ได้เรียงอาจส่งคืนโครงสร้างข้อมูลของคลาสอื่นซึ่งเก็บเนื้อหาไว้เสมอ ตอนนี้คุณมีผลข้างเคียงน้อยลง (ดังนั้นจึงเกิดข้อผิดพลาดน้อยและง่ายต่อการเข้าใจรหัส) เช่นเดียวกับรหัสที่ใช้กันอย่างแพร่หลายมากขึ้น (การออกแบบในอดีตจะสิ้นเปลืองทั้งในการประมวลผลและประสิทธิภาพทางปัญญาของมนุษย์สำหรับอาร์เรย์ขนาดเล็ก

หลีกเลี่ยงการพึ่งพาภายนอกแบบฟุ่มเฟือย

คุณอาจสามารถใช้โค้ด terse มากที่สุดเท่าที่จะเป็นไปได้ด้วยการใช้รหัสซ้ำสูงสุดโดยใช้ 13 ไลบรารีที่แตกต่างกันเพื่อให้งานง่ายขึ้น อย่างไรก็ตามการโอนค่าโสหุ้ยทางปัญญาให้กับผู้อ่านของคุณนั้นต้องทำให้พวกเขาเข้าใจอย่างน้อยส่วนหนึ่งของห้องสมุด 13 แห่งที่แตกต่างกัน ใครก็ตามที่พยายามสร้างและทำความเข้าใจกับห้องสมุดบุคคลที่สามซึ่งมีความซับซ้อนนี้ควรได้รับการชื่นชมในทันทีซึ่งต้องมีการดึงและสร้างห้องสมุดอื่น ๆ อีกโหลให้สามารถใช้งานได้

นี่อาจเป็นมุมมองที่ถกเถียงกันมาก แต่ฉันต้องการการทำสำเนารหัสที่ไม่ซับซ้อนไปมากตรงกันข้ามถ้าผลลัพธ์สุดท้ายนั้นผ่านการทดสอบแล้วอย่างดี หากตัวเลือกอยู่ระหว่างรหัสซ้ำ 3 บรรทัดเพื่อคำนวณเวกเตอร์ครอสโปรดักส์หรือดึงในห้องสมุดคณิตศาสตร์มหากาพย์เพียงเพื่อกำจัดรหัส 3 บรรทัดฉันขอแนะนำทีมเก่ายกเว้นว่าทีมของคุณทั้งหมดอยู่บนกระดานด้วยห้องสมุดคณิตศาสตร์นี้ ณ จุดนี้คุณยังอาจพิจารณาเพียงแค่เขียนโค้ด 3 บรรทัดแทนที่จะเป็น 1 หากเล็กน้อยเพื่อแลกกับผลประโยชน์การแยก

การใช้รหัสซ้ำเป็นการกระทำที่ทำให้เกิดความสมดุล นำมาใช้ซ้ำมากเกินไปและคุณถ่ายโอนความซับซ้อนทางปัญญาในแบบหนึ่งต่อหลายอย่างเช่นในรหัส 3 บรรทัดที่คุณบันทึกไว้ด้านบนนั้นมีค่าใช้จ่ายในการกำหนดให้ผู้อ่านและผู้ดูแลรักษาเข้าใจข้อมูลมากกว่ารหัส 3 บรรทัด . นอกจากนี้ยังทำให้รหัสของคุณมีเสถียรภาพน้อยลงเพราะหากห้องสมุดคณิตศาสตร์มีการเปลี่ยนแปลงรหัสของคุณก็เช่นกัน นำมาใช้ใหม่น้อยเกินไปและคุณทวีคูณโสหุ้ยทางปัญญาและรหัสของคุณสิ้นสุดลงเพื่อรับประโยชน์จากการปรับปรุงส่วนกลางดังนั้นจึงเป็นการกระทำที่สมดุล แต่ความคิดที่ว่าการกระทำที่สมดุลนั้นมีค่าควรแก่การกล่าวถึงตั้งแต่พยายามประทับตรารูปแบบเล็กน้อย กับผลลัพธ์ที่ยากต่อการรักษาถ้าไม่มากไปกว่าสิ่งที่ตรงกันข้าม

ทดสอบอึออกจากมัน

นี่คือการกำหนด แต่ถ้ารหัสของคุณไม่ได้จัดการกรณีการป้อนข้อมูลทั้งหมดและพลาดกรณีขอบบางอย่างแล้วคุณจะคาดหวังให้คนอื่นรักษารหัสที่คุณเขียนว่าคุณไม่ได้รับสิทธิก่อนที่จะโอนไปยังตาและมือของพวกเขา? มันยากพอที่จะทำการเปลี่ยนแปลงโค้ดที่ทำงานได้อย่างสมบูรณ์แบบโดยไม่ต้องใช้โค้ดในตอนแรก

ยิ่งไปกว่านั้นรหัสที่ผ่านการทดสอบอย่างละเอียดโดยทั่วไปจะพบว่ามีเหตุผลน้อยกว่าที่จะเปลี่ยนแปลง ที่เกี่ยวข้องกับความมั่นคงซึ่งเป็นจอกศักดิ์สิทธิ์มากกว่าที่จะได้รับการบำรุงรักษาเนื่องจากรหัสที่เสถียรซึ่งไม่จำเป็นต้องเปลี่ยนมีค่าใช้จ่ายในการบำรุงรักษา

เอกสารประกอบอินเตอร์เฟส

จัดลำดับความสำคัญ "สิ่งที่ทำ" เหนือ "วิธีที่สิ่งเหล่านั้นทำ" หากคุณไม่สามารถอุทิศเวลาเท่ากันในการจัดทำเอกสารทั้งสอง อินเทอร์เฟซที่ชัดเจนที่เห็นได้ชัดในความตั้งใจของมันเกี่ยวกับสิ่งที่มันจะทำ (หรืออย่างน้อยที่สุดสิ่งที่มันควรจะทำ) ในทุกกรณีป้อนข้อมูลที่เป็นไปได้จะให้ความชัดเจนของบริบทเพื่อการดำเนินงานของตนเอง เพื่อใช้รหัส แต่ยังทำงานอย่างไร

ในขณะเดียวกันรหัสที่ขาดคุณสมบัติเหล่านี้ซึ่งผู้คนไม่รู้ด้วยซ้ำว่าควรทำอะไรคือ SOL ไม่ว่ารายละเอียดการใช้งานจะเป็นอย่างไร คู่มือ 20 หน้าเกี่ยวกับวิธีการนำซอร์สโค้ดมาใช้นั้นไม่มีค่าสำหรับผู้ที่ไม่สามารถเข้าใจได้อย่างชัดเจนว่าควรใช้ในตอนแรกอย่างไรและควรทำอะไรในสถานการณ์ที่เป็นไปได้ทั้งหมด

สำหรับด้านการนำไปใช้ให้จัดลำดับความสำคัญของการบันทึกสิ่งที่คุณทำแตกต่างจากคนอื่น ยกตัวอย่างเช่น Intel มีลำดับชั้นของขอบเขตสำหรับเมล็ด raytracing ของพวกเขา เนื่องจากฉันทำงานในสาขานี้ฉันสามารถจดจำได้ว่าโค้ดของพวกเขาทำอะไรได้อย่างรวดเร็วโดยไม่ต้องเปลี่ยนผ่านเอกสาร แต่พวกเขาทำสิ่งที่ไม่ซ้ำกันซึ่งเป็นความคิดของ traversing BVH และการแสดงทางแยกในแบบคู่ขนานโดยใช้แพ็คเก็ตเรย์ นั่นคือสิ่งที่ฉันต้องการให้พวกเขาจัดลำดับความสำคัญเอกสารของพวกเขาเพราะส่วนเหล่านี้ของรหัสแปลกใหม่และผิดปกติจากการใช้งาน BVH ประวัติศาสตร์

การอ่าน

ส่วนนี้เป็นอัตนัยมาก ฉันไม่ได้สนใจอะไรมากเกี่ยวกับความสามารถในการอ่านของชนิดที่ใกล้เคียงกับกระบวนการคิดของมนุษย์ รหัสที่มีเอกสารที่ดีที่สุดที่อธิบายสิ่งต่าง ๆ ในระดับสูงสุดยังคงเป็นเรื่องยากสำหรับฉันที่จะติดตามหากผู้เขียนใช้กระบวนการคิดที่แปลกประหลาดและซับซ้อนซึ่งทำให้เข้าใจผิดในการแก้ปัญหา ในขณะเดียวกันโคลงสั้น ๆ ที่ใช้ชื่อตัวละคร 2 หรือ 3 ตัวมักจะเข้าใจง่ายขึ้นถ้าตรรกะตรงไปตรงมา ฉันเดาว่าคุณสามารถตรวจสอบและดูว่าคนอื่นชอบอะไร

ฉันส่วนใหญ่สนใจในการบำรุงรักษาและที่สำคัญยิ่งกว่าคือความมั่นคง รหัสที่พบว่าไม่มีเหตุผลในการเปลี่ยนแปลงคือสิ่งที่ไม่มีค่าบำรุงรักษา


1

ฉันจะบอกวิธีหนึ่งในการรู้ว่าจะเป็นอย่างไรหากสมาชิกในทีมใหม่สามารถหยิบรหัสทำความเข้าใจและแก้ไขเพื่อแก้ไขข้อบกพร่อง / ตอบสนองความต้องการใหม่ ๆ ได้อย่างง่ายดาย


1

นี่เป็นเทคนิคที่ฉันชอบใช้:

แสดงรหัสต่อหนึ่งในโปรแกรมเมอร์ของคุณและให้พวกเขาอธิบายให้คุณฟังว่ามันทำอะไร คอยดูสิ่งเหล่านี้

1) หากพวกเขาไม่สามารถอธิบายวัตถุประสงค์ของบล็อก refactor ได้อย่างง่ายดาย
2) หากพวกเขาต้องข้ามไปยังส่วนอื่นของรหัสเพื่อทำความเข้าใจกับส่วนปัจจุบันให้ refactor มัน
4) เมื่อใดก็ตามที่คุณรู้สึกอยากจะพูดในระหว่างกระบวนการส่วนของรหัสนั้นจำเป็นต้องทำการปรับโครงสร้างใหม่ (รหัสไม่ได้พูดเพื่อตัวเอง)


สมมติว่าโปรแกรมเมอร์อย่างน้อยประสบการณ์อย่างเท่าเทียมกันและอ่านเป็นภาษาการเขียนโปรแกรมและสำนวน เทคนิคเหล่านี้มักจะนำไปสู่คนที่เขียนโค้ดในส่วนย่อยของการแสดงออกของภาษาในความพยายามที่เข้าใจผิดเพื่อให้เข้าใจง่ายแม้กระทั่งสมาชิกในทีมส่วนใหญ่ ผลที่ได้คือรหัสเนื้อหาที่ใหญ่ขึ้นในชุดย่อยของภาษาที่โง่เขลา และไม่ว่าคุณจะใบ้ชุดย่อยภาษามากน้อยเพียงใดรหัส 500KLOC ของชุดย่อยภาษาขนาดเล็กจะทำงานได้ดีกว่าในการรักษามากกว่ารหัส 200KLOC ที่ใช้ชุดย่อยที่แสดงออกได้มากกว่า
1703394

ดูเหมือนว่าจะทำซ้ำสิ่งที่ระบุไว้ในคำตอบที่ดีที่สุด
gnat

-1

รหัสที่รักษาได้มากที่สุดคือรหัสที่ไม่มี ดังนั้นแทนที่จะเพิ่มเข้าไปในการนับ LOC รหัสใหม่ที่ 'ลด' การนับ LOC (แม้ว่าการบำรุงรักษาน้อยกว่าเล็กน้อยเมื่อดูแยก) อาจทำให้รหัสฐานทั้งหมดสามารถบำรุงรักษาได้ง่ายขึ้นโดยการลดขนาด ดังนั้นกฎหลักสำหรับรหัสที่สามารถบำรุงรักษาได้:

  • เพิ่ม DRY สูงสุด

ประการที่สองไม่มีอะไรเลวร้ายยิ่งสำหรับการบำรุงรักษากว่าการพึ่งพาที่ซ่อนอยู่ ดังนั้นสำหรับกฎข้อที่ 2:

  • ทำให้การอ้างอิงทั้งหมดของคุณชัดเจน

ประการที่สามไม่ใช่โปรแกรมเมอร์ทุกคนที่มีความสามารถในการบำรุงรักษาหรือการเขียนอย่างเท่าเทียมกันโดยใช้คุณสมบัติหรือเทคนิคสำนวนภาษาขั้นสูง การลดจำนวนฐานรหัสทั้งหมดจะทำให้คุณได้รับรหัสฐานขนาดใหญ่เนื่องจากขนาดมันยากที่จะรักษา การอนุญาตให้ใช้คุณสมบัติด้านเทคนิคขั้นสูงและสำนวนตลอดทั้งรหัสจะทำให้การบำรุงรักษาโค้ดทั้งหมดโดยนักพัฒนาอาวุโสสิ่งที่ไม่ดี กุญแจสำคัญในการบำรุงรักษาคือระดับชั้นตามทักษะตัวอย่าง:

ห้องสมุดข้ามโครงการ: ผู้พัฒนาซอฟต์แวร์ระดับสูง, รหัสเต็มด้านเทคนิค / สำนวน / เทคนิคโครงการห้องสมุดเฉพาะและแบ็กเอนด์ระบบ: ผู้พัฒนาที่เป็นคนกลาง, หลีกเลี่ยงขั้นสูงสุดและยากที่จะอธิบายสิ่งต่าง ๆ ผู้สูงอายุจะต้องใช้รหัสนี้ในการมองหาโอกาสในการปรับปรุง DRY

Front-end: junior devs ให้ใช้ไกด์นำเที่ยวที่เข้มงวดและชุดของเทคนิคการสร้างภาษาและสำนวนที่ควรหลีกเลี่ยง ผู้พัฒนาซอฟต์แวร์จะมองหาโอกาสในการทำธุรกิจและตรรกะทางธุรกิจที่ซ่อนอยู่

ดังนั้นสำหรับกฎข้อที่ 3:

  • เลเยอร์รหัสของคุณตามระดับทักษะของนักพัฒนาและเขียนรหัสที่สามารถบำรุงรักษาได้

ผม


1
นี้ไม่ได้ดูเหมือนจะนำเสนออะไรที่สำคัญกว่าจุดทำและอธิบายในก่อน 25 คำตอบ
ริ้น

@gnat ฉันหวังว่าจะเพิ่ม 'ความแตกต่างเล็กน้อย' ให้กับ oversimplifications (ที่อาจเป็นอันตราย) จำนวนมากในคำตอบอื่น ๆ โดยเฉพาะอย่างยิ่งกับจุดที่ 3
1703394

1
@ user1703394 คำถามนี้และคำตอบคือ wiki ชุมชน หากคุณรู้สึกว่าคำตอบที่มีอยู่สามารถปรับปรุงได้คุณสามารถแก้ไขได้แม้จะไม่มีสิทธิ์ "แก้ไขโพสต์ของผู้ใช้คนอื่น"

-2

มันไม่ง่ายเกินไปที่จะพยายามเขียนโค้ดที่อ่านได้และบำรุงรักษาได้ง่าย แต่ก็ไม่ยากที่จะเขียนโค้ดที่ง่ายและบำรุงรักษาได้

OOAD เป็นคำตัวอักษรสี่ตัว แต่ยากที่จะเข้าใจในการวิเคราะห์และออกแบบเชิงวัตถุ

  1. เริ่มต้นด้วยการรวบรวมความต้องการที่ดีและคำแถลงปัญหาที่แน่นอนเสมอ

    • เริ่มต้นด้วยการใช้งานไม่กี่กรณีเช่น; ปฏิสัมพันธ์โต้ตอบผู้ใช้ระบบ
  2. คุณต้องเก็บวัตถุของคุณไว้อย่างแน่นหนาและแน่ใจว่ารหัสของคุณจะไม่ซ้ำ - ติดตาม DRY [อย่าทำซ้ำตัวเอง]

    • เมื่อใดก็ตามที่คุณเห็นสิ่งที่ซ้ำกันให้ค้นหาสถานที่ที่จะแค็ปซูล
  3. รหัสของคุณจะเปิดสำหรับการขยายและปิดเพื่อการปรับเปลี่ยน - OCP [หลักการแบบเปิดปิด]
  4. เมื่อคุณเปลี่ยนรหัสของคุณโปรดจำไว้เสมอ - อย่าสร้างปัญหาเพื่อแก้ปัญหา IT เพียงระบุว่าอย่าแก้ไขฟังก์ชันการทำงานที่มีอยู่ของคุณ
  5. หน่วยทดสอบรหัสของคุณ
    • ทดสอบรหัสของคุณเมื่อสิ่งผิดปกติเสมอ
  6. ในขณะที่ทำงานกับการทำงานอย่าลืมปฏิบัติตามพื้นฐาน OOP (หลักการเชิงวัตถุ) และเทคนิคต่าง ๆ เพื่อให้แน่ใจว่าแอปพลิเคชันของคุณได้รับการออกแบบมาอย่างดีตั้งแต่เริ่มต้น
    • วัตถุควรทำตามชื่อที่ระบุ
    • แต่ละวัตถุควรแสดงถึงแนวคิดเดียว
  7. จดจำคำแถลงปัญหาของระบบเสมอและซอฟต์แวร์บริบท / โดเมนทำงานอย่างไร
  8. ทำงานกระดาษด้วยเหมือนกันใช่ไหมที่เหมาะกับฉัน
    • การมีสิ่งที่เกี่ยวข้องกับ UI บางส่วนและไดอะแกรม UML จะทำงานได้เสมอ
    • คุณยังสามารถจับภาพหน้าจอของเซสชันระดมสมองจากกระดานไวท์บอร์ดได้เช่นกัน
  9. รูปแบบสถาปัตยกรรม
  10. ใช้หลักการออกแบบถ้าเป็นไปได้
  11. เอกสาร
    • เอกสารรหัสของคุณเสมอ
    • ตั้งค่าการเยื้องใน IDE และเอกสารด้วย

1
นี่คือทฤษฎีที่ไม่ตอบคำถามเราจะหาปริมาณหรือวัดคุณภาพของรหัสเพื่อให้เรารู้ว่าสามารถอ่านเข้าใจและบำรุงรักษาได้อย่างไร คำถาม
Jan Doggen

ตกลง !! แต่ถ้าเราปฏิบัติตามหลักการที่กล่าวมาแล้วง่ายต่อการวัดคุณภาพของรหัสอ่านเข้าใจง่ายและบำรุงรักษาได้อย่างชัดเจน ช่วยแก้ให้ด้วยนะถ้าฉันผิด.
Narender Parmar

ฉันไม่รู้ว่าทำไมคำตอบของฉันถูกลดระดับลงแม้ว่าฉันจะครอบคลุมประเด็นสำคัญแล้ว
Narender Parmar
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.