Bằng chứng thực nghiệm cho việc lựa chọn mô hình lập trình để giải quyết vấn đề


11

Wiki C2 có một cuộc thảo luận về Bằng chứng thực nghiệm cho lập trình hướng đối tượng mà về cơ bản kết luận rằng không có gì hấp dẫn đối với chính quyền. Điều này đã được chỉnh sửa lần cuối vào năm 2008. Thảo luận ở đây dường như đã giải thích được điều này: các câu hỏi về việc liệu OO có bị lỗi thời hay không , khi lập trình chức năng là một lựa chọn tồinhững ưu điểm và nhược điểm của AOP đều được trả lời với ý kiến ​​của những người đóng góp mà không phụ thuộc vào bằng chứng.

Tất nhiên, ý kiến ​​của các học viên đã thành lập và có uy tín là điều đáng hoan nghênh và có giá trị, nhưng chúng hợp lý hơn khi chúng phù hợp với dữ liệu thử nghiệm. Liệu bằng chứng này có tồn tại? Tôi biết rằng kỹ thuật phần mềm dựa trên bằng chứng là một điều, nhưng tôi có thể thực hành nó trong bối cảnh này không? Cụ thể, nếu tôi có một vấn đề cụ thể Pmà tôi muốn giải quyết bằng cách viết phần mềm, liệu có tồn tại một cơ thể kiến ​​thức, nghiên cứu và nghiên cứu sẽ cho tôi thấy kết quả của việc giải quyết các vấn đề như thế nào Pphụ thuộc vào sự lựa chọn của mô hình lập trình không?

Tôi biết rằng mô hình nào được đưa ra là "câu trả lời đúng" có thể phụ thuộc vào số liệu mà một nghiên cứu cụ thể chú ý đến, dựa trên những điều kiện mà nghiên cứu giữ không đổi hoặc thay đổi và không nghi ngờ gì về các yếu tố khác. Điều đó không ảnh hưởng đến mong muốn của tôi để tìm thông tin này và phê bình nó.

Rõ ràng là một số người nghĩ rằng tôi đang tìm kiếm một giải pháp "quay tay" - một số máy xúc xích mà tôi đưa thông tin về vấn đề của mình và từ đó có một từ như "chức năng" hoặc "có cấu trúc". Đây không phải là ý định của tôi. Những gì tôi đang tìm kiếm là nghiên cứu về cách thức - với rất nhiều sự cảnh báo và giả định rằng tôi sẽ không đi sâu vào đây nhưng tài liệu tốt về vấn đề này - một số tính chất của phần mềm khác nhau tùy thuộc vào vấn đề và sự lựa chọn của mô hình.

Nói cách khác: một số người nói "OO mang lại sự linh hoạt tốt hơn" hoặc "các chương trình chức năng có ít lỗi hơn" - (một phần) những gì tôi yêu cầu là bằng chứng của điều này. Phần còn lại là yêu cầu bằng chứng chống lại điều này, hoặc các giả định theo đó các tuyên bố này là đúng hoặc bằng chứng cho thấy những cân nhắc này không quan trọng. Có rất nhiều ý kiến ​​về lý do tại sao một mô hình tốt hơn một mô hình khác; Có bất cứ điều gì khách quan đằng sau bất kỳ trong số này?


1
tìm kiếm trên web cho kỹ thuật phần mềm dựa trên bằng chứng cho thấy nhiều liên kết
gnat

@gnat EBSE là về tóm tắt một cách có hệ thống các tài liệu và rút ra kết luận chung về cách chúng tôi có thể cải thiện thực tiễn. Câu hỏi của tôi là liệu văn học đó có tồn tại không; liệu có đủ để các đánh giá có hệ thống hoặc metaanalyses có hiệu quả hay không.

Câu trả lời:


12

Đối với lần lấy trước, xem Bản sửa đổi 1 của câu trả lời này . Tuy nhiên, các ý kiến ​​và chỉnh sửa cho câu hỏi làm rõ hơn những gì câu hỏi đang tìm kiếm và cho phép tôi rõ ràng hơn.

Vâng, kỹ thuật phần mềm dựa trên bằng chứng (EBSE) là một điều. Dường như có một vài nỗ lực đối với cơ sở dữ liệu EBSE, chẳng hạn như cơ sở dữ liệu này tại Đại học DurhamSEED, được bắt đầu bởi một giáo sư tại Cal Poly . Tất cả những nỗ lực này, cũng như những nỗ lực được thảo luận trong một số bài báo có thể được tìm thấy thông qua máy chủ IEEE Xplore hoặc Thư viện số ACM(đăng ký hoặc mua yêu cầu cho nhiều giấy tờ trong cả hai), được dựa trên thuốc dựa trên bằng chứng. Họ cung cấp các đánh giá tài liệu về dữ liệu thực nghiệm (quan sát và thử nghiệm) được công bố. Trên thực tế, bao gồm cả "đánh giá tài liệu" trong chuỗi tìm kiếm trên bất kỳ tìm kiếm xuất bản nào cũng mang lại thông tin về hầu hết các chủ đề - hơn 14000 lượt truy cập trên ACM và hơn 1000 trên cơ sở dữ liệu của IEEE (khi chỉ giới hạn ở các chủ đề điện toán).

Nhìn vào các loại chủ đề chung được thảo luận trong các cơ sở dữ liệu và đánh giá tài liệu EBSE này, tôi thấy một chủ đề chung - chúng có xu hướng độc lập với công nghệ. Sự nhấn mạnh dường như chủ yếu tập trung vào quy trình và phương pháp hơn là các công cụ cụ thể được sử dụng để tiến hành công nghệ phần mềm.

Vì vậy, khái niệm này tồn tại trong công nghệ phần mềm. Academia nhận thức được khái niệm dựa trên bằng chứng và có thể áp dụng thành công nó vào công nghệ phần mềm.

Cụ thể, câu hỏi giải quyết việc áp dụng các kỹ thuật EBSE cho việc lựa chọn mô hình có vẻ khó khăn, do số lượng biến số liên quan, buộc phải đưa ra các giả định cũng như giảm khả năng lặp lại thí nghiệm hoặc quan sát. Điều đó được nói ngay trong câu hỏi - "mô hình nào được đưa ra là" câu trả lời đúng "có thể phụ thuộc vào số liệu mà một nghiên cứu cụ thể chú ý đến, về những điều kiện mà nghiên cứu giữ không đổi hoặc thay đổi, và không nghi ngờ gì về các yếu tố khác nữa" . Mặc dù điều đó không có nghĩa là nghiên cứu mô hình nào là "tốt nhất" trong một tình huống nhất định, nhưng điều đó làm cho bất kỳ loại đánh giá tài liệu nào về các tài liệu này cực kỳ khó hoàn thành và vẫn trích xuất thông tin trên chúng.

Chắc chắn không có giải pháp "quay quây" để chọn mô hình.

Đưa ra một mô hình lập trình, bạn có thể tìm thấy các nghiên cứu trong các cơ sở dữ liệu học thuật và công nghiệp khác nhau về cách mô hình đó ảnh hưởng đến các khía cạnh khác nhau của phát triển phần mềm - chất lượng, khiếm khuyết, hiệu quả, v.v. - trong các điều kiện cụ thể khác nhau, từ kiến ​​thức và kinh nghiệm của nhóm đến miền vấn đề. Bất kỳ bài viết nghiêm ngặt nào cũng cần xác định rõ các điều kiện theo đó dữ liệu được thu thập và các giả định. Vấn đề trở nên cố gắng cô lập các yếu tố làm cho nó tốt trong từng điều kiện đó.

Về mặt học thuật, có một số tuyên bố rất dễ nghiên cứu. Ví dụ, tuyên bố rằng mô hình chức năng rất phù hợp với các ứng dụng yêu cầu đồng thời xuất phát từ định lý Church-Rosser . Do đó, có khả năng một hệ thống phần mềm được viết bằng ngôn ngữ chức năng sẽ có ít lỗi hơn liên quan đến đồng thời so với cùng một hệ thống được viết bằng ngôn ngữ hướng thủ tục hoặc hướng đối tượng.

Tuy nhiên, từ quan điểm thực tế, một nhóm phần mềm không thể luôn sử dụng công cụ hoặc kỹ thuật "tốt nhất" cho công việc chỉ vì nghiên cứu chỉ ra điều đó. Mặc dù chúng tôi cố gắng sản xuất các hệ thống phần mềm chất lượng cao nhất, chúng tôi vẫn hoạt động trong các hạn chế. Thông thường, tôi thấy các ràng buộc này được giảm thiểu (hoặc thậm chí loại bỏ khỏi phương trình) khi thảo luận về hiệu quả của bất kỳ phương pháp nào.

Là một học viên, khi tôi tham gia vào việc lựa chọn công nghệ để sử dụng, tôi cố gắng xác định các công cụ tốt nhất có thể. Nhưng sau đó, tôi buộc mình vào những gì được biết và hiểu rõ bởi đội ngũ mà tôi có. Quay trở lại ví dụ trước của tôi, nếu tôi có một đội ngũ thành thạo trong việc xây dựng các ứng dụng đồng thời trong C ++ và không có kinh nghiệm về Haskell, thì sẽ không có ý nghĩa gì khi đề xuất xây dựng hệ thống trong Haskell vì tôi có thể sẽ không thể thực hiện được lịch trình và hạn chế về ngân sách, và chất lượng của tôi có thể sẽ bị ảnh hưởng do thiếu kinh nghiệm trong chuỗi công cụ.

Tóm lại, kỹ thuật phần mềm dựa trên bằng chứng nói chung là một điều tốt tồn tại và các đánh giá tài liệu tồn tại và có sẵn. Tuy nhiên, có những khía cạnh của công nghệ phần mềm nơi áp dụng các phương pháp dựa trên bằng chứng cung cấp rất ít giá trị. Việc lựa chọn một mô hình lập trình cho một nỗ lực phát triển quy mô lớn là một trong những điều này.

Nếu bạn muốn tìm hiểu về cách giải quyết vấn đề hướng tới đối tượng hoặc lỗi trong lập trình chức năng - bạn sẽ dễ dàng tìm thấy các ấn phẩm về những điều đó. Tuy nhiên, tôi đã không tìm thấy (tôi cũng không đặt niềm tin vào) một ấn phẩm có thể giải quyết hiệu quả việc lựa chọn mô hình trên phạm vi rộng của các dự án kỹ thuật phần mềm trong thế giới thực.


Phần về tính đầy đủ của Turing bỏ qua sự đánh đổi, đó là những gì tôi muốn thấy được đưa ra ngoài và so sánh. Hãy để tôi đưa ra một ví dụ cụ thể. Rất nhiều người nói với tôi rằng lập trình chức năng là tuyệt vời để tránh các lỗi đồng thời. Bây giờ chúng ta thấy rằng Scheme giống như Pascal, Turing-Complete. Vì vậy, có thể viết mã an toàn đồng thời theo thủ tục. Đã đồng ý. Nhưng nó có tuyệt không? Có những lợi thế để chọn một phương pháp? Những lợi thế như vậy có thể được đo lường?

1
@GrahamLee Xác nhận hoặc bác bỏ giả thuyết của bạn đòi hỏi bằng chứng khách quan, không tồn tại. Có những lý do chủ quan để tạo ra một mô hình mới và một mô hình mới thể hiện các khả năng tính toán chính xác giống nhau - và điều này không bị hạn chế đối với các ngôn ngữ lập trình, mà còn đối với biểu diễn toán học cơ bản của các ngôn ngữ nói trên . Những lý do khách quan đó bao gồm nhắm mục tiêu một nhân khẩu học cụ thể (nhà toán học tính toán so với nhà phân tích kinh doanh - cách suy nghĩ của họ là khác nhau đòi hỏi một mô hình khác nhau).
Thomas Owens

2
@Thomas: hàm ý của bạn rằng thực tiễn lập trình là không rõ ràng đối với khoa học là đặc thù. Có rất nhiều nghiên cứu đang diễn ra. Một ví dụ được trích dẫn là nhóm nghiên cứu của Lutz Prechelt . Tôi không biết rõ khu vực này đủ để biết liệu có ai giải quyết được các câu hỏi cụ thể của Graham không, nhưng không có lý do gì để tin rằng chúng không phù hợp với loại phương pháp được sử dụng bởi Prechelt và những người khác.
Khủng hoảng

1
@Chris Tôi không tin rằng chúng mờ đục đối với khoa học. Tuy nhiên, tôi tin rằng có một số điều mà vào thời điểm bạn, như Graham nói trong câu hỏi, thêm "rất nhiều sự giả định và giả định" vào nghiên cứu, nó không còn hữu ích cho các học viên. Vào thời điểm đó, từ quan điểm thực tế, thực tế, đơn giản là hiệu quả hơn để dựa trên quyết định của bạn về lịch sử và kinh nghiệm. Có dữ liệu tốt, cứng, hợp lệ là một điều rất tốt. Nhưng có một điểm khi quá khó để có được hoặc nó chỉ có giá trị trong một tình huống rất cụ thể mà nó không hữu ích cho ngành công nghiệp.
Thomas Owens

1
@Thomas tôi nghi ngờ điều đó. Thực hành y khoa nói chung ít nhất là theo tình huống và nhạy cảm với bối cảnh như kỹ thuật phần mềm, và, er, bằng chứng cho thấy GP dựa trên bằng chứng tạo ra những cải tiến có thể đo lường được. Đây chủ yếu là vấn đề về số lượng và chất lượng nghiên cứu.
Cris

7

Tôi đã đọc Nghệ thuật lập trình Unix của Eric S. Raymond. Nó có một số hiểu biết lịch sử rất thú vị về những điều chúng ta hiện đang coi là đương nhiên. Ông trích dẫn một số nghiên cứu tốt từ phần mềm IEEE sử dụng bằng chứng thực nghiệm như mật độ khuyết tật. Đó có thể là một nguồn tốt nếu bạn đang tìm kiếm các nghiên cứu theo phong cách học thuật.

Ngay cả các kỹ thuật như mô đun hóa bằng cách sử dụng các chức năng không phải lúc nào cũng phổ biến. Một trong những trích dẫn yêu thích của tôi từ cuốn sách cho đến nay:

Dennis Ritchie khuyến khích tính mô đun bằng cách nói với tất cả và lặt vặt rằng các lệnh gọi hàm thực sự rất rẻ ở C. Mọi người bắt đầu viết các hàm nhỏ và mô đun hóa. Nhiều năm sau, chúng tôi phát hiện ra rằng các lệnh gọi hàm vẫn còn đắt đối với PDP-11 và mã VAX thường dành 50% thời gian cho lệnh CALLS. Dennis đã nói dối chúng tôi! Nhưng đã quá trễ rồi; tất cả chúng tôi đã bị cuốn hút ...

- Steve Johnson

Có thực sự có hai vấn đề với việc quá kinh nghiệm. Đầu tiên là chất lượng mã là một điều rất chủ quan. Mã có thể là khủng khiếp và vẫn đúng. Nhân dân nhận thức của một mô hình lập trình là một thước đo rất có giá trị, bởi vì mã được viết cho mọi người đọc càng nhiều càng tốt cho máy tính, nếu không muốn nói nhiều hơn nữa.

Vấn đề thứ hai là 50% các nhà phát triển có tài năng lập trình dưới mức trung bình. Sẽ không có vấn đề gì nếu nhà phát triển hàng đầu của bạn làm việc hiệu quả hơn bằng cách sử dụng lập trình chức năng nếu "rabble" đấu tranh để viết phần mềm làm việc bằng cách sử dụng nó, chứ đừng nói đến phần mềm đẹp, có kiến ​​trúc tốt. Tương tự như vậy với các ngôn ngữ lập trình TMTOWTDI , nhà phát triển hàng đầu của bạn vẫn sẽ viết mã sạch, mô-đun, nhưng các lập trình viên kém tài năng viết nhiễu dòng do thiếu cấu trúc áp đặt.

Đó là lý do tại sao tôi nghĩ rằng OOP đã vươn lên dẫn đầu về mức độ phổ biến mặc dù thiếu sót của nó. Nó không quá hạn chế đến nỗi nó đánh bại những người tài năng nhất, nhưng cấu trúc của nó cung cấp một cách ngắn gọn để giao tiếp và áp đặt các nguyên tắc thiết kế tốt cho những người kém tài năng nhất.

Trong dòng công việc của chúng tôi, chúng tôi có xu hướng đánh giá một giải pháp dựa quá nhiều vào giá trị kỹ thuật của nó. Một nỗ lực thành công cũng phải tính đến khía cạnh con người của phương trình.


"Chất lượng mã là một điều rất chủ quan" đã đồng ý - bạn phải cẩn thận với những gì bạn đo lường và nhận thức là một yếu tố quan trọng. Nhưng nhận thức, giống như nhiều thứ khác, cũng dễ uốn nắn: nhìn vào sự tăng giảm của chương trình chức năng để thấy rằng những gì mọi người nghĩ về cách họ làm việc không liên quan trực tiếp đến cách họ làm việc. Gần đây tôi cũng đã đọc lại TAOUP. Một phần động lực của tôi cho câu hỏi này là thấy trong các giải pháp văn học ban đầu cho các vấn đề hiện nay trong công nghệ phần mềm.

+1, "Vấn đề thứ hai là 50% các nhà phát triển có tài năng lập trình dưới mức trung bình." Câu này là một cứu trợ cho tôi. Nó tốt hơn nhiều loại thuốc tôi đã thử :)
NoChance

3

Có các cuộc thi lập trình sử dụng hệ thống phân loại máy tính và cho phép bạn viết bằng nhiều ngôn ngữ khác nhau và đăng tất cả các loại kết quả và mọi thứ. Tôi cá là họ có dữ liệu tốt cho bạn. Dưới đây là danh sách 8: http://www.makeuseof.com/tag/8-onlineprogramming-contests-challenge-win/

Tôi tưởng tượng bạn có thể so sánh các giải pháp có ý nghĩa với các vấn đề rất đơn giản và rõ ràng, như tổng bình phương, hoặc chuỗi Fibonacci hoặc vẽ một đường thẳng bằng thuật toán đường thẳng của Bresenham. Hầu hết các tác vụ lập trình trong thế giới thực không có các mục tiêu rõ ràng như vậy và mọi ngôn ngữ đều có những điểm hay. Phần lớn lợi ích của một ngôn ngữ là chủ quan. Bạn có thể tìm thấy dữ liệu có ý nghĩa hơn bằng cách khảo sát hạnh phúc của lập trình viên và khách hàng hơn là đếm các dòng mã hoặc số lỗi.

Tôi nhớ khi tôi dành nửa ngày để viết một trong những chương trình Awk đầu tiên của mình, tôi nghĩ rằng tôi sẽ mất cả tuần để làm điều "tương tự" trong Java. Nhưng đó là bởi vì giải pháp Java của tôi sẽ tập trung vào sự mạnh mẽ khi mà giải pháp Awk nhanh và bẩn và yêu cầu một số điều chỉnh thủ công trên đầu vào và đầu ra và thực sự bị vứt bỏ khi tôi hoàn thành. Awk và Java đều tuyệt vời, chỉ không cho những thứ giống nhau.

Tôi đoán những gì tôi đang nói là đối với các ứng dụng trong thế giới thực, việc so sánh các ngôn ngữ hoặc công cụ theo một cách có ý nghĩa là vô cùng khó khăn - vấn đề táo và cam cũ. Chúc may mắn! Tôi muốn xem những gì bạn tìm hiểu.


2

Tôi đã nghiên cứu nhiều cách khác nhau để phát triển phần mềm trong hơn 30 năm. Có rất nhiều bằng chứng được công bố tốt về việc chọn một mô hình.

Tôi tập hợp một thư mục ASCII có thể tìm kiếm lớn. Điều này bao gồm rất nhiều bài báo và bài viết của IEEE và ACM. Tôi gắn thẻ các mục với loại bằng chứng được cung cấp. Dưới đây là các thẻ phổ biến nhất:

...
133 =EXPERIMENT
177 =HISTORY
233 =IDEA
267 =SURVEY
338 =ESSAY
395 =THEORY
454 =ADVERT
491 =EXPERIENCE
500 =DEMO

Bây giờ hãy tìm kiếm PARADIGM và đếm các thẻ

  1 =ESSAY
  1 =EXPERIENCE
  1 =HISTORY
  1 =IDEA
  1 =POLEMIC
  1 =SURVEY
  1 =TALK

Nếu bạn muốn tìm hiểu sâu hơn, http://cse.csusb.edu/dick/lab.html và tôi hy vọng nó sẽ giúp ...


1

Dường như trong nhiều trường hợp, không có một nghiên cứu nào đủ lớn hoặc chất lượng đủ cao để cho phép đưa ra kết luận chung về việc liệu một thực hành trong công nghệ phần mềm tốt hơn một thực hành khác. Tôi đặc biệt tìm kiếm nghiên cứu để làm việc trong các mô hình khác nhau, nhưng việc thiếu tính khả dụng không bị giới hạn trong lĩnh vực đó vì vậy tôi sẽ đóng khung câu trả lời của mình theo nghĩa rộng hơn.

Một bài báo từ năm 2004, Kỹ thuật phần mềm dựa trên bằng chứng của Kitchenham và cộng sự , đã trình bày khá rõ ràng những lợi ích có được từ cách tiếp cận dựa trên bằng chứng và các vấn đề khi triển khai nó trong công nghệ phần mềm. Tôi sẽ không thảo luận về khía cạnh lợi ích ở đây (rõ ràng từ câu hỏi mà tôi muốn có thể làm việc theo cách này), nhưng các vấn đề có liên quan như là một câu trả lời cho câu hỏi tôi đã hỏi.

  • Thứ nhất, nếu bạn không phải là thành viên của ACM thì có lẽ bạn không thể đọc được liên kết ở trên, điều này bao gồm vấn đề đầu tiên: không phải tất cả các nghiên cứu mở rộng đều thực sự có sẵn cho các học viên.
  • nhiều thực hành kỹ thuật phần mềm diễn ra trong bí mật như là một phần của các quy trình bảo mật thương mại, do đó không thể thấy được những gì đã làm hoặc không làm cho những người đó.
  • công nghệ phần mềm là một thực hành lành nghề, vì vậy thật khó (không phải là không thể, chỉ đơn giản là khó) để sắp xếp một nghiên cứu mù phù hợp.
  • các phần khác nhau của vòng đời phần mềm ảnh hưởng đến kết quả của nhau đến mức khó kiểm soát trong mọi thử nghiệm.
  • như được minh chứng bởi các cuộc thảo luận ở đây, nhiều học viên không thấy "tài liệu" (hay khía cạnh học thuật của công nghệ phần mềm nói chung) có liên quan đến công việc của họ.

Vì vậy, câu trả lời tôi theo sau là "không", bằng chứng tôi đang tìm kiếm có lẽ không tồn tại. Tôi nên chọn mô hình của mình dựa trên các tiêu chí phổ biến hiện có về những gì tôi biết, những gì thú vị và ý kiến ​​chuyên gia.


2
từ bản tóm tắt của bài báo được trích dẫn, tôi nhấn mạnh: "Yếu tố kỹ năng có nghĩa là các thí nghiệm công nghệ phần mềm dễ bị thiên vị của đối tượng và người thử nghiệm . Yếu tố vòng đời có nghĩa là rất khó xác định công nghệ sẽ hoạt động như thế nào khi được triển khai . Kết luận: Kỹ thuật phần mềm sẽ được hưởng lợi từ áp dụng những gì có thể của phương pháp bằng chứng với điều kiện là nó giải quyết được các vấn đề cụ thể phát sinh từ bản chất của công nghệ phần mềm . " Tôi sẽ thêm vào: chúc may mắn với điều đó! ;)
Steven A. Lowe

Steven: một phần của động lực đằng sau EBSE là từ "Tôi có thể đoán các vấn đề sau, do đó tôi sẽ từ chối mọi cơ hội giải pháp của bạn hoạt động" để phân tích kết quả dựa trên giá trị của riêng họ. Có nhiều thứ cho một bài báo hơn là trừu tượng của nó.

2
Tôi đánh giá cao sự nhiệt tình của bạn. Khoa học y tế và phát triển phần mềm là những ngành hoàn toàn khác nhau. Trong khi sự tương tự là thú vị, nó hầu như không đột phá. Toàn bộ bài báo có sẵn ở đây labada.inf.utfsm.cl/~gvaldes/ESE/docs/NH Phần 5 phản ánh sự không phù hợp trở kháng được đề cập trong bản tóm tắt. Một bản đồ trực tiếp hơn về các kỹ thuật y tế sẽ là gỡ lỗi các hệ thống hiện có, không xây dựng các hệ thống mới. ;) Nếu bạn muốn xây dựng những sản phẩm tốt hơn, hãy xây dựng những đội tốt hơn. Con người quan trọng hơn nhiều so với các công cụ (cf Peopleware)
Steven A. Lowe

1
phụ lục: trang EBSE có một số thông tin hữu ích, dur.ac.uk/ebse/evidence.php sẽ đặc biệt hữu ích với những người mới tham gia lĩnh vực SE - nhưng hãy thực hiện các khảo sát với một khối muối, bởi vì (1) bằng chứng có sẵn là ít ỏi và (2) kết quả trung bình có thể không liên quan đến hiệu suất của nhóm các cá nhân cụ thể của bạn với các kỹ năng và năng khiếu chuyên môn cao.
Steven A. Lowe

0

Tôi không tin loại nghiên cứu này tồn tại. Người ta sẽ tin rằng đó không phải là mô hình lập trình quan trọng bằng thuật toán thực tế được sử dụng. Chẳng hạn, với bất kỳ hệ thống không tầm thường nào dựa trên các thuật toán không gian nhỏ, câu này dựa trên các thuật toán thời gian nhỏ sẽ tạo ra các số liệu khác nhau. Cái nào có thời gian tốt hơn rất có thể sẽ được coi là hợp lệ hơn, trừ khi không gian là một vấn đề thì điều ngược lại là đúng. Tôi thấy nó tương tự như mở đường. Mặc dù thuật toán hoặc công thức chế tạo vật liệu là không đổi trong tất cả các quy trình, có thể một công ty nghĩ rằng việc lát hai làn đường cùng một lúc (một làn ở hai bên đường) tốt hơn là lát hai làn đường cùng một lúc . Vào cuối ngày, điều đó không thành vấn đề vì quá trình tạo ra đỉnh đen vẫn như cũ, sự khác biệt duy nhất là cách tiếp cận. Quay trở lại với lập trình, nếu bạn có một nhóm các nhà phát triển C, hãy viết mã theo cách thủ tục, nếu bạn có một nhóm các nhà phát triển Java viết nó trong OO. Không được treo lên trên mô hình nhiều như việc thực hiện thuật toán. Bởi vì vào cuối ngày bạn có thể viết Java như C và bạn có thể cố gắng viết C như Java.

CẬP NHẬT

Để trả lời bình luận graham để lại cho tôi:
Tôi giả sử bởi kiến ​​trúc bạn có nghĩa là mô hình lập trình. Nếu bạn định sử dụng Clojure, có lẽ bạn nên thuê một nhóm lập trình viên Clojure. Tuy nhiên, dựa trên một tìm kiếm nhanh Clojure là một ngôn ngữ dựa trên Java, nó thực sự có chức năng. Cho rằng thông tin đó tôi sẽ đưa các lập trình viên Java (vì về mặt kỹ thuật họ chỉ có thể viết Java và nó sẽ cho bạn kết quả tương tự) hoặc tìm kiếm các lập trình viên chức năng như nhà phát triển Haskell. Bây giờ về mặt lựa chọn những gì tốt nhất, nó hoàn toàn phụ thuộc vào nhóm của bạn. Tôi sẽ không bao giờ có một nhóm các chuyên gia cơ sở dữ liệu quan hệ tổ chức một giải pháp đám mây cho tôi và tôi cũng sẽ không có một nhóm lập trình viên chức năng xây dựng một giải pháp định hướng đối tượng cho tôi. Bạn phải sử dụng những điểm mạnh của đội mà bạn không có tầm nhìn vinh quang mà bạn có trong đầu cho những gì một đội "nên"


Làm cách nào để tôi chọn thuê một nhóm lập trình viên Java hay một nhóm lập trình viên C? Tôi có nên đào tạo lại họ trong Clojure? Khi tôi đã chọn thuật toán của mình, kiến ​​trúc nào là cách "tốt nhất" để gói gọn nó trong một giải pháp phần mềm, với các giá trị đã cho là "tốt nhất"?

@GrahamLee xem cập nhật của tôi
Woot4Moo

Tôi cảm thấy chúng ta đang thảo luận về cùng một vấn đề nhưng ở các mức độ trừu tượng khác nhau. "Sử dụng sức mạnh của đội bạn có" có nghĩa là không bao giờ xây dựng máy tính, bởi vì Bletchley Park không có ai có sức mạnh trong việc xây dựng máy tính. Đôi khi bạn phải nói "chúng ta có thể tạo ra một giải pháp tốt hơn nếu chúng ta sử dụng thứ này "; những gì tôi đang theo là thông tin về những trường hợp đó.

0

Các mô hình khác nhau dẫn đến các giải pháp khác nhau. Sự phù hợp nào là 'tốt nhất' phụ thuộc phần lớn vào:

  • giải pháp
  • nhóm phát triển
  • môi trường hoạt động

Tôi biết không có nghiên cứu dứt khoát như vậy, và ngay cả khi có một nghiên cứu tôi sẽ không tin tưởng nó.

Đó là công việc của kiến ​​trúc sư.

Thay thế sự khôn ngoan của kiến ​​trúc sư bằng các kết luận có thể không liên quan của một nghiên cứu là một công thức cho thảm họa.

Lưu ý: một nhận xét đề cập đến việc quyết định "thuật toán" và sau đó chọn ngôn ngữ. Thuật toán là cơ chế cấu trúc trung tâm cho các ngôn ngữ thủ tục. Các ngôn ngữ hướng đối tượng tập trung vào các lớp và mô hình hợp tác / giao tiếp. Nếu bạn bị thuyết phục (với tư cách là kiến ​​trúc sư) rằng một giải pháp tập trung vào thuật toán là 'tốt nhất', thì hãy gắn bó với các ngôn ngữ thủ tục hoặc chức năng.

Phụ lục: không tin tưởng các nghiên cứu không phải là 'mê tín', đó là lẽ thường. Thí nghiệm khoa học phải khách quan và lặp lại. Các dự án phần mềm rất chủ quan, nhưng thậm chí tệ hơn chúng là những thử nghiệm không thể lặp lại . Bạn chỉ đơn giản là không thể thực hiện dự án X với nhóm Y, đo lường kết quả và sau đó quay ngược thời gian, xóa ký ức và thực hiện lại cùng một dự án với cùng một nhóm. Thông tin được phát hiện hoặc ngụ ý bởi các nghiên cứu có thể hữu ích cho kiến ​​trúc sư, nhưng nó không bao giờ có thể dứt khoát.


1
Vì vậy, nó nằm ngoài tầm nhìn của một kiến ​​trúc sư để tìm kiếm công việc trước đó để xây dựng ý kiến ​​của mình? Có lẽ là không - do đó câu hỏi liệu và kết quả như vậy có thể được tìm thấy.

2
Nếu có một nghiên cứu dứt khoát với phương pháp thực nghiệm hợp lý, kết quả của nghiên cứu có thể rất thú vị; vì câu trả lời này dường như cho thấy rằng bất kỳ nghiên cứu nào cũng vô giá trị đối với phương pháp không phù hợp với sở thích của tôi
jk.

3
@Steven: từ không tin vào kết quả của một nghiên cứu thực sự dứt khoát là 'mê tín'. Có lẽ điều bạn thực sự muốn nói là bạn không tin rằng có thể có những nghiên cứu dứt khoát ở SE (bản tuyên bố rõ ràng sẽ đòi hỏi một lượng lớn bằng chứng được hỗ trợ tốt).
Cris

1
Chất lượng của một phương pháp phần mềm là ở chỗ nó phù hợp với nhu cầu của con người địa phương. Nói chung, nó không bị hạn chế bởi các định luật vật lý (Scotty). Sẽ còn rất lâu nữa trước khi 'phần mềm' [kỷ luật] quản lý để chắt lọc các luật cơ bản bất biến của nó. Ví dụ: xem "Số liệu chất lượng phần mềm: Ba ​​số liệu có hại và hai số liệu hữu ích" trong ppi-int.com/newsletter/SyEN-046.php#featureppi-int.com/newsletter/SyEN-047.php#feature
Philip Oakley

1
@Cris: Đối với hồ sơ, không, tôi không tin rằng có thể có một nghiên cứu thực sự dứt khoát trong lĩnh vực này; xem phụ lục. Ý tưởng rằng một nghiên cứu 'dứt khoát' có thể được sử dụng thay vì phán đoán của chuyên gia để đưa ra quyết định kiến ​​trúc quan trọng là 'kháng cáo chính quyền', đó là một hình thức ngụy biện logic :) Theo kinh nghiệm của tôi - và tôi không làm chăn những lời buộc tội, chỉ là một quan sát - việc tìm kiếm những thứ như vậy thường là một nỗ lực để tránh trách nhiệm cho một quyết định, hoặc một nỗ lực để hỗ trợ một quyết định đã được đưa ra.
Steven A. Lowe
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.