¿Qué consideraría las mejores prácticas de herramientas de flujo de trabajo para el desarrollo de aplicaciones web (PHP)? [cerrado]

Realmente espero que alguien con más experiencia pueda editar la pregunta según mis ejemplos de respuestas:

• usando el control de versiones
• desarrollo impulsado por pruebas
• código de depuración (xdebug para php)
• uso de diagramas UML
• uso de OOP para código mantenible y reutilizable
• uso de frameworks (como Zend Framework para php) para el desarrollo rápido de aplicaciones

¿Algo más o una elaboración de lo que mencioné anteriormente?

Básicamente, estoy en el medio de formar un equipo de desarrolladores (yo también soy un desarrollador) y me gustaría recibir algunos consejos sobre cómo los programadores / diseñadores profesionales, etc., deberían trabajar juntos y qué estándares / paradigmas deberían usar.

Además, si alguien tiene algún libro o enlace sobre el tema, ¡lo agradecería!

Encontré esto que creo que satisface lo que estoy buscando, o al menos parte de eso:

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

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.

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.

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 )

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!

• Marco : codeigniter, sin duda. Tiene todas las funcionalidades que nunca pueda necesitar, y no obliga a utilizar cualquiera de ellos a menos que hagas necesidad de ellos;
• Control de versiones, IDE : soy bastante de la vieja escuela, y no creo que mi respuesta realmente pueda ayudarte;
• Wireframing, UML : vieja escuela en esto también, pero realmente: las pizarras ganan. Son flexibles, extensibles y admiten cualquier convención que le parezca adecuada;
• Administración de la base de datos : phpmyadmin;
• SO del servidor de desarrollo : podría ser banal, pero: Ubuntu. Instale un servidor LAMP en segundos; no se preocupe por agregar nuevas bibliotecas (la temida imagen: un comando, hecho); Si te gusta PHP, probablemente terminarás trabajando en el servidor Linux en producción, así que es mejor comenzar a practicar. (Descargo de responsabilidad: Ubuntu no es mi distribución favorita).
• Otra información : grep puede ser increíblemente útil al depurar el código de otras personas (¿quieres saber cuántos controladores usan un modelo dado? ¡Listo!).

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.

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

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).