Có thực sự có bất cứ điều gì để đạt được với thiết kế phức tạp?


8

Tôi đã làm việc cho một công ty tư vấn một thời gian, với các khách hàng có quy mô khác nhau và tôi đã thấy các ứng dụng web có độ phức tạp rất đơn giản:

  • MVC
  • Lớp dịch vụ
  • EF
  • DB

Để thực sự phức tạp:

  • MVC
  • Ơ
  • DI / IoC
  • Kho
  • Dịch vụ
  • Kiểm tra giao diện người dùng
  • Bài kiểm tra đơn vị
  • Kiểm tra tích hợp

Nhưng ở cả hai đầu của phổ, các yêu cầu chất lượng là như nhau. Trong các dự án đơn giản, các nhà phát triển / chuyên gia tư vấn mới có thể tham gia, thay đổi và đóng góp ngay lập tức mà không cần phải vượt qua 6 lớp trừu tượng để hiểu những gì đang diễn ra hoặc có nguy cơ hiểu nhầm một số trừu tượng phức tạp và giảm chi phí.

Trong mọi trường hợp, không bao giờ cần phải thực sự tạo mã có thể hoán đổi hoặc có thể sử dụng lại - và các thử nghiệm không bao giờ thực sự được duy trì qua lần lặp đầu tiên vì các yêu cầu thay đổi, quá tốn thời gian, thời hạn, áp lực kinh doanh, v.v.

Vì vậy, nếu - cuối cùng -

  • kiểm tra và giao diện không được sử dụng
  • phát triển nhanh chóng (đọc: tiết kiệm chi phí) là ưu tiên hàng đầu
  • yêu cầu của dự án sẽ thay đổi rất nhiều trong khi phát triển

... Sẽ là sai lầm khi đề xuất một kiến ​​trúc siêu đơn giản, thậm chí để giải quyết một vấn đề phức tạp, cho một khách hàng doanh nghiệp? Là sự phức tạp xác định các giải pháp doanh nghiệp, hay đó là độ tin cậy, # người dùng đồng thời, dễ bảo trì hoặc tất cả các điều trên?

Tôi biết đây là một câu hỏi rất mơ hồ và bất kỳ câu trả lời nào sẽ không áp dụng cho tất cả các trường hợp, nhưng tôi rất thích nghe các nhà phát triển / chuyên gia tư vấn đã kinh doanh trong một thời gian và đã làm việc với các mức độ phức tạp khác nhau , để nghe xem các bản tóm tắt tuyệt vời nhưng đắt tiền có xứng đáng với chi phí chung hay không, ít nhất là trong khi dự án đang trong quá trình phát triển.


10
Xml là câu trả lời thích hợp duy nhất.
Wyatt Barnett

2
Tôi nghĩ rằng câu trả lời đó chính xác là những gì tôi đã nói về phần mềm doanh nghiệp. Nhưng có một câu hỏi sâu hơn ở đây. Tôi nghe thấy poster hỏi "quan điểm của thiết kế và kiến ​​trúc phần mềm tiên tiến là gì?"
Michael Brown

4
Tôi thách thức khẳng định của bạn rằng bạn có thể tạo ra phần mềm không thể bảo trì, không tầm thường mà không cần kiểm tra tự động. Hơn nữa, tôi thách thức rằng bạn sẽ có thể xử lý các yêu cầu dịch chuyển nhanh chóng mà không cần giao diện nào đó.
Telastyn

@MikeBrown - cảm ơn bạn đã chỉnh sửa - mặc dù cảm thấy đó là một câu hỏi ngu ngốc, vâng, đó là những gì tôi đang hỏi.
SB2055

3
@BrianDHall: miễn là chúng tôi cố gắng và làm cho nó hoàn thành trong quá trình.
Wyatt Barnett

Câu trả lời:


11

... Sẽ là sai lầm khi đề xuất một kiến ​​trúc siêu đơn giản, thậm chí để giải quyết một vấn đề phức tạp, cho một khách hàng doanh nghiệp?

Nó phụ thuộc vào khách hàng. Nhiều người sẽ ổn với cách tiếp cận đơn giản hơn. Một số người sẽ nghĩ rằng bạn không đủ năng lực vì cách tiếp cận đơn giản đó sẽ không giải quyết được vấn đề của họ - toàn bộ "thứ đó phải siêu rẻ vì một lý do ..." khiến một số thứ trở nên đắt hơn so với chi phí.

kiểm tra và giao diện không được sử dụng

Tôi sẽ lập luận rằng không có cách nào trong địa ngục mà bạn có thể chi phí hiệu quả để tạo ra phần mềm không tầm thường mà không cần một trong hai thứ này. Là một công ty, nếu bạn cố bán cho tôi thứ gì đó mà không có họ, tôi sẽ sợ rằng bạn sẽ mang lại cho tôi một đống chó hấp hoàn toàn không thể tin được, không thể nhầm lẫn. ( chỉnh sửa: để rõ ràng Tôi đang nói về các giao diện ở đây, không phải interfaces. Các chương trình thủ tục và chức năng không phải là tất cả các đống rác, mặc dù chúng thiếu giao diện kiểu Java.)

nếu sự trừu tượng mát mẻ nhưng đắt tiền có giá trị tổng chi phí

Là người thiết kế chương trình, chúng ta cần đưa ra những phỏng đoán có giáo dục về nơi mọi thứ sẽ thay đổi và vẽ các đường thẳng ở đó để những thứ thay đổi có thể thực hiện nhanh chóng, dễ dàng và chính xác. Trừu tượng tốt sẽ giúp bạn tiết kiệm tiền theo thời gian vì thay đổi không thể tránh khỏi trở nên rẻ.

Nhưng không có lỗi, thuật ngữ "phi hành gia kiến ​​trúc" tồn tại vì một lý do. Bạn không phải lúc nào cũng xây dựng tàu con thoi. Thêm các khái niệm trừu tượng tồn tại ở giữa những thứ cần thay đổi hoặc tồn tại để hỗ trợ thay đổi không tồn tại ... chúng có thể khiến bạn phải trả giá.

Nhưng theo kinh nghiệm của tôi, tôi đã nghe người ta phàn nàn về trên đang trừu tượng, nhưng tôi đã chỉ nhìn thấy các dự án thất bại do mã dưới trừu tượng.


Cảm ơn bạn rất nhiều cho các thông tin. Tôi đã xây dựng các ứng dụng của riêng mình mà không có giao diện và chưa thấy giá trị của chúng ... Bạn có biết bất kỳ ứng dụng ví dụ đầy đủ nào mà bạn cho là phức tạp khi sử dụng một số trừu tượng, HOẶC bạn có thể giới thiệu một cuốn sách bao gồm khía cạnh này của Phát triển ứng dụng web? Tôi mới đặt mua cuốn sách của Skeet nhưng tôi nghĩ rằng nó tập trung nhiều vào ngôn ngữ hơn là kiến ​​trúc.
SB2055

3
Tôi đã thấy các dự án thất bại vì sự pha trộn quá trừu tượng của spaghetti và lasagna. Bạn nên luôn luôn giữ mọi thứ đơn giản nhất có thể và trung thực, kiến ​​trúc tốt là đơn giản với con mắt nhạy bén và có kinh nghiệm, nhưng n00bs không hiểu được. Kiến trúc tốt không làm bạn chậm lại, hoàn toàn ngược lại.
Falcon

5
Tôi đã thấy nhiều dự án thất bại vì mã quá phức tạp. Thiết kế đơn giản hơn có thể cho thấy những hạn chế của chúng, nhưng ít nhất bạn có thể thấy các vấn đề. Thiết kế phức tạp che giấu những hạn chế của chúng cho đến khi bạn cần sửa chữa hoặc thay đổi một cái gì đó.
Michael Storesin

1
@MichaelShopsin Đồng ý. Trên thực tế, đó cũng chính xác là khi họ thất bại. Tuy nhiên, theo kinh nghiệm của tôi, họ không thất bại giống như một đoạn mã được trừu tượng hóa. Họ thất bại với nhà phát triển sau khi quá nhiều nghiên cứu và công việc đã được thực hiện để vượt qua giới hạn đã bị ẩn. Ít nhất, với một dự án chưa được trừu tượng hóa, tôi biết nhanh chóng liệu mã có phù hợp với nhu cầu hay không và phải làm gì.
Logic Fuzzical

1
@MichaelShopsin - Tôi không giảm giá rằng mã quá phức tạp có thể khiến các dự án thất bại, nhưng chúng có xu hướng khập khiễng trong một thời gian dưới gánh nặng của sự phức tạp của chúng. Các dự án thiếu năng lực sẽ chết nhanh chóng khi họ không thể làm điều gì đó cần thiết mà không viết lại toàn bộ.
Telastyn

4

Để kiến ​​trúc sư, hoặc không phải kiến ​​trúc sư

Để viết lại Einstein, "mọi thứ nên đơn giản nhất có thể - nhưng không đơn giản hơn." Điều quan trọng là phải hiểu việc sử dụng thực sự của một số kiến ​​trúc - và chúng không nhất thiết phải cho hiệu suất cá nhân, và thường không phải để thỏa mãn công việc.

Đôi khi các kiến ​​trúc rất phức tạp vì một dự án doanh nghiệp quá lớn, với rất nhiều người làm việc, kiến ​​trúc này phần lớn cho phép rất nhiều người làm việc hướng tới một cái gì đó mà không phải ai cũng vấp ngã. Đôi khi, chúng ít nhiều hơn sự phức tạp được thêm vào làm giảm năng suất cá nhân và làm cho công việc khó khăn hơn - nhưng cho phép số lượng lớn người làm việc. Điều này hoạt động khi nỗ lực bổ sung vượt xa ý chí sống giảm, cá nhân, ý tôi là "năng suất".

Đây có phải là tình huống của khách hàng của bạn? Chà, nếu ngân sách của họ không nằm trong hàng triệu cho dự án này, có thể không. Nếu nó dưới 100 nghìn, thì gần như chắc chắn là không. Bạn xây một hầm bê tông cho lò phản ứng hạt nhân, không phải lò đốt củi :)

Không nhất thiết sai khi đề xuất "điều đơn giản nhất có thể có thể hoạt động" cho khách hàng của bạn, nếu đó là điều mà tình huống yêu cầu. Nó có thể là cách tốt nhất có thể để xử lý nó. Cách dễ nhất để xem là so sánh nó với các dự án nguồn mở / thương mại sẵn có được thiết kế để hoàn thành một nhiệm vụ tương tự (dù sao đây cũng là nghiên cứu thị trường chuyên sâu của bạn) và xem họ đã làm gì để làm những gì họ đã làm.

Tất nhiên, khi bạn đang làm việc với hàng triệu đô la, bạn nên biết về một số ưu đãi đồi trụy trong trò chơi. Nói tóm lại, "bao phủ mông": nếu bạn đề xuất một hệ thống kiến ​​trúc siêu phức tạp đòi hỏi phải có bằng tiến sĩ để hiểu đúng, khi nào thì nó sẽ là lỗi của ai? Tất nhiên, không phải của bạn - bạn chỉ đề xuất những công nghệ tinh vi nhất mà mọi người nói là tốt nhất - nhưng chúng "phức tạp" và "khó khăn", vì vậy điều đáng trách là ở những người đã cố gắng thực hiện nó. Họ phải không đủ thông minh hoặc đủ kỹ năng ... nói cách khác, rất nhiều lời khuyên được đưa ra để đảm bảo bạn không trông tệ khi các dự án thất bại, điều chắc chắn là họ không phải vì tất cả các dự án đều thành công. Đó là juju xấu, nhưng đó là một thực tế của chúng ta.

Không theo kịp

Tôi sẽ đề nghị rằng việc không liên tục cập nhật các thử nghiệm và theo dõi các quyết định kiến ​​trúc (tung kế hoạch khi chúng thay đổi thay vì cập nhật chúng, v.v.) là lý do tại sao rất nhiều hệ thống cuối cùng bị ném ra và viết lại từ đầu hoặc thay thế bằng bán buôn mới ' giải pháp 'một vài năm xuống đường.

Khi những điều thực thi sự rõ ràng và nhất quán bị loại bỏ vì kinh nghiệm, đôi khi rất dễ nghĩ rằng bạn rất ranh mãnh và thực sự "Hoàn thành mọi việc" khi thực tế bạn đã thay đổi tương lai khó khăn và phức tạp hơn; nó là rất phổ biến để đánh cắp năng suất trong tương lai để đạt được ngay lập tức. Thật tệ khi không ai nhận ra điều đó đang xảy ra.

Kiểm tra, ví dụ, đặc biệt phù hợp nhất khi mọi thứ thay đổi. Bạn thay đổi các bài kiểm tra để phản ánh hướng đi mới là gì, và sau đó tiến hành sửa chữa tất cả những thứ hiện đang bị "hỏng" vì mọi người đã thay đổi ý định hoặc nhận ra rằng họ đã bỏ lỡ điều gì đó lần trước. Điều này giống như từ bỏ việc ngủ vì bạn có rất nhiều việc phải làm trong tuần này - nó sẽ khiến mọi việc trở nên khó khăn hơn.

Trong kết luận, "Nó phụ thuộc" (Hữu ích, phải không?)

Sự phức tạp về kiến ​​trúc là một chi phí trên cao, như thuê một không gian rộng hơn cho một doanh nghiệp sản xuất gạch; nó chỉ có ý nghĩa khi có sự phức tạp thực sự cần phải được quản lý. Nếu đó là một nhóm 3 người làm việc trên một giải pháp tương đối thông thường, thì công cụ MVC đơn giản và công cụ tối thiểu có lẽ là hoàn toàn đủ.

Nếu đó là một giải pháp phần mềm doanh nghiệp, đa hệ thống, phức tạp, với hàng triệu ngân sách và ít nhất là một nửa tá nhóm 3-5? Bạn sẽ cầu xin một tình yêu ngọt ngào, ngọt ngào mà chỉ có kỹ thuật khứ hồi về phân tích chương trình hướng đối tượng và tất cả các biểu đồ, sơ đồ và mô hình của nó có thể cung cấp. Bất cứ điều gì để giúp bạn giữ cho hàng chục hoặc hàng trăm cặp mắt không nhìn chằm chằm vào bạn, tự hỏi họ phải làm gì hôm nay và làm thế nào để họ có thể hoàn thành mọi việc.


2

Chào mừng bạn đến tư vấn.

Một nơi tuyệt vời để kiếm hàng tấn tiền nhanh chóng cung cấp các tính năng cho khách hàng.

Nếu bạn tìm cách làm việc để tạo ra phần mềm đẹp, có thể thích ứng, hoạt động tốt cả hiện tại trong tương lai, tôi khuyên bạn nên làm việc trong một ngành cụ thể như chăm sóc sức khỏe hoặc chính phủ nơi bạn có thể tạo ra một phân khúc tốt hơn cho chất lượng công việc.


1
Chỉ tò mò, tại sao lại chăm sóc sức khỏe và chính phủ? Là những lĩnh vực được biết đến với phần mềm đặc biệt có thể bảo trì / thích ứng / đẹp / chất lượng cao / <tính từ>?

2

Những gì bạn đạt được từ một thiết kế vững chắc, là một chu kỳ thay đổi đáng tin cậy hơn trong thời gian dài. Chi phí ban đầu cao hơn vì bạn cần các lập trình viên được đào tạo đúng cách và thiết kế phù hợp, tuy nhiên mục đích là để giữ chi phí cho những thay đổi sau này tăng vọt khỏi tầm kiểm soát.

Không có một thay đổi kiến ​​trúc vững chắc chỉ rẻ hơn lúc ban đầu. Khi dự án phát triển, những thay đổi ngày càng trở nên tốn kém. Điều này, kết hợp với mong muốn lao động rẻ hơn và lặp lại nhanh hơn, có thể giết chết dự án vì những thay đổi cuối cùng sẽ tốn kém hơn so với công ty sẵn sàng trả mất nhiều thời gian hơn công ty có thể chờ đợi. Thay đổi sau này có thể mất một đội trung bình và thời gian trung bình thay vào đó sẽ yêu cầu một đội siêu phàm và thời gian dài để sàng lọc qua nhiều năm mã và tái cấu trúc đủ để thực hiện các thay đổi một cách an toàn.

Nếu khách hàng hiểu và muốn thực hiện sự hy sinh này, thì hãy thực hiện mọi thay đổi cần thiết bằng bất kỳ phương pháp nào là nhanh nhất. Nhưng thật không khôn ngoan (và có thể không trung thực) khi thực hiện những sự đánh đổi đó cho họ, vì quá trình này sẽ ảnh hưởng đến quyết định kinh doanh của họ.


Một phần của công việc là để hiểu tất cả những điều trừu tượng mà bạn đã liệt kê, không chỉ để hỏi "Những thứ này có cần thiết không?" nhưng để hiểu khi nào và tại sao chúng lại cần thiết và tìm ra cách áp dụng các mẫu đó như là một phần của việc làm việc với phần mềm.

Một phần khác của công việc là hiểu rằng khách hàng thường đánh giá công việc theo những gì họ có thể thấy (ui, chức năng) và họ nên được giáo dục về những gì họ không thể thấy (trạng thái của cơ sở mã).


2

Phức tạp là tương đối. Khi tôi mới bắt đầu học lập trình khái niệm con trỏ đặc biệt là các danh sách được liên kết rất phức tạp ("Làm thế nào bạn có thể có thứ gì đó giống như một lĩnh vực"), nhưng một khi tôi đã hiểu được khái niệm này, điều đó thật đơn giản.

Khi tôi bắt đầu học lập trình chức năng, khái niệm lambda có vẻ phức tạp. Nhưng sau đó tôi đã liên hệ nó với ý tưởng về một con trỏ Hàm từ C ++ và nó thật đơn giản. Và như vậy với cà ri, và hoàn thành, vân vân và vân vân.

Khi tôi mới bắt đầu học TDD, tôi đã nghĩ nó phức tạp hoặc nó đã thêm chi phí cho quá trình phát triển. Bây giờ tôi không cảm thấy mã của mình đã hoàn tất trừ khi tôi có các bài kiểm tra ít nhất là bao quát con đường hạnh phúc. Lúc đầu phụ thuộc tiêm và sử dụng giao diện thay vì các lớp cụ thể có vẻ phức tạp. Nhưng họ cho phép bạn xây dựng mã của mình với giả định rằng bạn sẽ tìm ra các chi tiết của các phụ thuộc và tập trung vào các cấu trúc cấp cao hơn trước.

Kiểm tra Clean Code và The Coder sạch của "Chú Bob" Martin. Đầu tiên nói về cách viết mã tốt hơn. Phần thứ hai nói về cách trở thành một lập trình viên giỏi hơn. Có một sự khác biệt giữa hai.

Để cho một sự tương tự, tôi đang học guitar. Tôi đang ở giai đoạn mà tôi có thể chơi những giai điệu và hợp âm đơn giản. Chuyển đổi giữa các hợp âm và vị trí là khó khăn. Bằng cách luyện tập nhiều hơn, tôi sẽ có thể đạt được những chuyển đổi đó dễ dàng hơn và nó sẽ trở thành bản chất thứ hai đối với tôi.

Tôi sử dụng kho lưu trữ / đơn vị mẫu công việc để tôi có thể sử dụng kho lưu trữ trong bộ nhớ trong khi tôi đang xây dựng chức năng cơ bản và chuyển đổi sang kho lưu trữ "sql lite" hoặc "odata" khi tôi đến gần hơn với việc phân phối. Lưu ý rằng điều này cho phép tôi hoàn thành nhiều chức năng hơn ngay cả trước khi cơ sở hạ tầng cuối cùng được đưa ra (hoặc thậm chí quyết định). Các tóm tắt cho phép tôi tạo các bản giả và sơ khai dễ dàng hơn để tôi có thể xác minh mã phụ thuộc vào các bản tóm tắt hoạt động như mong đợi. Một lần nữa, tôi có thể hoàn thành các tính năng từ trên xuống.

Tôi sẽ nói rằng nó sai khi tạo cơ sở hạ tầng đầu tiên. Một thực tế đơn giản là nó chống nhanh nhẹn. Nếu tôi dành một cuộc chạy nước rút cho "cơ sở hạ tầng", tôi sẽ xây dựng những thứ mà tôi thậm chí không chắc chắn tôi sẽ cần và người dùng sẽ không có gì để xem xét để cung cấp phản hồi.

Đó là những gì trừu tượng cung cấp. Bạn càng thực hành sử dụng chúng, chúng càng trở thành bản chất thứ hai và bạn sẽ nhìn lại cuộc thảo luận này và ngạc nhiên về việc bạn đã phát triển bao xa. Cũng giống như hy vọng, tôi sẽ tự hỏi trong một vài năm, việc chuyển đổi hợp âm đã từng là một thách thức đối với tôi như thế nào.


1

Tôi không hoàn toàn đồng ý với tuyên bố của bạn rằng sự trừu tượng tự động làm tăng sự phức tạp. Trừu tượng là lý do chính tại sao ngày nay người ta không phải giải quyết mã máy.

Vấn đề đôi khi với sự trừu tượng là họ có xu hướng tập trung vào các hoạt động bên trong hơn là che giấu sự phức tạp cho người dùng cuối của nó. Trừu tượng nên cô lập logic và thúc đẩy tái sử dụng. Hơn nữa, tôi nghĩ thử nghiệm là một cách tuyệt vời để thách thức thiết kế kiến ​​trúc. Chủ yếu là vì nó buộc bạn phải xem mã của mình từ quan điểm người dùng.

Các vấn đề bạn đề cập về việc thiếu thời gian, là nguyên nhân chính cho thiết kế xấu. Thiết kế tốt thường không đến ngay lập tức, nhưng thông qua các lần lặp và sàng lọc. Cách chúng tôi thường trích xuất các yêu cầu từ khách hàng của mình là thông qua các câu chuyện của người dùng. Bằng cách này, khách hàng có thể nghĩ về những gì và làm thế nào anh ta muốn sử dụng hệ thống. Hơn nữa, nếu kiến ​​trúc sư nhận thức được ý định của hệ thống thì các quyết định thiết kế hoặc kỹ thuật trừu tượng phù hợp có thể được chọn để thêm tính linh hoạt cho hệ thống. Không phải vì họ mát mẻ hay tốt đẹp.


1

Giải quyết các câu hỏi của bạn ...

... Sẽ là sai lầm khi đề xuất một kiến ​​trúc siêu đơn giản, thậm chí để giải quyết một vấn đề phức tạp, cho một khách hàng doanh nghiệp?

Tuyệt đối không.

Từ góc độ khách hàng

Như đã nêu ở trên, nó phần lớn phụ thuộc vào khách hàng. Nó cũng phụ thuộc vào khả năng của bạn để đánh giá chính xác giải pháp nào phù hợp với khách hàng của bạn. Mặc dù luôn luôn có một chi phí cảm nhận cho giá trị mong muốn, nhưng với tư cách là một nhà tư vấn, công việc của bạn là đặt ra những kỳ vọng phù hợp của khách hàng. Trong một số trường hợp, bạn sẽ phải đáp ứng nhận thức đó. Trong những người khác, nó sẽ là lợi ích tốt nhất của bạn để sửa chúng. Rốt cuộc, bạn nên là chuyên gia cho khách hàng của bạn. Và nếu bạn không, bạn nên có kiến ​​thức để có thể trở thành chuyên gia đó. Đó là những gì họ trả cho bạn.

Từ góc độ nhà phát triển

Phần khó nhất trong việc lựa chọn sử dụng kiến ​​trúc nào là, thường là, ước tính chính xác khối lượng công việc cần thiết để sử dụng công nghệ để đáp ứng các nhu cầu cụ thể. Điều này rất nhanh chóng có thể dẫn đến các dự án không đạt kỳ vọng của khách hàng. Hiểu rằng một số dự án thực sự được thực hiện nhanh hơn bằng cách sử dụng các đoạn mã "phức tạp" này mà bạn đề cập. Nó cũng được hiểu rằng một số thì không. Bạn phải cung cấp phép đo đó, dựa trên những gì bạn hoặc nhóm của bạn biết.

Là sự phức tạp xác định các giải pháp doanh nghiệp, hay đó là độ tin cậy, # người dùng đồng thời, dễ bảo trì hoặc tất cả các điều trên?

Mặc dù chi tiết cụ thể có thể khác nhau, nhưng nói chung, giải pháp doanh nghiệp là một giải pháp phần mềm áp dụng cho đối tượng kết hợp rộng. Số lượng người dùng đồng thời có thể hoặc không phải là một yếu tố, mặc dù thường là vậy. Tổng số người dùng, thường xuyên trong một loạt các vai trò kinh doanh, là một trong những yếu tố quyết định lớn nhất đến việc liệu giải pháp đó có phải là "doanh nghiệp" hay không.

Nhiều giải pháp doanh nghiệp rất phức tạp, nhưng một số khá đơn giản. Trong khi doanh nghiệp đưa ra một không khí đáng tin cậy (và chắc chắn nên được giữ theo một tiêu chuẩn nhất định), các giải pháp khác nhau có mức độ tin cậy khác nhau.

Dễ bảo trì là điều mà tôi nghĩ rằng mọi nhà phát triển (độc lập hoặc thành viên trong nhóm) đều nỗ lực, nó không nhất thiết phải dễ dàng đạt được. Điều quan trọng là có một quy trình bảo trì có hướng dẫn vững chắc, thay vì "dễ dàng". Hãy nhớ rằng, các cơ sở mã khác nhau sẽ có mức độ dễ dàng khác nhau tùy thuộc vào triết lý, phương pháp luận, hoạt động môi trường (kinh doanh) độ phức tạp của mã.

Phản ứng với các tuyên bố khác của bạn ...

Trong mọi trường hợp, không bao giờ có nhu cầu thực sự tạo mã có thể hoán đổi hoặc tái sử dụng

Thường không bao giờ có một nhu cầu cụ thể để làm như vậy. Điều này nên là mục tiêu của bạn, mọi lúc, tuy nhiên. Hãy xem xét điều này ... Bạn có thể có một ứng dụng khách yêu cầu khả năng truy cập hoặc hiển thị lịch của họ từ trang web. Nếu bạn tự tạo mã có thể tái sử dụng, thì khi một khách hàng khác yêu cầu điều tương tự, bạn đã hoàn thành một số công việc. Nếu bạn không, thì bạn phải làm lại từ đầu. Mỗi vấn đề của khách hàng thường là một vấn đề mà khách hàng khác trong tương lai có thể cần. Nói cách khác, mọi khách hàng bạn làm việc cùng nên có khả năng giảm chi phí công việc cho các khách hàng tương lai của bạn (không nhất thiết là chi phí của sản phẩm).

và các bài kiểm tra không bao giờ thực sự được duy trì sau lần lặp đầu tiên vì các yêu cầu thay đổi, nó quá tốn thời gian,

Tôi sẽ tranh luận ở đây rằng phương pháp thử nghiệm không đủ trừu tượng. Gần đây tôi đã sử dụng một đoạn mã đã tự kiểm tra đơn vị của chính nó. Một tùy chỉnh assertexpectchức năng đã được thực hiện phù hợp với nhu cầu của dự án. Bất cứ khi nào cần một bài kiểm tra đơn vị, nó có thể được áp dụng mà không cần điều chỉnh mã. Trong thực tế, mã được phân phối tích cực với các xác nhận và mong đợi vẫn còn trong đó. Nó thực hiện những kiểm tra như một phần của mã làm việc.

... thời hạn, áp lực kinh doanh, vv ....

Tôi thường thấy rằng áp lực kinh doanh thêm và thời hạn cản trở quá trình mã hóa là lỗi của nhà phát triển, không phải của khách hàng. Mặc dù điều này không phải lúc nào cũng đúng, nhưng nhiều lần áp lực kinh doanh là do nhận thức về việc không đáp ứng được kỳ vọng của khách hàng. Khi thời hạn cản trở mã, thường là do nhà phát triển không thể đánh giá chính xác số lượng công việc cần thiết cho mã chức năng có thể sử dụng. Nói cách khác, lên lịch cho họ (khách hàng mong đợi điều đó) , đo lường họ (khách hàng tương lai mong đợi điều đó) , thực hiện chúng (người dùng yêu cầu) và được trả tiền cho họ (hợp đồng của bạn sẽ yêu cầu điều đó) .


1

Rất nhiều điều mà câu hỏi này đặt ra là vô cùng chủ quan, tôi nghĩ rằng điều quan trọng là đưa ra một số dữ liệu về chi phí gộp của sự phức tạp của kiến ​​trúc. Có một nghiên cứu trường hợp thực sự thú vị đến từ MIT Sloan, đó là biện pháp

  • giảm năng suất của nhà phát triển
  • tăng doanh thu
  • và tăng mật độ khuyết tật do kết quả phức tạp hơn.

Về cơ bản, tôi sẽ nói rằng có một phương tiện hạnh phúc mà mọi codebase nên cố gắng tạo ra sự đơn giản giữa (A) để năng suất của nhà phát triển cao và (B) tầm nhìn xa để chức năng không bị ảnh hưởng khi các tính năng mới được thêm vào.

Nghiên cứu điển hình là về một công ty có cơ sở mã hóa nguyên khối có lõi có độ phức tạp cao (nghĩ như các tiện ích và công cụ trừu tượng hóa cao) và ngoại vi có độ phức tạp thấp hơn (nghĩ các tính năng mới hơn với ít phụ thuộc). Giữa ngoại vi và cốt lõi, năng suất của nhà phát triển giảm 50% (thứ điên rồ) và lỗi tăng 2,6 lần.


0

Tôi có thể liên quan đến sự nghi ngờ của bạn về các kỹ thuật phát triển phần mềm phức tạp và sẽ đoán rằng có rất nhiều người có thể, vì chính xác những lý do mà bạn đặt tên: Họ thêm một chi phí cho việc tạo ra một hệ thống mới trong khi không phải lúc nào cũng hiển thị ngay lập tức những lợi ích.

Điều đó rõ ràng không có nghĩa là chúng không tồn tại, vì mỗi khái niệm đều có một lý do, hầu hết các lần đều là một lý do tốt. Tổng cộng họ nên giảm bớt công việc cần thiết để hoàn thành một dự án và tăng cường nó sau đó.

Về lý thuyết, tất nhiên, và tôi cá là bạn đã học được tất cả những lợi ích lý thuyết đó và bây giờ hơn bao giờ hết bạn thấy chúng thất bại. Và điều đó cũng có thể có lý do chính đáng, sử dụng một khái niệm đúng không dễ như hiểu lý do tại sao nó được sử dụng, và trong khi bạn có thể có kinh nghiệm để quyết định khi nào nên trừu tượng và khi nào thì không, khách hàng của bạn có thể chưa.

Sử dụng một khái niệm tại mọi điểm có thể trong dự án của bạn có thể khiến bạn mất rất nhiều thời gian (xem câu trả lời của Telatsyn cho một câu đơn giản gọn gàng về điều đó) và thậm chí sử dụng một khái niệm ở đúng nơi có thể khiến bạn tốn kém, nếu bạn không đủ kinh nghiệm sử dụng nó . Như bạn đã nói, đó không phải là những khái niệm đơn giản mà đôi khi thực sự phức tạp cần phải phù hợp với hoàn cảnh của bạn, một sự hiểu biết về lý thuyết không thể đủ để sử dụng nó nhanh và đúng.

Và vì những lý do đó, không có gì ngạc nhiên khi khách hàng của bạn mà không thực sự nhận thấy trôi đi khỏi các khái niệm và từ bỏ các bài kiểm tra và trừu tượng của họ và bắt đầu làm việc đơn giản trở lại.

Về rào cản lớn mà công nghệ phần mềm có thể gặp phải, tôi đề nghị bài viết này cho bạn: Bảy giai đoạn chuyên môn về Kỹ thuật phần mềm Tôi tình cờ thấy nó ở đâu đó trên trang này và nó thể hiện một số suy nghĩ và kinh nghiệm thực sự thú vị.


-1

Tôi sẽ nói rằng nếu bạn đang phát triển các ứng dụng cho doanh nghiệp thì bạn hoặc ai đó phụ trách các dự án của bạn (Proj mgr) sẽ có cảm giác tốt hơn về số lượng công việc nên làm cho các dự án. Nếu bạn đang thấy lãng phí thời gian thì bạn nên thảo luận về quan điểm của mình với Proj mgr. Cách tôi cảm nhận và vận hành luôn dựa trên một loại phán đoán cơ bản, nhưng tôi luôn để ý khách hàng đó sẽ ném cho bạn một quả bóng cong. Tôi sẽ có lỗi khi làm một công việc tốt bằng cách chấm điểm I của bạn và vượt qua t của bạn. Tôi cũng sẽ đảm bảo rằng tôi có quản lý vòng đời ứng dụng phù hợp để hầu hết các chi phí được tự động hóa để nó không tiết kiệm thời gian, v.v ... Tôi hy vọng điều đó có ích!


1
bài này khá khó đọc (tường văn bản). Bạn có phiền chỉnh sửa ing nó thành một hình dạng tốt hơn?
gnat
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.