Quince principios que todo ingeniero de software debe seguir

principios-ingeniero-de-software

Una lista de quince principios que un Ingeniero de Software quizá debería seguir.

1. Mantén en mente los fundamentos.
Si olvida los conceptos básicos de los lenguajes de programación está perdiendo su conocimiento más fundamental.  Lo cual no es buena idea.

2. Asuma siempre el peor escenario.
Si tuvo una educación formal en ciencias de la computación, quizá aprendió algo acerca de la notación “big-O” que te dice el costo de un algoritmo, si es lineal o cuadrático por ejemplo. Saber cuando un algoritmo no tiene manera de ejecutarse rápidamente es importante.

3. Pruebe su código.
Asegúrate de probar su código.  Dependiendo del método que use, puedes manejar pruebas en varios niveles.  Pero siempre debe crear tantas pruebas como pueda.

4. No emplee nuevas tecnologías sólo porque son nuevas, úselas para resolver problemas.
Como tecnólogos, tendemos a usar las herramientas más nuevas con la esperanza de arreglar las cosas mágicamente.  Que sea útil es la clave, aunque no sea lo máximo.

5. Leer, y mucho.
Si no lee acerca de la industria tarde o temprano quedará fuera de ella.

6. Pruebe nuevas técnicas y tecnologías.
Esto no se contrapone con lo dicho anteriormente. Es necesario probar cosas nuevas para determinar si puede ser útil.  Probar cosas nuevas ayuda a aprender y a mantenerte al tanto de la industria.  Pruebe sin poner en riesgo un proyecto crítico.

7. Si falla aprenderá algo.
Si su código falla al menos aprenderá porque no funciona y refinarás la solución. En algunos casos, se puede considerar a la falla como un pequeño éxito.

8. Cambie el software.
Algunas veces se necesita simplemente terminar el trabajo, pero se debe estar consiente de la deuda técnica que se adquiere. Si simplemente se entrega software sin remover la deuda técnica de forma continua, a la larga el proyecto será una verdadera pesadilla cuando demasiados errores se hayan acumulado.

9. Hacerlo de la “forma correcta”.
Muchos desarrolladores tienen la idea de una “forma correcta” de diseño y desarrollar aplicaciones, pero esto puede no ser lo ideal para el proyecto o puede estar sobrado. Esto parece una contradicción con el punto anterior, pero lo ideal es conservar un balance.

10. Deja el código mejor de lo que lo encontraste.
En vez de predicar los beneficios de la refactorización, piense si quieres mantener una pila de código que se vuelve cada vez peor. Si se limpia un poco cada vez que se modifica entonces no será tan difícil después.

11. Tenga en cuenta siempre la concurrencia.
Si esta construyendo una aplicación web, y no nos referimos a algo de la escala de Facebook, cosas raras pueden ocurrir con la carga excesiva.  Siempre que se tenga una aplicación con una concurrencia de usuarios mayor a 100 pueden ocurrir cosas raras cuando se lee y se escribe sobre algunos recursos, como en las instancias de HashMaps y esto es solo alguna de las cosas de las que te debes preocupar.

12. La cantidad de almacenamiento puede ser libre, pero la transferencia apesta.
Quizá piensa que escribir todo en disco es una forma excelente de persistir datos. Generalmente lo es, pero si usa el almacenamiento en disco para guardar recursos temporales sin depurar, su aplicación podría volverse lenta muy rápidamente.  El almacenamiento debería limitarse a aquellos datos que necesiten persistir por largos periodos de tiempo, o cuando los datos no pueden residir en memoria.

13. La memoria no puede llegar tan lejos como se piensa.
Para comenzar, muchos tienen sus aplicaciones y sus bases de datos en el mismo servidor. Esto es perfectamente aceptable hasta que ambos requieran de mucha RAM.  Por ejemplo típicamente se tiene una aplicación con Tomcat a 528MB, no obstante una vez que se tiene que lidiar con el almacenamiento persistente (RDBMS, NoSQL, etc) frecuentemente se puede pasar hasta los 8GB y las cosas pueden ponerse difíciles. Obviamente, esto depende mucho de los usuarios que acceden al sistema y de cuantos datos almacenan.

14. El almacenamiento en cache lo arregla todo hasta que el servidor colapsa. Si se buscan mecanismos para liberar de consultas excesivas a la base de datos, se termina usando una especie de cache.  El problema es que el cache puede terminar usando mucha más memoria que la que se usa de forma típica, especialmente cuando se tiene que lidiar con datos que dependen del numero de usuarios que acceden. Lo peor de usar un cache es que se puede llegar al punto en que se genere un error OutOfMemory, por mencionar el caso de java.  En este punto, el servidor caerá o dejará de responder y el cache no será de ninguna utilidad y se habrá convertido en parte del problema.

15. Piense como un consultor.  Con los empleados algunas empresas tienden a cambiar las cosas.  Los plazos se pueden mover, el alcance puede aumentar y el desarrollador tiene que encontrar la manera de cumplir con estas nuevas restricciones.  Es necesario que se deje en claro que los plazos no pueden moverse debido a que el trabajo necesario para hacer las cosas no cambia o que el alcance no puede aumentar sin hacer lo mismo con el número de recursos disponibles.  Los consultores tienden a administrar los proyectos de forma diferente que los empleados y está en estos últimos cambiar esa regla.

 

Fuente

Dejar un Comentario

19 + dieciseis =

Empiece a escribir y presione Enter para realizar la búsqueda

Top Contáctanos