¡Cuánto de la declaración ‘soy un programador’ genuino ‘! He leído el código no la documentación ‘es cierto?

Answer 1

Bueno, la afirmación podría ser totalmente cierta cuando “I” se refiere a la persona específica que la pronuncia. Pueden ser un programador genuino que se niega a leer la documentación.

En general, los programadores leen la documentación. Personalmente, casi siempre leo la documentación primero, y luego, cuando no puedo encontrar la respuesta en la documentación, leo el código. De hecho, normalmente cuando no puedo encontrar la respuesta a algo en la documentación que debería estar allí, me molesta, ya que leer el código requiere más tiempo y esfuerzo. Si solo el autor hubiera tomado unos minutos adicionales para completar esto, ¡piense en cuántas horas se podrían haber ahorrado!

En algunos casos, voy directamente al código porque sé que no todo puede documentarse. Este suele ser el caso cuando estoy tratando con el kernel de Linux. Supongo que algunos programadores del núcleo podrían tener la actitud de “los programadores reales no leen la documentación”, si creen que son los únicos programadores reales …

Answer 2

Los programadores genuinos leen el código y la documentación.

Debes leer la especificación de cualquier código que estés escribiendo. Si no sabe qué se supone que debe hacer el código, no puede hacer que la computadora lo haga.

Debe leer la documentación del usuario para conocer las características que posee. Si hay errores, ¿quién mejor para señalarlos que tú? Si la documentación se disculpa por las deficiencias en la función, debe saber cuáles son las deficiencias percibidas (cuanto antes, mejor).

Pero claro, lee el código también. Idealmente, el código es lo suficientemente claro para que pueda leerse de una manera bastante sencilla. Siendo realistas, esto no siempre será cierto, pero deberías trabajar para conducir el código en esa dirección.

Answer 3

“Soy un programador ‘genuino'”. – Lee como la declaración: “Confía en mí, tengo XYZ años de experiencia”. – (Sea escéptico.)

Los buenos programadores leen la documentación. En gran parte después de leer un poco de código original y tener más experiencia, se pregunta por qué se hizo algo de una manera y no de otra (un programador experimentado puede detectar rutinas ineficientes y métodos / uso del lenguaje, pero puede verificar o verificar un resumen).

Leer la documentación también es un programador experimentado para diferenciar entre varias formas diferentes de hacer algo.

Los bits funky de código ineficiente provienen de personas que no leen la documentación, a menudo copian / pegan / modifican el código para lograr un objetivo.

Hay algo que decir para leer el código en lugar del documento …
El código no siempre hace lo que dice un documento. Nuevamente, a menudo porque una persona inexperta actualiza o cambia el código, y descuida (o olvida) la fecha y la fecha de la documentación. Por lo tanto, leer el código es una buena idea.

La declaración, según el contexto, podría significar lo anterior: el programador puede pensar que es más genuino leer el código y no el documento. Pero si no se lee el documento, es difícil actualizarlo si se cambia el código.

Pero el modificador “genuino” hace que la declaración suene insensible, y yo sería muy escéptico con respecto al producto de trabajo de una persona así.

Answer 4

La proposición implica una conclusión de que uno es un programador genuino basado en la premisa de que uno lee código y no documentación. Este argumento es más débil que un cordero que no puede soportar el peso de su propia lana. Me detestaba prestarle más atención de la que merece. Sin embargo, voy a plantear un punto simple. ¿Cómo espera convertirse en un programador, y mucho menos en un programador “genuino”, si no lee la documentación? La declaración implica que, como programador “genuino”, uno nunca ha leído un tutorial, libro, blog, foro, especificación, documento del sistema, documento de diseño o cualquier forma de documento de integración. Cualquiera que diga algo como esto es un mentiroso o no un programador.

Answer 5

Bueno, genuinos o no, probablemente se hayan vuelto así trabajando para compañías / proyectos donde el código casi nunca está documentado. Olvídate de la documentación, la mayoría de ellos ni siquiera están bien comentados.

Lo mismo sucede conmigo (aunque no pretendo ser un auténtico programador por este motivo), desde que comencé mi carrera (ahora más de media década) he trabajado en muchos proyectos de mantenimiento (ambos en servicio). y algunas de las mejores compañías basadas en productos – No daré nombres: P) – ¡Nunca vi documentación para el código en ninguno de los proyectos!

Se esperaba que entendiéramos el código (y, a veces, creamos documentación basada en nuestro entendimiento) y comenzáramos a trabajar en él (solución de errores, adición / eliminación de características, etc.).

Esto se ha convertido en la rutina habitual para la mayoría de los desarrolladores / ingenieros de software y cuando escucho nuevas juntas, solicite capacitación o documentación (que generalmente les damos), tengo la sensación de que quieren ser alimentados con una cuchara. ‘Los programadores genuinos no leen la documentación’.

Aunque, cada vez que tengo que escribir un fragmento de código, lo escribo desde el punto de vista de mantenimiento (buenos comentarios, si no es un documento separado). Me aseguro de que a los futuros usuarios les resulte fácil de entender. 🙂

Answer 6

Depende de la documentación.

Leí documentación arquitectónica de alto nivel que da diseño sobre vistas.

Los documentos de función y los comentarios de codificación son mucho menos confiables. No es infrecuente que una función haya sido documentada cuando se creó por primera vez, pero luego se han producido numerosos cambios posteriores y los comentarios están lamentablemente desactualizados.

Por lo tanto, generalmente prefiero que el código sea tan auto documentado como sea posible, con un mínimo o ningún comentario.

Entonces, si me refiero a la documentación dentro del código, entonces tiendo a estar de acuerdo: muchos codificadores simplemente ignorarán o no confiarán en este tipo de documentación.

Answer 7

Hasta cierto punto, estaría de acuerdo. ¡La mejor indicación de lo que hace el código es el código mismo! Si el código es limpio, conciso y está documentado internamente, honestamente, ¿quién necesita más?

Answer 8

Los programadores reales tampoco leen la documentación.

Answer 9

No sé si es verdad , pero cualquier programador que esté más dispuesto a perder el tiempo reconstruyendo ideas a partir del código cuando haya documentación disponible con la información que él o ella necesita, va a hacer mucho menos que la persona que no lo está. Como interesado en los concursos de orina.

¿Es más “genuino” perder tiempo en un proyecto en lugar de hacer las cosas? Supongo que podría ser …

(Esta es la razón por la que también tengo problemas con los colegas que dicen cosas como “solo lea el código” a las nuevas contrataciones. Tal vez sea más puro intelectualmente o algo así, pero es una pérdida de recursos que alguien pase un día averiguando qué puede explicar en quince minutos)

Answer 10

Cojones. El código no es el idioma nativo de nadie; hay una buena probabilidad de que lo que alguien intentó poner allí (de acuerdo con lo que dicen los documentos) no sea realmente lo que puso allí.

Por el contrario, si desprecia algo tan útil como la documentación, es probable que su código sea ilegible y, por lo tanto, no se pueda mantener. Se tirará lo antes posible.

Answer 11

Solo el 50% en un momento dado, ya que ambas mitades de la oración se excluyen mutuamente

Answer 12

Si el código está bien escrito, leo el código. Si el código no está bien escrito necesito documentación. Los programadores “genuinos” usan las herramientas disponibles frente a ellos para realizar la tarea. No dibujan líneas en la arena.