2008-10-04 3 views
19

Ho letto il libro di Richard P. Gabriel "Patterns of Software" (pdf) che contiene un saggio chiamato "Writing Broadside" in cui afferma che i programmatori dovrebbero sviluppare la loro capacità di scrivere in modo chiaro. Ho trovato che i suoi suggerimenti hanno sicuramente migliorato la mia capacità di scrivere specifiche tecniche e documenti di progettazione.I programmatori dovrebbero essere in grado di scrivere in modo chiaro?

Uno dei suoi suggerimenti è di sviluppare laboratori di scrittura sul posto di lavoro. Che ciò contribuirà a migliorare la tua capacità di esprimerti chiaramente durante la documentazione dei tuoi progetti.

Abbiamo già un sistema in cui, una volta alla settimana, un membro del team dà un discorso su Pecha Kucha a qualsiasi argomento per migliorare la nostra capacità di offrire presentazioni.

Quindi sto pensando di suggerire anche i workshop di scrittura.

Qualcuno ha laboratori di scrittura sul proprio posto di lavoro?

"Un uomo che ha la conoscenza ma manca chiaramente del potere per esprimerlo non è meglio che se non avesse mai avuto alcuna idea." - Thucydides

Modifica: Quello di cui sto parlando è la possibilità di documentare il codice in modo chiaro, ad es. specifiche tecniche e documenti di progettazione. Non la scrittura del codice sorgente stesso.

+0

@ Rob, hey non mi riferisco a smuovere le acque, io sono solo un po 'confuso. Hai detto che non stai parlando di codice, BUt nei commenti del mio post hai fatto riferimento al commento di Mitch (che riguardava il codice) e hai detto che era di questo che stai parlando. Cos'è questo? – mattlant

+0

@mattlant, per favore leggi di nuovo la risposta di Mitch. Elements of Style è una bibbia sulla scrittura chiara. Non codifica L'altro punto di Mitch riguarda il buon naming delle variabili e sta facendo notare che se non riesci ad esprimere bene le idee ottieni variabili come "x1" invece di "current_balance" più descrittivo. –

+0

OK, capisco cosa intendi con quello. Ma immagino che è dove vorrei continuare a non essere d'accordo. Ti capisco di essere bravissimo a scrivere quei nomi descrittivi, ma ho una scarsa padronanza di mettere tutto ciò in un inglese meraviglioso che tutti possono leggere. L'hai detto anche tu. Il mio unico punto di tutto questo era ... – mattlant

risposta

20

obbligatorio Dijkstra citazione:

Oltre un'inclinazione matematica, una eccezionale padronanza della propria lingua madre è il bene più vitale di un programmatore competente.

+1

La padronanza della parola e la padronanza della scrittura sono due cose diverse, e una può essere superiore su una e non sull'altra e viceversa. – mattlant

20

Sì! Sicuramente.

Uno dei maggiori problemi che vedo nel codice è l'incapacità di nominare le cose con precisione. Questo può spesso essere dovuto all'incapacità di esprimere le proprie idee.

Una grande risorsa per migliorare le capacità di scrittura è: The elements of Style. È piccolo, succinto e facile da leggere.

6

Quello che facciamo è lasciare che i colleghi facciano una presentazione ogni settimana, principalmente su argomenti tecnici, in modo da ottenere anche una formazione avanzata.

Immagino che questo non solo alleni la capacità di esprimere te stesso, ma rafforza anche la squadra e la comunicazione all'interno della squadra.

Migliora davvero la produttività se i membri del team sanno come esprimersi, anche per cose minuscole come la differenza tra "parametri" e "argomenti".

-4

il mio pensiero:

A, il più importante, penso che uno sviluppatore deve essere in grado di scrivere chiaro, conciso, bello, codice di autoregolamentazione documentare. Questo è molto più importante della scrittura di documenti.

B, i test dell'unità devono essere chiari e concisi e una documentazione su come utilizzare il codice.

C. Una parte di questo dipende. Se sono programmatori di livello molto basso che lavorano su piccole parti di codice, A + B stand, Tuttavia, se sono di alto livello, o lavorano su gran parte del sistema, o l'intero sistema, allora sì diventa più importante che essi sapere come scrivere in modo chiaro e corretto, ma in una certa misura.

In breve, penso che sia importante, ma non è la misura di quanto sia buono un develper. Quanto bene il codice documenta se stesso è la vera misura.

Inoltre, se ogni sviluppatore potesse scrivere documenti, gli scrittori tecnici sarebbero senza lavoro.

Per quanto ne so, qualsiasi risorsa o cosa suggerire, no, non ho mai veramente cercato di migliorare le mie capacità di scrittura.

EDIT: Dovrei aggiungere anche se alcuni di questi dipendono dal processo che si utilizza e da quali ruoli e responsabilità può avere uno sviluppatore. Ovviamente se è necessario che gli sviluppatori scrivano parte del manuale utente, allora sì, scrivere chiaramente è MOLTO importante. Ma di solito non è la norma.

EDIT2: Niente di tutto questo è destinato a dire che un devloper non dovrebbe avere alcuna capacità di scrittura, era più dire che codice scrittura è molto più importante di Tech/doc scrittura.

Edit3: Ora che è stato chiarito che il doesnt OP vuole alcun riferimento alla scrittura di codice, allora devo dire che no, in generale non è molto importante per uno sviluppatore per essere in grado di scrivere documentazione tecnica e documentazione di progettazione, poiché ci sono cose molto più importanti per uno sviluppo da essere bravo a farlo.

+1

Essere in grado di scrivere chiaramente ed esprimere idee, non significa necessariamente scrivere documenti. È ancora in codice. –

+0

e per favore dimmi cosa ho detto che neutralizza quello che hai detto? "Il più importante, penso che uno sviluppatore debba essere in grado di scrivere un codice chiaro, conciso, bello, autodocumentante." – mattlant

+0

LEGGI LA DOMANDA! "Ho trovato che i suoi suggerimenti hanno sicuramente migliorato la mia capacità di scrivere documenti tecnici e di spec." "faceva parte di ciò che mi dice che l'OP stava facendo molto più del codice. – mattlant

2

Gli sviluppatori di software sono molto simili ai professionisti di qualsiasi altra area o settore dovrebbero essere in grado di esprimere i propri pensieri e le proprie idee.

Lo sviluppo del software è uno sforzo di squadra e la comunicazione è il fattore più importante che può causare il fallimento del progetto. Tanto più oggi gli sviluppatori di progetti comunicano con vendite, marketing, uomini d'affari, utenti e altri come non hanno idea di come sviluppare software. E la capacità di comunicare idee e inclinare gli altri verso di loro è un'abilità molto critica.

Inutile dire che se Tech Lead ha creato un design brillante ma non è in grado di comunicare il suo progetto al resto del team, ciò significa che non si dispone di.

+0

Aha, ma un lead tecnologico è molto diverso da un * programmatore * come generalizzato dall'OP – mattlant

+0

Il lead tecnologico è un po 'diverso dal semplice sviluppatore, ma l'idea generale è ancora valida: se hai o vuoi avere idee che altri ti seguiranno deve essere in grado di comunicarli. La citazione da Tucidide nella domanda originale cattura tutto. –

+0

In effetti, ma in molte grandi aziende, le idee di * programmatore * non vengono ascoltate. Questo sta lentamente cambiando, specialmente con le grandi quantità di piccole organizzazioni, ma a quel punto direi che non sono più un programmatore. – mattlant

0

Qui in Argentina dobbiamo comunicare con i nostri amici negli Stati Uniti per portare a termine il nostro lavoro.

Il modo principale di comunicazione è email e IM. Non immagineresti quanto sia difficile capire un sacco di email a causa della mancanza di buona scrittura. E non sto parlando di cose tecniche difficili, ma solo come esprimerti in un inglese semplice.

Quindi sì. Penso che sia il molto importante.

3

@slashmais: chiunque in qualsiasi tipo di capacità professionale dovrebbe essere in grado di comunicare chiaramente, sia esso ingegnere, manager, tester o quant'altro. Questa non è solo una preferenza personale, lo credo per il bene di un'organizzazione o di un business. Non vuoi programmatori la cui unica funzione è quella di implementare e scarsamente documentare il codice; volete ingegneri che possano riflettere profondamente sul codice e comunicare l'intenzione ad altri in un mezzo esterno al codice.

Quello che facciamo nella mia azienda è una presentazione tecnica settimanale di un ingegnere su un argomento a loro scelta. Questa è una grande vittoria per tutti - aiuta l'ingegnere ad affinare le loro capacità di parlare e scrivere e ci istruisce su quello che stanno facendo. Abbiamo anche revisioni del codice in cui la documentazione del codice è criticata tanto quanto il codice stesso. Ciò porta a un codice molto più gestibile.

Non importa se si tratta di messaggistica istantanea, posta elettronica, documenti scritti o codice - meno tempo ho da spendere cercando di analizzare la comunicazione e più tempo spendo per realizzare le cose come risultato della comunicazione, meglio è per la mia compagnia.

2

Sì, i programmatori dovrebbero documentare il proprio lavoro; costruiresti una casa da un modello in scala di un ottavo e confida che i progetti non fossero necessari?

Vale la pena leggere: Steve McConnell Code Complete, in particolare i capitoli sulle funzioni di denominazione e la documentazione di scrittura. Se stai nominando e commentando il tuo codice in modo appropriato, i documenti si scrivono da soli.

2

La comunicazione è essenziale in qualsiasi professione, l'ingegneria del software e la programmazione di computer non fanno eccezione. Non importa quanto sia brillante la tua idea se non riesci a comunicarla efficacemente a colleghi, manager e clienti. Puoi avere la stessa influenza con un testo ben scritto come con un codice ben scritto.

Un buon esempio che sono sicuro è familiare alla maggior parte delle persone che leggono questo è il famoso libro K & R. A mio parere, uno dei motivi per cui C è diventato un linguaggio di programmazione così importante è perché Kernighan e Ritchie hanno prodotto un libro ben scritto. Se avessero prodotto un manuale che era tipico dello stile dei manuali del compilatore in quel momento, invece di un testo facile da seguire, succinto e in competizione dubito che C sarebbe diventato tanto dominante quanto lo è stato.

+0

Questo è un cattivo esempio. K & G erano al di sopra del livello di "programmatore" – mattlant

1

Il compito di programmazione coinvolge due parti principali. Il primo è comunicare con una macchina che cosa stai cercando di fare con il tuo codice. Questa è la parte facile, il compilatore/interprete/macchina virtuale fa la maggior parte del lavoro lì. La parte difficile è comunicare agli altri programmatori cosa stai cercando di fare con il tuo codice.

A causa dell'aspetto umano della programmazione, è fondamentale che tu sia uno scrittore efficace per essere un programmatore efficace. Far funzionare le cose non è abbastanza buono, le persone che vengono dopo aver bisogno di essere in grado di capirlo e lavorare con esso altrettanto bene.

Avere una buona capacità di scrittura può aiutarti a scrivere codice in un modo più naturale (anche se ci sono dei pit-down per le lingue naturali, quindi usali come appropriato). Ti aiuterà anche a documentare, commentare e spiegare meglio quel codice.

Come ha detto Blair Conrad, nominare le cose è anche importante ed è notevolmente avvantaggiato dall'avere migliori capacità di scrittura. Ciò che chiamate le cose ha un impatto sul modo in cui le persone pensano a loro. Se altri programmatori riescono a capire come è stato concepito il codice, hanno una migliore possibilità di usare quel codice come previsto.

0

Sì,


Ma scrivere chiaramente non è lo stesso che avere l'ortografia e la grammatica impeccabile.

Per quanto buona sia l'ortografia, la loro scrittura sarà difficile da capire se non possono ordinare i loro pensieri in modo logico e decidere quali dettagli sono importanti da includere (e lasciare fuori).

Un breve commento che è al punto è molto meglio di un lungo commento con una grammatica senza errori che non ha colpito il punto.

Se desideri passare alla gestione, la possibilità di scrivere rapidamente documenti lunghi con ortografia e grammatica perfette diventa molto più importante.

Ricorda tutto su come sia facile capire che cosa intendi, non come gli piace il tuo stile di scrittura.

La grammatica senza errori non è sempre il modo migliore di comunicare, ad es.

“Questo è il tipo di inglese con che non voglio mettere.”