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

ECOM-6030CAPÍTULOS 24

LARGE PROJECTS

Prof. Nelliud D. Torres© - Derechos Reservados

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

APLICAR SOFTWARE ENGINEERING AL DESARROLLO WEB

Software Engineering1. 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


Pag: 510

WRITING MAINTAINABLE CODEA 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 Code3.Using a Standard Directory Structure4.Documenting and Sharing In-House Functions


Pag: 510

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.


Pag: 510

Defining Naming ConventionsLa 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++.


Pag: 510

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


Pag: 511

Commenting Your CodeSe 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.


Pag: 512

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.


Pag: 512

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.


Pag: 512 - 513

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.


Pag: 513

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.


Pag: 513

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.


Pag: 514

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.


Pag: 514

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.


Pag: 514

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.


Pag: 516

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.


Pag: 516

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.


Pag: 519

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


Pag: 519

http://www.zend.com/

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.


Pag: 520

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 adicional8/12/2007 © - Derechos Reservados - Prof. Nelliud D.

Torres 22

Pag: 520

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

REFERENCIAS• PHP and MySQL Web Development, Third Edition,

Luke Welling, and Laura Thomson• Version Control• http://www.cvshome.org/ - CVS• http://www.perforce.com - Bitkeeper

• http://kphpdev.sourceforge.net - IDE


REFERENCIAS – CONT.• PHP Document Utilities• http://www.phpdoc.de• http://phpdocu.sourceforge.net • http://sourceforge.net/projects/phpautodoc/ -

IDE•

• http://www.zend.com – PHP Optimizer


Documents

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