Verdadero significado del desarrollo iterativo y código de refactorización

Question

Recientemente comencé a trabajar como desarrollador y trabajando con un desarrollador más experimentado que me supervisa/asesora.

Muchas de las cosas que él está aconsejando simplemente no parecen correctas. Por ejemplo, me dice que simplemente escriba mi código de una manera procedimental ignorando qué tan bien está escrito o en su diseño general y solo lo hago funcionar. Luego iterativamente mejorará según sea necesario, mejorando el código a lo largo del tiempo.

Esto me hace sentirme incómodo al dedicar realmente tiempo a pensar en las soluciones y los problemas reales antes de la codificación y creo que apresurándome y codificando de esta manera al final, se dedicará más tiempo a esto. Lamentablemente, no estoy en la etapa de poder resolver problemas inmediatamente escribiendo el código perfecto la primera vez.

Además, m frunce el ceño al documentar el código, creyendo que debería hablar por sí mismo. Siente que un breve comentario en la parte superior de cada método debería ser suficiente. De nuevo, esto parece contrario a la intuición para mí.

Con todo, siento que ahora estoy escribiendo un código realmente hacky para poder ponerme en marcha. ¿Está correcto y es así como se hacen las cosas en toda la industria?

Answer 1

Además, se ve con buenos ojos la documentación de código, beliveing ​​que debe hablar por sí .

Eso es todo lo que necesitaba leer. Esta persona realmente no tiene idea de lo que se necesita para escribir un código que se pueda mantener.

Dicho esto, esta persona es obviamente su mentor/supervisor, por lo que no puede simplemente decir: "oye, eso es estúpido", tiene que hacerlo con tacto.

Pero no documentar el código porque "debería hablar por sí mismo" es una receta para el desastre. Y definitivamente debes prestar atención a escribir un código claro, efectivo y eficiente. Siempre es mejor hacer algo bien que simplemente hackear algo que no vas a entender dentro de 6 meses. Si no lo entiendes, es probable que nadie más lo haga.

Creo que deberías hablar con su supervisor y explicar la situación.

Dicho esto, a veces hay razones para tomar atajos si el tiempo apremia, citando Jamie Jawinski, que trabajaba en Netscape,

"Vamos a enviar el producto más alta calidad que puede en 31 de marzo "

Así que tiene que encontrar el equilibrio. Pero, en general, escribir comentarios útiles en el código no toma mucho más tiempo, ciertamente no lo suficiente como para afectar significativamente a una línea de tiempo del proyecto, y me gusta lo que Donald Knuth dijo:

... cuando se escribe un programa, pensar de es principalmente como una obra de literatura. Está tratando de escribir algo que los seres humanos van a leer . No lo considere principalmente como algo que una computadora va a seguir.Cuanto más efectiva está en hacer su programa legible, más eficaz que va a ser: Usted entenderá que hoy, vas a entender que la próxima semana, y sus sucesores que van a mantener y modificarlo comprenderá él.

En resumen, no hay sustituto para escribir código altamente efectivo, claro y fácil de mantener, incluso con una línea de tiempo ajustada.

Answer 2

No, esa no es la forma en que se hacen las cosas normalmente. Pero hay algunas consideraciones.

Hay un patrón de desarrollo denominado "desarrollo basado en pruebas". En este patrón, básicamente escribes el menor código posible para pasar cualquier prueba que tengas. A medida que cambien los requisitos, escriba nuevas pruebas y luego cambie el código para que coincida. Él podría estar guiándote hacia algo más como esto. En cuyo caso, si escribe pruebas suficientemente buenas, no importa cuál sea el aspecto del código original, si realizó la prueba para cada caso que necesita, entonces el código siempre hará lo que quiera, incluso si es un desastre horrible. (Esto es, por cierto, por qué a algunas personas no les gusta el desarrollo impulsado por pruebas).

En cuanto a los comentarios, por supuesto, los comentarios son importantes. Pero los comentarios no son un sustituto del código fácil de leer, con nombres y nombres de funciones correctamente nombrados. Sobre el comentario es definitivamente posible y hace que el código sea más difícil de leer y entender (porque cada línea es un comentario como // increment i). Además, cuantos más comentarios tenga y cuanto más grande sea, más probable será que se desactualice y se desincronice con el código real. Todo el mundo leerá eso y dirá "eso no sucederá", pero siempre lo hace. Alguien siempre entra para cambiar "en cosas pequeñas" y no actualiza el comentario, y luego de eso ocurre unas tres veces el comentario es simplemente incorrecto.

Hay una cosa más a considerar. Considere la posibilidad de que esta persona no lleve lo que le dijo como filosofía, sino que simplemente está tratando de ayudarlo. Tal vez haya dedicado demasiado tiempo a diseñar adecuadamente su solución antes de escribir cualquier cosa y siente que si tiene algo de "papel" primero, sería más fácil para usted mejorarlo que intentar mantener toda la solución en su cabeza. Tal vez has estado escribiendo demasiados comentarios, malos comentarios o pasando demasiado tiempo en comentarios (o incluso en el formato de comentarios, he visto que esto sucede) y siente que aprendiste más en esta etapa al pasar tiempo en tu código que en hacer comentarios bonitos.

Answer 3

Su opinión del 100% aquí, pero si su solución está bien diseñada, creo que un comentario para cada método puede ser la cantidad correcta. Debería describir lo que hace y por qué, pero no entrar en los detalles de cómo. A menos que su método sea extremadamente largo (indicativo de un diseño deficiente), el código debería explicarse por sí mismo, es decir, si su método parece intrincado y es difícil de entender, tal vez deba desglosarlo para que se lea de forma más natural. Siempre hay excepciones, pero esa es mi opinión.

Donde trabajo, el código parece tener muy pocos comentarios pero si el nombre del método es realmente representativo de su función, y el código dentro del método está limpio, no tengo problemas para entenderlo.

Lamentablemente no estoy en la etapa de ser capaz de resolver problemas inmediatamente escribiendo código perfecto primera vez.

No existe un código perfecto, se trata de saber qué compromisos son aceptables.

Tal vez su metor simplemente está tratando de hacer su vida más fácil diciendo 'no se preocupe por el diseño'.

O tal vez se está refiriendo a la práctica de rojo, verde, refactor (Desarrollo basado en pruebas) - la idea de que primero debe escribir pruebas, luego escribir el código hasta el punto de que funciona - solo entonces refactoriza eso.

Answer 4

Hay muchas escuelas de pensamiento y muchos estilos diferentes. Dejé de contar y en su lugar trato de usar un enfoque pragmático.

En cuanto a la implementación del código, utilizo el principio "haz que funcione", "hazlo bien", "hazlo rápido". Pero luego también uso "Lo más simple que podría funcionar" (DTSTTCPW)

La cantidad de comentarios que escribe depende de una serie de factores. Una escuela de pensamiento defiende la tesis de que el buen código es auto-documentado. Además, he visto innumerables comentarios que estaban completamente fuera de sincronización con el código.

Otra escuela de pensamiento cree que necesita comentarios.

Estoy tomando la posición de que existen varios factores que influyen en su elección. Una es su preferencia personal. Luego está tu jefe. En otros casos, está tu equipo. Lo ideal es que todos estén en la misma sintonía al acordar conjuntamente los estándares de codificación. Y al final si siempre tienes la opción: Ámalo, cámbialo o déjalo. Las opciones 1 y 3 pueden ser las únicas si su jefe (o mentor) no puede convencerse o no está dispuesto a encontrar consenso en el equipo.

Mi comprensión del desarrollo iterativo es que agrega funciones en pequeños incrementos. En cualquier momento, usted está listo para enviar y su código es tan delgado y malo como puede obtenerlo, incluidos los comentarios cuando corresponda.

Mi comprensión del desarrollo basado en pruebas (TDD) es que utiliza pruebas para dirigir el diseño de su sistema. Esto es más y más allá de la mera programación de prueba.

Este enfoque me ha funcionado durante los últimos 10 años y con muchos equipos con los que he trabajado. Pero estoy seguro de que hay muchas otras opciones, estilos, preferencias y metodologías que funcionan igual de bien. ¡Todo depende!

Answer 5

Estoy de acuerdo en el código de auto-documentación a un grado. Debe nombrar sus variables y métodos bien en lugar de confiar en los comentarios. p.ej. ¿Cual preferirías?

//Get the speed of the train from the database 
int value = GetValue(); 

int trainSpeed = GetTrainSpeedFromDatabase(); 

¿Qué pasa si decidí que quería obtener el trainspeed desde un archivo XML ahora, en el segundo ejemplo yo soy mucho más probable que actualizarlo por lo que tiene sentido y no dejar el comentario engañosa.

Answer 6

Voy a dar un paso aquí y sugerir que puede estar malinterpretando lo que el desarrollador senior le está diciendo. "Simplemente haz que funcione" y "el código debería hablar por sí mismo" son mutuamente excluyentes. Si asumimos que este tipo sabe realmente lo que está haciendo, permítanme ofrecer un par de explicaciones alternativas:

• Es fácil para los nuevos desarrolladores que se pierden en la agónica malezas sobre la manera correcta de diseñar software. Es un tipo de parálisis de análisis. Probablemente quiera que entres rápidamente al código para que realmente consigas algo escrito y descubras rápidamente lo que no funciona bien. Parece que te está dejando fallar temprano y con frecuencia para aprender.

• Muchos desarrolladores nuevos rocían generosamente su código con comentarios inútiles. Te está pidiendo que escribas un código de auto-documentación, no un código estrafalario y confuso. Si solo se le permite un breve comentario en la parte superior de una función, debe usar nombres claros de las variables y algoritmos sencillos y simples para que el código tenga sentido. Ésto es una cosa buena.

No hay nada de malo en sentarse con su mentor para aclarar lo que le está diciendo. Usted tiene preocupaciones válidas. No dude en pedirle más información. Muestra confianza y la capacidad de pensar por ti mismo. Los buenos empleados no son robots aturdidos por la mente.