📚 APRENDE PROGRAMACIÓN EN PLATZI Accede a más de 1000 cursos y 21 áreas de estudio con este DESCUENTO para nuestra comunidad: 🔗 mouredev.com/platzi 🔗 Redes y enlaces de interés | moure.dev 👾 Discord | mouredev.com/discord
📚 APRENDE PROGRAMACIÓN EN PLATZ Accede a más de 1000 cursos y 21 áreas de estudio con este DESCUENTO para nuestra comunidad: 🔗 mouredev.com/platzi 🔗 Redes y enlaces de interés | moure.dev 👾 Discord | mouredev.com/discord
A mí en lo personal me gusta modularizar mas algunos compañeros de trabajo en alguna oportunidad me han dicho que programo "enredado". Otra práctica que he empezado a utilizar este año (y en proyectos personales) es programar en inglés, ya que los nombre de funciones y variables son más cortos, entre otras muchas ventajas (como mejorar y aprender el idioma). Saludos desde Santiago de Chile.
Yo creo que te empecé a seguir y mirar tus videos porque me relajás, sos como el modo Zen del programador extremo. Te pongo de fondo casi como un podcast... La mayoría de las cosas de las que hablás ya las sé, por experiencia y la facultad etc, pero siempre algún concepto nuevo se aprende. Aún así dejo todo para relajarme jajaja. Me encantaría tener más amigos y conocer más gente como vos. Yo soy muy electrificado, y las personas como vos me hacen bien. Gran contenido abrazo.
Que buen video es el mejor que e visto ya que no solo te muestran como mejorar tu forma de programación sino también dan una comprensión más profunda del todo lo que realizas durante la programación y esto como bien dice es aplicado a todos los lenguajes de programación, la verdad me encantó ya que no había en internet ningún curso así donde te explican el porque de las cosas muchos cursos en línea actualmente se centran en como resolver un problema o como usar una metodología y ya es todo nunca explican el motivo de porque esa estructura ni porque debes hacerlo de esa forma o ni siquiera mencionan que esa es la forma correcta, la verdad me encantó el vídeo muchas gracias por el video me sirvió mucho sigue así 👍🏻 gran video pocos canales como el tuyo la verdad me alegro mucho de haberlo encontrado, estaré al pendiente de todos tus videos, saludos.
De verdad que es agradable ver tus videos, transmites paz y tu castellano no pareciera que estas en España. Un gusto haber llegado a tu canal y a ver si un dia nos cuentas como te organizas en un día de labores(o como lo hacías en el pasado y que mejoraste, tanto profesional como familiar)
Tienes unamanera excelente de explicar las cosas, tus cursos son estupendos, recién empezaré el de python y espero luego continuar con los demás, muchas gracias Moure
Razón extra en el punto 14: las palabras en Inglés son usualmente mas cortas en ese idioma a comparación con el nuestro, por lo mismo los nombres de funciones y variables terminarán siendo mas cortos, por ende mas legibilidad en bloques grandes de codigo.
@Kung Foo - Programación y demás sandeces Entiendo y en parte estoy de acuerdo, lo decía desde el punto de vista de "buscar el pedazo de codigo dentro del archivo donde esta X funcionalidad", No puedes negar que un shorthand if es mucho mas legible con variables cortas jaja. Sobre el naming, hay bastantes convenciones para mantenerlas concisas e informativas, personalmente uso camel case con tipo al inicio, como "strTitle", "arrPosts", "oPost", para strings, arreglos y objetos respectivamente.
gracias por los tips, me interesó el tema, ya que soy programar por autoaprendizaje, según estos puntos, no estoy tan mal, siempre hay algo que mejorar, pero en general ando bien, gracias, execelente vídeo.
Estoy aprendiendo a programar (hace varios meses ya 😵💫) y estoy tratando de aplicar los consejos de este video en un programa de práctica, un registro de entrada y salida para ser más exacto. Estoy tratando de meter todo lo que pueda en funciones para reducir el código repetido, pero no puedo evitar anidar dos o tres sentencias if 😂. Como sea, me ha servido bastante este video como orientación.
Mil gracias Maure llevo aprendiendo a programar desde hace 3 meses y la verdad saber donde están los agujeros para no pisarlos es muy bueno, y ya que lo has preguntado de los 15 conocía 10 los que tienen que ver con clases y funciones aun no se lo que son jejejeje seguro que con tiempo entiendo todo lo que has explicado en el video. Aun así mil gracias por el video
te agradezco por todo la información, la verdad no tenia idea alguna de todos esas malas practicas, esto es una ayuda muy importante para alguien que esta comenzando.
Excelentes Tips, personalmente me quedo con el uso del constructor para estados null de objetos en la sección de hardcoding este punto va resultar beneficioso en los diseños. gracias por el tutorial.
Yo como desarrollador con muchos años en el sector, siempre recomiendo NUNCA COMENTAR CÓDIGO bajo casos excepcionales. Un código SIEMPRE TIENE QUE SER AUTODESCRIPTIVO por sí mismo. Si hay algo en el código que cuesta de entender,es por el echo de que el desarrollador no se ha explicado bien en el desarrollo semantico del código. Siempre hago la analogía con una partitura , a caso una partitura está reescrita por el compositor o se entiende por la simbología lo suficiente como para tocar un instrumento. Pues el mismo caso para el código NUNCA HAY QUE COMENTAR LO QUE YA ESTÁ COMENTADO, simplemente hay que encontrar técnicas de escritura para que un desarrollador pueda entender un código con solo un vistazo rápido. Si UN CÓDIGO ESTÁ MUY COMENTADO ES PORQUE NO ES AUTODESCRIPTIVO eso es sinónimo de mala programación. Sin embargo sí que considero que hay excepciones, por ejemplo, has tenido que hacer algún remiendo/ chapuza porque no se adapta bien tu libreria con el sistema. Y explicas porqué has tenido que solucionarlo así, trozos de código que crees que pueden causar algun efecto de duda, pero siempre en casos excepcionales. Otro problema al comentar el código es que los comentarios quedarán obsoletos en poco tiempo hasta que deje de ser consistente el comentario con el código ,por el simple echo de que el código ha pasado por muchas manos. Dejando como resultado confusión para la gente que empieze a tocar esa parte de código. Resumiendo NO COMENTES LO QUE YA ESTÁ COMENTADO.
Correcto, el código debe ser autodescriptivo. Si el trozo de código es difícil de entender es un mal diseño. Los comentarios también deben ser mantenidos para que expliquen los cambios en el código que comenta... Si se diseña bien no son necesarios.
Cuando tienes que retomar o retocar algo que hiciste hace 2-3 años se agradece que este mínimamente comentado para no volverte loco. Hay lenguajes que son mas autoexplicativos que otros, pero comentar nunca esta de mas y si trabajas con mas gente es obligatorio comentar lo que haces.
Vídeo recomendadísimo, sobre todo para empezar a tapar smells antes de que llegue nuestro amigo y vecino Sonar 😂. Me ha llamado la atención la parte de comentar el código. Entre la "antigua" norma de comentar mucho y Uncle Bob diciendo que un código limpio no necesita comentarios, al final el saber dónde y cómo comentar es todo un arte jedi.
Excelente video man, respecto al punto 11 podría decir que los comentarios se ahorran si el nombre de la clase o función describe correctamente lo que hace. Si es una función que cuenta con un algoritmo complejo, si podría ayudar algún comentario que especifique cierto paso.
Muchísimas gracias, me ayudó a darme cuenta de varios errores que he cometido y que me doy cuenta que me hubieran hecho el trabajo más fácil de haberlos hecho bien
Brais estás en mi lista de inspiración mil gracias por tu conocimiento, quisiera subieras una guia para programar en mobil usando HTML, JS y CSS no he encontrado información se que algunos mencionan angular, cordoba y la base de datos firebase pero no encuentro alguien que arme una guia para poder desarrollar una app en movil con lenguaje web y poder diseñar mis app te agradecería mucho anhelando en un futuro poder devolverte todo ese conocimiento
14:39 *_"Pensemos siempre en la seguridad de la ejecución de ntro programa. Cuantas menos cosas pueda hacer, más seguro será, y menos podremos meter la pata"_* Y esto señores es la definición de la filosofía Unix, q Linux adoptó exitosamente x 20 años... hta la llegada de Poettering y sus "bad boys" balbuceando q era un criterio viejo y "obsoleto" q no cabía en una mentalidad "moderna" y "revolucionaria" como la de ellos y lo desecharon... lo q llevó a esas "maravillas" de systemd, pulseaudio y otras, a las q pintan color "progreso" y no son más q la versión remozada de una mala idea, fallida y antiquísima. Muy agradecido x este video. Es una bocanada de aire fresco en este ambiente viciado de necios con pretensiones de "lumbreras".
imagino que no soy el único en comentar esto pero, la razón 14 no está al revés? es decir, que sería SI programar en inglés, por ser el idioma universal de programación?
Me encanta tu comentario de 'tu yo del futuro'. A todos los que han trabajado conmigo les digo (en cuanto a comentarios) pon el comentario para que , al menos, tu yo del futuro se entere.... Bueno... De 15... Tengo q revisar bien las de las variables... Ahí tengo q decir que no le presto toda la atención aunque suelo hacerlo. Por el resto... Me has dado un "subidón... subidón..."😁
jajaja, Tengo un compañero que hacia (o hace) todo eso, a tal grado que terminaba los proyectos en minutos y el programa funciona, aunque no hace lo que deberia hacer.
Para mi el objetivo de un hacer un código un programa un software es que funcione y listo y el buen programador sabe que aunque el programa sea correcto en el resultado sabe cuales son los errores escondidos es decir códigos que si sumamos 2+2 debe dar 4 es lo correcto pero debe tener en cuenta que si por error se digita cualquier tecla no se valide y esto debe tenerse en cuenta en la creación del código y listo cada programador diseña su programa independiente lo otro es que se copie el código pero si no lo entiende queda mamando.
Completamente de acuerdo en todas ellas, pero particularmente me gusta nombrar a mis variables y funciones en español ya que así las distingo muy fácilmente de las que he usado del propio lenguaje y librerías y además hace más comprensible mi código.
Otra mala práctica muy hbaitual que he visto es la de usar códigos de mil o más líneas, meter todo en una única clase o método/función, y también lo contrario, astraer en 20 clases algo.
Tengo un jefe que no le gusta que use palabras en ingles cuando programo, mas que todo en las bases de datos me gusta usar "id", mi jefe a pesar que sabe que significa no le gusta, dice que use identificador o secuencia... digo es mas fácil dos letras... en fin.
Algo que dijiste me hizo mucho ruido... yo el code smell que uso con respecto a comentarios es el opuesto: Si un código tiene mucho comentario explicando como funciona, es probable que ese código esté mal escrito y no sea lo suficientemente legible. Lo dice Rob Martin: un comentario es una demostración de la incapacidad de expresarse en código. Aparte el código evoluciona y nunca se está 100% seguro que se modifique los comentarios. Mejor separar el código complejo en varias funciones autoexplicativas
Cero comentarios me parece un error. Me refiero a comentar código que lo precise. A veces, por bueno que sea el código, un comentario acertado puede ahorrarte mucho trabajo.
@@mouredev O sea, me parece que decir que "Cero comentarios me parece un error" es demasiado fuerte. Yo te puedo pasar código que escribí sin comentarios(hablo de comentarios, no xdoc que si me parece bueno) y estoy seguro que vas a entender bien y rápido lo que hace inclusive sin saber la tecnología que estoy usando. El comentario es en si el ultimo recurso cuando no se puede lograr un código más entendible. Es más, concuerdo con Rob Martin cuando expresa que un comentario es una incapacidad de expresarse(que eso es lo que hacemos cuando codificamos). Muchos comentarios son facilmente eliminables si se aplica lo que dice en video(modulacion + bien nombrado) Por Ejemplo: if ((person.sex = FEMALE && person.age > 60)) || (person.sex = MALE && person.age > 65) || (person.isDisabled())) {...} // Is the person eligible for a pension? ese comentario aporta valor porque explica facilmente que chequea ese if y como decis nos facilita el trabajo. Pero no es mejor: if (person.isPensionEligible()) {...} Con el resto de los puntos estoy en general de acuerdo, alguno con pequeño matiz y agregaría alguno más(el else es un enemigo por ejemplo)
excelentes consejos ! consulta sobre el curso de kotlin que tenes en youtube! esta actualizado? o lo vas a actualizar? estoy estudiando programacion full stack , pero quisiera a futuro irme para el lado mobile, me llama muchisimo la atencion,y quisiera aprender kotlin, se java pero por lo que vi en kotlink hay muchos cosas que varian y me confunden por eso quiero arrancar con kotlin aparte que veo el lenguaje esta ganando terreno en lo que es mobile
No se Pyton, pero por el estructurado, creo intuir que es el lenguaje que usastes para los ejemplos. Una duda ¿el proceso de minimizar lineas, tambien puede ser considerado mala practica?, ejemplo burdo : una funcion con un parametro y un console.log para ver si llegó el objeto correctamente, todo en una sola linea... es considerada mala practica? Se ganó de antemano un like por lo bien explicado en el video. Gracias
Con el tema de los comentarios no estoy de acuerdo, si haces los tests, estos mismos documentarán el código. Nosotros no ponemos ningún comentario para explicar código, lo consideramos una mala práctica en el equipo...
Yo creo que hay que poner muy pocos, pero en algunos casos, a pesar de test, pueden ayudar mucho a entender la complejidad de una funcionalidad rápidamente empleando medio minuto. Obviamente, todo es discutible :)
Me gustaría que profundizaras un poco más en el apartado de seguridad ya que ha quedado un poco abierto (entiendo que cada lenguaje tendrá lo suyo). Lo de los comentarios es una de las cosas que genera más dilemas, hay quien comenta poco (o nada) y quien comenta demasiado, a nivel personal prefiero un código sobre comentado que no un código apenas comentado. Buen video.
Has enseñado un poco de POO o OOP. Eso es un poco avanzado. Sería bueno que expliques algunas palabras en Inglés que usas como por ejemplo Hard Coding. Yo no tengo problemas pero otros se pueden quedar en la luna. Me gusta sus videos porque necesito saber las palabras técnicas que se usa en español. Gracias.
No estoy de acuerdo con esa práctica tan extendida de dividir funciones relativamente extensas en funciones más pequeñas, creo que si lo que hace la función tiene coherencia y sigue una secuencia lógica de pasos relacionados entre sí, no hay motivo para segregar dicha lógica, en mi opinión así se consigue lo contrario a "simplificar".
