Fem fordele ved kommandolinjeværktøjer

Nogle frygter kommandolinjen. Andre betragter det som arcane og forældet. Mange af os ved dog sandheden; ofte er kommandolinjeværktøjer bare de rigtige værktøjer til jobbet.

Kommandolinjeværktøjer og applikationer giver os mange fordele, der ikke er tilgængelige, vanskelige at opnå eller ufuldstændige med GUI-applikationer. Disse fordele er adskillige, men især kan fem komme øjeblikkeligt op i tankerne:

1. Skalerbarhed

Enhver, der laver paranoid cookiehåndtering i Firefox længe nok, vil sandsynligvis løbe ind i problemet med 1001 Cookies, hvor dialogboksen til cookiehåndtering vises så hurtigt og i sådanne numre, at det ser ud til, at det kan tage hele dagen at komme igennem dem alle. Dette eksempel demonstrerer et problem med GUI'er og andre grænseflader i bunden: skalerbarhed. Når du kun udfører en enkelt, enkel opgave en gang, kan det virke ret let at bare klikke på et par interfaceknapper og gå videre. Når der pludselig er masser af sådanne opgaver, og de alle kræver brugerens opmærksomhed (som at vælge, hvilke cookies de skal acceptere og hvor længe de skal beholde dem), bliver GUI'en mere til hinder end en hjælp, og din proceslinje (hvis du Brug en) fyldes hurtigt op med vindusknapper, der viser noget som "C ..." og intet andet.

I modsætning hertil har kommandolinjeværktøjer en tendens til at give langt større mulighed for at håndtere sådanne skalerbarhedsproblemer hurtigt og nemt. Organisering af output i grupper, så opgaver, der kræver det samme brugerrespons, er sammenklumpet, hvilket gør det muligt at tage en enkelt handling for at opnå resultater over et stort antal diskrete opgaver. Hvor disse legioner af Firefox-dialoger kræver en beslutning og klik for at udføre for hver enkelt, kan en lidt fornuftig sortering og piping af output fra forskellige kaldinger af ja-kommandoen tilbyde kommandolinjeværktøjsbrugeren muligheden for kun at bruge en håndfuld trin til at håndtere hundreder af diskrete opgaver.

2. Skriftlighed

Enhver Unix-sysadmin skal forstå kraften ved scripting til kommandolinjeværktøjer. Mange Microsoft Windows-administratorer er imidlertid ikke så fortrolige med kommandolinjens magt og fleksibilitet i samme omfang som deres Unix sysadmin-brødre. Årsagen til dette er, at når det kommer til systemadministration, har MS Windows-administratorer ofte en meget sværere række at hakke på grund af mæglingen mellem administratoren og systemets grundlæggende funktionalitet, der tvinges til dem ved hjælp af GUI-centreret design af operativ system. Når der er fem knapper, der skal klikkes i en bestemt rækkefølge atten gange om dagen i et GUI-program, skal man klikke på disse knapper atten gange, men når en bestemt kompleks kommando skal indtastes atten gange i en Unix-skal, skal det er en ubetydelig øvelse til at scriptere denne aktivitet for at fjerne nogle af den administrative omkostningsbyrde for sysadmin.

Den kompetente Unix sysadmin er Maytag-reparationsvirksomheden for informationsteknologiverdenen. Automation gennem systemscripting pares væk al tedium og repetitivitet i deres daglige opgaver, indtil de ikke har noget tilbage at gøre til side fra at være tilgængelige i tilfælde af at noget går i stykker, og - hvis de er heldige nok til at have chefer, der tillader den slags ting - kommer med idéer til, hvordan man forbedrer, hvordan tingene gøres. I mellemtiden køres den GUI-eneste administrator ofte ujævn hver dag, gør ting manuelt (ved hjælp af en mus), som den kompetente Unix-sysadmin har delegeret til admin-scripts for længe siden.

De bedste MS Windows-administratorer gør selvfølgelig hvad de kan for at downloade deres egne gentagne opgaver til admin-scripts, men den relative svaghed ved systemadministratorens automatiseringsindstillinger fungerer som en begrænsende faktor. I en ikke-gradvis grad er forskellen den gennemgribende indflydelse af kommandolinjefunktionaliteten i Unix, i modsætning til det meget GUI-centriske design af Microsoft Windows. Hvor GUI-udviklere planlægger muligheden for at automatisere aktiviteter, er de normalt nødt til at opbygge makrosystemer i hver enkelt applikation separat, hvorimod selve kommandolinjen er "makrosystemet" for alle tilgængelige kommandolinjeværktøjer, hvilket sikrer ensartethed af scripting-grænseflader og tilgængeligheden af ​​automatiseringsfunktioner for mange flere stykker software end ellers ville være så let at skrive.

3. Enkelt design

Fordelene ved et enkelt design er velkendte. For eksempel synes det rimeligt at sige, at enkelhed er sikkerhed. I tilfælde af at forklaringen ikke er overbevisende, kan du læse om, hvordan designenkelt er et vigtigt element i open source-sikkerhed, herunder den uundgåelige sandsynlighed for, at mere kode betyder flere fejl. Mere specifikt, når man overvejer sikkerhedsfordelene ved simpelt design, er det vigtigt at forstå forholdet mellem sikkerhed, kompleksitet og GUI-miljøet .

Kommandolinjeværktøjer drager ofte fordel af mere lige, åbenlyse, enkle design. En del af grunden til dette er det faktum, at kommandolinjeværktøjer let kan skrives som mindre, enklere værktøjer, der - i Unix-traditionen - hver især gør en ting godt. Hvor fangenskabelige grænseflader er måden at gøre det med GUI-applikationer, der tvinger udviklere til en snigende featurismetilstand, når de "forbedrer" deres software for at give brugerne mulighed for at udføre mere komplekse opgaver, kan kommandolinjeværktøjer, som hver Do One Thing Well kan bindes sammen på flyv ved Unix-rørledningen for at udføre komplekse opgaver uden at kræve nogen at tilføje funktioner til selve katteværktøjet, såsom:

  • funktioner til estimering af "læsningsniveau"
  • PDF eksport
  • stave og grammatik kontrol

4. Enkel grænseflade

GUI-applikationer er afhængige af menuer og knapper for at få alt gjort. Dette betyder, at magtfulde værktøjer kræver komplicerede grænseflader, så brugeren kan få adgang til (næsten) alle funktioner i applikationen med en mus. Jo flere funktioner en applikation har, jo mere kompliceret bliver interface. Microsoft Office-produktivitetssuite er et fremragende eksempel på den form for kompleksitet, som interface bruger, når mange funktioner tilføjes. Denne applikationssuite er blevet så kompliceret i årenes løb, at befolkningen hos Microsoft til sidst måtte komme med en innovativ tilgang til at styre denne kompleksitet. Resultatet var båndet - en slags dynamisk menulinje, hvor din applikation forsøger at præsentere de mest anvendte og mest nyttige funktioner på ethvert givet tidspunkt afhængigt af, hvad brugeren præcist gør på det øjeblik. Denne tilgang er interessant og hjælper med at styre kompleksiteten i applikationssuite, men samtidig understøtter den afslappede brugers mest almindelige aktiviteter på bekostning af at gøre tingene meget vanskeligere for "strømbrugere" og deres produktivitet. De mest kyndige brugere har en tendens til at have mest problemer med båndet.

Kommandolinjeprogrammer og tastaturdrevne, konsolbaserede, bundne grænseflader kan tilbyde enkel interaktion for afslappede brugere uden at trække tæppet ud under fødderne af mere kyndige brugere. Mange sådanne værktøjer vil give enkle brugsoplysninger ved hjælp af en --hjælpsindstilling, når de påberåbes dem på skallen, eller let adgang til brugshjælp fra en bunden grænseflade via et tastetryk eller to. Begyndere kan nemt lære de rudimentære grundlæggende, og når de lærer mere om, hvordan de bruger det, udvides deres facilitet med applikationen. Simpelheden i grænsefladen kommer aldrig på bekostning af den ekspanderende viden.

5. Stabilt design

Efterhånden som GUI-miljøer udvikler sig over tid, ved at hente nye klokker og fløjter og funktionssæt, skal GUI-applikationer ændres for at passe ind i disse miljøer. Efterhånden som GUI-applikationer bliver mere komplekse med tiden med tilføjelsen af ​​nye funktioner, gennemgår applikationerne mutation, så de aldrig helt fungerer som de gjorde for en version siden. Bagudkompatibilitet er en meget vanskelig præstation med nye versioner af GUI-applikationer af disse grunde og mere. Som et resultat er brugere nødt til at læse om, hvordan deres foretrukne GUI-applikationer fungerer til en vis grad, hver gang de opgraderer. Selvom de aldrig har brug for nye funktioner tilføjet til applikationerne, ændres de gamle funktioner, de bruger regelmæssigt, ofte med frigivelsen af ​​nye versioner. Normalt har de brug for nye funktioner, hvis kun nogle få, men indlæringskurven for ændringer i, hvordan de gamle funktioner bruges, er normalt meget stejlere end for en lille håndfuld nye funktioner, de vil bruge i fremtiden.

Derudover kan den enkle kendsgerning, at brugere har gjort de samme ting på samme måde i lang tid, resultere i, hvad undervisere kalder "negativ overførsel af læring", hvor det, de allerede ved, (i dette tilfælde fra en tidligere version af en applikation ) forstyrrer deres evne til at lære ny viden under lignende omstændigheder. Kommandolinjeværktøjer, især i betragtning af deres typisk enklere design, har ikke en tendens til at lide under dette problem i næsten samme grad. Hvis der skal tilføjes en ny funktion, kræver det normalt ikke, at de gamle funktioner omskiftes, som næsten altid nemt kan fås på samme måde, som de fik adgang til før opgraderingen.

I betragtning af den større mulighed for at binde separate værktøjer sammen på kommandolinjen end i GUI-miljøet, er tilføjelse af nye funktioner til et bestemt værktøj ofte unødvendigt (og uønsket) alligevel, fordi ny funktionalitet simpelthen kan bygges som et nyt værktøj, hvilket giver brugeren mulighed at anvende disse to værktøjer sammen via Unix-rørledningen. Slutresultatet er, at slutbrugeren typisk ikke behøver at bekymre sig om ustabilt softwaredesign, hvor grænseflader og bagenden opfører sig på uventede nye måder, når en ny version af værktøjet frigives.

Betydningen af ​​muligheder

Kommandolinjen er naturligvis ikke egnet til alt . GUI'er og andre bundne grænseflader giver fordele, der er fraværende eller vanskelige at opnå, udelukkende med kommandolinjeværktøjer. Der er faktisk nogle opgaver, for hvilke betydelig ekspertise er nødvendig for endda at møde fordelene ved en kommandolinjetilgang, så enhver inexpert-bruger kun vil blive hindret af manglen på en captive interface.

I de fleste tilfælde er det også vigtigt at have kommandolinjeværktøjer, selv når en captive interface er passende. Faktisk, i mange tilfælde, hvis en captive interface er en god ide, skal den bygges oven på kommandolinjeværktøjer, sådan at den captive interface selv - hvad enten det er en GUI eller en konsolbaseret grænseflade som den, der er leveret af forbannelserne bibliotek på Unix - er kun en tynd finér over hjælpeprogrammer, der også kan aktiveres individuelt fra kommandolinjen eller i et script efter behov.

Der er lille chance for, at GUI overses til fordel for kommandolinjen i den daglige slutbrugers computersoftwaredesign. Mange udviklere synes imidlertid tilfreds med at ignorere vigtigheden af ​​kommandolinjen og fordelene, det kan give for brugerne. En del af grunden til dette er, at brugerne selv ikke er opmærksomme på fordelene ved at bruge kommandolinjeværktøjer. Hvis du er en af ​​disse brugere, kan det være på tide at hente en kopi af den bedste tilgængelige Linux-bog og gøre dig mere bekendt med fordelene ved kommandolinjeværktøjer.

© Copyright 2021 | mobilegn.com