r = n / 2; // Asigno a r la mitad de n
//Bucle mientras r-(n/r) sea mayor que t
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) ); // Asigno a r la mitad de (r + (n/r))
}
¡Hostias!: mejor poner algo como "cálculo de la raíz cuadrada según la aproximación de Newton-Raphson" valdría, ¿o no?
2.- Interrupciones.
Llamadas de teléfono, reuniones imprevistas, consultas realmente estúpidas e innecesarias de usuarios....Todo esto influye al final de una manera u otra en la calidad de nuestro software, y creedme: ¡no para bien!. Hay que procurar abstraerse todo lo posible: estamos desarrollando algo importante, que debemos estar seguros de comprender, mantener y testear. ¡Poneros si hace falta vuestro iPod y a desarrollar!.3.- No enfocar inicialmente el desarrollo a lo que se pide realmente.
Inventar cosas superfluas, "esto" nos lo pedirán seguro, crearé unas tablas de más por si acaso...¿para qué?. Céntrate siempre en analizar y desarrollar exactamente lo que te piden, ni más, ni menos.
4.- Gestores que no entienden de programación.
Sí, posiblemente tu jefe directo no entienda, ni quiera entender, nada de desarrollo software. Pero ¿para qué? ¿te serviría realmente para algo? A veces (lo digo por mis 15 años de experiencia) es mejor que sea así. Habla francamente con tu responsable y si es necesario se dice: "esto no se puede hacer", o actualmente "es demasiado complejo enfocarlo de esta manera y necesitamos más tiempo"....Unas respuestas más brillantes que: sí, sí, no hay problema, esto lo programamos en 2 días estará y tener el código que con más parches que un ejército de piratas....
5.- Documentar nuestas aplicaciones.
¿Alguna excusa para no hacerlo?. Así que ya sabes.....te guste o no, uses herramientas automáticas o manuales, me da igual: documenta tus cambios, tu software no es sólo lo que ahora corre, es un histórico de revisiones, es un manual de usuario, son observaciones importantes para futuros colegas que intenten comprender tu código....Aquí reside una de las grandes diferencias entre buenos y malos desarrolladores, y en el mundo opensource se ve muy claro....Si no documentas lo tuyo para que otros lo entiendan, ¿para qué lo haces?.
6.- Uso de aplicaciones de terceros no documentadas.
¿Has leído el punto anterior?. Seguramente ahora te estarás acordando de algunos de los que aparecen en los créditos de este maravilloso software que usa tu empresa. ¡Exige documentación técnica y operativa!. Y si puede ser antes de comprar ese software "tan bueno", mejor....Te evitaré sorpresas futuras.
7.- Hardware.
Todos nos hemos vuelto locos a veces por no comprender bien algún bug o pérdida de rendimiento en alguna base de datos, en algún servidor....¿por qué?. Era simplemente conocer de antemano las características y limitaciones de la máquina en la que corren nuestros S.O. y aplicaciones. Debemos esforzarnos más en conocer las características físicas/virtuales donde se ejecutan. No queda otra, aunque nos hablen de Cloud-Computing y la madre que parió a la nube....yo personalmente prefiero la opción de comprender, comprender y comprender bien claro donde está cada cosa y si hace falta crea logs hasta para ver por dónde pasa cada elemento importante en tu sistema. ¡Hazlo ya!.
8.- Vaguedad de los usuarios finales.
¿Tan difícil es que un usuario de nuestras aplicaciones se moleste en dar "alguna" información del problema que haya detectado? Es universal la consulta al informático tipo: "esto no funciona", "arréglalo ya que tengo que sacar el informe"...¿pero qué diablos no funciona? ¿en qué nos ha ayudado el usuario?. ¡Necesitamos exigirles toda la información que puedan darnos, pantallazos incluidos si hace falta!. Si no implicamos al usuario final en el sistema creedme que nunca se podrá alcanzar un nivel de excelencia en dicho sistema. Todos somos partes inherentes a él y todos estamos de algún modo interrelacionados.
9.- Otros programadores.
Los programadores no siempre nos llevamos bien con otros programadores. Lógico, como cualquier humano ¿no?. Pero estos son algunos síntomas peligrosos que hay que observar y en su caso llamar al orden a ese otro programador:
* Estar de mal humor hasta el punto de ser hostil
* No entender que hay un tiempo para debatir la arquitectura del sistema y un tiempo para hacer las cosas
* Incapacidad para comunicarse de manera efectiva y confusa según una terminología estándard
* Dejadez y apatía a la hora de desarrollar y documentar
* Culpar a otros de errores propios
10.- Tu propio código fuente, 6 meses después de ponerlo en producción.
No sé si habéis tenido curiosidad o necesidad de hacerlo, pero probad esta técnica. Revisad vuestro código unos meses después de que esté operativo: ¡cuántas sorpresas os vais a llevar!. No existe el código perfecto pero parece que aquel día mucho no nos acercamos a él, no, creo que más bien....todo lo contrario jejejeje.
¡Ánimo y seguro que si seguís estos sencillos y cercanos consejos vuestro código cada vez pintará mejor, será más reusable, vuestros usuarios estarán más contentos y vosotros también!. Nos vemos.
No hay comentarios :
Publicar un comentario