Tôi đã làm việc như một nhà phát triển ứng dụng được một năm rưỡi rồi (tôi không biết lâu) và tôi vừa được nhận dự án lớn đầu tiên của mình.

Không cần phải nói nó đã không diễn ra suôn sẻ, vì vậy tôi đã tìm kiếm lời khuyên từ một lập trình viên cao cấp có liên quan đến dự án về cách tiếp cận nó.

Anh ấy nói rằng tôi đã hết sức suy nghĩ về nhiệm vụ trong tay, và bởi vì tôi chưa bao giờ giải quyết một dự án có quy mô này trước khi tôi dành quá nhiều thời gian cho việc suy nghĩ các mẫu thiết kế. Nói một cách khôn ngoan, anh ấy nói với tôi "F * ck tương lai, xây dựng ngay bây giờ".

Đây có phải là một lập trình viên xu hướng thường làm theo khi đi về một dự án như thế này? Ví dụ, nếu bạn được yêu cầu làm một bằng chứng về mô hình khái niệm, thì đó có phải là một xu hướng điển hình chỉ để nghiền một ví dụ khả thi càng sớm càng tốt?

Chỉnh sửa: Trước cuộc tranh luận này đã nổ ra, tôi muốn đề cập rằng tình huống này khá cực đoan: chúng tôi có thời hạn rất chặt chẽ do các yếu tố ngoài tầm kiểm soát của chúng tôi (ví dụ như thị trường mà chúng tôi đang nhắm sẽ mất hứng thú nếu chúng tôi không 'cho họ xem một cái gì đó) và lời khuyên của anh ấy đã chứng minh là rất hiệu quả cho nhiệm vụ đặc biệt này.

Đội trưởng Rõ ràng để giải cứu!

Tôi sẽ là Đội trưởng Rõ ràng ở đây và nói rằng có một số nền tảng được tìm thấy.

Bạn muốn xây dựng cho tương lai và tránh tự nhốt mình vào một lựa chọn công nghệ hoặc một thiết kế tồi. Nhưng bạn không muốn mất 3 tháng để thiết kế một thứ gì đó đơn giản hoặc thêm điểm mở rộng cho một ứng dụng nhanh và bẩn sẽ có tuổi thọ 2 năm và không có khả năng có các dự án tiếp theo.

Thật khó để tìm ra sự khác biệt, bởi vì bạn không thể luôn dự đoán được sự thành công của sản phẩm và nếu bạn cần gia hạn sau này.

Xây dựng ngay bây giờ nếu ...

• dự án sẽ bị loại bỏ
• dự án có vòng đời ngắn
• dự án không nên có phần mở rộng
• dự án không có giá trị tác động rủi ro (chủ yếu là về hình ảnh)

Nói chung, các dự án nội bộ hoặc một cái gì đó được xây dựng cho khách hàng nên được phát triển ngay bây giờ. Hãy chắc chắn có các yêu cầu thẳng, và liên quan đến chúng khi cần thiết để biết những gì cần thiết và những gì không. Đừng muốn dành quá nhiều thời gian cho bất cứ điều gì "tốt đẹp để có." Nhưng đừng mã như một con lợn.

Để lại vấn đề chung cho sau này, nếu nó có thể là cần thiết và đáng để nỗ lực:

Xây dựng cho tương lai nếu ...

• dự án sẽ được công khai
• dự án là một thành phần được tái sử dụng
• dự án là bước đệm cho các dự án khác
• dự án sẽ có các dự án tiếp theo hoặc phát hành dịch vụ với những cải tiến

Nếu bạn đang xây dựng cho một cái gì đó công khai, hoặc sẽ được sử dụng lại trong các dự án khác, thì bạn có xác suất cao hơn nhiều rằng một thiết kế xấu sẽ quay trở lại ám ảnh bạn, vì vậy bạn nên chú ý đến điều đó hơn. Nhưng nó không phải lúc nào cũng được đảm bảo.

Hướng dẫn

Tôi muốn nói rằng tuân thủ các nguyên tắc sau tốt nhất có thể, và bạn nên đặt mình vào vị trí thiết kế các sản phẩm hiệu quả, có thể thích ứng:

• biết rằng YAGNI ,
• HÔN ,
• Bất cứ khi nào bạn cảm thấy muốn gãi ngứa và nghĩ đến một sự bổ sung, hãy viết nó ra. Nhìn lại các yêu cầu dự án của bạn và tự hỏi nếu bổ sung là ưu tiên hay không. Hỏi xem họ có thêm giá trị kinh doanh chính hay không.

Tôi biết rằng cá nhân tôi có xu hướng lật đổ và lật đổ. Nó thực sự giúp viết ý tưởng xuống và rất thường xuyên suy nghĩ lại nếu tôi cần các tính năng bổ sung. Thông thường, câu trả lời là không, hoặc, "nó sẽ rất tuyệt sau này." Những ý tưởng cuối cùng đó rất nguy hiểm, vì chúng ở sau đầu tôi và tôi cần buộc bản thân mình không lên kế hoạch cho chúng.

Cách tốt nhất để viết mã mà không gây áp lực và không chặn chính bạn sau này là tập trung vào một thiết kế tối thiểu tốt. Phá vỡ mọi thứ độc đáo như các thành phần mà sau này bạn có thể mở rộng, nhưng không cần suy nghĩ về cách chúng có thể được mở rộng sau này. Bạn không thể dự đoán tương lai.

Chỉ cần xây dựng những điều đơn giản.

Tiến thoái lưỡng nan

Áp đảo

Đây có phải là một lập trình viên xu hướng thường làm theo khi đi về một dự án như thế này?

Chết tiệt Đó là một vấn đề nan giải đã biết và nó chỉ cho thấy rằng bạn quan tâm đến sản phẩm. Nếu bạn không, điều đó đáng lo ngại hơn. Có sự bất đồng về việc có hay không luôn luôn thực sự nhiều hơn và nếu tệ hơn thì luôn thực sự tốt hơn . Bạn có thể là một chàng trai MIT hoặc New Jersey . Không có câu trả lời dễ dàng ở đây.

Tạo mẫu / Quick-n-Dirty / Ít hơn

Đây có phải là một xu hướng điển hình chỉ để nghiền một ví dụ khả thi càng sớm càng tốt?

Đó là một thực tế phổ biến, nhưng đó không phải là cách mà phần lớn các dự án được tiếp cận. Tuy nhiên, theo nguyên mẫu là một xu hướng tốt trong quan điểm của tôi, nhưng một trong những nhược điểm có ý nghĩa. Có thể khuyến khích quảng bá các nguyên mẫu nhanh và bẩn cho các sản phẩm thực tế hoặc sử dụng chúng làm cơ sở cho các sản phẩm thực tế dưới áp lực quản lý hoặc hạn chế về thời gian. Đó là khi nguyên mẫu có thể trở lại ám ảnh bạn.

Có những lợi thế rõ ràng cho việc tạo mẫu , nhưng cũng có rất nhiều khả năng lạm dụng và lạm dụng (nhiều nghịch đảo chính xác của các lợi thế được liệt kê trước đây là kết quả).

Khi nào nên sử dụng Prototyping?

Có những gợi ý về các loại dự án tốt nhất để sử dụng nguyên mẫu :

[...] Tạo mẫu có lợi nhất trong các hệ thống sẽ có nhiều tương tác với người dùng.

[...] Tạo mẫu rất hiệu quả trong việc phân tích và thiết kế các hệ thống trực tuyến, đặc biệt là để xử lý giao dịch, trong đó việc sử dụng các hộp thoại màn hình có nhiều bằng chứng hơn. Sự tương tác giữa máy tính và người dùng càng lớn, lợi ích [...] càng lớn.

"Một trong những cách sử dụng hiệu quả nhất của tạo mẫu nhanh cho đến nay là một công cụ cho các yêu cầu lặp lại của người dùng về kỹ thuật và thiết kế giao diện người-máy tính."

Mặt khác:

Các hệ thống có ít tương tác người dùng, chẳng hạn như xử lý hàng loạt hoặc các hệ thống chủ yếu thực hiện tính toán, được hưởng lợi rất ít từ việc tạo mẫu. Đôi khi, mã hóa cần thiết để thực hiện các chức năng hệ thống có thể quá chuyên sâu và lợi ích tiềm năng mà việc tạo mẫu có thể cung cấp là quá nhỏ.

Và nếu bạn có một con quái vật màu xanh lá cây xung quanh, chỉ cần đảm bảo giữ nguyên mẫu trong ngân sách ...

Khi bạn bắt đầu lập trình, mọi thứ là một bằng chứng về khái niệm ngay cả khi nó chỉ là cho chính bạn. Có những trường hợp khi một ý tưởng đòi hỏi một cái gì đó nhanh chóng và bẩn thỉu hoặc một nguyên mẫu bởi vì thời gian là yếu tố chính. Nỗi sợ hãi lớn giữa các nhà phát triển là các bên liên quan nghĩ rằng ứng dụng nhỏ đã sẵn sàng để sản xuất hoặc bạn sẽ có thể thêm các tính năng ở cùng một tỷ lệ mãi mãi. Bạn làm việc trong một dự án lớn và phát hiện ra điều này không đúng.

Các dự án lớn thường có các yêu cầu phức tạp hơn, do đó, có một sự cám dỗ để thử và thực hiện các thiết kế phức tạp. Bạn sẽ dành nhiều thời gian để đọc, nghiên cứu và cố gắng thực hiện chúng. Điều này có thể trở thành một người dọn dẹp thời gian lớn, nhưng nó là một phần của việc học hỏi và tích lũy kinh nghiệm. Biết khi nào nên sử dụng một thiết kế cụ thể là khó khăn và thường đi kèm với kinh nghiệm. Tôi đã thử "dự án" trên "này" và nó không hoạt động nhưng bây giờ tôi thấy nó nên hoạt động "ở đây".

Bạn phải lập kế hoạch và lên kế hoạch rất nhiều, nhưng đừng làm tất cả cùng một lúc. Nó chắc chắn không phải được thực hiện ngay từ đầu. Tôi muốn thấy ai đó tạo dự án lớn đầu tiên của họ như thế này:

1. Thiết kế và thảo luận một chút.
2. Viết một loạt các mã mà làm một cái gì đó.
3. Nhận ra các vấn đề và mã hóa DỪNG.
4. Hãy nghiêm túc về thiết kế và ngừng lo lắng về việc mất đà hoặc mojo mã của bạn và bỏ qua người quản lý dự án (Bạn đang ủng hộ anh ấy / cô ấy.).
5. Nhận dự án dưới sự kiểm soát. Sửa chữa mớ hỗn độn của bạn. Hãy chắc chắn rằng mọi người đều hiểu kế hoạch. Giữ cho dự án được kiểm soát.

Đôi khi bạn nhấn một trong những tính năng thực sự khiến bạn lo ngại về cách triển khai nó trong cơ sở mã hiện có. Đây không phải là lúc để "làm cho nó hoạt động". Tôi đã có một ông chủ nói: "Đôi khi bạn phải lấy một chiếc ghế đẩu thay vì búa." Anh ấy nói với tôi điều này sau khi anh ấy bắt tôi "suy nghĩ" tại bàn làm việc của tôi. Không giống như nhiều ông chủ, anh ta không cho rằng tôi là kẻ ngốc và chắc chắn rằng tôi hiểu rằng anh ta muốn tôi làm nhiều hơn thế. Thiên tài.

Cuối cùng, mã của bạn là thiết kế. Nó được hỗ trợ bởi các tài liệu, sơ đồ, cuộc họp, email, thảo luận về bảng trắng, câu hỏi SO, tranh luận, chửi rủa, cơn thịnh nộ và trò chuyện yên tĩnh về cà phê. Có một điểm mà bạn không thể thiết kế thêm nữa và có nguy cơ phải bỏ thêm thời gian thiết kế vì những sai sót bạn sẽ chỉ phát hiện ra khi cố gắng viết mã. Ngoài ra, bạn viết càng nhiều mã, cơ hội tốt hơn bạn sẽ giới thiệu một lỗ hổng thiết kế mà bạn không thể mã hóa theo cách của mình. Thời gian cho phân một lần nữa.

Các lập trình viên thường xây dựng một cái gì đó hoạt động ngay bây giờ mà không nghĩ về tương lai?

Đúng.

Họ có nên làm như vậy?

Không.

Thoạt nhìn, dường như "nghĩ về tương lai" vi phạm các nguyên tắc thiết kế đã được thiết lập như KISS và YAGNI , họ cho rằng không nên thực hiện bất cứ điều gì không cần thiết ngay bây giờ.

Nhưng thật ra thì không. Suy nghĩ về tương lai có nghĩa là thiết kế phần mềm đơn giản, có thể mở rộng và quản lý được. Điều này đặc biệt quan trọng đối với các dự án dài hạn. Các tính năng mới sẽ được yêu cầu theo thời gian và có một thiết kế chắc chắn sẽ giúp việc thêm các phần mới dễ dàng hơn.

Ngay cả khi bạn không thực hiện dự án sau khi hoàn thành nó, bạn vẫn nên phát triển nó một cách thông minh. Đó là công việc của bạn, và bạn nên làm tốt, ít nhất là để không quên công việc tốt được thực hiện như thế nào.

Các nhà phát triển Agile có một câu nói, "Bạn không cần bạn (YAGNI)" khuyến khích bạn thiết kế cho những gì bạn cần bây giờ hơn là những gì bạn nghĩ bạn có thể cần trong tương lai. Để mở rộng một thiết kế để làm việc trong tương lai, lộ trình được đề xuất là tái cấu trúc.

Khía cạnh quan trọng của vấn đề này là giữ các yêu cầu cho sản phẩm của bạn trong tâm trí khi bạn thiết kế và để đảm bảo rằng bạn không thiết kế cho một loạt các yêu cầu có thể xảy ra trong tương lai.

Có một điều cần nói cho các nhà phát triển có thể nghĩ hai hoặc ba lần lặp trước - họ biết khách hàng hoặc miền của họ tốt đến mức họ có thể dự đoán nhu cầu trong tương lai với độ chính xác cao và xây dựng cho họ, nhưng nếu bạn không chắc chắn, tốt nhất không nên dành quá nhiều thời gian cho những thứ mà bạn hoặc khách hàng không cần.

Đây có phải là một lập trình viên xu hướng thường làm theo khi đi về một dự án như thế này?

Tôi nghi ngờ ý của người cố vấn của bạn là bạn không nên xây dựng bất kỳ sự phức tạp bổ sung nào có thể không được yêu cầu bởi giải pháp cuối cùng.

Thật quá dễ dàng để nghĩ rằng một ứng dụng nên làm điều này và điều đó và nhận được ồ ạt.

Đối với các mẫu thiết kế, điều đáng ghi nhớ là chúng là một phương tiện để kết thúc. Nếu bạn thấy có kinh nghiệm rằng một mẫu thiết kế nhất định không phù hợp mặc dù linh cảm trước đó của bạn, thì điều này có thể chỉ ra mùi mã.

Ví dụ, nếu bạn được yêu cầu làm một bằng chứng về mô hình khái niệm, thì đó có phải là một xu hướng điển hình chỉ để nghiền một ví dụ khả thi càng sớm càng tốt?

Thật đáng để chỉ đạo trước khi dự án bắt đầu như những cột mốc nào và liệu họ sẽ muốn thấy một chút của mọi thứ (lát cắt dọc) hay chỉ từng chi tiết khi bạn phát triển nó (lát cắt ngang). Là một phần của thiết kế ban đầu, tôi thấy nó đáng để lên máy bay cho toàn bộ ứng dụng vì vậy mặc dù mã không được viết, bạn có thể thực hiện chế độ xem trực thăng toàn bộ hoặc lặn sâu trong một khu vực nhất định.

Anh ấy nói rằng tôi đã hết sức suy nghĩ về nhiệm vụ trong tay, và bởi vì tôi chưa bao giờ giải quyết một dự án lớn như thế này nên tôi đã dành quá nhiều thời gian cho việc suy nghĩ các mẫu thiết kế. Nói một cách khôn ngoan, anh ấy nói với tôi "F * ck tương lai, xây dựng ngay bây giờ".

Tôi nghĩ đó là một chút tâm lý cao bồi từ nhà phát triển khác. Phiên bản hiện đại của một mọt sách khó tính chỉ "làm ngay bây giờ". Nó trở thành một chủ đề phổ biến trong số các công ty mới thành lập và không cần cảm ơn mọi người tại Facebook vì đã bắt đầu cụm từ "hoàn thành công việc tốt hơn là làm đúng".

Thật hấp dẫn. Thật đáng khích lệ và đưa ra tầm nhìn của các nhà phát triển đứng xung quanh một bàn điều khiển vỗ tay khi họ triển khai dự án lớn của họ vào thế giới đúng giờ, về ngân sách và tất cả vì họ không vượt qua bất cứ điều gì.

Đó là một tưởng tượng lý tưởng và cuộc sống không hoạt động theo cách này.

Một kẻ ngốc sẽ lao vào một dự án với suy nghĩ anh ta chỉ có thể "làm điều đó" và hoàn thành nó. Thành công sẽ ủng hộ nhà phát triển chuẩn bị cho những thách thức vô hình, và coi nghề nghiệp của mình như nghề thủ công tinh xảo.

Bất kỳ nhà phát triển cấp cao nào cũng có thể chỉ trích, lên án và phàn nàn - và hầu hết đều làm như vậy!

Trong khi anh ấy / cô ấy nói với bạn rằng bạn "quá suy nghĩ" dự án. Tôi chúc mừng bạn đã thực sự "suy nghĩ" đầu tiên. Bạn đã thực hiện những bước đầu tiên để trở thành một nhà phát triển tốt hơn sau đó là người khác.

Đây có phải là một lập trình viên xu hướng thường làm theo khi đi về một dự án như thế này? Ví dụ, nếu bạn được yêu cầu làm một bằng chứng về mô hình khái niệm, thì đó có phải là một xu hướng điển hình chỉ để nghiền một ví dụ khả thi càng sớm càng tốt?

Đó chính xác là một bằng chứng của khái niệm. Đó là một nỗ lực để nghiền nát thứ gì đó càng nhanh càng tốt để mọi người có thể lùi lại một bước và nhìn vào nó. Nó được thực hiện để ngăn ngừa sai lầm, định hướng sai và lãng phí thời gian / tiền bạc.

Có nhiều loại bằng chứng khác nhau về các khái niệm. Bạn có thể xây dựng một cái gì đó bị vứt vào thùng rác khi hoàn thành hoặc bạn có thể xây dựng một cái gì đó đại diện cho một điểm khởi đầu cho dự án. Tất cả phụ thuộc vào những gì bạn cần, và mức độ gần gũi của sản phẩm với sản phẩm cuối cùng.

Đó cũng là một cơ hội để thể hiện ý tưởng của bạn. Đã có những lúc tôi trình bày một nguyên mẫu đưa mọi thứ đến một mức độ mà họ không mong đợi.

Thiết kế thường là kết thúc mở nên quá dễ để áp dụng quá nhiều hoặc quá ít. Và bạn sẽ biết số tiền chính xác chỉ sau khi dự án được thực hiện hoặc loại bỏ. Hoặc thậm chí là không.

Không có công thức chung để thành công, nhưng bạn có thể học cách nhận ra thái cực. Thiết kế hoàn chỉnh của mọi thứ ở phía trước hầu như không bao giờ hoạt động ngoài những thứ tầm thường. Bạn có thể để lại các thành phần để tinh chỉnh và chỉ cần có cảm giác rằng nó có thể được thực hiện hoặc có cách để phát hiện sớm các vấn đề.

Bạn có thể tìm kiếm cách phát triển gia tăng hoạt động nếu bạn không quen. Các phương pháp thành công thường được lặp đi lặp lại ở một hoặc nhiều cấp độ, tìm kiếm phản hồi chặt chẽ và phát triển trên một số bộ xương.

Có một vài lý do tốt để lắng nghe lời khuyên để ngừng lập kế hoạch và bắt đầu viết mã;

1. Chỉ sau 18 tháng làm nhà phát triển, không có khả năng bạn có thể dự đoán tương lai đủ tốt để lập kế hoạch cho nó, bất kể điểm trung bình đại học của bạn. Đây là điều cực kỳ khó khăn đối với các nhà phát triển sáng giá nhưng thiếu kinh nghiệm để nắm bắt, vì tất cả chỉ là về việc không biết những gì bạn không biết. Những bàn tay cũ có thể đã nhận ra điểm yếu này trong tầm nhìn của bạn, và khôn ngoan khuyến khích bạn chỉ cần vào đó và cố gắng hết sức.

2. Các nhà phát triển trẻ có thể bị ám ảnh với việc hoàn thiện thiết kế trước khi họ bắt đầu viết mã. Họ có thể che đậy nỗi sợ viết mã (lo lắng về hiệu suất) hoặc có thể có khối lập trình viên (như khối nhà văn). Họ dally trong thiết kế vì không có đầu ra công việc cần thiết. Nhà phát triển trẻ có thể sẽ phản ứng giận dữ với đề nghị rằng họ "sợ" bất cứ điều gì. Có lẽ vào cuối dự án họ sẽ nhận ra rằng họ đã như vậy. Lời khuyên là đừng lo lắng và hãy viết mã tạo thành phương pháp chữa trị duy nhất được biết đến cho khối lập trình viên. Một bàn tay cũ có thể khôn ngoan đưa ra lời khuyên này.

3. Với sự hạn chế của lịch trình khắc nghiệt, cơ hội hoàn thành dự án của bạn bị hạn chế. Lên kế hoạch quá dài và cho dù kế hoạch có tốt đến đâu, bạn cũng không thể thực hiện kịp thời và bạn không bao giờ được tiếp thị. Bắt đầu hack ngay từ đầu, và có thể bạn sẽ gặp may mắn và ngay lần đầu tiên. Bạn cung cấp sản phẩm một cách kỳ diệu. Hoặc, có thể bạn không may mắn như vậy, và cung cấp một mẩu xỉ nửa nướng nhưng nó được đưa vào thị trường đúng giờ và bạn học được điều gì đó. Hoặc có thể bạn thất bại. Nhưng "có thể bạn thất bại" vẫn có tỷ lệ cược tốt hơn "không bao giờ được đưa ra thị trường" vì bạn đã lên kế hoạch quá lâu. Sự hiểu biết chính là cơ hội của bạn bị hạn chế ngay từ đầu, vì vậy bạn không mất gì khi hack. Người quản lý của bạn có thể biết có rất ít cơ hội thành công và được chỉ định một tài nguyên cơ sở giống như một bài tập học tập. Chúng ta học tốt hơn từ thất bại hơn là từ thành công. Có lẽ bạn đã từng hỏi, "Khi nào tôi có thể có cả một dự án?"

Cần một nhà phát triển khá nội tâm và không có bản ngã để thấy được sự không hoàn hảo của chính họ, vì vậy hãy suy ngẫm một lúc trước khi đọc phần còn lại của điều này, e rằng bạn sẽ tự bào chữa cho mình để bỏ qua điểm yếu của mình ...

Không phải mọi nhà phát triển đều đặc biệt giỏi trong việc phân tích, lập kế hoạch và các nhiệm vụ khác đòi hỏi phải suy nghĩ. Suy nghĩ là khó khăn và icky. Nó đòi hỏi một loại mồ hôi tinh thần khiến bạn khó chịu và quằn quại sau một ngày làm việc. Điều đó không thú vị bằng việc vào trạng thái dòng chảy với hai lon Monster và hòn đá của bạn bật lên to và mã hóa, mã hóa, mã hóa. Các nhà phát triển không thích suy nghĩ sẽ chống lại quan niệm rằng lập kế hoạch là một ý tưởng tốt. Họ đề xuất các phương pháp dev không yêu cầu lập kế hoạch trước. Họ thích các công ty và nhà quản lý không nhấn mạnh vào kế hoạch. Họ hấp dẫn những công việc mà chi phí không lên kế hoạch không quá cao. Họ coi trọng tất cả các phiên mã hóa ban đêm và đưa hotfix đó ra cho khách hàng có toàn bộ hoạt động kinh doanh vì lỗi.

Một số nhà phát triển thậm chí đã nhận ra rằng làm cho một cái gì đó hoạt động đủ tốt để demo có nghĩa là làm cho nó hoạt động hoàn toàn và trong mọi trường hợp có thể bị trì hoãn, và thậm chí có thể bị đẩy sang một nhà phát triển khác, trong khi họ nhận được danh tiếng cho "hoàn thành công việc" ban đầu.

Có những người quản lý không thể tự mình phát hiện ra một xu hướng cho đến khi nó đã bị phá vỡ trên facebook. Thay vì tìm một công việc quản lý cửa hàng lốp xe giảm giá, những người quản lý này đặt vấn đề của bạn là họ cần mã chạy vào thứ Sáu. Họ không muốn nghe rằng bạn cần thiết kế API hoặc kiểm tra xem thuật toán của bạn có khả năng mở rộng hay không. Đây chỉ là công nghệ mumbo-jumbo đối với họ. Họ sẽ khuyến khích bạn viết mã bởi vì đó là tất cả những gì họ hiểu về phần mềm khi họ viết các tập lệnh perl để giúp khách hàng chuyển các tập tin của họ. (Họ có danh hiệu 'kỹ sư phần mềm' trong công việc bán hàng đầu tiên của họ. Ai biết phần mềm sẽ rất nhàm chán và khó khăn?)

Cho tôi xem mã của bạn và tôi sẽ cho bạn biết bạn là ai

Mã của bạn là thẻ thăm của bạn. Nếu bạn viết mã lộn xộn, điều gì cho bạn biết về bản thân bạn với người khác? Chỉ cần nghĩ về điều đó. Mỗi khi chúng tôi tìm thấy trong văn phòng một đoạn mã thực sự tồi tệ, chúng tôi tự hỏi, ai đã viết nó và làm thế quái nào anh ta đi qua trường đại học?

Bạn đang trở thành những gì bạn mã

Mã của bạn là chương trình của bạn cho cuộc sống.

Một lập trình viên viết mã xấu giống như một vũ công ba lê nhảy múa trong câu lạc bộ thoát y

Một số người không quan tâm đến việc nhảy múa trong câu lạc bộ thoát y. Nhưng nếu họ là những vũ công cao lớn, họ đang lãng phí kỹ năng của mình. Nếu bạn là một vũ công nghèo nhưng có đôi chân đẹp, bạn có thể lột đồ cho nhiều người.

Cuối cùng, bạn nên đọc tiểu thuyết 'Chân dung' của Gogol, và bạn sẽ được cảnh báo bởi câu chuyện của nhân vật chính. Bạn của bạn giống với người đàn ông từ bức chân dung. Anh ta đang dụ dỗ bạn bằng tiền, nhưng bạn sẽ trả giá cao cho nó.