¿Cómo dar un paso atrás y mirar el código con nuevos ojos? [cerrado]

53

He pasado el último año como equipo de un solo hombre desarrollando una aplicación de cliente enriquecido (más de 35,000 LoC, por lo que vale). Actualmente es estable y en producción. Sin embargo, sé que mis habilidades estaban oxidadas al inicio del proyecto, así que sin duda hay problemas importantes en el código. En este punto, la mayoría de los problemas están relacionados con la arquitectura, la estructura y las interacciones: los problemas fáciles, incluso los problemas de arquitectura / diseño, ya se han eliminado.

Desafortunadamente, he pasado tanto tiempo con este proyecto que me cuesta mucho pensar fuera de él: abordarlo desde una nueva perspectiva para ver los defectos profundamente ocultos o inherentes al diseño.

¿Cómo me salgo de mi cabeza y fuera de mi código para poder obtener una imagen nueva y mejorarla?

    
pregunta BenCole 06.09.2012 - 16:18

12 respuestas

46

Formas de abordar esto:

  • Encuentre a alguien que esté familiarizado con la tecnología y el problema empresarial y coméntelo. Esto puede ser difícil en un equipo de una sola persona, pero generalmente es la mejor opción.
  • Trabaja en un proyecto diferente por un tiempo. Esto también puede ser difícil, pero incluso tomar un descanso de una semana puede darle una nueva perspectiva.
  • Observe proyectos o productos similares, como productos de código abierto, si los hay. Tenga cuidado de no copiar el código, pero es posible que hayan abordado la idea de manera completamente diferente.
  • Aprenda un nuevo idioma, biblioteca o marco. Las técnicas involucradas pueden darle una idea de cómo abordar los mismos problemas que tiene de manera diferente.
  • Lea un buen libro / blog / revista sobre diseño o el idioma / marco. No estoy seguro del nivel de habilidad en el que se encuentra, pero hay muchas alternativas en otras respuestas en este sitio.

Si tiene ejemplos específicos que quiere abordar, quizás publíquelos aquí.

    
respondido por el akton 06.09.2012 - 16:25
13

Depuración de patas de goma : Siéntese con un código o un módulo o un Presentar y explicar, en voz alta. Cuando te encuentres diciendo algo que suena mal, tonto o simplemente no está bien, escríbelo como un problema para investigar.

    
respondido por el Freiheit 06.09.2012 - 18:50
9

Sigue aprendiendo y ampliando tus habilidades. Es difícil saber lo que no sabes, pero cuando lo veas, ese momento "aha" te llegará. Podría provenir de aprender otro idioma o patrón de diseño.

Se te pedirá que hagas un cambio. Es posible que encuentres partes de tu código que no sean tan flexibles y que requieran una gran cantidad de trabajo. Esto no es necesariamente un fracaso porque al principio no puedes pensar en todo.

Los usuarios comenzarán a quejarse. Justo cuando crees que todo es genial ...

    
respondido por el JeffO 06.09.2012 - 16:32
7

Una memoria corta ayuda. Se me ha dicho que me quejé del "idiota" que cambió algo hace una semana, solo para encontrar en el control de origen que era yo.

Un buen primer paso es identificar el código que podría mejorarse. Busque en su control de código fuente los archivos que cambian con mayor frecuencia. ¿Con qué código es más difícil trabajar? ¿Qué código produce la mayoría de los errores? ¿Qué tipo de cambios causan un efecto dominó en todo el código? En esta etapa, no tiene que saber por qué el código es problemático, solo eso es problemático.

Una vez que haya identificado las áreas en las que debe trabajar, intente averiguar cuál es realmente el problema. Hay libros que adoptan un enfoque sistemático para clasificar los problemas de diseño. Mire Refactoring de Martin Fowler, C ++ Coding Standards de Herb Sutter, Clean Code de Robert Martin, etc. Tienen un montón de "reglas" que permiten mira su código de una manera objetiva.

Una vez que haya identificado cuál es el problema más probable, intente diferentes maneras de solucionarlo. Por ejemplo, si la regla que rompió es "prefiera la composición a la herencia", cámbiela por composición y vea cómo se siente.

Obviamente, puede ser útil que otra persona vea el código, pero no siempre es tan útil como podría pensar, porque está mucho más familiarizado con los tipos de problemas que causa el código que nadie más, y las razones detrás del diseño. Aprender algunas formas de evaluar objetivamente su propio diseño pagará grandes dividendos.

    
respondido por el Karl Bielefeldt 06.09.2012 - 17:03
4

Haz que otra persona mire tu código. Si no puede encontrar a otra persona para que lo vea, escriba una descripción completa de la interacción como si se la mostrara a otra persona. El proceso de tratar de explicar sus decisiones a otra persona (incluso si es solo para practicar) puede ayudarlo a pensar realmente POR QUÉ está haciendo las cosas de cierta manera y ayudarlo a ver cualquier agujero en su lógica.

    
respondido por el Ben McCormick 06.09.2012 - 16:27
4

Conozco muy bien esta situación. Cuando me quedo atrapado de esa manera, trato de tomar diferentes puntos de vista sobre el proyecto.

1.) Punto de vista del usuario / cliente: utilizar comentarios

Desafortunadamente, estamos atrapados en nuestro código de una manera que no podemos ver nuestros propios defectos porque usamos nuestras aplicaciones de la manera que las hemos codificado. Observe cómo lo usa la gente y trate de averiguar cuál sería la guía de usuario más intuitiva. Juega un poco con prototipos de interfaz de usuario. Esto parece ser divertido, pero si descubre que se vería obligado a recodificar grandes partes de su código simplemente cambiando la lógica de uso, es hora de comenzar un ciclo de rediseño.

2.) Haga un análisis funcional de su código y visualícelo

Algunos IDE y marcos te empujan a, por ejemplo, mezcla de interfaz de usuario y código de backend. Si deja que esto suceda, algún día enfrentará la situación de que su base de código difícilmente se puede mantener debido a las dependencias nebulosas y difíciles de romper. Especialmente mezclar código UI con otro código puede llevar a código spaghetti y funcionalidad redundante. Divide tu código en bloques funcionales como, por ejemplo, clases de base de datos, clases de comunicación, clases de UI, clases principales, etc. y asignan nombres a los bloques de funciones. Luego visualice la funcionalidad con una herramienta gráfica (yo uso una herramienta de mapeo mental) para descubrir si su estructura es lo suficientemente lógica y modular como para poder reutilizar grandes bloques de código para diferentes proyectos y puede reemplazarlos con versiones más nuevas sin gran dolor.

La mejor manera de hacer esto en mi experiencia es crear un documento que visualice todas las dependencias entre sus clases y sus llamadas desde su código. El resultado es una visualización de su diseño de interfaz. Si este mapa de código parece un clusterf *** completo, es hora de actuar. Si aún no ha sucedido, debe pensar en una convención de nomenclatura adecuada que represente la estructura de su código de una manera que no tenga que pensar en cómo llamarlo y en qué hace.

3.) Utilice enfoques comunes para el control de calidad

Mi favorito es el FMEA. En términos de codificación, esto significa no solo analizar lo que salió mal en el pasado sino también pensar en lo que podría salir mal. Un ejemplo bastante común es una conexión de red caída repentinamente. Una vez que haya hecho esto, puede clasificar las condiciones de error por consecuencias como pérdida de datos, bloqueo, cálculo incorrecto y juzgar el impacto en el usuario. Si aún no lo ha hecho, la definición de errores simplificados y las clases y rutinas de excepción puede ayudarlo a mantener su código limpio y directo. La mejor manera es implementarlas en cada nueva tranquilidad de código antes de comenzar a escribir cualquier otra cosa. (Bueno, soy culpable de no seguir siempre este consejo).

Además, me ayudó a generar y actualizar con frecuencia una "lista de propuestas de mejora" para mi propio código. (Para ser honesto, todavía hay mucho código en mis proyectos del que no estoy orgulloso). También trato de tomarme el tiempo para recopilar y echar un vistazo al código de mejores prácticas de las documentaciones de API, las conferencias de desarrolladores o las revistas de desarrolladores.

Hasta este punto no es necesario que toque su código. Se trata simplemente de saber qué está mal y encontrar una manera de definir cómo mejorar su código.

Finalmente, algunos consejos para el trabajo diario de un viejo pedo. Intenta evitar morder más de lo que puedes comer. Esto conduce a demasiada presión para una codificación limpia. Rara vez tienes tiempo para hacerlo bien, pero tendrás que tomarte el tiempo para corregir los defectos después.

Nada es tan duradero como la solución provisional, pero cuando se rompe, a menudo es demasiado tarde para solucionarlo a tiempo. Los ejemplos son hacks desagradables o extrañas excepciones que solía hacer que algo funcionara, p. Ej. una falla en el marco subyacente o sistema operativo. Y luego se solucionó el error o la nueva versión simplemente elimina la API ...

Si está atascado y se ve obligado a encontrar una solución alternativa, haga comentarios y tome notas que deberían revisarse de vez en cuando. Normalmente nos mejoramos y mejoramos por aprender algo nuevo. Si encuentras una manera mejor implementarla tan rápido como puedas. De lo contrario, es posible que se encuentre codificando la solución para la solución y la excepción de la excepción algún día. (El que está sin pecado entre vosotros, que me lance el primer byte).

    
respondido por el sacristan 23.12.2012 - 00:41
2

No te preocupes por las cosas pequeñas.

Todo el mundo podría codificar mejor. Hacemos las cosas rápido y luego nos damos cuenta de que, un par de semanas después, se podría haber hecho de manera más eficiente. El punto es que el 90% de tu código es probablemente lo suficientemente bueno.

Revise sus registros de errores y encuentre las rutinas que podrían estar causando problemas. A medida que encuentre los errores, también puede revisar el código y pensar en qué podría hacer que el código sea más eficiente. La mayoría de las veces, se dará cuenta de que, más allá de corregir el error en sí, no podrá realizar una mejora notable, pero a veces, se dará cuenta de que hay una mejor manera de hacer algo.

Hable con los usuarios y vea dónde están notando problemas, ya sea de UX o de velocidad. Solucione estos problemas, con la intención de mejorar su código.

En algún momento, descubrirá que su código se ha vuelto demasiado frágil y que simplemente no hay manera de hacer los cambios que necesita hacer. Luego piense en cómo podría haber hecho que el sistema fuera más flexible, ya sea a través de API o de desarrollo basado en pruebas. En muchos casos, descubrirá que puede comenzar a poner estas API en el código, sin una gran cantidad de cambios. En otros casos, te darás cuenta de que el esfuerzo por mejorar el código no vale la pena.

Los cambios incrementales pueden ser difíciles. El objetivo es no volver a escribir completamente la base del código si no es necesario. Claro, usted es un mejor programador ahora que hace un año, pero lo que tiene debe estar funcionando ahora mismo. Dentro de 5 años, cuando un programador junior se queje con usted sobre el código heredado que tienen para intentar solucionar, solo sonría y asiente, y no admita que lo escribió.

    
respondido por el Brian Hoover 06.09.2012 - 17:41
1

¿Has considerado irte y encontrar una empresa donde puedas estar en un equipo? Creo firmemente que, aislado o en un equipo estancado, los desarrolladores se pierden mucho de lo que la profesión tiene para ofrecer.

Las revisiones por pares permiten que alguien que ya está fuera de tu cabeza te dé un consejo. La Revisión del Código de Intercambio de Pila puede ser un buen lugar para poner en revisión un código que no es particularmente propietario de su compañía. Es probable que no pueda manejar bloques grandes, pero muchos programas están hechos de muchos códigos simples y otros códigos que no son simples y crean muchos problemas. Si tiene un ejemplo de un código que es típico, pero se repite y modifica muchos lugares, también podría ser un buen candidato para la revisión. Por ejemplo, si da formato a los mensajes, no solicite que se revise todo el paso del mensaje, solo un mensaje de ejemplo bastante complejo.

Si desea ser más objetivo con respecto a su propio código, supongo que podría compararlo con un estándar de codificación, ejecutar comprobadores de código estáticos o dinámicos en él, o si está poco documentado, agregar comentarios podría ayudar.

Hay una psicología de pruebas que dificulta la prueba de su propio código, pero ciertamente hacemos todo lo posible para hacerlo durante la prueba de unidad. Leer su propio código puede ser un problema similar o peor. Muchos campos utilizan mentores, jueces competitivos, entrenadores, etc. Nuestro también lo hace si cuenta con arquitectos, ingenieros de sistemas y evaluadores. Los clientes con acceso a una herramienta de informe de errores o al departamento de atención al cliente le enviarán comentarios desde fuera de su cabeza una vez que el producto esté en el campo. Esta es otra gran razón para el enfoque de Agile de lanzar temprano y con frecuencia. Puede que seas el único desarrollador de tu empresa, pero hay personas afectadas por tu código que pueden darte tu opinión desde algún ángulo.

    
respondido por el DeveloperDon 03.10.2012 - 05:41
0

"¿Es este un problema menor de lo que creo que es, o es un problema que otros también experimentan?"

Sheesh. Basta ya. Si el código está en producción, libre de errores y haciendo lo que se supone que debe hacer, la arquitectura no es importante. Al menos por ahora.

Esperamos que todos aprendamos sobre la marcha. He escrito muchos códigos de los que estaba orgulloso en el momento en que lo escribí, solo para decidir que fue horrible uno o dos años después. En este momento estoy trabajando en un proyecto de varios años que está lleno de código increíblemente crufty, pero el código funciona. Estoy tomando un enfoque muy conservador para tocar cualquiera de ellos.

Y tú también deberías. Si no ve ningún problema arquitectónico importante en este momento, después de un año de trabajo, creo que puede ser seguro suponer, por ahora, que no hay problemas importantes. Esto no es mala artesanía. Está avanzando.

    
respondido por el user75772 23.12.2012 - 02:49
0

Además de otras respuestas, recomendaría ir a una conferencia de desarrolladores.

Esto te expondrá a muchos temas y personas que te harán pensar en tu propia aplicación y lugar de trabajo. Especialmente porque hablarán sobre lo que funciona y no para entonces, y los problemas que surjan. Existe una gran probabilidad de que haya alguna superposición con su aplicación.

Preferiblemente, tome 3 días para esto. Descubrí que es lo suficientemente largo como para obtener la distancia mental necesaria para mi propio trabajo y verlo a través de los ojos de una comunidad más grande (por así decirlo) en lugar de la mía.

Por cierto, esto también se aplica a equipos de personas, ya que el pensamiento grupal puede ocurrir en cualquier lugar.

Finalmente, si no obtiene la aprobación para esto, digamos una vez al año, cambie de trabajo.

    
respondido por el Macke 23.12.2012 - 20:27
-1
  • Practicar patrones de diseño y mejores prácticas
  • Elija un marco, herramientas, paquetes, etc. en función de los requisitos y las necesidades de su aplicación, para esto necesita leer muchos blogs de etch y encontrar soluciones para cada problema de tecnología individual
  • Cree un borrador de diseño / arquitectura y discútalo con alguien que sea bueno en temas técnicos / arquitectónicos. Mejorar este borrador utilizando comentarios y comentarios. sigue haciendo esto hasta que alcances un estado estable.
  • Implemente un código tal que todo lo que la aplicación necesita se pueda configurar y mantener

    la nueva arquitectura y la reimplementación de su proyecto sin duda darán como resultado que la aplicación tenga mejor consistencia, rendimiento, etc.

respondido por el Murali Mopuru 08.09.2012 - 20:35
-1

Creo que ayudar a 'preocuparse' de algunas personas inteligentes. Tiene que haber información específica. ¿Es el sitio web 24x7x365? ¿LoB app? ¿Dónde se está ejecutando o está alojado?

Una vez que te metes en los objetivos centrales y los resultados deseados, otros pueden ayudarte a enfocarte y dirigir tu atención. Su código podría ser el mejor código que se haya escrito para una tarea específica, o lo peor. Realmente no importa, ¿cómo afecta eso al objetivo deseado?

    
respondido por el user75800 23.12.2012 - 14:00

Lea otras preguntas en las etiquetas