Mi diseño propuesto suele ser peor que el de mi colega, ¿cómo puedo mejorar? [cerrado]

Creo que esta es una señal muy positiva de tus habilidades. Es mucho más común que las personas que tienen dificultades para encontrar el diseño "mejor" en un equipo sean completamente incapaces de reconocer por qué otro diseño es mejor.

Tienes dos fortalezas realmente grandes (y sorprendentemente poco comunes) a tu favor:

• Eres capaz de evaluar tus diseños contra otros objetivamente
• Tienes el deseo y el esfuerzo de hacer que tus diseños sean óptimos

Tienes solo un par de años y tienes un largo camino por recorrer, pero con esta actitud definitivamente llegarás, simplemente no te rindas; Todos tratamos con retrocesos mentales como este. Cada vez que tengo la oportunidad, me gusta conectar Principios de diseño (NO es lo mismo que los patrones de diseño ) y creo que este es un ejemplo perfecto de dónde son útiles. Estudíalos y practícalos aplicándolos en tus diseños; antes de que te des cuenta, habrás dado un paso más en este sentido.

Al final del día recuerda, diseñar es difícil. Nos enfrentamos a abstracciones complejas de alto nivel todos los días, para crearlas desde el aire, hacer que funcionen bien y que la tarea de los colegas sea fácil de usar. Es una tarea extremadamente difícil. Lleva práctica, por años .

Entonces, levante la cabeza y recuerde: hay un grupo de personas que no pueden evaluar dos diseños y en realidad reconocen uno como preferible a otro, ¿qué tan bien cree que se están llevando bien en la creación de buenos diseños?

Editar:
'Para más información, después de entender los principios y practicar un poco su aplicación, creo que hay otra joya de otra pregunta que habla del valor de estudiar una variedad de idiomas que tienen diferentes propósitos y reglas:

  

Idealmente, todos los programadores deben conocer un lenguaje de cada clase. ¿Qué podrías aprender?

     

1. Un lenguaje convencional OOP de tipo estático: Java, C # (utilizado principalmente en software empresarial) y C ++ (programación del sistema y aplicaciones de escritorio complejas)
  
2. Un lenguaje OOP basado en prototipos: Javascript (programación web del lado del cliente)
  
3. Un lenguaje de procedimiento: C (software incorporado y programación del sistema)
  
4. Un lenguaje funcional: Haskell, ML o Lisp (los lenguajes funcionales son buenos para el software altamente paralelizado).
  

Un lenguaje de programación lógico (Prolog) probablemente no sea tan útil en la industria, ya que se utiliza principalmente en investigación en IA.

Esto ayudará a ampliar la variedad de ideas que vienen a la mente al intentar diseñar una solución.

1. Esto es absolutamente normal para que varias personas propongan diseños de diferente calidad. En el pasado me invitaron a juzgar competiciones en diseño de software, así que fui testigo de esto de primera mano: incluso los diseños más simples dieron como resultado soluciones de una calidad drásticamente diferente, todas provenientes de personas inteligentes y con experiencia.
2. El código fuente de lectura es demasiado bajo para ayudarlo a mejorar sus habilidades de diseño: el código aborda la complejidad en el nivel más bajo que el diseño general.

La mejor manera de mejorar en el diseño de software es diseñar software ^* . Una forma de hacerlo es mirar las competiciones de diseño: TopCoder tiene un archivo de más de 100 diseños de componentes, completo con documentación de diseño UML e implementaciones en Java y / o C #. Elija un componente terminado que le guste, lea la especificación de requisitos e intente crear un diseño original para cumplir con los requisitos. Pase una hora o dos pensando en el problema y dibujando un diagrama de clase, luego abra el diseño ganador y lea lo que hizo el autor. Compare su diseño con el suyo, detecte las diferencias y vea si su diseño es mejor. Verifique el cuadro de mando de la competencia para ver cómo los jueces calificaron el diseño. Esto le dará la información que necesita para decidir cómo mejorar sus habilidades de diseño.

Bueno, no renuncies a tu trabajo. Es mejor trabajar con alguien que tenga mejores habilidades que tú, para que puedas aprender de él o ella.

Mira el mejor diseño y determina por qué es mejor. Conozca el diseño aceptado y piense en formas en que podría aplicar un diseño similar en otras situaciones. Una vez que sepa por qué es mejor que su diseño, entonces sabrá qué error no debe hacer la próxima vez que haga un diseño. Hable con el otro desarrollador y pregúntele cómo se le ocurrió el diseño.

Para mejorar las habilidades de diseño, lo mejor es crear diseños, luego ser brutales con usted mismo al evaluarlos y determinar cómo pueden mejorarse. Hágase preguntas como: ¿Funcionará y cumple con el requisito en todos los aspectos? ¿Se puede mantener? ¿Cómo podré probar esto? ¿Causará problemas de rendimiento? ¿Cuál es la probabilidad de que cambie el requisito y qué tan bien funcionará el diseño? ser capaz de manejar el cambio. Lea sobre patrones de diseño y luego intente aplicarlos a sus diseños. Refactor sin piedad después de idear un diseño inicial. Si está diseñando una base de datos junto con la aplicación, lea extensamente acerca de la normalización y el ajuste del rendimiento de la base de datos, aprenderá mucho sobre el diseño de la base de datos si aprende cómo hacer que una base de datos funcione de manera más efectiva y eficiente. Para aplicaciones, piense en los principios DRY y SOLID al hacer su diseño. Lea acerca de antipatrones para saber qué cosas debe evitar hacer.

Reconocer un mejor diseño es una habilidad importante. Debe fomentar esto a medida que sigue algunas de las sugerencias anteriores con respecto a los diseños.

¿En qué criterios juzgó mejor el otro diseño? ¿Fue más simple y fácil de entender? ¿Proporcionó una ventaja de rendimiento? ¿Fue más extensible? Hay muchos principios de diseño, como la descomposición, la abstracción, la ocultación de la información y la modularidad de los componentes, que puede utilizar para juzgar los diseños y que es posible que ya reconozca.

• Intente nombrar sus criterios, comprenderlos, expandirlos y reutilizarlos al mirar otros diseños. Cuando diseñe cosas por sí mismo, haga parte de su proceso usar esos criterios y mida conscientemente sus diseños en relación con ellos. Luego, prepárese para modificar o desechar completamente su diseño si no cumple con sus criterios.

Obtendrá ideas sobre diferentes principios para diseños de algunas de las siguientes fuentes: enlace Diseño de software en wikipedia Google "principios de diseño de software"

• Comprenda diferentes modelos para el diseño de software, como Diseño orientado a objetos o Diseño funcional o Diseño de análisis estructurado. Estas pueden ser mentalidades completamente diferentes desde las cuales abordar una tarea de diseño y cada una tiene áreas donde sobresalen. Aprende estos como herramientas para tu caja de herramientas. enlace

• Asegúrese de separar el diseño de la implementación, intente diagramar las cosas que ve como buenos diseños, para separar el lenguaje y los aspectos específicos de la implementación de los principios de diseño de nivel superior. Y para desarrollar tu "ojo de diseño" y tus habilidades de comunicación.

• Por último, pero quizás lo más importante, leer mucho es una muy buena herramienta: hay muchas cosas interesantes desde el análisis de fractales a bayesiano hasta el procesamiento de lenguaje natural y lógica difusa, que puede proporcionar ideas para ideas que surgirán más adelante y inesperadamente. Con la web puede examinar temas a lo largo y ancho, solo para su entretenimiento y edificación, y se beneficiará. No necesita convertirse en experto, solo familiarizarse con los términos e ideas.

Diviértete, ¡no lo hagas si no lo disfrutas al menos un poco!

Bueno, ya has dado el primer paso. Admite que tiene algo que aprender, que el trabajo de su colega es mejor que el suyo y que quiere aprender y mejorar.

El segundo paso es analizar. Mira su trabajo y no digas que es mejor; averiguar por qué es mejor. Busque detalles específicos y puntos que hizo mejor.

Una vez que entiendas eso, extrae los principios detrás de esto. Haga preguntas como estas:

• ¿Qué pasa con este diseño es mejor que mi diseño?
• ¿Es este punto algo específico de este diseño o es un principio general que podría aplicarse a otros diseños en el futuro?
• Si es un principio general, ¿cuáles son sus límites? ¿Cuándo es una buena idea no hacer las cosas de esta manera? (Este es muy importante. Evita que consideres una idea útil como un golden hammer , incluso en casos inapropiados.)

Intente resolver las cosas por su cuenta, ya que internalizará mejor las ideas si surgió la cadena de razonamiento que lo llevó a la conclusión, pero también hable con su compañero de trabajo para asegurarse de que esté seguro. re obteniendo las cosas bien (Después de todo, no quiere cometer errores en su razonamiento e interiorizar un mal principio). Y no dude en pedir ayuda a su compañero de trabajo si no puede resolver las cosas. La programación es una disciplina en la que la humildad tiende a ser respetada, y muchos programadores aprovecharán la oportunidad para enseñarle algo nuevo a alguien, lo que probablemente sea una parte importante de por qué StackOverflow se hizo tan grande tan rápido.

También me gustaría agregar (además de las grandes respuestas) que hay más que "Él puede crear un diseño mejor que yo". Las otras respuestas se centran en cómo puede mejorar en Diseño, que es todo y bueno ... pero ...

Apuesto dinero a que USTED puede hacer algo mejor que su compañero de trabajo. No para crear una coincidencia de orinar ni nada (¿puedes hacer Y mejor? ¡Jódete, puedo hacer X mejor!), Pero para señalar la verdad de que todos tienen fortalezas y debilidades.

En mi trabajo hay 4 desarrolladores. Hay momentos en que los dos "programadores" principales pueden crear cosas que simplemente me dejan en el polvo. Hace girar mi cabeza tratando de envolver mi cabeza alrededor de sus creaciones.

Pero soy mucho mejor en SQL y scripts de línea de comando que ellos, y puedo automatizar las cosas que dejan a THEM en el polvo.

¿Son mejores que yo? En alguna zona es definitivamente. Demonios, en muchas áreas son: soy el desarrollador junior en mi tienda por lejos e individualmente tienen años de experiencia en mí. A pesar de esos años de experiencia, soy mejor en algunas áreas que incluso ellos.

Deja de concentrarte en el hecho de que alguien es mejor en X que tú. Esa persona, sin intentarlo ni siquiera pensar en ello, podría superarlo incluso después de haber practicado en él durante los próximos 10 años. No es que no deba trabajar para corregir sus debilidades, pero recuerde que para cada fortaleza hay una debilidad.

Enfóquese en ambas, fortalezas y debilidades, de usted y sus compañeros de trabajo.

En todos los aspectos de la vida encontrará personas que no son tan buenas como usted, así como personas que son mejores que usted, especialmente después de "un par de años" de experiencia.

Tienes que aprender de todos.

No te sientas mal. Tal vez tu colega sea un natural. Deberías felicitarlo sinceramente y aprender todo lo que puedas de él.

No permitas que los profesionales se pongan celosamente entre ti y la oportunidad de aprender.

1. Un par de años realmente no es mucho. Y que hay personas con mejores o peores vistas de diseño de alto nivel. Por ejemplo, he conocido personas capaces de escribir algoritmos complejos para programas de bajo nivel en un abrir y cerrar de ojos, pero incapaces de comprender conceptos y diseño de niveles superiores como la cohesión y las dependencias. Sin embargo, este no es un estado de facto. Ambos pueden mejorar en el diseño de nivel superior (lea algunos libros, pruebe algunos trucos en su casa, etc.) y también puede descubrir que en otras áreas de programación su programador compañero es menos bueno. Además, si crees que estás en el mismo nivel tanto en experiencia como en conocimiento técnico, esto puede haber tenido una situación aleatoria. La próxima vez quizás tengas mejores ideas de diseño. Además, en lugar de renunciar a su trabajo, aproveche esta oportunidad y aprenda de su colega. La próxima vez, hagan un diseño juntos, intenten captar sus secretos, sus pensamientos. La programación es como un oficio, se aprende haciendo y observando a otros hacerlo.

2. Las habilidades de diseño en su mayoría vienen con experiencia y después de leer algunos libros importantes. Te recomendaría lo siguiente:

   • Robert C. Marting - Principios, patrones y prácticas ágiles (hay 2 versiones, una en Java y otra en C #. No importa cuál elija, las ideas y los principios pueden aplicarse a cualquier objeto orientado - y no solo - código fuente)
   • Than, Robert C. Marting tiene otros 2 libros interesantes: Clean Code y The Clean Coder
   • Incluso si Martin cubre todos los patrones de diseño moderno en su primer libro, desea buscar el libro de patrones de diseño original de la banda de los cuatro.
   • Finalmente, hay otros libros que son muy apreciados hoy en día: software orientado a objetos en crecimiento guiados por pruebas, o refactorización por M. Feathers (creo), o escritura de casos de uso efectivo por A. Cockburn y algunos más que descubrirás en el camino.

Ninguno de estos libros es una bala mágica, pero leer las 2 primeras recomendaciones probablemente cambiará tu visión y percepción sobre la programación para siempre.

No dejes que te afecte. Si tiene años de experiencia corrigiendo errores y haciendo pequeños programas, eso es lo que usted mejorará. Su compañero de trabajo probablemente tenga años de experiencia en el diseño de proyectos más grandes.

Estar familiarizado con los bits subyacentes es increíblemente útil, pero si quieres mejorar en el diseño, tendrás que diseñar algunos proyectos. Repite hasta que la habilidad se hunda.

En resumen, "años de experiencia" no siempre es equivalente. Ve y haz que tus años valgan la pena.

"Mejorarse" a menudo implica medir sus diseños o código contra algo / alguien mejor, comparar cuidadosamente lo que es diferente, aprender de esas diferencias e intentar mejorar continuamente sus futuros diseños basados en eso. Sentirse tan mal por descubrir que necesita aprender más ralentizará este proceso beneficioso. Si se muda a un lugar donde no haya personas (u otros recursos) que a veces o siempre puedan ofrecerle una mejor comparación, puede perder esta oportunidad de aprender y ralentizar su proceso de apuestas.