Tại sao một số lập trình viên nghĩ rằng có một sự tương phản giữa lý thuyết và thực hành? [đóng cửa]

So sánh kỹ thuật phần mềm với kỹ thuật dân dụng, tôi rất ngạc nhiên khi quan sát một cách suy nghĩ khác: bất kỳ kỹ sư dân sự nào cũng biết rằng nếu bạn muốn xây dựng một túp lều nhỏ trong vườn, bạn có thể lấy nguyên liệu và xây dựng nó trong khi bạn muốn xây dựng một ngôi nhà 10 tầng (hoặc, ví dụ, một cái gì đó như thế này ) bạn cần thực hiện một số phép toán để chắc chắn rằng nó sẽ không sụp đổ.

Ngược lại, nói chuyện với một số lập trình viên hoặc đọc blog hoặc diễn đàn tôi thường thấy một ý kiến ​​phổ biến rộng rãi có thể được hình thành ít nhiều như sau: lý thuyết và phương pháp chính thức dành cho các nhà toán học / nhà khoa học trong khi lập trình thiên về việc hoàn thành công việc .

Điều thường được ngụ ý ở đây là lập trình là một thứ gì đó rất thực tế và mặc dù các phương pháp chính thức, toán học, lý thuyết thuật toán, ngôn ngữ lập trình sạch / mạch lạc, v.v., có thể là những chủ đề thú vị, chúng thường không cần thiết nếu tất cả mọi người muốn là có được mọi thứ thực hiện .

Theo kinh nghiệm của tôi, tôi sẽ nói rằng trong khi bạn không cần nhiều lý thuyết để kết hợp một kịch bản 100 dòng (túp lều), để phát triển một ứng dụng phức tạp (tòa nhà 10 tầng), bạn cần một thiết kế có cấu trúc, tốt phương pháp xác định, ngôn ngữ lập trình tốt, sách văn bản tốt nơi bạn có thể tra cứu thuật toán, v.v.

Vì vậy, lý thuyết IMO (đúng số lượng) là một trong những công cụ để hoàn thành công việc .

Câu hỏi của tôi là tại sao một số lập trình viên nghĩ rằng có một sự tương phản giữa lý thuyết (phương pháp chính thức) và thực hành (hoàn thành công việc)?

Là kỹ thuật phần mềm (phần mềm xây dựng) được nhiều người nhận thức là dễ dàng so với, nói, kỹ thuật dân dụng (xây dựng nhà ở)?

Hay hai môn học này thực sự khác biệt (ngoài phần mềm quan trọng, nhiệm vụ phần mềm dễ chấp nhận hơn nhiều so với thất bại trong việc xây dựng)?

Tôi cố gắng tóm tắt, những gì tôi đã hiểu từ các câu trả lời cho đến nay.

1. Trái ngược với công nghệ phần mềm, trong kỹ thuật dân dụng, rõ ràng hơn bao nhiêu lượng lý thuyết (mô hình hóa, thiết kế) là cần thiết cho một nhiệm vụ nhất định.
2. Điều này một phần là do thực tế là kỹ thuật dân dụng cũng lâu đời như loài người trong khi công nghệ phần mềm chỉ mới xuất hiện được vài thập kỷ.
3. Một lý do khác là phần mềm là một loại vật phẩm dễ bay hơi hơn, với các yêu cầu linh hoạt hơn (nó có thể được cho phép sụp đổ), các chiến lược tiếp thị khác nhau (thiết kế tốt có thể được hy sinh để đưa nó ra thị trường một cách nhanh chóng), v.v.

Kết quả là, rất khó để xác định mức độ phù hợp của thiết kế / lý thuyết phù hợp trong công nghệ phần mềm (quá ít -> mã lộn xộn, quá nhiều -> Tôi không bao giờ có thể hoàn thành) vì không có quy tắc chung và chỉ (rất nhiều) kinh nghiệm có thể giúp đỡ.

Vì vậy, nếu tôi giải thích chính xác câu trả lời của bạn, sự không chắc chắn này về bao nhiêu lý thuyết thực sự cần thiết góp phần vào cảm xúc yêu / ghét hỗn hợp mà một số lập trình viên hướng tới lý thuyết.

Tôi nghĩ rằng sự khác biệt chính là với kỹ thuật dân dụng, vật lý thế giới thực hoạt động như một kiểm tra thực tế mạnh mẽ, liên tục, giữ cho lý thuyết lành mạnh và cũng hạn chế các thực hành xấu, trong khi trong công nghệ phần mềm không có lực lượng mạnh như nhau để giữ các khái niệm tháp ngà không thực tế. như tay nghề kém chất lượng trong kiểm tra.

Nhiều lập trình viên đã có kinh nghiệm tồi tệ với lý thuyết chạy trốn trở thành một trở ngại tích cực để hoàn thành công việc (ví dụ: "UML thực thi", các quy trình phát triển siêu quan liêu). Ngược lại, các bản hack và bản vá bẩn có thể giúp bạn đi khá xa, mặc dù cuối cùng cũng chậm. Và như bạn quan sát trong đoạn cuối của bạn: thất bại thường không phải là cuối cùng và do đó không phải là vấn đề.

Kỹ thuật phần mềm và kỹ thuật dân dụng có ít điểm chung. Những nỗ lực kỹ thuật dân dụng bị giới hạn bởi các tính chất vật lý của vật liệu và môi trường. Kỹ sư xây dựng dành nhiều thời gian để tìm hiểu về tính chất đất và đặc tính vật liệu. Phát triển phần mềm chỉ bị giới hạn về mặt vật lý bởi tốc độ của bộ xử lý và bộ lưu trữ có sẵn. Cả hai điều này đều dễ hiểu và chúng tôi không dành nhiều thời gian để nghiên cứu chúng. Hạn chế chính để phát triển phần mềm là trí tuệ của con người. Và không có hai nhà phát triển giống nhau. Mã này có thể duy trì? Bởi ai? Việc triển khai quicksort ba dòng trong Haskell rõ ràng có thể đúng với một số người, nhưng không thể hiểu được với những người khác. Một nhóm gồm hai người có thể hoàn thành một ứng dụng trong một tháng, trong khi một nhóm khác gồm mười người phải vật lộn để giao hàng trong một năm.

Phát triển phần mềm là tất cả các thiết kế, các tạo tác đang được thiết kế là các đơn đặt hàng có độ lớn phức tạp hơn bất kỳ bài viết nào được sản xuất và mỗi bài viết là duy nhất.

Là một kỹ sư cơ khí ít nhiều trung thực (với một số dân sự) đã trở thành lập trình viên, rồi tiến sĩ CS (AI), rồi giáo viên, rồi lập trình viên một lần nữa (xin lỗi, Kỹ sư phần mềm ), tôi đã nổi giận chủ đề chung này.

Trong kỹ thuật truyền thống

• bạn phải biết toán học và khoa học của mình vì mọi thứ bạn làm đều dựa trên nó
• "anh hùng" trong lĩnh vực này là những người phát minh ra những điều mới, khám phá những ý tưởng mới, giải quyết những vấn đề được coi là không thể giải quyết

Có một "vật lý" áp dụng cho phần mềm - lý thuyết thông tin, nhưng các kỹ sư phần mềm ít tiếp xúc với nó và chắc chắn không có gì được áp dụng. Lý thuyết nhất họ nhận được là khả năng tính toán và big-O.

Ngoài ra, tôi liên tục ngạc nhiên về những người nghĩ rằng biết lập trình là đủ, và họ không cần phải hiểu vấn đề của chương trình của họ là gì.

Hơn nữa, tính sáng tạo không được khuyến khích. Nó không được khuyến khích, ủng hộ các phương pháp suy nghĩ nhóm mẫu số ít phổ biến nhất, được ngụy trang thành "khả năng đọc". (Hãy tưởng tượng nếu các kỹ sư hàng không hoặc hạt nhân được khuyến khích không làm bất cứ điều gì có thể khó hiểu đối với các đồng nghiệp cơ sở của họ.)

Những điều họ học được, như cách lập trình ứng dụng web, có giá trị lớn. Kỹ năng của thợ sửa ống nước hoặc thợ điện cũng vậy, nhưng nó không phải là kỹ thuật.

Nếu tôi cắt một góc trên hầu hết các phần mềm và làm một cái gì đó không phải là thiết kế tốt nhất, nhưng sẽ hoàn thành công việc, không ai sẽ chết. Đó là lý do tương tự một túp lều trong vườn không cần các tiêu chuẩn giống như tòa nhà 10 tầng. Tuy nhiên, tôi có thể xây dựng một ứng dụng rất lớn như facebook, và nếu nó làm hỏng và mất một số dữ liệu, hoặc bất cứ điều gì, nó không thực sự là vấn đề lớn. Thực tế cũng đơn giản hơn để sửa nền tảng của một ứng dụng lớn, hơn là thay thế nền tảng của tòa nhà 10 tầng. Tất cả bắt nguồn từ bối cảnh và tính toán rủi ro.

Tôi cũng có thể, an toàn và đơn giản là tiếp tục thêm vào một ứng dụng. Bạn không thể dễ dàng ném lên tầng ba mới của tòa nhà 10 tầng (biến nó thành 11). Tôi có thể đưa một tính năng mới vào một ứng dụng lớn mỗi ngày nếu tôi muốn.

Bây giờ, thiết kế tốt làm cho tất cả điều này dễ dàng hơn trong lập trình. Nhưng điều đó không phải là không thể với thiết kế kém và rủi ro là ... phần mềm lỗi. Không thường chết.

Chịu đựng tôi về điều này. Tôi có một điểm.

Tôi đã có một giáo sư nói với tôi một lần rằng sự chần chừ dẫn đến sự chần chừ hơn, mặc dù hầu hết mọi người sau một đêm quấy rối viết giấy / nhồi nhét / lập trình đều nói với chính họ, "Tôi sẽ không bao giờ làm điều đó một lần nữa. và hoàn thành sớm. " Theo kinh nghiệm của tôi với tư cách là người trì hoãn hoàn toàn, tôi đã thấy điều này là đúng và đây là lời giải thích của giáo sư tại sao: cho dù kinh nghiệm của sự trì hoãn là khó chịu như thế nào, trong hầu hết các trường hợp, bạn đã hoàn thành được thành công tương đối. Đây là rủi ro cao / hành vi khen thưởng cao. Sau một thời gian, bạn quên đi tất cả những điều khó chịu, và chỉ nhớ phần thưởng. Do đó, sự cám dỗ tiếp theo để trì hoãn là tất cả những gì hấp dẫn hơn, bởi vì bạn đã thành công lần cuối cùng.

Tôi nghĩ rằng một sự tương tự có thể được thực hiện ở đây với kỹ thuật lập trình "hoàn thành công việc" mà tất cả chúng ta thường thấy. Một lập trình viên hoặc nhóm lập trình viên, có thể vì sự thờ ơ, lười biếng, hoặc có lẽ là hạn chế thời gian thực sự, đưa phương pháp "hoàn thành công việc" vào lập trình, ném tất cả lý thuyết và toán học của bạn và thực hành tốt ra ngoài cửa sổ. Và bạn biết những gì? Họ hoàn thành công việc Nó không thanh lịch, đẹp, hoặc có thể bảo trì, nhưng nó hoàn thành công việc. Có thể một cấp trên phi kỹ thuật không biết dấu chấm phẩy từ semaphore mang đến cho họ một số lời khen ngợi cao về "hoàn thành công việc". Vì vậy, lần tiếp theo, lập trình viên bị cám dỗ áp dụng cách tiếp cận chậm chạp này vào lập trình, mọi thứ sẽ dễ dàng hơn, bởi vì, lần trước nó đã hoạt động phải không? Đó là lối thoát "dễ dàng", trừ khi người nghèo của bạn,

Tôi đã từng là một linh hồn đáng thương, đáng tiếc, và có rất nhiều bạn có lẽ. Tôi cầu xin tất cả các bạn. Đừng đi đường dễ dàng! :)

Tiền đề của bạn là thiếu sót. Lý do chính khiến các kỹ sư dân dụng sử dụng kỹ thuật khi thiết kế các tòa nhà lớn, cầu, đường hầm, v.v. là để đảm bảo rằng họ đang sử dụng lượng vật liệu tối thiểu (bê tông, thép kết cấu, v.v.) đáp ứng các tiêu chuẩn an toàn cần thiết. Hoàn toàn có thể xây dựng một tòa nhà cao tầng mà không cần nhiều toán học (ví dụ: kim tự tháp của nền văn minh Ai Cập và Maya cổ đại) nếu chi phí vật chất và lao động không có đối tượng, nhưng một khi đã được xây dựng, thường không có điểm nào để sửa đổi họ để làm cho họ sử dụng vật liệu hiệu quả hơn.

Có một sự năng động khác nhau trong việc thiết kế các hệ thống phần mềm lớn. Nếu bất cứ điều gì, chúng thường được thiết kế dưới, nhưng điều này là do thiết kế có thể được thay đổi linh hoạt khi tiến hành công việc, điều đơn giản là không thể thực hiện dễ dàng với các dự án kỹ thuật dân dụng.

Yếu tố phổ biến là chi phí. Thiết kế trên một dự án kỹ thuật dân dụng truyền thống giúp giảm chi phí (cả thực tế, về vật liệu và tiềm năng về trách nhiệm pháp lý), trong khi đó có một điểm trong phát triển phần mềm khi chi phí thiết kế tăng vượt quá giá trị trả về.

Tôi cũng sẽ chỉ ra, ngoài một số câu trả lời xuất sắc khác mà nhân loại đã làm tương đương với "kỹ thuật dân dụng" vì thời Ai Cập dễ dàng vì vậy chúng ta đã có nhiều thời gian để hoàn thiện lý thuyết chung về cách mọi thứ nên được thực hiện. Chúng tôi đã xây dựng phần mềm trong khoảng 70 năm hoặc lâu hơn (tùy thuộc vào những gì bạn cho là "phần mềm" đầu tiên); Ý tôi là chúng ta không có cùng thời gian để phát triển cùng một loại kinh nghiệm.

Bản thiết kế của kiến ​​trúc sư / dân dụng hầu như không bao giờ giống với kế hoạch "như đã xây dựng". Một cái gì đó LUÔN thay đổi. Tại sao? Bởi vì có, và sẽ luôn luôn là "những ẩn số chưa biết". Có những điều bạn biết và có thể lên kế hoạch, những điều bạn biết là chưa biết và vì vậy bạn có thể nghiên cứu và ước tính, và sau đó có những điều bạn không biết bạn không biết; "Bất ngờ". Bạn đặt mục tiêu loại bỏ những thứ này trong hầu hết các hệ thống bằng cách học tất cả những gì bạn có thể, nhưng tất cả chỉ là một vi phạm mã xây dựng nhỏ (có thể dựa trên quy tắc không tồn tại 2 năm trước khi tòa nhà của bạn được khái niệm hóa) và tất cả kế hoạch tổng thể bao gồm phải thay đổi, đôi khi khá quyết liệt.

Phần mềm rất giống như thế này; Luôn luôn có một ẩn số chưa biết. Tuy nhiên, không giống như kỹ thuật dân dụng hoặc kết cấu, phát triển phần mềm vốn đã khoan dung hơn nhiều đối với sự thay đổi dựa trên những vấn đề mà những ẩn số chưa biết tạo ra. Nếu bạn đang xây dựng tòa nhà 10 tầng và bạn đã đánh giá quá cao khả năng chịu tải của nền tảng bạn đặt trong thiết kế của mình, bạn không thể xây dựng tòa nhà thành 10 tầng hoặc bạn phải phá bỏ một lượng công việc đáng kể trở lại nền tảng và củng cố hoặc xây dựng lại nó. Tuy nhiên, trong phần mềm, nếu bạn đánh giá thấp các yêu cầu đối với một tầng cụ thể của cấu trúc giải pháp tổng thể, có nhiều tùy chọn để sửa lỗi tầng đó không liên quan đến việc vô hiệu hóa tất cả các công việc khác. Bạn có thể thay thế một máy chủ DB bằng một máy chủ mạnh hơn hoặc cụm sao chép / chuyển đổi dự phòng, hoặc một cụm cân bằng tải / phân phối. Tương tự cho máy chủ web. Nếu bạn mã hóa một thuật toán không hiệu quả nhưng đơn giản dựa trên các giả định sai về kích thước đầu vào, bạn hầu như luôn có thể loại bỏ và viết lại việc thực hiện theo cách tương đối phẫu thuật, mà không ảnh hưởng đến mã khác có kiến ​​thức về thuật toán (gọi và chuyển đầu vào nó, hoặc mong đợi một đầu ra từ nó).

Sự dễ dàng thay đổi tương đối này cho phép một kỹ sư phần mềm viết mã dựa trên những gì anh ta biết mà không phải lo lắng quá mức về những gì anh ta không biết. Điều này cho phép áp dụng lý thuyết lỏng lẻo và thiết kế khái niệm trước; bạn đi sâu vào và hoàn thành nó, và trên đường bạn tìm thấy những thứ bạn đã mã hóa cần thay đổi, và thay đổi chúng. Bạn vẫn phải biết các khái niệm và lý thuyết, bởi vì khi một vấn đề được phát hiện ra, đó là những điều sẽ giúp bạn xác định nguyên nhân và tạo ra giải pháp. Tuy nhiên, bạn được phép đưa ra quyết định nhanh chóng mà không chịu thua "tê liệt phân tích", vì nếu hóa ra bạn đã đưa ra quyết định sai dựa trên điều gì đó bạn không biết hoặc không ảnh hưởng đến "tính toán" của bạn, sai lầm dễ sửa hơn.

Sự khác biệt chủ yếu là do các yêu cầu đã biết:

• Về mặt lý thuyết, mọi thứ đều được xác định trước, vì vậy bạn có thể biết chính xác những gì bạn cần trước khi bắt đầu.
• Trong thực tế, chúng thường không có ở đó hoặc bạn phát hiện ra điều gì đó giữa chừng trong quá trình thực hiện khiến bạn phải thiết kế lại một cái gì đó. Vì vậy, tốt hơn hết là nhảy với ít nhất là các thiết kế thô sơ, để bạn có thể sớm phát hiện ra những vấn đề này.

Ngoài ra, khi nói về "lý thuyết", nó thường có nghĩa là khía cạnh lý thuyết của khoa học máy tính, thay vì kỹ thuật phần mềm. Đây là một phần của khoa học máy tính chủ yếu là tìm kiếm các thuật toán tốt hơn và hiệu quả hơn, chứng minh liệu điều gì đó có thể hoặc không thể (ví dụ P và NP), v.v. Mặc dù thật tốt khi có những điều này trong tâm trí bạn, nhưng chúng không xuất hiện trong quá trình phát triển phần mềm rất thường xuyên.

Chúng tôi sử dụng các thư viện cho loại điều đó càng nhiều càng tốt.

Thực tế có khá nhiều cấp độ kỹ thuật phần mềm tùy thuộc vào phần mềm bạn đang xây dựng đang làm gì.

NASA cần phần mềm để điều khiển các tàu con thoi có người lái trong không gian, do đó, mức độ của quy trình kỹ thuật sẽ nghiêm ngặt hơn nhiều so với việc xây dựng một trang web để hiển thị hình ảnh của tên lửa.

Một trong những đồng nghiệp của tôi từng làm việc cho NASA trước đây đã mô tả quy trình kỹ thuật phần mềm của họ là viết hàng trăm trang biện minh và hàng trăm giờ họp để biện minh cho việc viết một dòng mã!

Đừng hiểu lầm tôi vì tôi không cố tỏ ra thiếu tôn trọng khi tôi nói điều này nhưng ngay cả sau tất cả chi phí thời gian, tài nguyên và hàng tỷ đô la, tàu con thoi vẫn nổ tung.

Ngay cả các kỹ sư dân sự cũng biết rằng cho dù họ đưa vào thiết kế bao nhiêu lý thuyết thì cuối cùng cũng sẽ phá vỡ nó vì vậy họ cũng cần phát triển các kế hoạch dự phòng.

Khi xây dựng phần mềm, chi phí của nó bị sập hiếm khi gây mất mạng nên việc nhanh chóng ném đồ ra khỏi đó và lái thử nó sẽ dễ dàng hơn nhiều. Hãy đồng ý rằng hoàn thành công việc nhanh chóng dẫn đến mã yếu. Ngay cả khi điều này luôn luôn đúng, nhìn thấy phần mềm đang hoạt động là cách tốt nhất để nhà phát triển thấy nơi yếu và cần được làm mạnh hơn so với nơi yếu và vẫn mạnh hơn gấp nhiều lần so với mức cần thiết để theo kịp tải trọng.

Tóm lại, Premature optimization is the root of all evil hoặc như ông chủ của tôi sẽ luôn nóiShipping is a feature!

Có rất nhiều câu trả lời hay ở đây, nhưng tôi nghĩ rằng sự so sánh giữa Khoa học Máy tính và Kỹ thuật Xây dựng là thiếu sót.

Nói đúng ra, những gì các nhà phát triển phần mềm chuyên nghiệp làm giống như Kỹ thuật phần mềm hơn là Khoa học máy tính. Một điểm tương đồng tốt hơn là Khoa học Máy tính là Vật lý cho Kỹ thuật Phần mềm. Tương tự, Civil Engieering là một tập hợp các đơn giản hóa và xấp xỉ Vật lý để thực tế xây dựng công cụ.

Tôi tưởng tượng rằng Kỹ sư xây dựng hiếm khi phải tính đến thuyết tương đối rộng khi đi làm. Phần lớn Kỹ thuật Xây dựng có thể được xây dựng một cách an toàn trong Cơ học Newton. Tương tự, Kỹ thuật phần mềm có thể được thực hiện rất thành công với sự hiểu biết gần đúng về khoa học máy tính lý thuyết.

Sự khác biệt lớn là những cây cầu, tòa nhà chọc trời và các sản phẩm khác của Kỹ thuật Xây dựng là những điều được hiểu một cách hợp lý. Các kỹ sư phần mềm thường xây dựng các cấu trúc mới, hoặc sử dụng các phương pháp mới để xây dựng những thứ được hiểu rõ. Kỹ thuật phần mềm là FAR kém trưởng thành hơn Kỹ thuật Xây dựng và điều đó có thể sẽ tiếp tục đúng trong tương lai gần.

TL; DR : Lý thuyết và thực hành là khác nhau trong Kỹ thuật phần mềm giống như chúng ở mọi nơi khác. Sự tương đồng thích hợp là Kỹ thuật phần mềm: Xây dựng dân dụng :: Khoa học máy tính: Vật lý. Nhưng trong thực tế, nó phức tạp hơn thế một chút :)

Vì vậy, câu hỏi của tôi là tại sao một số lập trình viên nghĩ rằng có một sự tương phản giữa lý thuyết (phương pháp chính thức) và thực hành (hoàn thành công việc)?

Xây dựng phần mềm không giống như xây dựng một cây cầu. Trong phần mềm, có nhiều đối tượng được xây dựng có thể được xác định hoặc không được xác định khi bắt đầu. Các tiêu chuẩn tồn tại để tăng tính dễ bảo trì và cộng tác của nhà phát triển, không tuân thủ các công thức toán học tùy tiện hoặc các lý tưởng khác. Ví dụ, khi chọn hành vi dựa trên một biến số đôi khi có ý nghĩa khi sử dụng một công tắc, lần khác là một mẫu nhà máy. Nó phụ thuộc vào sự dễ dàng của bảo trì và xác định các điểm đau như vấn đề hiệu suất.

Một ví dụ khác có thể được thực hiện với thao tác dữ liệu. Nó thường có ý nghĩa để sử dụng các đại biểu trong bối cảnh của .NET. Nó không dễ dàng như vậy trong Java vì nó không có khung hỗ trợ cho phong cách lập trình chức năng mà .NET có. Nói cách khác, trong trường hợp chung, đơn giản là không thể thực hiện X trong tình huống Y. Điều này là do thực tế là X và Y phụ thuộc vào N số yếu tố biến.

Là kỹ thuật phần mềm (phần mềm xây dựng) được nhiều người coi là dễ dàng so với, nói, kỹ thuật dân dụng (xây nhà)?

Tôi không chắc chắn "dễ dàng" là thuật ngữ chính xác. Việc thiếu bằng chứng hữu hình có thể dẫn đến nhận thức rằng không có công việc nào được thực hiện. Hoặc, tương tự, công việc hiện tại dễ dàng thay đổi.

Hay hai môn học này thực sự khác biệt (ngoài phần mềm quan trọng, nhiệm vụ phần mềm dễ chấp nhận hơn nhiều so với thất bại trong việc xây dựng)?

Kỹ thuật truyền thống và Kỹ thuật phần mềm rất khác nhau vì những lý do tôi đã nêu.

Nhận thức của bạn có thể sai ở đây hoặc nó bao gồm nhiều tài nguyên từ những người chưa viết phần mềm đủ phức tạp.

Trải nghiệm của bạn là phù hợp với những gì hầu hết những người tôi biết (những người đã thiết kế và viết phần mềm đủ phức tạp) sẽ nói.

Điều đó nói rằng, khi nói đến hầu hết các lập trình viên , khi nhiệm vụ viết một cái gì đó cho họ thiết kế ("toán học" như bạn nói) đã được thực hiện bởi kiến ​​trúc sư / người lãnh đạo / v.v. trước khi thực hiện nhiệm vụ viết nó cho họ. Vì vậy, nó có thể xuất hiện theo cách đó từ cấp độ tiền tuyến.

Tôi nghĩ lý do cho sự tương phản này là vòng đời của một dự án phần mềm và dự án phần cứng hoặc kiến ​​trúc là khác nhau. Hầu hết các phần mềm phát triển dần dần, nó không được lên kế hoạch từ đầu đến cuối. Các nhà phát triển phần mềm có thể áp dụng cách tiếp cận lặp lại để phát triển: lập kế hoạch, thực hiện và lắng nghe phản hồi. Nếu phản hồi là tích cực, hãy tiếp tục, nó không - lùi lại một bước và xem xét lại chiến lược của bạn. Đó là lý do tại sao các nhà phát triển phần mềm có những thứ như phát triển nhanh, sản phẩm khả thi tối thiểu, v.v.

Kỹ sư xây dựng không có sự sang trọng như vậy. Đối với họ, một khi một cái gì đó được lên kế hoạch, bạn không thể thay đổi nó dễ dàng như với phần mềm, bởi vì chi phí cho những thay đổi đó có thể rất khủng khiếp. Mặt khác, để phát triển phần mềm, nó không tốn nhiều tiền và điều này có thể được sử dụng cho lợi thế của họ.

Nhưng không phải mọi ngành phát triển phần mềm đều có thể chi trả cho cách tiếp cận như vậy. Làm phần mềm, ví dụ, cho các dịch vụ hàng không hoặc y tế đòi hỏi lập kế hoạch rất cẩn thận và rất nhiều tính toán trước đó.

Nó có vẻ giống với tôi. Bạn xây dựng một tòa nhà lớn trong số các khối tiêu chuẩn, bê tông cường độ tiêu chuẩn, thép tiêu chuẩn. Bạn xây dựng một ứng dụng lớn từ các thư viện tiêu chuẩn.

Bạn không thử và chính thức chứng minh một ứng dụng lớn chính xác giống như cách bạn không thử và viết hàm sóng cho tòa nhà 100 tầng

Tôi là một kỹ sư cơ khí và sản xuất trước khi tôi phát hiện ra khoảng 20 năm trước rằng năng khiếu của tôi nằm ở phần mềm. Tôi đồng cảm với nhiều yếu tố mà bạn đã đặt ra.

Tôi nghi ngờ rằng bản chất thực sự của vấn đề là về cách chúng ta hoàn thành công việc. Bây giờ chúng tôi đã có mười năm phát triển nhanh nhẹn dưới vành đai tập thể của chúng tôi, và thông điệp rất rõ ràng. Đừng tiến bộ theo từng lớp; tiến bộ bằng tính năng. Chắc chắn - sẽ có các dự án khi bạn cần tiến triển theo từng lớp (ví dụ: xây dựng ngăn xếp mạng của bạn trước máy chủ web của bạn) nhưng đối với phần lớn các dự án trong thế giới thực, chúng tôi đã học được bài học cung cấp các tính năng làm việc, một hoặc một vài một thời gian, là hiệu quả hơn nhiều để xây dựng các lý thuyết lớn chưa được kiểm chứng, và sau đó cố gắng thực hiện chúng.

Vì vậy, hãy lấy ví dụ về túp lều của bạn (tôi thường nói về việc làm một cây cầu bằng cách ném một khúc gỗ qua luồng so với cây cầu treo dài hàng km ... bất cứ điều gì!), Và đưa nó vào thế giới của công nghệ phần mềm. Sự khác biệt chính mà tôi thấy là trong phần mềm, hầu hết các công việc đều có quy mô mà nó không cần mô hình hóa lớn để thành công. Sai lầm của người mới bắt đầu thường cho rằng mọi thứ cần nhiều thứ hơn so với thực tế và đối với hầu hết chúng ta, đã mắc lỗi đó một vài lần, chúng tôi rất muốn làm lại nó quá thường xuyên.

Không có tranh luận - có những dự án cần bắt đầu với một ủy ban gồm 17 kiến ​​trúc sư phần mềm. Trong thực tế, chúng hiếm như kim cương 20 cara.

Tôi nghĩ rằng sự tương tự là thiếu sót. Theo như tôi biết, kỹ thuật dân dụng không có cơ sở lý thuyết giống như khoa học máy tính; khoa học máy tính được sinh ra từ toán học lý thuyết, giống như máy Turing. Kỹ thuật dân dụng là về việc tạo ra các cấu trúc chống lại mẹ thiên nhiên và thậm chí có thể trông đẹp. Một lần nữa, tôi thực sự không biết nhiều về kỹ thuật dân dụng, nhưng tôi không nghĩ có những kỹ sư dân sự tương đương với P vs NP, người bán hàng rong và những điều thú vị khác để đánh bại bộ não của bạn. Và chắc chắn có một nơi dành cho lý thuyết khoa học máy tính của chúng ta nếu ai đó giải quyết được nhân viên bán hàng du lịch hoặc vấn đề tạm dừng chúng ta đang có rất nhiều tiến bộ mới tuyệt vời. Nhưng đối với một kỹ sư phần mềm, người có kinh doanh là kiến ​​trúc sư phần mềm, những vấn đề như vậy thực sự chỉ là niềm vui và trò chơi.

Bây giờ, tôi cũng nghĩ rằng nó phụ thuộc vào ý nghĩa của "lý thuyết". Có phải chúng ta đang nói mẫu thiết kế, hoặc bơm bổ đề? Bởi vì có một sự hiểu biết vững chắc về các mẫu thiết kế là rất quan trọng để trở thành một kỹ sư phần mềm giỏi. Tuy nhiên, khi kiến ​​trúc một hệ thống phần mềm lớn, lý thuyết về các vấn đề P / NP không hữu ích. Theo nghĩa đó, tôi tin rằng có một sự tương phản rất rõ ràng giữa công nghệ phần mềm và khoa học máy tính lý thuyết.

Hay lý thuyết đề cập đến các thuật toán? Bạn không dành nhiều thời gian để viết các thuật toán bạn đã học trong lớp thuật toán của mình. Tại sao? Bởi vì bạn thường chỉ cần chúng trong các trường hợp cụ thể (và sau đó bạn tìm kiếm nó và nghiên cứu nó), hoặc bạn sử dụng một thư viện đã được viết cho bạn. Không cần phải viết một phân loại bayesian. Trừu tượng là một nguyên tắc quan trọng trong khoa học máy tính. Tôi nghĩ các kỹ sư phần mềm có xu hướng không học cách thuật toán hoạt động cho đến khi họ cần.

Một lý do khác là hiện tại có một số phương pháp phát triển phần mềm "hoàn thành công việc" phổ biến có hiệu quả. Ví dụ, trong phát triển nhanh, bạn không thiết kế toàn bộ hệ thống trước đó. Lý do cho điều này là bởi vì bạn không biết chính xác những gì bạn đang xây dựng nên bạn muốn những gì bạn đang làm để trở nên linh hoạt và thích nghi với thông tin và yêu cầu mới. Thiết kế tất cả từ đầu ra và sau đó xây dựng không phải lúc nào cũng tạo ra phần mềm tốt nhất. Tuy nhiên, nó không phải là giải pháp cho mọi thứ. Ví dụ: giả sử bạn đang thiết kế một số thứ mới về điện toán phân tán-cụm-điên-mới. Bạn không thể thực hiện một số bản phác thảo khăn ăn và bắt đầu SCRUM của bạn.

TL; DR. Tôi nghĩ rằng có một số tương đương xung quanh từ "lý thuyết." Theo truyền thống, lý thuyết đề cập đến các khía cạnh toán học lý thuyết của khoa học máy tính. Trừ khi bạn đang nghiên cứu các cách tính toán mới hơn, phần lớn khoa học máy tính lý thuyết không đóng vai trò gì trong cuộc sống hàng ngày của một kỹ sư phần mềm. Kỹ sư phần mềm quan tâm đến các mẫu thiết kế và kiến ​​trúc hệ thống. Chi tiết thực hiện cụ thể của các thuật toán nhất định không quan trọng. Thông thường với những ý tưởng ít phức tạp hơn, nó phù hợp để không thiết kế nhiều và chỉ bắt đầu viết mã. Và tôi nghĩ rằng đây là nơi mà ý tưởng xuất phát từ việc các lập trình viên không thích lý thuyết.

Khoảng cách giữa lý thuyết và thực hành là quá lớn tại thời điểm này. Khi thực hiện lý thuyết, bạn được đưa ra ba tiên đề và sau đó được chỉ ra rằng một định lý một dòng có một chứng minh nghìn trang hoặc không có bằng chứng nào cả. Trong công nghệ phần mềm, bạn được cung cấp các API không nhất quán của hàng ngàn chức năng cung cấp cho bạn vô số cách (xấu) khi thực hiện một tính năng chưa được xác định rõ.

Kỹ thuật phần mềm thực sự sẽ khiến hầu hết những người trong lĩnh vực chính thức phát điên, và sự phát triển phần mềm toán học thực sự khiến những người trong ngành kỹ thuật phát điên. Cả hai lĩnh vực đều yêu cầu những người có năng khiếu khác nhau và tôi không nghĩ rằng những năng khiếu này thường trùng lặp.

Lý thuyết chính thức giả định rằng bạn có thể lập kế hoạch chính xác mọi thứ trước như một sản phẩm được sản xuất, phần mềm đó sẽ tồn tại vô thời hạn trong cùng một môi trường và việc giải quyết một vấn đề trừu tượng chung luôn là mục tiêu. Nó giả định vòng đời sản phẩm phần mềm 4D: thiết kế, phát triển, triển khai, thực hiện. Lý thuyết chính thức là giải quyết vấn đề thiết kế phần mềm bằng cách sử dụng phân tích, trừu tượng hóa, khái quát hóa và dự đoán sự thay đổi trong tương lai. Điều này là tốt nếu bạn có một vấn đề được xác định rõ trong một miền đơn giản, dễ phân tích, dự đoán và khá tĩnh.

Lập trình thực tế là giải quyết vấn đề đúng (không phải là thiết kế phần mềm) theo đúng cách ngay bây giờ, để đồng nghiệp của bạn có thể thực hiện công việc của họ tốt hơn / nhanh hơn / tất cả, hoặc để doanh thu có thể chảy vào công ty. Nhiều phần mềm không giống như một sản phẩm, không bao giờ 'hoàn thành', mà giống như một sinh vật sống, bắt đầu chuyên môn hóa cao cho một ngách sinh thái và có thể có tuổi thọ thay đổi rộng rãi trong đó nó cần phải giải quyết các vấn đề mới, giải quyết các vấn đề mới nhiều môi trường luôn thay đổi. Trong thế giới kinh doanh, với chính trị và pháp lý và cạnh tranh và các tổ chức, cấu trúc và xu hướng luôn thay đổi, các yêu cầu thường mơ hồ, phức tạp với tất cả các loại trường hợp đặc biệt, được xác định kém và có thể thay đổi nhanh chóng. Chúng không thể phân tích, dự đoán hoặc tĩnh, và thường không hợp lý hoặc hợp lý. Phần mềm có khả năng không liên quan trong 2 tuần vì vẫn được sử dụng trong 20 năm. Nó đi vào thế giới không biết nhiều hoặc không thể làm được gì nhiều, và cần được nuôi dưỡng, chải chuốt và rèn luyện suốt đời để lớn lên mạnh mẽ, linh hoạt và có thể thích nghi với môi trường luôn thay đổi và những vấn đề mới. Nếu bạn bỏ bê nó sau khi sinh, nó sẽ trở nên hoang dã nếu nó tồn tại đủ lâu, và gây ra đau đớn và đau khổ, giải quyết các vấn đề với lực cùn.

Lý thuyết chính thức không giải quyết được nhu cầu của nhiều phần mềm kinh doanh trong thế giới thực. Nó lừa chúng tôi tin rằng phần mềm có thể được thiết kế và thực hiện. Đó là một sản phẩm đôi khi có thể được cố định, đánh bóng hoặc có những thứ được xử lý, nhưng không phải là một sinh vật cần được nuôi dưỡng đúng cách với sự quan tâm và chăm sóc liên tục trong suốt cuộc đời của nó. Vì vậy, chúng tôi kết thúc với mã di sản hoang dã thực sự xấu xí, nhưng lý thuyết chính thức có lẽ sẽ không giúp được điều đó.

Điều đó nghe có vẻ khá tiêu cực, nhưng trong thực tế, tôi thích sử dụng lý thuyết chính thức. Một thiết kế đẹp luôn mang lại nụ cười cho khuôn mặt của tôi. Tuy nhiên, đó chủ yếu là trong lập trình sở thích của tôi không chịu sự thay đổi của kinh doanh. Trong công việc, tôi chủ yếu xử lý mã hữu cơ và chỉ hy vọng rằng tôi có thể chú ý đủ để nó phát triển đúng, khiến tôi tự hào và không đáng ghét và thô lỗ với những người khác phải đối phó với nó.

Cổ phần thấp hơn, công việc dễ dàng hơn và quản lý hiếm khi thấy giá trị trong thiết kế tốt. Sự không ổn định của hệ thống, khả năng bảo trì và tính toàn vẹn là một vấn đề "CNTT" - không phải là vấn đề "Kinh doanh". Tất cả các giám đốc điều hành có một điểm chung. Họ hoặc 95% tập trung vào tiền, hoặc họ báo cáo cho ai đó.

Phần còn lại của trận chiến là với các lập trình viên đồng bào của bạn. Nhiều người trong số họ không thể hoặc sẽ không cam kết suy nghĩ về một vấn đề trước khi bắt đầu mã hóa. Do những điều trên, một lượng lớn những người này là các nhà phát triển cao cấp, khiến việc đưa một thiết kế tốt vào sản xuất càng khó khăn hơn.

Tôi đã xem dự án dẫn đầu nhiều năm lãng phí khi thêm các tính năng đặc biệt và sửa lỗi cho các dự án bắt đầu bằng đá, và sau đó bắn hạ mọi nỗ lực để đưa trật tự vào hỗn loạn với các cụm từ như "quá phức tạp" hoặc "lãng phí thời gian". Thật không dễ chịu khi xem một vòng xoáy dự án lớn đến sự diệt vong không thể tránh khỏi của nó bởi vì ban quản lý sẽ không thừa nhận họ đang xây dựng nhà tù của riêng họ hàng ngày; tuy nhiên, tôi sợ rằng đó là một thực tế đáng tiếc mà nhiều nhà phát triển đã chứng kiến ​​và - tốt hơn hoặc tồi tệ hơn - học được từ đó.

Tôi cố gắng tìm một phương tiện trong công việc của tôi. Tôi không viết nhiều mã trong các dự án "vô vị" hơn là hoàn toàn cần thiết và tôi tận dụng mọi cơ hội để chuyển chức năng ra khỏi chúng. "Giữa các dự án," tôi dành thời gian cho thiết kế và dọn dẹp trong các dự án mà tôi thực sự có quyền kiểm soát.

Cuối cùng, đó là một mớ hỗn độn lớn về chính trị và tính chính trực cá nhân mà 75% các lập trình viên trên thế giới không có bụng. Tôi chỉ có thể chịu đựng nó, bản thân mình.

Trước hết, tôi thích câu hỏi này. Tôi đã viết như ba câu trả lời 1000 từ và tất cả chúng đều sai lầm khủng khiếp cho đến khi tôi kết thúc chúng.

Vấn đề với việc cố gắng so sánh hai cái này là tương tự nhau, tôi nghĩ, đó là lập trình là một quá trình mô hình hóa có thể trừu tượng hoặc ràng buộc chặt chẽ với cụ thể như bạn muốn.

Mặt khác, lý thuyết kỹ thuật kết cấu bị ràng buộc chặt chẽ với các bộ luật dựa trên thực tế rất cụ thể mà bạn phải tuân thủ. Bạn không thể thay đổi bối cảnh hoặc luật pháp. Vấn đề tự nó bắt nguồn từ những luật đó. Tuy nhiên, trong lập trình, đôi khi giải pháp thực sự làm thay đổi bản chất của câu hỏi hoặc chỉ đơn giản là đặt nó trong một bối cảnh khác.

Cho dù mẫu MVC, chẳng hạn, có phù hợp hoàn hảo hay không, có liên quan nhiều đến bối cảnh đó. Một ứng dụng máy tính để bàn thường chỉ giao dịch bằng một ngôn ngữ và một ngôn ngữ, không tính các tệp cấu hình.

Mặt trước của một ứng dụng web, mặt khác, bao gồm chủ yếu hai ngôn ngữ khai báo (không lập trình) và JavaScript. Một điều vật lý mà bạn không thể hoàn toàn trừu tượng là thực tế là luôn có bức tường http này để tặc lưỡi giữa máy chủ và trình duyệt. Bất kể bạn chôn nó như thế nào trong mã, điều đó cần có thời gian và thiết kế không đồng bộ.

Rõ ràng bạn không thể sử dụng một mẫu phổ biến và được đánh giá cao như MVC để xử lý các mối quan tâm về giao diện người dùng trên web mà không thay đổi cách bạn có thể xử lý nó trong ngữ cảnh ứng dụng máy tính để bàn. Trong thực tế tôi sẽ tranh luận, bạn nên biết điều gì làm cho MVC trở nên hữu ích nhưng thậm chí không cố gắng thực hiện nó theo cách đặc biệt chính xác hoặc bán buôn. Mô hình ứng dụng web là duy nhất ở chỗ tất cả các công cụ tìm kiếm được xử lý bởi trình duyệt của người dùng và tất cả các công cụ dữ liệu / mô hình-ish thường có trên máy chủ ở đâu đó. Nhưng nơi đó để lại bộ điều khiển? Tất cả trên máy chủ hoặc tất cả ở mặt trước? Ai đó phải sở hữu điều đó. Hoặc có thể MVC không phải là 100% phù hợp nhất cho kịch bản. Không phù hợp cho các công cụ kết thúc .NET. Không khủng khiếp trong bối cảnh các widget UI cụ thể.

Xây dựng một ngôi nhà giải quyết một vấn đề. Tuy nhiên, các vấn đề lập trình điển hình thường liên quan đến việc giải quyết các vấn đề trong các vấn đề và đôi khi giải pháp là xác định lại vấn đề bên ngoài. Thật không may là thực sự quan tâm đến ý tưởng đó không may.

Glenn Vanderburg trình bày một cái nhìn tuyệt vời về sự khác biệt giữa kỹ thuật phần mềm và các ngành kỹ thuật truyền thống hơn: http://www.youtube.com/watch?v=NP9AIUT9nos

Nếu một kỹ sư dân sự có thể thử nghiệm các thiết kế của mình mà không phải trả bất kỳ chi phí nào trước khi xây dựng điều cuối cùng, anh ta sẽ sử dụng lý thuyết ít hơn nhiều. Nếu trong vài giây, anh ta có thể xây dựng một cây cầu miễn phí hàng nghìn lần để kiểm tra khi nào nó bị hỏng, anh ta sẽ làm như vậy thay vì mất hàng tháng để tính toán khi nó có thể phanh trong lý thuyết ...

Trong phát triển phần mềm đó chính xác là những gì bạn làm. Thay vì tính toán tốc độ của thuật toán của bạn trong lý thuyết, bạn chỉ cần kiểm tra nó và biết câu trả lời trong vòng vài giây.

Trong thực tế, hầu hết các phần mềm ngày nay không còn bị giới hạn bởi các ràng buộc vật lý như sức mạnh tính toán hoặc bộ nhớ. Hạn chế của phần mềm là sự phức tạp chiếm số lượng lớn trong các hệ thống lớn hơn và lớn hơn. Nó quản lý sự phức tạp này bằng cách giữ cho hệ thống dễ hiểu bởi con người, điều tạo nên thách thức lớn trong lập trình ngày nay.