คุณพิจารณาถึงหลักการที่ 1 ของการเขียนโปรแกรมอย่างไร


59

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

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


เราไม่ได้พูดถึงการต่อสู้กับสโมสร
งาน

คำตอบ:


97
  1. KISS - ทำให้มันงี่เง่า
  2. แห้ง - อย่าทำซ้ำตัวเอง
  3. YAGNI - คุณไม่ต้องการมัน

จูบควรเป็น Keep It Simple Smart ครั้งแรกที่คุณต้องเขียนโค้ดขนาดใหญ่อีกครั้งเนื่องจากคุณไม่ได้ออกแบบอย่างชาญฉลาดและสามารถขยายได้คุณจะเห็นด้วยกับสิ่งนี้ :)

8
ฉันคิดว่า KISS ควรเป็น "Keep It Simple, Stupid!"
Dennis C

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

10
ฉันจะเพิ่ม YAGNI ด้วย

3
@Programmin Tool - ฉันไม่คิดว่า "โง่" นั้นฟุ่มเฟือย ฉันคิดว่ามันบ่งบอกว่าเรามีแนวโน้มที่จะต้องการ "ฉลาด" และสิ่งนี้แสดงให้เห็นถึงความซับซ้อนที่ไม่จำเป็น อย่างที่ฉันเห็นมัน "โง่" พยายามเตือนเราถึงแนวโน้มนี้โดยช่วยให้เราจดจำสิ่งที่เราคิดว่าเริ่มแรกคือ "ฉลาด" มักจะไม่
codekaizen

37

เขียนรหัสเช่นถ้าเป็นคุณที่จะต้องรักษารหัสนั้น


นี่เป็นฮิวริสติกที่ใช้ประโยชน์ได้จริง, 3x :)

19
เขียนรหัสราวกับว่า psycopath ขวานกวัดแกว่งจะต้องรักษามัน FTFY
Semicolon ที่ถูกลืม

10
... และโรคจิตขวานควงรู้ว่าคุณอยู่ที่ไหน
CAD bloke

2
.. และเขาได้รุนแรงขึ้นเพียงขวานของเขา ...
Roalt

1
... และเขากำลังทำงานเคียงข้างคุณ
Broken_Window

29

จงขี้เกียจที่สุดเท่าที่จะทำได้


2
อีกครั้งโดยทั่วไปเกินไป IMO คำถามนี้ทำให้เกิดคำถามว่า "ความเกียจคร้านในปริมาณที่เหมาะสมคือความขี้เกียจจริง ๆ ?" เพราะเห็นได้ชัดว่า "เลอะเทอะ" เป็นสิ่งที่คุณไม่ต้องการ

นี่คือการอ้างอิงถึง "Laziness, Impatience, and Hubris" ของ perl "

ดังนั้นเรากำลังพูดถึงความเกียจคร้านแบบต่าง ๆ ? ฉันคิดโดย "ขี้เกียจ" Bob หมายความว่า "อย่ากังวลกับการจัดระเบียบรหัสของคุณก่อนที่มันจะยุ่งเหยิง": D

2
กว้างเกินไป โดยการเปรียบเทียบตัวแปรและฟังก์ชั่นทั้งหมดจะเป็นตัวอักษร 1 ตัวเพราะฉัน 'ขี้เกียจเกินไป' ในการพิมพ์สิ่งที่มีความหมาย สมมติว่าฉันต้องรักษามันด้วยอย่างไรก็ตามบางทีคุณอาจถูกต้องเพราะฉันจะทำให้มันบำรุงรักษาได้ง่ายที่สุด
Kyle Ballard

3
@ Kyle: ใช่นั่นคือจุด "ความเกียจคร้านที่แท้จริง" กำลังทำให้ทุกอย่างง่ายขึ้นสำหรับตัวคุณเองในตอนนี้และในอนาคต ซึ่งกลับกลายเป็นเหมือนทำสิ่งที่ถูกต้อง ถ้าคุณทำทำงานน้อยลง แต่ตอนนี้ทำงานมากขึ้นต่อมาคุณไม่ได้เป็น "ขี้เกียจที่เป็นไปได้" :)

23

Zen, part I: การเขียนโปรแกรมเป็นเพียงถนนไม่ใช่ทาง

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

Zen, part II: ถ้าคุณรีบรีบเดินไปช้า ๆ หากคุณกำลังรีบจริงๆให้อ้อม

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

ข้อผิดพลาดในการออกแบบนั้นหายากที่สุดและ / หรือแก้ไขขั้นตอนต่อไปคือข้อผิดพลาดในการเขียนโปรแกรมในส่วนที่ทุกคนต้องพึ่งพาจากนั้นส่วน "การแสดงซอฟต์แวร์ออกจริง" หากคุณต้องการแก้ไขข้อผิดพลาดในการออกแบบในตอนท้ายของโครงการ ummm นั่นไม่ดี ... ;-)

Zen, ส่วนที่ III: รู้เส้นทางของคุณ, Neo

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


เอ่อแล้วอีกครั้ง: ฉันเป็นเจ้าของที่ดินในที่ดินเซนขณะที่พูดเกี่ยวกับการเขียนโปรแกรม :)

@part III - อย่าเพิ่ม "สิ่งแปลกใหม่" เว้นแต่คุณจะได้รับเงินเพื่อทำมัน!
46499 Jason

+1 สำหรับการอ้างอิงเมทริกซ์ ฉันเป็นคนดูดคนดี (นั่นและเซนทำให้ฉันคิดถึง Python)

19

KISS (ทำให้มันง่ายโง่)

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


ฉันคิดว่านี่เป็นกฎทั่วไปเกินไป มันทำให้เกิดคำถามว่า "คุณจะกำหนด 'ง่าย' ได้อย่างไรจริง ๆ "

3
และถ้าคุณโง่คุณจะรู้ได้อย่างไรว่ามันเป็นเรื่องง่าย
Steven A. Lowe

นั่นเป็นสิ่งที่ดีสตีเวน :)

1
"นี่คือสาเหตุที่คุณไม่สามารถเป็นโปรแกรมเมอร์ที่ดีได้เพียงแค่รู้หลักการแรกของการเขียนโปรแกรม" - รักมัน

1
@Dima: ถูกต้องฉันหมายถึงคุณภาพและความเรียบง่าย (อย่างน้อยในกรณีนี้) นั้นไม่สามารถระบุได้ แต่เรารู้เมื่อเห็นถ้าตาของเราได้รับการฝึกฝน
Adriano Varoli Piazza

18

การเพิ่มประสิทธิภาพก่อนวัยอันควรเป็นรากฐานของความชั่วร้ายทั้งหมด - Donald Knuth


ไม่ว่าจะในการนำไปใช้หรือการออกแบบ

16

อย่าบูรณาการล้อ


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

5
ต้องมีการปรับแต่ง "ล้อ" บางส่วน

บอกต่อ Dunlop เขาคิดค้นยางลม ถ้ามันไม่ได้สำหรับเขาแล้วคิดค้นล้อใหม่เราจะต้องเจอกับการขับรถ
Kibbee

3
เกี่ยวกับวิธีการ: คิดค้นนวัตกรรมใหม่เฉพาะล้อหากผลประโยชน์จะคุ้มค่ากับราคา
e.James

16

ทำความเข้าใจปัญหาก่อน!


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

@ e-Satisfaction: Yeap นั่นคือสิ่งที่ฉันคิดว่าเมื่อฉันตอบคำถามนี้เป็นครั้งแรก ฉันเลื่อนดูคำตอบทั้งหมดและไม่น่าแปลกใจที่ไม่มีใครโพสต์มาก่อน
OscarRyz

คำตอบที่ดี. ชั่วโมงและเวลาสูญเปล่าเมื่อโปรแกรมเมอร์ไม่เข้าใจความต้องการอย่างครบถ้วนของปัญหา
Steve Wortham

ปัญหาคือ: คุณรู้ได้อย่างไรว่าคุณเข้าใจปัญหา?
CamelCamelCamel

13

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

ฉันคิดว่ามันทำงานควบคู่กับการออกแบบแบบแยกส่วน: คุณสมบัติในอนาคตสามารถเพิ่มได้โดยไม่ต้องออกแบบรหัสที่มีอยู่


12

รู้เมื่อไม่ได้โปรแกรม


สิ่งนี้บนโลกควรจะหมายถึงอะไร

และเมื่อไร

บางครั้งคุณต้องจัดการกับปัญหาของผู้ใช้ที่แตกต่างกัน - ไม่ใช่แค่รหัสวิธีแก้ไขปัญหา

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

1
สิ่งที่เขาหมายถึงคือปัญหาการเขียนโปรแกรมจำนวนมากสามารถแก้ไขได้ราคาถูกลงและทันเวลามากขึ้นด้วยการซื้อแอพพลิเคชั่นชั้นวางส่วนประกอบหรือไลบรารี
Gordon Bell

11

กาแฟในรหัสออก


3
Tea in in my case =)

+1 มากกว่าอืมเช่น "Coffee In, โค้ด + ช่วงหยุดพักลูมาก ๆ " :) ฉันรักทั้งกาแฟและชาฉันแกว่งไปมาทั้งสอง ...
Darknight


7

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

- Charles Antony Richard Hoare


6
  1. แยกแยะระหว่างสาเหตุและผลกระทบ (ทำงานกับคอมพิวเตอร์)

  2. แยกแยะระหว่างข้อเท็จจริงและความคิดเห็น (ทำงานกับผู้คน)

  3. เรียบง่ายที่สุดเท่าที่จะทำได้ แต่ไม่เรียบง่ายกว่า (การออกแบบ)


5

การเขียนโปรแกรมเป็นวิธีการที่ไม่สิ้นสุด หรือบางที "ไม่สามารถหมายความว่าควร"


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

พูดได้ดี! couldnt เห็นด้วยมากขึ้น
1416 Antony

5

ในความคิดของหลักการที่สำคัญที่สุดคือการลดลงของความซับซ้อนโดยการสร้างแนวคิดที่ดี

ซึ่งรวมถึง

  • การเข้าใจปัญหาที่จะแก้ไข
  • การออกแบบทางออกที่เหมาะสมสำหรับมันและ
  • ใช้มัน
  • ควรเป็นวิธีที่ทำให้โค้ดสามารถเข้าใจและบำรุงรักษาได้

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


4

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

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


4

มันไม่ทำงานจนกว่าคุณจะแสดงในการทดสอบ


6
ไม่เป็นความจริงฉันเขียนโค้ดที่ใช้ได้และไม่ได้ทดสอบ! : D

1
"ฉันไม่ได้ทดสอบมันฉันได้พิสูจน์ให้เห็นเพียงว่ามันถูกต้อง" :)
แดเนียล Daranas

4

คิดก่อนรหัสในภายหลัง

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

เมื่อทำการดีบั๊กคำตอบแรกมักจะผิด

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


3

ปัญหาใด ๆ ก็สามารถแก้ไขได้ด้วยการอ้อมอีกชั้นหนึ่ง


ที่จริงแล้วการมีทางอ้อมมากเกินไปเป็นปัญหาที่รอการระบุและแก้ไข ดังนั้น ..

แก้ไขแล้ว ... โดยอ้อมอีกชั้น! =)
Erik Forbes

ผิดปกติพอมันจริง ดูที่ Spring ...


3

หลักการ: ซอฟแวร์จับความรู้

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

เทคนิคต่าง ๆ สำหรับการแสดงขั้นตอนทั้งหมดที่ตั้งอยู่บนพื้นฐานลำดับ , Choice , การทำซ้ำ



3

เสมอเขียนรหัสราวกับว่าคนที่จะรักษามันเป็นฆาตกรต่อเนื่องโรคจิตที่รู้ว่าคุณอยู่ที่ไหน

อย่าคิดว่าคุณรู้ทุกอย่างเกี่ยวกับการเขียนโปรแกรม


2

ฉันได้เขียนโปรแกรมโดยการศึกษาอุปกรณ์อิเล็กทรอนิกส์ดิจิทัลดังนั้นฉันเดาว่าฉันมีประตูตรรกะพื้นฐาน (ไม่ใช่และหรือหรือ xor หมายถึง) เป็นหลักการแรกของการเขียนโปรแกรม



2

ขยะใน - ขยะไม่สำคัญว่าส่วนต่อประสานผู้ใช้ของคุณดีแค่ไหนหากข้อมูลไม่ดี


2

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


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