Thiết kế phần mềm: Xây dựng nó nhanh hay xây dựng nó tốt?


38

Khi xây dựng một ứng dụng không tầm thường, tốt nhất bạn nên tập trung vào việc làm mọi thứ hoạt động nhanh chóng và sử dụng các phím tắt trong mã như trộn logic mô hình với các khung nhìn của bạn, phá vỡ đóng gói - mùi mã điển hình? Hoặc, tốt hơn hết là bạn nên dành thời gian trả trước để xây dựng thêm kiến ​​trúc, xây dựng nó đúng, nhưng có nguy cơ rằng tất cả các mã bổ sung này có thể không được sử dụng do thiết kế của bạn khá trôi chảy và bạn có thể phải vứt nó đi nếu phản hồi gây ra cho bạn để đi theo một hướng khác?

Đối với bối cảnh, tôi đang xây dựng một ứng dụng máy tính để bàn. Tôi là nhà phát triển duy nhất và tôi đang làm việc bán thời gian này kể từ khi tôi có một công việc ban ngày. Bây giờ, đối với công việc, tôi cố gắng làm mọi thứ đúng cách, lịch trình cho phép. Nhưng đối với dự án này, điều mà tôi mong đợi sẽ biến đổi khi tôi nhận được phản hồi từ mọi người, tôi không chắc đó là cách tiếp cận đúng đắn. Tôi đã dành vài giờ trong tuần này để đưa vào thiết kế sách giáo khoa Model View Controller để truyền đạt các thay đổi trong mô hình tới chế độ xem. Điều này nói chung là tuyệt vời, nhưng tôi không chắc mình có cần nhiều chế độ xem để hiển thị dữ liệu hay không và tôi biết rằng tôi có thể có những thứ được hiển thị nhanh hơn mà không cần kiến ​​trúc bổ sung. Có thể dành khoảng 10 - 15 giờ mỗi tuần cho dự án, tôi cảm thấy sẽ mất nhiều thời gian để có được thứ gì đó được xây dựng mà tôi có thể demo nếu tôi tuân thủ các thực hành phần mềm tốt. Tôi biết rằng người dùng của tôi đã thắng ' Tôi quan tâm rằng tôi đã sử dụng MVC trong nội bộ, họ chỉ muốn một cái gì đó giải quyết vấn đề của họ. Nhưng tôi cũng đã ở trong tình huống bạn phải gánh chịu quá nhiều nợ kỹ thuật do bị cắt ngắn mà mã rất khó để duy trì và thêm các tính năng mới vào. Tôi rất muốn nghe cách người khác tiếp cận loại vấn đề này.


10
"Không bao giờ có thời gian để làm điều đó đúng, nhưng luôn có thời gian để làm điều đó hơn."
Scott Whitlock

1
Bạn có biết làm thế nào các cố vấn tài chính nói rằng đừng mắc nợ? Đừng mắc nợ kỹ thuật :)
Nicole

3
tham chiếu xkcd bắt buộc: xkcd.com/844
user281377

@ammoQ đánh tôi với nó.

1
Steven: Theo kinh nghiệm của tôi, giả định đó được duy trì trong khi các yêu cầu trong tương lai rơi vào phạm vi dự kiến ​​(và được chuẩn bị theo quan niệm); nhưng đôi khi, một yêu cầu mới cần một số "tương tác ma quái trên một khoảng cách" thậm chí còn khó thực hiện hơn trong một thiết kế phù hợp, bởi vì tất cả các lớp, các lớp được phân tách gọn gàng, v.v ... đột nhiên cần phải giao tiếp theo cách mà thiết kế không được chuẩn bị cho .
user281377

Câu trả lời:


48

Xây dựng nó tốt .

Xây dựng nó "nhanh" là một ngụy biện logic nếu bạn nhìn vào bức tranh lớn. Nó sẽ ngăn bạn không bao giờ xây dựng nó tốt, và cuối cùng bạn sẽ bị sa lầy bởi các lỗi và lỗ hổng kiến ​​trúc cơ bản ngăn cản tái cấu trúc hoặc thậm chí làm cho việc thêm các tính năng mới bên cạnh không thể.

Xây dựng nó tốt thực sự là ngược lại. Lúc đầu, nó có thể chậm hơn, nhưng cuối cùng bạn sẽ nhận ra hiệu quả đạt được từ việc dành thời gian để đưa ra những lựa chọn đúng đắn. Ngoài ra, bạn sẽ có thể thích ứng với các yêu cầu trong tương lai dễ dàng hơn (tái cấu trúc nếu cần) và bạn sẽ có một sản phẩm cuối tốt hơn, ít nhất là, ít lỗi hơn.

Nói cách khác (trừ khi đây là hợp đồng một lần thực hiện), hãy xây dựng nó nhanh = xây dựng nó chậm, xây dựng nó tốt = xây dựng nó nhanh .


Ngoài ra có một điều quan trọng để nhận ra về "xây dựng nó tốt" và thiết kế một kiến ​​trúc. Bạn đã hỏi...

... Nhưng có nguy cơ rằng tất cả các mã bổ sung này có thể không được sử dụng do thiết kế của bạn khá trôi chảy và bạn có thể phải vứt nó đi nếu phản hồi khiến bạn đi theo một hướng khác?

Đó không thực sự là một rủi ro thực sự từ "dành thời gian kiến ​​trúc". Thiết kế kiến ​​trúc nên hữu cơ . Đừng dành thời gian thiết kế kiến ​​trúc cho bất kỳ phần nào cho đến khi nó hợp lý. Kiến trúc chỉ nên phát triển từ các mẫu được quan sát và xác nhận trong dự án của bạn.

Luật của John Gall từ Systemantics :

Một hệ thống phức tạp được thiết kế từ đầu không bao giờ hoạt động và không thể vá để làm cho nó hoạt động. Bạn phải bắt đầu lại, bắt đầu với một hệ thống đơn giản làm việc.


9
Tôi không thể nâng cao đủ. Một câu nói hay khác là của chú Bob "Cách duy nhất để đi nhanh là đi thật tốt"
CaffGeek

1
+1 vì một khi bạn đã thực hiện tốt, bạn có thể sử dụng lại mã đó và tiếp cận lại trong dự án tiếp theo và nó sẽ còn nhanh hơn nữa. Rửa sạch và lặp lại cho đến khi nó là bản chất thứ hai.
Gary Rowe

4
Để vinh danh cha tôi, "Nếu bạn nửa khẳng định nó lần đầu tiên, thì bạn sẽ có gấp đôi số lượng công việc khi bạn quay lại để sửa nó."
Ông Ant

Heh ... công thức làm tôi nghĩ: xây dựng nó tốt = xây dựng nó nhanh = xây dựng nó chậm. Tôi đoán rằng "xây dựng nó nhanh" nên được xây dựng với chi phí thấp hơn về mặt nợ kỹ thuật. Vì ít công việc là cần thiết để xây dựng trên một hệ thống được thực hiện tốt.
Spoike

@Spoike Tôi đồng ý nhưng cũng có ý tưởng là "xây dựng nó tốt = xây dựng nó nhanh hơn sau này ". Vì vậy, nhiều nhà quản lý không muốn từ bỏ tốc độ trong một vài tháng sẽ thực sự tăng tốc độ sau này.
Nicole

17

Nhanh rồi

Đây là từ kinh nghiệm cá nhân của tôi đã thử rất nhiều phương pháp khác nhau.

Vấn đề với việc chỉ hoạt động nhanh (và phát hành) nói chung là bạn sẽ giải quyết tính năng sau khi tính năng vào ứng dụng của bạn và vì nó được phát hành nên rất khó để thực hiện các thay đổi cơ bản cho chương trình của bạn. Bạn phải trả giá đắt trong thời gian dài vì không có gì có kiến ​​trúc cơ bản, nó giống như xây dựng một vụ lùm xùm trên cát lún.

Chương trình làm tốt điều đó là bạn sẽ lãng phí rất nhiều thời gian và mã. Nó giống như xây dựng một biệt thự mà không có bất kỳ bản thiết kế nào. Viết ứng dụng là một quá trình học tập và hầu như (theo kinh nghiệm của tôi) không thể thiết kế trước. Điều đó có nghĩa là bạn sẽ thực hiện nhiều thao tác tái cấu trúc và nếu bạn viết mọi thứ "tốt" mọi lúc, cuối cùng bạn sẽ vứt đi rất nhiều mã.

Thefor, nhanh, sau đó tốt!

Điều chính khi bạn bắt đầu chỉ là lấy mọi thứ trong mã để có thể đóng đinh tất cả các tính năng và xem loại kiến ​​trúc nào bạn cần hỗ trợ. Một điều tốt nữa về phương pháp đo lường này là tôi sẽ giúp bạn có động lực vì bạn sẽ nhanh chóng có thứ gì đó chạy. Điều quan trọng nữa là phải thực hiện một số chức năng "trường hợp cạnh" vì điều đó sẽ có tác động đến kiến ​​trúc chung của bạn. Đừng bận tâm viết bài kiểm tra đơn vị hoặc làm việc trên các chi tiết ở giai đoạn này. Nếu bạn nghĩ rằng bạn sẽ cần hỗ trợ đa ngôn ngữ trong tương lai, một kiến ​​trúc plugin không có gì, thực hiện nó, nhưng nhanh và bẩn. Thực hiện một số tái cấu trúc để giữ cho ứng dụng có thể quản lý được nhưng không có gì quá mức.

Sau khi bạn cảm thấy bạn có một "nguyên mẫu" đang hoạt động, đã đến lúc bắt đầu tái cấu trúc. Về cơ bản, bạn muốn làm lại ứng dụng như bạn đã làm nếu bạn bắt đầu từ đầu biết mọi thứ bạn biết bây giờ. Điều quan trọng là làm cho kiến trúc đúng, không phải thực hiện lại tất cả các tính năng bạn đã làm trong giai đoạn một, nhưng bạn nên có kiến ​​trúc tại chỗ để hỗ trợ nó sau này.

Bằng cách này, bạn sẽ kết thúc với một ứng dụng có kiến ​​trúc âm thanh hiệu quả nhất có thể, theo kinh nghiệm của tôi dù sao đi nữa :)


2
+1 Yeh, tôi đã thêm - sử dụng phương pháp lặp lại ..
pmod

Tôi đồng ý với câu trả lời này. Và tôi đồng ý với pmod.
Kim Jong Woo

Tốc độ lặp lại nhịp đập chất lượng lặp đi lặp lại - theo StackExchange mình - với một số ví dụ tốt - codinghorror.com/blog/2010/09/go-that-way-really-fast.html
jasonk

10

Xây dựng nó

Nhanh chóng nếu thời gian để thị trường quan trọng hơn chất lượng

Vâng, nếu chất lượng quan trọng hơn thời gian đưa ra thị trường


8

Xây dựng nó nhanh sẽ mang lại cho bạn lợi ích ngắn hạn và tổn thất dài hạn.

Xây dựng nó tốt sẽ chịu tổn thất trong thời gian ngắn nhưng lợi ích lâu dài.

Xây dựng nó cũng đòi hỏi sự kiên nhẫn và khôn ngoan nhưng bạn sẽ được đền đáp.

Xây dựng nó nhanh chỉ tốt cho tạo mẫu nhanh và vứt bỏ mọi thứ. Mục tiêu dài hạn chỉ có thể đạt được với thái độ đúng đắn ngay từ đầu.


5

Đối với các dự án mà bạn dự định phân phối cho người khác sử dụng, tôi sẽ luôn gặp lỗi ở phía trước của công việc trước. Một kiến ​​trúc được suy nghĩ tốt sẽ dễ dàng mở rộng hơn nếu cần. Cắt ngắn chỉ là mô hình để tích lũy nợ kỹ thuật.

Nó có thể chậm một cách bực bội. Những việc đáng làm là đáng làm.


1
Chỉ để đủ điều kiện tuyên bố "nghĩ tốt": điều đó không có nghĩa là suy nghĩ về mọi thứ ở phía trước (điều này không thể thực hiện được), mà chỉ cần dành một chút thời gian để suy nghĩ cách tích hợp một tính năng thay vì ném nó vào đâu đó và thực hiện với nó .
Matthieu M.

5

Xây dựng nó tốt = xây dựng nó nhanh chóng

Các phím tắt có xu hướng quay lại và cắn bạn thậm chí nhanh hơn bạn nghĩ. Đôi khi ngay cả trước khi ăn trưa.

Về bối cảnh của bạn; đừng trừu tượng ngay lập tức. Bám sát YAGNI và loại bỏ trùng lặp. Triển khai mẫu dựa trên Chế độ xem đó khi bạn thực sự có chế độ xem thứ hai không phải vì bạn nghĩ rằng bạn có thể có chế độ xem trong tương lai. Khi Chế độ xem thứ hai đó xuất hiện, sự trừu tượng mà bạn tạo thường tốt hơn nhiều so với chế độ xem mà bạn đã thực hiện xung quanh lần xuất hiện đầu tiên đó.


3

Chà nếu bạn đã biết những gì bạn đang làm, nhanh chóng nếu bạn không

Tôi là một nhà khoa học nghiên cứu và tôi viết rất nhiều mã khám phá trước khi tôi có bất kỳ manh mối nào về bức tranh lớn là gì hoặc dự án sẽ phát triển như thế nào. Trong những trường hợp này, thật khó để thấy "tốt" nên được định nghĩa như thế nào. Ngoài ra, thường rất khó để xem tất cả các chi tiết nhỏ và cách mọi thứ có thể được mở rộng trả trước. Do đó, câu ngạn ngữ cũ được áp dụng:

  1. Lam cho no hoạt động.
  2. Làm cho đúng Làm cho nó đúng thứ hai có lợi thế là bạn có thể xác định tốt hơn "đúng" một khi bạn đã có kinh nghiệm làm cho nó hoạt động.

2

Xây dựng nó tốt .. luôn luôn, nhưng đưa ra ảo tưởng về việc đi nhanh

nhưng để làm cho nó nhanh chỉ cần làm cho nó nhỏ hơn. Xây dựng một tập hợp con nhỏ của tổng thể đủ quan trọng để nhận phản hồi. Thêm dần dần vào nó với tốc độ không đổi sẽ mang lại nhiều lợi ích tương tự của việc xây dựng nhanh mà không bán linh hồn của bạn cho phản ứng dây chuyền của những đêm mất ngủ khi chơi whack-a-bug.


+1, chỉ xây dựng những gì thực sự cần thiết.
Nicole

1

Tôi nghĩ nó phải luôn luôn được "xây dựng tốt". Nếu thời gian để thị trường là một mối quan tâm lớn thì sử dụng một quá trình phát triển gia tăng. Trường hợp xấu nhất là bạn có một sản phẩm có ít tính năng hơn, nhưng ít nhất bạn có một sản phẩm chất lượng cao để xuất xưởng có thể được mở rộng trong các bản phát hành tính năng trong tương lai.


1

Cân đối

Nó không thực tế để thiết kế mã của bạn để hoàn thiện hoặc trộn một số mã với nhau trong nháy mắt, phải không? Nó thực sự về sự cân bằng nổi bật. Điều quan trọng trong quan điểm của tôi là những gì bạn làm khi nào.

Tôi nghĩ rằng điều quan trọng nhất ở đây là đảm bảo tuyệt đối cốt lõi của ứng dụng, cấu trúc cơ bản, được xây dựng thực sự tốt. Không khí kín. Khi đạt được điều đó, tùy thuộc vào các hạn chế về thời gian, nếu trong trường hợp bạn thiếu thời gian, bạn có thể lấy một số mã với nhau và tính lại nó sau, và bạn có thể chi trả cho sự xa xỉ đó bởi vì bạn sẽ cẩn thận để có được nền tảng đúng, và nó sẽ không ảnh hưởng đến mã yếu tố.


chính xác. Xây dựng nó tốt nhất có thể trong thời gian cho phép.
jwenting

1

Làm điều đơn giản nhất có thể có thể làm việc. Trong trường hợp cụ thể của bạn, chương trình của bạn sẽ không trở nên rất lớn, với bạn là người duy nhất làm việc bán thời gian. Tôi không ủng hộ cách cư xử tệ như lạm dụng goto, tên biến không cần thiết, v.v., nhưng bạn không nên làm cho nó phức tạp hơn mức cần thiết. Có lẽ MVC chỉ là quá mức cho dự án cụ thể của bạn.


0

mà tôi mong đợi sẽ biến hình khi tôi nhận được phản hồi từ mọi người

Bạn tự nói điều đó tốt nhất:

Nhưng tôi cũng đã ở trong tình huống bạn phải gánh chịu quá nhiều nợ kỹ thuật do bị cắt ngắn mà mã rất khó để duy trì và thêm các tính năng mới vào.

Nếu bạn thiếu thời gian, đừng ngại hỏi thêm thời gian để hoàn thành dự án từ chủ lao động của bạn bằng cách sử dụng lý do tương tự này. Tôi chắc chắn họ sẽ cấp nó cho bạn. Đã nói điều này, tôi hiểu rằng đôi khi có thể cảm thấy khó chịu như thế nào khi làm việc quá sức với một cái gì đó và không thể thể hiện rất nhiều kết quả. Nhưng đừng lo lắng, bạn sẽ đến đó và xây dựng nó tốt chắc chắn sẽ có giá trị khi bạn làm.


0

Thông thường tôi thích xây dựng cấu trúc tốt và tiết kiệm thời gian bằng cách không lo lắng về các chi tiết triển khai cụ thể. Giống như bạn nói, dù sao họ cũng sẽ thay đổi. Ý tưởng đằng sau việc xây dựng một cấu trúc được thực hiện tốt là những thay đổi có thể xảy ra rất nhanh, một khi cơ sở được xây dựng. Tôi cố gắng tập trung vào việc trở nên chung chung nhất có thể trong các lớp học của mình và làm cho chúng có thể trở lại nếu có thể. Tôi thường cung cấp cho người dùng một ứng dụng được xây dựng tốt, chỉ đáp ứng các yêu cầu về khả năng sử dụng cơ bản nhất. Người dùng nhận được tất cả các loại Ý tưởng khi có một công cụ trong tay, do đó, không có suy nghĩ nào để tiến xa.


0

Xây dựng nó tốt . Nếu bạn không có thời gian, hãy giảm tính năng thiết lập.

Thiết kế nó là phổ quát nhất có thể. Ví dụ: thiết kế một kiến ​​trúc plugin, ngay cả khi bạn biết, chỉ một plugin sẽ được sử dụng lần đầu tiên. Sử dụng các sơ đồ cấu hình phổ quát (cấu hình mở rộng, ngôn ngữ tổ chức), thậm chí chỉ có một tham số lúc đầu. Đó là một khoản đầu tư rất tốt và bạn chỉ có thể thực hiện khoản đầu tư này khi bắt đầu dự án.


0

tốt nhất là tập trung vào việc làm cho mọi thứ hoạt động nhanh chóng và sử dụng các phím tắt trong mã như trộn logic mô hình với các khung nhìn của bạn, phá vỡ đóng gói - mùi mã điển hình? Hoặc, tốt hơn hết là bạn nên dành thời gian trả trước để xây dựng thêm kiến ​​trúc

Trong tai tôi, cách bạn đặt nó ở đó, bạn đang liệt kê hai thái cực. Sự lựa chọn đầu tiên, phá vỡ đóng gói, đưa logic mô hình vào các khung nhìn, đó chỉ là lập trình lười biếng kém. IMHO, giải quyết những vấn đề đó không giống như đưa vào kiến ​​trúc nhiều hơn. Có lẽ trừ khi điều bạn đang nói là mã UI đang thực thi các câu lệnh SQL. Nhưng sau đó tôi sẽ không nói xây dựng thêm kiến ​​trúc, sau đó tôi sẽ nói rằng bạn hoàn toàn thiếu thiết kế và kiến ​​trúc và bạn nên lấy một kiến ​​trúc.

Khi nói đến kiến ​​trúc, tôi sẽ chọn cách đơn giản nhất giải quyết vấn đề của bạn ngay bây giờ, và sau đó mở rộng khi có vấn đề phát sinh.

Ví dụ: Đây là những gì bạn cần ngay bây giờ chức năng trả về dữ liệu từ một bảng cơ sở dữ liệu, tôi sẽ không lo lắng về các vấn đề như làm thế nào để tôi tải dữ liệu từ các bảng có liên quan, mặc dù tôi sẽ biết rằng vấn đề cuối cùng sẽ phát sinh. Tôi sẽ bắt đầu lo lắng về nó khi tôi thực hiện chức năng đó.

Vì vậy, đối với các dự án phát triển nhà riêng của tôi, tôi sẽ thực hiện theo cách tiếp cận sau: Xây dựng giải pháp đơn giản nhất có thể giải quyết vấn đề mà tôi đang làm việc ngay bây giờ, nhưng xây dựng nó tốt. Sau đó tôi sẽ cấu trúc lại giải pháp khi cần sự phức tạp hơn. Theo các thực hành TDD làm cho tái cấu trúc an toàn và cũng giúp tránh mùi mã (rất khó để tạo các bài kiểm tra đơn vị tốt, nếu bạn đang phá vỡ đóng gói).

Đó cũng là cách tiếp cận tôi làm khi làm việc chuyên nghiệp. ;)


0

Tôi khuyên bạn trước tiên bạn nên đứng lên phần mềm, bao quát mọi khía cạnh và đứng phần mềm trước rồi dần dần trang trí và cải thiện hiệu suất của nó


-1

Bạn thường muốn ở giữa hai cạnh này:

Xây dựng nó tốt = phần mềm thời gian thực quan trọng mà cuộc sống của mọi người phụ thuộc vào. tức là kiểm soát phần mềm: lò phản ứng hạt nhân, máy lọc máu, máy MRI , v.v.

Xây dựng nó nhanh = phần mềm vô dụng mà không ai thực sự sử dụng.


ha! xây dựng một phần mềm vô dụng ...
pmod

Bất kỳ lý do về bỏ phiếu tiêu cực?
vz0
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.