Grandaj Programaj Vortoj aŭ Frazoj

PoŝoprotektantoLaborante kun iuj esceptaj programistoj, mi ofte trovas min en renkontiĝoj kun arkitektoj, gvidantoj kaj programistoj, kiuj (mi pensas) amas ĵeti iujn grandajn vortojn aŭ frazojn tie por provi timigi la produktadministrantojn aŭ iliajn klientojn.

Ĝi estas unu el tiuj aferoj, kiujn programistoj ŝatas fari. Jen dek el ili kun tre simpla priskribo (tio sendube tiros la koleron de programistoj ĉie, dum mi mortigas ilian terminologion per miaj simplaj aŭtomobilaj metaforoj):

  1. Abstraktado - ĉi tio prenas malfacilan procezon aŭ funkcion kaj esence rompas ĝin logike ... ĉu laŭ hierarkio (A apartenas al B, B apartenas al C, ktp) aŭ laŭ trajto aŭ funkcio (koloro, grandeco, pezo, ktp). Abstraktado faciligas objekteman programadon per organizado de la funkcio logike. Por konstrui mian aŭton, mi konstruas kadron, motoron kaj korpon aparte.
  2. Senvalorigo - ĉi tio signifas, ke ekzistas iu malnova kodo en la sistemo, kiu povas resti sed bezonas iom post iom malaperi. Kiam kodo estas malrekomendata, programistoj ne aludas la kodon aŭ uzas pli novan kodon ĝis ĉiuj referencoj pasas al la malnova, tiam ĝi devas esti forigita. Foje, se ĝi estas funkcio, kiu foriras, vi povas konservi ĝin dum iom da tempo per averto al viaj uzantoj, ke ĝi foriros. Mi ricevas novan stereosistemon kun nova drataro sed mi forlasas la malnovan drataron kaj ne uzas ĝin.
  3. Enkapsuligo - ĉi tio estas la procezo organizi viajn programajn funkciojn ene de gepatro kiam la funkcio ne atingas aliajn partojn de la sistemo. Se vi havas milionojn da funkcioj, vi volas havi ilin efike organizitaj kaj funkciantaj en la regionoj, kiujn ili funkcias anstataŭ disponigi ilin tutmonde. Mi metas la subtenan meicsanikon de la motoro en la motoran kupeon ... Mi ne metas la oleo-filtrilon sur la malantaŭan seĝon.
  4. heredaĵo - ĉi tio estas la kapablo alpreni la propraĵojn de alia komuna kodo (klaso) por reuzi ĝin por nova funkcio sen devi reskribi ĝin. Heredo estas alia bona objektorientita disvolva praktiko. Mia aŭta seĝo povas esti uzata por porti infanon aŭ plenkreskulon - kiu ajn sidas en ĝi.
  5. Normaligo - ĉi tiu estas la metodo organizi datumojn pli efike en datumbazo per konstruado de referencoj. Ekzemplo estus se mi devus registri trafiklumojn la tutan tagon ... ruĝa, flava kaj verda. Prefere ol skribi ĉiun diskon per ruĝa, flava kaj verda - mi skribas 1, 2 kaj 3 kaj tiam faras alian tablon kie 1 = ruĝa, 2 = flava kaj 3 = verda. Tiel mi nur registras ruĝan, flavan kaj verdan unufoje. Ĉiu el miaj aŭtopordoj havas la saman pordan tenilon. Unu tenilo, uzata en 4 malsamaj lokoj anstataŭ 4 malsamaj teniloj.
  6. Objektorientita - en modernaj programlingvoj, ĉi tio estas projekta metodo, kiu ebligas al vi verki specifan kodon laŭ pecoj, laŭ funkcio, kaj poste reuzi ilin. Ekzemplo estus, se mi volus kontroli pri valide konstruita retpoŝta adreso. Mi povus konstrui la funkcion unufoje, kaj tiam uzi ĝin kie ajn mi bezonas en mia aplikaĵo. Mia aŭto havas 18 ″ -randojn, kiujn povas uzi aliaj aŭtoj de la sama aŭ aliaj fabrikantoj.
  7. Polimorfismo - Ĉi tiu malfacile klarigeblas, sed esence ĝi estas la kapablo disvolvi kodon dinamike uzeblan por aliaj situacioj. Alivorte, ĝi povas heredi unikan kaj dinamikan funkciecon simple per la maniero kiel ĝi estas referencita. Ĉi tio estas tre efika disvolva rimedo. Mi povas uzi la elektran elirejon de mia aŭto por ŝargi mian telefonon aŭ provizi sukon al mia pneŭpumpilo.
  8. rikuro - ĉi tio estas metodo, kie kodo referencas sin. Fojfoje ĝi estas efika kaj intenca, sed alifoje ĝi povas fini spiraligante viajn aplikaĵojn. Mi klakas serĉi mian aŭton-stereofonon kaj ĝi trapasas la radiostaciojn. Ĝi neniam finiĝas, nur daŭras.
  9. Refaktorigado - jen la procezo de reskribado de kodo por plifaciligi ĝin sekvi aŭ organizi ĝin pli bone sed ne nepre aldoni pliajn funkciojn. Mi rekonstruas mian motoron.
  10. Servila Orientita Arkitekturo (SOA) - prenu programon orientitan al objektoj kaj apliku ĝin al grandaj sistemoj, kie vi povas havi tutajn sistemojn, kiuj plenumas iujn funkciojn. Vi eble havas klientan administran sistemon, kiu parolas al komerca sistemo, kiu parolas al ekspeda sistemo, ktp. Mi tiras antaŭfilmon kun mia aŭto por sendi aĵojn de unu loko al alia. Mi uzas trailor-problemon (XML) por konekti ilin.

Mi konstatas, ke miaj metaforoj ne estis ĉiam perfekte celataj. Mi esperas, ke ili tamen iomete helpis!

Iuj konsiloj, kiam vi aŭdas ĉi tiujn vortojn en via sekva renkontiĝo kun programisto ... ne kuru reen al via sidloko kaj rigardu ilin Vikipedio, ili rigardos. Ne tremu, ili atakos. Jen kion fari ... pripensu la fenestron kvazaŭ vi profunde pripensas kaj poste rigardu malantaŭen kun esplora aspekto aŭ gratu vian mentonon. Atendu, ke ili sekvu sian deklaron per pli da informoj.

... Ili rigardas.

8 Komentoj

  1. 1

    LOL, vi vere najlis ĝin Doug 🙂 Ĉu vi provas eksigi nin? Vi scias diable bone, ke ni celas, ke tiuj konceptoj ne estas komprenataj kaj tial havas manieron kun klientoj. Nun ni devas eltrovi manieron preterpasi ilin kombinante tiuj kapvortoj por krei unu gigantan frazon, kiu povas tiel:

    Nu, vi scias, ke la funkcio, kiun vi provas enmeti, povas esti abstraktita al multaj objektoj, kiuj enkapsuligas la funkciadon kaj komunikas per servo-orientita arkitekturo.

  2. 5

    Estante programisto, mi povas estimi ĉi tiun afiŝon. Ni tamen ne tiom malbonas 😉 Mi neniam petolus homojn kun tia tekno-babilado 🙂

    Lasu min provi kaj pripensi ankoraŭ kelkajn vortojn por vi ....

Kion vi pensas?

Ĉi tiu retejo uzas Akismeton por redukti spamon. Lernu, kiel via komento datiĝas.