Los Principios del Programador

El Principio del Carcter Personal Lo sepamos o no, nos guste o no, nuestro carcter est reflejado en cada lnea de cdigo que escribimos, en cada informe que diseamos, en cada interfaz de usuario que construimos, en cada diagrama que hacemos. Cuando otra persona mira nuestro cdigo o lo que es tan importante, la salida que produce nuestro cdigo esa persona, conscientemente o no, se hace un juicio de nosotros. Piensa en el cdigo que has escrito hasta ahora... cul sera ese juicio? Estaras orgulloso, te pondras en pie y diras que ese cdigo lo has escrito t? O solo admitiras tmidamente que es tuyo, y lanzaras excusas de por qu no es lo bueno que debera ser? Si tu cdigo es malo, alguien que lo lea probablemente asuma que no es el nico cdigo que has hecho mal, que no es lo nico que haces mal. La buena noticia es esta: tenemos control absoluto sobre la calidad de nuestro cdigo. La cuestin no es si uno es capaz de escribir el mejor cdigo posible, sino si se preocupar por intentarlo. Si un programador carece de ciertos conocimientos o de cierta experiencia, pero hace lo posible por escribir el cdigo de forma clara, entendible, bien comentada, de forma que muestre que al menos ha invertido tiempo en aprender algunos fundamentos bsicos, entonces habr actuado como deba con diligencia y eso ser obvio para un observador que lea con atencin. No es razonable que alguien juzgue mal a un programador porque le falte algo de experiencia o porque desconozca an algunas tcnicas. Sin embargo, es absolutamente razonable encontrar una conexin entre la calidad global del cdigo de un programador y la calidad del carcter de dicho programador. El Principio del Carcter Personal establece: Escribe tu cdigo de forma que refleje, y saque a relucir, solo lo mejor de tu carcter personal. El Principio de la Esttica Un aspecto de la programacin que con frecuencia descuidamos es la esttica. La esttica trata sobre la belleza y la elegancia, y del valor de estas cualidades. Mucha gente, sin embargo, cree que la esttica es solo importante cuando se habla de arte y literatura. Pocas personas se dan cuenta de la importancia de la belleza y la elegancia en las cosas cotidianas, y muy pocos programadores se dan cuenta de la importancia de stas cuando se escribe cdigo. La esttica es especialmente importante en el desarrollo de software, un terreno en el que siempre estamos tratando con niveles de abstraccin. Los aspectos estticos de nuestras abstracciones estn directamente relacionados con su extensibilidad y, por lo tanto, con su utilidad.

Un programador debe esforzarse en conseguir la belleza, sin importar la herramienta o el lenguaje de programacin que est utilizando. La belleza puede conseguirse a muchos niveles, desde el alto nivel de la elegancia en el diseo del sistema hasta el ms bajo nivel de la apariencia visual del cdigo en la pantalla. Ser ordenado y claro cuenta. El mejor cdigo no solo funciona de forma correcta y eficiente, y est bien formado desde el punto de vista del compilador; el mejor cdigo es tambin agradable de ver por el ojo humano y por lo tanto ms fcil de absorber y de comprender para el cerebro humano. Steve McConnell escribe en su libro Code Complete, "El disfrute visual e intelectual de un cdigo bien formateado es un placer que pocos no-programadores pueden apreciar. Pero los programadores que se sienten orgullosos de su trabajo experimentan una gran satisfaccin artstica puliendo la estructura visual de su cdigo." (Pgina 399) El Principio de la Esttica establece: Esfurzate por conseguir la belleza y la elegancia en cada aspecto de tu trabajo. El Principio de la Claridad La claridad en el cdigo es un estado que debemos buscar activamente. Uno de los mayores delitos que como desarrolladores podemos cometer es olvidar que nuestro cdigo tiene una vida ms all de los pocos momentos que nos lleva escribirlo. Las probabilidades de que alguien, posiblemente nosotros mismos, maneje nuestro cdigo en el futuro son muy altas. Incluso aunque escribamos un cdigo que funciona perfectamente y nunca causa problemas al usuario, estaremos perjudicando a otros compaeros desarrolladores (sin mencionar a nuestra empresa) si no escribimos nuestro cdigo de la forma ms clara posible. Hay una diferencia entre claro y correcto, y muchas veces se confunden. La correccin es siempre el principal inters del desarrollador, como debe ser. La correccin lleva a que la sintaxis del cdigo sea correcta a los ojos del compilador, que el diseo de la interfaz cubra las necesidades del usuario, y que los algoritmos que se implementan cumplan con sus requerimientos. Pero si no se dedica una atencin igual a la claridad, la comprensibilidad y la mantenibilidad del cdigo sufrirn mucho. Para que nuestro cdigo sea lo ms claro posible, debemos deliberadamente usar tcnicas como la utilizacin de identificadores descriptivos, la modularidad, la indentacin (el sangrado), los espacios en blanco, la cohesin del cdigo, el acoplamiento dbil del cdigo, propiciar la fcil realizacin de las pruebas y la documentacin, y comentar adecuadamente. La falta de claridad en nuestro cdigo causa problemas innecesariamente, y tambin situaciones profesionalmente embarazosas. A nuestros colegas desarrolladores que tienen que tratar con nuestro cdigo en aos (o incluso dcadas) sucesivos. Y a nuestra empresa, con la que no jugamos limpio devalundola; incluso en algunos casos nuestro cdigo puede convertirse en un problema de responsabilidad legal para nuestra empresa.

Dejar a nuestros colegas en esa situacin es como mnimo descorts, pero dejar a nuestra empresa en esa situacin es mucho peor: nosotros llegamos al acuerdo de producir cdigo de calidad por un precio. La empresa ha cumplido pagndonos ese precio pero, en qu situacin sale ella de este acuerdo con nosotros? El Principio de la Claridad establece: Dale el mismo valor a la claridad que a la correccin. Utiliza activamente tcnicas que mejoran la claridad del cdigo. La correccin vendr casi por s sola. El Principio de la Distribucin Este principio se refiere a la distribucin visual del cdigo. El Principio de la Distribucin es un corolario a los dos principios anteriores: El Principio de la Esttica y El Principio de la Claridad. El Principio de la Esttica nos dice que, adems del disfrute intelectual que supone la lectura de cdigo bello y elegante, la propia belleza y la elegancia juegan un papel crucial para conseguir dicho buen cdigo. Por otro lado, El Principio de la Claridad nos dice que hagamos nuestro cdigo lo ms claro posible a un lector humano, y que la claridad va de la mano con la correccin. El Principio de la Distribucin pone estos dos principios duales en prctica. Es difcil discutir la importancia de la distribucin visual del cdigo sin referirnos al principio fundamental de Steve McConnell (Fundamental Theorem of Formating) que establece: "Una buena distribucin visual muestra la estructura lgica de un programa." (pgina 403, Code Complete) Esto significa que la distribucin visual no solo sirve para hacer el cdigo visualmente ms atractivo, sino que tambin acta a nivel del subconsciente haciendo el cdigo ms entendible al lector. El objetivo es reducir la cantidad de trabajo que un lector necesita para entender el cdigo. La apariencia visual debe ser nuestra primera herramienta para comunicarnos con claridad con un lector humano que est leyendo nuestro cdigo. Hay varias tcnicas que aseguran que la distribucin visual del cdigo ayude a entender su estructura lgica. Estas tcnicas deben formar parte de los conocimientos fundamentales de todo programador: uso adecuado de los espacios en blanco (y lneas en blanco), indentacin, agrupamiento de lneas relacionadas, uso de parntesis extra para que las expresiones lgicas y las frmulas matemticas sean ms claras, mrgenes para alinear el cdigo relacionado de distintas lneas, emplazamiento adecuado de delimitadores de bloque, etc. Como Steve McConnell sugiere en su teorema, la idea es utilizar la distribucin visual de nuestro cdigo para comunicar a nivel de subconsciente con el lector. Recuerda que cuando estamos trabajando en el terreno del desarrollo de software, estamos siempre trabajando con abstracciones, y una abstraccin es ms til cuanto ms entendible es.

El Principio de la Distribucin establece: Usa la distribucin visual de tu cdigo para comunicar la estructura de tu cdigo a un lector humano. El Principio de lo Explcito Seguir el Principio de lo Explcito nos ahorrar, a nosotros y a nuestros sucesores, innumerables problemas. El Principio de lo Explcito es un corolario de El Principio de la Claridad. Pero el Principio de la Claridad nos dice que hagamos nuestro cdigo de forma clara y entendible para el lector humano. Y el Principio de lo Explcito tambin se aplica a esa misma entendibilidad, y a lo que es ms importante, a hacer nuestro cdigo ms tolerante a cambios. Veamos un ejemplo simple: muchos lenguajes de programacin ofrecen el concepto de "fichero". Normalmente el fichero no lo proporciona el lenguaje de programacin directamente, sino que se utiliza a travs de una librera. Cuando escribimos el cdigo necesario para abrir el fichero, normalmente existen propiedades para determinar el estado del cursor del fichero. Cuando nuestro cdigo llama a la funcin que abre el fichero, la funcin probablemente tenga un estado del cursor por defecto, lo cual significa que no tenemos que especificar explcitamente el estado del cursor simplemente podemos aceptar el estado por defecto. Si un desarrollador acepta ese estado por defecto, entonces el desarrollador ha introducido una suposicin implcita en su cdigo, lo cual, para empezar, reduce la claridad del mismo. Y lo que es mucho peor, ha creado una oportunidad gigantesca para que se den futuros errores. El estado del cursor afecta directamente el comportamiento del fichero. Nuestro cdigo obviamente depende de ese comportamiento. Qu ocurrira con nuestro cdigo seis meses despus cuando se actualice la librera de manejo de ficheros?Qu ocurre si la nueva versin cambia el estado por defecto del cursor del fichero?Sabes lo que va a ocurrir con el cdigo que asuma el estado por defecto del fichero? Simplemente va a fallar por completo. O peor, va a cambiar su comportamiento en algo leve: alguna condicin de un IF va a ser Falsa en vez de Verdadera, y el bloque ELSE se va a ejecutar en vez del bloque IF que debera ejecutarse; y entonces, meses despus, alguien se dar cuenta de que los datos corruptos y los daos se han extendido por todo el sistema. Por no haber sido explcito, el desarrollador del cdigo del ejemplo acept implcitamente el estado del cursor por defecto, haciendo su cdigo menos tolerante a futuros cambios. Esto es inaceptable. Debemos aprender a detectar donde pueden darse este tipo de problemas (el ejemplo del fichero es uno de muchos, y cada lenguaje de programacin y plataforma tiene otros muchos), y debemos usar nuestros conocimientos para que no nos afecten en el futuro. Como profesionales, debemos saber que el cambio es algo constante en nuestra profesin, y debemos hacer lo posible para asegurar que nuestro cdigo soportar fcilmente esos cambios sin producir errores o resultados incorrectos. Incluso

cuando nuestro cdigo falla, debemos asegurarnos que lo hace correctamente, es decir, que a pesar de fallar, nos proporciona la mayor cantidad de informacin especfica acerca de dnde y por qu ha fallado. El truco para que estos problemas no ocurran es ser explcitos. Los problemas merodean por lo implcito en las suposiciones indocumentadas y no probadas, en las tcnicas crpticas, en las secciones indocumentadas explcitamente, en las cuales nos perdemos como un barco hundindose silenciosamente en el vasto y opaco ocano. El Principio de lo Explicito establece: Intenta siempre favorecer lo explcito sobre lo implcito. El Principio del Cdigo Auto-Documentado El cdigo auto-documentado no se consigue accidentalmente. Como desarrolladores, debemos esforzarnos en el desarrollo de un estilo de codificacin slido, lo cual es la clave del cdigo auto-documentado. Debemos estar constantemente mejorando y perfeccionando nuestro estilo, de forma que cada programa que escribimos sea mejor que el anterior. Un estilo bien desarrollado se consigue incorporando tcnicas probadas, como el uso de identificadores informativos y consistentes; la modularizacin bien cohesionada y acoplada; evitar el uso de tcnicas difciles de comprender; hacer una buena distribucin visual del cdigo; dar nombres adecuados a las constantes; probando y documentando las suposiciones; y muchas otras. Para aprender estas tcnicas debemos leer los textos realizados por otros que nos precedieron, y que abrieron camino. Buscar en la bibliografa clsica. Aprender de los maestros. Suscribirse a revistas. Unirse a listas de discusin de Internet. Leer cdigo y cdigo de otros programadores. Cuando veas cdigo que decepciona estas expectativas, analzalo y trata de ver por qu. Cuando veas cdigo que alcanza el alto nivel que buscamos, trata de identificar las tcnicas que el desarrollador us para alcanzar ese gran nivel. Hay un dicho que dice: cualquier tonto puede aprender de sus propios errores; una persona sabia tambin aprende de los errores ajenos. Y qu ocurre con los comentarios? Los necesitamos aunque nuestro cdigo est autodocumentado? Auto-documentar el cdigo, como la perfeccin, es un objetivo difcil de conseguir, probablemente imposible. Sin embargo, eso no debe detenernos en nuestro empeo. All donde esa perfeccin no se pueda conseguir, debemos suplementar nuestro esfuerzo aadiendo buenos comentarios. El cdigo bien escrito no debe necesitar demasiados comentarios; debe explicarse por s mismo. De todas formas, aadir ciertos comentarios es necesariosolo que deben ser del tipo adecuado (ver El Principio de los Comentarios).

Visto de cerca, el cdigo verdaderamente auto-documentado es un placer de contemplar, y a su observador le queda claro que esa maravilla solo pudo ocurrir mediante el esfuerzo de un ingeniero de software concienzudo y diligente. El Principio de Cdigo Auto-Documentado establece: La documentacin ms fiable para el software es el propio cdigo. En muchos casos, el propio cdigo es la nica documentacin. Por lo tanto, esfurzate en hacer que tu cdigo sea auto-documentado, y all donde no sea posible, aade comentarios. El Principio de los Comentarios Los comentarios son armas de doble filo. Usados correctamente, pueden mejorar infinitamente la extensibilidad y el mantenimiento del cdigo. Usados de forma indebida, pueden hacerlo confuso y menos legible. Comentar indebidamente es en el mejor de los casos de poca ayuda, y en el peor de los casos un enorme desastre. El Principio de los Comentarios tiene tres apartados: Primero, comenta mediante frases completas. Esta simple tcnica incrementa en gran medida la comprensin por parte de un lector tanto de los propios comentarios como del cdigo que comentan. Los fragmentos de frases tienden a ser crpticos. Escribir cada comentario mediante una frase completa tambin hace que lo entiendan ms personas, lo cual es muy importante en el entorno multa-cultural en el que nos encontramos hoy da. Los comentarios de alta calidad escritos mediante frases completas tambin son una ayuda para instruir a desarrolladores con menos experiencia. Segundo, usa los comentarios para resumir cdigo. El "comentario resumen" describe un bloque de cdigo con la idea de ahorrar a una persona el tiempo que llevara leer todo el cdigo que el comentario describe. El comentario resumen aparece normalmente unas lneas por encima de un bloque de cdigo. Un buen resumen no repite de nuevo el cdigo, sino que explica diversas lneas de cdigo en dos o tres frases. Tercero, intenta siempre comentar "a nivel de la intencin". Lo que esto quiere decir es que se debe comentar a nivel del problema, ms que a nivel de su solucin. El cdigo es la solucin al problema. Idealmente, el cdigo debera hablar por s mismo (ver El Principio del Cdigo Auto-Documentado). Una persona que lea el cdigo, si el cdigo es bueno, debera entender fcilmente qu hace el cdigo y cmo lo hace. Sin embargo, la informacin que no permanece en el cdigo es precisamente lo que haba en la mente del desarrollador que lo escribi: su intencin. En general, esto es lo que necesita estar comentado. Cul era la intencin del desarrollador?Con qu intencin se ha usado ese cdigo? Cmo intenta este cdigo solucionar el problema en cuestin? Cul es la idea que hay detrs de ese cdigo? Cmo este cdigo explcitamente se relaciona con las otras partes de cdigo?. Uno de los mayores pecados que un desarrollador puede cometer es abandonar su cdigo sin que su intencin quede clara a futuros lectores del cdigo.

El Principio de los Comentarios establece: Comenta mediante frases completas para resumir y comunicar la intencin. El Principio de las Suposiciones El Principio de las suposiciones es un corolario al Principio de lo Explcito. Hacer comprobaciones y documentar bien las suposiciones hechas en el cdigo tiene varios beneficios: uno, incrementa su comprensin; dos, hace el cdigo ms predecible; tres, hace el cdigo ms fcil de mantener; cuatro, reduce la necesidad de comentarios; cinco, hace el cdigo ms fiable; seis, hace el cdigo ms comunicativo cuando algo va mal; siete, la deteccin temprana mediante comprobaciones protege los datos de que se corrompan ; ocho, obliga que prestemos atencin a las suposiciones y comprobaciones que hace una rutina, y por tanto a su relacin con otras rutinas y datos compartidos, lo cual reduce la incidencia de errores. Las comprobaciones son la piedra angular de la programacin defensiva. En realidad en cada pieza de cdigo hacemos suposiciones. Lo que ocurre es que algunas son obvias y no es necesario que se comprueben ni se documenten. Sin embargo, podemos y debemos comprobar (y documentar) las muchas otras suposiciones que son menos evidentes. El tipo de suposiciones ms comn que deben ser comprobadas (y documentadas), son los pre-requisitos en los que una rutina se basa. Estas comprobaciones normalmente son una serie de sentencias If...Then al principio de la rutina. Si alguna de las comprobaciones falla, entonces el cdigo debe ejecutar una accin que corrija la situacin, o bien devolver un mensaje de error explicando que una de las suposiciones fall. (Otra forma de hacer comprobaciones de las suposiciones, a veces pasada por alto, es el uso de asertos, que son expresiones Verdadero/Falso que normalmente slo se compilan en versiones de "depuracin" del programa para su prueba.) El Principio de las Suposiciones establece: Da los pasos que sean razonables para comprobar, documentar y prestar atencin a las suposiciones hechas en cada mdulo y rutina. El Principio de la Interfaz con el Usuario La formulacin de esta regla est tomada prestada de About Face: The essentials of User Interface Design, escrito por el gur del diseo de interfaces de usuario: Alan Cooper. Cooper abunda en esta idea en su posterior libro, The Inmates are Running the Asylum : "La mayora del software se usa en entornos de trabajo, donde las vctimas de los malos interfaces de usuario son los trabajadores. Sus trabajos les obligan a usar el software, ellos no pueden elegir no usarlodeben tolerarlo lo mejor que puedan. Estn obligados a aguantarse su frustracin y a ignorar la vergenza que sienten porque el software les hace

sentirse estpidos".(Pgina 34) Esta es una afirmacin que debe hacer que nos paremos a considerar el impacto real, bueno o malo, que nuestro software tiene en la gente. Cmo llega un usuario a sentirse estpido?. Alan Cooper ha dedicado dos libros enteros a responder a esta pregunta, y otros autores se han enfrentado tambin a este tema (incluyendo a Donald Norman en su excelente libro, The Design of Everyday Things.) Obviamente, aqu no podemos extendernos tanto. Pero de todas formas, aqu va un ejemplo sencillo: un usuario hace click en un botn e inmediatamente le sale un mensaje que dice: "No puede usar esa funcin en este momento". Entonces por qu estaba el botn habilitado para ser pulsado? El desarrollador, por no tomarse la molestia tan sencilla de deshabilitar o bien ocultar el botn, ha creado una situacin en la que l o ella es como un bromista que seala una falsa mancha en la camisa del pobre usuario y le da en la cara cuando ste mira hacia abajo. Muy divertido. El mal diseo de la interfaz de usuario es un enorme problema que afecta a toda la industria del hardware y del software. Es triste comprobar como desarrolladores tanto de hardware como de software regularmente disean soluciones que terminan haciendo que los usuarios se sientan estpidos. Es incluso ms triste que muchos desarrolladores sean felices en su ignorancia de desconocer el estrs que causan a la gente. Sin embargo, como desarrolladores estamos en la posicin de ayudar a resolver este problema. Como desarrolladores software, nuestra principal responsabilidad en cuanto a la interaccin con el usuario descansa en el diseo de la interfaz de usuario. Afrontmoslo: en la mayora de los casos no hay un diseo de la interfaz de usuario preparado con antelacin. La mayora de las decisiones de diseo de la interfaz de usuario (y esto incluye el diseo de los informes que genera el software) son tomadas por el desarrollador mientras se construye. Por lo tanto, en la mayora de los casos, es solo responsabilidad del desarrollador tomar los pasos necesarios para no hacer que el usuario se sienta estpido. El desarrollador es el que sita los botones y los campos. El desarrollador, por tanto, tiene casi control total de la experiencia que vive el usuario delante del software. El Principio de la Interfaz con el Usuario establece: Nunca hagas que el usuario se sienta estpido. El Principio de Volver Atrs Todos hemos sido culpables alguna vez de esto: "No tengo tiempo de hacer eso ahora. Ya volver y lo har luego". Este tipo de decisiones suelen aplicarse a tareas como comentar el cdigo, su adecuada distribucin visual, el control de errores, la modularizacin adecuada, la correcta implementacin, etc. Quizs t seas esa persona, rara, que siempre vuelve ms tarde a ese cdigo y hace todo ese trabajo tedioso, pero la mayora de nosotros los mortales nunca lo hacemos.

El momento de hacer todas esas tediosas tareas asociadas a la codificacin es el preciso momento en el que se est escribiendo el cdigo. La principal razn por la que nadie vuelve ms tarde a "limpiar" su cdigo es que una tarea que es tediosa de realizar mientras escribes el cdigo, es monumentalmente ms tediosa cuando tienes que volver atrs y hacerla despus. Alguien cree de verdad que volver y codificar buenas comprobaciones de errores en cientos de rutinas a posteriori es menos tedioso que crear esas rutinas con sus comprobaciones de errores desde el principio? No solo odiars cada minuto de esa tarea, sino que casi con toda probabilidad introducirs errores que no estaban all antes. En el caso de los comentarios, los comentarios que aadas despus nunca sern tan buenos como los comentarios que podras haber escrito justo en el momento en que escribiste el cdigo. Y qu ocurre si tienes que dejar un trabajo antes de tener la oportunidad de volver atrs y hacer todas esas tareas? Habrs dejado esa tediosa y mucho ms monumental tarea a otro, lo cual es muy poco profesional. El Principio de Volver Atrs establece: El momento de escribir buen cdigo es justamente el preciso momento en el que lo ests escribiendo. El Principio de El Tiempo y El Dinero de Otros El Principio de El Tiempo y El Dinero de Otros se aplica a todo el trabajo que realiza un desarrollador: cdigo, informes, interfaces de usuario, modelos, diagramas, pruebas, y documentacin. Esta regla no solo se aplica al cdigo, sino a la profesionalidad. Recuerda la regla con la que empezamos: El Principio del Carcter Personal establece: Escribe tu cdigo de forma que refleje, y saque a relucir, solo lo mejor de tu carcter personal. El Principio de El Tiempo y El Dinero de Otros es una forma menos cordial de decir lo mismo. Enorgullcete de tu trabajo, porque tu trabajo eres t, y te juzgarn por el trabajo que has hechoy a veces slo por eso. Incluso si no te preocupa que te juzguen, Te preocupa hacer las cosas bien hechas? Te sientes bien habiendo aceptado dinero por ese cdigo? Te preocupa como t y tu trabajo se refleja en la profesin de ingeniera del software en general? Escribir cdigo para alguien no es un tan solo un juego divertido, la calidad del trabajo de cada desarrollador se refleja en todos los dems desarrolladores. El Principio de El Tiempo y El Dinero de Otros establece: Un verdadero profesional no gasta el tiempo ni el dinero de otras personas produciendo software que no est razonablemente libre de fallos; que no est mnimamente probado; que no cumpla con los requisitos establecidos; que est falsamente adornado con caractersticas innecesarias; o que tenga un aspecto deplorable.

10 Consejos para programar mejor A veces tenemos malas costumbres, y con muchos aspectos, en la programacin no iba ser diferente, por lo que os damos unos pocos consejos para evitar errores y programar mejor. 1. Comenta tu cdigo, comenta mientras programas, cuando finalizas el mismo. Hoy te acuerdas de lo que hace pero, y maana? y si otro lo lee? Comenta que hace esa funcin, que hace cada lnea, nunca ser poco. Los saltos de lneas y las Tabulaciones son tus amigos Es importante que quede claro y se pueda leer. Las tabulaciones, son fundamentales para entender que est dentro de cada parte. No las olvides! Estas escribiendo en varios lenguajes en un mismo fichero?, para algo existen las extensiones, cada lenguaje, cada parte se puede separar en pequeos trozos que harn ms comprensible el cdigo. Si ests haciendo niveles cada uno puede estar en un archivo, si tienes muchas funciones jntalas, junta la carga de recursos, agrupa cada parte para una mejor comprensin, facilitar la lectura y la optimizacin. Usa nombres definitorios para tus variables, sencillos, por ejemplo, DisparoDePersonajePrincipal, algo que nada ms verlo sepas que funcin es. Usa funciones, No repitas cdigo!, si algo lo vas a hacer varias veces son lneas innecesarias, puedes ahorrar tiempo y lneas. Declara las variables antes de usarlas, no vayas definiendo variables por todo el cdigo, antes de usarlo en una funcin o en un fichero. Piensa en lo que creas, no crees 100 variables o arrays y las dejes por ah, lo que creas y no guardas o colocas ms tarde te molestar. Aprende la sintaxis, al igual que a la hora de hablar necesitas saber cmo expresarte, en esto la sintaxis es muy importante. Lee y mira mucho cdigo, lee y vuelve a leer, como lo han hecho, lelo en pseudocodigo y acostmbrate a buscar lo que no sepas.

2.

3.

4.

5. 6. 7. 8. 9. 10.

10 consejos para un programador novato Nadie nace sabiendo ni siendo un experto en cualquier tema. Todo lleva un tiempo de aprendizaje, de prctica y de aplicacin. Desarrollar programas eficaces y funcionales para micro controladores no es la excepcin de esta regla. En este artculo no aprenders a programar sino que encontrars los consejos ms importantes que te guiarn por el camino menos frustrante hacia una realizacin exitosa. Participa de los mejores consejos que se brindan en los foros ms importantes de toda la Web y descubre los secretos que utilizan los programadores ms avezados. Entra al mundo geek y s parte

Foros, listas de correo, blogs, YouTube, MSN y muchos otros medios son utilizados en la Web para permitir que la gente pueda comunicarse entre s y pueda ayudarse mutuamente en los temas referentes a micro controladores. Luego de recorrer durante algunos aos muchos de estos espacios en busca de informacin y conocimientos, he encontrado que la mayora de los interrogantes y consejos que se brindan a quienes recin comienzan en el mundo de los micro controladores se reiteran una y otra vez en todos los lugares. Pareciera que las dudas y las preguntas son siempre las mismas. La razn es muy obvia y sencilla: cada da hay ms gente con ansias de aprender, y como sabemos que t eres uno de ellos, hemos preparado un pequeo listado de las cosas ms importantes a tener en cuenta al momento de iniciarte en este apasionante mundo del micro controlador. Sea cual fuere la marca de micro controlador que prefieras o el lenguaje de programacin que utilices, existen mtodos de trabajo que, cuando te acostumbras a ellos, comienzas a descubrir que todo se vuelve ms fluido, ms sencillo y ms rpido. Es all cuando dejas de perder el tiempo en cosas sencillas o elementales y pasas a utilizar el tiempo para crear y concebir con eficiencia tus mejores trabajos. Al comenzar, las dudas son interminables y los miedos al fracaso suelen ser los culpables de que muchos abandonen su inters por el mundo de los micro controladores. No hay que dejar de tener en cuenta que la informacin est tan dispersa en la red que encontrar lo que estamos buscando es a veces ms difcil que ver abrazados a Bill Gates y a Steve Jobs. Por eso, si estabas a un paso de comenzar a trabajar con micro controladores y no encontrabas la puerta de acceso, ven con nosotros, lee estos pequeos Tips, aprndelos, ponlos en prctica y deslmbranos con tu creatividad. 1 El Datasheet del micro controlador Una de las mayores razones de confusin y de complicaciones al desarrollar un proyecto es la falta de informacin del micro controlador que se desea utilizar. Las hojas de datos son los documentos ms importantes que debemos acopiar al momento de decidirnos e inclinarnos por un determinado tipo de micro controlador. 1. Por ejemplo, si en tu diseo vas a utilizar un PIC 16F877A, debes imprimir, leer y recurrir a sus hojas como si fuese El Libro de la Verdad Absoluta. Todas las respuestas estn all. Todo lo que necesitas saber est all. No te permitas iniciar un desarrollo sin haber ledo las hojas de datos del micro controlador que utilizars. Un registro mal sesteado y nada funcionar. Desde la configuracin inicial del dispositivo (fuses), pasando por los registros de los ADC (Analog to Digital Converter) o los mdulos CCP que te permiten obtener seales PWM, hasta la mismsima configuracin del reloj o clock del sistema. Todo est all.

2. Piensa en tus objetivos, suea con ellos. Qu deseas lograr con tu desarrollo? Pensar en la idea final nos suele llevar a visualizar en la mente el proyecto terminado y consolidado en un prototipo funcionando a la perfeccin. Qu componentes adicionales necesitara? Ah! Tengo esos componentes? Luego de que ya hayas dado vuelta todos los estantes y cajones buscando ese material que te faltaba, comienza a anotar los que te hagan falta, los que no tengas. No abuses de tu memoria para recordar todo lo que necesitas comprar en la tienda; coloca en ella tu desarrollo y utilzala como un micro controlador: optimiza este recurso y utilzalo slo para ampliar y perfeccionar tu proyecto. Los materiales que hacen falta no deben ocupar espacio en tu mente; haz un listado minucioso y detallado para no hacer dos viajes y listo. 3. No quieras correr antes de empezar a caminar Uno de los errores ms comunes de los que recin se inician es querer obtener ms de lo que pueden llegar a comprender. No intentes hacer como primer trabajo un cartel luminoso de LEDs para venderlo en los estadios de ftbol y volverte millonario la semana prxima. Ni siquiera pretendas construir y empuar el sable lser de Obi-Wan Kenobi y ser la envidia del colegio. No, no! Si no tienes nocin de la complejidad del proyecto que emprenders es porque no has ledo o interpretado el punto anterior. Las frustraciones provocadas por los fracasos en los primeros intentos aniquilan la confianza en nosotros mismos y arruina toda la diversin que significa construir y materializar nuestros sueos mientras vamos aprendiendo. SIEMPRE comienza con lo ms elemental y, a medida que los xitos comiencen a llegar, puedes ir agregando complejidad a los diseos. Adems, cualquier programador experimentado te dir que su primer trabajo fue escribir Hola Mundo en un display o un LED titilando como una baliza. Quien diga que no, te miente cobardemente. Comienza a caminar comprendiendo los conceptos bsicos y la terminologa tcnica y desarrolla pequeos proyectos de luces, motores o pantallas LCD. Luego, comienza a hacer un poco de jogging y trote liviano con algo ms complejo como letreros de luces y pequeos controles de los que se utilizan en industrias. La domtica y lamecatrnica son dos campos muy interesantes y amplios como para sumar buena experiencia. Si no salteas ninguno de los pasos, muy pronto estars corriendo grandes competencias a la par de los profesionales. 4. Corta la pizza en porciones, no la comas entera Por ms simple que sea un proyecto, siempre es bueno dividir en bloques o pasos la tarea a realizar. Silbar y comer man son cosas muy habituales y sencillas de hacer, pero concretarlas al unsono no es algo fcil. Organzate y preprate a trabajar por partes. Primero ESTO, luego ESTO OTRO y al final AQUELLO. Intentar hacer todo a la vez o en forma desordenada sin un patrn de accin puede ocasionarte errores al momento de construir el proyecto. Por ejemplo, si decides incorporar un Puente Para mover un motor,

contrlalo antes de conectarlo al micro controlador. Es decir, conctalo y prubalo en forma independiente para saber que el mismo funciona. As con todos los bloques en los que puedas sub-dividir tu proyecto. 5. No slo la fuerza te guiar, deja que el Sr. Spock tambin lo haga. Tus inspiraciones sern una avalancha de imgenes y pequeos trailers en tu imaginacin, pero en el teclado debers actuar de manera puramente lgica. El nmero uno, nos guste o no, est antes que l dos. Primero el cero, luego el uno, despus el dos, el tres y as en adelante. Siempre es as y nunca cambia esa realidad, a pesar de las paradojas de Ariel Palazzesi. Los programas funcionan as. Obtenemos la variable A y la transformamos en B; le sumamos C y el resultado se muestra en el paso D, y as se encadenan los procesos individuales que desembocan en el resultado final del programa. Nada es al azar, ni porque se le ocurra a Max Ferzzola. Los programas siguen un razonamiento lgico y, por lo tanto, los micro controladores tambin. Si tu mente se acostumbra a razonar de esta manera, programar ser un juego de nios para ti. 6. El pseudo-cdigo tambin es lgico. Te puede parecer arcaico, poco profesional y hasta una prdida de tiempo, pero escribir en un papel todos los pasos que seguir tu programa puede ser una ayuda muy importante mientras vas redondeando la idea final. Por ejemplo: Necesito una variable (A) que contenga un valor 20 al iniciar. Tambin otra (B) que valga 18 en el mismo momento. Despus las sumo y coloco el resultado en una tercera variable que se llamar C. Las muestro en el display. En un programa en lenguaje BASIC eso resulta ser: A = 20 B = 18 C = A+B Print at 1,1, Dec C Escribir la secuencia de acciones que queremos que nuestro programa realice nos permitir modelarlo a nuestro gusto y requerimiento, adems de optimizarlo. Cuando lo aprendes en la escuela, te lo ensean como Diagrama de Flujo y puede que con el tiempo te olvides de l, pero cuando lo aprendes por ti mismo, razonando los pasos a seguir, no lo olvidas nunca.

7. Organiza tu trabajo en partes y/o bloques Algo que puede parecer muy intrascendente, pero que es de vital importancia, es comentar cada lnea de cdigo que escribamos. Aunque creamos que es intil, si no lo haces, terminars arrancndote los cabellos una semana despus al no darte cuenta qu es lo que quisiste colocar all o por qu llegaste a ese lugar dentro del programa. Que hoy los comentarios te ocupen 10 renglones por cada lnea de cdigo significar que el prximo mes te ahorres 10 horas de trabajo intentando descubrir qu intentaste hacer all.

8. Organiza y guarda estructuras pre-armadas. A medida que vayas utilizando un micro controlador en particular (siempre seleccionamos uno preferido) y comiences a utilizarlo reiteradamente, te resultar cmodo tener a mano una estructura estandarizada de conexiones y bloques de programas. Es decir, si acostumbras a utilizar un micro controlador X, si siempre utilizas la misma frecuencia de cristal oscilador, si siempre utilizas el mismo tipo de LCD, y si adems tambin conectas siempre tus desarrollos a un ordenador a travs de un puerto RS-232, tendrs siempre un gran bloque de programa que se repite diseo tras diseo. Cuando comienzas a darte cuenta que muchos de tus diseos repiten pasos o bloques, all empiezas a armar tus templates que son plantillas pre -armadas de cosas que se reiteran habitualmente. Consrvalas y organzalas en lugares prcticos y de fcil acceso. Te servirn para ahorrar mucho tiempo al momento de iniciar el diseo de un nuevo proyecto. Aprovecha el trabajo que ya tienes hecho y que sabes que funciona. 9. No preguntar hasta agotar las posibilidades de conocimiento. En la mayora de los foros o grupos de correo que aglutinan a miles de entusiastas de los micro controladores sera muy fcil registrarse gratis, realizar consultas y, una vez que nos brindan las respuestas, seguir adelante. Adems, en esos lugares siempre hay gente bien dispuesta a brindar ayuda. Trata de no hacerlo hasta el final de tus posibilidades. Lee las hojas de datos de los materiales que te estn complicando el diseo, busca dentro de los foros, utiliza Google, lee algn libro relacionado al tema, busca hasta el cansancio en la ayuda del programa (Help) y, como ltimo recurso, pregunta a otros. Si ante el menor inconveniente acudes a otras personas para que te resuelvan los problemas, nunca aprenders lo suficiente. Adems, cuando te den la solucin a tu problema, no sabrs entender que dicha solucin slo la pudiste obtener all porque no tienes idea de lo que buscas. Todos siempre necesitamos una ayuda hasta en la tontera ms insignificante, pero la comodidad y la holgazanera de que otros te hagan el trabajo no es un buen negocio para un programador. Por ltimo, si pides ayuda, demuestra haber hecho tus intentos de solucin contando lo que has realizado y los resultados que has obtenido. Si no haces nada, y slo te limitas a pegar el enunciado que te han dado tus profesores, no esperes que alguien te ayude.

10. La frustracin es el enemigo a vencer. Trata de no abandonar los proyectos porque algo no funcion como esperabas. Descubre en esas oportunidades un reto o un desafo antes que un fracaso. Siempre es bueno mantenerse tranquilo y calmo a pesar de que nuestros circuitos echen humo por los cuatro costados. Todo error que se busca, al encontrarlo y solucionarlo, es un aprendizaje que queda grabado. Puede sonar muy extrao pero la asimilacin del conocimiento es directamente proporcional al dao provocado. Es decir, cuanto ms grave y ms caras sean las roturas, mayores sern los aprendizajes de saber qu es lo que NO se debe hacer y por qu suceden algunas cosas. No fue Dios el culpable de que algo no nos funcionara, sino que somos nosotros los que hemos metido mal algn cable. Un buen paseo, una buena caminata y al da siguiente retomar el trabajo es una de las mejores formas de vencer la frustracin. Por eso, siempre hay que revisar, revisar, revisar y volver a revisar todas las conexiones antes de conectar la energa al circuito. Nada debe dejarse librado al azar y mucho menos restarle importancia creyendo que hemos hecho bien las cosas. Todos somos humanos y podemos cometer el error ms infantil que puedas imaginar. No olvides que muchas veces una parte del xito es una sumatoria de aprendizajes brindados por los fracasos. 11. Google es el mejor amigo del hombre (programador) Si lo que buscas no est en Google, es porque no existe y eres un pionero en la materia. Toneladas de material que puede ayudarte est all en Google esperndote para poner en marcha tu proyecto. En castellano, en ingls o en arameo antiguo, lo que necesites estar en texto, imgenes y video. Nunca dejes de consultar en Googleantes de preguntar tus dudas a otros. Conclusiones A cada momento puedes descubrir un nuevo modo de estructurar un programa. Disfruta de cada LED que puedas hacer brillar y no lo tomes como algo ms; detente y tmate un tiempo para analizar tu buen trabajo. Sin caer en narcisismos banales, aprovecha cada buena rutina de programa para limpiar de tus hombros los fracasos y las tristezas de los cdigos que no te funcionaron. Siempre nos parece que los fracasos son demasiado pesados. Solo en tu fuerza interior est la manera de hacer que las alas que te brinda la concrecin de un buen trabajo inclinen la balanza y venzan el peso de las frustraciones. Olvdate de frases bochornosas como Pues es raro, Nunca haba pasado antes, Pues ayer funcionaba o el clsico y nunca bien ponderado Debe ser un virus. Si no enfrentas el problema, nunca podrs vencerlo, y si no abres tu mente y te cierras con terquedad sin intentar realizar otros caminos, nunca esperes resultados diferentes.

Si has ledo hasta aqu y eres un programador con experiencia, seguramente tendrs ms consejos para aquellos que recin comienzan. Te invitamos a que los agregues en los comentarios. Gustosamente leeremos tus aventuras y desventuras como programador. Recomendacin: No cuentes slo las ganadas.

20 Tips para ser un mejor programador

1. Estudia, estudia y estudia El estudiar nos permite perfeccionarnos, cuanto ms estudiemos ms oportunidades de programar mejor tendremos, no solamente estoy hablando de universidades, ni tampoco de cursos, hoy por hoy gracias a internet existen infinidad de tutoriales y manuales, sin ir ms lejos el sitio oficial de PHP es realmente muy bueno. 2. Busca antes de preguntar Esto es un mal comn del que quiere aprender a programar, es ms fcil preguntarle a alguien que sepa, pero realmente no tiene que ser as por varias razones, primero porque es algo de muy de vago, luego que cuando alguien nos da la respuesta fcil no aprendemos nada, lo interesante cuando se nos presenta un problema es buscar la solucin nosotros mismos, sino damos con la respuesta recin ah preguntar, este ejercicio realmente es muy beneficio, nos permite preparar nuestra cabeza para solucionar futuros problemas. 3. Busca scripts ya desarrollados Por lo general podemos encontrar muchas funciones, scripts listos para utilizar, pero lo interesante es estudiarlos, ver cmo funcionan, de ah aprendemos si copiamos y pegamos vamos mal. 4. Lee el cdigo fuente libre Yo muchas veces descargo algunas aplicaciones para ver cmo estn programadas, de verdad que se aprende mucho, a medida que realicemos esta prctica cada vez iremos aprendiendo ms, en especial si estas aplicaciones son de uso popular en donde miles de programadores del mundo meten mano para mejorarla. Un buen ejemplo de esto es WordPress. 5. No copies y pegues Es fcil, entramos a google buscamos una funcin que sirva para lo estamos necesitando y listo. Pero la realidad es que no siempre lo que descargamos es correcto, y si luego tenemos que solucionar un problema lo ms probable es que no tengamos ni idea por dnde empezar. Ni hablar del factor aprendizaje cero que esta prctica implica.

6. Buscar el momento para programar Estas sentado delante de tu ordenador, llaman por telfono, tu compaero de trabajo o familiar te pregunta algo, realmente es lo ms molesto e incmodo que hay, es difcil concentrarse, es preferible hacer algo ms Light antes de programar algo mal y despus tener que arreglarlo. 7. Ten tu propia Wiki Esto lo recomiendo muchsimo, es muy sencillo instalar una Wiki en nuestra pc, simplemente podemos descargar el Easyphp y tener en nuestro ordenar un servidor funcional, y mejor an si quieres hacer la instalacin a mano. La wiki es interesante para poder almacenar rutinas que usamos frecuentemente, en mi caso suelo guardar validaciones, etc. Una vez que aprendimos a hacer algo y lo tenemos lo mejor posible es interesante tenerlo a mano para no perder tiempo escribiendo lo mismo una y otra vez. 8. Comenta todo lo que sea necesario Escribir comentarios en el cdigo suele ser bastante molesto y parecer innecesario, pero comentar las cosas importantes nos puede ahorrar mucho tiempo cuando tengamos que retocar el cdigo meses despus. 9. Participa en foros/comunidades Es interesante para interactuar con otras personas que estn en nuestra misma sintona, muchas veces ayudaremos nosotros y otra vez nos podrn ayudar. En lnea general estas comunidades tienen muy buena onda, y la ayuda mutua es lo que abunda, unas lneas de cdigo pueden ser tiles para muchas personas, de ah que entre todos se puede perfeccionar. Recuerden respetar el punto 2. 10. Habla con otros programadores Mensajera instantnea, en un caf, por telfono, etc. Es interesante tener amigos que estn en lo mismo, no solamente por el tema de la ayuda mutua, estos grupos suelen ser tambin de ayuda emocional del programador, unos chistes, algn comentario puede ser una inyeccin de energa para continuar con un problema que no podemos resolver. 11. Tiempo libre para otras cosas Me encanta programar, pero entend que no es lo nico en la vida, a veces es bueno una salida, una pelcula, realmente es necesario desenchufarnos. 12. Arma tu bunker Tener un espacio de trabajo acorde con tus gustos es indispensable para programar, un buen silln que no dae nuestra columna, un lindo escritorio que nos permita desparramar CDS, libros, etc. Tambin hay que ser organizado, pero siempre a nuestro gusto, es bueno que sea TU espacio y que nadie meta mano, uno a la larga lo termina sintiendo como un refugio.

13. Tu equipo en condiciones Otro punto importante, una buena computadora, que no tenga problemas, si es necesario un poco ms de RAM, no hace falta tener una supe mquina para programar con PHP pero si algo que no se est colgando cada 2 seg. 14. Usa herramientas gratuitas Si no podes pagar ciertas herramientas realmente ni te gastes en bajar las versiones piratas, en PHP no se necesita mucho y realmente no vale la pena estar trucando programas. 15. Organiza tu propia biblioteca de scripts Relacionado con el punto 7. La wiki es muy buena, pero hay que tenerla organizada, sino encontrar algo puede llevarnos ms tiempo que volverlo a escribir. Yo soy bastante desorganizado, pero con los aos aprend a manejar mi problemita 16. Se agradecido con los que te ayudan Si alguien te ayuda, por favor al menos di gracias. Recuerda que las personas que te rodean no son tu soporte tcnico (Al menos que les pagues). Si alguien se molesta en responder a tus consultas agradcele, para la prxima esa persona seguir teniendo buena predisposicin. 17. Se humilde Esencial. Siempre hay alguien que sabe ms que uno y ms en este rubro en donde hay verdaderos crneos, Yo hace varios aos que programo en PHP y sin embargo siempre aprendo algo nuevo, y en parte eso es lo que me gusta de programar, siempre se puede mejorar. 18. Siempre busca perfeccionarte Relacionado con el punto anterior. Las tecnologas evolucionan y nosotros debemos hacer lo mismo. Una linda practica cuando tenemos un poco de tiempo libre es tratar de optimizar un cdigo nuestro de unos meses anteriores, si aprendimos cosas nuevas de seguro que podemos hacerlo mejor que antes.

19. Intenta ser eficiente y luego intntalo de nuevo Que funcione no quiere decir que este bien. Tambin una de las cosas ms lindas de programar: Siempre se puede hacer una funcin ms eficiente, que consuma menos recursos, no hay que conformarse que arroje los resultados que queremos, probablemente lo podemos hacer mejor.

20. Programa primero lo que menos te gusta Esto es bastante personal, pero por lo general me da buenos resultados. Cuando me siento a programar algo los primeros minutos son de ambientacin l uego tengo un periodo de concentracin digamos mxima, en ese momento las cosas que parecen o son ms complicadas son cuando ms rpido y mejor salen, luego cuando uno est ms cansado puede dedicarse a las cosas ms sencillas y rutinarias. Los 10 Mandamientos del Programador Java Comenta el cdigo. Cuando estamos escribiendo cdigo nuevo, es fcil entender lo que se est haciendo, pero si no tocamos ese cdigo por un periodo de tiempo y tenemos que volver al mismo, ya no es tan obvio. Comentar el cdigo te ayudar a entender ms rpidamente la lgica del programa. No compliques las cosas. Muchas veces queremos solucionar algn problema de la forma ms enredada porque se ve bien. Busca la forma ms simple de resolver las cosas. Esto te ayudar a entender el cdigo mejor y a mantenerlo de una manera ms eficiente y es menos propenso a errores. Menos es ms, no es siempre bueno. Muchos lenguajes de programacin te permiten concatenar funciones y muchas veces queremos hacer varias cosas a la vez en una lnea. Esto dificulta la lectura y la lgica del cdigo. Evita el har coding. Usa las constantes, de este modo si necesitamos cambiar este valor, slo tenemos que hacerlo en la constante y no en el resto del cdigo. Si es valor es algo que va a ir cambiando a lo largo de la vida del programa, sera mejor usar ficheros externos de configuracin (XML, propiedades, base de datos, etc), de esta forma no tenemos que modificar el cdigo, recompilar y redistribuir la nueva versin. No reinventes. Aprovchate de los marcos de trabajo (frameworks) existentes y de los patrones de diseo. Estn ampliamente probados. Cuidado con los prints y la concatenacin de Strings. Normalmente tendemos a escribir prints por todo el programa, con la intencin de depurar nuestra aplicacin. Esto puede afectar seriamente al rendimiento de la aplicacin. Usa algn tipo de mecanismo para que esos prints solo se ejecuten cuando estemos en la fase de desarrollo. La concatenacin de String puede ser otra de las operaciones que afectan al rendimiento del programa. Si vas a hacer muchas operaciones de concatenacin, en Java la clase String es inmutable, por lo tanto cada vez que haces una concatenacin ests des-referenciando los Strings que estas concatenando y creando un nuevo String. En Java tienes disponibles 2 clases que aumentan drsticamente el rendimiento para este tipo de operaciones. StringBuffer y StringBuilder. StringBuilder es incluso ms rpido que StringBuffer, ya que este no es

thread-safe. Por lo tanto si el cdigo de desde el que ests haciendo las concatenaciones no es multihilo usa StringBuilder, si no, usa StringBuffer. Pon atencin al interfaz de usuario. El aspecto del interfaz de usuario, la forma de navegar por el mismo y la comodidad a la hora de usar el mismo, van a depender mucho de la aceptacin y el xito de tu aplicacin. Sigue el mismo estilo en toda la aplicacin, escoge cuidadosamente el ttulo de las ventanas, etiquetas de texto, etc. Sigue el mismo diseo que otros sistemas ampliamente aceptados. Pon tu interfaz a pruebas con tu mujer, marido, novi@, amig@, etc. Para ver como se mueve por la aplicacin, etc. Documentacin. Es lo que personalmente odio ms. Escribir documentacin es muy pesado y en el momento en el que estamos trabajando en un proyecto todo tiene sentido y fcil de seguir. Pero de nuevo, cuando tenemos que volver al proyecto despus de un tiempo ya no nos parecer tan obvio como pensbamos. Adems si el proyecto no era lo suficiente grande como para requerir a ms de una persona para trabajar en el mismo, recuerda que el proyecto puede crecer y requerir a uno o ms programadores incorporarse al proyecto. O simplemente el proyecto pasa a manos de otra persona. Es una de las tareas ms pesadas, pero de las que ms que se agradecen a lo largo del tiempo. Unidades de testeo. Es una muy buena y recomendada prctica que debemos hacer incluso antes de escribir nuestros paquetes, libreras, etc. Y son las unidades de testeo. Esto nos va a ayudar de una forma muy rpida si nuestras funciones funcionan como deben. Nos va ahorrar mucho tiempo en el futuro (cada vez que tengamos que modificar nuestras funciones) y es otra de las tcticas que nos ayudar a reducir el nmero de errores en nuestro programa. Calidad, no cantidad. Es mejor entregar un programa con las funciones bsicas bien desarrolladas, a entregar un programa lleno de funciones y que cada dos por tres el mismo se cuelgue o no haga lo que se supone que tiene que hacer. Los 10 mandamientos de los programadores Esto me lo pasaron ahora en la procu, lo que necesitamos son algunas reglas o guas para ayudar a los programadores a separar su propio cdigo de programacin de ellos mismos. 1. Entender y aceptar que nos podemos equivocar. El punto es encontrar los errores rpidamente antes de que el usuario los encuentre. Afortunadamente, los errores rara vez son fatales, as es que podemos aprender de ellos, rernos y seguir adelante. 2. No eres tu cdigo. Recuerda que lo principal de una revisin o auditoria es encontrar problemas o errores y que estos siempre los encontraras. No lo tomes personal cuando te descubras uno de ellos.

3. No importa que tanto de programacin sepas, siempre existe alguien que sabe ms. Como individuo aprendes mucho ms si preguntas. Busca y acepta informacin de otras personas, especialmente cuando pienses que no lo necesitas. 4. Nunca rescribas o copies cdigo sin consultar. Existe una lnea muy delgada entre arreglar el cdigo y reescribir cdigo. Hay que conocer la diferencia y seguir programando con el estndar designado. 5. trata a las personas que saben menos que t con respeto, deferencia y paciencia. Las personas que no conocen de computacin y que tratan a menudo con programadores por lo regular opinan que somos en el mejor de los casos unos genios y en el peor unos nios llorones. No reforcemos este estereotipo con coraje e impaciencia. 6. La nica constancia en el mundo es el cambio. Hay que se abiertos y aceptarlo con una sonrisa. Hecha una mirada a cada uno de los cambios que se requieran, plataforma o herramienta como un nuevo reto, no como un serio inconveniente al que hay que enfrentarse. 7. La nica verdadera autoridad viene del conocimiento, no de la posicin. El conocimiento engendra autoridad y la autoridad engendra respeto. As es que si quieres respeto estudia y preprate ms. 8. Pelea por lo que t crees, pero acepta cuando estes equivocado. Hay que entender que a veces tus ideas no sern las apropiadas. Aun si te das cuenta despus que tus ideas son las correctas no tomes venganza o digas Te lo dije. 9. No seas el tipo ermitao. No seas el tipo que est en una oficina oscura que solo sale a comprar un refresco. El tipo de la oficina oscura es alguien fuera de contacto humano. 10. Critica el cdigo y no al programador. Se cortes con el programador, no as con el cdigo. Tanto como te sea posible, haz que tus comentarios sean positivos y bien orientados a mejorar el cdigo. Y ya que estamos en la onda de programacin, pongo una frase que de Steve McConnell: Los desarrolladores de software estn atrapados entre dos fuegos. Uno de ellos consiste en que los desarrolladores trabajan muy duro y no tiene tiempo para aprender mtodos de trabajo eficaces que pueden resolver la mayora de problemas relacionados con el tiempo de desarrollo; el otro fuego consiste en que no van a tener tiempo hasta que aprendan ms sobre desarrollo rpido.