none
La huella del Programador RRS feed

  • Debate general

  • hago este post por que en este foro y muchos blogs de .Net y c# siempre se esta comentando de como es mvc, de mvvm, de arquitectura en capas, principios solid etc etc etc.

    Y uno siempre esta buscando aprender y tratar de hacer las cosas mejor para sus proyectos, aunque para mi a sido imposible seguir al pie de la letra los marcos de desarrollo, pues he tomado lo que me sirve me creado lo que mi líder llama la huella del programador.

    Lo cual hable hoy con el sobre eso, y realmente no me dijo nada bueno, se podría decir que salí regañado. ya que en todos los proyectos que participo busco poner mi huella. 

    Para lo que el me comenta que ser bueno no significa dejar tu huella o tu estilo, si no adaptarte al el estilo de quien sea, que siempre habrá proyectos con muchas huellas y mi trabajo es seguir las huellas que están hechas, en pocas palabras me dijo:

    Concéntrate en el requerimiento funcional, que es lo ve el cliente, el código fuente cada programador deja su huella y la defenderá, tu trabajo es sin importar la huella previa, has los mantenimientos y modificaciones lo mas pronto posible. 

    Y creo que tiene razón, a veces uno se pierde en querer crear buen código y por eso atrasas el requerimiento funcional.

    Que piensan en este foro sobre esto???

    viernes, 29 de junio de 2018 15:32

Todas las respuestas

  • Yo paso por lo mismo.  Tiene fundamento pero también carece de visión.

    Para bien o para mal (y aparentemente, porque soy arrogante jeje), en la gran mayoría de los casos me encuentro con código de muy baja calidad cuando tomo proyectos existentes.  Han habido muchos casos en mi vida profesional en donde he tenido presente la opción de arreglar rápidamente algo contra la opción de hacerlo como debió hacerse desde un principio.  En la mayoría de los casos donde tomé la opción 1 (corregir rápidamente), me ha terminado "mal" porque posteriormente he tenido que lidiar con otro problema derivado de lo mismo.  Entonces se me vuelve a presentar la opción:  Corregirlo rápidamente (pero ya no parece tan rápido) o hacerlo bien.  Si lo hubiera hecho bien desde el principio, no hubiera tenido que pasar por lo mismo otra vez.

    Lo mismo me pasa con la mayoría de los componentes RAD de Visual Studio:  Son para trabajos sencillos, para el programador principiante.  ¿Por qué vinculo a datos manualmente y no usando un ObjectDataSource, por ejemplo?  Porque no tengo flexibilidad para cubrir casos excepcionales.  No tengo dónde meter código por optar por rapidez.  Igual me pasa con los ORM.  No tengo por dónde entrarle cuando no soy yo quien controla el código fuente.

    Entonces supongo que mi opinión es:  Comparar huellas.  Si la huella de mi antecesor es deforme, en lo personal haré lo posible por borrarla.  Sí, hay contratos, hay límites de tiempo, hay límites monetarios, etc.  Es un dame que te daré.  Pero de ser posible, siempre hay que optar por corregir el problema de raíz en vez de repellar la superficie.


    Jose R. MCP
    My GIT Repositories | Mis Repositorios GIT

    viernes, 29 de junio de 2018 15:47
    Moderador
  • WebJose

    Y otro problema es cuando los dos recursos están aun, tu y el que hizo el proyecto, y como dices que tal si los dos son arrogantes, que tal si tus cambios de mejora, a el lo entorpecen, por que sea como sea que este el código es de el y lo entiende. y tus cambios ya no estará tan familiarizado y el defenderá su huella también.

    Como resultado dos compañeros de trabajo enojados, tus cambios, sus cambios, dos formas de programar distintas en el mismo proyecto. Los dos entorpeciendo ce el trabajo. gente lastimada por que se critico su trabajo.

    Y muchos dirán la solución es poner un standard y que todos los sigan. Pero cuando desarrollador te piden hacer las cosas de una manera forzosa y no estas de acuerdo, ya no lo disfrutas. 

    Total ya no se que es lo correcto, hoy tome un proyecto donde la clase de datos tiene 2845 lineas de código, y lleno de métodos que retornan bool y un parametro out de tipo Dataset, cuando realmente esa aplicación solo hace alrededor de 10 consultas. 

    Tontamente critique propuse cambiar todo y el resultado fue malo

    la respuesta fue, yo hago un cambio en 5 minutos desde la presentación hasta los datos cualquiera que sea y tu cuanto te vas a tardar

    viernes, 29 de junio de 2018 16:14
  • Cierto, todo muy cierto.  Y si resulta ser que quien hizo todo malo es el arquitecto, terminan por despedirte (me pasó a mí) porque él es quien habla con los de arriba y lo que hacen es criticarlo a uno para que al final los de arriba digan "no nos sirves".  Esa es mi desgracia (más arrogancia jaja):  El 99,9% de las veces, soy muy superior al "arquitecto".

    Y que no le asusten 3000 líneas.  En mi último proyecto para una compañía de dentistas en New York, me tocó arreglar (en realidad, desaparecer) un archivo de JavaScript AngularJS de 8800 líneas que contenía el código de AngularJS de toooodas las vistas del sitio web.  Todas referenciaban el mismo archivo, cargando rutinas de todas las vistas y usando solamente las que correspondían a la vista.  Habían versiones de la misma función copiadas y pegadas porque el inútil que lo hizo ni siquiera poseía la capacidad de pasar por parámetros los nombres de campo.  Entonces le parecía bueno copiar y pegar, cambiar el nombre de función y cambiar los nombres de los elementos a mano.  Yo me rehusé a trabajar así y retrasé la corrección de errores por un release mientras reescribí todo en 30+ archivos y un total de 3300 líneas.


    Jose R. MCP
    My GIT Repositories | Mis Repositorios GIT

    viernes, 29 de junio de 2018 16:26
    Moderador
  • hola

    La respuesta depende de como este planteado cada proyecto, si esta corto de presupuesto, el cliente es pesado y quiere la funcionalidad para ayer, el codigo paso por muchs manos, etc

    bueno en ese caso toca hacer lo que se pueda, sacar la funcionalidad y pasar a otra cosa

    Ahora muy distinto es un proyecto de innovacion, donde se prioriza aprender, se puede dar marcha atras y rehacer lo que hizo mal, hay una buena planificacion.

    En este caso si se puede pensarla arquitectura

    Lo que planteas le pasa a miles de programadores, y depende puntual de ese proyecto, si te tocan muchos de este tipo y no te gusta, solo hay una solucion, pensar en un cambio laboral

    >>Y creo que tiene razón, a veces uno se pierde en querer crear buen código y por eso atrasas el requerimiento funcional.

    crear buen codigo se puede, pero tiene que surgir de la planificacion, si se arman tareas solo para parchar como se pueda con los tiempos justos, bueno mucho no se va a poder realizar

    pero esto depende de variables de tiempo y presupuesto del proyecto

    si tu jefe te dice esto es porque seguramente no debe tener muchos tiempo o dinero para invertir, debe querer scer la funcionalidad cuanto antes, aunque despues se siga pagando mas caro el precio del mantenimiento siguiente

    Estas son decisiones que exceden a un programador, porque deberias estar al tanto de que se prometio al cliente

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    lunes, 2 de julio de 2018 5:09