Normas generales de desarrollo de sistemas

En esta sección vamos a mostrar las normas generales que nos deben guiar en el desarrollo de sistemas, en distintas categorías

Transportabilidad

Un sistema debe poder ser “migrable” o “copiable” muy fácilmente. Esto nos permite reutilizar el trabajo en beneficio de la productividad y de los clientes, que se benefician de lo aprendido con otros clientes.

Prácticas:

No usar directorios fijos new, sis, ZZZ... Usar las variables:

En PHP En HTML
  • $SRVn2c
  • $SRVprg
  • $SRVdat
  • $SRVimg
  • $SRVtmp
  • $SRVstl
    		•
  • $URLn2c
  • $URLprg
  • $URLdat
  • $URLimg
  • $URLtmp
  • $URLstl
    		•

    >Nota: Anteriormente se recomendaba la utilización de rutas relativas complementadas con las variables $TOprg, $TOdat... Ahora, se prefiere la utilización de rutas absolutas por ser más eficientes y no depender del lugar

    En PHP

    Bien:

    require ("$SRVn2c/rutinas/utilitiesasesor.php"
require ("$SRVprg/PERpost.php");

    Mal:

    require ("../../sis/rutinas/utilitiesasesor.php");
require("http:///ZZZ/04/90/900/PERpost.php");

    En HTML

    Bien:

    echo "<script type='text/javascript' src='$URLn2c/rutinas/calendar.js'></script>";
echo "<link type='text/css' rel='stylesheet' href='$URLstl/estilo.css' />";

    Mal:

    echo "<script src='http://www.net2client.com/sis/rutinas/calendar.js'></script>";
echo "<link type='text/css' rel='stylesheet' href='../CRM/stl/estilo.css' />";

    Usar $BD y $EEE en vez de la Base de datos “00”, o de la aplicación “701”

    Seguridad

    Las aplicaciones deben ser seguras y no deben permitir su ejecución por personas no autorizadas. La forma de hacer esto es a través del COKO.

    Por lo tanto, una aplicación escrita por el asesor, debe llamarse a través de versup.php o (a partir de la versión 5.1) puede llamarse directamente y hacer un require del programa ambienteN2C, así:

    require ("ambienten2c.php");

    Esto va a asegurar que haya un COKO válido, que el usuario esté autorizado, y va a dar acceso a todas las variables y funciones de N2C, igual que si el programa hubiese sido llamado a través de versup.php.

    Auditabilidad: Trazas en el uso

    N2C lleva trazas de las operaciones realizadas. El usuario espera saber siempre quien añadió o modificó un registro, que contenía cuando se borró y quien envió un email. Los programas estándares de Net2Cliwnr lo hacen. Si no se usan, es decir si el asesor escribe su propio programa, debe siempre registrar en la tabla LOG las operaciones siguientes:

    • Ingreso/salida al sistema
    • Insertar, Modificar o Eliminar registros
    • Envío de emails

    El registro debe ser hecho en el mismo formato que lo hace N2C. Favor consultar al equipo de Kernel.

    Experiencia uniforme

    Cuando el usuario utiliza programas escritos por el asesor espera tener la misma experiencia que cuando usa programas del sistema. Por lo tanto:

    • Todo reporte de más de una página debería tener el mismo aspecto (L&F) y manejo de listarsup (botones de ordenamiento, pagineo...)
    • Al lado de todo email, se debe tener un botón de envío de email
    • El nombre de un campo debe poder modificarse en un solo lugar y debe reflejarse en todas partes. Por lo tanto, nunca se deben tener los nombres de variables cableados ("Hard-coded") sino que debe usarse la rutina BuscarNombre, para conseguir el nombre externo de una variable
    • Al modificar una lista todo debe seguir funcionando. Esto se puede lograr con el uso de CajaLista. En caso de que no se pueda modificar una lista sin la intervención del programador, esto debe estar claro en los comentarios de la lista.

    Funcionamiento en múltiples navegadores

    Todas las aplicaciones deben funcionar bien, al menos, en los siguientes navegadores:

    • Internet Explorer 6 (IE6)
    • Internet Explorer 7 (IE7)
    • Firefox

    Se recomienda fuertemente desarrollar las aplicaciones bajo firefox, debido a las grandes facilidades de debug que ofrece, teniendo una ventana de IE abierta, a fin de asegurar que cada página que se hace, sea compatible con ambos navegadores

    Productividad y reusabilidad

    La productividad es clave para la viabilidad y el crecimiento de la empresa. Debemos escribir programas de la más alta calidad, en el menor tiempo posible y procurar que todo lo que se escriba sea fácilmente reusable. Para ello, el uso de rutinas del sistema asegura la reusabilidad y que las aplicaciones se modernizan.

    • Cuando se está realizando una función, uno debe preguntarse siempre ¿Seré el primero en necesitar esto? ¿Seré el último?
    • Se deben usar las rutinas y clases que ofrece N2C. Si hay una forma mejor de hacer algo, no seamos egoístas, incorporémosla al kernel
    • Evitar operaciones directas a la base de datos. Hoy es mysql mañana debería poder ser cualquiera, sin modificaciones
    • Por último, no se debe invertir tiempo en “preciosismos” que no esté pagando el cliente

    Confiabilidad

    Nuestros sistemas tienen que ser confiables. Si algo falla hay que hacerlo notar inmediatamente

    • No usar “include” sino “require”: Si se está incluyendo un archivo es por algo. Si no está, hay que hacerlo notar inmediatamente y no dejar que el programa siga corriendo con un compartamiento raro que es más difícil de descubrir.
    • Después de cada lectura verificar si funcionó y abortar en caso contrario: 
      $aa="SELECT * FROM {$EEE}XXX WHERE XXXCodigo=''";
$SelectXXX=mysql_query($aa);
if (!$SelectXXX) die("No se pudo realizar $aa ".mysql_error());
$CantXXX=mysql_num_rows($SelectXXX);
for ($i=0;$i<$CantRes;$i++){
	$rowXXX=mysql_fetch_assoc($SelectXXX);
};
    • Utilizar mysql_real_escape_string al realizar operaciones en la base de datos cuando un campo pueda contener comillas, apóstrofe o algún otro carácter especial. 
      $PERLinea9 = mysql_real_escape_string($_POST["PERLinea9"]);

    Mantenibilidad

    No queremos ser indispensables. Queremos poder salir de vacaciones sin que nos tengan que llamar, por lo tanto, cualquiera debería poder modificar nuestros programas. Para eso es indispensable seguir las normas de programación y documentación. Y en cuanto a la documentación, todo programa o función debe explicar:

    • Su objetivo
    • Cuales son sus entradas y salidas
    • Quien lo invoca, a quien invoca
    • Quien lo escribió

    Código a incluir:

    /**
* Program:	miprograma.php
* Objetive:	Mostrar las estadísticas de uso del sistema
* Description:	Este programa lee la tabla XXX y recorre todos los registros guardando
*		en un arreglo todos los valores leídos, para después graficar los
*		valores obtenidos
* @query_string	Parámetro recibido en el query string
* @post		$VarPost1: Primera variable obtenida por método POST
* @post		$VarPost2: Seguna variable obtenida por método POST
* @get		$VarGet: Variable obtenida por método GET
* @author		Fulano DeTal
* @called_by:	panel.htm y varios programas más
* @calls:	None
*/

    Se recomienda copiar esto tal cual, para poder producir la documentación con un programa que lo lee en este formato.

    Es muy común que los errores en los sistemas sean causados por algún cambio. Por lo tanto, cada vez que se hace un cambio es indispensable escribir en el programa que se está modificando,  la información siguiente:

    // Modif XX 2007-12-20 Ref. 1234 Se añadió la instrucción siguiente

    En donde:

    • XX es el autor del cambio
    • 2007-12-20 es la fecha del cambio, en formato AAAA-MM-DD
    • 1234 es el número del ticket (o de la tarea en los programas del Kernel)
    • Se termina escribiendo cual fue el cambio que se hizo

    Reglas adicionales para el Kernel

    El Kernel nos da productividad, competitividad y reusabilidad. Tenemos que facilitar su mantenimiento y seguir las prácticas siguientes:

    • La documentación debe estar en inglés
    • Cualquier programa que se añada debe incluirse en la tabla de PROGRAMAS de la intranet (701)
    • Cualquier cambio que se haga debe estar documentado en el programa (Modif) y en la tabla de TAREAS de la intranet (701)
    • Cualquier mejora debe ser explicada en la guía del asesor, en el control de versiones y en el blog

    Internacionalización

    Somos una empresa global, queremos poder seguir siéndolo, por eso debemos usar las siguientes prácticas:

    • Todo programa que pudiese ir al exterior debe documentarse en inglés
    • Uso de programas multilingues con la tabla $MM
    • Hay idiomas que usan apóstrofe, por lo tanto hay que tener cuidado con esto y usar la instrucción mysql_real_escape_string