Bạn có nên viết tài liệu tốt và mã sạch để tăng hệ số Bus Bus Factor không?

Một trong những mục tiêu chính của các công ty phát triển phần mềm là tăng yếu tố Bus của họ Điều này cũng được ủng hộ trong một cuộc nói chuyện được tổ chức bởi Google .

Điều đó có nghĩa là bạn nên viết mã và ghi lại mọi thứ theo cách mà nếu bạn chạy qua xe buýt vào ngày mai, dự án vẫn có thể tiếp tục. Nói cách khác, bạn nên làm cho bản thân dễ dàng thay thế bởi một lập trình viên khác với bộ kỹ năng tương tự như của bạn.

Có thể thay thế, điều đó có trái với lợi ích của nhà phát triển không? Trong cuốn sách, 48 luật về quyền lực Quy tắc 11 nói rằng bạn nên cố gắng giữ mọi người phụ thuộc vào bạn, để có được quyền lực, sau đó chuyển thành phần thưởng bằng tiền.

Ngoài kịch bản, nơi bạn cần một số tài liệu cho chính mình để tiếp tục dự án sau 6 tháng tạm dừng, dường như có một xung đột lợi ích rõ ràng ở đây giữa nhà phát triển và công ty phần mềm.

Vì vậy, là một lập trình viên, bạn nên thực sự viết tài liệu tuyệt vời và mã dễ đọc cho mọi người; hoặc bạn nên viết mã và tài liệu theo cách mà nó thực hiện công việc và chính bạn có thể hiểu nó, nhưng một người khác có thể gặp khó khăn khi hiểu nó?

Bạn nên cố gắng để trở nên không thể thay thế không phải bằng cách viết mã mà không ai khác hiểu, mà bằng cách thu thập nhiều kinh nghiệm và kiến ​​thức hơn những người khác. Cách trước đây khiến bạn trở thành nhà phát triển, mọi người đều cố gắng tránh làm việc cùng, vì họ sẽ sợ và ghê tởm việc duy trì mã bạn đã viết. Cách thứ hai bạn trở thành một thành viên trong nhóm tìm kiếm, người mà các nhà quản lý muốn có trong nhóm của họ.

Theo kinh nghiệm của tôi, việc viết sạch, mã tài liệu tốt (và tốt nhất là tự viết tài liệu) luôn được đền đáp. Trên thực tế, tôi đã tận dụng mọi cơ hội để giúp đỡ và dạy người khác (cũng như học hỏi từ họ khi họ biết điều gì đó tốt hơn) và tôi hầu như không cảm thấy nguy hiểm khi bị thay thế bởi một người kém năng lực hơn mình. Trên thực tế, điều này thường giúp toàn bộ nhóm làm việc tốt hơn và giải quyết vấn đề nhanh hơn, đó là giấc mơ của mọi nhà quản lý - và một người quản lý hợp lý không muốn thay thế các thành viên của một nhóm tốt.

Nếu bạn định thao túng các tổ chức hoặc mọi người một cách minh bạch thì tốt hơn hết là họ nên ngu ngốc hoặc trong tình trạng kẹt khiến họ không còn lựa chọn nào khác. Một cửa hàng phát triển phần mềm hoạt động tốt sẽ xem xét mã tối nghĩa của bạn và tài liệu bị thiếu và chỉ đơn giản là sa thải bạn trước khi bạn có thể gây ra nhiều thiệt hại. Nếu họ hoạt động kém hoặc không thể khiến bất kỳ nhà phát triển nào khác làm việc cho họ, tại sao bạn lại muốn có một tội lỗi với họ?

PS Cả ông Greene và Machiavelli đều không thực sự đạt được nhiều thành công ngoài việc viết những cuốn sách cố gắng tâng bốc sẽ là "những người khó tính" thời bấy giờ. Hãy nghe lời khuyên của họ với một hạt muối.

Nếu bạn không thể thay thế, bạn không thể được thăng chức.

Bạn không muốn là không thể thay thế. Bạn không muốn làm cho mọi người cảm thấy phụ thuộc vào bạn, bạn muốn họ đánh giá cao bạn. Nói chung, bạn muốn tránh xa mọi người, những người tin rằng thậm chí một nửa luật quyền lực nên được áp dụng cho các mối quan hệ (chuyên nghiệp hoặc cá nhân).
Các quy tắc này là một hướng dẫn được thiết lập về cách thiết lập thành công một tình huống thắng-thua. Những gì bạn muốn, là một tình huống đôi bên cùng có lợi .
Ngay khi mọi người bắt đầu cảm thấy, bạn đang cố gắng đẩy họ về phía thua của một tình huống thắng-thua, họ sẽ chiến đấu trở lại. Nỗ lực thiết lập các tình huống thắng-thua thường dẫn đến kết quả thua-thua, bởi vì bạn đang lãng phí một cách hiệu quả các nguồn lực để đưa đối tác của mình vào thế thua, thay vì đầu tư chúng vào thành công chung của mối quan hệ đối tác.

Nếu bạn làm điều này với nhà tuyển dụng của bạn, họ sẽ cố gắng áp dụng các biện pháp đối với bạn, để giảm độc quyền kiến ​​thức của bạn. Hầu hết, đây sẽ là những hướng dẫn lố bịch về cách bạn phải thực hiện công việc của mình và từ đó sẽ biến cuộc sống công việc của bạn thành một địa ngục sống. Ngoài ra, họ sẽ gọi cho bạn vào lúc 3 giờ đêm khi có thứ gì đó bị hỏng, bởi vì bạn là người duy nhất, người có thể sửa nó. Cố gắng khai thác các tình huống như đòn bẩy có khả năng gây tác dụng ngược và khiến bạn gặp nhiều rắc rối hơn.

Các nghĩa địa đầy những người đàn ông không thể thiếu.
- Gaulle, Charles De

Vì vậy, cắt crap và làm công việc của bạn đúng cách. Nếu không phải vì bất cứ điều gì khác, thì đối với bạn, bởi vì bạn có khả năng là linh hồn nghèo, người phải thực hiện một số thay đổi cho mã 2 năm kể từ bây giờ.

Các phản hồi tiêu cực không quá ngạc nhiên, với số lượng lập trình viên tốt hơn trung bình mà trang web này thu hút. Những người tài năng thường không cần phải dùng đến những chiến thuật bảo mật thông qua các loại chiến thuật này. Nhưng tôi đã làm việc tại một nhà cung cấp ô tô Fortune 500 với một vài nhà phát triển không tài năng, những người đã tự mình tạo ra những sở thích nhỏ mà họ bảo vệ một cách nhiệt tình bằng cách tạo ra một lượng lớn tài liệu cho các giao diện khủng khiếp mà họ đã thiết kế.

Toàn bộ công việc của một chàng trai là duy trì mã cho một mô-đun bắc cầu hai hệ thống con hoàn toàn riêng biệt, cho phép các mô-đun trên mỗi hệ thống giao tiếp thông qua UART. Về cơ bản, đó là Lập trình nối tiếp 101. Thay vì chỉ tạo một giao diện chung trông giống như thế này:

  int sendData (int targetModule, void * data, size_t byteCount);
  int recvData (int sourceModule, void * data, size_t maxBytes);

ông đã tạo ra các opcodes riêng cho mỗi tin nhắn mà bất kỳ hai mô-đun giao tiếp nào cũng có thể muốn gửi cho nhau. Điều đó có nghĩa là mô-đun của anh ta cần biết về mọi tin nhắn và cần được cập nhật mỗi khi tin nhắn được thêm hoặc thay đổi. Nói về sự thân mật không phù hợp!

Vấn đề là, anh chàng này đã giữ một tài liệu Word liệt kê gọn gàng tất cả các opcode / tin nhắn và siêng năng cập nhật nó khi cần thiết. Nó trở thành toàn bộ công việc của anh ấy . Một vài lần một tuần, anh ấy sẽ gửi một bản sửa đổi mới cho tất cả những người không may có anh ấy trên con đường quan trọng của họ. Và điều này được coi là "chuyên nghiệp", vì quản lý thích xem tài liệu. Kinda làm tôi khóc cho ngành công nghiệp ô tô.

Tôi đoán quan điểm của tôi là: đôi khi viết tài liệu có thể, trên thực tế, bảo vệ các lập trình viên tầm thường. Các nhà quản lý thường không thể phân biệt sự khác biệt giữa một thiết kế tốt và một thiết kế xấu, và nhiều người buộc phải đưa ra các quyết định kỹ thuật với thông tin hạn chế. Nó cực kỳ căng thẳng đối với họ. Nhìn thấy một tài liệu Word với hàng tá bảng được định dạng gọn gàng có thể rất thoải mái, ngay cả khi những gì nó mô tả là một ý tưởng tồi về cơ bản.

Có thể thay thế, điều đó có trái với lợi ích của nhà phát triển không?

Tôi ghét phải phá vỡ nó cho bạn, nhưng mọi người đều có thể thay thế. Chắc chắn, đôi khi nó có thể là một thách thức nhỏ để thay thế bạn (nếu bạn có kinh nghiệm và đủ sáng), nhưng đó là năm nhẹ từ không thể.

Cách để thực sự trở thành một hàng hóa có giá trị đối với nhà tuyển dụng của bạn (không chỉ nhà tuyển dụng hiện tại, mà bất kỳ nhà tuyển dụng nào ) là thể hiện khả năng viết mã dễ dàng để tìm kiếm bởi bất kỳ ai đọc mã (ít thời gian để làm việc với nó) và tài liệu mã (bất kỳ ai cũng có thể có được tổng quan cấp cao về hệ thống của bạn mà không cần đào sâu vào mã).

Thực tế là giỏi về tài liệu mã là một chất lượng khó khăn trong những ngày này, vì vậy điều đó một mình sẽ giúp bạn khác biệt với những người khác.

Mã tài liệu sạch và tốt cũng xứng đáng được đưa vào sơ yếu lý lịch (ít nhất là kết quả rõ ràng của nó, tức là "chúng tôi có thể đưa ncác nhà phát triển mới vào với sự hỗ trợ và hỗ trợ tối thiểu do tài liệu của tôi), trong đó lén lút thực hiện bản thân bạn "không thể thay thế" không.

Có thể thay thế, điều đó có trái với lợi ích của nhà phát triển không?

Phụ thuộc vào lợi ích của nhà phát triển đó là gì. Nếu bạn là một người muốn gắn bó với một công việc duy nhất cho toàn bộ sự nghiệp của mình, thì hoàn toàn không thể thiếu đối với một công ty thưởng cho sự bất tài và kiếm tiền tốt thì hoàn toàn có.

Nhưng điều gì xảy ra khi công ty gặp sự cố, có lẽ vì họ đã thuê quá nhiều người như vậy? Bạn sẽ đi đâu tiếp theo? Điều gì khi họ hỏi bạn tại sao bạn ở lại cùng một công việc trong 15 năm? Và như vậy.

Bây giờ hãy nhìn nó theo một cách khác: Có bao nhiêu nhà phát triển đã mất việc bằng cách là người viết mã mà bất cứ ai cũng có thể đọc?

Khả năng duy nhất xảy ra là nếu công ty gặp rắc rối và khiến mọi người trở nên dư thừa. Nếu điều đó đang xảy ra, tốt hơn hết là bạn nên ra ngoài, và bạn sẽ chuẩn bị rất tốt cho các cuộc phỏng vấn sắp tới. Thêm vào đó, lương tâm của bạn sẽ hoàn toàn miễn phí - bạn sẽ không để lại mã không thể giải thích được mà bạn đã viết cho lợi ích của chính mình.

Tôi không biết bạn là người như thế nào, nhưng điều đó phục vụ sở thích của tôi tốt hơn.

Cá nhân, tôi nghĩ một trong những thế mạnh lớn nhất của tôi là tự động hóa công việc của mình. Bạn nghĩ gì về một công ty có xu hướng nghĩ khi tôi trở nên dư thừa so với yêu cầu của riêng tôi? Họ có nghĩ rằng "ok, chúng ta sẽ thoát khỏi anh ta ngay bây giờ" hay họ nghĩ "tại sao chúng ta không chuyển anh ta sang một vai trò khác và để anh ta làm điều đó một lần nữa"?

Có thể thay thế, điều đó có trái với lợi ích của nhà phát triển không?

Bạn đúng, nhưng tôi nghĩ bạn đã hiểu sai ý nghĩa của việc thay thế. Tôi có thể tìm thấy 1000 nhà phát triển viết mã bận rộn, không có giấy tờ có thể nhanh chóng biến thành một mớ hỗn độn không thể nhầm lẫn.

Một nhà phát triển sản xuất không chỉ các chương trình ổn định mà còn cả mã sạch, tài liệu thông tin và đảm bảo tính liên tục của dự án, điều đó không chỉ không thể thay thế, đó là vô giá .

Tôi sẽ giải quyết câu hỏi này từ một khía cạnh khác, vì đã có một số câu trả lời xuất sắc.

Xem xét những gì xảy ra khi bạn chơi các trò chơi nhỏ bằng cách cố gắng làm cho mình "không thể thay thế" mặc dù ngăn người khác học cách mã của bạn hoạt động. Bạn ở trong cùng một công việc duy trì những mớ hỗn độn của riêng bạn miễn là công ty chịu đựng bạn. Và đó là trường hợp tốt nhất, kịch bản tồi tệ nhất là các kỹ sư và quản lý tài năng hơn, tài năng hơn và đạo đức hơn trong công ty của bạn thấy sự cản trở trong thực tiễn kém của bạn đối với công ty và họ quyết định làm gì đó: bằng cách sa thải bạn và viết lại mọi thứ từ đầu. Nó đã được thực hiện. Trên thực tế, đó là một điều khá phổ biến xảy ra.

Bây giờ hãy xem xét những gì xảy ra khi bạn viết mã tốt và tài liệu tốt. Bạn tạo ra một thành phần hoặc một hệ thống hoạt động tốt, sau một thời gian hoạt động, các lỗi hoạt động trơn tru và hầu như không cần phải xem xét. Phải mất ít nỗ lực để duy trì nó. Sau đó, bạn có thể chuyển sang các dự án lớn hơn và tốt hơn, với một chiến thắng vững chắc dưới vành đai của bạn. Mọi người sẽ nhận ra bạn vì đã hoàn thành tốt công việc và sẽ bắt đầu tôn trọng ý kiến ​​của bạn. Bạn sẽ có khả năng đi lên trong chuỗi thức ăn và đưa ra các quyết định có ý nghĩa hơn hoặc thực hiện các công việc quan trọng và có tác động hơn hoặc quản lý các dự án ở cấp cao hơn. Sự nghiệp của bạn sẽ được cải thiện, bạn sẽ được thăng tiến, bạn sẽ kiếm được nhiều tiền hơn, bạn sẽ được đồng nghiệp công nhận và chấp thuận, bạn sẽ ngày càng thành công hơn với nhiều dự án quan trọng hơn vào hồ sơ theo dõi của mình.

Bạn thích con đường nào?

Nếu bạn là điểm thất bại duy nhất, khách hàng của bạn (hoặc chủ nhân) có thể sẽ cố gắng thay thế bạn; luôn luôn có một điểm mà việc thay thế phần mềm ít tốn kém hơn là bảo trì phần mềm, bất kể nó có vẻ thiết yếu đến mức nào. Có một lý do CNTT là một trong những ngành nghề gia công nhất.

Mặt khác, việc có thể thay thế mang lại cho bạn một số lợi ích vô giá:

• có thể đi nghỉ
• không được gọi
• tự do rời đi và làm việc trong một dự án mới và xuất cảnh

Nếu bạn không dành 5 phút để viết một số tài liệu nhanh thì bạn sẽ dành một giờ để đọc lại và giải thích cho mọi người khi họ cần sử dụng mã của bạn.

Tệ hơn nữa có thể là mất nhiều ngày để tìm kiếm một công việc mới vì sếp của bạn phát hiện ra bạn không viết mã có thể duy trì.

Tài liệu tuyệt vời cuối cùng sẽ bị lỗi thời với tái cấu trúc / tiến hóa, và việc cập nhật nó thực sự tốn thời gian.

Mã sạch + kiểm tra đơn vị> tài liệu tuyệt vời

Câu trả lời cho câu hỏi của bạn là có". Có bạn nên viết tài liệu tốt và mã sạch. Cố tình làm khác thể hiện sự thiếu liêm chính, trong khi ngày càng phổ biến trong thế giới kinh doanh không phải là một điều "tốt".

Không ai là không thể thay thế. Những người sản xuất một tình huống theo đó họ nghĩ rằng họ có xu hướng tìm ra cách khó mà họ không làm. Sản xuất một đồng phụ thuộc cho chính bạn là phản tác dụng vì nó cũng giới hạn bạn, không chỉ chủ nhân của bạn.

Một trong những mục tiêu chính của các công ty phát triển phần mềm là tăng hệ số Bus của họ

Tiền đề sai. Mục tiêu chính của một công ty phát triển phần mềm (dù sao tôi cũng từng làm việc) là sản xuất phần mềm tốt nhất có thể và kiếm tiền, không nhất thiết phải theo thứ tự đó. Giảm "yếu tố xe buýt" chỉ là một cách để tránh mất tiền.

Luật 11 Học cách giữ người phụ thuộc vào bạn.

Điều đó có ý nghĩa gì với bạn?

Bạn có muốn mọi người phụ thuộc vào bạn vì bạn đã làm suy yếu họ theo cách mà họ chỉ có thể tiến lên với sự giúp đỡ của bạn? Hay bạn muốn mọi người phụ thuộc vào bạn vì bạn thông minh và sâu sắc, đáng tin cậy, đáng tin cậy và có thể giúp người khác làm việc của họ tốt hơn? Bạn có muốn làm cho đồng nghiệp của bạn trông xấu mà không có sự giúp đỡ của bạn, hoặc bạn muốn họ đánh giá cao bạn vì đã làm cho họ trông tốt?

Đó là cuộc gọi của bạn.

(giả sử mã sản xuất)

Tôi có xu hướng đi xa hơn một chút. Tôi đã viết về việc tạo ra các chương trình "bằng chứng ngốc", nhưng tôi không luôn đủ điều kiện rằng: Tôi viết rất nhiều mã mà người khác sẽ không nhìn thấy hoặc làm việc với (ít nhất, đó là kỳ vọng khi nó được viết). TôiTôi là thằng ngốc tôi đang cố bảo vệ mình trong trường hợp đó. Đó là một điều tốt khi chương trình của bạn phát hiện ra các vấn đề cho bạn và vấn đề đã được đơn giản hóa đến mức rõ ràng là có lỗi và nguồn gốc của nó. Sự thật là, chi tiết triển khai rất rõ ràng khi bạn viết chương trình (trừ khi bạn triển khai sớm), nhưng chúng phải được trừu tượng hóa và chống lỗi cho khách hàng (ngay cả khi địa phương mô-đun tồn tại). Lý do là các chương trình trở nên rất phức tạp. Đôi khi bạn có thể tách vấn đề, nhưng không phải tất cả thời gian. Nếu bạn giữ các thành phần của mình rất nghiêm ngặt, đơn giản, được đóng gói tốt và bằng chứng ngốc, chúng có xu hướng mở rộng tốt và hầu hết các lỗi được phát hiện trước khi chúng được chuyển đi. Việc sử dụng lại dễ dàng hơn và bạn cũng có sự tự tin hơn và thời gian sử dụng lại các chương trình dễ dàng hơn. những chương trình phức tạp mà bạn viết chỉ trở nên phức tạp hơn (thậm chí với bạn) sau một thời gian rời khỏi chương trình. Khi bạn đọc nó trong 6 tháng, có thể mất một khoảng thời gian vô lý để hiểu và gỡ lỗi so với phiên bản bằng chứng ngốc. Nếu một thành phần giới thiệu một sự thay đổi đột phá, nó có thể không bị phát hiện trong một thời gian dài. Các chương trình rất phức tạp; bạn không thể thoát khỏi thực tế đó, nhưng bạn có thể biến nó thành bằng chứng ngu ngốc, điều này sẽ giúp cuộc sống của bạn dễ dàng hơn rất nhiều khi có sự cố hoặc khi nó phải được sử dụng lại hoặc thay đổi. Do đó, cách tiếp cận bằng chứng ngu ngốc có nghĩa là phần mềm của bạn có thể được hiểu, sử dụng lại hoặc duy trì bởi đàn em hoặc những người mới hơn trong nhóm (không chỉ là người giỏi / có kinh nghiệm như bạn). Thay thế là một mối quan tâm riêng biệt: Nếu mọi người thích làm việc với các chương trình của bạn, bạn đang làm tốt công việc - đừng ' t lo lắng về sự thay thế. Chắc chắn, tôi có thể đưa ra các kịch bản trong đó các chương trình khó hiểu có thể cứu công việc của bạn, nhưng viết một chương trình tốt mà người khác có thể sử dụng và duy trì rõ ràng là điều xấu xa hơn (nhìn vào sự hồi sinh của người khác). Nếu tôi bắt mình viết một cái gì đó không phải là bằng chứng ngu ngốc, tôi sẽ cố gắng sửa nó.

Ngoài kịch bản, nơi bạn cần một số tài liệu cho chính mình để tiếp tục dự án sau 6 tháng tạm dừng, dường như có một xung đột lợi ích rõ ràng ở đây giữa nhà phát triển và công ty phần mềm.

Bạn thực sự không biết bạn đã nghĩ gì khi bạn xem lại các triển khai không hoạt động. Khi bạn thực sự có kinh nghiệm, thì vấn đề sẽ đơn giản hơn vì bạn có thể dựa nhiều hơn vào các phương pháp hoặc phương pháp đã được thiết lập mà bạn sử dụng. Tuy nhiên, điều đó cũng cho rằng các phương pháp này là bất biến. Mặc dù tài liệu có thể lỏng lẻo, bạn vẫn phải phòng thủ trong việc triển khai của mình (ví dụ: bạn biết rõ hơn là vượt qua NULL trong kịch bản này - kiểm tra điều kiện đó).

Vì vậy, là một lập trình viên, bạn nên thực sự viết tài liệu tuyệt vời và mã dễ đọc cho mọi người; hoặc bạn nên viết mã và tài liệu theo cách mà nó thực hiện công việc và chính bạn có thể hiểu nó, nhưng một người khác có thể gặp khó khăn khi hiểu nó?

Tôi khuyên bạn nên sử dụng phương pháp chứng minh ngu ngốc, thậm chí còn rõ ràng hơn và có khả năng chống lỗi cao hơn so với phương pháp tiếp cận yếu tố xe buýt. Viết chương trình và tài liệu của bạn sao cho dễ hiểu bởi ai đó bên ngoài dự án - nó cũng tốt cho bạn. Làm như vậy sẽ tăng giá trị của bạn cho công ty và nhóm của bạn, họ sẽ không muốn thay thế bạn.

Về cơ bản, bạn đã hiểu nhầm trò chơi. Trò chơi không phải là tiếp tục làm những việc cũ mà bạn đã làm trước đây, chịu trách nhiệm cho tất cả các mã bạn đã viết vì không ai khác nhận được nó. Trò chơi là hoàn thành một dự án và chuyển sang dự án tiếp theo, để lại mã mà người khác có thể dễ dàng hiểu và làm việc khi bạn vắng mặt để bạn có thể làm những điều mới và đảm nhận nhiều trách nhiệm khác nhau. Tiền đề của bạn chỉ hoạt động nếu bạn vui mừng khi bị mắc kẹt làm điều tương tự lặp đi lặp lại mà không có cơ hội học hỏi hoặc cải thiện.

Tôi cũng sẽ chỉ ra rằng nếu bạn không có dịp xem mã đó rất thường xuyên, bạn cũng sẽ gặp khó khăn khi tìm ra nó trong sáu tháng nếu bạn cố tình làm xáo trộn nó.

Tôi ghi lại những gì tôi viết ít mã, không phải để người khác có thể đọc nó, nhưng để tôi có thể đọc nó trong 3 tháng! Đó là về việc bảo trì dễ dàng hơn. Nếu bạn chịu trách nhiệm về mã bạn đã viết và bạn không thể sửa các lỗi xuất hiện sau đó, thì bạn sẽ muốn nó được ghi lại rõ ràng ... Thật không liên quan đến việc bạn có thể thay thế như thế nào nếu bạn không thể để làm công việc của bạn!

Mọi chuyên gia máy tính "không thể thay thế" mà tôi gặp phải sự không may khi tương tác đã bị thay thế, phần lớn là do họ đang cố giữ con tin tài nguyên của chủ nhân. Khi tôi có những người báo cáo cho tôi biết thời gian của họ là có giá trị để "lãng phí" tài liệu, tôi thay thế họ càng sớm càng tốt.

Có vẻ như nếu một nhân viên tương lai coi 48 luật quyền lực là có thể chấp nhận được về mặt đạo đức hoặc đạo đức, thì bạn sẽ tốt hơn nếu không có chúng.

Nếu bạn THỰC SỰ muốn không thể thay thế (mà bạn có thể muốn xem xét lại sau khi đọc tất cả các câu trả lời ...) - tại sao dừng lại với việc không ghi lại mã?

Có một hướng dẫn thực sự xuất sắc về cách viết mã không thể nhầm lẫn mà bạn chắc chắn nên đọc: http://thc.org/root/phun/unmaintain.html

Thưởng thức! (Tôi chắc chắn đã làm ...)