Regole della struttura. Imparare a strutturare i programmi, esplorare le possibilità, gli errori, le soluzioni, ecc. - pagina 4
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
E cosa succede alla vostra chiara struttura se a metà, o anche più vicino alla fine del progetto, il cliente cambia improvvisamente:
Questo è un buon test di quanto il vostro progetto sia pronto e resiliente al cambiamento.
Questo è il problema, ed è il motivo per cui sono in questo thread.
Voglio trovare una risposta su come progettare (o come stipare il cliente in un tale quadro), in modo che entrambi i suoi desideri siano soddisfatti e il progetto non sia rotto.
SZY perché la moneta ha due lati, con uno si può cambiare il progetto, con un altro si può dire "No come parte di questo progetto non può fare," la verità è da qualche parte nel mezzo.
La cosa migliore è progettare lo sviluppo in modo tale che la maggior parte dei desideri essenziali del cliente siano realizzabili.
Nessun programmatore normale disegna diagrammi di flusso al giorno d'oggi. Tutte queste sono sciocchezze teoriche pensate per essere insegnate agli scolari, ma non per lavorare in progetti reali.
Tutto dipende da cosa mettere sulla carta.
Non sono a favore della scrittura, ma a volte è necessario redigere una struttura generale su carta. È conveniente e veloce, è come uno schizzo per un gioielliere, il quadro generale dovrebbe essere chiaro.
Forse è per questo che ci sono molti programmatori non normali, perché non disegnano diagrammi di flusso.
Al giorno d'oggi, nessun programmatore normale disegna diagrammi di flusso. Tutte queste sono sciocchezze teoriche progettate per insegnare agli scolari, ma non per lavorare in progetti reali.
Al giorno d'oggi, nessun programmatore normale disegna un diagramma di flusso.
Credo che sia per questo che ci sono molti programmatori anormali, perché non disegnano diagrammi di flusso.
Non la chiamerei così nettamente "sciocchezza teorica". Disegnare "quadrati con frecce" sulla carta è ampiamente usato nella programmazione, prendete UML per esempio - pieno di "frecce con quadrati". :) Quindi, anche gli schemi a blocchi nelle fasi iniziali possono essere utili...
Ho provato a progettare con UML, non ha senso (IMHO).
Tutti questi quadrati e frecce li posso tenere perfettamente in testa, ma le astrazioni non mi entrano in testa, quindi le abbozzo.
HI Se si scava più a fondo, il cervello umano è adatto a memorizzare immagini, mappe, modelli di comportamento, ma non a costruire astrazioni, l'astrazione è la cosa più difficile che una persona possa fare.
Così l'umanità ha sempre cercato di formalizzare l'astrazione in qualcosa di più familiare.
Il cervello umano è adatto a memorizzare immagini, mappe e modelli di comportamento, ma non a costruire astrazioni; le astrazioni sono il compito più difficile per gli esseri umani.
ZZZI Ecco perché l'umanità si sforza sempre di formalizzare l'astrazione in qualcosa di più familiare.
Sono d'accordo.
Ho i miei metodi per ricablare il mio cervello in quest'area, ho anche lo sviluppo di un software (che posso condividere all'occasione), ma lo sviluppo è molto lento (anche se evidente col senno di poi).
--
In un certo senso, tutta e qualsiasi programmazione è un lavoro di astrazione, ma c'è un'enorme variazione nel livello e nell'abilità della gestione pratica dei concetti astratti.
Sono d'accordo.
Ho i miei metodi per affinare il mio cervello in quest'area, ho anche degli sviluppi software (posso condividerli all'occasione), ma lo sviluppo è stato molto lento (anche se evidente col senno di poi).
--
In un certo senso, tutta e qualsiasi programmazione è un lavoro con astrazioni, ma c'è una grande differenza nel livello e nell'abilità dell'uso pratico delle astrazioni.
Non siamo interessati all'astrazione per l'astrazione, vero?
Penso che dal momento che non siamo evolutivamente più adatti all'astrazione ?! (discutibile, almeno meglio degli altri abitanti di questo pianeta), dovremmo cercare di costruire stampelle.
Per esempio, la gente ha inventato una tecnica come il brainstorming.
Spesso ho problemi a nominare un'entità, dandole un nome succinto che sia abbastanza comprensibile ed estremamente breve. Quando questo riesce, l'astrazione è facilmente assimilabile.
Scusa, non posso scrivere molto adesso (non è conveniente farlo da un cellulare), non avrò tempo di farlo quando arriverò lì. Non posso scrivere molto ora (non è conveniente al telefono) e non avrò il tempo.
Scusa se non posso scrivere molto adesso (non è conveniente dal mio cellulare), non avrò tempo quando arriverò lì. Meglio domani.