Fem fordeler med kommandolinjeværktøy

Noen mennesker frykter kommandolinjen. Andre anser det som arcane og foreldet. Mange av oss vet sannheten; ofte er kommandolinjeverktøy de riktige verktøyene for jobben.

Kommandolinjeverktøy og applikasjoner gir oss mange fordeler som er utilgjengelige, vanskelige å oppnå eller ufullstendige med GUI-applikasjoner. Disse fordelene er mange, men spesielt fem kan komme øyeblikkelig i tankene:

1. Skalerbarhet

Alle som gjør paranoid cookie-administrasjon i Firefox lenge nok, vil sannsynligvis løpe inn i problemet med 1001 Cookies, der dialogvinduene for informasjonskapsler administreres så raskt og i så mange tall at det ser ut som om det kan ta hele dagen å komme gjennom dem alle. Dette eksemplet demonstrerer et problem med brukergrensesnitt og andre grensesnitt som er fanget: skalerbarhet. Når du bare utfører en enkelt, enkel oppgave en gang, kan det virke ganske enkelt å bare klikke på et par grensesnittknapper og gå videre. Når det plutselig er en overflod av slike oppgaver, og de alle krever brukerens oppmerksomhet (for eksempel å velge hvilke informasjonskapsler som skal aksepteres og hvor lenge de skal beholde dem), blir GUI mer til hinder enn en hjelp, og oppgavelinjen (hvis du bruk en) fylles raskt opp med vindusknapper som viser noe som "C ..." og ingenting annet.

Derimot har kommandolinjeværktøyene en tendens til å gi langt større mulighet til å håndtere slike skalerbarhetsproblemer raskt og enkelt. Organisering av utdata i grupper, slik at oppgaver som krever samme brukerrespons blir samlet sammen, og gjør det mulig å utføre en enkelt handling for å oppnå resultater over et stort antall diskrete oppgaver. Der de legionene med Firefox-dialoger krever en beslutning og klikk for å utføre for hver enkelt, kan litt skikkelig sortering og piping av utdataene fra forskjellige påkallinger av ja-kommandoen tilby kommandolinjeverktøybrukeren muligheten til å bruke bare en håndfull trinn for å håndtere hundrevis av diskrete oppgaver.

2. Skriftbarhet

Enhver Unix-sysadmin bør forstå kraften i skripting for kommandolinjeværktøy. Mange Microsoft Windows-administratorer er imidlertid ikke like kjent med styrken og fleksibiliteten til kommandolinjen i samme grad som Unix sysadmin-brødrene. Årsaken til dette er at når det gjelder systemadministrasjon, har MS Windows-administratorer ofte en mye vanskeligere rekke å hekte på grunn av meklingen mellom administratoren og systemets grunnleggende funksjonalitet som blir tvunget til dem av den GUI-sentriske utformingen av operativsystem. Når det er fem knapper som må klikkes i en bestemt rekkefølge atten ganger om dagen i et GUI-program, må man klikke på knappene atten ganger, men når en bestemt kompleks kommando må legges inn atten ganger i et Unix-skall, er en triviell øvelse for å skripte den aktiviteten for å fjerne noe av den administrative kostnadsbelastningen for sysadminen.

Den kompetente Unix sysadmin er Maytag-reparatør for informasjonsteknologiverdenen. Automatisering gjennom systemskripting pares bort all tedium og repetitivitet i de daglige oppgavene sine til de ikke har noe igjen å gjøre til side fra å være tilgjengelige i tilfelle noe går i stykker og - hvis de er heldige nok til å ha sjefer som tillater den slags ting - kommer opp med ideer for hvordan du kan forbedre måten ting gjøres. I mellomtiden kjøres ofte GUI-administratoren ujevn hver dag for å gjøre ting for hånd (ved hjelp av en mus) som den kompetente Unix sysadmin har delegert til admin-skript for lenge siden.

De beste MS Windows-administratorene gjør selvfølgelig det de kan for å laste ned sine egne repeterende oppgaver til admin-skript, men den relative svakheten i systemadministratorens automatiseringsalternativer fungerer som en begrensende faktor. I ikke-gradvis grad er forskjellen den gjennomgripende påvirkningen av kommandolinjefunksjonaliteten til Unix, i kontrast til selve GUI-sentriske designet til Microsoft Windows. Der GUI-utviklere planlegger muligheten til å automatisere aktiviteter, må de vanligvis bygge makrosystemer i hver applikasjon hver for seg, mens selve kommandolinjen er "makrosystemet" for alle tilgjengelige kommandolinjeværktøyer, noe som sikrer enhetlighet av skriptgrensesnitt og tilgjengeligheten av automatiseringsfunksjoner for mange flere programvarestykker enn det ellers ville være så lett å skrive.

3. Enkel design

Fordelene med en enkel design er velkjente. For eksempel virker det rimelig å si at enkelhet er sikkerhet. Hvis forklaringen ikke er overbevisende, kan du lese om hvordan enkel design er et viktig element i åpen kildekodesikkerhet, inkludert den uunngåelige sannsynligheten for at mer kode betyr flere feil. Når du vurderer sikkerhetsfordelene ved enkel design, er det viktig å forstå forholdene mellom sikkerhet, kompleksitet og GUI-miljøet .

Kommandolinjeverktøy drar ofte fordel av mer enkle, åpenbare, enkle design. En del av grunnen til dette er det faktum at kommandolinjeverktøy lett skrives som mindre, enklere verktøy som - i Unix-tradisjonen - gjør en ting godt. Hvor fangenskapelige grensesnitt er måten å gjøre det på med GUI-applikasjoner, og tvinger utviklere til en snikende featurismemodus når de "forbedrer" programvaren sin slik at brukere kan utføre mer komplekse oppgaver, kan kommandolinjeværktøy som hver enkelt gjør en ting godt knyttes sammen på fly av Unix-rørledningen for å utføre komplekse oppgaver uten å kreve noen å legge til funksjoner i selve katteverktøyet, for eksempel:

  • funksjoner for estimering av "lesenivå"
  • PDF eksport
  • stave- og grammatikkontroll

4. Enkelt grensesnitt

GUI-applikasjoner er avhengige av menyer og knapper for å få gjort alt. Dette betyr at kraftige verktøy krever kompliserte grensesnitt, slik at brukeren kan få tilgang til (nesten) alle funksjonene i applikasjonen med en mus. Jo flere funksjoner en applikasjon har, desto mer komplisert blir grensesnittet. Microsoft Office produktivitetssuite er et godt eksempel på den typen kompleksitet grensesnittet påtar seg når mange funksjoner legges til. Den applikasjonssuiten har blitt så komplisert gjennom årene at personene hos Microsoft til slutt måtte komme med en innovativ tilnærming til å håndtere den kompleksiteten. Resultatet var Ribbon - en slags dynamisk menylinje, der applikasjonen din prøver å presentere de mest brukte og mest nyttige funksjonene til enhver tid, avhengig av hva brukeren gjør akkurat i det øyeblikket. Denne tilnærmingen er interessant og hjelper deg med å administrere kompleksiteten i applikasjonssuiten, men samtidig støtter den tilfeldige brukers vanligste aktiviteter på bekostning av å gjøre ting mye vanskeligere for "strømbrukere" og deres produktivitet. De mest kunnskapsrike brukerne har en tendens til å ha mest problemer med båndet.

Kommandolinjeprogrammer og tastaturdrevne, konsollbaserte, captive grensesnitt kan tilby enkel interaksjon for tilfeldige brukere uten å trekke ut teppet fra føttene til mer kunnskapsrike brukere. Mange slike verktøy vil gi enkel bruksinformasjon ved å bruke et --help-alternativ når du påkaller det ved skallet, eller lett tilgang til brukshjelp fra et internt grensesnitt via et tastetrykk eller to. Nybegynnere kan lære de rudimentære grunnleggende enkelt, og når de lærer mer om hvordan de bruker det, blir anlegget deres med applikasjonen utvidet. Enkelheten i grensesnittet kommer aldri på bekostning av den utvidede kunnskapen.

5. Stabil design

Etter hvert som GUI-miljøer utvikler seg over tid, og skaffer seg nye klokker og fløyter og funksjonssett, må GUI-applikasjoner endres for å passe inn i disse miljøene. Ettersom GUI-applikasjoner blir mer komplekse med tiden med tillegg av nye funksjoner, gjennomgår applikasjonene mutasjoner slik at de aldri helt fungerer som de gjorde for en versjon siden. Bakoverkompatibilitet er en veldig vanskelig prestasjon med nye versjoner av GUI-applikasjoner av disse grunnene og mer. Som et resultat må brukerne lære seg hvordan deres favoritt GUI-applikasjoner fungerer til en viss grad hver gang de oppgraderer. Selv om de aldri har bruk for nye funksjoner som er lagt til i applikasjonene, endres ofte de gamle funksjonene de bruker med utgivelsen av nye versjoner. Vanligvis trenger de nye funksjoner, om bare noen få, men læringskurven for endringer i hvordan de gamle funksjonene brukes er vanligvis mye brattere enn for en liten håndfull nye funksjoner de vil bruke i fremtiden.

I tillegg kan det enkle faktum at brukere har gjort de samme tingene på samme måte en god stund, resultere i det lærere kaller "negativ overføring av læring", der det de allerede vet (i dette tilfellet fra en tidligere versjon av et program ) forstyrrer evnen til å lære ny kunnskap under lignende omstendigheter. Kommandolinjeværktøyer, spesielt gitt deres typisk enklere design, har ikke en tendens til å lide dette problemet i nesten samme grad. Hvis en ny funksjon må legges til, krever det vanligvis ikke omskifting av de gamle funksjonene, som nesten alltid lett kan nås på samme måte som de fikk tilgang til før oppgraderingen.

Gitt større mulighet for å knytte separate verktøy sammen på kommandolinjen enn i GUI-miljøet, er det ofte unødvendig (og uønsket) å legge til nye funksjoner til et bestemt verktøy uansett, fordi ny funksjonalitet ganske enkelt kan bygges som et nytt verktøy, slik at brukeren å ansette de to verktøyene sammen via Unix-rørledningen. Sluttresultatet er at sluttbrukeren vanligvis ikke trenger å bekymre seg for ustabil programvaredesign der grensesnitt og bakenden oppfører seg på uventede nye måter når en ny versjon av verktøyet slippes.

Betydningen av alternativer

Kommandolinjen er selvfølgelig ikke egnet for alt . GUIer og andre grensesnitt som er fanget gir fordeler som er fraværende eller vanskelig å oppnå, utelukkende med kommandolinjeværktøy. Det er faktisk noen oppgaver, som betydelig kompetanse er nødvendig for å til og med møte fordelene med en kommandolinjetilnærming, slik at enhver inexpert bruker bare vil bli hindret av mangelen på et fanget grensesnitt.

For de fleste tilfeller, selv når et internt grensesnitt er passende, er kommandolinjeverktøy også viktig å ha. Faktisk, i mange tilfeller, hvis et fanget grensesnitt er en god idé, bør det bygges på toppen av kommandolinjeværktøyene, slik at det captive grensesnittet i seg selv - enten det er en GUI eller et konsollbasert grensesnitt slik som gitt av forbannelsene bibliotek på Unix - er bare en tynn finér over verktøy som også kan påberopes individuelt fra kommandolinjen eller i et skript ved behov.

Det er liten sjanse for at brukergrensesnittet blir neglisjert til fordel for kommandolinjen i den daglige designen av sluttbrukerens datamaskinprogramvare. Mange utviklere synes imidlertid fornøyd med å ignorere viktigheten av kommandolinjen og fordelene det kan gi for brukere. En del av grunnen til dette er at brukerne selv ikke er klar over fordelene som kan være med å bruke kommandolinjeværktøy. Hvis du er en av disse brukerne, kan det være på tide å hente en kopi av den beste Linux-boken som er tilgjengelig og gjøre deg kjent med fordelene med kommandolinjeværktøyene litt mer.

© Copyright 2020 | mobilegn.com