¿Debo usar técnicas avanzadas la mayor parte del tiempo en mi nuevo trabajo solo porque puedo? [cerrado]

7

En pocas palabras, soy nuevo en la empresa, debería escribir técnicas avanzadas con template s, std técnicas ... etc. para causar una buena primera impresión y dejar que mis colegas confíen / queden impresionados con mi ¿Debo trabajar o debo preocuparme más por escribir un código estándar más sólido / basado en cada problema actual que deba resolverse?

    
pregunta Vinícius Magalhães Horta 04.01.2016 - 02:32

4 respuestas

41

Absolutamente no.

Si se uniera a mi equipo y pasara todo el tiempo utilizando técnicas más avanzadas que las necesarias para la tarea en cuestión, sin duda quedaría muy impresionado. Estarías haciendo más difícil leer, entender y mantener el código ... no solo para tus compañeros de equipo, sino también para ti. ¿Y por qué razón? ¿Presumiendo? No está bien.

¡Aunque al menos me harías más fácil encontrar contenido para tu primera revisión de rendimiento!

La forma de impresionarme es usar la herramienta adecuada para el trabajo. Si surge un problema que se resuelve mejor con una "técnica avanzada", y usted es capaz de ofrecer tal solución de tal manera que la estabilidad del código y la capacidad de mantenimiento no se vean comprometidas, entonces estaría impresionado.

Sin embargo, para ser claro, el uso de plantillas y de las instalaciones estándar de la biblioteca no es "avanzado". Requiero que cualquiera que se una a mi equipo de C ++ esté familiarizado con esto como una cuestión de rutina.

    
respondido por el Lightness Races in Orbit 04.01.2016 - 02:39
12

Como un descargo de responsabilidad, aquí interpreto "avanzado" como no como una plantilla de clase básica para una estructura de datos o una plantilla de función para un algoritmo genérico que ingresa a los iteradores. Esto no parece ser un territorio espectacular a menos que esté entre un equipo de personas que no saben cómo usar C ++. Estoy asumiendo cosas como, por ejemplo, plantillas de clase de política que permiten combinaciones infinitas en políticas cuando solo una combinación es realmente útil: soluciones exóticas que van más allá de lo normal ... tal vez incluso más avanzadas que las clases de política: cosas sin nombre todavía que las personas nunca antes visto, trucos que utilizan el lenguaje que nunca se han aplicado en el código de producción.

Noooooooooooo!

El sello distintivo de un desarrollador experimentado no es aquel que aplica metatemplates recursivos para crear algo parecido a un DSEL básico para resolver una tarea de rutina. Eso es programación de la masturbación: es mejor guardarlo para proyectos de chatarra para entender mejor cómo funciona el lenguaje o al escribir un libro sobre cómo explorar los límites más profundos de un lenguaje de programación.

Ni siquiera proviene de un mecanismo elaborado para reemplazar 3 líneas de repetitivo sencillo en 50 archivos fuente con 1 línea de código. En todo caso, la experiencia le entusiasmará inicialmente con estas soluciones solo para, con el paso de los años, volver a la solución sencilla cuando se da cuenta de que la capacidad de mantenimiento se ha degradado en lugar de mejorar al ser tan elegante.

Una de las métricas ocultas clave de la capacidad de mantenimiento que no se discute con tanta frecuencia es la "familiaridad". El código exótico es un código desconocido, y probablemente no lo sea incluso para usted mismo después de que haya pasado un tiempo al volverlo a visitar. Esta es la razón por la cual el código idiomático es tan valioso: mejora la capacidad de mantenimiento al mejorar la familiaridad. Estamos saturados por el código idiomático, por lo que tiende a permanecer siempre familiar. "Exótico" es el polo opuesto, y suele estar acompañado por un deseo de remodelar el lenguaje de programación que se está utilizando en lugar de abrazar sus fortalezas y aceptar sus debilidades.

Las plantillas pueden ser formas maravillosas y directas de lograr abstracciones en tiempo de compilación sin penalización de tiempo de ejecución, y algunas veces incluso se usan adecuadamente en un contexto recursivo o similar a DSEL para algo que el lenguaje sería increíblemente inepto de manejar. Supongo que cuando dices "avanzado", es para usar plantillas de una manera muy inusual. Pero abrazados demasiado rápido, pueden terminar rápidamente contrarrestando los objetivos para los que estaban destinados a cumplir: pueden convertirse en una macro elaborada.

Si desea impresionar a las personas, use la solución más simple, idiomática y directa que pueda obtener: cuanto menos exóticas, mejor. A veces, habrá secciones en una base de código que tienen una demanda inusualmente compleja en la que tenemos que romper con la norma. Sin embargo, la clave aquí es hacer esto con moderación, a regañadientes, para no aplicar soluciones complejas para tareas simples. La solución a nivel de genio es encontrar una solución simple y simétrica para una tarea aparentemente muy compleja; esto suele ser muy difícil, pero no es tan difícil evitar aplicar soluciones complejas para tareas simples.

Mientras esto es C en lugar de C ++, revisa el kernel de Linux. Está escrito de la manera más asombrosamente directa dada la combinación de complejidad y la naturaleza crítica de lo que está haciendo, sin embargo, está organizado de manera lógica y mejor que algunas bases de código básicas que están haciendo cosas mucho más simples. Tome este tipo de fuentes de simplicidad y sencillez como inspiración y como una manera de impresionar a sus colegas.

Es genial entender técnicas realmente avanzadas como las complejidades de SFINAE, pero guarda ese conocimiento avanzado para los problemas más avanzados donde las soluciones avanzadas terminan siendo las soluciones más elegantes y directas.

    
respondido por el user204677 04.01.2016 - 06:23
3

A veces, el ambiente es conservador o simplemente no está abierto a hacer las cosas de otra manera, a lo que la gente está acostumbrada y, por lo tanto, se siente cómoda. Luego, se encontrará con la oposición cada vez que se salga del camino que conocen sus compañeros de trabajo y le lanzarán un razonamiento falso por no utilizar una técnica en particular en lugar de intentar ponerse al día y aprender algo nuevo. No hay una manera estándar de lidiar con eso. A veces es mejor simplemente hacerlo y dejar que los resultados hablen por sí mismos, otras veces es mejor no mover el bote demasiado y dejar que todos se acostumbren al nuevo tipo primero, para obtener algo de crédito, aceptación y disposición. Es más un reto social que técnico.

    
respondido por el Martin Maat 04.01.2016 - 05:38
2

Es fácil decir: "No, no hagas eso" o "simplemente escribe un código que se pueda mantener". Es fácil asumir que cualquier programador en su sano juicio gravitará hacia la misma solución obvia, simple y hermosa. Pero estoy aquí para decirte que es una tontería. La complejidad (si podemos llamarlo así) de cualquier proyecto está determinada por una dinámica difícil de definir que incluye la cultura institucional, la cultura del lenguaje de programación, los gustos individuales, los gustos de la comunidad y los cambios en todas esas cosas a lo largo del tiempo. En pocas palabras, lo que es obvio hoy no fue obvio ayer y no será obvio mañana. Para mí, eso significa que la forma obvia de hacer las cosas no lo es.

A modo de ilustración, realice una práctica como DI . Cuando empecé a trabajar en grandes proyectos, DI no existía. Entonces, de repente, estaba en todas partes. Estaba confundido. ¿Por qué agregar una capa de direccionamiento indirecto al código directo? Donde antes era fácil seguir las dependencias de implementación a implementación, ahora tenía que navegar a una interfaz y averiguar con qué implementación concreta estaba tratando. No fue obvio. Pero ... tenía sus beneficios. Hizo las pruebas más fáciles y, con un poco de suerte, creó un cambio en el pensamiento que convirtió las pruebas en una preocupación principal. Por lo tanto, me gusta DI. Pero decir que es obvio y simple es una media verdad. Es obvio y simple dados ciertos objetivos (capacidad de prueba, programación a una interfaz) pero no es obvio y simple para un programador nuevo.

Como un ejemplo menos empresarial, mire el código fuente de Lua versus el código del kernel de Linux. Ambos proyectos están muy preocupados por la simplicidad y el rendimiento y, sin embargo, ambos proyectos se ven muy, muy diferentes. ¿Cómo puede ser eso si todos los buenos programadores llegan a la misma solución simple? (Le aseguro que ambos proyectos disfrutan del esfuerzo de los programadores excelentes . Personalmente, encuentro que la fuente de Lua es inspiradora y encantadora).

Lo que esto significa para usted es que es imposible para nosotros decir si debería o no debería utilizar técnicas "avanzadas". Realmente depende de tu equipo y de tu proyecto. Lo que está avanzado para un equipo no es para otro. Preste mucha atención durante la revisión del código. (Usted tiene revisiones de código, ¿verdad?) Si un miembro del equipo o dos comentan que su código es un poco complicado, procese sus comentarios e intente hacer que su código sea "localmente idiomático". Si lo estás haciendo bien, debería ser difícil saber quién escribió qué código en un proyecto. Si no se siente bien, puede que el proyecto o el equipo no sean para usted.

    
respondido por el Scant Roger 04.01.2016 - 14:31

Lea otras preguntas en las etiquetas