In che modo gli sviluppatori affrontano il problema "da dove cominciare" in un contesto di difficoltà travolgenti causate da troppe informazioni eterogenee? [chiuso]

Question

In che modo gli sviluppatori affrontano il problema "da dove cominciare" in un contesto di difficoltà travolgenti causate da troppe informazioni eterogenee? [chiuso]

#1 da (1 voti)
#2 da (1 voti)

-1

Un mio amico, un programmatore PHP principiante, ha bisogno di collegare il prodotto che la sua azienda sviluppa con un prodotto di terze parti (una serie di servizi web). Ha ricevuto la documentazione "rilevante" (poche centinaia di pagine di materiale illeggibile) da questa terza parte, ha letto la documentazione PHP relativa al client SOAP, ha letto su SOAP e WSDL, ma non ha una minima idea da dove cominciare . Invece di un'esercitazione passo-passo, ha molta documentazione eccessivamente prolissa.

Gli ho suggerito di utilizzare la prototipazione:

Immagina lo scenario di base in cui è possibile utilizzare i servizi Web di terze parti,
Seleziona la documentazione pertinente,
Costruisci (da zero) lo script PHP più semplice che riprodurrà questo scenario,
Una volta che il prototipo funziona, integra la funzionalità nel prodotto esistente,
refactoring,
Espandi il prodotto esistente con funzionalità aggiuntive.

Sebbene ciò possa aiutare a spingere questa persona nella giusta direzione, sento che il mio suggerimento è solo parzialmente utile. Mi immagino sei anni fa senza sapere nulla su WSDL e SOAP e dover cercare all'interno di centinaia di pagine di documentazione: sarei già scoraggiato ai passaggi 2 e 3.

Gli sviluppatori esperti hanno un sacco di schemi, pratiche e processi che aiutano a risolvere i problemi di base che si incontrano frequentemente nello sviluppo del software:

Gli aspetti tecnici di una funzionalità sono incerti? Utilizza la prototipazione.
L'applicazione "non risponde"? Utilizza il profilo per trovare i colli di bottiglia.
I requisiti sono soggetti a frequenti cambiamenti? Usa Agile.
I programmatori devono essere sicuri che il loro codice non contenga omissioni? Utilizza le revisioni del codice.
Le versioni successive di un prodotto non vengono distribuite abbastanza velocemente? Usa DevOps.

Mentre questi modelli e pratiche aiutano gli sviluppatori a risolvere problemi puramente tecnici / organizzativi (come "So come implementare Web Sockets in Java, Python e Node.js, ma ora ho bisogno di farlo in Haskell."), il Stessi schemi e pratiche non sono utili per i programmatori meno esperti che hanno bisogno di risolvere problemi più sostanziali e meno tecnici (come "Credo che i Web Socket siano una specie di HTTP ma succede nell'altro modo, qualcosa del genere; per implementarlo nella mia app, ma non sono sicuro del perché ne abbiamo bisogno. ")

Invitare il programmatore a trascorrere tre anni al college o dodici mesi a leggere libri legati alla programmazione non è sempre un'opzione: alcune persone devono lavorare per pagare le bollette, devono completare il progetto per la prossima scadenza e non vengono pagate leggere libri.

Quindi quali sono le altre opzioni?

methodology patterns-and-practices problem-solving

posta Arseni Mourzenko 02.09.2014 - 23:15

fonte

2 risposte

1

In generale

Rompa ogni problema in N problemi che, se risolti, risolveranno anche il problema più grande, in cui N è il numero di cose che puoi avvolgere in una sola volta.

La "rottura in basso" può consistere in:

informazioni sullo spazio dei problemi ad alto livello
definizione o chiarimento delle condizioni "risolte"
che indica i passaggi o le azioni del problema più grande.

Applica ricorsivamente fino a quando ogni problema è banale.

In particolare

Il tuo amico deve evitare di pensare a SOAP, XML, JSON e tutti gli altri dettagli tecnici fino a quando il problema non si riduce a problemi di cui uno o più sono risolti da quei dettagli. A quel punto, uno o più dei sotto-problemi saranno, X richiede i dati Y da Z usando l'API di Z . Se Z non ha un'API o il tuo amico non sa come utilizzare l'API fornita, ha bisogno di apprendere quel particolare spazio, googling o chiedere ad altri professionisti.

risposta data 03.09.2014 - 02:29

fonte

Leggi altre domande sui tag methodology patterns-and-practices problem-solving

È necessario accreditare l'autore del software rilasciato con la licenza MIT? Quale tipo di stile di architettura assomiglia maggiormente allo stack MEAN? [chiuso]

score 1 · Accepted Answer

La serie di passaggi che hai suggerito sembra molto ragionevole. La maggior parte delle linee d'azione arriverà a partire dalla più piccola unità di interazione tra PHP e la libreria esterna e implementandola, imparando da essa, estendendo l'ambito, implementando, apprendendo, eventualmente ridefinendo, ripetendo. Cioè lavorando dal basso verso l'alto per collegare la libreria esterna al prodotto su cui sta lavorando. In linea di principio, potrebbe anche esserci un modo per avvicinarsi a questo top down, ma questo probabilmente richiederebbe al tuo amico di conoscere più dei mattoni grezzi di cui avrà bisogno, che è il problema nel primo caso, quindi questo è fuori.

Il fatto potrebbe essere che il tuo amico ha semplicemente il compito di qualcosa che non può risolvere anche in un ragionevole lasso di tempo, solo perché al momento non ha abbastanza esperienza / knowhow / abilità (tuttavia potresti voler etichettarlo ). Oltre alla linea guida generale che gli hai dato un lavoro più specifico, potresti aiutarlo a superare la gobba. Sia da te o dai colleghi. Ciò significherebbe parlare del problema specifico con qualcun altro che ha abbastanza ingegneria generale del software sa come convincere un percorso verso una soluzione da lui (che potrebbe essere anche tu), o con qualcuno che abbia abbastanza conoscenze specifiche (es. PHP, SOAP e WSDL) che possono dargli consigli e linee guida dirette per spostarlo.

Questa non è una brutta cosa, solo una parte del crescere nella tua professione scelta. Ho visto molta documentazione trasformata in liste lunghe di "HowTo" da cui è possibile copiare e incollare. Penso che ci sia una capacità di comprendere, astrarre e concludere con una conoscenza incompleta dei nuovi sistemi che incontri (un'abilità che cresce con ogni sistema che incontri). Lo stile di documentazione HowTo non promuove questa abilità. Sembra che il tuo amico stia attraversando la soglia in cui si è laureato usando la documentazione di "HowTo" e potrebbe essere un processo doloroso, ma se lo farà uscirà uno sviluppatore e un ingegnere migliori.