Một ẩn dụ lập trình tốt là gì? [đóng cửa]

Tôi đang đề cập đến việc giải thích cho người không lập trình là lập trình là gì. Tôi chắc chắn đã tìm kiếm các câu hỏi tương tự trước khi tạo câu hỏi này, nhưng một vài câu hỏi mà tôi tìm thấy dường như né tránh câu hỏi, và tôi đặc biệt muốn thấy một số phép ẩn dụ hoặc tương tự. Cá nhân tôi thấy dễ dàng hơn để giải thích một cái gì đó kỹ thuật cho ai đó thông qua việc sử dụng các phép ẩn dụ hoặc các phép loại suy.

Lý do tôi quan tâm đến điều này là vì nhiều người gặp phải công việc của một lập trình viên hàng ngày, nhưng nếu bạn hỏi người bình thường rằng lập trình viên là gì hoặc làm gì, họ thực sự không biết. Điều này dẫn đến một số tình huống hiểu lầm (ví dụ: "[...] nhưng tôi nghĩ bạn tốt với máy tính!")

Tôi thực sự muốn tìm một cái tốt nhất ngoài đó. Tôi muốn có thể dễ dàng giải thích cho ai đó về sự lựa chọn nghề nghiệp của tôi. Tất nhiên, ít nhất là ý tưởng chung.

Cá nhân tôi không có một ngôn ngữ vững chắc, nhưng tôi đã suy nghĩ rất lâu về nó và tôi thường bị cuốn hút vào phép ẩn dụ 'ngôn ngữ', nơi chúng tôi tình cờ biết một ngôn ngữ mà máy tính hiểu, và do đó chúng tôi có thể nói cho máy tính biết làm, hoặc "dạy" chúng, để giải quyết vấn đề của chúng ta.

Ví dụ:

Hãy tưởng tượng rằng trong một thực tế xen kẽ, robot hình người có trí thông minh nhân tạo tồn tại và một số người có thể giao tiếp với họ thông qua một ngôn ngữ chung, đó là một biến thể của tiếng Anh. Những người có thể giao tiếp với robot có thể dạy họ cách giải quyết một số vấn đề nhất định hoặc thực hiện một số nhiệm vụ nhất định, như làm việc vặt của chúng tôi.

Chà, mặc dù những robot như thế vẫn chưa tồn tại, các lập trình viên của thời đại chúng ta cũng giống như những người đó, nhưng thay vì giao tiếp với robot, họ giao tiếp với máy tính. Các lập trình viên "dạy" máy tính cách thực hiện một số tác vụ nhất định hoặc giải quyết một số vấn đề nhất định bằng phần mềm mà họ tạo ra bằng cách sử dụng "ngôn ngữ chung" này.

Các lập trình viên và "ngôn ngữ chung" này là những gì mang lại cho chúng ta những thứ như email, trang web, trò chơi video, trình xử lý văn bản, điện thoại thông minh ( nói một cách đơn giản ) và nhiều thứ khác mà chúng ta sử dụng hàng ngày.

Tôi không có ý định đưa lập trình lên ngai vàng hay bất cứ điều gì, đó chỉ là phép ẩn dụ tốt nhất tôi có thể nghĩ ra.

Tôi chắc chắn rằng ai đó sẽ tìm thấy một số vấn đề với vấn đề này, nó có thể là một chút giả định, nhưng một lần nữa đó là lý do tại sao tôi hỏi câu hỏi này.

Nó giống như phải viết chi tiết từng bước hướng dẫn cách lái xe đi đâu đó. Nhưng bạn thường phải thêm các kế hoạch dự phòng cho những thứ như 'nếu xảy ra kẹt xe' hoặc 'nếu xe tải bị hỏng ở làn đường rẽ'.

Và đôi khi bạn phải lặn sâu hơn nữa và giải thích các quy tắc của con đường như lái xe về phía nào hoặc làm gì khi vượt đèn đỏ. Và đôi khi bạn thậm chí cần phải giải thích chính xác cách tay lái hoặc bàn đạp ga hoạt động.

Và thông thường, một khi bạn đã có tất cả các mô tả chi tiết chính xác, khách hàng nói rằng "điều đó thật hoàn hảo, ngoại trừ việc nó cần phải làm việc cho ai đó lái tàu lượn"

Tôi viết hướng dẫn rất, rất chi tiết cho một chiếc máy rất, rất ngu ngốc.

Tôi sử dụng phép ẩn dụ "Chúng tôi viết công thức đan " thân thiện với bà ngoại.

Cơ sở lý luận:

• Đan là một quá trình cơ học khá đơn giản, về cơ bản bạn cần phải làm theo các hướng dẫn chi tiết chính xác để có được bất cứ điều gì từ nó.
• Hầu hết các hướng dẫn đan là cho nhiều kích cỡ. Điều này cung cấp cho bạn if-statements và toán học và vòng lặp.
• Bạn có thể tìm thấy lỗi trong công thức khi đội quân của những người bà giận dữ đi kèm với áo len lỗi của họ!

Tương tự không tốt lắm nhưng khi mọi người bảo tôi sửa máy thì tôi nói "Tôi là người thiết kế những chiếc xe. Tôi không phải là thợ cơ khí!"

Khi còn bé, tôi đã đọc một mô tả thực sự tốt về lập trình: nó giống như nói cho robot biết cách thực hiện một công việc hàng ngày, phổ biến, như đi học. Vì vậy, bạn có thể nói với nó là "Đi học!", Nhưng nó không biết làm thế nào. Vì vậy, bạn bảo nó "đi ra ngoài, rẽ trái, tiếp tục đi bộ cho đến khi bạn đến trường, rẽ trái, đi vào và ngồi xuống". Nhưng có một con đường trên đường! Vì vậy, bạn phải bảo nó "dừng lại ở đường, kiểm tra xem không có xe cộ, băng qua đường và tiếp tục đi bộ" ở đâu đó ở giữa đó. Còn cửa ra vào thì sao? Vì vậy, bạn thêm "kiểm tra xem cửa trường có mở không. Nếu không, hãy mở nó." trong đó. Cuối cùng, bạn có một chương trình có thể cho robot của bạn biết cách tự đến trường.

Điều này phù hợp rất gọn gàng với Logo, nơi bạn hướng dẫn rùa chính xác theo cách này để tạo ra các hình dạng phức tạp.

Lập trình giống như một hộp sôcôla . Đôi khi bạn tìm thấy những gì bạn đang tìm kiếm ngay lập tức, nhưng hầu hết thời gian cần rất nhiều thử nghiệm và sai sót. Đôi khi bạn nhận được dừa.

Đèn giao thông . Ô tô đang di chuyển hoặc dừng lại. Một đèn giao thông rất dễ hình dung khi thiết lập, nhưng điều gì xảy ra nếu bạn thêm một đèn khác? Làm thế nào về một phần ba? Thế còn cả một thành phố? Một hệ thống giao thông được tạo thành từ hàng ngàn đèn dừng, mỗi đèn đơn giản, nhưng khi được chụp toàn bộ, nó trở thành một hệ thống phức tạp. Nếu một trong những đèn giao thông đó gặp trục trặc hoặc tắt chỉ sau vài giây, nó sẽ khiến cả hệ thống rơi vào hỗn loạn. Nếu mọi thứ đều đồng bộ, bạn chỉ cần tận hưởng chuyến đi.

Một diễn giả động lực tìm thấy chìa khóa để mở khóa câu đố về động lực, ước mơ và ý tưởng của mọi người. Mỗi hoàn cảnh, mỗi người là khác nhau. Những gì làm việc trong quá khứ có thể không thích hợp bây giờ. Đôi khi một khóa có thể được sử dụng lại, nhưng cần phải được điều chỉnh cho phù hợp với từng cá nhân. Những lần khác, chìa khóa phải được thời trang một lần nữa. Điều đáng khen nhất là khi người đó đã được mở khóa và bạn thấy họ ra ngoài và chinh phục thế giới. Điều tàn phá nhất là khi bạn cảm thấy gần gũi, nhưng không thể mở khóa tiềm năng.

Một câu chuyện trinh thám , nơi thám tử từ từ xây dựng vụ án của mình bằng cách tìm kiếm manh mối và thu thập chứng cứ. Phương pháp, thông minh, và chính xác sẽ giành chiến thắng trong ngày. Cẩu thả, thiếu hiểu biết và lười biếng sẽ làm chết trường hợp. Cuối cùng, công việc sẽ đứng hoặc sụp đổ trước một ban giám khảo của các đồng nghiệp.

Một máy đánh bạc . Bạn đặt tất cả các đồng tiền của bạn vào và kéo đòn bẩy. Đôi khi bạn thắng lớn, đôi khi bạn ngồi đó hàng giờ và không có gì xảy ra. Đôi khi một người khác chỉ tình cờ đi ngang qua, kéo cần gạt một lần và trúng giải độc đắc.

Âm nhạc . Một lưu ý là đủ đơn giản, nhưng một biện pháp phức tạp hơn. Một bài hát hoàn chỉnh có nhiều biện pháp với nhiều ghi chú. Nếu một ghi chú bị tắt, nó có thể làm hỏng toàn bộ hiệu suất. Nếu mọi ghi chú được phân phối hoàn hảo, hiệu suất sẽ mờ dần trong nền và chỉ có âm nhạc tồn tại.

Ẩn dụ tốt nhất cho bất cứ điều gì là chính nó. Bất cứ điều gì khác nhau sẽ mất một số độ chính xác. Như vậy, chọn phép ẩn dụ tốt nhất phụ thuộc vào những gì, cụ thể, bạn muốn nắm bắt về lập trình. Vì sẽ có rất nhiều câu trả lời được đưa ra ở đây về ẩn dụ mã hóa, tôi sẽ trả lời bằng phép ẩn dụ cổ điển cho toàn bộ quá trình phát triển:

Xây dựng công trình

Khía cạnh phổ biến nhất của phép ẩn dụ này là một kiến ​​trúc sư vật lý có phần giống với kiến ​​trúc sư phần mềm. Dưới đây là một vài điểm tương đồng khác:

• Thay đổi là rẻ hơn và rẻ hơn bạn thực hiện chúng sớm hơn. Đó là, bạn có thể di chuyển một dòng trên giấy bây giờ hoặc 10 tấn xi măng sau đó.
• Một tòa nhà không có kế hoạch phù hợp sẽ có xu hướng sụp đổ
• Các nhà xây dựng cố gắng thực hiện những gì khách hàng muốn. Nếu khách hàng không mô tả chính xác những gì họ muốn tòa nhà trông như thế nào (hoặc có một số thất bại khác trong giao tiếp), sẽ rất tốn kém khi thay đổi.
• Có một số định luật vật lý không thể uốn cong. Giống như câu chuyện thứ 2 rộng ba trăm feet không thể được xây dựng trên câu chuyện thứ 1 rộng 100 feet, tính năng X không thể được xây dựng mà không có hệ thống con Y mạnh mẽ.

Tất nhiên, giống như bất kỳ phép ẩn dụ nào, nó cũng có những hạn chế. Một số sai sót với nó:

• Các tòa nhà được sử dụng 1 lần; bạn xây dựng nó ở đâu đó, và nó ở lại. Bạn không thể sao chép nó một triệu lần cho một triệu người dùng khác nhau với một triệu nhu cầu khác nhau với chi phí gia tăng bằng không.
• Các tòa nhà là bất biến hơn đáng kể so với phần mềm.
• Không có sự tương đồng rõ ràng với chi phí vật liệu xây dựng. Một dòng mã không tốn kém gì - chỉ mất thời gian để sản xuất ra nó phải trả tiền.
• Kiến trúc gia tăng (tùy thuộc vào người bạn yêu cầu) có thể với phần mềm là không thể với xây dựng, nơi bạn thiết kế nó một lần, sau đó xây dựng nó.

Vì vậy, giống như bất kỳ sự tương tự, nó phụ thuộc vào những gì bạn đang cố gắng giải thích. Hãy cảnh giác vì quá phụ thuộc vào bất kỳ một phép ẩn dụ nào, hoặc khách hàng của bạn sẽ bắt đầu tự hỏi thuế tài sản trên hệ thống bảng lương mới của anh ta sẽ là gì.

Tôi yêu sự tương tự về phát triển phần mềm của Chris McMahon giống như việc tạo ra âm nhạc, đặc biệt là nhạc jazz.

Đây là Ella Fitzgerald và Bá tước Basie đang thực hiện bài hát One O'Clock Jump. Bài hát là một bản blues mười hai thanh, tương đương với nhạc jazz của một ứng dụng cơ sở dữ liệu với giao diện người dùng. Ý tôi là: giống như mọi lập trình viên đã xây dựng một ứng dụng cơ sở dữ liệu với giao diện người dùng, mọi nhạc sĩ người Mỹ đã chơi các bản nhạc mười hai thanh. Đó là một khuôn khổ mà nhiều bài hát được treo, từ Count Basie đến Jimi Hendrix đến Ramones.

Video đặc biệt này là một ví dụ tuyệt vời về thực hành nhanh nhẹn. Nghe cách giọng nói và piano ảnh hưởng lẫn nhau. Điều này rất giống với lập trình cặp, và nó rất giống TDD: giọng nói làm gì đó; piano đáp lại; piano làm một cái gì đó; giọng nói đáp lại. Và chú ý giao tiếp bằng mắt. Những người này nhận thức sâu sắc về những gì đang diễn ra ngay lập tức. Họ không có bản nhạc (BDUF). Họ tham gia vào một hoạt động đòi hỏi sự tập trung và kỹ năng mạnh mẽ, giống như phát triển phần mềm tốt. Họ cũng nhận thức rõ ràng rằng có một đối tượng, giống như phát triển phần mềm tốt nên nhận thức được nhu cầu của những người trả hóa đơn.

Đây là liên kết đến bài đăng trên blog mà anh ấy thảo luận về nó: http://chrismcmahonsblog.blogspot.com/2007/05/example-of-analogy-monks-vs-music.html

Đôi khi tôi đề cập đến lập trình như để kiểm soát những thây ma vô tri . Tóm tắt bài viết trên blog của tôi về nó:

• Giống như thây ma, máy tính chúng tôi hoạt động rất ngu ngốc. Thật khó để hướng dẫn họ làm bất cứ điều gì trừ khi các hướng dẫn được chi tiết
• Thây ma rất hung dữ và nếu chúng ta bỏ lỡ những chi tiết nhỏ trong chỉ dẫn, hãy để sinh vật không bị cản trở, nó có thể nghiền nát mọi thứ xung quanh mình. Điều tương tự với máy tính: việc thiếu một chi tiết trong hướng dẫn có thể khiến chương trình của bạn bị sập và phá hủy dữ liệu của bạn.
• Bạn phải biết phép thuật nếu bạn muốn điều khiển một thây ma. Tương tự với lập trình.
• Càng nhiều người có bộ não tập trung tại một nơi, họ càng có nhiều máy tính. Có vẻ như bộ não thu hút máy tính - giống như cách chúng thu hút zombie.

Lập trình giống như xây dựng mọi thứ với Lego :

• Bạn đang gắn nhiều bit nhỏ lại với nhau để tạo ra những thứ lớn hơn
• Các bit nhỏ có số lượng hình dạng và kích thước giới hạn
• Những điều nhỏ nhặt chỉ có thể phù hợp với nhau theo những cách nhất định
• Chơi với những thứ này có thể rất nhiều niềm vui

Lập trình máy tính giống như nuôi một đứa trẻ ...

• Mọi người đều không đồng ý về cách làm đúng
• Nó giúp bạn thức dậy vào ban đêm
• Nó không bao giờ làm những gì bạn nói với nó
• Cho dù bạn có đọc bao nhiêu cuốn sách về chủ đề này, khi bạn thực hiện nó, bạn cảm thấy như bạn không biết mình đang làm gì
• Sau một thời gian bạn có xu hướng lười biếng
• Bạn hy vọng nó sẽ có lợi nhuận lớn trong tương lai nhưng cuối cùng bạn phải duy trì nó cho đến cuối đời
• Nó không bao giờ hoàn toàn sạch sẽ, thông minh hoặc an toàn như bạn muốn
• Khi bạn nhìn lại nó sau, bạn tự hỏi bạn đang nghĩ cái quái gì vậy
• Bất chấp mọi căng thẳng nó gây ra cho bạn, dù sao bạn cũng thích nó.

Sự khác biệt chính là chúng tôi cảm thấy khó chịu nếu ai đó đánh cắp mã nguồn của chúng tôi, nhưng chúng tôi thường rất vui khi có ai đó đưa con mình ra khỏi tay chúng tôi.

Lập trình giống như xây dựng một nhà máy hoặc một dây chuyền lắp ráp.

Hãy nghĩ về phần mềm như một máy hoặc dây chuyền lắp ráp tồn tại bên trong máy tính. Một số nguyên liệu thô và các thành phần được đưa vào máy, và nó tuân theo một bộ quy trình để xử lý chúng thành một số sản phẩm cuối cùng. Các quy trình được thiết lập để thực hiện một thao tác cụ thể trên một số nguyên liệu thô hoặc thành phần cho một bộ thông số cụ thể (ví dụ: thời gian, nhiệt độ, khoảng cách, v.v.) theo một thứ tự cụ thể. Nếu chi tiết của thao tác được thực hiện không chính xác hoặc cảm biến của máy không được hiệu chuẩn chính xác hoặc nếu một số nguyên liệu thô hoặc thành phần không nằm trong tiêu chuẩn chất lượng dự kiến, nó có thể thay đổi kết quả của hoạt động và sản phẩm sẽ không thành công như mong đợi.

Một máy như vậy là rất cứng nhắc trong hoạt động của nó và đầu vào chấp nhận được. Máy móc không đặt câu hỏi về trí thông minh của nhà thiết kế cũng như môi trường hoạt động hiện tại của nó. Nó sẽ tiếp tục làm theo các thủ tục miễn là nó được hướng dẫn. Ngay cả khi một sự thay đổi trong nguyên liệu thô hoặc các thành phần có thể có tác động mạnh mẽ đến những gì xảy ra trong các hoạt động sau này, máy vẫn sẽ thực hiện các quy trình của mình. Quá trình sẽ cần được xem xét để xem những thay đổi nào đối với các thủ tục là cần thiết để bù đắp và tạo ra kết quả mong muốn. Thay đổi về thiết kế hoặc cấu hình của sản phẩm cũng có thể yêu cầu thay đổi đáng kể đối với các hoạt động được thực hiện hoặc đơn đặt hàng của chúng. Mặc dù những người phụ trách sản xuất đã nhanh chóng học được tầm quan trọng của việc cô lập các hoạt động càng nhiều càng tốt để giảm các tác động không mong muốn giữa chúng, rất nhiều giả định được tạo ra từ các thành phần điều kiện khi chúng trải qua quá trình xử lý; các giả định có thể không được phát hiện cho đến khi sản phẩm cuối cùng nằm trong tay người dùng trong một số môi trường hoạt động khác nhau.

Giúp một thằng ngốc nhanh chóng vượt qua một lớp toán đòi hỏi một bài luận viết.

Lập trình máy tính giống như chơi một ván cờ trong đó kích thước của bàn cờ, số lượng quân cờ và quy tắc chi phối các quân cờ đó tăng kích thước và độ phức tạp khi trò chơi tiếp diễn.

Phần mềm viết giống như ... Viết! ^^

Các sinh viên mới tham gia các lớp CS / Lập trình, thực tế, giống như người dùng không lập trình. Ví dụ về robot là tốt.

Quay lại, vào những năm 80, sử dụng Logo, Karel, (hoặc môi trường lập trình tương tự), nơi người dùng học lập trình, xem máy tính như robot, thay vào đó, một chiếc TV có máy đánh chữ, đã giúp ích rất nhiều. Những công cụ thường được sử dụng trong trường trung học cơ sở và trung học phổ thông.

Chương trình thực tế đó đã giúp các sinh viên tìm hiểu các kỹ năng giải quyết vấn đề, ngay cả khi họ không liên quan đến máy tính !!!

Hoặc, ngay cả khi các sinh viên không trở thành lập trình viên.

Một số trường đại học và đại học cũng áp dụng những công cụ đó trong các khóa học năm đầu tiên.

Tôi tự hỏi tại sao nhiều trường trung học bỏ giảng dạy Logo và Karel ...

Tôi thích sự tương tự của Fred Brooks, từ Tháng huyền thoại, rằng lập trình giống như thực hiện phép thuật.

(Chương trình) xây dựng, không giống như lời của nhà thơ, là có thật theo nghĩa là nó di chuyển và hoạt động, tạo ra đầu ra có thể nhìn thấy tách rời khỏi chính cấu trúc đó. Nó in kết quả, vẽ hình ảnh, tạo ra âm thanh, di chuyển cánh tay. Sự kỳ diệu của huyền thoại và truyền thuyết đã trở thành sự thật trong thời đại của chúng ta. Một loại câu thần chú chính xác trên bàn phím và màn hình hiển thị trở nên sống động, hiển thị những thứ chưa từng có. ...

(Một) phải thực hiện chính xác. Máy tính cũng giống như phép thuật của huyền thoại và truyền thuyết về mặt này. Nếu một nhân vật, một lần tạm dừng câu thần chú không hoàn toàn ở dạng thích hợp, phép thuật không hoạt động. Con người không quen với việc hoàn hảo, và một vài lĩnh vực hoạt động của con người đòi hỏi điều đó. Điều chỉnh theo yêu cầu cho sự hoàn hảo là, tôi nghĩ, phần khó nhất khi học lập trình.

"[...] nhưng tôi nghĩ bạn tốt với máy tính!"

Đây thường là một nỗ lực để lừa một người đam mê sửa máy tính (bạn có cảm thấy thôi thúc phải chứng minh họ sai không?). Câu trả lời chuẩn của tôi:
Tôi là một lập trình viên. Điều đó giống như một kỹ sư ô tô - anh ta có lẽ sẽ không biết cách sửa phanh của bạn '72 Trabant, và chắc chắn sẽ không làm điều đó nếu anh ta biết. Một thợ máy sẽ làm điều đó!

Tôi thích khái niệm về một công thức nấu ăn.

Lập trình giống như mang theo một lượng lớn sức mạnh. Bạn có thể làm cho máy tính làm bất cứ điều gì bạn muốn. Bạn chỉ bị giới hạn bởi trí tưởng tượng của mình và lượng thời gian bạn sẵn sàng đầu tư.

Các lập trình viên giống như những người tạo ra một ngôi nhà. Chúng tôi có thể cho bạn biết tất cả mọi thứ về những ngôi nhà chúng tôi đã làm. Tuy nhiên, nếu bạn hỏi chúng tôi hỏi một ngôi nhà ngẫu nhiên mà chúng tôi tình cờ đi trên đường, rất có thể chúng tôi sẽ không biết nhiều về nó. Nhưng nếu bạn cần một cái gì đó được thêm vào hoặc thay đổi trên ngôi nhà đó, chúng tôi có thể làm cho nó xảy ra với điều kiện chủ sở hữu cho phép chúng tôi.

Trong một trong những bài viết cũ của Chris Crawford về lập trình , ông đã ví một chương trình phức tạp với bộ máy quan liêu, với nhiều cơ quan giao tiếp bằng cách chuyển các bản ghi nhớ qua lại. Tôi đã thấy rằng đó là một phép ẩn dụ rất hữu ích khi giải thích sự phát triển phần mềm.

Tôi thường đánh đồng lập trình với một trò chơi ghép hình.

Để tạo một dự án mới - bạn có vô số mảnh ghép, một vài trong số đó không thuộc về hình ảnh này và bạn không có bản xem trước về câu đố trông như thế nào khi nó được thực hiện. Nhưng bạn có biết kích thước và màu sắc chung, vì vậy ước tính là có thể, nhưng không nhất thiết phải chính xác.

Để sửa đổi một dự án đã tồn tại - một con mèo đã đến và đánh bật một đoạn của câu đố đã hoàn thành. Sẽ mất một chút thời gian, nhưng khung đã có sẵn, vì vậy nó không quá tệ (tùy thuộc vào mức độ cần thay đổi).

Nó cũng giúp cho việc mô tả tiến trình. Một trong những dự án gần đây của tôi, có lúc tôi đã tự hỏi làm thế nào để mô tả nó để một người không có kỹ thuật sẽ hiểu tại sao tôi không biết bao lâu nữa, và tôi đã nghĩ ra: Hãy nghĩ về một trò chơi ghép hình trong đó có tất cả các mảnh viền được thực hiện, như là hơn một nửa nếu các mảnh bên trong. Những cái còn lại hoàn toàn tách biệt với nhau, điều tôi phải làm bây giờ là lấp đầy những khoảng trống.

Thật đáng buồn, nhưng lập trình là một công việc chỉ có thể được hiểu bằng cách học cách làm nó.

Lập trình có một số mức độ nhận thức khác nhau và khác nhau từ các khía cạnh khác nhau.

Ở cấp độ thấp, đó là "viết hướng dẫn rất, rất chi tiết cho một cỗ máy rất, rất ngu ngốc"

Ở cấp độ tiếp theo, nó là đối phó với sự phức tạp. Xây dựng phép ẩn dụ mới để đơn giản hóa công việc. Giống như toán học cao hơn.

Từ các khía cạnh khác nhau, việc sử dụng các công nghệ phụ trợ như kiểm soát phiên bản, mã tự ghi, xây dựng dự án và thử nghiệm.

Từ phía bên kia giao diện "người dùng" xây dựng của nó (không phải theo nghĩa đen, ý tôi là API cũng là UI), dự đoán các lỗi có thể xảy ra (do người dùng, dữ liệu hoặc thậm chí chính nó thực hiện) và phản ứng đúng với các lỗi.

Và cuối cùng.

Ẩn dụ cho lập trình là văn học. Trước tiên cần học bảng chữ cái. Nhưng viết một cuốn tiểu thuyết này thậm chí không bắt đầu.