¿Cómo convenzo a un compañero que los algoritmos son importantes?

StackOverflow https://stackoverflow.com/questions/1654425

  •  11-09-2019
  •  | 
  •  

Pregunta

A los compañeros de la mina está trabajando en un informe que muestra el avance semanal (domingo a sábado) de todos los empleados de nuestra pequeña empresa de consultoría. Hay un trozo de código que escribió que muestra las columnas correspondientes a los días de la semana de destino. Su algoritmo es el siguiente:

  1. Obtener qué día de la semana, el primer día del mes es. Si es domingo, establecer un indicador a cero; de lo contrario, ponerlo a uno.
  2. Iterar a través de todos los días del mes. Si es domingo, incrementar la bandera. Entonces, si el valor del indicador es igual a la semana para que se muestre, mostrar la columna correspondiente al día actual; de lo contrario, ocultar la columna.

Por supuesto, la bandera indica lo que es la semana en curso.

sugerí otro algoritmo:

  1. Obtener el cual días del mes son la primera (F) y la última (L) días de la semana especificado. Por ejemplo, la primera semana de octubre de 2009 comienza el martes 1 y termina el sábado 3.
  2. Iterar a través de las columnas correspondientes a los días 1 a F-1, y ocultarlos.
  3. Iterar a través de las columnas correspondientes a día F a L, y mostrarlos.
  4. iterar a través de las columnas correspondientes a día L + 1 a DaysOfMonth, y ocultar ellos.

La parte "difícil" en mi algoritmo es parte 1. Es decir "difíciles", como en "difícil de entender", debido a la complejidad algorítmica de hacerlo es constante. Y mi algoritmo tiene la ventaja de tener lazo más fuerte. lazo de mi pares hace una comparación para cada día del mes. La mía no.

Este fue un pequeño ejemplo y se podría decir que el exceso de optimización aquí es un poco demasiado paranoico. Pero su estilo de programación no cambia un poco cuando escribimos código real de la eficiencia crítico.

Su código también está llena de estas pruebas: 

/* doSomething() doesn't change the state of the relevant variables. */
if (condition)
{
    flag++;
    if (flag > test)
        doSomething();
}
else
    if (flag >= test)
        doSomething();

Cuando, por supuesto, se puede hacer de esta manera: 

if (flag >= test);
    doSomething();
if (condition)
    flag++;

¿Qué hago?!?!?!

EDIT:. Corregí las comparaciones en los ejemplos de código

¿Fue útil?

Solución

Esta es su tarea, o la suya? Si el suyo, que lo haga. Soy una persona que se nutre de la eficiencia, de hecho me convierto en una gran frustración cuando algo parece ineficiente y está fuera de mi control.

Hay más de 200 personas en Entonces, ¿quién podría poner mi muy eficientes '' ideas, algoritmos y código para la vergüenza. Probablemente más, no se puede ir por el representante solo. Si el propio Linus Torvalds se ha registrado, que empezaría a 1 como el resto de nosotros.

Lo que hay que considerar es que la gente tiene que ser capaz de mantener el código que escriben. Esto significa, que tienen que entenderlo como si daban a luz. Incluso si alguien demostró otro algoritmo como mucho más eficiente que la mía, yo no lo uso a menos que estuviera cómoda con él.

Si se trata de un proyecto conjunto, escribir a su manera, demostrar la velocidad y luego pasar unas horas muy, muy paciente con su compañero que le ayudará a comprender realmente a él.

Mirar hacia atrás en cosas que escribió hace 5 años, cada uno tiene que aprender sobre la marcha y todo el mundo hace cosas a su propio ritmo, especialmente el aprendizaje.

Otros consejos

Creo que su amigo tiene la idea correcta. Tome el algoritmo que obviamente es correcta sobre el algoritmo que tomaría una hora de explicar pero, sin objetivo de rendimiento en particular en mente, es más rápido.

Si usted tiene un requisito específico de rendimiento, como 'el código tiene que ser capaz de dar resultados correctos para todos los meses en los próximos diez años a menos de 200 microsegundos en la máquina X', y el código más simple falla el requisito, entonces es posible considerar el uso de su versión.

(La muestra de código que envió es de hecho mejor, evidentemente, en su camino, porque es menos complicado.)

A partir de su descripción, no estoy seguro estoy de acuerdo con su colega. La cuestión clave es si o no este pedazo de código es un cuello de botella .

Para convencer a me para cambiar su algoritmo tendría que perfil de la aplicación en cuestión y me muestran que este pedazo de código es el rendimiento crítico. A continuación, hacer su cambio y crear un perfil nuevo. De esa manera usted tiene un base objetiva de comparación .

Si hay una diferencia significativa entre los dos algoritmos entonces los dos se puede discutir si es o no vale la pena hacer el cambio.

Si usted está preocupado acerca de los tiempos de carga de página de una aplicación web, recordar las lecciones de sitios web de alto rendimiento y los href="http://developer.yahoo.com/performance/" rel="nofollow noreferrer"> pautas de actuación -. la forma de manejar CSS, javascript y almacenamiento en caché tendrá un impacto mucho mayor que la optimización de los algoritmos que se ejecutan en el servidor

La promoción de optimización sin medición es tan peligroso como ignorar las implicaciones de rendimiento de los algoritmos de ingenuos.

Bueno, no debería interferir porque, obviamente, estás equivocado ... Las dos piezas de código no son equivalentes. Sólo tomar condición = 1, bandera = 0 y test = 1

no veo el problema aquí ... aunque su versión cuenta con un poco de manera indirecta de llegar a la meta, lo hace llegar hasta allí.

Esta declaración que voy a decir no debe ser tomado fuera de contexto, pero siempre habrá gente que lo hace así - y eso no es malo, todo lo contrario ... que tal vez no sabe buena manera de hacer algo, pero no sabe cómo conseguir el resultado no importa lo feo que su método es.
Eso puede ser un verdadero salvavidas cuando nadie sabe el algoritmo correcto para algo ... lo más probable es que va a cinta aislante que de alguna manera.

Me acuerdo con el sentimiento que prevalece aquí: si una mejora de rendimiento podría hacer que el código mucho más difícil de leer, más vale que sea una buena razón para hacer que el cambio

.

Por otro lado, eso no significa que siempre debemos conformarse con la primera cosa que viene a la mente . A veces hay alternativas inequívocamente superiores que son igualmente legible o casi.

Si desea convencer a su colega a tomar su elección de algoritmos en serio, usted debe escoger sus batallas con cuidado. No trate de convertir su mundo al revés y forzar la situación en todos los casos a encontrar. Comience por hacer sus sugerencias sólo cuando se puede pensar en un algoritmo de reemplazo que es manifiestamente superior y también está claro, y estar dispuestos a retroceder si se resiste.

Si te sientes tortuosos, que incluso podría darle consejos, preguntas principales, o cualquier otra técnica que se pueda imaginar para ayudarle a averiguarlo por sí mismo.

Me siento su dolor. Los programadores son realmente stubburn en la naturaleza. Cada uno tiene sus propios principios y normas para la construcción de programas. Si otras opiniones chocan con algunos de entonces, el cambio de opinión del programador es como mover pilares fundamento de un edificio rascacielos. :)

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top