Czy powinieneś zachować kopię całego kodu, który piszesz? [Zamknięte]

197

Wiem, że firma, dla której pracujesz, jest właścicielem kodu i oczywiście zostaniesz aresztowany, jeśli spróbujesz go sprzedać. Ale czy programiści często przechowują osobistą kopię napisanego przez siebie kodu (do wglądu w przyszłości)?

Najwyraźniej ten facet został wysłany do więzienia za kopiowanie kodu źródłowego.

superFoo
źródło
13
może to być poważny problem prawny, jeśli w jakiś sposób sprzedasz / wykorzystasz go firmie konkurencyjnej.
EL Yusubov,
19
Zauważ, że w powiązanym artykule jest to dość konkretny przypadek, ponieważ odszedł z kodem, który najprawdopodobniej został objęty przez NDA (biorąc pod uwagę klienta), a nawet jeśli nie, nie jestem pewien, czy zaryzykuję odejść z kodem, który został opracowany dla cholernego Banku Rezerw Federalnych ! Nie musi mieć to wszystko tam, jeśli myślisz, że nic nie może pójść źle z tym i że nie będzie co najmniej kilka wpływowych ludzi, którzy nie chcieliby ten pomysł w ogóle , jeśli kiedykolwiek słyszał Wziąłeś kod z wami .
haylem
10
Zakładając, że była to praca najemna, a zatem twój były pracodawca jest właścicielem praw autorskich do kodu, który dla nich napisałeś i nie udostępnił go jako open source, powiedziałbym, że przechowywanie kopii napisanego przez ciebie kodu jest tak samo nieodpowiednie, jak przechowywanie kopie kodu napisanego przez współpracowników.
Keith Thompson,
37
@DavidPeterman - dlaczego pracodawca, który cię zatrudnił, nie miałby wszystkiego, co dla nich robisz? Czy uważasz, że część twojego domu należy do stolarza, który wykonał obramowanie?
Reactgular
10
@MathewFoscarini Rozumiem, co mówisz, ale mówię o algorytmach. To tak, jakby powiedzieć, że cieśla nie jest właścicielem kroków, które podejmuje, aby zbudować dom
David Peterman

Odpowiedzi:

303

Ale czy programiści często przechowują osobistą kopię napisanego przez siebie kodu (do wglądu w przyszłości)?

Nie wiem, jak często to jest, ale często czy nie, to wciąż zły pomysł.

Programiści często działają w myśleniu, że dwukrotne rozwiązanie tego samego problemu to strata czasu. Staramy się zaprojektować nasz kod tak, aby nadawał się do ponownego użycia (czasami). Budujemy biblioteki klas i funkcji do ponownego wykorzystania w pewnym momencie w przyszłości. Czasami wręczamy nasz kod, aby nikt inny nie musiał pisać kodu, aby rozwiązać ten sam problem, który właśnie zrobiliśmy. Dlatego może być zrozumiałe, że chcesz zabrać ze sobą „swój” kod podczas przechodzenia z jednego zadania do drugiego. Ale nadal nie powinieneś tego robić z następujących powodów:

  1. To nie jest twój kod do wzięcia.

  2. Kod napisany dla byłego pracodawcy jest częścią firmy, którą zbudowali. Ich kod stanowi część ich przewagi konkurencyjnej. Oczywiście konkurenci mogą napisać własny kod, aby rozwiązać ten sam problem, ale nie powinni czerpać korzyści z budowania pracy, za którą pracodawca zapłacił, jest właścicielem i nie upoważnił Cię do podjęcia pracy.

  3. Jeśli mają jakiś sens, twój nowy pracodawca nie chce żadnej części kodu, którą wziąłeś od swojego byłego pracodawcy. Im częściej „polecasz” pracę wykonaną dla poprzedniego pracodawcy, tym bardziej narażasz nowego pracodawcę na prawne niebezpieczeństwo.

  4. Jeśli kiedykolwiek przypadkowo pozwolisz, aby ujawniło się u Nowego Pracodawcy, że nadal masz kopię rzeczy, które zrobiłeś dla Starego Pracodawcy, Twój szef w New prawdopodobnie zrozumie, że weźmiesz kopię ich kodu, kiedy odejdziesz do innego praca. To może nie pasować do niego.

  5. Nawet jeśli nie przeklinasz faktycznych wierszy lub po prostu niejasnych pomysłów ze swoich starych rzeczy, po prostu posiadanie starych rzeczy w posiadaniu może budzić podejrzenia, że ​​możesz to wykorzystać do czegoś. Wyobraź sobie, że Stary Pracodawca pozywa Nowego Pracodawcę i jako jeden z niewielu pracowników, którzy przenieśli się ze Starego do Nowego, nagle składasz zeznanie. Nikt z was tak naprawdę nie skopiował kodu Olda do produktu New, ale prawnik przed tobą pyta: „Panie SuperFoo, czy ty teraz lub masz go w dowolnym momencie od czasu opuszczenia Old Employer, miałeś w posiadaniu kopię dowolnego kodu, który ty lub ktoś jeszcze napisał podczas pracy w Old Employer? ”

  6. Nie potrzebujesz kodu, który napisałeś w zeszłym miesiącu, w zeszłym roku lub dłużej. Rozwiązałeś problem raz i teraz wiesz, jak rozwiązać problem ponownie. Lub możesz wiedzieć, jak nie rozwiązać problemu - nowa implementacja będzie lepsza, ponieważ masz doświadczenie.

  7. Istnieją lepsze sposoby. Trudno jest wrócić i nauczyć się czegoś przydatnego, odczytując stary kod z kontekstu. Dziennik lub dziennik opisujący to, czego się uczysz, pomysły, które posiadasz itp., Jest o wiele bardziej użyteczny w przyszłości.

  8. Nawet jeśli Stary Pracodawca wie, że masz ich kod i nie przeszkadza ci to, nadal go nie chcesz! Jedyne, co może się z tym wiązać, to telefon o 3 nad ranem: „Hej, SuperFoo? Jak się masz? Słuchaj, masz kopię naszych rzeczy, prawda? Słuchaj, mamy problem z i zawęziliśmy go do kilku plików, które napisałeś, których nasz nowy facet po prostu nie rozumie. Wiem, że jest późno, ale czy mógłbyś poprowadzić go przez SuperDuper.pl? ”

Odpuść sobie. Nie potrzebujesz tego.

Caleb
źródło
7
Co więcej, jeśli media, na których trzymasz zawartość, zostaną zgubione lub skradzione, będzie to bardzo problematyczne. Prawdę mówiąc, wolę unikać jakichkolwiek połączeń VPN lub źródeł na moich komputerach osobistych, jeśli to w ogóle możliwe. Twój komputer może być częścią botnetu, nawet nie wiedząc, po co ryzykować?
Koder
8
Doskonała odpowiedź! Po opuszczeniu mojego starego pracodawcy zaoferowano mi kopię kodu (lub ciągły dostęp). Odmówiłem, właśnie z powodów zbliżonych do liczby 8. W końcu był powód do rezygnacji z nich. Gdybym nadal chciał je rozwidlać,
zostałbym
79
+1: Nie potrzebujesz go Trudną częścią jest zastanawianie się, co napisać, a nie pisanie tego. Jeśli napiszesz to po raz drugi, prawdopodobnie będzie jeszcze lepiej.
kevin cline
6
Kiedy rozwiązuję problem z moim kodem, zwykle wypisuję rozwiązanie na blogu. Nie kod źródłowy z mojej pracy, ale kod ogólny zgodny z tym samym wzorcem (prosta jedna linia lub kilka linii do osiągnięcia celu - nie behemoty kodu). Uważam, że jest to świetna metoda przechowywania tego, czego nauczyłem się podczas poprzednich prac. +1 za punkt # 7!
Gaʀʀʏ
11
Czy nie powinien istnieć jakiś próg dla ilości kwalifikującego się kodu? Jeśli for (int i=0; i < N; ++i)
użyję
159

Zawsze przechowuję kopię kodu, który piszę i przenoszę go między zadaniami. Kolejni pracodawcy nigdy nie widzą / nie uruchamiają kodu, ale używam go jako referencji w domu: „Ach tak, czy nie zrobiłem czegoś podobnego do tego w Projekcie X?”.

Czy to jest legalne? Zależy od jurysdykcji i okoliczności, ale jest to dość powszechne. Moralnie nie mam z tym problemu, pod warunkiem, że nie dajesz kodu nowym pracodawcom ... To przypomnienie i pokaz tego, co zrobiłeś, a nie bezpłatne zasoby dla twojego pracodawcy.

[Druga strona to nieunikniony wstyd, który pojawia się, gdy spojrzysz na starszy kod: „Co ja sobie myślałem? Dlaczego, u licha, zrobiłem to w ten sposób? ']

cjmUK
źródło
35
+1 I nie ma nawet znaczenia, czy jest to legalne. Mimo to wielu z nas to robi. Nie szkodzi to twojemu poprzedniemu pracodawcy (nie sprzedajesz kodu konkurentowi) i i tak nie można go regulować. W pewnym sensie, jeśli „pamiętasz”, jak rozwiązałeś problem dla poprzedniego pracodawcy, „kradniesz” dla nich ten sekret - w sposób, którego nie można regulować, dopóki nie wymyślą kontroli umysłu;)
Andres F.
89
@AndresF. To tylko racjonalizacja. Kod jest własnością twojego starego pracodawcy, twoje wspomnienia nie są. Jeśli pamiętasz, jak rozwiązałeś problem, nie potrzebujesz kodu, więc po co go brać?
Caleb
10
+1 za przedstawienie argumentu moralnego. Osobiście śledzę to, głównie dlatego, że większość mojego kodu nie jest specyficzna dla domeny. Pamiętam, jak coś rozwiązałem, ale niekoniecznie niuanse tego.
Telastyn
46
W przypadku oskarżenia firmy o kradzież adresu IP, posiadanie kopii kodu będzie działało jako duży czynnik obciążający przeciwko tobie. Pamięć o tym nie jest. To jest różnica.
Oleksi
13
@Caleb Bez względu na to, wielu programistów bierze fragmenty kodu po ich odejściu. Jest to całkowicie oddzielne działanie od używania tego kodu do konkurowania ze starym pracodawcą lub krzywdzenia go, i zwykle jest traktowane jako odniesienie, jak w „jak do diabła wcześniej rozwiązałem ten problem / skonfigurowałem to oprogramowanie? chcesz, ale wciąż jest to powszechna praktyka, która nikogo nie krzywdzi. Możesz zakopać głowy w piasku lub twierdzić, że to źle, ale nadal tak się dzieje. Zwłaszcza w przypadku outsourcingu / offshoringu - jeśli uważasz, że tak nie jest zdarzają się niespodzianki!
Andres F.,
51

To bardzo zły pomysł. Ten kod nie należy do ciebie (prawnie mówiąc), a posiadanie go może sprawić ci wiele kłopotów. Staje się to jeszcze bardziej prawdziwe, kiedy przenosisz się do nowej pracy i nadal trzymasz ten kod źródłowy w pobliżu. Gorzej, jeśli jest to konkurent. Twoja firma nie byłaby zadowolona, ​​gdybyś miał dostęp do kodu źródłowego, gdy już dla nich nie pracujesz.

Chodzi o zarządzanie ryzykiem. Oczywiście oczekuje się, że zatrzymasz rzeczy poprzedniego pracodawcy, których możesz użyć gdzie indziej. Właśnie dlatego sprawiają, że Twój znak zakazuje konkurowania przez ostatnie X miesięcy / lat po ich opuszczeniu, jednak posiadanie kodu sprawia, że ​​jesteś bardziej narażony na oskarżenia o rażące kopiowanie kodu firmy (nawet jeśli tego nie zrobiłeś, i użyłem tych samych pomysłów). Czy posiadanie kodu jest warte zarządzania tym ryzykiem?

Z pewnością użyteczne rzeczy, które otrzymałeś po napisaniu kodu, nie są dokładną składnią; to wiedza, którą zdobyłeś. Prawdopodobnie nie warto zajmować się tymi wszystkimi legalnymi sprawami.

Oleksi
źródło
9
To nie jest zły pomysł, chyba że w twoim biurze są ścisłe kontrole bezpieczeństwa (takie jak nie zezwalanie na pocztę e-mail i pendrivy). Zresztą nikt nie będzie przeszukiwał twojego domowego komputera i zrozumiałe jest, że programiści zabierają wiedzę z poprzednich prac. Nie można temu zapobiec i byłoby to nierozsądne, niezależnie od tego, czy kod zostanie „zapamiętany”, czy skopiowany dosłownie. Co można zrobić jako pracodawcy jest egzekwować żadnych klauzul konkurować lub NDAS lub cokolwiek mechanizm prawny jest dostępny w Twoim kraju.
Andres F.,
14
@Malfist Nie, ty nie. IANAL, ale dość dobrze ustalono, że przynajmniej w Stanach Zjednoczonych produkty pracy, które ktoś płaci za tworzenie, są ich własnością, a nie twoją. Zobacz pracę do wynajęcia w Wikipedii.
Caleb,
5
@Malfist Again, no. Zobacz link w moim poprzednim komentarzu.
Caleb
4
@Malfist: „jeśli jesteś jedynym programistą i nie zmusili Cię do rezygnacji z praw autorskich, możesz zabrać kod ze sobą, gdy odchodzisz (zawsze tak robię)”. Nie jestem jednak pewien, czy Twoje umowy odzwierciedlają większość rzeczywistości. Większość umów na wynajem oprogramowania wyraźnie mówi, że musisz dostarczyć wszystkie źródła i pliki binarne oraz przekazać im własność i prawa autorskie. Co jest dość normalne dla freelancerów. Możesz to negocjować, ale spodziewam się, że w umowach będą to praktycznie klauzule de facto (zarówno w przypadku umów wewnętrznych, jak i zewnętrznych).
haylem
5
Rozważmy hipotetycznie dewelopera, który pamięta dowolny wiersz napisany podczas swojej kariery. Czy byłoby nielegalne, gdyby używał tej pamięci podczas pracy nad przyszłymi projektami? Dlaczego robisz rozróżnienie między zapamiętywaniem kodu a zapisywaniem jego kopii na prywatnym dysku HD? Jeśli możesz wziąć przykład z własnego doświadczenia, powinieneś być, nawet jeśli jest zapisany w twoim notatniku, zamiast być przechowywany w mózgu. A jeśli nie możesz ponownie odczytać starego kodu, który zapisałeś na komputerze, to nie powinieneś mieć możliwości „przypomnienia”, co oczywiście nie ma sensu.
Nadir Sampaoli
36

To nie jest rzadkie.

Mam kopię prawie 1 każdego kodu, który napisałem profesjonalnie, a na pewno cały kod z moich bieżących projektów, niezależnie od tego, kto go napisał 2 . Wraz z kodem mam ogromną stertę legalnej dokumentacji, która jasno określa, co mogę, a czego nie mogę z tym zrobić. Sam kod nie jest tym samym, co próba czerpania z niego korzyści.

To powiedziawszy, jest to kwestia prawna, a kwestie prawne są zwykle bardzo skomplikowane i zlokalizowane. W razie wątpliwości naprawdę musisz porozmawiać z prawnikiem. Mogę zachować swój kod, ale jestem w 99% pewien, że nie będę miał z tego powodu kłopotów.

1 Brakuje przede wszystkim tego, czego nie chciałem zarchiwizować. Z powodów prawnych brakuje tylko jednego kodu małego projektu.
2 Charakter projektów i moja rola w nich, jestem jednym z facetów, którzy muszą mieć przynajmniej pojęcie o tym, co się dzieje, nawet jeśli nie byłem zaangażowany w budowę konkretnego modułu.

Yannis Rizos
źródło
4
@haylem Nigdy nie jestem w siedzibie firmy;)
yannis
3
ale jestem pewien, że wiesz, co miałem na myśli, i że prawdopodobnie nie ma to większego znaczenia, gdzie jesteś fizycznie :)
haylem
3
Słyszałem, jak jeden programista przemawiał na konferencji WordPress, a on powiedział coś w stylu „Jeśli wykonuję dla ciebie pracę kontraktową, upewniam się, że wiesz, że jesteś właścicielem kodu, który piszę dla ciebie, ale to nie znaczy, że niczego się nie nauczyłem nowy, pisząc kod ”.
programista
3
@Caleb Posiadanie odpowiedniej dokumentacji może być rzadkie (nie wiem), jednak nie sądzę, aby trzymanie kopii kodu było. Tak się
składa,
2
@Krelp, klucze szyfrujące, takie jak klucze do sejfów, można wymusić za pośrednictwem wezwania do sądu.
Malfist,
29

Widzę twojego aresztowanego Chińczyka i wychowuję cię „kodem nie jest własność, dlatego nie można go ukraść”.

Ref .: Kod „nie własność fizyczna”, zasady sądowe w sprawie szpiegowskiej Goldman Sachs

To powiedziawszy.

  • Czy zachowuję kod, który piszę? Absolutnie.
  • Czy mam pełne projekty? Absolutnie.
  • Czy upewniam się, że przekierowuję mój kod z komputera roboczego na komputer domowy? Betcha!
  • Czy kiedykolwiek ponownie używam tego kodu w innej firmie lub w osobistym projekcie? Nie.
  • Czy często patrzę na stary kod i używam wtF !? Cały czas.
TimSonOfSteve
źródło
14
+1 Hehe, ładna, szczera odpowiedź. Najlepsze jest to, że tak naprawdę nigdy nie wracasz do starego kodu. Po prostu czujesz się bezpieczniej, jeśli weźmiesz go ze sobą, aby nigdy więcej na niego nie patrzeć!
Andres F.
Czy nie był to również poważny problem w niedawnej sprawie Oracle przeciwko Google?
robertc
1
Zupełnie się z Tobą zgadzam. Robię to samo. To bardzo dobra referencja.
Andrea Girardi
2
kod nie jest własnością, dlatego nie można go ukraść, to okropne podsumowanie sprawy Goldmana Sachsa. Rosjanin został uniewinniony, nie dlatego, że nie zrobił nic złego, ale dlatego, że jego kradzież nie kwalifikowała się zgodnie z prawem, prokurator próbował użyć przeciwko niemu. To nie znaczyło, że nie naruszył umowy z GS ani nie narusza praw własności intelektualnej. Przeczytaj artykuł uważniej i być może zapoznaj się z poniższymi komentarzami.
Nate
Powiązany artykuł: Czy Goldman Sachs przekroczył granice, obciążając swojego byłego programistę? . To także dobry przykład, że nawet jeśli wygrasz w końcu, sama legalna bitwa może bardzo zaszkodzić.
CodesInChaos
10

Oto proste pytanie dla Ciebie. Idź do swojego szefa i powiedz: „Mam kopię całego kodu, który napisałem podczas pracy tutaj. Tylko kod, który napisałem, a nie innych ludzi. To jest dla mojej własnej edukacji i nigdy go nie wydam”.

Kolejne ich działania będą dyktować (tak, to słowo istnieje w Ameryce Północnej / Świecie), jeśli jesteś w błędzie lub w ich oczach.

Niezależnie od własnej „etyki” pracujesz dla pracodawcy. Jeśli uznają, że to, co robisz, jest złe, to jest złe na podstawie ich etyki. Gdy ci płacą, a ty jesteś przez nich zatrudniony, to do twojego sądu należy albo się z nimi zgodzić, albo nie zgodzić, co może cię zwolnić.

Teraz jest to kwestia uczciwości. Pozwoliłem, aby poprzedni pracownik zabrał część naszego kodu, ale najpierw wszystko sprawdziłem.

To, że uważasz, że masz rację, nie czyni cię po prawicy. Zazwyczaj programiści podpisują umowy, gdy są zatrudnieni. Jeśli go podpisałeś, musisz żyć zgodnie ze swoim słowem.

Ryan Ternier
źródło
„podczas gdy tu pracowałem” oznacza, że ​​dana osoba nie jest już twoim szefem. Jeśli to twój były szef, dlaczego miałbyś go zapytać?
Alexander
Dlaczego? Kontrakty? Integralność?
Ryan Ternier
Możesz zachować kod, który napisałeś, nie wykorzystując go do niczego, a jednocześnie jednocześnie przestrzegać umów i zachować integralność.
Alexander
2
Jeśli podpiszesz umowę, w której stwierdza się, że cały kod jest własnością pracodawcy, zabranie go do domu stanowi naruszenie tej umowy, jeśli nie będzie wiedział, że go posiadasz lub wyraził zgodę na jego posiadanie. To skutecznie kradzież. Tak, to „kod”, cyfrowe zera i jedynki, ale w większości przypadków jest czarno-biały.
Ryan Ternier
To klasyczna dyskusja „piractwo to kradzież”.
Alexander
8

czy programiści często przechowują osobistą kopię napisanego przez siebie kodu?

Odpowiadając bezpośrednio na pytanie, w moich doświadczeniach powiem, że jest to rzadkie. Wyjątkiem tego, że widziałem to ludzie, którzy robią dużo Freelancing i zachować kod na rękę dla przyszłych projektów konserwacji i poprawiania swoich klientów, i wyobrażam sobie, że jest to wyraźnie określone w umowie (choć nie jestem w nawyk recenzowania umów o wolnym handlu z moimi przyjaciółmi, więc kto wie). Znane mi osoby, które pracują w większych firmach, nigdy nie przyznały się do przechowywania kodu od byłych pracodawców.

Wiem, że nie zrobiłbym tego, ponieważ nie mogę wymyślić jednej sytuacji, w której byłby użyteczny (nie wspominając, że jestem prawie pewien, że mój obecny pracodawca zabrania takich rzeczy - musiałbym po prostu sprawdzić dokumenty, aby mieć pewność ). Kod, który napisałem / naprawiłem, jest zazwyczaj tak specyficzny dla konkretnego wymagania biznesowego, że nie wyobrażam sobie, aby kiedykolwiek pojawił się w przyszłości w taki sposób, że łatwiej byłoby ponownie użyć starego kodu niż napisać nowy kod.

FrustratedWithFormsDesigner
źródło
3
Jako freelancer będę trzymać cały kod w pobliżu. Ponowne użycie jest bardzo mało prawdopodobne, ale w końcu utrzymam go (na przykład, jeśli pracodawca zatrudni kogoś, kto spieprzy kod i zatrudni mnie ponownie, aby go naprawić).
Camilo Martin,
1
W moim freelancingu stwierdzam, że jest dużo kodu, który jest często ponownie wykorzystywany. Ile razy kończę pisanie tego samego kodu logowania użytkownika, zanim go ponownie użyję. Podczas gdy trzymam kod w celu konserwacji, wspólne obszary kodu są zwykle kopiowane. Jeśli znalazłem jakiś kod, który jest zasadniczo taki sam między dwoma projektami, tworzę jego kopię w formie uogólnionej i w razie potrzeby kopiuję ją do innych projektów.
Chris
8

W tamtych czasach programiści często mieli osobistą bibliotekę procedur, których mogliby używać do rozwiązywania problemów w bieżącej pracy. Źródło pozostanie w tyle, gdy programista odejdzie, ale wszelkie ulepszenia również poszły z nim.

Spowodowało to sytuację korzystną dla wszystkich. Był to również podzbiór całego napisanego kodu.

Oczywiście większość tego, co było w bibliotekach osobistych, znajdowałaby się dzisiaj w bibliotekach standardowych.

Jon Strayer
źródło
W niektórych środowiskach istnieje wyraźne rozgraniczenie między kodem biblioteki lub komponentu lub klasami jawnie zaprojektowanymi do ponownego użycia (parsery itp.) A tymi, które są specyficzne dla domeny problemowej. Kod, który jest specyficzny dla domeny problemowej (główna wbudowana aplikacja XWare lub jednostka komercyjna) może nie być przydatny poza tym miejscem, ale komponent / biblioteki niskiego poziomu lub biblioteki wielokrotnego użytku mogą być rzeczywiście bardzo przydatne.
Warren P,
6

W ramach relacji pracodawca-pracownik w większości części Ameryki Północnej nielegalne jest przesyłanie lub przesyłanie materiałów cyfrowych (tj. Kodu źródłowego) ze sprzętu pracodawcy bez uprzedniej prawnej zgody pracodawcy.

Częścią przepisów prawnych dotyczących definicji pracownika w miejscu pracy jest opis, że pracownik nie zapewnia własnego sprzętu roboczego, chyba że umowa o pracę stanowi inaczej, z wyjątkiem zawodów, które wymagają od pracownika zakupu własny sprzęt (np. pracownik budowlany).

Większość przepisów prawa pracy w Ameryce Północnej definiuje pracodawcę jako główny podmiot podejmujący ryzyko w relacji pracownik-pracodawca. Pracownik otrzymuje wynagrodzenie za swój czas, podczas gdy pracodawca zapewnia materiały, sprzęt i kontroluje czynności pracownika związane z pracą.

W jakim momencie podczas tej relacji okradzione jest kradzież cennego materiału od pracodawcy, który zapłacił i zaryzykował tworzenie tego materiału?

Kluczowym problemem było pytanie „kod źródłowy, który napisałeś?”. Nie, proszę pana, to nie ty to napisałeś. Pod kierunkiem twojego pracodawcy to oni go napisali. Jesteś tylko wynajętą ​​ręką, która ją napisała. W Ameryce Północnej nie ma sądu, który byłby po twojej stronie, gdyby Twój pracodawca podjął kroki prawne w celu zabezpieczenia ich własności. Wystarczy skopiować kod źródłowy na pamięć USB, aby dostać się do gorącej wody.

To powiedziawszy, jeśli pracodawca zezwolił ci na użycie własnego sprzętu (np. Laptopa) lub przesłanie materiału, to inna sprawa. Po zakończeniu pracodawca musi powiadomić cię, że wszelkie materiały powinny zostać zwrócone / zniszczone.

Pomyślałem, że opublikuję tę odpowiedź, ponieważ wygląda na to, że niektórzy sądzą, że to szara strefa. Naprawdę nie sądzę, jeśli jesteś programistą, że powinieneś chodzić po Internecie, że przechowujesz kopie materiałów pracodawcy. Mam na myśli, że już znałeś odpowiedź na to pytanie, ponieważ utworzyłeś nowe konto członkowskie, aby zadać to pytanie. ;)

Mathew Foscarini
źródło
Po zakończeniu pracodawca musi powiadomić Cię, że wszelkie materiały powinny zostać zwrócone / zniszczone. Czy to naprawdę prawda? Czy na pracodawcy ciąży prawny i / lub umowny obowiązek?
Radu Murzea
Pracodawca nie jest prawnie zobowiązany do tego, ale może w każdej chwili zażądać zwrotu wszelkich należących do nich materiałów od pracownika, chyba że istnieje umowa między pracodawcą a pracownikiem, która pozwala pracownikowi zachować te materiały.
Reactgular
5

Zrobiłem to w przeszłości kilka prac temu.

Jednak nigdy nie wróciłem i nie spojrzałem na to. Od czasu do czasu wykorzystywałem pomysły i rzeczy, których się nauczyłem, ale ani razu nie znalazłem powodu, aby wrócić i spojrzeć na kod.

Więc nie zawracałbym sobie głowy. Jest to prawnie wątpliwe i nigdy tak naprawdę nie przydało mi się w praktyce.

JohnB
źródło
4

Pewnie. Lubię przechowywać kopię całej mojej pracy - czy to pisania kodu, czy w inny sposób. Nazwij to notatnikiem, jeśli chcesz. Łamać zasady? Być może.

Komentarze na temat przewagi konkurencyjnej są nieistotne, chyba że twój następny pracodawca jest bezpośrednim konkurentem. Jeśli przeprowadzasz się z firmy telefonicznej do domu oprogramowania lub od twórcy gier do twórcy baz danych, nie ma to znaczenia. Jeśli planujesz ponownie użyć kodu - cóż, to inna historia.

Co ciekawe, często słyszysz o twórcach stron internetowych, którzy przynoszą ze sobą „zestaw narzędzi” ze standardowym zestawem bibliotek JavaScript i arkuszy stylów CSS . Ale nie widziałem tego wspomnianego tutaj.

Steve Bennett
źródło
3

Niedawno usunąłem cały stary kod, który zachowałem od mojego poprzedniego pracodawcy. Zachowałem tylko te fragmenty kodu, które moim zdaniem były dobre na przyszłość. Odkąd odszedłem, zauważyłem, że znacznie się zmieniłem i nigdy nie odwoływałem się do starego kodu. Znalazłem / odkryłem / nauczyłem się znacznie lepszych sposobów rozwiązywania tych samych problemów.

To była fajna wycieczka w dół linii pamięci :)

Antony Scott
źródło
2

Myślę, że należy wprowadzić rozróżnienie między wzorcem projektowym a rzeczywistym kodem (kopiowanie linia po linii)

Zapisanie jakiegoś psuedokodu w stylu - to świetny sposób na leniwe ładowanie X w Y to jedno. Zapisywanie całego kodu to coś innego.

PSU_Kardi
źródło
1

Za zgodą pracodawcy opublikuj czysty kod wielokrotnego użytku jako projekty typu open source, z których mogą korzystać inni ludzie. Wtedy twój pracodawca może również skorzystać ze składek innych osób na ten kod.

W ten sposób możesz zachować kod zgodnie z prawem, zbudować publiczne portfolio napisanego kodu, a kod może przynieść korzyści innym osobom.

Sarel Botha
źródło
1

Z różnych powodów, takich jak praca w domu, równie dobrze możesz mieć już kopię, a ja z jednej strony nie chciałbym ich usuwać po pracy, dlaczego to robisz? To nie jest sprzeczne z moimi przekonaniami ani czymś takim.

Ale jeśli chodzi o korzystanie z niego, nie jest on tak przydatny jak post na blogu!

Konkluzja: napisz swój kod, bloguj o problemach, które napotkałeś i jak je rozwiązałeś (szczególnie, gdy są to ogólne i szerokie rzeczy), i nie przejmuj się (prawdopodobnie zaszyfrowaną) pamiątką z ostatniej pracy.

Camilo Martin
źródło
1

W finansach CFA rozwiązuje ten problem. Nie wolno pobierać informacji związanych z klientami lub pracą dla firmy (w tym przypadku kodem). Ale nic nie stoi na przeszkodzie, aby zapamiętać, co możesz, a następnie zapisać to później.

Nie jestem pewien, czy to uzasadnione, ale myślę, że najlepiej jest zostawić kod źródłowy, ale zapisz swoje pomysły i jak to zrobiłeś, gdy tylko wrócisz do domu. Kradzież to kradzież i w sądzie starają się dowiedzieć, czy zdecydować, czy skopiowałeś kod, czy nie.

Peter Mortensen
źródło
Pamiętaj, że niektórzy pracodawcy dołożą wszelkich starań, aby powstrzymać cię od „zapisywania swoich pomysłów” po powrocie do domu. Scenariusz „przegrać” nie jest dla nich kopiowanym kodem, ale konkurencją przeciwko nim - i do tego pomysły są znacznie lepsze. Nie jestem pewien, czy jest to możliwe do wyegzekwowania, ale niektórzy próbują cię zastraszyć, że są właścicielami wszelkich pomysłów, które możesz mieć w godzinach pracy.
Andres F.,
1
@AndresF. Kiedyś pracowałem w funduszu hedgingowym, który próbował temu zapobiec. Szczerze mówiąc, nie mogli temu zapobiec, dlatego zmusili ludzi do podpisania umów o zakazie konkurencji i zapłacili za to, że nie będą pracować przez 1-2 lata po rezygnacji. Chociaż jest to bardzo kosztowne (płacisz 2 lata pensji komuś, kto nie pracuje dla ciebie), sprawia, że ​​twoja wiedza staje się nieaktualna, kiedy odchodzisz i bezużyteczna jako zagrożenie dla konkurencji.
Lostsoul
+1 tylko za pomysły, a nie kod. Był związany z firmą, która pozwała byłego programistę za kradzież kodu i sprzedaż podobnego produktu. Sędzia orzekł, że ponieważ błędy były identyczne, musiał ukraść kod.
jqa
Widziałem, że wielu pracodawców wymaga, aby nowy pracownik zgodził się na piśmie, że nie będą angażować się w inne działania biznesowe, dopóki są zatrudnieni przez pracodawcę, a wszelkie inne projekty, które pracownik wykonuje po stronie, są również własnością pracodawcy. Myślę, że ten temat sam w sobie jest zupełnie inną kwestią, ale umowy te występują w większości umów o pracę.
Reactgular
@MathewFoscarini Zgadzam się. W mojej firmie wymagamy od pracowników pisemnej zgody przed zaangażowaniem się w cokolwiek, z czego otrzymują korzyść (w tym projekty poboczne, działalność charytatywną itp.). Jeśli naprawisz samochód sąsiadów, a on kupi ci piwo, będzie to wysokiej jakości, chociaż pracownicy zdają sobie sprawę, że prawdopodobnie nie będziemy go ścigać.
Lostsoul
1

Jeśli zapisujesz kod w celu ponownego użycia go później, mam z tym dwa problemy:

  • Jeśli kod jest specyficzny dla domeny, prawdopodobnie jest również zastrzeżony. W każdym razie nie ma dwóch takich samych firm lub problemów, a próba rozwiązania jednego problemu za pomocą rozwiązania innego nie jest dobrym wzorcem.

  • Jeśli zapisywany kod rozwiązuje typowy problem, powinieneś zakwestionować swoje podejście. Dlaczego poświęcasz dużo wysiłku, aby rozwiązać typowy problem, gdy prawdopodobnie istnieją (i lepsze) rozwiązania open source?

    Jeśli uważasz, że masz najlepsze rozwiązanie typowego problemu, powinieneś naprawdę spróbować udostępnić swój kod publicznie w publicznym repozytorium i / lub blogu z kodem podczas pisania, a nie przechowywać go dla siebie. Twój szef nie powinien sprzeciwić się udostępnianiu ogólnej biblioteki ani zmusić cię do ponownego wynalezienia koła (jeśli to zrobi, znajdź nową pracę).

Jeśli zapisujesz swój kod, ponieważ chcesz pokazać go potencjalnemu pracodawcy lub poprawić swoje umiejętności, sugeruję, abyś zamiast tego wziął udział w projekcie open source.

David Veksler
źródło
1
Drugi punkt zakłada, że ​​byłoby rozwiązanie open source, co jest dalekie od pewności. Ale co najważniejsze, część zachowanego przeze mnie kodu to kod pokazujący, w jaki sposób korzystałem z komponentów / usług innych firm. Na przykład, jeśli opracuję przyzwoite rozwiązanie płatnicze, które integruje się z Paypal, skorzystam z kodu, aby skorzystać z niego później - więc nie muszę ponownie wymyślać koła następnym razem.
cjmUK
0

Nie zachowałem jeszcze żadnego kodu, który napisałem dla pracodawców. Zachowałem niezależne rzeczy (utrata kodu może być trudna do obsługi klienta).

Zastanawiam się jednak nad zachowaniem kodu, który stworzyłem dla tego pracodawcy. Powodem jest to, że jestem programistą i opracowałem wiele rzeczy po stronie klienta, które wyglądają raczej ładnie. Nie zaprojektowałem ich, ale wdrożyłem je i często wpadałem na pomysł. Chciałbym zachować kopię tych rzeczy, aby zbudować portfolio online. Jak wszyscy wiemy, strony nie trwają wiecznie, więc nie mogę realistycznie liczyć na to, że moja praca pozostanie online. Posiadanie kopii zapasowej pozwoliłoby mi mieć portfolio online.

Wiem, że projektanci często przechowują kopie swoich prac (nawet jeśli była to praca najemna) na potrzeby portfolio.

Nie jestem pewien, jaka jest to legalność (nie jest to wyraźnie wymienione w mojej umowie).

Xandor Schiefer
źródło
4
but what are your thoughts on this?Nie zapraszaj otwarcie do rozmowy na swoją odpowiedź, przedstawiając kolejne pytanie. Powiedz nam, czy powinniśmy zachować kopię całego kodu, który piszemy. Możesz poprawić odpowiedź, edytując ją.
wałek klonowy
1
Myślę, że istnieje różnica w zachowaniu oryginalnych plików źródłowych (w twoim przypadku plików graficznych takich jak .ai lub .psd) w porównaniu z zrzutem ekranu końcowego produktu dla twojego portfolio. Nadal powinieneś poprosić swojego pracodawcę o zgodę, ale powinni oni być bardziej zgodni z tym ostatnim.
Sarel Botha
Ponieważ praca ma często charakter interaktywny, zrzut ekranu nie wycina jej dla portfolio. To pokazuje tylko projekt (który w większości nie jest mój). Mógłbym zrobić zrzut ekranu ze mnie przy użyciu omawianej pracy, ale wciąż nie przekazuje takich informacji, jak opóźnienie, wydajność, kompatybilność z różnymi przeglądarkami.
Xandor Schiefer
0

Cóż, aby rozwinąć logikę biznesową dla mojej firmy, nie mogę zachować kodu, ponieważ jest to nielegalna i osobista własność firmy. Jako programista wiem, jak rozwinąć tę logikę, więc mogę o niej pamiętać. Zasadniczo domyślnie jest przechowywany w twoim umyśle, a jeśli będziesz go potrzebować następnym razem, to automatycznie powinieneś wdrożyć logikę / lepszą logikę niż poprzednia. To ludzka natura i inteligencja. :)

Ale problem pojawia się, gdy rozwijasz logikę narzędziową, są one do ponownego użycia i zawsze ważne, może być potrzebne często w różnych projektach. Więc powinieneś chcieć to mieć przy sobie.

Mam alternatywne rozwiązanie tego. Po prostu utwórz plik JAR bez źródła / dokumentacji dla tych narzędzi i dodaj go jako zewnętrzny plik JAR innej firmy w swoim projekcie. Prawdopodobnie robiąc to, możesz potwierdzić swoją odpowiedzialność, a także samozadowolenie z posiadania kodu ;)

Soumyadip Das
źródło
1
Inne podejście polega na tym, że kiedy napotykam przydatny / wielokrotnego użytku fragment kodu, który chciałbym „zabrać ze sobą” ... po prostu wracam do domu i piszę post na blogu o konkretnym API lub technice, która była zainteresowana mnie. Ten post na blogu oczywiście nie odnosi się do mojego pracodawcy ani nie używa, wiersz po wierszu, kodu zapisanego na bilecie mojego pracodawcy.
Joel Martinez
Jeśli istnieją reguły, to muszą być anty-regułami. Które możesz wykorzystać na swoją korzyść. Są to różne techniki, aby to osiągnąć. Najważniejsze jest to, aby praca była czysta.
Soumyadip Das
0

Nie trzymam kodu z prostego powodu: firma zapłaciła mi za napisanie kodu dla nich. Daję im mój kod, a oni dają mi moją wypłatę. Facet, który zrobił mój lunch, nie zachowuje tego dla siebie, dlaczego kod miałby być inny?

Ponadto, jak już wspomniałem, odchodzę z pracy, wszystkie bóle głowy pozostają tam, nowa praca, nowy start, ale z nieco większym doświadczeniem i zrozumieniem rodzajów problemów w tej starej pracy.

Scott S.
źródło