Soy un ingeniero de software en un inicio de tecnología y estoy agradecido de trabajar con otros ingenieros inteligentes. Sin embargo, todo el código que escribo es reescrito por otros y me siento aterrado de incluso escribir cualquier cosa por temor a que se vuelva a escribir. ¿Como puedó resolver esté problema?

Answer 1

A falta de detalles sobre el grado de reescritura de su código, todo lo que puedo hacer es ofrecerle algunos consejos sobre cómo ser un buen programador:

• Si tiene tiempo y su inicio lo abraza, haga TDD. En otras palabras, escriba sus pruebas de unidad antes de escribir la clase y el método que están probando. Al pensar en las pruebas que necesita, se asegura de comprender el problema de dominio que intenta resolver al escribir el código. También se asegurará de que está siguiendo los principios de SOLID. También asegurará que esté codificando las dependencias a las interfaces, utilizando la inyección de dependencias y burlándose de esas dependencias en sus pruebas unitarias. Todas estas cosas hacen para el código bien diseñado.
• Err en el lado de la legibilidad en su código. Si hay una forma “genial y complicada” de escribir una expresión y una forma ingenua y casi “infantil” de escribirla, usa esta última. La legibilidad del código es primordial. Los compiladores son lo suficientemente inteligentes como para optimizar cualquier ineficiencia percibida que pueda introducir al hacer que su código sea más legible.
• Refactor, refactor, refactor. Luego refactorizar de nuevo. Y otra vez.

  Si tus clases tienen más de un par de pantallas largas, divídelos; Probablemente haya demasiada funcionalidad allí para una sola clase.
  Si sus métodos tienen más de seis o siete líneas, extraiga de forma iterativa las piezas principales de la funcionalidad del método y ponga esa funcionalidad en su propio método.
  Siga haciendo esto hasta que su funcionalidad se divida en muchos métodos privados pequeños, fáciles de leer y bien nombrados.

• Trate de evitar poner comentarios en su código, aparte de los comentarios que documentan interfaces y métodos de acceso público. Si necesita agregar un comentario a un método privado para explicar lo que está haciendo, necesita refactorizar ese método para hacerlo más legible, o cambiarle el nombre, o ambos. Por ejemplo, si te encuentras poniendo un comentario como

  // El siguiente código toma los cuatro valores y calcula el índice de ShulmanFlobble de la serie.

  … extraiga el código al que se aplica el comentario y colóquelo en un método estático privado llamado:

  doble estático privado CalculateShulmanFlobbleIndexOfSeries (doble v1, doble v2, doble v3, doble v4)

  … entonces puede refactorizarlo para que acepte un objeto llamado ‘Serie’ que contiene los cuatro valores de este modo:

  privada estática doble CalculateShulmanFlobbleIndexOfSeries (Series sensibleName)

  Entonces mata el maldito comentario.

• Evite la sangría del código tanto como sea posible. Si hay condiciones bajo las cuales puede salir de un método, pruébelas antes y salga inmediatamente. No cree muchos sangrados si () s. Si alguien le dice que un método solo debe tener un punto de salida, ignórelo; son un imbécil imbécil

Hay mucho mas Lea Refactoring por el libro de Martin Fowler y Eric Evans sobre DDD. No te arrepentirás.

Micro.
(32 años de experiencia en desarrollo de software).

Answer 2

Aprende del código que se está reescribiendo.

Hay dos cosas que suceden aquí,

1. Pautas de codificación: su compañía tiene buenas pautas de codificación y los Ingenieros Superiores se aseguran de que cada línea de código que hace al producto final sea perfecta según las pautas establecidas. Debe ser lo suficientemente audaz para conversar con ellos y comprender lo que está haciendo mal. En caso de que su empresa tenga documentos que lo ayuden, lea y vuelva a leer los documentos hasta que comprenda las pautas.
2. No les gustas: Esto rara vez es un caso, pero puede suceder. A veces, los Ingenieros Superiores han desarrollado un ego muy extraño sobre la forma en que han construido el código durante un período de tiempo. Ellos no quieren que nadie se desvíe de ese método. También es posible que no te expliquen lo que estás haciendo mal. Simplemente cambia tu código. Esta situación es difícil, pero nuevamente tendrás que ser audaz y al menos tener una conversación con ellos. Debe preguntar, pero con mucha calma, como si los apreciara por lo que están haciendo, pero pregunte por qué era necesario hacerlo. En esto puede haber muchas posibilidades y tendrás que lidiar con la verdad a medida que se desarrolle.

Por su parte, también debe comenzar a invertir su tiempo en mejorar sus propias prácticas de codificación. Lea libros como Clean Code y entienda cómo debe escribir un código limpio.

Verifique todo lo que están cambiando y en el futuro comience a escribir el código como lo están escribiendo.

En general, mejore constantemente su código para que dejen de cambiar el código.

Una cosa que absolutamente no debes hacer es enojarte por esto. Eso te mantendrá miserable y no te permitirá crecer en tu carrera. Cada persona tiene que enfrentar algún tipo de crítica por su trabajo. Esa es la razón por la que comencé Success Factory: Turning Imagination to Reality blog. De modo que podría ayudar a los ingenieros a manejar o evitar tales situaciones a medida que crecen de 3x a 4x veces más rápido que sus compañeros.

Hoy tal vez estés enfrentando menos críticas. Pero a medida que te vuelves mejor que los demás. Y si por casualidad su gerente se da cuenta de que está haciendo un buen trabajo y lo aprecia, entonces las críticas realmente empeorarán.

Lo mejor es ignorarte y mejorarte constantemente.

Answer 3

Si te gusta la ingeniería de software, tendrás que aceptar algunas cosas:

1 – Nunca escribirás el código perfecto.
2 – Escribirás un montón de errores.
3 – Pasarás tiempo rastreando dichos errores.
4 – Las personas (incluido usted) cambiarán y evolucionarán su código.

Acepta lo anterior y enfócate en estas cosas:

1 – ¿Cómo puede mejorar la eficiencia de su código? Si es lento o algorítmicamente descuidado, alguien lo cambiará.
2 – ¿Cómo puede mejorar su modularidad de código? Si no funciona bien con otro código, alguien tendrá que domesticarlo. Si no es adaptable, alguien tendrá que reemplazarlo. Esto es especialmente cierto si hay un marco existente al que está modificando o agregando.
3 – ¿Cómo puede mejorar la legibilidad de su código? Si alguien no puede leerlo, es posible que no puedan entender lo que está haciendo, así que lo cambiarán o lo tirarán y lo reescribirán. Esto es tan fundamental, pero a menudo se deja a un lado en medio de la serie de problemas de resolución de problemas que está programando. Haga un punto para mantener la legibilidad!

El núcleo de la programación es probar, probar, mejorar. Hay inherentemente fallas e imperfecciones en ese proceso. Siempre estar aprendiendo. Parece que estás en una situación en la que tienes buenos mentores y reconoces eso, ¡así que aprovecha! Consiéntase en el hecho de que todos los integrantes de su equipo han escrito código con errores, código mal formateado, código mal documentado, código cambiado por otra persona, etc. En algún momento, también cambiará el código de otra persona. y espero que les ayude a entender por qué.

Answer 4

Revise el historial de confirmación y analice las diferentes razones por las que se modificó su código. Hay algunas razones por las que podría ser modificado:

1. Refactorización por nuevas características o cambios arquitectónicos. Esto no tiene nada que ver contigo en absoluto.
2. Corrección de errores. Esto tiene mucho que ver con usted, si esta es la razón, entonces sea más concienzudo y escriba un código mejor.
3. Refactorización sin cambios funcionales. Es posible que sigan una filosofía de código limpio, una convención de codificación o una arquitectura que no conoce. Pregúntales sobre eso. Averigüe por qué no está en la misma página y descubra una manera de mantenerse sincronizado en el futuro. Probablemente estarán ansiosos por ayudarte en esta área.

Answer 5

Si quieres tener una carrera en la economía del conocimiento, tienes que vivir de acuerdo con el mantra de que todos los días son días escolares. Las revisiones de código son una forma clave en que una organización de codificación puede inculcar esta mentalidad en su cultura. Mi experiencia es que someterse a una revisión por pares antes de que se ingrese su código requiere mucho tiempo, pero es la forma más efectiva de mantener los estilos y estándares de codificación, y también le ayuda a familiarizarse con el espíritu compartido de sus compañeros en el equipo. Si no tiene una revisión por pares en su proceso, me preguntaría si la repetición del trabajo que vería es simplemente una rotación basada en los gustos de la siguiente persona para recoger su código … Verifique con su gerente si tiene un conjunto acordado de estándares de codificación y apégate a ellos

Answer 6

Escribir código generalizado. Desarrollar pequeñas librerías o módulos que puedan ser reutilizados. Utilizar interfaces genéricas.

Cuando escribe código generalizado y extensible, no es necesario volver a escribir nada a menos que haya un problema de rendimiento.

Answer 7

Creo que esto ha sido sugerido por la mayoría, pero
1. Hable con ellos / verifique la base del código para ver por qué se está reescribiendo el código. Este debe ser tu primer y más importante paso. Obtenga comentarios de otros miembros de su equipo, intente mejorar sus habilidades en base a eso y, si no llegan pronto con sus comentarios, dígales que si mejora en su trabajo, reducirá su trabajo.
2. Agregue revisiones de código formal / informal con su equipo / supervisor a su ciclo de compromiso hasta que todos estén cómodos.
3. Y lo más importante: nunca, nunca, nunca te desanimes, ni tengas miedo de continuar tu trabajo.

Answer 8

¿Se está reescribiendo inmediatamente o después de unos meses? ¿Está siendo completamente eliminado y reescrito desde cero o está siendo refaccionado? Estos son muy diferentes. Es normal que las partes del código se vuelvan a escribir después de un tiempo relativamente corto y la refactorización es definitivamente normal. En cualquier caso, hablaría con su supervisor o solo con todo el equipo en una reunión regular y mencionaría que se siente de esa manera y sugeriría una programación por pares durante un tiempo o revisiones regulares del código. Si está escribiendo un código que a nadie le gusta, esto le ayudará a entender por qué. Si está escribiendo un código que está bien, o que es bastante bueno, pero luego se vuelve a refaccionar completamente, esto también lo ayudará a comprender por qué. La comunicación abierta no amenazante, no defensiva es clave y la programación de pares o las revisiones de código son un par de formas de hacerlo.

Answer 9

¿Es su código legible por otros? Solo reescribo el código que es ilegible y está lleno de duplicados … y tengo convenciones de nomenclatura incorrectas en todo el lugar … de lo contrario, se debería a errores y otros cambios funcionales.

Yo uso el tío Bob como guía en la codificación.
Dejo que mis juniors vean esta presentación -> Código incorrecto, artesanía, ingeniería y certificación

Answer 10

Así es la vida. Soy un programador veterano de 30 años. Gané un premio Usenix STUG por mi trabajo en el software detrás de Wikipedia. Con el tiempo, otros han reemplazado y reescrito partes de ese código, hasta el punto en que probablemente no queda ninguno mío. Eso no significa que mi código fuera malo, no lo era. Simplemente significa que el código más reciente hace más cosas y resuelve más problemas que el mío. Estoy totalmente bien con eso.

Answer 11

Bueno, no sabemos por qué está siendo reescrito. Realmente deberías preguntar. Tal vez sea parte de su proceso normal, o tal vez haya algo mal en lo que estás haciendo.

A veces hay estándares de codificación que se deben seguir.

O quizás usas un estilo de codificación diferente al de los otros. Si está fuera de la escuela, puede estar usando todo tipo de conceptos de torres de marfil, como fábricas de clase de fábricas de clase de tipos abstractos. O un montón de patrones de codificación extraños. O demasiadas capas de objetos y abstracción. Si hay alguna vieja barba gris trabajando allí, es posible que no se sientan cómodos con todas esas cosas. He desenredado un montón de código demasiado complicado en mi vida. En un ejemplo particularmente malo, hubo un módulo de 7.000 líneas que realmente no hizo nada con los datos, excepto los bits de distorsión y caída aleatorios. Podría haber sido totalmente sacado y disparado.

O tal vez alguien pensó que el código era demasiado lento, demasiado grande o demasiado inestable.

O tal vez alguien más sabía que su código tenía que encajar con otro código, por lo que tuvo que ser reenvasado para encajar en el panorama general.

O a veces los programadores tienen algo de tiempo libre y no pueden dejar de querer modificar las cosas.

Pero realmente debería mirar el código modificado e intentar averiguar qué cambiaron y cuál podría ser la razón. Podría haber sido simplemente alguien con un tiempo de inactividad y una cierta mentalidad, o tal vez supieron de un algoritmo mejor y más rápido, o tal vez simplemente refactaron su código para que fuera más pequeño y más modular. Si no puede entender por qué lo hicieron, realmente debería preguntar, gentilmente, cuál fue el motivo.

Answer 12

Primero, debes averiguar por qué tu código se está reescribiendo. Es extraño que alguien se moleste, ya que la gente generalmente está bastante ocupada.

Para darle una pequeña perspectiva, hay algunos programadores que son excelentes para obtener el 98% del camino y son terribles para obtener el último 2%. Hay personas que son excelentes en la corrección y corrección de errores y que son terribles en escribir código desde cero. Hay personas que son excelentes para el pulido y no tanto en la arquitectura de código (a falta de un término mejor). Si alguien se molesta en volver a escribir su código, debe contribuir con algo que haga que valga la pena mantenerlo. Si tiene un valor negativo, ya que siempre está tomando el tiempo de otra persona, busque que lo dejen ir a menos que descubra lo que está sucediendo y cambie la situación.

Pregúntele a su gerente o líder de equipo, o verifique los compromisos como alguien más sugirió. ¡Y publica tus hallazgos aquí!

Answer 13

Si su código es reescrito, su trabajo está en juego. Por más aterrador que sea, estar sentado en silencio no lo ayudará a mejorar ni a comprender por qué.
Tuve un colega que no se iría hasta que sus preguntas fueran respondidas, ¿cómo sabías dónde mirar? ¿Por qué pusiste un punto de quiebre allí, etc.? Así que no dudes en preguntar, si evitan las respuestas, es probable que sea porque no son un jugador de equipo. Y probablemente no sean buenos para la compañía en la que está trabajando a largo plazo.

Si hay una verdadera mejora requerida de su parte, trabaje duro y mejore tan pronto como sea posible.

Nadie nace inteligente, solo trabajaron duro. También fueron ayudados por sus maestros, compañeros para llegar allí. Es su deber compartir sus conocimientos con otros en el equipo.

Answer 14

Respuesta en dos partes aquí: A) No te adjuntes y B) escribe un código mejor.

A) Tú no eres tu código. La vida media para la mayoría de los códigos es muy corta. Reescribir y un cambio significativo es parte del proceso normal;

B) ¿Sabes por qué están reescribiendo tu código? ¿Les has preguntado? Sus compañeros de trabajo no confían en su código, no les gusta o no pueden usarlo. Averigua cuál de estos es verdadero, y trabaja en solucionarlo.

Answer 15

Pídales que lo guíen a fondo un par de tales cambios. Pídales que expliquen qué están cambiando y por qué.

Pídales que revisen su código antes de cometerlo y explíqueles los cambios que solicitan; Además de tener el código correcto en primer lugar, las revisiones son una gran herramienta de enseñanza.

Answer 16

Los programadores son como los cerveceros y los editores, nunca son felices hasta que ellos mismos lo han hecho. Dale tiempo y descubrirás que tus compañeros de trabajo más jóvenes harán la misma queja sobre ti.

Answer 17

Averigüe por qué los otros codificadores necesitan volver a escribir su código. No lo tomes como un insulto personal sino como una oportunidad de aprendizaje. Dices que eres un ingeniero inteligente. Hazte más inteligente al no repetir los mismos errores una y otra vez.