Al mirar una nueva base de código, me gusta comenzar desde un enfoque ascendente.
Donde comprendo un archivo y luego paso a la siguiente abstracción.
Pero muchas veces me encuentro olvidando lo que está haciendo la abstracción de nivel inferior.
Así que estaré en este punto en el que me encuentro en un ciclo casi interminable de volver a los archivos que anteriormente había comprendido completamente y luego tratar de volver a aprenderlos; mientras trataba de hacer malabarismos con muchas otras abstracciones que se conectan entre sí en mi cabeza.
¿Existe una mejor estrategia para enfrentar esta situación?
¿Debo olvidarme de los detalles de nivel inferior y tomarlos como un hecho? Pero incluso entonces, muchas veces se necesita una comprensión previa de la abstracción de nivel inferior para comprender lo que está haciendo la abstracción actual.
fuente
Respuestas:
La programación concreta es el impulso de atraer detalles hacia usted para que pueda clavarlos en un solo lugar. Todos comenzamos de esta manera y es difícil dejarlo ir.
La programación abstracta es definitivamente "olvidarse de los detalles de nivel inferior". A veces incluso detalles de alto nivel. Alejas los detalles y dejas que algo más se ocupe de ellos. Lo astuto es que has estado haciendo esto todo el tiempo. ¿Realmente entiendes lo que sucede
print "Hello world"y se muestra en tu pantalla?La cosa número uno para exigir mientras luchas por soltar estos detalles son los buenos nombres. Un buen nombre asegura que no te sorprendas cuando mires dentro. Es por eso que no le sorprendió que
printpusiera algo en su pantalla y realmente no le importaba cómo.foo "Hello world"Hubiera sido una historia diferente.Además, los niveles de abstracción deben ser consistentes. Si está en un nivel que consiste en calcular pi, no debería preocuparse por cómo mostrar pi. Ese detalle se ha filtrado en una abstracción a la que no pertenece.
Los detalles más bajos, más altos o laterales, que no se refieren a lo que estoy pensando en este lugar, pueden desaparecer por completo o al menos esconderse detrás de un buen nombre.
Entonces, si realmente está luchando rebotando de un archivo a otro, apostaré a que alguien lo ha atrapado con malos nombres o abstracciones con fugas.
Arreglo esto leyendo con mis dedos. Una vez que tengo pruebas decentes sobre este desastre, separo las responsabilidades, les doy nombres claros para evitar sorpresas y se lo muestro a otra persona para asegurarse de que no estoy viviendo en un mundo de fantasía.
Aparentemente no estoy solo cuando se trata de trabajar de esta manera:
fuente
En la parte inferior, hay algunas actualizaciones de cómo me fue cada trimestre del año, creo que son valiosas.
Buen nombre. O, si se trata del código de otra persona, tratar de atribuir buenos nombres / responsabilidades en función incluso de los malos nombres en las clases / funciones de ese sistema, por lo que tiene sentido en mi cabeza. Una vez que lo hace, las implementaciones de bajo nivel se vuelven mucho más fáciles de recordar.
Eso es todo lo que tengo. Hay muchos puristas en este sitio que juran por Dios que sabe qué patrones u objetos de cualquier tipo, pero un buen nombre lo llevará lejos. He hecho más que bien por mí mismo al crear código mínimamente documentado / bien nombrado / bien desacoplado y nunca volvió a morderme, incluso si mi código fue utilizado en muchos lugares, por muchas personas, pero el Una cosa que hice bien fue perder mucho tiempo en buenos nombres, buenos comentarios y esquemas que explicaran el flujo de mi código. La implementación de bajo nivel es necesaria para entender si desea expandir mi código de manera profunda. El código bien escrito puede expandirse de manera razonable, por lo tanto, está bien que alguien o usted no entienda / recuerde las implementaciones de bajo nivel.
Si está interesado en un poco de controversia que la gente en mi campo original y yo sabemos que es verdad, pero si escucha lo que está escrito aquí, aprenderá a estar de acuerdo y en desacuerdo con esta respuesta. , sigue leyendo:
Pero aquí hay otro problema: los puristas. Escuchará respuestas e ideologías bien redactadas que son razonables y completamente lógicas, de hecho, no tienen nada de malo. Pero no tiene que seguirlos, de hecho, podrían estar jugando en su desventaja.
Mis amigos trabajaron con grandes sistemas y simplemente se ríen de las personas que se preocupan demasiado por las convenciones y los patrones y, por una buena razón, yo también lo haría; puedo encontrar mi razonamiento para esto desde mi campo principal de análisis de datos, Como no soy un desarrollador tan experimentado: la mayoría de las cosas que piensas importan, no importan y hay una fuerte correlación con tu ego en este sentido.Muchas veces, un individuo, debido a su ego, habrá obtenido el conocimiento de que probablemente lo malinterpretó debido a sus prejuicios que ahora son reforzados por la autoridad que cree que acaba de decir "lo mismo que hice". Esta es una trampa muy conocida en la que nunca deberías caer. Esto no significa que no lo esté usando correctamente o para el bien común, pero a menudo, lo que estas personas harán es prometer que lo que sea que digan sea el premio de oro.
¿Entonces que puedes hacer?
Explique su código a un compañero de trabajo y pregúntele si tiene sentido desde un punto de vista de alto nivel.
Eso es todo lo que importa. Por supuesto, cualquiera que esté leyendo el código de otra persona siempre tendrá una fiesta de fichas alternativas para ver la implementación de ciertas cosas, pero eso no importa, si quien lee su código tiene un conocimiento de alto nivel de su sistema y comprende "por qué suceden las cosas". "(una vez más, sin saberlo necesariamente," cómo suceden "), entonces eres dorado.
Este no soy yo el que dice que siga adelante y escriba código basura que no sea eficaz o que no respete nada, pero lo que digo es:
1) Está bien olvidarlo. Con el tiempo, mejorará en la lectura del código con el que está trabajando. Si el código que está leyendo exige que conozca las implementaciones de bajo nivel en un buen nivel, entonces es un código mal escrito y juega con lo que dije antes: ¿lo comprende un compañero de trabajo?
2) El mundo está lleno de muchas personas muy inteligentes que no son muy inteligentes. A menudo también son muy emocionales y son propensos a reforzar los prejuicios de las fuerzas externas. Son muy buenos en lo que hacen, pero lo que ellos, como actores de la difusión de información, olvidan es: las ideas / información, incluso si están respaldadas por la "lógica", tienen el contexto de quien las envía, lo cual es crucial para comprender si eso la información también es útil para usted. Lo que tiene sentido para usted podría tener sentido para los demás y les encantaría, pero la información no debe tomarse como absoluta y, una vez más, debe considerar, o al menos tratar de averiguar el contexto de dónde proviene y compararlo con su contexto propio para ver si coincide. Es realmente lo mismo que los multimillonarios que nos dan estos "pedacitos de conocimiento para salir adelante"
En resumen: escriba código que sea comprensible y tenga en cuenta que todavía es discutible donde necesitamos tantos patrones / clases y refinería como dicen algunos. Hay personas muy inteligentes en ambos lados del argumento y solo debería reforzar la idea de hacer lo que funcione para su equipo de una manera razonable: no se quede atascado en pequeños detalles que no importan, los resolverá más tarde, recuerda, vives en un mundo extremadamente competitivo donde el tiempo es lo más importante:
Momento en el éxito de las startups.
Asigne su tiempo y recursos de una manera codiciosa y significativa.
Aquí hay una edición, 6 meses después:
Ha sido un viaje loco. Nunca pensé que solo la separación / buena denominación y documentación pueden básicamente permitirle conectar y desconectar cualquier cosa de su base de código. Tuve que volver a escribir una gran cantidad de código para ponerlo al día con los nuevos cambios e hice una buena parte de él en 2-3 días. Puedo decir con seguridad que no seguí SOLID en todas partes debido a la falta de conocimiento, ni a las mejores prácticas, y puedo decir que están en mi deuda técnica, pero no por mucho. Separar, nombrar bien y documentar, le permitirá cambiar el código en poco tiempo cuando finalmente se dé cuenta de lo tonto que era.
No me malinterpreten: si escribe su código estrechamente acoplado, sufrirá mucho, ya sea que odie o no SOLID, incluso comprenderlo y aplicarlo en un nivel base permite un gran desacoplamiento que, sinceramente, es lo único con lo que realmente ayuda OOP. Se suponía que OOP también se refería a la reutilización de código y, mientras eso sucede aquí y allá, realmente no puedes reutilizar muchos objetos que creas, así que concéntrate en asegurarte de que tu sistema esté bien separado. Una vez que alcances la madurez y supongamos que el tío Bob viene y toma la delantera en tu proyecto, él dirá "Ok, esto es una tontería, pero al menos todo está separado, bien nombrado y documentado, así que al menos sé de qué se trata todo esto. " (Espero). Para mi funciona. Mi LOC cambia constantemente, pero al momento de escribir, son 110k líneas de código, 110k líneas de código de ejecución que funcionan en armonía para una sola persona es mucho.
Aquí hay una edición, 3 meses después, en un código de 8 meses que estoy refactorizando:
Todo tiene sentido. Ahora puedo tomar lo que escribí en ese momento, conceptualmente y reformular el código de nuevo, con nuevas ideas porque entiendo perfectamente lo que está sucediendo y por qué funciona debido a los esquemas / buenos nombres y comentarios. Escribí un código hace mucho tiempo que no me importaba nombrar bien y tal y es doloroso pasar. Ahora estoy pensando cuál podría ser el siguiente paso para explicar mi código.
fuente