Bạn có nên giữ một bản sao của tất cả các mã bạn viết? [đóng cửa]

Tôi biết công ty bạn làm việc sở hữu mã và rõ ràng bạn sẽ bị bắt nếu bạn cố bán nó. Nhưng có gì lạ khi các nhà phát triển giữ một bản sao cá nhân của mã họ đã viết (để tham khảo trong tương lai)?

Rõ ràng anh chàng này đã bị gửi đến nhà tù vì sao chép mã nguồn.

Nhưng có gì lạ khi các nhà phát triển giữ một bản sao cá nhân của mã họ đã viết (để tham khảo trong tương lai)?

Tôi không biết mức độ phổ biến của nó, nhưng phổ biến hay không, đó vẫn là một ý tưởng tồi.

Các lập trình viên thường hoạt động trong suy nghĩ rằng giải quyết cùng một vấn đề hai lần là một sự lãng phí thời gian. Chúng tôi cố gắng thiết kế mã của chúng tôi để có thể tái sử dụng (đôi khi). Chúng tôi xây dựng thư viện các lớp và hàm để tái sử dụng tại một số điểm trong tương lai. Đôi khi chúng tôi thậm chí còn cung cấp mã của mình để không ai khác phải viết mã để giải quyết vấn đề tương tự mà chúng tôi vừa làm. Vì vậy, có thể dễ hiểu khi muốn mang theo mã "của bạn" khi bạn chuyển từ công việc này sang công việc khác. Nhưng bạn vẫn không nên làm điều đó, vì những lý do sau:

1. Đó không phải là mã của bạn để lấy.

2. Mã bạn đã viết cho chủ cũ của bạn là một phần của doanh nghiệp họ đã xây dựng. Mã của họ là một phần của lợi thế cạnh tranh của họ. Chắc chắn, các đối thủ cạnh tranh có thể tự viết mã để giải quyết vấn đề tương tự, nhưng họ không nên tận dụng lợi thế của việc xây dựng công việc mà chủ nhân của bạn đã trả tiền, sở hữu và không ủy quyền cho bạn đảm nhận.

3. Nếu họ có bất kỳ ý nghĩa nào, nhà tuyển dụng mới của bạn không muốn bất kỳ phần nào của mã mà bạn đã lấy từ chủ cũ của mình. Bạn càng "giới thiệu" công việc bạn đã làm cho một số chủ nhân trước đây, bạn càng khiến nhà tuyển dụng mới gặp nguy hiểm về pháp lý.

4. Nếu bạn từng vô tình để nó trượt ở Nhà tuyển dụng mới mà bạn vẫn có một bản sao của những thứ bạn đã làm cho Chủ cũ, thì ông chủ của bạn tại New có thể sẽ nhận ra rằng bạn sẽ lấy một bản sao mã của họ khi bạn để lại cho người khác việc làm. Điều đó có thể không ngồi tốt với anh ấy hoặc cô ấy.

5. Ngay cả khi bạn không đưa ra những dòng thực tế hoặc chỉ là những ý tưởng mơ hồ từ những thứ cũ của bạn, chỉ cần sở hữu những thứ cũ của bạn có thể làm bạn nghi ngờ rằng bạn có thể đang sử dụng nó cho mục đích gì đó. Hãy tưởng tượng rằng Chủ nhân cũ kiện Chủ nhân mới, và là một trong số ít nhân viên chuyển từ Cũ sang Mới, bạn đột nhiên thấy mình đưa ra một sự lắng đọng. Không ai trong số bạn thực sự sao chép mã của Old vào sản phẩm của New, nhưng luật sư trước mặt bạn hỏi: "Ông SuperFoo, bạn có hoặc có bất cứ lúc nào kể từ khi rời Nhà tuyển dụng cũ sở hữu một bản sao của bất kỳ mã nào mà bạn hoặc có ai khác viết khi làm việc tại Old Employer không? "

6. Bạn không cần mã mà bạn đã viết tháng trước, năm ngoái hoặc lâu hơn. Bạn đã giải quyết vấn đề một lần, và bây giờ bạn biết cách giải quyết vấn đề một lần nữa. Hoặc, bạn có thể biết cách không giải quyết vấn đề - việc triển khai mới của bạn sẽ tốt hơn vì bạn có kinh nghiệm.

7. Có nhiều cách tốt hơn. Thật khó để quay lại và học bất cứ điều gì hữu ích bằng cách đọc mã cũ ra khỏi bối cảnh. Một cuốn nhật ký hoặc tạp chí mô tả những gì bạn học, những ý tưởng mà bạn có, v.v ... sẽ hữu ích hơn rất nhiều sau này.

8. Ngay cả khi Nhà tuyển dụng cũ biết rằng bạn đã nhận được mã của họ và đồng ý với điều đó, bạn vẫn không muốn nó! Điều duy nhất có thể có là một cuộc gọi điện thoại lúc 3 giờ sáng: "Này, SuperFoo? Bạn thế nào? Nghe này, bạn đã có một bản sao của công cụ của chúng tôi, phải không? Hãy nhìn xem, chúng tôi có vấn đề với và chúng tôi đã thu hẹp nó thành một vài tập tin mà bạn đã viết rằng anh chàng mới của chúng tôi không hiểu. Tôi biết điều đó đã muộn, nhưng bạn có thể dẫn anh ấy qua SuperDuper.pl không? "

Để nó đi. Bạn không cần nó.

Tôi luôn giữ một bản sao của mã tôi viết và lấy nó giữa các công việc. Các nhà tuyển dụng sau đó không bao giờ được xem / chạy mã, nhưng tôi sử dụng nó làm tài liệu tham khảo tại nhà: 'À đúng, tôi không làm điều gì tương tự như vậy trên Project X?'.

Điều này có hợp pháp không? Phụ thuộc vào quyền tài phán và hoàn cảnh, nhưng nó khá phổ biến. Về mặt đạo đức, tôi không có vấn đề gì với điều đó, với điều kiện bạn không chỉ đơn giản là cung cấp mã cho nhà tuyển dụng mới ... Đó là một lời nhắc nhở và chứng minh những gì bạn đã làm, thay vì tài nguyên miễn phí cho chủ lao động của bạn.

[Mặt trái của điều này là sự xấu hổ không thể tránh khỏi xuất hiện khi bạn nhìn vào mã cũ hơn: 'Tôi đã nghĩ gì ?? Tại sao trên trái đất đã làm tôi làm điều đó mà cách ?? ']

Đây là một ý tưởng rất xấu. Mã đó không thuộc về bạn (nói một cách hợp pháp) và việc sở hữu nó có thể khiến bạn gặp nhiều rắc rối. Điều này càng trở nên đúng hơn khi bạn chuyển sang một công việc mới và vẫn giữ mã nguồn đó xung quanh. Thậm chí tệ hơn nếu đó là một đối thủ cạnh tranh. Công ty của bạn sẽ không vui nếu bạn có quyền truy cập vào mã nguồn của họ khi bạn không làm việc cho họ nữa.

Đó là tất cả về việc quản lý rủi ro của bạn. Rõ ràng là bạn sẽ giữ lại những thứ từ một chủ nhân trước đây mà bạn có thể sử dụng ở một nơi khác. Đây là lý do tại sao họ đưa ra các điều khoản không cạnh tranh của bạn kéo dài X tháng / năm sau khi bạn rời khỏi chúng, tuy nhiên việc sở hữu mã này khiến bạn dễ bị ai đó cáo buộc bạn sao chép mã của công ty một cách trắng trợn (ngay cả khi bạn không, và chỉ sử dụng những ý tưởng tương tự). Là có mã giá trị quản lý rủi ro này?

Chắc chắn những thứ hữu ích bạn nhận được từ việc viết mã không phải là cú pháp chính xác; đó là kiến ​​thức bạn có được. Có lẽ không đáng để xử lý tất cả những thứ hợp pháp này.

Nó không phải là hiếm.

Tôi có một bản sao của gần ¹ mỗi đoạn mã tôi đã viết một cách chuyên nghiệp và chắc chắn tất cả các mã từ các dự án hiện tại của tôi, bất kể ai đã viết nó ² . Cùng với mã tôi có một đống giấy tờ pháp lý khổng lồ xác định rõ ràng những gì tôi có thể và không thể làm với nó. Chỉ cần có mã không giống như cố gắng kiếm lợi từ mã.

Điều đó nói rằng, đó là một vấn đề pháp lý và các vấn đề pháp lý có xu hướng cực kỳ phức tạp và cục bộ. Nếu nghi ngờ, bạn thực sự cần nói chuyện với một luật sư. Tôi có thể giữ mã của mình xung quanh, nhưng tôi chắc chắn 99% tôi sẽ không gặp rắc rối khi làm như vậy.

_{¹ Cái còn thiếu chủ yếu là những gì tôi không quan tâm để lưu trữ. Chỉ thiếu một mã của dự án nhỏ vì lý do pháp lý.
² Bản chất của các dự án và vai trò của tôi đối với chúng, tôi là một trong những người cần có ít nhất một ý tưởng về những gì sẽ đi đến đâu, ngay cả khi tôi không tham gia xây dựng một mô-đun cụ thể.}

Tôi thấy người đàn ông Trung Quốc bị bắt của bạn và nuôi bạn với "mã không phải là tài sản, do đó không thể bị đánh cắp".

Tham chiếu: Mã 'không phải tài sản vật chất', các quy tắc của tòa án trong vụ án gián điệp của Goldman Sachs

Với những gì đã nói.

• Tôi có giữ mã tôi viết không? Chắc chắn rồi.
• Tôi có giữ các dự án đầy đủ không? Chắc chắn rồi.
• Tôi có chắc chắn rằng ngón tay cái của tôi lái mã từ máy tính làm việc của tôi vào máy gia đình không? Bạn betcha!
• Tôi có bao giờ sử dụng lại mã đó ở một công ty khác hoặc trong một dự án cá nhân. Không.
• Tôi có thường nhìn vào mã cũ và đi WtF!? Tất cả thời gian.

Đây là một câu hỏi đơn giản cho bạn. Hãy đến gặp sếp của bạn và nói với họ: "Tôi có một bản sao của tất cả các mã tôi đã viết khi tôi làm việc ở đây. Chỉ có mã tôi đã viết chứ không phải các dân tộc khác. Đây là cho giáo dục của riêng tôi, và tôi sẽ không bao giờ đưa ra".

Hành động tiếp theo của họ sẽ ra lệnh (vâng, từ đó tồn tại ở Bắc Mỹ / Thế giới) nếu bạn sai hoặc đúng trong mắt họ.

Bất kể "đạo đức" của riêng bạn, bạn làm việc cho một chủ nhân. Nếu họ cho rằng những gì bạn đang làm là sai, thì đó là sai dựa trên đạo đức của họ. Khi họ trả tiền cho bạn và bạn được họ thuê, thì tại tòa án của bạn phải đồng ý với họ hoặc không đồng ý, điều đó có thể khiến bạn bị sa thải.

Bây giờ là một câu hỏi về tính toàn vẹn. Tôi đã để một nhân viên trước lấy một số mã của chúng tôi, nhưng tôi đã xem xét tất cả mã đó trước.

Chỉ vì bạn tin rằng bạn đúng, không làm cho bạn đúng. Thông thường các nhà phát triển phần mềm ký hợp đồng khi họ được tuyển dụng. Nếu bạn đã ký một, bạn cần phải sống theo lời của bạn.

có phải là không phổ biến cho các nhà phát triển để giữ một bản sao cá nhân của mã họ đã viết

Trả lời câu hỏi trực tiếp, tôi sẽ nói theo kinh nghiệm của tôi, điều này là không phổ biến. Các ngoại lệ này mà tôi đã thấy là những người làm rất nhiều nghề tự do và họ giữ mã trên tay cho các dự án bảo trì và nâng cao trong tương lai khách hàng của họ, và tôi sẽ tưởng tượng rằng điều này được nêu rõ trong hợp đồng (mặc dù tôi không phải là trong thói quen xem xét các hợp đồng tự do của bạn bè tôi, vậy ai biết được). Những người tôi biết, những người làm việc trong các công ty lớn hơn chưa bao giờ thừa nhận giữ mã từ các nhà tuyển dụng cũ.

Tôi biết tôi sẽ không vì tôi không thể nghĩ đến một tình huống duy nhất sẽ hữu ích (không kể rằng tôi khá chắc chắn rằng chủ nhân hiện tại của tôi cấm những điều đó - tôi chỉ cần tìm tài liệu để chắc chắn ). Mã tôi đã viết / đã sửa thường rất cụ thể đối với một yêu cầu kinh doanh cụ thể mà tôi không thể tưởng tượng được nó sẽ xuất hiện trở lại trong tương lai theo cách dễ sử dụng lại mã cũ hơn là viết mới mã.

Trước đây, thông thường các nhà phát triển có thư viện thói quen cá nhân mà họ sẽ sử dụng để giải quyết các vấn đề trong công việc hiện tại. Nguồn sẽ ở lại phía sau khi nhà phát triển rời đi, nhưng bất kỳ cải tiến nào cũng đi với anh ta.

Điều này dẫn đến một tình huống đôi bên cùng có lợi Nó cũng chỉ là một tập hợp con của tất cả các mã được viết.

Tất nhiên hầu hết những gì trong thư viện cá nhân sẽ có trong các thư viện tiêu chuẩn ngày nay.

Theo quan hệ chủ lao động với nhân viên ở hầu hết các vùng của Bắc Mỹ, việc chuyển hoặc truyền tài liệu kỹ thuật số (tức là mã nguồn) từ thiết bị của chủ nhân của bạn mà không có sự cho phép trước của chủ lao động là bất hợp pháp.

Một phần của luật pháp liên quan đến định nghĩa của nhân viên tại nơi làm việc, là mô tả rằng nhân viên không cung cấp thiết bị làm việc của riêng họ trừ khi có quy định khác trong hợp đồng nhân viên, ngoại trừ các giao dịch yêu cầu nhân viên mua hàng thiết bị riêng của họ (tức là công nhân xây dựng).

Hầu hết các luật về việc làm ở Bắc Mỹ định nghĩa người sử dụng lao động là người chấp nhận rủi ro chính trong mối quan hệ giữa người lao động với người sử dụng lao động. Nhân viên được trả tiền cho thời gian của mình trong khi người sử dụng lao động cung cấp vật liệu, thiết bị và kiểm soát các hoạt động liên quan đến công việc của nhân viên.

Tại thời điểm nào trong mối quan hệ này, việc đánh cắp tài liệu có giá trị từ chủ lao động, người đã trả tiền và chấp nhận rủi ro khi nói rằng tài liệu được tạo ra có ổn không?

Vấn đề chính với vấn đề này là câu hỏi "mã nguồn mà bạn đã viết?". Không thưa ngài, không phải là người đã viết nó. Dưới sự hướng dẫn của chủ nhân của bạn, chính họ là người đã viết nó. Bạn chỉ là người làm thuê đã gõ nó ra. Không có tòa án ở Bắc Mỹ sẽ đứng về phía bạn nếu chủ nhân của bạn thực hiện các hành động pháp lý để bảo đảm tài sản của họ. Chỉ cần sao chép mã nguồn vào ổ USB có thể đưa bạn vào nước nóng.

Như đã nói, nếu chủ lao động cho phép bạn sử dụng thiết bị của riêng bạn (ví dụ: máy tính xách tay) hoặc truyền tài liệu, thì đó là một vấn đề khác. Chủ lao động phải thông báo cho bạn khi chấm dứt rằng bất kỳ tài liệu nào sẽ được trả lại / tiêu hủy.

Chỉ cần nghĩ rằng tôi sẽ đăng câu trả lời này, vì có vẻ như một số người nghĩ rằng đây là một khu vực màu xám. Tôi thực sự không nghĩ rằng nếu bạn là một nhà phát triển, bạn nên truy cập Internet để đăng các tài liệu của nhà tuyển dụng. Ý tôi là, bạn rõ ràng đã biết câu trả lời cho câu hỏi này vì bạn đã tạo một tài khoản thành viên mới chỉ để đặt câu hỏi này. ;)

Tôi đã làm điều này trong một vài công việc trước đây.

Tuy nhiên tôi chưa bao giờ quay lại và nhìn nó. Thỉnh thoảng tôi đã sử dụng lại những ý tưởng và những điều tôi học được nhưng tôi chưa một lần tìm thấy lý do để quay lại và xem mã.

Vì vậy, tôi sẽ không làm phiền nữa. Đó là sự nghi ngờ về mặt pháp lý và tôi chưa bao giờ thực sự thấy nó hữu ích trong thực tế.

Chắc chắn rồi. Tôi muốn giữ một bản sao của tất cả các công việc tôi làm - cho dù đó là viết mã hay không. Gọi nó là một sổ lưu niệm, nếu bạn thích. Phá vỡ các quy tắc? Có lẽ.

Các ý kiến ​​về lợi thế cạnh tranh là không liên quan trừ khi nhà tuyển dụng tiếp theo của bạn là đối thủ cạnh tranh trực tiếp. Nếu bạn chuyển từ một công ty điện thoại sang một nhà phần mềm hoặc từ một nhà phát triển trò chơi sang một nhà phát triển cơ sở dữ liệu, điều đó không thành vấn đề. Nếu bạn thực sự có kế hoạch sử dụng lại mã - tốt, đó là một câu chuyện khác.

Thật thú vị, bạn thường nghe về các nhà phát triển web mang theo "hộp công cụ" với họ, với một bộ thư viện JavaScript và biểu định kiểu CSS tiêu chuẩn . Nhưng tôi chưa thấy điều đó được đề cập ở đây.

Tôi vừa mới xóa tất cả các mã cũ tôi giữ từ chủ nhân trước đây của tôi. Tôi chỉ giữ những đoạn mã mà tôi nghĩ là tốt để tham khảo trong tương lai. Tôi thực sự thấy rằng tôi đã di chuyển đáng kể từ khi tôi rời đi và tôi chưa bao giờ đề cập đến mã cũ. Tôi đã tìm thấy / phát hiện / học được nhiều cách tốt hơn để giải quyết các vấn đề tương tự.

Đó là một chuyến đi nhỏ xuống làn đường bộ nhớ mặc dù :)

Tôi nghĩ rằng cần phải có sự phân biệt giữa mẫu thiết kế và mã thực tế (sao chép từng dòng một)

Viết ra một số psuedocode giống như - đây là một cách tuyệt vời để lười tải X trong Y là một chuyện. Viết ra tất cả các mã là một cái gì đó khác.

Với sự cho phép của chủ nhân của bạn, hãy xuất bản mã có thể sử dụng lại gọn gàng dưới dạng các dự án nguồn mở để người khác sử dụng. Sau đó, chủ nhân của bạn cũng có thể được hưởng lợi từ sự đóng góp của những người khác vào mã này.

Bằng cách này, bạn có thể giữ mã hợp pháp, xây dựng danh mục mã công khai mà bạn đã viết và mã có thể mang lại lợi ích cho người khác.

Vì một số lý do khác nhau, như làm việc tại nhà, bạn cũng có thể đã có một bản sao và tôi sẽ không xóa những thứ này sau khi làm việc, tại sao lại làm như vậy? Nó không đi ngược lại niềm tin của tôi hoặc một cái gì đó.

Nhưng, liên quan đến việc sử dụng nó, nó không hữu ích như một bài viết trên blog!

Điểm mấu chốt: viết mã của bạn, viết blog về các vấn đề bạn gặp phải và cách bạn giải quyết chúng (đặc biệt là khi đó là công cụ chung và rộng) và đừng bận tâm đến việc lưu giữ (có thể được mã hóa) từ công việc cuối cùng.

Trong tài chính, CFA giải quyết vấn đề này. Bạn không được phép lấy thông tin liên quan đến khách hàng hoặc công việc của bạn cho công ty (trong trường hợp này là mã). Nhưng không có gì ngăn cản bạn ghi nhớ những gì bạn có thể và sau đó viết nó xuống.

Không chắc nó hợp pháp đến mức nào, nhưng tôi nghĩ rằng cách tốt nhất của bạn là để lại mã nguồn của bạn nhưng viết ra ý tưởng của bạn và cách bạn đã làm nó ngay khi bạn về nhà. Ăn cắp là ăn cắp và tại tòa tất cả những gì họ đang cố gắng tìm hiểu để quyết định là bạn có sao chép mã hay không.

Nếu bạn đang lưu mã của mình với mục tiêu sử dụng lại mã sau, tôi có hai vấn đề với điều đó:

• Nếu mã là tên miền cụ thể, nó có thể là độc quyền. Dù sao, không có hai doanh nghiệp hoặc vấn đề hoàn toàn giống nhau và cố gắng khắc phục một vấn đề với giải pháp cho một vấn đề khác không phải là một mô hình tốt.

• Nếu mã bạn đang lưu giải quyết một vấn đề phổ biến, bạn nên đặt câu hỏi cho phương pháp của mình. Tại sao bạn lại dành nhiều nỗ lực để giải quyết một vấn đề phổ biến khi chúng có khả năng là các giải pháp nguồn mở hiện có (và tốt hơn)?

  Nếu bạn tin rằng bạn có giải pháp tốt nhất cho một vấn đề phổ biến, bạn thực sự nên cố gắng chia sẻ mã công khai trên kho lưu trữ công cộng và / hoặc blog mã khi bạn viết nó, không giữ nó cho riêng bạn. Sếp của bạn không nên phản đối việc chia sẻ một thư viện chung chung hoặc buộc bạn phải phát minh lại bánh xe (nếu có, hãy tìm một công việc mới).

Nếu bạn đang lưu mã của mình vì bạn muốn hiển thị nó cho một nhà tuyển dụng tiềm năng hoặc để cải thiện kỹ năng của bạn, tôi khuyên bạn nên đóng góp cho một dự án nguồn mở thay thế.

Tôi chưa giữ bất kỳ mã nào tôi đã làm cho nhà tuyển dụng. Công cụ tự do mà tôi đã giữ (có thể khó hỗ trợ khách hàng nếu tôi mất mã).

Tuy nhiên, tôi đang xem xét việc giữ mã mà tôi đã tạo cho nhà tuyển dụng này. Lý do là tôi là một nhà phát triển web và tôi đã phát triển rất nhiều thứ ở phía khách hàng trông khá đẹp. Tôi đã không thiết kế chúng, nhưng tôi đã thực hiện chúng và thường nảy ra ý tưởng. Tôi muốn giữ một bản sao của công cụ này để xây dựng một danh mục đầu tư trực tuyến. Như chúng ta đều biết, các trang web không tồn tại mãi mãi, vì vậy tôi không thể thực sự tin tưởng vào công việc của mình khi trực tuyến. Có một bản sao lưu sẽ cho phép tôi có một danh mục đầu tư trực tuyến.

Tôi biết rằng các nhà thiết kế thường giữ các bản sao công việc của họ (ngay cả khi đó là công việc cho thuê) cho mục đích danh mục đầu tư.

Tôi không chắc tính hợp pháp của việc này là gì (nó không được đề cập rõ ràng trong hợp đồng của tôi).

Chà, để phát triển logic kinh doanh cho công ty của tôi, tôi không thể giữ mã vì đó là tài sản cá nhân và bất hợp pháp của công ty. Là nhà phát triển, tôi biết cách phát triển logic đó, vì vậy tôi có thể giữ logic đó trong tâm trí. Về cơ bản theo mặc định, nó được lưu trữ trong tâm trí của bạn và nếu bạn cần nó vào lần tới, thì tự động bạn nên thực hiện logic / logic tốt hơn so với trước đó. Đó là bản chất và trí thông minh của con người. :)

Nhưng vấn đề tạo ra khi bạn phát triển một số logic tiện ích, chúng có thể tái sử dụng và luôn luôn quan trọng, bạn có thể cần nó thường xuyên trong các dự án khác nhau. Vì vậy, bạn nên muốn giữ nó với bạn.

Tôi có một giải pháp thay thế cho điều đó. Chỉ cần tạo JAR không có nguồn / tài liệu cho người sử dụng và thêm nó dưới dạng JAR của bên thứ ba bên ngoài trong dự án của bạn. Có lẽ bằng cách này, bạn có thể xác nhận trách nhiệm cũng như sự hài lòng của bản thân rằng bạn có mã ;)

Tôi không giữ mã vì một lý do đơn giản: Công ty trả tiền cho tôi để viết mã cho họ. Tôi đưa cho họ mã số của họ, và họ đưa cho tôi tiền lương của tôi. Anh chàng làm bữa trưa cho tôi, không thể giữ một phần cho riêng mình, tại sao mã lại khác?

Ngoài ra, vấn đề được đưa ra trước đây, tôi đã nghỉ việc, tất cả những vấn đề đau đầu vẫn ở đó, công việc mới, khởi đầu mới, nhưng với một chút kinh nghiệm và hiểu biết về các loại vấn đề trong lĩnh vực công việc cũ đó.