3USD tu primer mes de Premium ūüėĪ Canjear promo No me interesa

notifications Notificaciones

Marcar todas como leídas

Ver m√°s

lightbulb_outline

Un buen desarrollador.

timer 3 Min.

remove_red_eye 3967

calendar_today 30/11/14

√öltimamente me he topado y he pensado en varias de las cosas, que generalmente la escuela no te ense√Īa, y que te convierten en un buen desarrollador, y es que por la naturaleza de una escuela (evaluaciones, tiempos, semestres, finales) es casi imposible trabajar en los detalles de un proyecto, casi siempre, al final, todo se limita a si funciona o no, si cumple lo que el maestro pidi√≥ o no.
Durante la carrera (y a veces fuera de ella) he escuchado muchas veces la frase "lo importante es que funcione", la realidad, en la vida profesional es otra, que funcione es sólo el primer paso, y generalmente es lo más sencillo.
Aquí presento una de las cosas que me parecen hacen a un programador pasar de los proyectos casuales a un trabajo más profesional, estoy seguro de que habrá otros, o probablemente haya quien no concuerde con ellos, ojalá puedan dejar sus opiniones en los comentarios :)

Testing

Hay malos programadores, buenos programadores y programadores que hacen testing del código que escriben. Hacer testing automático, puede resultar laborioso al principio, sin embargo, acarrea muchos beneficios, el más claro de ellos es, menos bugs, y es claro que si tu código fue probado, es menos probable que falle. El otro beneficio es que, todos los programadores hacen testing, sí, pero manual, cada que recargas la página para ver si funcionó lo que hiciste, o pones una variable por ahí de debugging para ver si se entró a un ciclo o una condición, estás haciendo testing, pero de nuevo, lo hacemos manualmente, automatizarlo significa que ahorramos tiempo, dejando que el mismo código pruebe el código.
Supongo que al principio es dif√≠cil, porque el c√≥digo tiene niveles de complejidad, y as√≠ igual los tests, hay c√≥digo que es m√°s dif√≠cil de testear, y en ocasiones hay que ser tan creativo para escribir c√≥digo como para testearlo. √Čsta, es una pr√°ctica, que como todas, se desarrolla llev√°ndola a cabo, practicando.

POO

No es que la programaci√≥n orientada a objetos sea muy complicada, de hecho nos ense√Īan POO en todas las universidades, adem√°s de que hay N cursos en l√≠nea, art√≠culos y m√°s. Sin embargo, en mi experiencia, uno nunca deja de aprender conceptos de objetos. Al principio empezamos creando clases, tal vez despu√©s comencemos a heredar una que otra cosa, posteriormente a usar interfaces, a encapsular los datos, sobrecargar m√©todos; posteriormente tal vez empezamos a crear m√≥dulos, tal vez nos demos cuenta que un objeto sabe mucho de otro objeto y creemos clases que los relacionen. A√ļn despu√©s, te enteras de que existen cosas como la Ley de Demeter(http://es.wikipedia.org/wiki/Ley_de_Demeter), y otras m√°s. 
Lo que quiero decir es que entre más objetos escribes, te vuelves mejor desarrollador, te vuelves mejor definiendo clases, métodos, alcance de los atributos, etc. etc. etc.

Escalabilidad

Por la naturaleza de los primeros proyectos que escribimos, no nos desarrollamos pensando en problemas de escalabilidad, rendimiento o velocidad. M√°s a√ļn, cuando presentas un proyecto en la universidad, no ser√°s sometido ni a 50 usuarios concurrentes, adem√°s de que al maestro no le importar√° si el sitio carga en 10 segundos, en 20 o en 2. En el mundo real, todo lo antes descrito pasa, y las empresas, startups, iniciativas, esperan estar preparadas para todo eso, esperan que su sitio est√© online 100% del tiempo, esperan que su sitio sea veloz. Aqu√≠ es donde queda m√°s claro que lo importante no es s√≥lo si funciona, si no qu√© tan bien funciona, aqu√≠ es donde podemos darnos cuenta que hay niveles de funcionamiento, no todo lo que "funciona" est√° bien hecho.
Un proyecto de la vida real debe estar preparado para crecer, no necesariamente para millones de usuarios concurrentes, pero s√≠ miles, o mejor a√ļn cientos de miles. Y sobre todo, si al principio no est√° listo, debe estar dise√Īado para poder escalarlo despu√©s.

Mantenimiento.

¬ŅQu√© caso tiene definir bien o mal las clases de nuestro proyecto? O mantener conceptos como DRY(http://en.wikipedia.org/wiki/Don%27t_repeat_yourself) si a final de cuentas, si funciona o no, no necesariamente depende de eso... bueno, la respuesta es, mantenimiento. Por supuesto que me refiero a mantenimiento de software; en la escuela terminas un proyecto y listo, rara vez vuelves a saber de √©l. En la vida real, encuentras bugs en producci√≥n que tiran el sitio o la app, te mandan a resolver el error del c√≥digo de otro programador, o a agregar un nuevo feature a √©se proyecto de miles de l√≠neas. Esas cosas pasan siempre, y en ese momento agradecer√°s al yo de tu pasado, o cualquiera que sea el anterior programador, el que haya dise√Īado el c√≥digo apropiadamente, que haya utilizado patrones de dise√Īo, etc. B√°sicamente que hayas escrito c√≥digo limpio, porque si lo haces, agregar nuevas cosas o resolver errores ser√° mucho m√°s f√°cil.

¬ŅQu√© m√°s?

Hay muchas m√°s cosas que diferenc√≠an a un buen desarrollador de uno promedio, por ahora dejar√© √©stas por aqu√≠ (son las que consider√©, s√© que un buen desarrollador sabr√° otras) ¬Ņpor qu√©? Es s√≥lo algo que he visto mucho √ļltimamente, es algo que s√© las empresas pedir√°n cuando busquen contratarte, es algo que me ha hecho leer y revisar lo que he escrito antes, as√≠ que, nunca es muy pronto para empezar a aplicar buenas pr√°cticas, as√≠ que no importa que tanto o poco c√≥digo hayas escrito, puedes ya a empezar a convertirte en el futuro Facebook developer, Google developer, o qui√©n sabe qu√© quieras hacer. Porque eso s√≠, programadores hay pocos, pero buenos programadores hay todav√≠a menos, por lo que las empresas los pelean, los buscan, les ofrecen las maravillas del mundo, y estoy seguro que varios de ustedes querr√°n estar en esa situaci√≥n ;)


Otros artículos del blog

Comunidad