Cuando es un Ingeniero de Software No es un Ingeniero de Software?

Posted by admin on February 13, 2013

El título de “ingeniero de software” tiene que ser entre los más explotados en el corporativo de alta tecnología del mundo. También es uno de los más populares.

Y ¿por qué no? Suena mucho mejor que el “programador de computadoras,” y se ve mucho mejor en la tarjeta de visita de uno. Por desgracia, a menudo es inexacta. La ingeniería es, después de todo, la aplicación de los principios técnicos para desarrollar los sistemas que son robustos, eficientes y elegantes. He encontrado que un gran número de ingenieros de software pueden desarrollar programas de trabajo, pero el diseño de ingeniería real, poco o nada.

¿Suena esto duro? Tal vez, pero también he encontrado difícil de negar. Me he encontrado muy pocos ingenieros de software, por ejemplo, que tienen estilos de codificación limpios, nítidos y legibles-un elemento esencial del diseño de software elegante. También he encontrado un predominio de las funciones de manera críptica por escrito, abstracciones torpes de software y código espagueti extraño. Para mi consternación, he descubierto que incluso entre los graduados en ciencias informáticas, muchos reducen programación orientada a objetos con el mero uso de datos privados, las funciones públicas y ejemplificaciones de los objetos. Es suficiente para romper el corazón de un profesor.

Ahora, no voy a ir tan lejos como para decir que la mayoría de los programadores escribir código espagueti. Eso no sería justo. Sin embargo, creo que los programadores de relativamente pocas personas tienen un profundo aprecio por el arte del desarrollo de software. Eso no quiere decir que son ignorantes de estas cosas, no en absoluto. Por el contrario, es más que los aspectos de ingeniería de diseño de código elegante son demasiado descuidado.

Creo que esto sucede porque las herramientas de programación modernos han hecho el diseño de códigos adecuada parecer una molestia. En los primeros años de la computación, la gente se vieron obligados a escribir sus diseños de software, pensando en muchos detalles finos antes de que se sentó delante del ordenador. Hoy en día, con nuestros compiladores rápidos y los sistemas de depuración interactiva, los programadores a menudo les resulta más conveniente para simplemente sentarse y empezar a programar, con sólo un mínimo de diseño de software. Eso sí, entiendo que esto a veces es más eficiente – cuando la tarea de programación es bastante habitual, por ejemplo. Sin embargo, cuando por ejemplo el diseño-como-you-go de desarrollo de software se convierte en una práctica estándar, entonces usted tiene los ingredientes de un completo caos.

En parte, este problema tiene sus raíces en la naturaleza maleable de los programas informáticos. No se precie ingeniero civil tendría que diseñar un puente por vigas golpeando juntos hasta que él tiene algo que funciona, después de todo, si el puente se colapsa, se podría tomar meses para reconstruirlo. Del mismo modo, ningún arquitecto sensato quiere construir una casa sin planos y planos. Sin embargo, es común que los programadores desarrollar software con funciones mal elegidas y sólo sketchiest de los diseños. Después de todo, si el software no funciona, siempre puede encontrar el error y corregirlo – por lo menos, en teoría. En la práctica, estos errores son a menudo difíciles de detectar, y la fijación de ellos puede requerir una cirugía extensa. Las consecuencias de un programa de software mal diseñado puede ser desastroso efecto.

Por esta razón, creo que empresas de alta tecnología necesario para dar la ingeniería de software el respeto que se merece. Ellos necesitan desarrollar una verdadera cultura del diseño de software sistemática, en lugar de limitarse a conformarse con “lo que funcione”. Una empresa que está mirando hacia el futuro tiene que pagar la devoción debida a los principios de mantenimiento de software, la documentación adecuada y un diseño elegante y robusto. También se debe inculcar una cultura de verdadera ingeniería de software entre sus empleados. El no hacerlo puede funcionar en el corto plazo, pero es una receta para el desastre a largo plazo.

Categories: Software

Comments are closed.