ออกแบบซอฟต์แวร์: สร้างมันเร็วหรือสร้างมันดี?


38

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

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


10
"ไม่เคยมีเวลาทำถูกต้อง แต่มีเวลาทำมากกว่าเสมอ"
Scott Whitlock

1
คุณรู้ว่าที่ปรึกษาทางการเงินบอกว่าอย่าไปสู่หนี้ได้อย่างไร อย่าไปเป็นหนี้ทางเทคนิคทั้ง :)
นิโคล

3
การอ้างอิง xkcd บังคับ: xkcd.com/844
281377

@ammoQ เอาชนะฉันไป

1
Steven: จากประสบการณ์ของฉันข้อสันนิษฐานนั้นยังคงอยู่ในขณะที่ความต้องการในอนาคตตกอยู่ในช่วงที่คาดหวัง แต่บางครั้งข้อกำหนดใหม่จำเป็นต้องมีบางอย่าง "การมีปฏิสัมพันธ์ที่น่ากลัวในระยะไกล" ซึ่งเป็นเรื่องยากกว่าที่จะนำมาใช้ในการออกแบบที่เหมาะสมเพราะสิ่งที่แยกจากชั้นเรียนอย่างเป็นชั้น ๆ เลเยอร์ ฯลฯ ในทันทีนั้นจำเป็นต้องสื่อสาร .
281377

คำตอบ:


48

สร้างมันได้ดี

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

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

ในคำอื่น ๆ (ยกเว้นกรณีนี้คือการทำสัญญาใดอย่างหนึ่งและทำ) สร้างมันขึ้นมาได้อย่างรวดเร็ว = สร้างมันช้าสร้างมันได้ดี = สร้างมันได้อย่างรวดเร็ว


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

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

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

กฎของ John Gall จากSystemantics :

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


9
ฉันไม่สามารถลงคะแนนได้มากพอ อีกคำพูดที่ดีมาจากลุงบ๊อบ"วิธีเดียวที่จะไปอย่างรวดเร็วคือไปได้ดี"
CaffGeek

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

4
เพื่อเป็นเกียรติแก่พ่อของฉัน "ถ้าคุณครึ่งตูดครั้งแรกคุณจะมีปริมาณงานเพิ่มขึ้นเป็นสองเท่าเมื่อคุณกลับไปแก้ไข"
นาย Ant

เฮ้ ... สูตรทำให้ฉันคิดว่า: สร้างมันได้ดี = สร้างมันเร็ว = สร้างมันช้า ฉันเดาว่า "สร้างมันเร็ว" ครั้งสุดท้ายควรสร้างให้น้อยลงซึ่งเป็นหนี้ทางเทคนิค เนื่องจากต้องทำงานน้อยลงเพื่อสร้างระบบที่ดี
Spoike

@Spike ฉันเห็นด้วย แต่ความคิดก็คือ "สร้างมันให้ดี = สร้างมันขึ้นอย่างรวดเร็วในภายหลัง " ผู้จัดการหลายคนไม่ต้องการที่จะยอมแพ้ความเร็วสักสองสามเดือนเพื่อที่จะเพิ่มความเร็วในภายหลัง
Nicole

17

เร็วแล้วดี

นี่เป็นประสบการณ์ส่วนตัวของฉันที่ได้ลองวิธีการมากมาย

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

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

ก่อนอื่นเร็วแล้ว!

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

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

ด้วยวิธีนี้คุณจะจบลงด้วยแอปพลิเคชันที่มีสถาปัตยกรรมเสียงที่มีประสิทธิภาพที่สุดเท่าที่จะเป็นไปได้ในประสบการณ์ของฉันต่อไป :)


2
+1 ใช่ฉันเพิ่ม - ใช้วิธีวนซ้ำ ..
pmod

ฉันเห็นด้วยกับคำตอบนี้ และฉันเห็นด้วยกับ pmod
Kim Jong Woo

ความเร็วของการวนซ้ำเต้นคุณภาพของการวนซ้ำ - ตาม StackExchange ด้วยตัวเอง - ตัวอย่างที่ดี - codinghorror.com/blog/2010/09/go-that-way-really-fast.html
jasonk

10

สร้างมัน

รวดเร็วถ้าเวลาไปตลาดสำคัญกว่าคุณภาพ

ดีถ้าคุณภาพสำคัญกว่าเวลาในการตลาด


8

การสร้างอย่างรวดเร็วจะให้ผลประโยชน์ระยะสั้นและการสูญเสียในระยะยาว

การสร้างมันอย่างดีจะทำให้เกิดการสูญเสียเวลาสั้น ๆ แต่จะได้ประโยชน์ในระยะยาว

การสร้างมันขอความอดทนและภูมิปัญญาอย่างดี แต่คุณจะได้รับรางวัล

การสร้างอย่างรวดเร็วนั้นดีสำหรับการสร้างต้นแบบและสิ่งที่ทิ้งอย่างรวดเร็วเท่านั้น เป้าหมายระยะยาวสามารถทำได้โดยมีทัศนคติที่ถูกต้องตั้งแต่เริ่มต้น


5

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

บางครั้งมันอาจช้าอย่างน่าผิดหวัง สิ่งที่ควรทำมีค่าควรทำในสิ่งที่ถูก


1
เพียงมีคุณสมบัติในคำสั่ง "คิดดี": มันไม่ได้หมายถึงการคิดทุกอย่างล่วงหน้า (สิ่งนี้ไม่สามารถทำได้) แต่เพียงสละเวลาสักครู่เพื่อคิดว่าการบูรณาการคุณลักษณะมากกว่าการโยนมันที่ไหนสักแห่งและทำกับมัน .
Matthieu M.

5

สร้างมันให้ดี = สร้างมันอย่างรวดเร็ว

ทางลัดมีแนวโน้มที่จะหมุนไปมาและกัดคุณเร็วขึ้นกว่าที่คุณคิด บางครั้งแม้แต่ก่อนอาหารกลางวัน

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


3

ถ้าคุณรู้อยู่แล้วว่าคุณกำลังทำอะไรอยู่ถ้าคุณไม่ทำ

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

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

2

สร้างมันให้ดี .. เสมอ แต่ให้ภาพลวงของการไปเร็ว

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


+1 สร้างเฉพาะสิ่งที่จำเป็นจริงๆ
Nicole

1

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


1

สมดุล

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

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


แก้ไข. สร้างให้ดีที่สุดเท่าที่จะเป็นไปได้ตามเวลาที่กำหนด
jwenting

1

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


0

ซึ่งฉันคาดว่าจะแปรเปลี่ยนเมื่อฉันได้รับข้อเสนอแนะจากผู้คน

คุณพูดได้ดีที่สุด:

แต่ฉันก็เคยอยู่ในสถานการณ์ที่คุณเกิดหนี้สินทางเทคนิคมากมายจากทางลัดซึ่งรหัสนั้นยากที่จะรักษาและเพิ่มคุณสมบัติใหม่ ๆ

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


0

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


0

สร้างมันได้ดี หากคุณไม่มีเวลาให้ลดการตั้งค่าคุณสมบัติ

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


0

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

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

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

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

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

นั่นเป็นวิธีการที่ฉันใช้เมื่อทำงานอย่างมืออาชีพ ;)


0

ฉันขอแนะนำให้ก่อนอื่นคุณควรจะยืนซอฟต์แวร์ครอบคลุมทุกด้านและยืนซอฟต์แวร์ก่อนแล้วค่อยตกแต่งและปรับปรุงการแสดงของมัน


-1

โดยปกติคุณต้องการอยู่ตรงกลางของขอบทั้งสองนี้:

สร้างซอฟต์แวร์ที่ดี = ชีวิตแบบเรียลไทม์ที่สำคัญซึ่งชีวิตของผู้คนขึ้นอยู่กับ เช่นการควบคุมซอฟต์แวร์: เครื่องปฏิกรณ์นิวเคลียร์, เครื่องล้างไต, เครื่องMRIเป็นต้น

สร้างอย่างรวดเร็ว = ซอฟต์แวร์ไร้ประโยชน์ที่ไม่มีใครใช้งานจริง


ฮ่า! สร้างซอฟแวร์ที่ไร้ประโยชน์ ...
pmod

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