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

utilizzando il controllo della versione

SVN è molto comune, ma il mercurial è più bello, potente e ha un solido supporto gui.

sviluppo basato su test

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

codice di debug

con i test unitari non avrai quasi bisogno di xdebug. io uso xdebug di solito solo per il profiling. (controlla KCachegrind btw)

uso di diagrammi UML

il problema più grande con tutto ciò che riflette la logica del codice è che è molto lavoro manuale da mantenere sincronizzato. puoi automatizzare alcune attività, ma non è così utile, perché di solito vuoi usare uml prima di avere qualsiasi cosa. 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" è uno strumento gratuito e anche gli strumenti di mind mapping sono molto utili per il brainstorming, alcuni possono effettivamente competere con carta e penna.)

uso di OOP per codice riutilizzabile e manutenibile

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

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

RAD è una buona cosa per far partire presto la tua app. ma alcuni componenti, in particolare l'ORM, ti spareranno, almeno per quanto riguarda la scalabilità. il problema principale qui è che leghi la logica del tuo dominio a lavorare con gli oggetti, il che diventa molto difficile da trarre in considerazione se hai bisogno di una soluzione ottimizzata per il database scalabile. sii consapevole di ciò e incoraggia i tuoi 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 buone pratiche in giro, impostare standard di codifica, usare 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 severe. test di unità e scm è davvero un must have, ma qualcuno di nuovo al test delle unità ha davvero bisogno di imparare il suo valore prima che lo adori. 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 male. hai bisogno di un algoritmo sei gradi di separazione ? basta scegliere alcuni amici a caso. puoi creare un'applicazione completa attorno ad essa, con una logica sbagliata. se il cliente decide di abbandonarlo, tutti hanno risparmiato un sacco di soldi.

agile

scopri le metodologie agili, la programmazione estrema, la mischia, ecc. ci sono molti libri là fuori. qualsiasi libro renderà la tua squadra migliore, ma è il massimo per coinvolgere tutti i membri del team.

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

• Framework: CodeIgniter . Fornisce le migliori piattaforme di sviluppo web per PHP.

• IDE: Netbeans è il miglior IDE per PHP che ho usato su Windows.

• Test unità: ci sono diverse opzioni, una ricerca su google ne risulterà molte. CodeIgniter ha anche il proprio tester di unità disponibile.

• Debugger: Xdebug.

• Libreria Javascript: Jquery

• Programma FTP: FileZilla

• Amministrazione database: PhpMyAdmin

• Wireframing: Balsimus Mockup o usa una lavagna.

• Varie: Usa WAMP se su Windows per installare, avviare, interrompere, & riavvia 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 registrazione, accesso / uscita, una sezione di amministrazione per la ricerca degli utenti, ecc., ti consiglio di creare un piccolo progetto in qualsiasi quadro tu scelga e utilizzi quel progetto come base per ogni nuovo progetto che inizi. Normalmente chiamo questo progetto "scheletro". Se ho intenzione di iniziare a lavorare su xyz.com, vorrei copiare la directory skeleton e rinominarla come 'xyz.com', inserire alcuni file di configurazione, e avrei una copia di xyz.com con alcune delle funzionalità già funzionante.

Sono d'accordo soprattutto con il post di Click Upvote, tuttavia, se stai lavorando su un sito relativamente grande, ti consiglio di usare il framework Symfony accoppiato con l'ORM di Doctrine.

Se il tuo progetto è previsto per il prossimo anno, direi che è il momento di 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 server web. Lavoro principalmente su Windows, ma sviluppo su Ubuntu in esecuzione su una macchina virtuale VMWare sul mio desktop (o server quando sono al lavoro).

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

L'uso del diagramma UML è bello ma è del tutto facoltativo. Qualsiasi diagramma farebbe finché il tuo team capirà cosa significano. Cercare di utilizzare nessuno che nessuno conosce veramente bene può portare a problemi e tempo perso.

Consiglierei di avviare ciascuna pagina da un modello ( link ) o chiedere al tuo designer di disegnarla per te. Non aspettarti che gli sviluppatori siano bravi nell'estetica visiva e creino buone pagine dal nulla.

Chiedere a qualcuno di assegnare un compito di revisione del codice, se hai diversi membri del team di seniour, fagli fare revisioni a rotazione ( Review Board )

Quando hai a che fare con il lavoro collaborativo hai bisogno di:

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

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

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

• uso di diagrammi UML: questo aiuta quando tutti hanno una conoscenza operativa su OO Programming e DesignPatterns, tuttavia è sempre una buona pratica

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

• uso di framework (come Zend Framework per php) per lo sviluppo rapido di applicazioni: My Advise è SYMFONY, il primo framework php (non un toolkit). Ha una community molto ampia, molta documentazione e la sua implementazione è interamente su PHP. Ci lavoro da un anno e si lega totalmente con OOP

• Potrebbe anche essere necessario un sistema per tenere traccia di bug, richieste di funzionalità, ecc. come: Mantis o Traccia . Questo sistema è abbastanza semplice e diretto. Ti permettono anche di legare la tua sovversione e di mettere in relazione i tuoi commit con certe caratteristiche o bug che la gente pubblica.

Infine, è sempre importante se stai guidando un team di sviluppo per fare riunioni periodiche di piccole dimensioni in modo che tutti conoscano lo stato del sistema a un certo punto e forse in quel modo sarai in grado di pianificare o vedere come vanno le cose stanno funzionando.

Nella mia azienda devo inviare una e-mail ogni giorno dicendo a cosa sto lavorando e se ci sono delle complicazioni.

Buona fortuna!

• Framework : codeigniter, senza dubbio. Ha tutte le funzionalità che potresti mai aver bisogno e non ti obbliga a usarne nessuna a meno che tu non ne abbia bisogno;
• Controllo versione, IDE : sono abbastanza vecchio stile, e non penso che la mia risposta possa davvero aiutarti;
• Wireframing, UML : vecchia scuola anche in questo, ma in realtà: le lavagne vincono. Sono flessibili, estendibili e supportano qualsiasi convenzione che ritieni opportuna;
• Amministrazione del database : phpmyadmin;
• Sistema operativo del server di sviluppo : potrei essere banale, ma: Ubuntu. Installa un server LAMP in pochi secondi; non fatevi prendere dal panico sull'aggiunta di nuove librerie (l'immaginario temuto: un comando, fatto); se ti piace il PHP probabilmente finirai a lavorare sul server linux in produzione, quindi è meglio iniziare a fare pratica. (Disclaimer: Ubuntu non è la mia distribuzione preferita).
• Varie : grep può essere incredibilmente utile quando esegui il debug del codice di altri utenti (vuoi sapere quanti controller usano un determinato modello? Fatto!).

modifica

Ho dimenticato la cosa più importante: le specifiche. Scrivi le 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 versione Dato che lavori in una squadra, è nel tuo interesse che tu vada con qualcosa di distribuito. I tuoi candidati sono Git e Mercurial. Ciò significa che il tuo team può eseguire il commit localmente senza interrompere il progetto, ma tiene comunque traccia del proprio lavoro, quindi spinge questi commit al server centrale. È anche molto più veloce e ha meno conflitti di fusione poiché il codice viene tracciato come serie di modifiche anziché come revisioni. Leggi la guida di hginit (scritta dal co-fondatore dello stack overflow non di meno) e capirai un po 'di più su cos'è un DVCS. link

Dovresti utilizzare il repository per la distribuzione invece di rsync o ftp.

Sviluppo guidato dai test A seconda di ciò che stai facendo, i test possono perdere un sacco di tempo. Non sto dicendo che dovresti saltare completamente, per i progetti più piccoli è un 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. Essere consapevoli del fatto che TDD non riesce a trovare tutti i bug. Ci saranno problemi di esperienza utente, problemi di layout, problemi di prestazioni e così via.

Debug Xdebug è fondamentalmente la tua unica scelta qui. Si integra bene con Netbeans. Se senti la necessità di stampare sempre le variabili, dovresti usare un file di registro. Utilizza la funzione di registro dei framework, questo è molto più sicuro nella produzione.

Pianificazione / Diagrammi Se stai usando un buon framework non dovresti aver bisogno di fare troppi diagrammi dettagliati. Mantenetelo semplice e lavorate in cicli di rilascio più brevi, è facile sovrastimare. I requisiti e le specifiche di un progetto sono destinati a cambiare in modo da non passare tutto il tempo su di essi. Ricorda che il codice IS specifica al livello più dettagliato.

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

Puoi usare uno strumento come Mysql Workbench per progettare schemi di database in diagrammi ed esportarli come SQL.

Framework e OOP Questa è probabilmente la parte più importante. Trovati un framework popolare che supporterà lo sviluppo rapido e il riutilizzo del codice. Ad alcune persone non piacerà che dica questo, ma un quadro dovrebbe dettare il tuo modo di lavorare. 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 nello 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 supponenti e questo significa che posso guardare il codice di qualcuno e capire cosa fa. Symfony sembra l'opzione migliore qui, ma vorrei controllare Rails (Ruby) e Django (python) comunque, potrebbe essere esattamente quello di cui hai bisogno.

Ci sono molte domande su "struttura" sullo stack overflow come questo: link

Monitoraggio dei bug Fai del tuo team un buon bug tracker creato per gli sviluppatori. Non utilizzare qualcosa di semplificato come il campo base. Redmine e Unfuddle sono due esempi di bug tracker eccellenti, che possono anche monitorare il tempo e integrarsi con i repository. Il tuo team dovrebbe utilizzare questo strumento per comunicare sui problemi anziché su email o IM. Rende più facile per un nuovo sviluppatore quando è disponibile una cronologia esistente di bug e documenti. Questo articolo spiega esattamente cosa deve fare un buon bug tracker e perché. link

Consiglierei di guardare Bazaar per il controllo della versione. Rispetto a Git ha il vantaggio principale che è in realtà facile da usare e 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 grande curva di apprendimento. Ti sto guardando Git.

A parte ciò, sono un strong sostenitore di non forzare nulla sui tuoi sviluppatori. Detto questo, permetti loro di usare l'IDE, il sistema operativo e così via che preferiscono.

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

La decisione a favore o contro un quadro imho non è qualcosa che puoi fare in base alle raccomandazioni fatte qui. Ti suggerisco di elencare quelli che ti sembrano promettenti in base alle loro caratteristiche e poi scrivere una piccola app di prova in ognuno di essi. (Scrivi sempre lo stesso).