Názory k článku
Na GitHubu je 70 % duplicitního kódu

Jediny nefusersky pristup v pripade pouzivania 3rd party komponentov je nechat 3rd party komponenty 3rd party komponentami a nesahat do nich. Ak sa do nich saha, tak to maju byt zmeny, ktore opravuju alebo rozsiruju funkcionalitu 3rd party komponentu ako takeho *a tieto potom pretlacit do upstreamu*. Zdrojovy kod 3rd party komponentu nie je miesto na aplikovanie vendor-specific hackov. Tie treba drzat mimo komponentu (nad jeho verejnym API).

Cokolvek menej striktne ako takyto pristup je cisto cista a nefalsovana fuserina a skor ci neskor sa vypomsti. Intenzita pomsty a naklady na splatenie "tech debtu" potom rastu s invazivnostou, lajdackostou prevedenia zmeny, vseobecnej exponovanosti 3rd party komponentu, jeho komplexitou a dolezitostou dalsej existencie kodu, ktory tak ucinil. Nie je ale otazkou toho, ci. Spravna otazka je: kedy.

A little copying is better than a little dependency. (Go proverb)

Závislosti v js (node.js) jsou docela peklo, zvláště pokud se o vyvíjený produkt nemůžete starat kontinuálně, ale dostanete se k tomu tak 3-4x do roka. To kam došel npm ekosystém hraničí s neudržitelností, i relativně malé projekty mají i tisíce závislostí, kolikrát jeden modul i v několika verzích. Velice často ty moduly mají do 100 řádků a z nějakého neznámého důvodu autoři s oblibou kompletně mění API. Takže když chcete po půl roce aktualizovat verze (třeba i z nějakých bezpečnostních důvodů), donutí vás to významně zasáhnout do aplikace. Proti tomu je práce se standardní knihovnou Go vysvobození, aktualizujete na novou verzi a vše jede jak má. V používaných knihovnách se API mění jen opravdu výjimečně.

Express 4.16.0 contains important security updates.

Od toho máš právě možnost udělat fork cizí knihovny a přidat si tam vlastní úpravy nebo něco opravit (pokud to původní autor nechce přijmout do hlavní větve nebo už se o projekt nestará). Pak používáš pořád knihovnu (tzn. v tomto výzkumu by se to neobjevilo jako duplicita, protože je to fork) a přitom nejsi závislý na někom jiném.

A pokud bude žádoucí změnu zpropagovat do jiné větve, pomůže ti s tím verzovací systém (merge, cherry-pick).

A pokud bys ten kód místo forku zkopíroval, tak ho udržovat nemusíš?

Kopírování dává smysl v případě, že bys z velké knihovny potřeboval malý kousek kódu. Ale i v takovém případě by šlo hledat čistější řešení – např. usilovat o rozdělení knihovny na menší modul (resp. knihovny by se takhle už měly navrhovat) nebo použít jinou knihovnu, která není tak rozsáhlá.

Přesně. Nejen že ho musí udržovat dál, ale navíc ho odpojí od původního kódu, je těžší sledovat změny, dělat backporty oprav, prakticky zabrání tomu aby se jeho úpravy dostaly snadno do upstreamu… Geniální nápad, tohle kopírování celých knihoven…

Vaše teoretické diskuse jsou sice fajn a v zásadě správné, ale je z nich vidět, že prakticky vůbec nevíte, o čem je řeč.

Já si právě také myslím, že to nejde, proto mne překvapilo tvrzení Kallsymse, že to tak dělá, a ještě se tvářil, že je to úplně běžné.

Vy často máte problém s pochopením psaného textu. Člověk ne vždy vytvoří fork za cílem vytvoření pull requestu.

Ano, s tím, že někdo nechápe psaný text, mám problém často. Překvapivě často mám problém i s tím, že psaný text nechápe sám jeho autor. Psal jsem snad někde, že se fork vždy vytváří za účelem pull requestu? Nepsal. Pouze jsem se ptal na ten případ, kdy někdo vytvoří fork (pomocí klonování, ne pomocí funkce GitHubu) a pak z toho nezávislého forku dělá pull request. Vycházel jsem z vašeho textu:

Ono je to dost často i kvůli tomu, že pokud chce člověk přispět, tak si vytvoří fork, tam udělá změny a pošle pull request.
A když Lazywriter připomněl, že se zkoumaly neforkované projekty, dotčeně a arogantně jste doplnil, že jste samozřejmě nemyslel fork vytvořený pomocí funkce GitHubu ale pouze pomocí klonování repository.