Barrapunto

A partir de aquí dejé de leer. Semejante gilipollez no merece mi tiempo.

tener que poner en tu web los puntos en los que no puedes convencer a tus compañeros de despacho...

-- Te opones férreamente a las funciones/métodos de más de 20 líneas de código --

Siempre he creído que una función debe ser reducida al mínimo, la eficiencia se basa en la sencillez de la solución, si eso fuera malo echaríamos a la basura el trabajo que tiene a la informática donde esta como es el caso de Edsger Dijkstra. [wikipedia.org]

-- Los ciclos de CPU son un recurso precioso y tu estilo de programación y lenguaje reflejan esas creencias. --

Por creencias como esas es que existen programas rápidos que marcan la diferencia entre los buenos programadores y los malos, o ¿que son 2 milisegundos en dos millones de ciclos? -Véase KHTML vs Gecko, Apache vs Lighttpd, Win-Vista vs Linux -

-- Tus usuarios son estúpidos. Realmente estúpidos. --

Ningún usuario es estúpido, tan solo nunca sabe lo que quiere y como lo quiere, y cree que programar es cosa de pintar un botón en una caja.

La verdad estoy en desacuerdo con las afirmaciones presentadas (quizás de acuerdo a eso yo mismo sea mal programador) pienso en lo personal que hay una clave que diferencia un programador malo del bueno y esa es la falta de RECURSIVIDAD.

¿Las doce normas de un buen programador?

Mi corta experiencia en el sector del desarrollo de software, debería limitar mis comentarios en torno a la programación propiamente dicha. Pero teniendo en cuenta que llevo trabajando alrededor de unos 12 años en otros sectores, como el de la construcción, etc..., me gustaría lanzar una dudas para que seamos autocriticos.

El desarrollo de software en cierto modo, la creación una serie de procedimientos para "agilizar, gestionar o automatizar tareas repetitivas", por lo que se necesita que sean rápidas y seguras, aparte de fáciles de utilizar.

Por lo que yo me pregunto. ¿Qué mas da que el programador desarrolle un súper código, utilizando los menos ciclos posibles, de código desacoplado, generando una interface amplia y funcional, si el cliente o usuario final del producto (sea para vender o para ceder) no puede realizar las tareas que necesita de una forma fácil, segura y rápida?

Realmente que es programar, escribir líneas de código pomposas, para crear el "código puro"; ordenado, moderno, escalable, magnifico, una obra de arte. Si luego el usuario no lo entiende y no sirve de nada. O programar es sacar un programa funcional. Que utilice la gente.

Para mi lo importante este en la calle un producto agradable y que se utilice.

Yo no pinto la mona lisa, le saco una foto.

que el autor de las "señales" no debe ser ninguna fiera programando.

Vamos creo que esto no sigue lógica alguna. Empieza criticando el tamaño del código, pero luego dice que las funciones deben ser grandes, Que el UML no sirve para nada. Se mete con mi querido java. Dice que los patrones de código son solo para los fashion !! Que desfachatez dios mío.

  Que están criticando a los programadores junior o que ? Entre otra cosas la principales cosas que no se hacen bien, son el tiempo dedicado a la aplicación y la documentación. Si el proyecto es grande o mínimamente un software estándar donde va trabajar un numero de mínimo 3 programadores, el código debe ser legible , y estar documentado para que el compañero sepa donde esta cada cosa, donde puede modificar exactamente alguna parte o ver donde esta el error. Y cuando modifiquen algo que trate de modificar lo que se requiere y punto.

  Si por ejemplo se quiere programar en algún lenguaje, a no ser que seas un programador freelance, deberás estar de acuerdo con el resto de tu "equipo" sobre que lenguaje se adapta mejor, no imponer tu visión exclusiva sobre cual es el mejor lenguaje del momento.

  La principal virtud para tener éxito es: ser organizado, conciso, y entender muy bien lo que se te pide o lo que quieres hacer, eso si se te da mejor con diagramas, o con una hoja de calculo repasando cada posible paso que deba dar tu programa mejor que mejor. El tema de todo esto es que tu controles al programa no que el programa te controle a ti ;P

  Respecto a lo súper arquitectos del software estoy de acuerdo, no tienen ni idea de lo que és programar, en teoría las empresas los contratan para supervisar, coordinar, proyectos algo que se aleja de la técnica de la programación, pero que sirve para que la gente técnica se espabile, es decir para organizar y marcar unos tiempos sobre la duración del proyecto y comunicarse con el cliente o los diferentes departamentos para que todo el mundo se entienda. Es decir si el programador en ese momento le dice al arquitecto oye que esto del Java esta tirado "te lo hago en un par de días" después no te quejes, tuviste tu oportunidad para definir correctamente los posibles inconvenientes para saber cuanto te va a costar, en tiempo tu programa...

  Para acabar todo este rollo, solo decir que aparte de los buenos o malos hábitos, yo creo que los programadores, los hay inexpertos y expertos, que normalmente han librado más batallas y saben que lo importante es el día D y que funcione y dejate de virguerías, y los inexpertos debemos seguir aprendiendo que si un programa nos sale mal no se acaba el mundo, hay que aprender de los errores ;)..

   

Para que lo sepais.

Estoy de acuerdo al 97% con la noticia. (bien leída)

Practicamente es la conclusion a la que he llegado con el paso de los años en la mayoría de los temas que critica.

Aunque añadiría otro: ¿No comentas tu código? Esencial.

Tu programa resuelve el problema que pretendes resolver?

SI: Sabes programar
NO: Dedicate a otra cosa

Sí, yo creo que se puede resumir en un punto: ¿Tú programa cumple su misión? Ahí tienes tu respuesta.

al que le mole java, que mire esto: http://harmful.cat-v.org/software/java [cat-v.org]
y sobre el resto, yo le veo bastante sentido a la mayoría de las cosas que dice, aunque no me parece de demasiada relevancia. ya tenemos, por ejemplo, "the practice of programming" de kernighan (sí, ese kernighan que tú estás pensando) y pike (pike tambien tiene unas notas, por si no teneis acceso al libro: http://www.lysator.liu.se/c/pikestyle.html [lysator.liu.se] ) o las notas de russ cox ( http://swtch.com/~rsc/worknotes/ [swtch.com] ). son sobre C, pero algunas normas son generalizables a otros idiomas.

Como ya se ha dicho por ahí el artículo es un verdadero desajuste y sinceramente más me parece una llorona del que lo escribe para justificar las cosas que el no hace que otra cosa.

Las buenas prácticas de programación son para utilizarlas, el UML no es malo, los patrones de diseño no son malos, java no es malo... etc, el uso excesivo de esas cosas no son malas.

El problema del artículo es que mezcla unas cosas con otras que no tienen relación ninguna. El código cuanto más rápido mejor, ahora bien, en cada situación se dan unas condiciones y a veces hay que elegir, código más rápido o más legible, más rápido o hecho antes, más legible o que esté para ya. Cada situación es distinta y además, ese tipo de decisiones dejan de ser de software, son de "managment", es decir, del tipo que tiene la responsabilidad del proyecto y debe "dirigir" el rumbo del mismo.

Hablá en otro lado de "usuarios tontos". Estamos desviandonos de la conversación. ¿No hablabamos de programación? ¿Por qué metes usabilidad en el contexto? Los programadores no somos (como norma general) buenos diseñadores de interfaces y menos de interfaces usables. Lo ideal es que nos guíen, a ser posible que nos lo den hecho. El programador aporta límites sobre lo que se puede hacer, dilucida la mejor forma de hacerlo y escribe el programa... pero es el comercial quien captura las necesidades del cliente, es el ingeniero de sistemas (dependiendo de la empresa) el que captura unos requisitos ... el programador /analista/arquitecto solo diseña el programa para hacer lo que le piden y, si se puede, el experto en usabilidad diseña el layout y el workflow del programa, el diseñador estructura el interfaz visual (iconos, aspecto), etc. Otra cosa es que aveces una sola persona sea, o intente ocupar, todos esos puestos...

Yo soy analista programador, me gusta diseñar la arquitectura, me gusta escribir el código y seguir unas prácticas de programación (y si, hay lenguajes que me gustan más que otros) pero no me metas cuestiones que no tengan que ver conmigo.

http://eltimoperfecto.blogspot.com/2007/11/regla-n mero-1-para-ser-buen-programador.html [blogspot.com]

Si no la sigues, eres mal programador.

La verdad (para algunos triste, para otros no)es que el software es una herramienta, y no importa cómo esté hecha si cumple su función.

La optimización, perfección, uso de clases, uso de UML, patrones o lo que quieras es irrelevante (y dicho así, hasta a mí me parece una barbaridad, la verdad)

PERO:

(1) Si un proyecto es pequeño, y hace lo que tiene que hacer, y los que lo usan lo pueden usar bien, no importa una mierda que esté programado con el culo. Ser buen programador es terminarlo cuanto antes y olvidarse de ello.

(2) Si un proyecto es más grande, y varias personas tienen que trabajar en él, el SER BUEN PROGRAMADOR consiste en usar métodos de trabajo en equipo y un código que acelere el desarrollo, la corrección y la evolución. Puede ser con clases, con UML con modelos MVC o como sea.

(3) Ser un MAL PROGRAMADOR es creer es confundir la ciencia de crear algoritmos con el trabajo de desarrollar software.

Y ES MÁS:

Si "ser buen programador" es "hacer buenos programas", entonces la cosa es aún más complicada, porque un "buen programa" no es lo que NOSOTROS digamos que es, es lo que los USUARIOS del programa digan, y lo que una empresa puede permitirse hacer.

ALGUNA LEYES DEL MUNDO REAL (que la saben todas las empresas):

(a) Un gramo de diseño, vale más que diez kilos de programación.

(b) Un gramo de publicidad, vale más que diez toneladas de optimización.

(c) Un gramo de terminar pronto y hacer que funcione, vale más que todo lo demás ... porque si no se agota el presupuesto y el programa nunca funcionará (muy optimizado y muy UML ... pero se irá a la mierda por falta de dinero).

CONCLUSIONES CURIOSAS:
Es muy probable que un "doctor" de la computación (de los que están en las universidades) con sus toneladas de conocimientos teóricos, sean, empresarialmente, MALISIMOS programadores.

Por lo menos por saber programar, se puede definir como el hecho de tener la logica de programacion. Tener la capacidad de hacer un algoritmo. Tener la capacidad de resolver un problema. Como sea. Optima o no optima la solucion.

Es otra cosa BIEN DISTINTA el conocer muchos algoritmos distintos, para ordenar o para buscar, por ejemplo. Se pueden conocer todos los algoritmos y sus caracteristicas sin haber escrito una linea de codigo.

Quien es mejor programador? El teorico que conoce todos los algoritmos que nunca ha escrito una linea de codigo? O acaso el chaval que quizas no conoce el quicksort o la busqueda binaria, pero que su programa funciona con una ordenacion de burbuja? Quien resuelve el problema? Quien sabe programar?

No perdamos de vista esa distincion. Se puede saber programar SIN CONOCER los algoritmos mas clasicos.

Si, lo son.
Pero tienes que tener el suficiente sentido de autocrítica para darte cuenta de que si tienes 300 usuarios y los 300 se equivocan lo más probable es que tu interfaz de usuario esté mal hecha.
Que es a lo que se refiere el artículo.

Precisamente el error del programador suele estar en ignorar ese hecho.
Si los usuarios son estúpidos, habrá que programar para estúpidos. ...de todas formas, "ignorantes" es más preciso que estúpidos, aunque quede menos cool.

Porque la diferenciación entre función, método, subrutina, procedimiento, etc... suele ir a gusto del programador de turno. A veces el programador de turno es quien programó el lenguaje y se dedicó a poner esa diferenciación como feature, y a veces el programador de turno es el colega que está usando un lenguaje que no hace distinción entre esos términos mientras él se empeña en distinguirlos (por costumbre probablemente). Vamos, que son sinónimos intercambiables en la mayoría de las ocasiones y es una mera cuestión de obcecación empeñarse en lo contrario.

Lo mismo es que no lo has leído bien o no lo has comprendido.

Y asumir que por el simple hecho de haber estudiado teleco o FP una persona es peor programador que tú es mucho asumir, hamijo.

Pero «a la larga» acabará significádolo ;)

Exacto, creo que ningún método debe de tener un 'return'

¿Mande?

Te "pego" una frase que me encanta y que uso como firma a veces:

Computing is a race between the universe and engineers. Engineers trying to develop better idiot proof software, and the universe trying to make better idiots.

Los usuarios son por definición ignorantes en programación. Los programadores son por definición ignorantes del resto del negocio.
Por eso a menudo la mala opinión es mutua. Lo que demuestra precisamente la ignorancia de ambas partes.

El caso es, que en el código bien escrito los comentarios (la mayor parte de ellos) son superfluos.
Para mi los comentarios en el código son como las notas al pie en un texto, cuando en realidad el sentido de lo que estás leyendo depende de esas notas y tienes 5 notas al pie por página es el texto lo que necesita ser revisado, añadir más notas sólo lo hará más infernal.
Citando a Rob Pike:

¿Entonces si tu comentario fuera un método sería así?
6. Piensas que ninguna función/método debería tener más de un return. Exacto, creo que ningún método debe de tener un 'return' (y ni te digo ya si tiene más). Serán manias mias :P