usando el control de versiones
SVN es muy común, pero mercurial es más guapo, poderoso y tiene un sólido soporte de interfaz gráfica de usuario.
desarrollo impulsado por pruebas
bueno, si haces pruebas unitarias, ya estás en el lado ganador. para herramientas, es una cuestión de elección. la prueba debe ser lo más fácil posible, esa es la razón por la que abandoné PHPUnit para SimpleTest.
código de depuración
con las pruebas unitarias difícilmente necesitará xdebug. Yo uso xdebug generalmente solo para perfilar. (echa un vistazo a KCachegrind por cierto)
uso de diagramas UML
El mayor problema con todo lo que refleja la lógica del código es que es mucho trabajo manual mantenerse sincronizado. puede automatizar algunas tareas, pero no es tan útil, porque generalmente desea usar uml antes de tener algo. El otro problema es que las herramientas de diagrama son mucho más difíciles de usar que el lápiz y el papel o una pizarra. use uml si tiene que comunicar un problema con múltiples desarrolladores o si necesita una abstracción para usted mismo. ("dia" es una buena herramienta gratuita. también las herramientas de mapeo mental son muy útiles para la lluvia de ideas, algunas pueden competir con el lápiz y el papel).
uso de OOP para código mantenible y reutilizable
bueno, oop funciona hasta cierto punto. :) un buen consejo: composición> herencia. La herencia es una herramienta poderosa para reutilizar a primera vista, pero el mantenimiento y el acoplamiento flojo sufrirán por ello. Segundo buen consejo: mantenimiento> reutilización. Un sistema abstracto puede ser muy poderoso, pero también difícil de mantener.
uso de frameworks (como Zend Framework para php) para el desarrollo rápido de aplicaciones
RAD es algo bueno para que su aplicación salga temprano. pero algunos componentes, especialmente ORM, dispararán sus pies, al menos si se trata de escalabilidad. El principal problema aquí es que vincula su lógica de dominio para trabajar con objetos, lo que se vuelve muy difícil de descifrar si necesita una solución optimizada de base de datos pura y escalable. tenga en cuenta eso y aliente a sus desarrolladores a utilizar la base de datos sin capas de abstracción de alto nivel. la abstracción de la base de datos es un mito, orm es una mentira.
BESO
los recién llegados generalmente quieren aplicar todas esas mejores prácticas, establecer estándares de codificación, usar todas las buenas cadenas de herramientas, lo que sea. funciona para algunos desarrolladores, pero algunos se encontrarán con un bloqueo mental si las cosas son demasiado estrictas. la prueba de unidad y la SCM son realmente imprescindibles, pero alguien nuevo en la prueba de unidad realmente necesita aprender su valor antes de que le encante. no exagere, aplique las prácticas paso a paso y vea cómo funciona. KISS también se reduce a código. a veces la mejor manera de resolver un problema difícil es resolverlo mal. necesitas un algoritmo de separación de seis grados ? solo elige algunos amigos al azar. puede crear una aplicación completa a su alrededor, con una lógica incorrecta. si el cliente finalmente decide abandonarlo, todos ahorraron mucho dinero.
ágil
Aprenda sobre metodologías ágiles, programación extrema, scrum, etc. Hay muchos libros disponibles. cualquier libro mejorará su equipo, pero es lo mejor para que cada compañero de equipo participe.
Control de versiones: si está en Windows, TortoiseSVN es el mejor, más intuitivo y más fácil de usar en mi experiencia.
Marco: CodeIgniter . Manos a la mejor plataforma de desarrollo web para PHP.
IDE: Netbeans es el mejor IDE para PHP que he usado en Windows.
Pruebas unitarias: hay varias opciones, una búsqueda en Google mostrará muchas. CodeIgniter también tiene su propio probador de unidades disponible.
Depurador: Xdebug.
Biblioteca Javascript: Jquery
Programa FTP: FileZilla
Administración de la base de datos: PhpMyAdmin
Wireframing: Balsimus Mockup, o use una pizarra.
Varios: use WAMP si está en Windows para instalar, iniciar, detener y reiniciar fácilmente apache, mysql y php, todo en un solo paquete.
Además, si va a trabajar en muchos sitios web diferentes, y la mayoría de esos sitios web tendrán algunas funciones comunes como registrarse, iniciar sesión / cerrar sesión, una sección de administración para buscar usuarios, etc., recomiendo construir un pequeño proyecto en cualquier marco usted elige y utiliza ese proyecto como base para cada nuevo proyecto que inicie. Normalmente llamo a este proyecto 'esqueleto'. Si voy a comenzar a trabajar en xyz.com, copiaría el directorio esqueleto y lo renombraría como 'xyz.com', completaría algunos archivos de configuración y obtendría una copia de xyz.com con algunas de las características ya estoy trabajando.
fuente
Framework: CodeIgniter. Hands on the best web development platform for PHP.Esto, francamente, es una mierda. Si alguna vez has usado Symfony, Rails o Django, verás algunos problemas importantes. No hay una estructura de directorio modular, ni una interfaz de línea de comando. Luego, tiene componentes centrales como formularios y modelos que ocupan mucho código. Si conoce algún patrón de software, verá que codeigniter apesta a lo grande. Por lo menos, use Kohana, que es CI bifurcado y hecho correctamente después de que la comunidad murió.Estoy de acuerdo principalmente con la publicación de Click Upvote, sin embargo, si está trabajando en un sitio relativamente grande, definitivamente recomendaría usar el marco de Symfony junto con Doctrine ORM.
Si su proyecto se vence el próximo año, diría que tómese el tiempo para invertir en Symfony2 y Doctrine2.
Además, no puedo enfatizar lo suficiente la importancia de desarrollar en un sistema basado en Unix, Ubuntu es mi preferencia y un excelente servidor web. Trabajo principalmente en Windows pero desarrollo en Ubuntu ejecutándose en una máquina virtual VMWare en mi escritorio (o servidor cuando estoy en el trabajo).
En cuanto a IDE, recomiendo usar NuSphere PHPEd o Storm PHP, lamentablemente, como todas las cosas geniales, no son gratuitas.
fuente
El uso del diagrama UML es bueno pero es completamente opcional. Cualquier diagrama servirá siempre que su equipo entienda lo que significan. Intentar utilizar el estándar que nadie conoce realmente puede generar problemas y perder tiempo.
Recomendaría comenzar cada página desde una maqueta ( http://balsamiq.com ) o pedirle a su diseñador que la dibuje para usted. No espere que los desarrolladores sean buenos en estética visual y creen buenas páginas de la nada.
Haga que alguien se asigne a la tarea de revisión de código, si tiene varios miembros del equipo seni - haga que hagan revisiones en rotación ( Junta de revisión )
fuente
Cuando se trata de trabajo colaborativo, necesita:
• usando el control de versiones: creo que Git o Subversion funcionarán bastante bien
• desarrollo impulsado por pruebas: estoy empezando a aprender que esto es imprescindible, pero no lo lleves a extremos
• código de depuración (xdebug para php): xdebug es mi elección
• uso de diagramas UML: esto ayuda cuando todos tienen conocimientos prácticos sobre programación OO y patrones de diseño; sin embargo, siempre es una buena práctica
• uso de OOP para código mantenible y reutilizable: y FLEXIBILIDAD, creo que este es el aspecto clave de OOP.
• uso de frameworks (como Zend Framework para php) para el desarrollo rápido de aplicaciones: My Advise es SYMFONY, el primer framework php (no es un kit de herramientas). Tiene una comunidad muy grande, mucha documentación y está completamente implementado en php. He estado trabajando con él durante un año y se une totalmente con OOP
• También puede necesitar un sistema para rastrear errores, solicitudes de funciones, etc. como: Mantis o Track . Estos sistemas son bastante fáciles y directos. También le permiten vincular su subversión y relacionar sus confirmaciones con ciertas características o errores que las personas publican.
Finalmente, siempre es importante si va a liderar un equipo de desarrollo para hacer reuniones pequeñas periódicamente para que todos conozcan el estado del sistema en un momento determinado y tal vez de esa manera sean capaces de planificar o ver cómo funcionan las cosas.
En mi empresa, tengo que enviar un correo electrónico todos los días para informar en qué he estado trabajando y si hay alguna complicación.
¡La mejor de las suertes!
fuente
editar
Olvidé lo más importante: especificaciones. Escriba especificaciones reales para su proyecto antes de tocar cualquier código. Tenga en mente todos los diagramas de interacción del usuario. Te salvará siglos.
fuente
Control de versiones Dado que está trabajando en un equipo, le conviene que vaya con algo distribuido. Tus candidatos son Git y Mercurial. Esto significa que su equipo puede comprometerse localmente sin interrumpir el proyecto, pero aún así realizar un seguimiento de su trabajo y luego enviar estos compromisos al servidor central. También es mucho más rápido y tiene menos conflictos de fusión, ya que el código se rastrea como conjuntos de cambios en lugar de revisiones. Lea la guía hginit (escrita por el cofundador de stack overflow no menos) y comprenderá un poco más sobre qué es un DVCS. http://hginit.com/
También debe usar el repositorio para la implementación en lugar de rsync o ftp.
Desarrollo guiado por pruebas Dependiendo de lo que esté haciendo, las pruebas pueden perder mucho tiempo. No digo que debas omitirlo por completo, para proyectos más pequeños es una sobrecarga. Si está escribiendo una biblioteca o un gran proyecto a largo plazo, asegúrese de escribir pruebas para ello. Las pruebas ayudarán en la fase de mantenimiento. Tenga en cuenta que TDD no puede encontrar todos sus errores. Habrá problemas de experiencia del usuario, problemas de diseño, problemas de rendimiento, etc.
La depuración de Xdebug es básicamente su única opción aquí. Se integra bien con Netbeans. Si siente la necesidad de imprimir variables, debe usar un archivo de registro. Utilice la función de registro de marcos, esto es mucho más seguro en la producción.
Planificación / Diagramas Si está utilizando un buen marco, no debería necesitar hacer demasiado diagramas detallados. Manténgalo simple y trabaje en ciclos de lanzamiento más cortos, es fácil planear en exceso. Los requisitos y especificaciones de un proyecto están sujetos a cambios, por lo que no pasaría todo su tiempo en ellos. Recuerde que la especificación del código IS en el nivel más detallado.
Use su herramienta de seguimiento de errores (consulte a continuación) para dividir la especificación en tareas que puede asignar a los miembros del equipo. Use una herramienta central para documentar los proyectos, el rastreador de errores probablemente tendrá un wiki.
Puede usar una herramienta como Mysql Workbench para diseñar esquemas de bases de datos en diagramas y exportarlos como SQL.
Marcos y POO Esta es probablemente la parte más importante. Encuentre un marco popular que admita un rápido desarrollo y reutilización de código. A algunas personas no les gustará que diga esto, pero un marco debería dictar la forma en que trabaja. Debe proporcionar una estructura para que un desarrollador pueda cambiar de proyecto y saber exactamente dónde está el controlador de una página determinada, exactamente cuáles son las variables de plantilla y cómo consultar el modelo. Algunos marcos permiten demasiada flexibilidad aquí y encontrará que los desarrolladores no siempre usan el marco de la misma manera. Me gusta la filosofía python; debería haber una forma obvia de hacer todo. Es por eso que me gustan los django y los rieles, son bastante obstinados y esto significa que puedo mirar el código de otra persona y entender lo que hace. Symfony parece la mejor opción aquí,
Hay muchas preguntas de "qué marco" en el desbordamiento de pila como esta: /programming/2648/what-php-framework-would-you-choose-for-a-new-application-and-why
Seguimiento de errores Obtenga a su equipo un buen rastreador de errores diseñado para desarrolladores. No use algo más simplificado como basecamp. Redmine y Unfuddle son dos ejemplos de excelentes rastreadores de errores, también pueden rastrear el tiempo e integrarse con sus repositorios. Su equipo debe usar esta herramienta para comunicarse sobre problemas en lugar de correo electrónico o mensajería instantánea. Facilita a un nuevo desarrollador cuando hay un historial de errores y documentos disponibles. Este artículo explica exactamente qué debe hacer un buen rastreador de errores y por qué. http://www.joelonsoftware.com/articles/fog0000000029.html
fuente
Recomiendo mirar Bazar para control de versiones. En comparación con Git, tiene la gran ventaja de que en realidad es fácil de usar e instalar en Windows, Mac OS y Linux. Además, los comandos bzr son muy similares a sus contrapartes svn, por lo tanto, alguien que haya trabajado con Subversion antes puede usar Bazaar fácilmente sin una gran curva de aprendizaje. Te estoy mirando, Git.
Aparte de eso, creo firmemente en no forzar nada sobre sus desarrolladores. Dicho esto, déjenlos usar el IDE, el sistema operativo, etc. que prefieran.
Aparte de eso, te recomiendo encarecidamente que realices trece pruebas para todo tu código, sin importar lo tedioso que sea.
La decisión a favor o en contra de un marco en mi humilde opinión no es algo que pueda hacer en base a las recomendaciones hechas aquí. Le sugiero que enumere los que le parecen prometedores en función de sus características y luego escriba una pequeña aplicación de prueba en cada uno de ellos. (Escriba el mismo cada vez).
fuente