ECOM-6030 CAPÍTULOS 24 LARGE PROJECTS Prof. Nelliud D. Torres © - Derechos Reservados.

Presentación del tema: "ECOM-6030 CAPÍTULOS 24 LARGE PROJECTS Prof. Nelliud D. Torres © - Derechos Reservados."— Transcripción de la presentación:

1 ECOM-6030 CAPÍTULOS 24 LARGE PROJECTS Prof. Nelliud D. Torres © - Derechos Reservados

2 CONTENIDO Software Engineering Writing Maintainable Code Coding Standards Defining Naming Conventions Commenting Your Code Indenting Breaking Up Code Using A Standard Directory Structure 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 2 Documenting And Sharing In-house Functions Implementing Version Control Choosing A Development Environment Documenting Your Projects Optimizing Code Testing

3 APLICAR SOFTWARE ENGINEERING AL DESARROLLO WEB

4 Software Engineering 1.Software Engineering – Se aplican principios de ingeniería al desarrollo de software. 2.El paradigma orientado a documentos no aplica en la programación Web ya que cada vez es más dinámico y menos estático en la muestra de documentos. 3.El desarrollo de aplicaciones web comparado con aplicaciones normales tiende a: – Tener menos tiempo para completarlo, mayor presión. – hay que tomar en cuenta el performance y por lo tanto hay que planificar con antelación 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 4 Pag: 510

5 WRITING MAINTAINABLE CODE A continuación se van a explicar los siguientes conceptos que ayudan grandemente a mantener el código de la aplicación Web que se esté desarrollando: 1.Coding Standards – Defining naming Conventions – Comenting Your Code – Indenting 2.Breaking Up Code 3.Using a Standard Directory Structure 4.Documenting and Sharing In-House Functions 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 5 Pag: 510

6 Coding Standards En muchas organizaciones se tiene un estandard al momento de programar. Se crean guías para poner nombre a los archivos y las variables, poner comentarios en el programa, indentar el código y así por el estilo. Generalmente estas prácticas tienden a olvidarse, especialmente en compañías pequeñas. A la larga esto puede traer más problemas y tiempo haciendo debugging. A continuación se detalla los estándares más importantes y comunes. 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 6 Pag: 510

7 Defining Naming Conventions La meta al definir reglas para asignar nombres son: Hacer que el código sea más fácil de leer. AL seguir un formato, se hace fácil identificar variables, constantes e incluso propiedades de las variables si así se indica (prefijos). Hace que los identifiers sean fáciles de recordar. Se debe buscar un balance en el largo de los nombres de las variables. El uso de mayúsculas y/o minúsculas también debe ser considerado. Se recomienda utilizar el formato de C++. 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 7 Pag: 510

8 Defining Naming Conventions – Cont. En los nombres de funciones: Deben ser orientados a verbos que describan lo que hacen. Ej. addslashes(), mysql_conection() No son case sensitive y se debe tener cuidado al respecto. Se recomienda el uso de prefijos para clasificar las funciones. A nivel procedural, un nombre de función tiende a escribirse utilizando underlines (ej. my_function()) y en objetos tiende a eliminarse (ej. myFunction()). 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 8 Pag: 511

9 Commenting Your Code Se deben incluir comentarios en: Archivos – Cada archivo debe tener comentarios que diga que es lo que contiene y para que se utiliza, quién lo escribió y cuando fue actualizado. Funciones – Debe indicarse que hace, que espera de input y que valores devuelve. Classes – Propósito de la clase. Sus métodos deben tener el mismo formato de comentario que las funciones. 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 9 Pag: 512

10 Commenting Your Code – Cont. Chunks of code – Se recomienda poner una serie de comentarios (abreviados)con un formato establecido y después llenarlo más detalladamente. Por ejemplo: <? // validate input data // send to database // report results ?> Complex code or hacks – Cuando se incluye un código de prueba que sea confuso o complejo, debe documentar el porqué se incluyó de modo tal que cuando se revise, se pueda uno recordar fácilmente. 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 10 Pag: 512

11 Indenting Los beneficios de la indentación son ya bien conocidos por todos. La indentación hace que el código sea más legible y fácil de entender y por lo tanto de depurar (debug). Se debe establecer un formato de indentar, como por ejemplo en el caso de los if anidados, cantidad de caracteres a indentar, etc. (Los esquemas) Debe haber una persona en el grupo que debe estar pendiente de que la indentación se esté cumpliendo entre los programadores. 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 11 Pag: 512 - 513

12 Breaking Up Code No se recomienda crear un solo gran programa con un gigantesco switch que distribuye las diferentes opciones. Se recomienda dividirlo en diferentes funciones, clases y archivos. Por ejemplo las funciones que manejan la base de datos, se pueden guardar en un archivo guardado dbfunctions.php En el próximo slide se muestran las razones principales por las que se deben dividir el código en funciones-clases y archivos. 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 12 Pag: 513

13 Breaking Up Code – Cont. El código se hace fácil para leer y entender. Se puede rehusar y minimiza la redundancia. Al momento de modificar una función por algún error o problema, es más fácil localizarlo y solo se tiene que hacer la modificación en un solo lugar. Facilita el trabajo en equipo. Permite repartir las tareas y responsabilidades de una forma más eficiente a los programadores. Se debe determinar cuales funciones –clases deben prepararse primero, cuales dependen de otras, etc. El structure chart ayuda mucho. 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 13 Pag: 513

14 Using a Standard Directory Structure De la misma forma que es una mala idea hacer un solo código gigante con todo, también lo es poner todos los archivos y funciones en un solo directorio. Se debe planificar la estructura del directorio. Una vez planificada, se debe documentar y repartir la documentación entre las personas que están trabajando en el proyecto para que todos sepan en donde se encuentran los diferentes archivos. 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 14 Pag: 514

15 Documenting and Sharing In-House Functions En la medida que el proyecto progresa, los programadores van desarrollando librerías con funciones y/o clases. Esto debe estar disponible al resto del grupo para que puedan utilizarse y ahorrar tiempo en el desarrollo del proyecto. En adición esto evita la posibilidad de crear redundancia como por ejemplo en la conexión y manejo de la Base de Datos. 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 15 Pag: 514

16 IMPLEMENTING VERSION CONTROL Es el arte de gerenciar cambios concurrentes en el código fuente de un proyecto. Esto ayuda en las situaciones: – Virar un código para atrás (versión anterior) ya que la modificación que se hizo no funciona. – Dos personas o mas están trabajando el mismo programa y tienen dos versiones diferentes del mismo programa. – Existe software que te maneja estas situaciones e incluso permite que dos programadores modifiquen el mismo código a la vez. Al final se muestran los enlaces de donde se pueden bajar. 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 16 Pag: 514

17 Choosing a Development Environment Hay herramientas que facilitan las tareas de los programadores y ofrecen herramientas (editores, visualizadores, etc) que facilitan la programación. Esto se conoce como Integrated Development Environment (IDE) y aumenta la productividad del proyecto. En el último slide se muestra un enlace para uno de estos sistemas. Muchos de estos productos tienen licencia comercial o versiones trial. 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 17 Pag: 516

18 Documenting Your Projects Los documentos recomendados (pero no limitados) para un proyecto son: Documentos de diseño Documentación técnica (guía de desarrolladores) Diccionario de datos (Data Dictionary) Guía del usuario (User’s Guide) Algunos de estos documentos se pueden generar por programación. En el slide final hay unos enlaces de algunos programas que permiten generar documentación. 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 18 Pag: 516

19 Optimizing Code Es algo que no puede ser ignorado en el mundo de las aplicaciones Web. Algunas guías que da el libro para reducir el tiempo de espera de los usuarios del sistema son: – Reducir en la medida que sea posible, las conexiones a la base de datos. – Reducir y optimizar los queries que se hacen a la base de datos. – reducir la generación de código estático lo más posible. – Utilizar funciones que manejen string en lugar de expresiones regulares lo más posible. – usar comilla sencilla en lugar de doble lo más posible. 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 19 Pag: 519

20 Optimizing Code – Cont. Existen productos en el mercado que ayudan a optimizar un proyecto. Un ejemplo es el Zend Optimizer que permite optimizar el código de un 40% a 100%. La dirección de la página es: http://www.zend.comhttp://www.zend.com 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 20 Pag: 519

21 Testing Muchos programadores cometen el error de hacer dos o tres pruebas a una aplicación y dar por hecho que corre bien. Si bien siempre pueden existir bugs en el código, el hacer unas pruebas eficientes los minimiza considerablemente. El libro recomienda dos métodos para mejorar las pruebas de un sistemas las cuales se mencionan en el próximo slide. 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 21 Pag: 520

22 Testing – CONT. Primero – Permitir que otro programador o team revise el código desarrolado por otro. De que se pueden obtener sugerencias de: – Errores perdidos – Casos de pruebas que no se consideraron – Optimización – Mejoras en seguridad – Uso de componentes existentes para mejorar el código. – Funcionalidad adicional 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 22 Pag: 520

23 Testing – CONT. Segundo– Conseguir usuarios que prueben la aplicación. Como se supone que las aplicaciones Web puedan ser utilizadas por cualquier usuarios que sepa utilizar un browser, la selección de una o más personan que prueben el sistema del punto de vista funcional no debe ser difícil de conseguir. Una posibilidad es poner la aplicación beta y ofrecer a los primeros 100 usuarios algún tipo de beneficio gratuito a cambio de que provean un feedback del sistema. 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 23 Pag: 520

24 REFERENCIAS PHP and MySQL Web Development, Third Edition, Luke Welling, and Laura Thomson Version Control http://www.cvshome.org/ - CVS http://www.cvshome.org/ http://www.perforce.com - Bitkeeper http://www.perforce.com http://kphpdev.sourceforge.net - IDE http://kphpdev.sourceforge.net 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 24

25 REFERENCIAS – CONT. PHP Document Utilities http://www.phpdoc.de http://phpdocu.sourceforge.net http://sourceforge.net/projects/phpautodoc/ - IDE http://sourceforge.net/projects/phpautodoc/ http://www.zend.com – PHP Optimizer http://www.zend.com 8/12/2007 © - Derechos Reservados - Prof. Nelliud D. Torres 25