Hace 10 años | Por facso a 97cosas.com
Publicado hace 10 años por facso a 97cosas.com

Traducción online al Español del libro ”97 Things Every Programmer Should Know”, contiene todo tipo de consejos y recomendaciones para los profesionales de la programación informática: refactorización, código limpio, pruebas, aprendizaje contínuo, etc. Compilación realizada por espartaesparta

Comentarios

zhensydow

2) Como empezar flames

esparta

#4 Alguna mejor idea de cómo podría/debería quedar? porque igual era dejar el Build como tal (cosa que se cambia en 3 minutos)

chemari

#5 En ese caso the build se refiere a la compilación.

esparta

#8 hmmm igual estoy cambiándolo (ahí), pero según recuerdo hay más lugares donde se refiere no sólo a la compilación, sino al proceso completo, compilación, linkeo, etc...

forms

#4 te doy mis dies

A

#4 La verdad es que me parecía interesante pero había dejado de leerlo debido a la pésima traducción. Gracias por enviar la versión original.

zhensydow

1) Haskell

m

#1 ¿Estudiante de la UPM plan 96?

zhensydow

#34 Tu, lógica, ¿la aprobastes?
a -> b no significa b -> a

m

#58 Por eso era una pregunta y no una afirmación... No implementes nada sin leerte dos veces las especificaciones porfa

sid

#1 Tienes razon, des de que use Haskell todos los demas lenguajes me parecen faciles,sencillos y nada rebuscados.

takamura

#1 Con eso eliminas, por ejemplo, el punto 2.

D

#12 el mítico Donald Knuth ya lo decía:

"Premature optimization is the root of all evil."

angelitoMagno

Esto es para guardarlo en favoritos y leer un artículo cada día.

jamma

load ""

u_1cualquiera

No llevo demasiado tiempo en meneame pero empiezo a detectar el patrón
N cosas que deberías saber sobre X

portada seguro

ccguy

#16 Los tres últimos podrían ser anexos sobre sueldos, cárnicas, programación en España...

a

#16 Teniendo en cuenta que se trata de una serie de tres libros actualmente y que todos se llaman 97 cosas... pues no se si tiene mucha "credibilidad" como dices.

97 Things Every Programmer Should Know, 97 Things Every Software Project Manager Should Know y 97 Things Every Software Architect Should Know.

Qué casualidad que todos sean 97.

Wayfarer

#33 Son 100 menos el 3% de comisión del editor...

u_1cualquiera

#25 #41
cout

D

#15 printf("%s cosas que deberías saber sobre %s", "gatos", "gatos");

LLort_II

#25 ¿gatoss? noob

hellodolly

10 consejos para programadores que empiezan

D

No me parecen buenas ideas para nada, una por ejemplo recomienda hacer finales todas tus clases (si estas diseñando una API) para que los usuarios no puedan heredar de ella y ahorrarte problemas en el futuro

D

Andy Hunt y Dave Thomas nos animan a aprender un nuevo lenguaje de programación cada año lol lol

D
Don_Gato

que siempre hay una cosa 98

D

una de las más importantes
TDD

D

#7 Eso lo usaba yo para matar mosquitos

D

#18 yo lo uso para matar bugs

MEV

#7 Pues no entiendo por qué te meten negativos. Desde que hago TDD he mejorado muchísimo como programador, me parece una forma estupenda de afrontar los problemas a resolver.

D

#70 Porque los negativos son para insultos, racismo, spam... lol

D

#48

En donde trabajabas ? Sal de Espana y te daras cuenta de que la realidad es muy diferente a lo que dices.
En cuanto a lo de PHP en un banco, por que razon crees que seria menos fiable que otro lenguaje ?

Pablosky

#60 #48 Por que el PHP (aún hoy) tiene muchos prejuicios en contra.

Vale que si lo usas mal es un infierno, vale, pero si lo usas bien... http://symfony.com/es/what-is-symfony

KimDeal

#48 #60 #62 "una aplicación para un banco o algo así serio no creo que sea buena idea hacerlo con PHP". Esto es un prejuicio sin justificación real. Los prejuicios hacia el PHP vienen, creo, principalmente de que es muy utilizado en web y en software y herramientas libres. En ciertos entornos (bancos, organismos públicos, aseguradoras...) la unión de los conceptos de web+libre es igual a perroflautas, hipis, rojos antisistema peligrosos.

También de que por intereses diversos se ha divulgado la falsa idea de que los desarrollos en PHP son menos seguros y no son orientados a objetos. Ni lo primero ni lo segundo es cierto (y aunque lo fuera, el Cobol tampoco es O.O. y se sigue utilizando masivamente).

davamix

Mucho consejo para los programadores pero el que escribió la lista debería de saber que los programadores somos vagos por naturaleza y no nos vamos a leer una lista de 97 cosas, y menos si están sin categorizar, ahí puestas a pelo.

A

#67 ¿Incrementan el coste? Yo creo que no, si después de seis meses con una metodología ágil tienes mil cosas implementadas y con el método tradicional tienes algo que no te sirve para nada, el coste ha sido altísimo en el segundo caso, ¿no?

A la empresa de desarrollo le interesa la metodología ágil, pero al cliente también le interesa porque obtiene algo útil a cambio... desde el principio. Si ve que el proyecto cuesta demasiado para lo que va obteniendo a las dos, tres semanas, se podría cancelar. Sin metodología ágil ¿a qué se llega si la empresa desarrolladora no cumple, al juzgado después de seis meses?

Hay múltiples pruebas de que el método tradicional supone sobrecostes increíbles: busca la sentencia de BSkyB contra EDS por ejemplo, o cómo la industria militar estadounidense pagó miles de millones de más en proyectos de software fracasados y ahora se ha pasado a metodologías ágiles.

KimDeal

#73 si, si, yo soy superfán de las metodologías ágiles, después de haberme pasado toda una vida con sistemas clásicos, cuando me empezaron a hablar de Lean, Scrum, Kanban, vi la luz y comprendí que era la manera correcta de trabajar para clientes que no tienen las cosas del todo claras.
Pero hasta la fecha no he conseguido convencer al cliente de que no le puedo cerrar el presupuesto, sinó darle cifras aproximadas, y eso no lo quieren, lo cual nos lleva de nuevo a las metodologías clásicas.

grouchoboy

#45 ¿De dónde sacas que twitter esta programado en php/ruby/python? Que yo sepa, twitter usa mayormente scala, que compila a bytecode para la maquina de java, luego javascript para la parte cliente y no se si tendrán todavía algo en ruby, imagino que algo quedará.
¿Y facebook? En facebook programan en php pero luego lo pasan a c o c++ con hiphop.

Java en si no es inseguro, son inseguros los applets java en navegador. Pero por lo demás es como cualquier otro lenguaje. Sinceramente si trabajas en seguridad informatica deberias tener eso claro y no ir diciendo que java es inseguro. Una parte pequeña del ecosistema java es inseguro el resto no.

Pablosky

#65 "En facebook programan en php pero luego lo pasan a c o c++ con hiphop." En realidad no, la nueva versión de Hip Hop funciona como la máquina virtual de Java, pero para PHP, y ejecuta directamente el PHP 10 veces más rápido que Apache+PHP o PHP por línea de comandos.

La pega es que todavía no es compatible con todo, precisamente hace unos días lo probé para una aplicación en Symfony2 de 400.000 líneas de código e iba "casi bien", Doctrine no arrancaba lol

LiberaLaCultura

Y si trabajas en España le falta poner acostúmbrate a echar horas de mas sin cobrarlas y a que te traten como ganado, la consultoras no son mas que ETTs de programadores.

D

#26 Trabajas en Espana ?

A

Me hace gracia la última. Se pasaron horas y horas haciendo un programa y escogiendo los colores y el diseño en base a que el usuario "quería un fondo negro", para en la presentación final descubrir que el usuario "cuando dijo negro quería decir blanco".

Si hubiesen utilizado una metodología ágil de desarrollo, habrían descubierto que la estaban cagando desde la primera semana. Pero nada, hay quien sigue creyendo que funcionan las metodologías basadas en "Análisis completo" -> "Diseño completo" -> "Desarrollo completo" -> "Presentación al usuario", cuando suelen fracasar miserablemente.

KimDeal

#40 el método clásico sobrevive porque casi todos los clientes/usuarios quieren trabajar con presupuestos cerrados. Es decir, lo más baratos posible. Las metodologías ágiles incrementan el coste, porque reflejan el coste real. Y eso no interesa a nadie (excepto al equipo de desarrollo, claro).

I

0) Java kills.

Como currela en seguridad informática os suplico por el amor de Ritchie que nunca desarrolleis en
Java.
http://www.informationweek.com/attacks/java-still-not-safe-security-experts-say/d/d-id/1106169?

D

#24 #43 Pues si no se pueden utilizar estos lenguajes (Java, ASP, .NET y visual basic.), mejor cerramos el chiringuito y nos hacemos panaderos o de cualquier otro oficio por que a ver en que lenguajes están hechas el 95% de las aplicaciones???.

mzneverdies

#44
Windows, Linux: C (mayoritariamente)
Facebook, twitter: php/ruby/python

D

#45 De verdad que crees que Windows y Linux esta hecho solo con C ??? Si windows no utilizara su plataforma de desarrollo .Net ni linux Java todabia estaríamos con sistemas operativos basados en consolas de comando.

De todas formas coméntale a tu jefe que en las próximas aplicaciones que vas a utilizar Phyton o Ruby a ver que te dice.

mzneverdies

#46 Aquí programamos en PHP (vale, si, te concedo que nos va como el culo ahora mismo, pero como al resto de españa en general)
Te iba a recomendar que mirases el significado de "mayoritariamente", pero me acabo de dar cuenta que ese palabro no existe, que se dice "mayormente", así que te voy a dar un positivo.

D

#47 el PHP te reconozco que es el lenguaje mas utilizado de los que has puesto y que tiene gran aceptación en desarrollos Web, pero el Phyton y Ruby en ningún sitio que he trabajado se utilizaba. Por otra parte el C con sus punteros se hace infernal.

El lenguaje a utilizar también influye del tipo de proyecto que sea, por que como sea una aplicación para un banco o algo así serio no creo que sea buena idea hacerlo con PHP.

MEV

#48 Yo trabajo con Ruby y encantado estoy, y conozco varios sitios que también lo utilizan.
Uno de ellos es una empresa de pagos internacionales a universidades americanas (mueven mucho dinero) y todo su software está montado en Ruby (combinando servicios en Rails, Sinatra, workers...).

m

#24

A

#24 Eso es sólo relevante cuando ejecutas java en un "sandbox". Básicamente, para el usuario normal, sólo afecta cuando usas java en el navegador.

Si lo que quieres es programar una aplicación de escritorio en Java (como por ejemplo un conocido IDE del que no sé si habréis oído hablar llamado Eclispe ), o ejecutas Java como tecnología en el servidor (cualquier tecnología de Servlets y derivados), esas vulnerabilidades son irrelevantes.

No es que lenguajes como php, ruby y phyton sean más seguros que java, es que en esos lenguajes directamente es imposible que estas vulnerabilidades se puedan dar, ya que ni siquiera ofrecen las características que Java ofrece que son las que a la postre causan estas vulnerabilidades. Si limitamos java a los usos posibles que ofrecen esos lenguajes, la seguridad es la misma.

En todo caso, es cierto que Oracle no está respondiendo bien a los problemas que se han encontrado. Pero sustituir esas aplicaciones de java por equivalentes en php, ruby y phyton es, en algunos casos, simplemente imposible, porque estamos hablando de código java que se ejecuta en el cliente (navegador). A veces se puede sustituir por código javascript (que es lo que se debe hacer cuando sea posible) o flash (que también está lleno de vulnerabilidades).

Pero incluso así Java permite algo que no se pude hacer fácilmente con javascript: firmar el código que se va a descargar para ser ejecutado y pedir al usuario exáctamente los permisos para las cosas que quieres hacer. En javascript no es posible porque no existe un consenso de cómo hacerlo que sirva para todos los navegadores.

kolme

Otra buena lectura para programadores:

http://samizdat.mines.edu/howto/HowToBeAProgrammer.html

D

menos mal que no soy programador....

x

Buen documento sin duda pero se echa de menos una versión imprimible en pdf

esparta

#28 Gracias ya está corregido y en línea.
#29 No estaría mal, lo veo y aviso.

d

El mejor es Lisp.

D

espartaesparta en la número 69 el título y el texto pone poliformismo, cuando debería ser polimorfismo.

eternoycambiante

Cojonudo

R

Opino que saber inglés debería esta muy arriba en lista.

Claro, que como la versión orignal está en inglés... se da por hecho.

T

DDD (Domain Driven Design) o Diseño Orientado/Guiado por el Dominio. Ahí, aunque no técnicamente, están resumidas todas las ideas base de esta lista o todo lo que se añada a ella.

A los desarrolladores con algo de experiencia, basta con que leáis los primeros capítulos de algún libro que habla de ella, para que cada dos por tres según lo leáis, penséis "joder, es lo que digo yo" y lo asociéis a algún proyecto en que hayáis participado.

ceroeurista

nunca buscar "google" en Google

Paideia

Escribe código como si tuvieras que mantenerlo por el resto de tu vida y seríamos más felices

Sofrito

Yo me sé 98.

G

Se podrían haber ahorrado tantas líneas si hubieran puesto "lo que no debes usar"

Java, ASP, .NET y visual basic.