Tìm hiểu về phong cách lập trình Mozart của Dijkstra

Question

Tôi đã xem qua this article về các kiểu lập trình, được xem bởi Edsger Dijsktra. Để diễn giải nhanh, sự khác biệt chính là Mozart, khi sự tương tự được tạo ra để lập trình, hoàn toàn hiểu được vấn đề trước khi viết bất cứ điều gì, trong khi Beethoven đưa ra quyết định khi viết ghi chú trên giấy, tạo ra nhiều bản sửa đổi trên đường đi. Với lập trình Mozart, phiên bản 1.0 sẽ là phiên bản duy nhất cho phần mềm có mục tiêu làm việc không có lỗi và hiệu quả tối đa. Ngoài ra, Dijkstra nói rằng phần mềm không ở mức độ tinh tế và ổn định đó không nên được phát hành ra công chúng.

Dựa trên quan điểm của anh ấy, hai câu hỏi. Có phải lập trình Mozart thậm chí có thể? Liệu phần mềm chúng ta viết hôm nay có thực sự có lợi nếu chúng ta áp dụng phong cách Mozart thay vào đó?

Suy nghĩ của tôi. Dường như, để giải quyết sự phức tạp ngày càng tăng của phần mềm, chúng tôi đã chuyển từ phương pháp này sang những thứ như phát triển nhanh, thử nghiệm beta công khai và sửa đổi liên tục, các phương pháp xác định phát triển web, nơi tốc độ quan trọng nhất. Nhưng khi tôi nghĩ về tất cả các phần mềm web sửa đổi có thể đi qua, đặc biệt là trong quá trình bảo trì, khi các bản vá lỗi thường được áp dụng trên các bản vá, sau đó được tinh chế thông qua một quá trình tái cấu trúc tẻ nhạt — cách Mozart có vẻ rất hấp dẫn. Ít nhất nó sẽ làm giảm bớt những cập nhật phần mềm gây phiền nhiễu đó, ví dụ: Digsby, Windows, iTunes, v.v., nhiều kết quả của các lỗ hổng không lường trước được yêu cầu bản phát hành mới và ngay lập tức.

Chỉnh sửa: Tham khảo the response below để có giải thích chính xác hơn về chế độ xem của Dijsktra.

Answer 1

Nó không mở rộng.

Tôi có thể tìm ra một dòng mã trong đầu, một chương trình thông thường và thậm chí là một chương trình nhỏ. Nhưng một chương trình trung bình? Có lẽ một số người có thể làm điều đó, nhưng bao nhiêu, và họ phải trả bao nhiêu? Và liệu họ có thực sự viết chương trình biên chế tiếp theo? Điều đó giống như lãng phí Mozart trên muzak.

Bây giờ, hãy thử tưởng tượng một nhóm người Mozart. Chỉ trong vài giây.

---

Vẫn là công cụ mạnh mẽ. Nếu bạn có thể tìm ra toàn bộ dòng trong đầu, hãy làm. Nếu bạn có thể tìm ra một thói quen nhỏ với tất cả các trường hợp vui nhộn của nó, hãy làm điều đó.

Trên bề mặt, nó tránh quay trở lại bảng vẽ vì bạn không nghĩ đến một vỏ cạnh yêu cầu hoàn toàn giao diện hoàn toàn khác.

Ý nghĩa sâu hơn (head fake?) Có thể được giải thích bằng cách học ngôn ngữ khác của con người. Trong một thời gian dài bạn suy nghĩ từ nào đại diện cho suy nghĩ của bạn, và làm thế nào để đặt chúng vào một câu hợp lệ - phiên mã đó tốn rất nhiều chu kỳ tiền cảnh.
Một ngày nào đó bạn sẽ nhận thấy cảm giác giải phóng mà bạn vừa nói. Nó có thể cảm thấy như "suy nghĩ trong một ngôn ngữ foregin", hoặc như thể "các từ đến một cách tự nhiên". Đôi khi bạn sẽ vấp ngã, tìm kiếm một từ hoặc thành ngữ cụ thể, nhưng phần lớn thời gian dịch chạy trong các tài nguyên rộng lớn của "CPU tiềm thức".

---

Các "Mục tiêu cao" đang phát triển một mô hình tinh thần của giải pháp đó là (chủ yếu) không phụ thuộc vào ngôn ngữ thực hiện, để tách giải pháp của một vấn đề từ chép vấn đề. Transcription là dễ dàng, lặp đi lặp lại và dễ dàng đào tạo, và các giải pháp trừu tượng có thể được tái sử dụng.

Tôi không biết làm thế nào điều này có thể được dạy, nhưng "tìm ra càng nhiều càng tốt trước khi bạn bắt đầu viết nó" âm thanh như thực hành lập trình tốt đối với mục tiêu đó.

Answer 2

Vâng, chúng ta không thể nào tốt bằng Mozart, phải không? Có lẽ lập trình Beethoven dễ dàng hơn.

Answer 3

Câu chuyện cổ điển từ Usenet, về một chương trình Mozart thực sự.

Lập trình viên thực tế viết trong Fortran.

Có thể họ làm gì bây giờ, trong suy đồi thời kỳ này của bia Lite, máy tính cầm tay và phần mềm "thân thiện", nhưng trở lại trong Cựu Ngày Tốt, khi thuật ngữ "phần mềm" nghe có vẻ hài hước và Real Máy tính được làm bằng trống và ống chân không, các lập trình viên thực sự đã viết trong mã máy. Không phải Fortran. Không phải RATFOR. Không, ngay cả, ngôn ngữ lắp ráp. Mã máy. Số liệu thô, chưa được trang trí, số thập lục phân không thể sửa được. Trực tiếp.

Kẻo một thế hệ hoàn toàn mới của lập trình viên lớn lên trong sự thiếu hiểu biết của quá khứ huy hoàng này, tôi cảm thấy bổn phận để mô tả, như tốt nhất mà tôi có thể thông qua sự chênh lệch thế hệ, làm thế nào một Programmer Bất viết mã. Tôi sẽ gọi anh ấy là Mel, bởi vì đó là tên anh ấy.

Lần đầu tiên tôi gặp Mel khi tôi đi làm cho Royal McBee Computer Corp., công ty con hiện tại không còn tồn tại của công ty máy đánh chữ . Công ty sản xuất LGP-30, nhỏ, giá rẻ (theo tiêu chuẩn trong ngày) máy tính bộ nhớ trống và chỉ có bắt đầu sản xuất RPC-4000, được cải thiện nhiều, lớn hơn, tốt hơn, nhanh hơn - máy tính bộ nhớ trống. Lõi chi phí quá nhiều, và không phải ở đây để ở lại, anyway.(Đó là lý do tại sao bạn chưa nghe của công ty, hoặc máy tính.)

tôi đã được thuê để viết một biên dịch Fortran cho kỳ diệu mới này và Mel là hướng dẫn của tôi để điều kỳ diệu của nó. Mel không phê duyệt các trình biên dịch.

"Nếu chương trình không thể viết lại mã số riêng của mình", anh hỏi, "điều gì là tốt?"

Mel đã viết, theo hệ thập lục phân, là chương trình máy tính phổ biến nhất là công ty sở hữu . Nó chạy trên LGP-30 và chơi blackjack với khách hàng tiềm năng tại các chương trình máy tính. Hiệu ứng của nó luôn ấn tượng. Gian hàng LGP-30 được đóng gói ở mọi chương trình và nhân viên bán hàng của IBM đứng xung quanh nói chuyện với nhau. Có hay không máy tính bán thực sự này là một câu hỏi chúng tôi chưa bao giờ thảo luận.

Công việc của Mel là viết lại chương trình blackjack cho RPC-4000. (Port? Điều đó có nghĩa là gì?) Máy tính mới có địa chỉ , trong đó mỗi máy hướng dẫn, ngoài mã hoạt động và địa chỉ của toán hạng cần thiết, có địa chỉ thứ hai chỉ ra ở đâu, trên trống quay , lệnh tiếp theo là . Theo cách nói hiện đại, mỗi hướng dẫn duy nhất được theo sau bởi GO TO! Đặt rằng trong ống Pascal và hút thuốc.

Mel yêu RPC-4000 vì ông thể tối ưu hóa code của mình: đó là, xác định vị trí hướng dẫn trên trống để mà chỉ là một kết thúc công việc của mình, các tiếp theo sẽ chỉ đến vào "đọc đầu "và có sẵn cho thực hiện ngay lập tức. Có một chương trình để thực hiện công việc đó, một "trình tối ưu hóa ", nhưng Mel từ chối sử dụng nó.

"Bạn không bao giờ biết nơi nó sẽ đặt mọi thứ", ông giải thích, "vì vậy bạn muốn phải sử dụng các hằng số riêng biệt".

Đã lâu rồi tôi mới hiểu được nhận xét đó. Vì Mel biết giá trị số của mọi hoạt động mã và được gán cho chính trống của mình địa chỉ, mọi hướng dẫn ông viết cũng có thể được coi là hằng số không đổi. Anh ta có thể nhận một hướng dẫn "thêm" trước đó "thêm", giả sử và nhân bởi nó, nếu nó có giá trị số đúng. Mã của anh ta không dễ dàng đối với một người khác để sửa đổi .

Tôi đã so sánh các chương trình được tối ưu hóa của Mel với cùng một mã được thực hiện bởi chương trình lắp ráp tối ưu hóa, và Mel luôn chạy nhanh hơn. Đó là vì phương pháp "từ trên xuống" của thiết kế chương trình chưa được phát minh , và Mel sẽ không sử dụng nó .Ông đã viết các phần bên trong nhất của vòng lặp chương trình của mình đầu tiên, vì vậy họ sẽ nhận được lựa chọn đầu tiên của các địa chỉ tối ưu địa chỉ trên trống. Bộ kết hợp tối ưu hóa không thông minh đủ để thực hiện theo cách đó.

Không bao giờ viết các vòng lặp thời gian trễ, , ngay cả khi balky Flexowriter yêu cầu sự chậm trễ giữa các ký tự đầu ra để hoạt động bình thường. Ông hướng dẫn chỉ nằm trên trống vì vậy mỗi người liên tiếp chỉ là qua đầu đọc khi cần; trống phải thực hiện một cuộc cách mạng hoàn chỉnh khác để tìm hướng dẫn tiếp theo. Anh ta đã đặt ra một thuật ngữ không thể nào quên cho quy trình này là . Mặc dù "tối ưu" là cụm từ tuyệt đối , như "duy nhất", nó trở thành phổ biến thực hành bằng lời nói để làm cho nó tương đối: "không hoàn toàn tối ưu" hoặc "ít tối ưu" hoặc "không tối ưu". Mel gọi là các vị trí trễ tối đa tối đa "tối đa điểm tối thiểu".

Sau khi hoàn thành chương trình blackjack và đã nhận nó để chạy, ("Ngay cả những initializer được tối ưu hóa", ông nói tự hào), ông nhận được một yêu cầu thay đổi từ bộ phận bán hàng. Chương trình đã sử dụng số ngẫu nhiên (tối ưu) ngẫu nhiên thanh lịch để phát ngẫu nhiên "thẻ" và giao dịch từ "tầng" và một số người bán hàng cảm thấy quá công bằng, vì đôi khi khách hàng bị mất. Họ muốn Mel sửa đổi chương trình, ở cài đặt công tắc cảm ứng trên bảng điều khiển, họ có thể thay đổi tỷ lệ cược và để khách hàng giành chiến thắng.

Mel balked. Ông cảm thấy điều này là một cách rõ ràng không trung thực, và nó là đặt trên tính toàn vẹn cá nhân của ông là một lập trình viên, mà nó đã làm, vì vậy ông từ chối làm điều đó. Trưởng phòng bán hàng số đã nói chuyện với Mel, cũng như ông chủ Big và, theo sự thúc giục của ông chủ, một số ít các biên tập viên . Mel cuối cùng đã cho trong và đã viết mã, nhưng ông đã kiểm tra ngược lại, và, khi cảm giác chuyển đổi được bật, chương trình sẽ ăn gian, chiến thắng mọi lúc. Mel đã rất vui mừng vì điều này, tuyên bố rằng tiềm thức của mình là không thể kiểm soát được đạo đức và kiên quyết từ chối sửa chữa nó.

Sau Mel đã rời công ty cho xanh pa $ ture $, Big Boss hỏi tôi nhìn vào mã và xem nếu tôi có thể tìm được kiểm tra và đảo ngược nó. Hơi miễn cưỡng, tôi đã đồng ý với giao diện . Theo dõi mã của Mel là một cuộc phiêu lưu thực sự .

Tôi thường cảm thấy rằng lập trình là một hình thức nghệ thuật, có giá trị thực chỉ có thể được đánh giá cao bởi một câu hỏi khác trong cùng một nghệ thuật phức tạp; có những viên đá quý xinh xắn và những chiếc coupe rực rỡ ẩn từ quan điểm và sự ngưỡng mộ của con người, đôi khi mãi mãi, bởi chính bản chất của quy trình . Bạn có thể tìm hiểu rất nhiều về cá nhân chỉ bằng cách đọc qua mã của mình, ngay cả trong hệ thập lục phân. Mel là, tôi nghĩ, một thiên tài vô danh.

Có lẽ cú sốc lớn nhất của tôi là khi tôi tìm thấy vòng lặp vô tội không có kiểm tra trong đó. Không kiểm tra. Không có. Cảm giác thường gặp cho biết nó phải là một vòng khép kín, nơi chương trình sẽ tròn, mãi mãi, không ngừng. Tuy nhiên, kiểm soát chương trình được truyền qua phải, và an toàn ở phía bên kia. Tôi mất hai tuần để tìm ra.

Máy tính RPC-4000 có thực sự là cơ sở hiện đại được gọi là chỉ mục đăng ký. Nó cho phép các lập trình viên để viết một vòng lặp chương trình sử dụng một hướng dẫn lập chỉ mục bên trong; mỗi lần thông qua, số trong chỉ mục đăng ký đã được thêm vào địa chỉ của hướng dẫn đó, vì vậy nó sẽ tham chiếu đến mốc tiếp theo trong một chuỗi. Anh ta chỉ có để tăng thanh ghi chỉ số mỗi lần. Mel không bao giờ sử dụng nó.

Thay vào đó, anh ta sẽ kéo chỉ dẫn vào sổ đăng ký máy, thêm một đến địa chỉ của nó và lưu trữ lại. Sau đó, ông sẽ thực hiện lệnh sửa đổi ngay từ sổ đăng ký. Vòng lặp đã được viết để thời gian thực hiện bổ sung này được thực hiện vào tài khoản - chỉ cần hướng dẫn này hoàn thành, bước tiếp theo là ngay dưới đầu đọc của trống, sẵn sàng để sử dụng. Nhưng vòng lặp không có kiểm tra trong đó.

Các đầu mối quan trọng đến khi tôi nhận thấy các bit đăng ký chỉ mục, các bit mà lay giữa địa chỉ và mã số hoạt động trong từ hướng dẫn, là quay on-- chưa Mel bao giờ sử dụng thanh ghi index, để nó không bằng tất cả thời gian. Khi ánh sáng chiếu vào nó gần như làm tôi bị mù.

Ông đã đặt các dữ liệu ông đã làm việc về gần phía trên cùng của bộ nhớ - địa điểm lớn nhất các hướng dẫn có thể giải quyết - vì vậy, sau khi cột mốc cuối cùng đã được xử lý, incrementing địa chỉ hướng dẫn sẽ làm cho nó tràn. Việc thực hiện sẽ thêm một đến mã hoạt động, thay đổi mã này thành mã tiếp theo trong tập lệnh: a hướng dẫn nhảy. Chắc chắn rằng, hướng dẫn chương trình tiếp theo là ở địa chỉ vị trí 0 và chương trình đã vui vẻ trên đường đi.

tôi đã không giữ liên lạc với Mel, vì vậy tôi không biết nếu ông đã từng đưa vào lũ của sự thay đổi đó đã rửa qua kỹ thuật lập trình từ những ngày dài biến mất. Tôi thích nghĩ rằng anh ta thì không. Trong mọi trường hợp, tôi đã rất ấn tượng với số đủ để tôi bỏ qua bài kiểm tra vi phạm , nói với Big Boss I không thể tìm thấy nó. Anh ta dường như không bị ngạc nhiên.

Khi tôi rời công ty, chương trình blackjack sẽ vẫn ăn gian nếu bạn bật công tắc cảm nhận đúng và Tôi nghĩ đó là cách thực hiện. Tôi không cảm thấy thoải mái khi hack mã của một Lập trình viên thực sự.

Answer 4

Nếu Apple đã sử dụng chương trình "Mozart", sẽ không có Mac OS X hoặc iTunes ngày hôm nay.

Nếu Google đã sử dụng chương trình "Mozart", sẽ không có Gmail hoặc Google Reader.

Nếu nhà phát triển SO áp dụng chương trình "Mozart", sẽ không có SO hôm nay.

Nếu Microsoft áp dụng chương trình "Mozart", sẽ không có Windows ngày hôm nay (tốt, tôi nghĩ điều đó sẽ tốt).

Vì vậy, câu trả lời đơn giản là KHÔNG. Không có gì là hoàn hảo, và không có gì là bao giờ có nghĩa là hoàn hảo, và bao gồm phần mềm.

Answer 5

Phong cách lập trình Mozart là một huyền thoại hoàn chỉnh (mọi người phải chỉnh sửa và sửa đổi những nỗ lực ban đầu của họ), và mặc dù "Mozart" về bản chất là một phép ẩn dụ trong ví dụ này, điều đáng chú ý là Mozart thực sự là một huyền thoại.

Mozart là một thần đồng thần tiên được coi là người sáng tác sonata đầu tiên của mình ở tuổi 4 (anh thực sự 6 tuổi, và nó đã hút - bạn sẽ không bao giờ nghe thấy nó được biểu diễn ở bất kỳ đâu). Nó hiếm khi được đề cập, tất nhiên, cha anh được coi là giáo viên âm nhạc vĩ đại nhất châu Âu, và anh buộc tất cả các con của mình phải luyện tập và sáng tác hàng giờ mỗi ngày ngay sau khi họ có thể cầm nhạc cụ hoặc bút. Bản thân Mozart đã cẩn thận để duy trì ảo tưởng rằng âm nhạc của anh nổi lên toàn bộ tâm trí anh bằng cách phá hủy hầu hết các bản nháp của anh, mặc dù đủ sống sót để cho thấy anh là một biên tập viên như mọi người khác. Beethoven chỉ trung thực hơn về quá trình này (có lẽ vì anh ta bị điếc và không thể biết liệu có ai đó lẻn vào anh ta không).

Tôi thậm chí sẽ không đề cập đến lý thuyết rằng Mozart có giai điệu của mình khi nghe những chú chim biết hót. Hoặc thực tế rằng ông đã tạo ra một hệ thống sử dụng xúc xắc để tạo nhạc ngẫu nhiên (điều này thực sự khá thú vị, nhưng cũng có thể giải thích số lượng nhạc của Mozart xuất hiện từ hư không).

Đạo đức của câu chuyện là: đừng tin vào quảng cáo. Lập trình là công việc, tiếp theo là nhiều công việc sửa chữa những sai lầm bạn đã thực hiện lần đầu tiên, tiếp theo là nhiều công việc sửa chữa những sai lầm bạn đã thực hiện lần thứ hai, vân vân cho đến khi bạn chết.

Answer 6

Tiến bộ trong máy tính là đáng để hy sinh trong vinh quang hay thiên tài ở đây và ở đó.

Answer 7

Tôi nghĩ rằng có thể xuất hiện để sử dụng chương trình Mozart. Tôi biết một công ty, Blizzard, không phát hành một sản phẩm phần mềm cho đến khi chúng tốt và sẵn sàng. Điều này không có nghĩa là Diablo 3 sẽ phát triển toàn bộ và hoàn thiện từ tâm trí của một ai đó trong một phiên mã hóa rực rỡ rực rỡ. Nó hiện có nghĩa là đó là cách nó sẽ xuất hiện cho phần còn lại của chúng tôi. Blizzard sẽ thử nghiệm trò chơi của họ trong nội bộ, không hiển thị nó cho phần còn lại của thế giới cho đến khi họ đã có tất cả các kinks làm việc ra ngoài. Hầu hết các công ty không sử dụng phương pháp này, thay vì phát hành phần mềm khi nó đủ tốt để giải quyết vấn đề, sau đó sửa lỗi và thêm các tính năng khi chúng xuất hiện. Cách tiếp cận này hoạt động (với các mức độ khác nhau) đối với hầu hết các công ty.

Answer 8

Edsger Dijkstra thảo luận về quan điểm của ông về chương trình Mozart và Beethoven trong video YouTube này có tiêu đề "Discipline in Thought".

dân trong chủ đề này đã thảo luận khá nhiều cách xem Dikstra của là không thực tế. Tôi sẽ cố gắng và bảo vệ anh ta một số.

• Dijkstra là chống lại các công ty cơ bản "thử nghiệm" phần mềm của họ về khách hàng của họ. Phát hành phiên bản 1.0 và sau đó ngay lập tức bản vá 1.1. Ông cảm thấy rằng chương trình nên được đánh bóng đến mức độ các bản vá lỗi "hotfix" là đường biên giới phi đạo đức.
• Ông đã làm không nghĩ rằng phần mềm nên được viết bằng một lần đổ hoặc những thay đổi đó sẽ không bao giờ cần phải thực hiện. Ông thường thảo luận về lý tưởng thiết kế của mình, một trong số đó là mô đun và dễ thay đổi. Ông thường nghĩ rằng các thuật toán cá nhân nên được viết theo cách này tuy nhiên, sau khi bạn đã hoàn toàn hiểu được vấn đề. Đó là một phần của kỷ luật của anh ta.
• Ông tìm thấy sau tất cả kinh nghiệm sâu rộng của mình với các lập trình viên, rằng các lập trình viên không hài lòng trừ khi họ đang đẩy giới hạn kiến ​​thức của họ. Ông nói rằng các lập trình viên không muốn lập trình một cái gì đó họ hoàn toàn và 100% hiểu vì không có thách thức trong đó. Các lập trình viên luôn muốn được trên bờ vực kiến ​​thức của họ. Trong khi ông hiểu tại sao các lập trình viên lại giống như vậy, ông tuyên bố rằng nó không đại diện cho lập trình dung sai lỗi thấp.

Có một số ngành hoặc ứng dụng lập trình mà tôi tin rằng "kỷ luật" của Dijkstra cũng được đảm bảo. NASA Rovers, thiết bị công nghiệp y tế nhúng (tức là phân phối thuốc, vv), một số phần mềm tài chính chuyển tiền của chúng tôi. Những khu vực này không có sự xa xỉ của sự thay đổi gia tăng sau khi phát hành và một "phương pháp tiếp cận Mozart" hơn là cần thiết.

Answer 9

Tôi nghĩ rằng câu chuyện Mozart nhầm lẫn những gì được vận chuyển so với cách nó được phát triển. Beethoven đã không thử nghiệm bản giao hưởng của mình trước công chúng. (Thật thú vị khi thấy anh ta thay đổi bất kỳ điểm số nào sau buổi biểu diễn công khai đầu tiên.)

Tôi cũng không nghĩ rằng Dijkstra đã nhấn mạnh rằng tất cả đều được thực hiện trong đầu của bạn. Sau khi tất cả, ông đã viết sách về lập trình xử lý kỷ luật liên quan đến việc làm trên giấy, và mức độ mà ông muốn xem kỷ luật toán học, bạn có nhận thấy bao nhiêu giấy và bảng phấn nhà toán học có thể tiêu thụ trong khi làm việc trên một vấn đề?

Tôi ủng hộ Simucal's response, nhưng tôi nghĩ rằng phép ẩn dụ Mozart-Beethoven sẽ bị loại bỏ. Đó là cái còi của Dijkstra khăng khăng về kỷ luật và sự hiểu biết vào một góc nơi mà nó thực sự không thuộc về.

Các chú thích bổ sung:

Việc phổ biến truyền hình không phải là quá nóng, và nó lẫn lộn một số điều về tác phẩm âm nhạc và những gì một nhà soạn nhạc đang làm và những gì một lập trình viên đang làm. Trong lời nói của Dijkstra, từ bài thuyết trình năm 1972 Turing: "Chúng ta không được quên rằng nó là không phải là kinh doanh của chúng tôi để tạo ra các chương trình; Một nhà soạn nhạc có thể ra ngoài để khám phá hành vi mong muốn.

Ngoài ra, trong quan điểm của Dijkstra rằng phiên bản 1.0 phải là phiên bản cuối cùng, chúng tôi cũng dễ dàng nhầm lẫn về cách thức hoạt động và chức năng mong muốn phát triển theo thời gian. Tôi tin rằng anh ta quá đơn giản khi nghĩ rằng tất cả các phiên bản trong tương lai là bởi vì phiên bản đầu tiên không được suy nghĩ và thực hiện một cách chặt chẽ và đáng tin cậy.

Thậm chí không có sự khẩn cấp về thị trường, tôi nghĩ giờ đây chúng tôi hiểu rõ hơn rằng các loại phần mềm quan trọng phát triển cùng với trải nghiệm người dùng với nó và mục đích tiện dụng mà họ có cho nó. Các ví dụ truy cập rõ ràng là các trò chơi (cũng xem xét cách phát triển hình ảnh chuyển động sân khấu). Bạn có nghĩ rằng Beethoven có thể viết Bản giao hưởng số 9 mà không có tất cả kinh nghiệm và thăm dò trước đó của mình không? Bạn có nghĩ rằng khán giả có thể đã nghe nó vì nó là gì không? Anh có nên đợi cho đến khi anh có Sonata hoàn hảo không? Tôi chắc rằng Dijkstra không đề xuất điều này, nhưng tôi nghĩ anh ta đã đi quá xa với Mozart-Beethoven để đưa ra quan điểm của mình.

Ngoài ra, hãy xem xét phần mềm chơi cờ. Các phiên bản mới không phải vì các phiên bản trước không phát chính xác. Đó là về khai thác những tiến bộ trong chẩn đoán chơi cờ và sức mạnh máy tính có sẵn. Đối với điều này và nhiều tình huống khác, ý tưởng rằng phiên bản 1.0 là phiên bản cuối cùng là tắt cơ sở. Tôi hiểu rằng anh ta đang phản đối đúng đắn việc phát hành phần mềm không đáng tin cậy và có thể bị suy giảm với các thiếu sót được tạo ra trong các bản phát hành bảo trì và trong tương lai. Nhưng lập luận phản đối của Mozart không giữ lấy tôi.

Vì vậy, Dijkstra có tiếp tục lái chiếc ô tô đầu tiên anh mua hoặc bản sao chính xác của ô tô đó không? Có lẽ đã có kế hoạch lỗi thời, nhưng rất nhiều việc phải làm với những cải tiến và độ tin cậy mà không thể có sẵn hoặc thậm chí được xem xét trong các thế hệ công nghệ ô tô trước đây.

Tôi là một người hâm mộ Dijkstra lớn, nhưng tôi nghĩ rằng điều Mozart-Beethoven là quá đơn giản cũng như không phù hợp. Tôi cũng là một fan lớn của Beethoven.

Answer 10

Tôi nghĩ ý tưởng là lên kế hoạch trước. Bạn cần ít nhất có một số loại phác thảo của những gì bạn đang cố gắng làm và làm thế nào bạn có kế hoạch để đạt được điều đó. Nếu bạn chỉ cần ngồi xuống bàn phím và hy vọng "the luse" sẽ dẫn bạn đến nơi mà chương trình của bạn cần phải đi, kết quả có thể là khá không đồng đều, và nó sẽ đưa bạn lâu hơn nữa để đến đó.

Điều này đúng với bất kỳ loại văn bản nào. Rất ít tác giả chỉ ngồi xuống máy đánh chữ không có ý tưởng và bắt đầu đập cho đến khi một cuốn tiểu thuyết bán chạy nhất được sản xuất. Heck, cha chồng của tôi (một giáo viên tiếng Anh trung học) thực sự viết phác thảo cho các chữ cái của mình.