Quali considereresti gli strumenti del flusso di lavoro delle migliori pratiche per lo sviluppo di applicazioni Web (PHP)? [chiuso]

Spero davvero che qualcuno con più esperienza possa modificare la domanda secondo i miei esempi di risposte:

• utilizzando il controllo versione
• sviluppo guidato dai test
• codice di debug (xdebug per php)
• utilizzo di diagrammi UML
• utilizzo di OOP per codice gestibile e riutilizzabile
• utilizzo di framework (come Zend Framework per php) per un rapido sviluppo delle applicazioni

Qualcos'altro o un'elaborazione di ciò che ho menzionato sopra?

Fondamentalmente, sono nel mezzo della formazione di un team di sviluppatori (sono anch'io uno sviluppatore) e vorrei alcuni consigli su come programmatori / designer professionisti ecc. Dovrebbero lavorare insieme e quali standard / paradigmi dovrebbero usare.

Inoltre, se qualcuno ha qualche libro o link sull'argomento, mi farebbe piacere!

Ho trovato questo che credo soddisfi ciò che sto cercando, o almeno parte di esso:

http://www.ibm.com/developerworks/websphere/library/techarticles/0306_perks/perks2.html

utilizzando il controllo versione

SVN è molto comune, ma mercuriale è più bello, potente e ha un solido supporto per la GUI.

sviluppo guidato dai test

bene, se fai test di unità sei già dalla parte dei vincitori. per gli strumenti, è una questione di scelta. il test deve essere il più semplice possibile, ecco il motivo per cui ho abbandonato PHPUnit per SimpleTest.

codice di debug

con i unit test difficilmente avrai bisogno di xdebug. di solito uso xdebug solo per la profilazione. (controlla KCachegrind tra l'altro)

utilizzo di diagrammi UML

il problema più grande con tutto ciò che riflette la logica del codice è che è un sacco di lavoro manuale da mantenere sincronizzato. puoi automatizzare alcune attività, ma non è così utile, perché di solito vuoi usare uml prima di avere qualcosa. l'altro problema è che gli strumenti del diagramma sono molto più difficili da usare rispetto a carta e penna o una lavagna. usa uml se devi comunicare un problema con più sviluppatori o se hai bisogno di un'astrazione per te stesso. ("dia" è un bel strumento gratuito. Anche gli strumenti di mappatura mentale sono molto utili per il brainstorming, alcuni possono effettivamente competere con carta e penna.)

utilizzo di OOP per codice gestibile e riutilizzabile

beh, oop funziona in una certa misura. :) un buon consiglio: composizione> eredità. l'ereditarietà è un potente strumento da riutilizzare a prima vista, ma la manutenzione e l'accoppiamento lento ne risentiranno. secondo buon consiglio: manutenzione> riutilizzo. un sistema astratto può essere molto potente, ma anche difficile da mantenere.

utilizzo di framework (come Zend Framework per php) per un rapido sviluppo delle applicazioni

RAD è una buona cosa per far uscire la tua app in anticipo. ma alcuni componenti, in particolare ORM, spareranno ai tuoi piedi, almeno se si tratta di scalabilità. il problema principale qui è che si collega la logica del dominio per lavorare con gli oggetti, il che diventa molto difficile da considerare se è necessaria una soluzione ottimizzata per il database scalabile puro. essere consapevoli di ciò e incoraggiare gli sviluppatori a utilizzare il database senza livelli di astrazione di alto livello. l'astrazione del database è un mito, orm è una bugia.

BACIO

i nuovi arrivati ​​di solito vogliono applicare tutte quelle migliori pratiche in circolazione, impostare standard di codifica, utilizzare tutte le belle catene di strumenti, qualunque cosa. funziona per alcuni sviluppatori, ma alcuni si imbatteranno in un blocco mentale se le cose sono troppo rigide. unit test e scm è davvero un must, ma qualcuno che non conosce test di unità ha davvero bisogno di imparare il suo valore prima di amarlo. non esagerare, applicare le pratiche passo dopo passo e vedere come funziona. KISS si riduce anche al codice. a volte il modo migliore per risolvere un problema difficile è risolverlo in modo errato. hai bisogno di un algoritmo di sei gradi di separazione ? scegli alcuni amici a caso. puoi creare un'applicazione completa attorno ad essa, con logica errata. se alla fine il cliente decide di abbandonarlo, tutti risparmiano un sacco di soldi.

agile

conoscere metodologie agili, programmazione estrema, scrum, ecc. ci sono molti libri là fuori. qualsiasi libro renderà la tua squadra migliore, ma è il migliore per coinvolgere ogni compagno di squadra.

• Controllo versione: Se su Windows, TortoiseSVN è il migliore, più intuitivo e più facile da usare nella mia esperienza.

• Framework: CodeIgniter . Mani sulla migliore piattaforma di sviluppo web per PHP.

• IDE: Netbeans è l'IDE migliore per PHP che ho usato su Windows.

• Unit test: ci sono diverse opzioni, una ricerca su Google ne farà apparire molte. CodeIgniter ha anche un proprio tester di unità disponibile.

• Debugger: Xdebug.

• Libreria Javascript: Jquery

• Programma FTP: FileZilla

• Amministrazione database: PhpMyAdmin

• Wireframing: Balsimus Mockup o usa una lavagna.

• Varie: utilizzare WAMP su Windows per installare, avviare, arrestare e riavviare facilmente apache, mysql e php in un unico pacchetto.

Inoltre, se hai intenzione di lavorare su molti siti Web diversi e la maggior parte di questi siti Web avrà alcune funzioni comuni come iscrizione, accesso / disconnessione, una sezione di amministrazione per la ricerca di utenti, ecc., Raccomando di creare un piccolo progetto in qualsiasi framework si sceglie e si utilizza quel progetto come base per ogni nuovo progetto che si avvia. Normalmente chiamo questo progetto "scheletro". Se inizierò a lavorare su xyz.com, copierei la directory skeleton e la rinominerei come "xyz.com", compilerei alcuni file di configurazione e avrei una copia di xyz.com con alcune delle funzionalità già funzionante.

Concordo principalmente con il post di Click Upvote, tuttavia se stai lavorando su un sito relativamente grande, consiglierei vivamente di utilizzare il framework Symfony associato all'ORM di Doctrine.

Se il tuo progetto è previsto per il prossimo anno, direi che prendi il tempo per investire in Symfony2 e Doctrine2.

Inoltre, non posso sottolineare abbastanza l'importanza di sviluppare su un sistema basato su Unix, Ubuntu è la mia preferenza e un ottimo web server. Lavoro principalmente su Windows, ma sviluppo su Ubuntu in esecuzione in una macchina virtuale VMWare sul mio desktop (o server quando sono al lavoro).

Per quanto riguarda IDE, consiglio vivamente di utilizzare NuSphere PHPEd o Storm PHP, purtroppo come tutte le grandi cose che non sono gratuite.

L'uso del diagramma UML è piacevole ma è del tutto facoltativo. Tutti i diagrammi farebbero finché il tuo team capirà cosa significano. Cercare di usare lo standard nessuno lo sa davvero bene può portare a problemi e perdita di tempo.

Consiglierei di iniziare ogni pagina da un mockup ( http://balsamiq.com ) o di far disegnare il tuo designer per te. Non aspettarti che gli sviluppatori siano bravi in ​​estetica visiva e creino buone pagine dal nulla.

Chiedi a qualcuno di assegnare il compito di revisione del codice, se hai diversi membri del team seniour: fai fare le revisioni a rotazione ( Review Board )

Quando si tratta di lavoro collaborativo è necessario:

• usando il controllo versione: penso che Git o Subversion funzioneranno abbastanza bene

• sviluppo guidato dai test: sto iniziando a capire che questo è un must, ma non portarlo agli estremi

• codice di debug (xdebug per php): xdebug è la mia scelta

• utilizzo di diagrammi UML: questo aiuta quando tutti hanno una conoscenza pratica dei modelli di programmazione e progettazione OO, tuttavia è sempre una buona pratica

• uso di OOP per codice riutilizzabile e mantenibile: E FLESSIBILITÀ, penso che questo sia l'aspetto chiave di OOP.

• utilizzo di framework (come Zend Framework per php) per un rapido sviluppo delle applicazioni: My Advise è SYMFONY, il primo framework php (non è un toolkit). Ha una comunità molto grande, molta documentazione ed è interamente implementato su php. Ci lavoro da un anno e si lega totalmente con OOP

• potrebbe anche essere necessario un sistema per tracciare bug, richieste di funzionalità, ecc. Come: Mantis o Track . Questi sistemi sono abbastanza facili e diretti. Ti consentono anche di associare la tua sovversione e di mettere in relazione i tuoi impegni con determinate funzionalità o bug pubblicati dalle persone.

Infine, è sempre importante che tu stia guidando un team di sviluppo a tenere periodicamente piccole riunioni in modo che tutti conoscano lo stato del sistema a un certo punto e forse in questo modo sarai in grado di pianificare o vedere come funzionano le cose.

Nella mia azienda devo inviare un'e-mail ogni giorno raccontando su cosa sto lavorando e se là dove ci sono delle complicazioni.

Buona fortuna!

• Framework : codeigniter, senza dubbio. Ha tutte le funzionalità di cui potresti mai aver bisogno e non ti obbliga a usarne nessuna a meno che tu non ne abbia bisogno;
• Controllo versione, IDE : sono piuttosto vecchio stile, e non credo che la mia risposta possa davvero aiutarti;
• Wireframing, UML : anche la vecchia scuola in questo, ma davvero: le lavagne vincono. Sono flessibili, estensibili e supportano qualsiasi convenzione che ritieni opportuno;
• Amministrazione del database : phpmyadmin;
• Sistema operativo server di sviluppo : potrei essere banale, ma: Ubuntu. Installa un server LAMP in pochi secondi; non preoccuparti di aggiungere nuove librerie (il temuto imagick: un comando, fatto); se ti piace PHP probabilmente finirai per lavorare su server linux in produzione, quindi è meglio iniziare a esercitarsi. (Dichiarazione di non responsabilità: Ubuntu non è la mia distribuzione preferita).
• Varie : grep può essere incredibilmente utile durante il debug del codice di altre persone (vuoi sapere quanti controller usano un determinato modello? Fatto!).

modificare

Ho dimenticato la cosa più importante: le specifiche. Scrivi specifiche reali per il tuo progetto prima di toccare qualsiasi codice. Tieni a mente tutti i diagrammi di interazione dell'utente. Ti farà risparmiare secoli.

Controllo della versione Dato che lavori in gruppo, è nel tuo interesse che vai con qualcosa di distribuito. I tuoi candidati sono Git e Mercurial. Ciò significa che il tuo team può impegnarsi localmente senza interrompere il progetto, ma comunque tenere traccia del proprio lavoro, quindi inviare questi commit al server centrale. È anche molto più veloce e presenta meno conflitti di unione poiché il codice viene monitorato come set di modifiche anziché come revisioni. Leggi però la guida di hginit (scritta dal co-fondatore dello stack overflow non meno) e capirai un po 'di più su cosa sia un DVCS. http://hginit.com/

È inoltre necessario utilizzare il repository per la distribuzione anziché rsync o ftp.

Sviluppo guidato dai test A seconda di cosa stai facendo, i test possono perdere molto tempo. Non sto dicendo che dovresti saltare completamente, per i progetti più piccoli è sovraccarico. Se stai scrivendo una biblioteca o un grande progetto a lungo termine, assicurati di scriverne dei test. I test aiuteranno nella fase di manutenzione. Tieni presente che TDD non riesce a trovare tutti i tuoi bug. Ci saranno problemi di esperienza dell'utente, problemi di layout, problemi di prestazioni e così via.

Il debug di Xdebug è praticamente l'unica scelta qui. Si integra bene con Netbeans. Se si sente la necessità di stampare le variabili, è necessario utilizzare un file di registro. Utilizzare la funzione di log dei framework, questo è molto più sicuro in produzione.

Pianificazione / Diagrammi Se si utilizza un buon framework non è necessario creare diagrammi troppo dettagliati. Mantenerlo semplice e lavorare in cicli di rilascio più brevi, è facile pianificare in eccesso. I requisiti e le specifiche di un progetto sono destinati a cambiare, quindi non ci passerei tutto il tempo su. Ricorda che il codice IS specifica al livello più dettagliato.

Usa il tuo strumento di tracciamento dei bug (vedi sotto) per suddividere la specifica in attività che puoi assegnare ai membri del team. Usa uno strumento centrale per documentare i progetti, probabilmente il tracker dei bug avrà un wiki.

È possibile utilizzare uno strumento come Mysql Workbench per progettare schemi di database in diagrammi ed esportarli come SQL.

Frameworks e OOP Questa è probabilmente la parte più importante. Trova te stesso un framework popolare che supporterà lo sviluppo rapido e il riutilizzo del codice. Ad alcune persone non piacerà che lo dica, ma una struttura dovrebbe dettare il modo in cui lavori. Dovrebbe fornire una struttura in modo che uno sviluppatore possa cambiare progetto e sapere esattamente dove si trova il controller per una determinata pagina, esattamente quali sono le variabili del modello e come interrogare il modello. Alcuni framework consentono troppa flessibilità qui e scoprirai che gli sviluppatori non usano sempre il framework allo stesso modo. Mi piace la filosofia del pitone; dovrebbe esserci un modo ovvio per fare tutto. Questo è il motivo per cui mi piacciono il django e le rotaie, sono piuttosto supponente e questo significa che posso guardare il codice di qualcun altro e capire cosa fa. Symfony sembra l'opzione migliore qui,

Esistono molte domande "what framework" su overflow dello stack come questa: /programming/2648/what-php-framework-would-you-choose-for-a-new-application-and-why

Tracciamento dei bug Trasforma il tuo team in un buon tracker di bug creato per gli sviluppatori. Non usare qualcosa di semplificato come il campo base. Redmine e Unfuddle sono due esempi di eccellenti bug tracker, possono anche tenere traccia del tempo e integrarsi con i tuoi repository. Il tuo team dovrebbe utilizzare questo strumento per comunicare sui problemi anziché tramite e-mail o messaggistica immediata. Semplifica il lavoro di un nuovo sviluppatore quando è disponibile una cronologia di bug e documenti. Questo articolo spiega esattamente cosa deve fare un buon tracker di bug e perché. http://www.joelonsoftware.com/articles/fog0000000029.html

Consiglierei di guardare Bazaar per il controllo della versione. Rispetto a Git ha il grande vantaggio di essere effettivamente facile da usare e da installare su Windows, Mac OS e Linux. Anche i comandi bzr sono molto simili alle sue controparti svn, quindi qualcuno che ha già lavorato con Subversion può facilmente usare Bazaar senza una gran parte della curva di apprendimento. Ti sto guardando Git.

A parte questo, credo fermamente nel non forzare nulla sui tuoi sviluppatori. Detto questo, lascia che usino l'IDE, il sistema operativo e così via che preferiscono.

A parte ciò, ti consiglio vivamente di eseguire test di wirte per tutto il codice, non importa quanto sia noioso.

La decisione a favore o contro un imho di framework non è qualcosa che puoi fare in base ai consigli fatti qui. Ti suggerisco di elencare quelli che ti sembrano promettenti in base alle loro caratteristiche e quindi scrivere una piccola app di prova in ognuno di essi. (Scrivi lo stesso ogni volta.)