Llegamos a ustedes gracias a:



Reportajes y análisis

Doce errores de programación que se deben evitar

[16/12/2010] Una revista de autos una vez declaró que un vehículo tiene "carácter", si se necesitan 15 minutos para explicar su idiosincrasia antes de que pueda ser prestado a un amigo. Mediante esa norma, cada pieza de software tiene un carácter - con demasiada frecuencia, apenas sale de la caja.

La mayoría de las "peculiaridades" de la programación son propias de un contexto particular, lo que hace que sean muy oscuras. Los sitios web que ofrecen datos XML, por ejemplo, no puede haber sido codificados para decirle al navegador que espere los datos XML, causando una demora de todas las funciones hasta que el valor correcto encaje en su lugar..
Sin embargo, ciertas prácticas de programación hacen que la mayoría de los desarrolladores se tire de los cabellos al abrir un archivo que ha estado exhibiendo demasiada "personalidad". Pase un tiempo en un bar cerca de cualquier compañía de tecnología, y escuchará los gritos: ¿Por qué el programador sigue utilizando esa estructura anticuada? ¿Dónde estaba el mecanismo de defensa contra los ataques de la web? ¿No había ninguna reflexión sobre lo que un novato haría con el programa?
Criaturas de hábitos, nosotros los desarrolladores parecemos encerrados en ciertos modos de falla que no pueden ser evitados, como es la frecuencia con la que somos víctimas de una particular práctica pobre de programación.
A continuación encontrará las dificultades de programación más comunes, cada una de ellas está acompañada por su opositora, dejando una prueba de que la programación, de hecho, se está convirtiendo en un arte -que requiere una mano hábil y una mente creativa para lograr un justo medio entre los extremos problemáticos.
Error de programación Nº 1: Acelerándolo y haciéndolo fallar
Apuntalar las bases es la forma más fácil de socavar el código. Con frecuencia esto significa perder de vista cómo el comportamiento arbitrario del usuario afectará su programa. ¿La entrada de un cero encontrará su camino en una operación de división? ¿El texto introducido es de la longitud correcta? ¿Los formatos de fecha han sido controlados? ¿El nombre del usuario ha sido verificado en la base de datos? Los errores en los lugares más pequeños hacen que el software falle.
La peor parte de la programación descuidada es que los avances en el diseño de lenguaje destinados a solucionar estos problemas no hacen su trabajo. Tome la última versión de Java, que trata de hacer la comprobación de puntero nulo más fácil, ofreciendo sintaxis abreviada para la prueba sin fin de puntero. Simplemente añadiendo un signo de interrogación a cada invocación de método, incluye automáticamente una prueba de punteros nulos, en sustitución de un nido de ratas de las posibles declaraciones, tales como:
<code>
    public String getPostcode(Person person) {
      String ans= null;
      if (person != null) {
        Name nm= person.getName();
        if (nm!= null) {
          ans= nm.getPostcode();
        }
      }
      return ans
    }
</code>
Con esto:
<code>
   public String getFirstName(Person person) {
      return person?.getName()?.getGivenName();
    }
</code>
Al final, sin embargo, estas mejoras de sintaxis solo se puede evitar que el código se estrelle, no aseguran que sea útil. Después de todo, no eliminan la raíz del problema: la proliferación de los valores nulos debido a la programación rápida y suelta.
Error de programación Nº 2: La sobrecarga de detalles en la otra cara
El software excesivamente abotonado puede frenarlo hasta hacer que se arrastre. La comprobación de unos pocos punteros nulos no puede hacer mucha diferencia, pero algunos software se escriben para ser como un obsesivo-compulsivo, que debe verificar que las puertas estén bloqueadas una y otra vez, de tal modo que el sueño no llega nunca.
La dedicación incansable a los detalles, incluso puede bloquear el software si el control obsesivo requiere comunicarse con un sitio web a distancia sobre la red. Tengo varios paquetes que se frenan a paso de tortuga si los utilizo en una laptop sin conexión a Internet W-iFi, ya que están tratando desesperadamente de llamar a casa para ver si una nueva versión puede estar disponible. El Wi-Fi LED parpadea, y el software se bloquea, buscando constantemente un punto de acceso que no está allí.
El desafío es diseñar las capas del código para comprobar los datos cuando aparecen por primera vez, pero esto es mucho más fácil decirlo que hacerlo. Si varios programadores trabajan en una biblioteca, o incluso si solo uno hace toda la codificación, es difícil recordar si el puntero se comprobó, y cuándo fue.
Error de programación Nº 3: No simplificar el control muy a menudo
Los desarrolladores invitan al desastre por no simplificar el control sobre las tareas en su código.
Mike Subelsky, uno de los co-fundadores de OtherInBox.com, es un entusiasta defensor de la existencia de un único lugar en el código para cada puesto de trabajo. Si hay dos lugares, las probabilidades son que alguien cambie una y la otra no. Si hay más de dos, las probabilidades de que alguien va a dejar de mantener a todos trabajando de la misma manera empeoran aún más.
"Habiendo trabajado en base a un código por más de tres años, mi mayor pesar, es no estar haciendo el código más modular", señala Subelsky. "He aprendido a la fuerza porqué es tan importante el Principio de Responsabilidad individual. Me adhiero a él con fuerza en el nuevo código, y es lo primero que ataco al refactorizar el código antiguo".
Subelsky, como usted puede suponer, es un programador de Ruby on Rails. El Framework alienta el código magro asumiendo que la mayor parte de la estructura del programa se divide en patrones conocidos, una filosofía que los programadores de Rails a menudo resumen como "convención no configuración". El programa asume que si alguien crea un objeto de tipo Nombre con dos campos primer nombre y apellido, entonces, inmediatamente debe crear una tabla de base de datos llamada Nombre con dos columnas, primer nombre y apellido. Los nombres se especifican en un solo lugar, evitando cualquier problema posterior si alguien no puede cumplir todas las capas de la configuración en sincronización.
Error de programación Nº 4: Delegarle demasiado a frameworks
Algunas veces las herramientas mágicas solo conducen a la confusión. Al abstraer la funcionalidad y asumiendo lo que queremos, los frameworks muy a menudo dejan a los desarrolladores en pérdida por lo que salió mal en su código.
G. Blake Meike, un programador con sede cerca de Seattle, es uno de los muchos desarrolladores que encuentra la excesiva dependencia de las herramientas automatizadas, como Ruby on Rails, como un obstáculo cuando se trata de producir un código limpio.
Convención, por definición, es algo fuera del código", señala Meike. "A menos que sepa las reglas de Ruby on Rails para convertir una URL en una llamada al método, por ejemplo, no hay manera, en absoluto, que se de cuenta de lo que realmente sucede en respuesta a una consulta".
Él considera que la lectura del código a menudo significa tener un manual cerca para descifrar lo que el código está haciendo a sus espaldas.
"Las reglas no son del todo triviales, y al mismo tiempo bastante razonables. Con el fin de trabajar sobre una aplicación Ruby on Rails, solo hay que conocerlas. A medida que la aplicación crece, depende cada vez más de estos pedacitos casi triviales de conocimiento externo. Eventualmente, la suma de todos los bits casi triviales es, decididamente, no trivial. Es una ecósfera de cosas que tiene que aprender a trabajar sobre la aplicación y recordar mientras la está depurando", indica.
Para empeorar las cosas, los frameworks a menudo lo pueden dejar a usted, y a cualquiera que venga después de usted, enredado con un código que es muy difícil de entender, modificar o ampliar.
Como Mike Morton, otro programador, explica, "Te llevan el 90% del camino hacia la cima de la montaña en una silla de manos, pero eso es todo. Si quiere hacer el último 10%, tendría que haberlo pensado antes y haber llevado oxígeno y pitones".
Error de programación Nº 5: Confiar en el cliente
Muchos de los peores errores de seguridad aparecerán cuando los desarrolladores asumen que el dispositivo del cliente hará lo correcto. Por ejemplo, el código escrito para ejecutarse en un navegador puede ser reescrito por el navegador para ejecutar cualquier acción arbitraria. Si el desarrollador no vuelva a comprobar todos los datos que vienen de vuelta, cualquier cosa puede salir mal.
Uno de los ataques más simples se basa en el hecho de que algunos programadores solo pasan de largo los datos del cliente a la base de datos, un proceso que funciona bien hasta que el cliente decide enviar por SQL en lugar de una respuesta válida. Si un sitio web pide un nombre de usuario y añade el nombre de una consulta, el atacante puede escribir en el nombre x; usuarios de DROP TABLE; La base de datos debidamente asume que el nombre es x y luego pasa al siguiente comando, que suprime la mesa llena con todos los usuarios.
Hay muchas otras maneras en que la gente inteligente puede abusar de la confianza del servidor. Las encuestas web son invitaciones para inyectar sesgo. Los desbordamientos de búfer siguen siendo una de las maneras más sencillas de corromper software.
Para empeorar las cosas, los agujeros de seguridad graves pueden surgir cuando se encadenan tres o cuatro agujeros aparentemente benignos. Un programador puede dejar que el cliente escriba un archivo si se asume que los permisos del directorio serán suficientes para detener cualquier escritura caprichosa. Otro puede abrir los permisos solo para corregir algunos errores aleatorios. Solo que no hay problemas, pero en conjunto, estas decisiones de codificación puede entregar acceso arbitrario al cliente.
Error de programación Nº 6: No confíe del todo en el cliente
Algunas veces, demasiada seguridad puede llevar, paradójicamente, a agujeros abiertos. Hace apenas unos días, me dijeron que la manera de resolver un problema con una determinada pieza de software ha sido solo para "chmod 777" el directorio y todo su interior. Demasiada seguridad terminó dañando las obras, dejando a los desarrolladores con las restricciones flojas oólo para mantener los procesos en ejecución.
Los formularios web son otro campo de batalla donde la confianza puede hacerle ahorrar en el largo plazo. No solo a nivel de seguridad del banco, los largos cuestionarios de datos personales, y la confirmación de direcciones de correo electrónico, desalientan a la gente de participar incluso en sitios relacionados con el chisme, pero tener que proteger esos datos una vez que se eligieron y almacenaron, puede ser un problema mucho mayor de lo que en realidad es.
Debido a esto, muchos desarrolladores web están buscando reducir la seguridad tanto como sea posible, no solo para hacer que a las personas se les haga más fácil engancharse con sus productos, sino también ahorrarles el problema de defender más de la cantidad mínima de datos necesarios para establecer una cuenta.
Mi libro, "Bases de datos traslúcidas", describe una serie de formas en que las bases de datos pueden almacenar menos información, mientras que prestan los mismos servicios.
Error de programación Nº 7: Confiar demasiado en las cajas mágicas
¿Preocupado acerca de la seguridad? Solo añada un poco de criptografía. ¿Quiere que su base de datos realice copias de seguridad? Basta con pulsar el botón de reproducción automática. No se preocupe. El vendedor dijo: "Simplemente funciona".
Los programadores de computadoras son muy suertudos. Después de todo, los científicos de la computación siguen creando bibliotecas maravillosas llenas de un sinfín de opciones para arreglar lo que aflige a nuestro código. El único problema es que la facilidad con la que alguien puede aprovechar el trabajo de otro también puede ocultar los problemas complejos que se pasan por alto o, peor aún, introducir nuevos obstáculos en nuestro código.
La criptografía es una de las principales fuentes de debilidad aquí, señala John Viega, co-autor de "24Pecados Capitales de Seguridad de Internet: Defectos de programación y cómo solucionarlos". Muchos programadores asumen que se pueden vincular en la biblioteca de encriptación, pulsar un botón, y tener una seguridad férrea.
Pero la realidad es que muchos de estos algoritmos mágicos tienen deficiencias sutiles, y evitar estas debilidades requiere aprender más de lo que está en la sección de inicio rápido del manual. Para empeorar las cosas, solo saber que tiene que mirar más allá de la sección de inicio rápido supone un nivel de conocimiento que va más allá de lo que está cubierto en la sección de inicio rápido, esta es probablemente la razón por la que muchos programadores están confiando la seguridad de su código a la sección de inicio rápido en primer lugar. Como dicen los profesores: "Usted no puede saber lo que no conoce".
Error de programación Nº 8: Reinventando la rueda
Una vez más, hacer su propio yogur, matar a sus propios cerdos, y escribir sus propias bibliotecas solo porque usted piensa sabe una mejor manera de codificar, puede volverse en su contra.
"Cultivar su propia criptografía es una agradable vista para los atacantes", señala Viega, incluso los expertos cometen errores al tratar de impedir que otros encuentren y exploten las debilidades en sus sistemas.
Por lo tanto, ¿en quién confiar: en usted o en los llamados expertos que también cometen errores?
La respuesta cae en el ámbito de la gestión de riesgo. Muchas bibliotecas no necesitan ser perfectas, por lo que acaparar una caja mágica es probable que sea mejor que el código que escribe. La colección incluye rutinas escritas y optimizadas por grupo. Pueden cometer errores, pero el proceso más amplio puede eliminar muchos de ellos.
Error de programación Nº9: Demasiada apertura a los usuarios
Los programadores aman poder acceder a las variables y ajustar muchas partes de una pieza de software, pero la mayoría de los usuarios no pueden imaginar siquiera cómo hacerlo.
Por ejemplo Android. La última vez que instalé un paquete de software para mi teléfono Android, me pidió la aprobación de cinco o seis maneras en que el software podía acceder a mi información. Por supuesto, el equipo de Android ha creado un conjunto maravillosamente detallado de las opciones que me permite habilitar o no el software en función de si se requiere el acceso a la cámara, seguimiento de mi ubicación, o una docena de otras opciones. Pero poniendo en los usuarios la responsabilidad de personalizar funcionalidades que no entienden por completo, puede provocar un desastre en forma de agujeros de seguridad inadvertidos y violaciones de privacidad, por no hablar de software que puede resultar demasiado frustrante o confuso para su mercado objetivo.
La ironía es que, a pesar de estar obsesionados con listas de control a la hora de tomar decisiones de compra, la mayoría de usuarios no pueden controlar la amplitud de las prestaciones ofrecidas por cada acto de software. Con demasiada frecuencia, las características adicionales desordenan la experiencia, haciendo que el software sea difícil de navegar y usar.
Error de programación Nº 10: Sobre determinar la experiencia de los usuarios
Algunos desarrolladores deciden evitar el problema de demasiadas características, ofreciendo exactamente una solución. Gmail es famoso por ofrecer solo algunas opciones que los desarrolladores aman. Usted no tiene carpetas, pero puede rotular o etiquetar correo con palabras, una característica que los desarrolladores argumentan es aún más potente.
Esto puede ser cierto, pero si a los usuarios no les gusta la idea, se buscan formas de evitar estas limitaciones -un resultado que podría traducirse en problemas de seguridad o el aumento de la competencia no deseada. La búsqueda de este medio entre simple y rico en funciones es un desafío interminable que puede resultar costoso.
Error de programación Nº 11: Cerrando la fuente
Uno de los retos más difíciles para cualquier empresa es determinar cuánto se comparte con las personas que utilizan el software.
John Gilmore, co-fundador de una de las primeras compañías de software de código abierto, Cygnus Solutions, señala que la decisión de no distribuir el funcionamiento del código va contra la integridad de dicho Código, siendo una de las maneras más fáciles de desalentar la innovación y, lo más importante, descubrir y corregir los errores.
"Un resultado práctico de la apertura de su código es que gente de la que nunca ha oído hablar contribuirá a mejorar su software", señala Gilmore. "Van a encontrar errores (y tratar de solucionarlos); van a agregar funciones que van a mejorar la documentación. Incluso cuando su mejora ha sido hecha de forma amateur, unos minutos de reflexión le revelarán una manera más armoniosa de lograr un resultado similar".
Las ventajas son más profundas. A menudo, el propio código crece más modular y mejor estructurado conforme los demás vuelven a compilar el programa y lo trasladan a otras plataformas. Solo la apertura del código le obliga a hacer que la información sea más accesible, comprensible, y mejor. A medida que hacemos los pequeños ajustes para compartir el código, ellos alimentan los resultados de nuevo en la base del código.
Error de programación Nº 12: Suponer que la apertura es una panacea
Millones de proyectos de código abierto se han puesto en marcha, y solo una pequeña fracción atrae cada vez a más de unas pocas personas para ayudar a mantener, modificar o ampliar el código. En otras palabras, W.P. Kinsella "si lo construyes, ellos vendrán" no siempre produce resultados prácticos.
Mientras que la apertura puede permitir que otros entren al juego y, por lo tanto, mejorar el código, el mero hecho de que esté abierto no servirá de mucho a menos que haya un incentivo para los colaboradores externos pongan el trabajo. Las pasiones entre los defensores del código abierto pueden cegar a algunos desarrolladores sobre la realidad de que la apertura por sí sola no impide los agujeros de seguridad, fallas de eliminación, o que se haga gran cantidad de código sin terminar intrínsecamente útil. La gente tiene otras cosas que hacer, y una pila de código abierto tiene que competir con el excursionismo, la familia, bares y puestos de trabajo remunerados.
La apertura de un proyecto también puede agregar una sobrecarga para las comunicaciones y la documentación. Un proyecto de código cerrado requiere documentación sólida para los usuarios, pero un buen proyecto de código abierto viene con una amplia documentación de la API y los mapas de ruta para el desarrollo futuro. Este trabajo extra vale la pena para los grandes proyectos, pero puede llegar a hacerse pesado para los más pequeños.
Con demasiada frecuencia, el código que trabaja parte del tiempo es planteado en SourceForge con la esperanza de que los elfos mágicos dejen de producir los zapatos y se apresuran a poner en marcha el compilador -una decisión que puede descarrilar el impulso de un proyecto antes de que realmente se inicie.
La apertura del proyecto también puede eliminar el apoyo financiero y fomentar una especie de ley de la calle. Muchas compañías de código abierto tratan de mantener alguna característica propietaria en su control, lo que les da cierta ventaja al obtener gente que pague para apoyar al equipo de desarrollo. Los proyectos que se basan más en los voluntarios que en los programadores pagados a menudo encuentran que los voluntarios son impredecibles. Mientras que la competitividad y la creatividad muy abiertas pueden dar grandes resultados, algunos de huyen de nuevo hacia la estructura, jerarquía, y el desarrollo de apoyo metódico y autoritario.
Peter Wayner, InfoWorld