Acabo de salir de la Universidad y he estado trabajando en esta empresa durante aproximadamente 8 meses, mientras me dieron el título de desarrollador, la mayor parte del tiempo que he dedicado a arreglar y depurar los códigos de otras personas.

Siempre me pregunto por qué no es responsabilidad del desarrollador original corregir su código. Entiendo que si el desarrollador original ya no está presente, entonces los otros desarrolladores tienen que hacerse cargo del trabajo, pero ¿qué pasa si el desarrollador todavía está trabajando como empleado en la empresa?

Uno puede argumentar que es beneficioso para los nuevos desarrolladores ya que lo ven como una oportunidad para aprender, y estoy de acuerdo con eso, pero ¿qué pasa si la complejidad del problema / problema del código es muy pronunciada? En mi caso, la mayoría de los códigos que me asignaron para solucionar son problemas no triviales, y siempre termina haciendo preguntas al desarrollador original sobre el código. ¿Por qué los desarrolladores que lo crearon no pueden solucionar el problema existente si lo entienden mucho mejor desde que lo codificaron? Y el problema al que me refiero no es un problema trivial en el que pueda solucionarlo en un día o dos, sino un problema que requiere una comprensión profunda del código para encontrar una solución.

¿Cuál es el razonamiento detrás de esto y es común en la industria del software?

Creo que la razón principal por la que verás justificar este tipo de cosas en el sentido más amplio es el "factor bus" . Si la misma persona escribe y mantiene un código a perpetuidad, nadie más que esa persona tendrá idea de cómo funciona, lo cual es un problema cuando esa persona se va. Por lo tanto, tener nuevos desarrolladores que corrijan errores para comenzar a menudo se justifica con esa justificación.

Personalmente, creo que es poco probable que la justificación coincida con el razonamiento. Creo que la razón real por la que esto sucede con los desarrolladores más nuevos es que los departamentos honestamente realmente no saben qué hacer con ellos, realmente no tienen un programa de capacitación integral y están nerviosos por asignarles funciones principales. Entonces, sea lo que sea que le digan, es probable que sea una forma predeterminada de demostrar que es capaz de manejar cosas y, con suerte, aprender una o dos cosas en el camino.

Personalmente, creo que hay formas mucho mejores de lograr esto, pero es una forma, y ​​supongo que a veces funciona, de una manera (a pesar del riesgo de que los novatos aburridos se vayan por pastos más verdes).

Otros comentaristas ya han cubierto algunos puntos importantes: estoy hablando desde la posición de alguien que trabajó durante un tiempo en un equipo de desarrollo específicamente encargado del mantenimiento del código enviado. Casi todas sus preguntas surgieron una y otra vez.

Hay muchas cosas que podrían estar sucediendo. Usted señaló uno: el desarrollador original puede haber dejado la empresa. Otra posibilidad es que, mientras el desarrollador original todavía está en la empresa, hace mucho tiempo que pasó a otras cosas, y ya no tiene esas cosas en la memoria de trabajo (especialmente si el código ha cambiado bastante desde que estaban trabajando en eso).

Lo que tuvimos que enfrentar, por ejemplo, es que el equipo del producto tenía horarios muy agresivos para entregar las próximas versiones del producto. Si también tuvieran que trabajar en errores en las versiones existentes, al menos así fue el razonamiento, no habrían podido cumplir con sus horarios. Supongo que este punto podría discutirse, pero la realidad del mundo del software corporativo es que sacar las cosas por la puerta supera todo lo demás, incluida la observación de todas las mejores prácticas de ingeniería de software en todo momento. "Compromisos" es el término vago bajo el cual caen todos los compromisos desagradables que los desarrolladores tenemos que hacer tarde o temprano en esos entornos.

Por otro lado, sin embargo, corregir errores no triviales requiere que realmente aprendas mucho sobre la base de código. Es doloroso, a veces desmoralizante, y muchas veces abrumador. Pero, ¿cómo cree exactamente que se convertirá en un experto en la materia en un proyecto de software? Puede pasar días leyendo el código para su edificación, pero ese tipo de lectura del código realmente no se adhiere tan bien como haber tenido que "luchar" con el código para solucionar un problema. Las investigaciones continuamente prevalecen sobre el lema que aprendemos haciendo. Lamentablemente, a menos que esté en una startup o en un nuevo equipo, esto significa que generalmente se está uniendo a un proyecto de software que ha estado presente durante varios lanzamientos y tiene clientes reales con quejas reales que deben abordarse. Esto implica que primero corregirá los errores antes de '

Lo que es realmente importante es comunicarse regularmente con su gerente y expresar lo que desea obtener del trabajo, y ver si la empresa puede adaptarse a sus objetivos en este momento. Con suerte, la respuesta será sí. Quédate un rato y reúne toda la experiencia que puedas de tu equipo actual. Si la respuesta es no, y eres un buen desarrollador, tendrás muchas opciones. Pero no descarte la experiencia que obtiene al corregir errores: ahora estoy en mi tercer trabajo de software y tengo que escribir toneladas de código. Afortunadamente, mucho funciona desde el principio porque he pasado mucho tiempo identificando, reparando e intentando evitar errores.

Tenemos que admitir que los desarrolladores de software pasan mucho más tiempo leyendo / entendiendo el código que creando. Y desde mi experiencia personal, cuanto mejor sea la compañía con la que trabajas, más código leerás. Entonces, el hecho de que tenga que lidiar tanto con el código de los demás no debería sorprenderlo ni confundirlo en absoluto.

Y esto parece bastante natural. Para aprender algo tienes que ver cómo se hace. No hay muchas compañías donde se practique la programación de pares y los novatos se les enseñe de esta manera. La mayoría de las veces aprende nuevas técnicas, patrones, estilo de codificación de la empresa, etc. al leer el código de otros.

Y la forma más eficiente de entender el código es trabajar con él: depurar, refactorizar, corregir errores. Esta es una práctica común si debe tomar posesión del código.

Las posibles razones por las que el desarrollador original no corrige sus errores podrían ser que

• el error tiene poca prioridad y la tarea actual del desarrollador es más importante o urgente.
• el desarrollador no ha trabajado con ese código durante mucho tiempo y de todos modos les tomaría algún tiempo recordar su código anterior.
• el desarrollador está muy ocupado con algo complicado y no necesita ser interrumpido.

PD: Creo que tienes suerte de que el desarrollador original esté allí para responder tus preguntas.

Hay razones pedagógicas y razones de factores de riesgo, pero principalmente son solo matemáticas. La mayoría del trabajo de programación es mantenimiento, y aquellos que han estado en una empresa por más tiempo han generado la mayor cantidad de código que necesita mantenimiento.

Considere una compañía de software de un solo hombre. Después de 10 años, contrata a alguien para que lo ayude. Si el 90% del trabajo disponible es de mantenimiento, ¿en qué va a trabajar el chico nuevo si no puede tocar el código del viejo? En un equipo más grande, el efecto es más difícil de cuantificar, pero eso no significa que no esté allí.

Así que trate de no obsesionarse con quién es responsable de qué código. Las personas se apegan a "su" código y no lo abandonan a la ligera. En unos años habrá un código para el que desea preservar su responsabilidad, pero simplemente no tendrá tiempo.

Erik es perfecto.

Además, la gerencia quiere cubrir sus apuestas al familiarizar a todos los desarrolladores con ciertos aspectos del código. El hecho de que una persona haya escrito algún código no los hace responsables automáticamente mientras trabajan allí. Todo lo contrario, cuantos más desarrolladores lo mantengan, más posibilidades hay de detectar errores y mejorar las redes. A todos les gusta dejar su huella;) si sabes a lo que me refiero. Otra opinión es que el código es propiedad de la compañía y no del desarrollador. Hace que la vida de los gerentes de proyecto sea un poco más fácil si tienen más desarrolladores para elegir para una determinada tarea. Probablemente solo lo están ayudando a acceder a sus bibliotecas de códigos y al mismo tiempo están probando su capacidad. Estarían locos si dejaran que un nuevo empleado se acercara a cualquier cosa que pudiera costarle dinero a la compañía, ciertamente durante los primeros 6 meses más o menos.

buenas respuestas, todas; aquí hay otro ángulo

puede ser simple economía

puede llevarle 5 veces más tiempo encontrar y solucionar un problema que el desarrollador original, pero el trabajo que el desarrollador original está haciendo mientras tanto proporciona muchos más ingresos a la empresa