DS

Sådan undgås almindelige vanskeligheder i dit datavidens programmeringsmiljø

SHAIK SAMEERUDDIN; School of Computer Science and Engineering (Specialization in Data Analytics), Vellore Institute Of Technology; [email protected] (DA);

Kontakt: (+91) 9848586260

Overvej følgende situation: du prøver at øve dine fodboldfærdigheder, men hver gang du tager op på banen, står du over for flere problemer: dine sneakers er på de forkerte fødder, snørebåndene er ikke faste, dine støvler er for korte, dine bukser er for lange, og bolden er i forkert størrelse. Dette er en latterlig situation, men det ligner det faktum, at mange dataforskere på grund af et par normale, let opløselige problemer befinder sig i:

. Mangel på bibliotekafhængighedskontrol

. Inkonsekvent stil i kode

. Inkonsekvente konventioner i navngivning

. Forskellige teamudviklingssituationer

. Brug ikke et indbygget udviklingsmiljø til at ændre kode

"Trip" dig op med alle disse fejl, spilder dine penge og dyrebare mentale energi og tænker over små detaljer. I stedet for at løse problemer med datavidenskab, finder du dig selv at håndtere utilsigtede vanskeligheder med at forsøge at opsætte systemet eller få applikationen til at fungere. Heldigvis med de rigtige værktøjer og fremgangsmåde er ovenstående problemer enkle at løse. I dette indlæg vil vi se på bedste praksis for et programmeringsmiljø inden for datavidenskab, der giver dig mere energi og fokus til at koncentrere dig om de spørgsmål, der betyder noget.

1) Manglende kontrol med biblioteksafhængighed:

Intet er mere frustrerende end at skrive kode, at en dag fungerer perfekt, og at finde det har mange fejl næste dag uden at ændre et tegn. Det har en enkelt årsag næsten hver gang jeg finder dette problem: ikke at holde styr på, hvilken biblioteksudgave, du bruger i din applikation. Dette problem er så almindeligt og så frustrerende, at det hedder afhængighedshelvede.

For at komme over dette har biblioteker versioner, som du kan huske: når du tror, ​​du bruger pandaer, er det forkert; du bruger virkelig pandaer == 0.24.0 eller pandaer == 0.19.2; osv. -bibliotek, du tilføjer til et projekt, er i en bestemt version, og det er nødvendigt at logge versionen af ​​dit projekt for at undgå dårlige øjeblikke med brudt kode. Ideen er at skabe et uafhængigt miljø: en overvåget installation af Python med egne pakker adskilt fra din Python-ramme. Der er mange måder at løse det på.

  1. Pythons indbyggede venv: Den leveres med Python, men er en smule vanskelig at bruge.
  2. Conda-virtuelle verdener: Brug conda-programadministratoren til at oprette og vedligeholde virtuelle miljøer. For dem, der er nye inden for virtuelle miljøer, er det sådan, jeg vil foreslå.
  3. Pipenv (tredjepart): Det bygger og håndterer også Pipfile-kontrollerede virtuelle miljøer. Jeg betragtede det som meget brugervenligt.
  4. Docker-containere: En database går ud over et virtuelt miljø, der indeholder alle de applikationer og kode, der kræves for at køre et program (selvom det ikke er rigtig en virtuel maskine). Docker bliver mere almindeligt inden for datavidenskab, fordi du kan pakke data, kode og alle nødvendige biblioteker sammen, så det er værd at lære at konfigurere og køre dockercontainere.

(Real Python har alle disse værktøjer med gode tutorials).

Pipfrysning> krav.txt er ikke tilstrækkelig: For at sikre, hvilke biblioteker der passer til den forventede version, skal du bruge virtuelle miljøer (som kan bygges ud fra kravene.txt). En virtuel env har også en specificeret version af Python, som fjerner problemet med forskellige Python-installationer.

Den tilgang, du vælger, afhænger af dit teams behov, og hvor længe du vil investere. Jeg bruger conda-indstillinger, for eksempel til personligt arbejde og rørsystemer på arbejdet. Jeg vil ikke fremsætte en anbefaling bortset fra at sige: vælg en, og brug den! Du skal aldrig gøre datavidenskab uden at forstå udgaven af ​​hvert bibliotek, du ringer til.

2) Inkonsekvent stil af kode:

Hvis du skulle vælge, hvor mange mellemrum du vil bruge på hver linje i et script, ville du ikke have tid tilbage til at tænke over den faktiske kode! De fleste menneskers tendenser til at formatere er ikke så dårlige, men tæt. Du bør aldrig tage bevidste beslutninger om kodeformat: emner som mellemrum omkring nøgleordsparametre, længde på sider, tomme linjer mellem metoder, bageste komma efter det sidste objekt i en sekvens, og så videre; variabler, der kun beskæftiger sig med, hvordan koden ser ud.

I stedet for at vælge på hver linje, skal du tage en global beslutning - tage en stil til dit projekt - og aldrig mere bekymre dig om det. Mit team bruger det sorte auto-formateringsværktøj på arbejdet, der anvender en standard kodestil i hele vores projekt og bare løser fejlene - ingen grund til at tænke over det. Hver gang jeg gemmer en Python-fil i kode, indstiller jeg den til automatisk at køre. Sort klarer sig så godt og er så let at bruge, at jeg også bruger det i hele mit personlige liv.

Python og andre sprog har også andre muligheder for automatisk formatering eller fnug. Jeg vil anbefale, at du følger en række retningslinjer for applikationstypen og bruger et værktøj til at teste alle filerne til brug. At bruge mere energi på kodeformatering end nødvendigt er helt klart spild af din dyrebare tid.

3) Inkonsekvente konventioner i navngivning:

I et andet eksempel på princippet om "at tage en global beslutning en gang i stedet for en masse lokale beslutninger", skal du oprette navnekonventioner for et projekt. Disse skal indeholde variabler, funktioner, klasser, mapper, kontroller og poster. Standardforkortelser for enheder (såsom km / h) og for aggregeringer (min, max) bør også inkluderes i navnekonventioner. Jeg skrev her om navngivende variabler.

At vælge de samme normer er ligeglad med at følge dem regelmæssigt. Enig om forventningerne til hele holdet (hvilket kan være bare dig), skriv dem ned på et bestemt sted, og følg dem derefter uden afvigelse. Ved kodevurderinger (en anden afgørende bedste praksis) håndhæves standarderne, så alle er på samme side. Dette råd handler om at reducere antallet af bevidste beslutninger, du træffer endnu en gang. Når du skriver navne på funktioner, variabler osv., Skal der være et meget indlysende valg baseret på koden og dine konventioner.

Hvis du fejler, skal du følge en lignende protokol, der bruges af et andet team. Vær ikke dogmatisk og nægter at ændre dig, da du altid har gjort tingene på en eller anden måde. Der er ikke plads til programmering af den statiske, uforanderlige personlige overbevisning. Opret regler, skriv dem ned, håndhæv dem og stoppe med at bruge tid på data videnskabs tilfældige problemer.

4) Forskellige teamudviklingssituationer:

Alle i teamet skal bruge den samme atmosfære til udvikling, ingen undtagelser. Som Windows-bruger i en levetid (22 år), på min nuværende position (Cortex Building Intelligence), overvejede jeg ikke noget om at protestere mod at bruge MacOS til udvikling. Der var simpelthen ikke noget valg at gøre: alle andre bruger en Mac, så det var det, jeg var nødt til at bruge til teamstandardisering. Jeg vil ikke gå ind for en enhed frem for en anden (her er de numre, som det er mest brugt til), men jeg vil argumentere ordentligt for, at alle på det samme team vil bruge det samme operativsystem.

Alle i teamet skal bruge det samme produktionsmiljø uden undtagelser. Som Windows-bruger på min nuværende position (Cortex Building Intelligence) i en levetid (22 år) overvejede jeg nul til at protestere mod at bruge MacOS til udvikling. Der var bogstaveligt talt ikke noget valg at gøre: alle andre har en Mac, og det var det, jeg var nødt til at bruge til at standardisere hold. Jeg vil ikke gå ind for en enhed frem for en anden (her er de numre, det bruges mest til), men jeg vil ordlydt argumentere for, at alle i det samme team vil bruge det samme operativsystem.

5) For meget programmering skrevet i notebooks snarere end et organiseret udviklingsmiljø:

Sandsynligvis den største ændring for mig fra forskningsdatavidenskabelig baggrund til branchen var at korrigere denne praksis: programmer og individuelle scripts skulle skrives i et integreret udviklingsmiljø, ikke Jupyter Notebooks. Den bærbare computer er fantastisk til at udforske, lære, tegne grafik og læse programmering, men til at skrive al kode skal du ikke udvikle en usund vane med at stole på den.

Jupyter Notebooks er et dårligt sted at skrive rigtige programmer med en masse scripts på grund af manglen på værktøjer: ingen fnug, ingen automatisk formateringskode i alle projekter, dårlig filsøgning, ingen projektomfattende søgning og fjernelse, ingen indbygget kontrolmekanisme, svag test, ingen indbygget terminal osv. Ja, disse ting bliver ikke besvaret af Jupyter Lab; det er stadig ikke et sted, hvor du kan eller bør skrive manuskripter.

Det er vanskeligt at nedbryde notesbøger, fordi det hjælper dig med at holde store stykke information i dit hoved. Vi er nødt til at tale om programmering i form af hele scripts sammensat af mange funktioner og klasser i stedet for tekstblokke. Derudover præsenterer en notesbog en lineær sti af kode, der udføres fra top til bund, når der er mange sammenkoblede stykker i et rigtigt program, der danner en løkke. Et script importerer dele til dit modul fra 10 andre, der opretter forbindelse i en kompliceret ramme.

Jeg vil ikke gå ind på kodning af bedste praksis, men miljøet, du prøver at udvikle, har en enorm indflydelse på, hvordan du tænker og skriver kode. Et korrekt integreret udviklingsmiljø giver dig mulighed for at tænke på datavidenskabskoden ikke som isolerede bærbare computere, men som et softwareprodukt: en med mange sammenlåse dele og komplicerede interaktioner.

En IDE har mange gode valg. Jeg anbefaler, at du eksperimenterer med nogle få for at finde den rigtige kompleksitet og det rigtige antal funktioner.

. Sublime Text starter let, men har mange plug-ins

. PyCharm er en robust platform med meget flere muligheder end du nogensinde har brug for og en lille læringskurve

Jeg bruger personligt Visual Studio Code, som er blevet den mest populære softwareteknologiditor. Vscode giver mig alt det ovenstående og mere via udvidelser (inklusive den indbyggede plugin og git-integration). Jeg bruger cirka 90 procent af min kodningstid i Visual Studio Code, og jeg har lige ønsket at lide det lige så meget som Jupyter Notebook.

Jupyter Notebooks har næsten intet grundlæggende forkert, de var bare aldrig beregnet til at udvikle seriøse programmer. De er et godt værktøj, når de bruges korrekt (implementering af begrebet litterat programmering). Som med enhver enhed kan notebooks dog bruges, hvor de ikke er passende. Du bliver nødt til at henvende dig til et avanceret udviklingsmiljø, når du ønsker at begynde at skrive produktionskode. Selv hvis du ikke er der endnu, vil jeg overveje at gøre dig bekendt med ideen om at skrive scripts i stedet for notebooks og udarbejde flere scripts sammen til et bibliotek (som du kan uploade til en notebook til analyse).

Til at begynde med en lidt skræmmende, men meget mere produktiv. Husk, at den måde, du tænker, påvirker dit miljø på.

Konklusioner:

Jeg tror, ​​vi kan gøre det bedre som sektor. Lad os bruge mindre tid på at udvikle algoritmer, bygge modeller, ingeniørfunktioner og implementere trænede modeller (og bekæmpe klimaændringer med maskinlæring) på utilsigtede vanskeligheder ved datavidenskab - håndtere afhængigheder, kodeformatering, navngivning, operativsystemer og kodeditorer - og mere tid på de væsentlige vanskeligheder. Ved at vedtage den praksis, der er beskrevet i denne artikel, har du mere tid og mentale ressourcer til at løse de virkelig vigtige problemer.

Gennem sit fremragende papir No Silver Bullet adresserer David Brooks begrebet utilsigtede vs grundlæggende problemer gennem software engineering. I løbet af de sidste 40 år er produktivitetsgevinster inden for softwareteknologi skabt ved at reducere utilsigtede problemer - dem, der er relateret til at oversætte ideer til kode - og de væsentligste vanskeligheder ved at tænke ideerne tilbage. Inden for datavidenskab ser jeg mange mennesker med utilsigtede problemer, som står op og begynder at kode, fordi de ikke har en passende atmosfære, eller fordi de ikke følger enkle standarder.

Som altid er anmeldelser og positiv kritik velkommen. Jeg kan nås på Linked- In: www.linkedin.com/in/shaik-sameeruddin-baa421171