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

He estado programando durante un par de años y, en general, soy bueno cuando se trata de solucionar problemas y crear scripts pequeños a medianos, sin embargo, generalmente no soy bueno para diseñar programas a gran escala en forma orientada a objetos. Pocas preguntas

1. Recientemente, un colega que tiene la misma cantidad de años de experiencia que yo y yo estábamos trabajando en un problema. Estuve trabajando en un problema por más tiempo que él, sin embargo, él encontró una solución mejor y al final vamos a usar su diseño. Esto realmente me afectó. Admito que su diseño es mejor, pero quería crear un diseño tan bueno como el suyo. Incluso estoy considerando renunciar al trabajo. No estoy seguro de por qué, pero de repente me siento bajo presión, por ejemplo, ¿qué pensarían los juniors de mí, etc.? ¿Es normal? ¿O estoy pensando demasiado en esto?

2. Mi trabajo consiste en programar en Python. Intento leer el código fuente, pero ¿cómo crees que puedo mejorar mis habilidades de diseño? ¿Hay algún buen libro o software que deba estudiar?

Por favor iluminame. Realmente apreciaré tu ayuda.

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

Tienes dos puntos fuertes realmente sorprendentes (y sorprendentemente poco comunes):

• Eres capaz de evaluar tus diseños frente a otros de manera objetiva
• Tienes el deseo y el esfuerzo para hacer que tus diseños sean óptimos

Solo llevas un par de años y tienes un largo camino por recorrer, pero con esta actitud definitivamente llegarás, simplemente no te rindas; Todos lidiamos con problemas mentales como este. Cada vez que tengo la oportunidad, me gusta conectar los Principios de diseño (NO lo mismo que los patrones de diseño) y creo que este es un ejemplo perfecto de dónde son útiles. Estudie y practique aplicarlos en sus diseños, lo hará antes de darse cuenta de que ha dado un paso más en este sentido.

Al final del día recuerda, diseñar es difícil. Estamos lidiando con complejas abstracciones de alto nivel todos los días, crearlas de la nada, hacer que funcionen bien y que los colegas puedan usarlas fácilmente es una tarea extremadamente difícil. Se necesita práctica, por años .

Así que anímate y recuerda: hay un montón de gente por ahí que no puede evaluar dos diseños y realmente reconoce uno como preferible sobre otro, ¿qué tan bien crees que se llevan bien en la creación de buenos diseños?

Editar:
'otro consejo, después de entender los principios y practicar un poco su aplicación, creo que hay otra joya de otra pregunta aquí que habla sobre el valor de estudiar una variedad de idiomas que tienen diferentes propósitos y reglas:

Idealmente, cada programador debe saber un idioma de cada clase. ¿Qué podrías aprender?

1. Un lenguaje convencional de 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 software altamente paralelo).

Un lenguaje de programación lógica (Prolog) probablemente no sea tan útil en la industria, ya que se usa 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 presenten diseños de diferente calidad. En el pasado me invitaron a juzgar las competencias en diseño de software, así que fui testigo de primera mano: incluso los diseños más simples dieron como resultado soluciones de calidad drásticamente diferente, todas provenientes de personas inteligentes y experimentadas.
2. La lectura del código fuente tiene un nivel 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 mirando los concursos 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 o dos horas 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, descubra 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 usted, para que pueda aprender de él o ella.

Mire el mejor diseño y determine por qué es mejor. APRENDA del diseño aceptado y piense en formas en las 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é se equivocó al no 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 que puedes hacer es crear diseños, luego ser brutal contigo mismo al evaluarlos y determinar cómo se pueden mejorar. Hágase preguntas como: ¿Funcionará y cumple con el requisito en todos los aspectos? ¿Es mantenible? ¿Cómo podré probar esto? ¿Causará problemas de rendimiento? ¿Qué tan probable es que el requisito cambie y qué tan bien será el diseño? ser capaz de manejar el cambio. Lea sobre los patrones de diseño y luego intente aplicarlos a sus diseños. Refactorice sin piedad después de idear un diseño inicial. Si está diseñando una base de datos junto con la aplicación, lea ampliamente sobre 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 SECO y SÓLIDO al hacer su diseño. Lea sobre los antipatrones para saber qué cosas debe evitar hacer.

Reconocer un mejor diseño es una habilidad importante. Debes fomentar esto mientras sigues algunas de las sugerencias anteriores con respecto a mirar diseños.

¿Con qué criterio juzgó mejor el otro diseño? ¿Fue más simple y fácil de entender? ¿Proporcionó una ventaja de rendimiento? ¿Fue más extensible? Existen muchos principios de diseño, como la descomposición, la abstracción, el ocultamiento de la información y la modularidad de los componentes que puede usar para juzgar los diseños y que quizás ya reconozca.

• Intente nombrar sus criterios, comprenderlos, expandirlos y reutilizarlos mientras observa otros diseños. Cuando diseñe cosas usted mismo, haga parte de su proceso usar esos criterios y medir conscientemente sus diseños contra ellos. Luego, prepárese para modificar o desechar por completo su diseño si no cumple con sus criterios.

Obtendrá ideas sobre diferentes principios para diseños de algunas de las siguientes fuentes: http://www.cs.wustl.edu/~schmidt/PDF/design-principles4.pdf Diseño de software en wikipedia Google "Principios de diseño de software"

• Comprender diferentes modelos para el diseño de software, como el diseño orientado a objetos o el diseño funcional o el diseño de análisis estructurado. Estas pueden ser mentalidades completamente diferentes para abordar una tarea de diseño y cada una tiene áreas en las que se destacan. Aprenda esto como herramientas para su caja de herramientas. http://userpages.umbc.edu/~khoo/survey2.html

• 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 detalles de implementación de los principios de diseño de nivel superior. Y para desarrollar su "ojo de diseño" y sus habilidades de comunicación.

• Por último, pero quizás lo más importante, leer ampliamente es una herramienta muy buena: hay muchas cosas interesantes, desde fractales hasta análisis bayesianos, desde lógica difusa hasta procesamiento de lenguaje natural, que pueden proporcionar forraje para ideas que surgirán más tarde e inesperadamente. Con la web puede examinar temas a lo largo y ancho, solo para su diversión y edificación, y se beneficiará. No necesita convertirse en experto, solo familiarizarse con los términos y las 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 desea aprender y mejorar.

El segundo paso es analizar. Mire su trabajo y no solo diga que es mejor; Averigua por qué es mejor. Busque detalles específicos y puntos que hizo mejor.

Una vez que comprenda eso, extraiga 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. Le impide tratar alguna idea útil como un martillo dorado , incluso en casos inapropiados).

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

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

Apuesto dinero a que TÚ puedes hacer algo mejor que tu compañero de trabajo. No para crear una combinación de meadas ni nada (¿Puedes hacer Y mejor? ¡Jódete, puedo hacer X mejor!), Sino 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 comandos que ellos, y puedo automatizar cosas que los dejan en el polvo.

¿Son mejores que yo? En alguna área definitivamente. Demonios, en muchas áreas lo son: soy el desarrollador junior en mi tienda por mucho 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 centrarte en el hecho de que alguien es mejor en X que tú. Esa persona, sin intentarlo ni siquiera pensar en ello, podría ser capaz de diseñarlo incluso después de practicarlo durante los próximos 10 años. No es que no deba trabajar para solucionar sus debilidades, pero recuerde que para cada fortaleza hay una debilidad.

Concéntrese en ambos, 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 es un natural. Deberías felicitarlo sinceramente y aprender todo lo que puedas de él.

No deje que los profesionales se pongan celosamente entre usted y la oportunidad de aprender.

1. Un par de años realmente no es tanto. 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ños de alto nivel como cohesión y dependencias. Sin embargo, este no es un estado de facto. Ambos pueden mejorar en el diseño de nivel superior (leer algunos libros, probar algunos trucos en casa, etc.) y también pueden descubrir que en otras áreas de programación su programador compañero es menos bueno. Además, si cree que tiene 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, intenta atrapar sus secretos, sus pensamientos. La programación es como un oficio, se aprende haciendo y viendo 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 principios se pueden aplicar a cualquier objeto orientado, y no solo - código fuente)
   • Entonces, 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 The Gang of Four.
   • Finalmente, hay otros libros que son muy apreciados hoy en día: software orientado a objetos en crecimiento guiado 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á en el camino.

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

No dejes que te afecte. Si tiene años de experiencia solucionando errores y creando pequeños programas, en eso se destacará. Su compañero de trabajo probablemente tenga años de experiencia diseñando proyectos más grandes.

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

En resumen, "años de experiencia" no siempre es equivalente. Ve a hacer que tus años valgan algo.

"Mejorar" a menudo implica medir sus diseños o códigos con respecto a algo / alguien mejor, comparar cuidadosamente las diferencias, aprender de esas diferencias y tratar continuamente de mejorar sus diseños futuros basados ​​en eso. Sentirse demasiado mal al descubrir que necesita aprender más ralentizará este proceso beneficioso. Si se muda a un lugar donde no hay personas (u otros recursos) que a veces o siempre pueden proporcionarle una mejor comparación, puede perder esta oportunidad de aprender y ralentizar mejor su proceso de apuestas.