Zkus si přečíst sekci Hnutí za dobrý kód z http://www.abclinuxu.cz/blog/bystroushaak/2014/7/python-poznamky
Jinak osobně jsem v pythonu dělal na projektu, který měl přes 40k řádek podle CLOC (tzn bez prázdných řádků, komentářů, docstringů a tak). Nebyl s tím vůbec žádný problém, dělali jsme to ve dvou a šlo to v pohodě. Možná za to mohla microservices architektura, ale prostě žádné hroucení na hlavu se nekonalo. Ani co se týče kódu, ani co se týče výkonu, naopak se to krásně škáluje. Umím si představit, že by to stejným způsobem šlo klidně o řád dál bez nějakého stresu.
IDE nebo jiné nástroje pro Python vám při refaktoringu typicky pomohou mnohem méně než kompilátory moderních staticky typovaných jazyků (a nezmění to ani pokročilejší IDE jako PyCharm). IMO udržovat kód v Pythonu je tedy o dost náročnější (na druhé straně to zřejmě kompenzuje dostatek programátorů).
IDE jako PyCharm obsahuje gramatiku jazyka a ve spojení například s debuggerem má všechny předpoklady k tomu, aby si typy zjistilo samo a uložilo například do slovníku, nebo formou anotací do zdrojového textu. Není proto těžké udělat plugin, který by to obstaral včetně vazby na refaktoring.
Udělat takový plugin je prakticky nemožné, neboť typová rekonstrukce i pro jednoduché typové systémy (jako je například System F) je nerozhodnutelná. A pro (rozumné) otypování netriviálních programů v Pythonu potřebujete mnohem složitější typový systém (hádám minimálně na úrovni DOT).
Z teoretického hlediska to možné není, z praktického ano. Stačí zaznamenat jaké typy proměnné nabývají během běhu programu, a to lze. Bude to empirická typová závislost, která bude poskytovat informaci, které typy proměnné nabývají, nevyloučí však, že jiný typ, z méně často používané větve programu, nebo větve nepokryté testy nenabudou.
Což bude posilovat používání proměnných s danými typy, protože tu informaci při rozvíjení systému budete mít po ruce a IDE vám ji bude napovídat. Když narazíte v programu na jiný typ, budete mít možnost rozhodnout, zda je to chyba, či záměr, ale nedostanete se do situace, kdy typ bude naprosto neznámý.
To je základ filosofie dynamických programovacích systémů, rozhodovat se na základě informací, které jsou v daném čase k dispozici, nepočítat se všemi možnými eventualitami, které mohou nastat ale v praxi nastávají občas, nebo vůbec. Co je důležité, určuje pak praxe provádění programu, což se dynamicky mění, chyby se opravují postupně, opravy vylepšují systém, nevznikají z nich nové chyby, protože opravujete jen to, co aktuálně nefunguje a neřešíte, co by možná mohlo nefungovat, což bývá často zdrojem dalších chyb. Systém je programován tak, aby se uměl z chyby sám zotavit, protože se počítá s tím, že nastanou.
U statických jazyků je to naopak, snažíte se navrhnout systém tak, aby zahrnoval všechny možnosti, nemyslíte na zadní kolečka, což vede k ignorování rizika chyby a když chyba nastane, systém rovnou zkolabuje. Jístota, že systém je napsán správně je vyšší, ale zároveň je vyšší jistota, že sytém někdy bez zjevné příčiny zkolabuje díky tomu, že v něm vznikne neočekávaná chyba.