¿Cuándo ya no importa la programación "adecuada"?

49

He estado construyendo un juego para Android en mi tiempo libre. Está utilizando la biblioteca libgdx , por lo que una gran parte del trabajo pesado ya está hecho para mí.

Durante el desarrollo, seleccioné sin cuidado los tipos de datos para algunos procedimientos. Utilicé una tabla hash porque quería algo cercano a una matriz asociativa. Valores clave legibles por humanos. En otros lugares para lograr cosas similares, uso un vector. Sé que libgdx tiene clases vector2 y vector3, pero nunca las he usado.

Cuando me encuentro con problemas extraños y busco ayuda de Desbordamiento de pila, veo que muchas personas simplemente resienten las preguntas que usan un determinado tipo de datos cuando otro es técnicamente "correcto". Como usar un ArrayList porque no requiere límites definidos en lugar de redefinir un int [] con nuevos límites conocidos. O incluso algo trivial como este:

for(int i = 0; i < items.length; i ++)
{
    // do something
}

Sé que evalúa item.length en cada iteración. Sin embargo, también sé que los artículos nunca serán más de 15 a 20 artículos. Entonces, ¿debería importarme si evalúo items.length en cada iteración?

Realicé algunas pruebas para ver cómo funciona la aplicación utilizando el método que acabo de describir en comparación con el correcto, siga el tutorial y use los tipos de datos exactos sugeridos por la comunidad. Los resultados: Lo mismo. Promedio de 45 fps. Abrí todas las aplicaciones en la pestaña del teléfono y la galaxia. No hay diferencia.

Así que supongo que mi pregunta es esta: ¿hay un umbral cuando ya no importa ser apropiado? ¿Está bien decir que "mientras se haga el trabajo, no me importa?"

    
pregunta Kai Qing 20.11.2012 - 23:46

10 respuestas

65

Usted escribe un programa para resolver un problema. Ese problema está acompañado por un conjunto específico de requisitos para resolverlo. Si se cumplen esos requisitos, el problema se resuelve y el objetivo se alcanza.

Eso es todo.

Ahora, la razón por la que se observan las mejores prácticas es porque algunos requisitos tienen que ver con la capacidad de mantenimiento, la capacidad de prueba, las garantías de rendimiento, etc. En consecuencia, tienes esas personas molestas como yo que requieren cosas como el estilo de codificación adecuado. No se necesita mucho más esfuerzo para cruzar tus T y salpicar tu I, y es un gesto de respeto para aquellos que tienen que leer tu código más tarde y descubrir qué hace.

Para sistemas grandes, este tipo de moderación y disciplina es esencial, porque tiene que jugar bien con los demás para que todo funcione, y tiene que minimizar la deuda técnica para que el proyecto no se derrumbe bajo su propio peso. .

En el extremo opuesto del espectro se encuentran aquellas utilidades únicas que escribe para resolver un problema específico en este momento, utilidades que nunca volverá a usar. En esos casos, el estilo y las mejores prácticas son completamente irrelevantes; lo hackeas, lo ejecutas y sigues con lo siguiente.

Entonces, como con tantas cosas en el desarrollo de software, depende.

    
respondido por el Robert Harvey 20.11.2012 - 23:52
18

Hay una vieja cita sabia: "No sigas los pasos de los sabios de la antigüedad. Busca lo que buscaban". Hay razones para todas las reglas de codificación "adecuada". Saber por qué existen esas reglas es más importante que saber cuáles son esas reglas.

Hay una regla de que no deberías poner una prueba que podría recalcularse repetidamente en un bucle for así. En los casos en que la regla se inventó para remediar (donde el rendimiento sería realmente diferente), tiene sentido. En ese caso, solo hay una respuesta correcta. En su ejemplo, se sabe que no hay diferencia de rendimiento y que no puede haber más de un par de docenas de iteraciones. En este caso, hay dos respuestas correctas, ya sea aplicar la regla de todos modos, ya que es simple y no dañará nada y podría ayudar a formar buenos hábitos, o ignorar la regla, ya que no hay una diferencia de rendimiento de la que preocuparse.

Prefiero la primera respuesta correcta, y parece que prefieres la segunda. No estás equivocado sobre eso. Creo que estás equivocado en tu idea de lo que se trata la programación "adecuada". No se trata de seguir un conjunto de reglas seleccionadas al azar que no te ayudan y no tienen ningún propósito. El hecho de que no corrija el bucle for en el ejemplo es en realidad una muy buena regla contra la optimización prematura.

La verdadera programación correcta consiste en seguir buenas reglas que tienen sentido de una manera inteligente.

    
respondido por el Michael Shaw 21.11.2012 - 02:23
10

La forma correcta de ver esto es disminuir los rendimientos: comparar el beneficio adicional de desarrollar el programa con el costo del desarrollo adicional.

Los rendimientos decrecientes se establecen cuando el beneficio marginal es menor que el tiempo / esfuerzo marginal.

¿Puede presentar un caso de negocios para mover items.length fuera del bucle for ? Económicamente, ¿puede ese cambio incluso justificar el tiempo dedicado a justificarlo? Ya que no hay diferencia en la experiencia del usuario, nunca obtendrá nada ni siquiera por el tiempo dedicado a la medición (que no sea una lección útil para recordar). A los usuarios no les gustará el programa más de lo que lo hacen, y como resultado de ese cambio, no se venderán más copias.

Esto no siempre es fácil de evaluar, porque los casos de negocios están llenos de incógnitas y riesgos y, por lo tanto, son susceptibles de caer en factores no considerados que solo serán evidentes en retrospectiva. Los cambios propuestos pueden ser completamente no triviales, por lo que hacen una gran diferencia.

Disminuir-devuelve el tipo de pensamiento puede constituir una búsqueda de excusas para no tomar alguna acción y evitar tomar riesgos, lo que en retrospectiva puede ser una serie de oportunidades perdidas.

Pero a veces es obvio cuando no hacer algo. Si alguna parte del desarrollo parece requerir que ocurra un milagro económico solo para pagar el costo del desarrollo (punto de equilibrio), probablemente sea una mala idea.

    
respondido por el Kaz 21.11.2012 - 01:18
3

Cuando no debería importarle que su código sea "correcto"

  • Si logra responder al objetivo comercial y mantenerlo a lo largo del tiempo con gastos generales bajos. (los usuarios no ven la fuente antes de que te paguen)
  • MVP / POC - Si escribir el código correcto significa perder tiempo en un concepto antes de saber cómo ganar dinero con él (si pasa años y 45 millones de dólares escribiendo su aplicación y termina cerrando la tienda porque no tenía mercado, no a uno le importa lo correcto que era el código)
  • Cuando se tiene una situación que pone en peligro la vida (por ejemplo, el prototipo 1 de Iron Man fue un truco sucio, pero lo sacó de la cueva, ¿no?)
  • o si simplemente no sabe cómo escribir el código correcto (si alguien consigue ganarse la vida escribiendo un código incorrecto, en el desempleo de hoy, es mejor escribir un código incorrecto que quedarse sin hogar)
  • si simplemente sabe lo que está haciendo o piensa que puede salirse con la suya fingiendo que lo hace

Cuándo escribir el código correcto

  • Si tendrá un impacto comercial significativo, por ejemplo, el rendimiento afectará los ingresos o evitará las ventas
  • Si no es correcto, el mantenimiento del código se convierte en un problema comercial (altos costos de mantenimiento)
  • Si usted es un programador conocido que trabaja en un gran proyecto de código abierto
  • Lo mismo para una gran empresa que aporta una biblioteca interna al mundo
  • Si desea mostrar su trabajo como un portafolio en futuras entrevistas
respondido por el Eran Medan 21.11.2012 - 07:09
2

¿Es el desempeño tu principal preocupación? ¿Es eso lo que estás tratando de maximizar?

Si es así, hay una lección fundamental que aprender, y si lo haces, serás uno de los pocos.

No intentes "pensar" lo que debes hacer para que sea más rápido, eso es adivinar. Si está preguntando "¿Debo usar esta clase de contenedor o esa?", O "¿Debo poner length en la condición de bucle?", Es como un médico que atiende a un paciente y trata de decidir qué tratamiento recibir. Dar sin realmente cuestionar o examinar al paciente.

Eso es adivinar. Todos lo hacen, pero no funciona.

En su lugar, deja que el programa te diga cuál es su problema. Aquí hay un ejemplo detallado.

¿Ves la diferencia?

    
respondido por el Mike Dunlavey 22.11.2012 - 05:59
2

Su pregunta es "siempre que se haga el trabajo, no me importa?"

Mi respuesta es: "nunca se sabe lo que pasará con su código". He estado involucrado en tantos proyectos que comenzaron como "hey, permítanme escribir algo rápido para solucionar el problema de un usuario". Escríbelo, exprésalo, nunca lo vuelvas a pensar.

Una vez, esa cosa que escribí se transformó en "oh, ahora el departamento completo del usuario quiere usar ese código", que antes de que pudiera cambiar se convirtió en "toda la compañía está usando ese código y ahora tengo que demostrar que lo hará". sobrevive a una auditoría y hay una revisión del código de 20 personas programada para mañana y algún vicepresidente ya lo vendió a nuestros clientes ".

Me doy cuenta de que solo estás "escribiendo un juego de Android en tu tiempo libre", pero nunca sabes si ese juego despegará y se convertirá en tu boleto a la fama y la fortuna. Peor aún, ese juego podría convertirse en tu boleto a la infamia porque sigue bloqueando los teléfonos de las personas. ¿Quieres ser la persona que recibe una oferta de trabajo porque los hijos de alguien no pueden dejar de jugar tu juego en sus teléfonos, o quieres ser la persona que se ve vilipendiada en foros como este?

    
respondido por el Dan Perkins 02.08.2013 - 18:22
1

La respuesta es que nunca importa, y siempre importa ...

Nunca importa porque la programación, propiamente o no, es una forma de lograr un objetivo, no un objetivo en sí mismo. Si ese objetivo se logra sin la programación "adecuada", está bien (desde una perspectiva empresarial, a menudo es mejor si el objetivo se puede lograr sin programación).

Siempre importa porque la programación adecuada es una herramienta que lo ayudará a alcanzar sus metas. La forma correcta de hacer las cosas es simplemente el reconocimiento de que hacerlo de otra manera causa más dolor a la larga que lo que ahorra.

Lo que responde a la pregunta de cuándo puede ignorarlo, cuando esté seguro de que otra forma será más fácil a largo plazo (posiblemente porque no lo habrá).

Las herramientas únicas se hacen tan rápido y sucio como sea posible, con poca o ninguna comprobación de errores u otra validación, sin registro de excepciones, código de cortar y pegar con cambios menores o incluso sin cambios en lugar de funciones genéricas, y así sucesivamente.

Solo ten cuidado: a veces esas aplicaciones rápidas y sucias cobran vida propia, lo que significa que todos los atajos te pican en el ...

    
respondido por el jmoreno 22.11.2012 - 06:45
1
  

O incluso algo trivial como este:

for(int i = 0; i < items.length;i ++) {
     // do something 
}
  

Sé que evalúa item.length en cada iteración. Sin embargo, yo también   Saber que los artículos nunca serán más de 15 a 20 artículos. Entonces, ¿debería importarme si   Evalúo items.length en cada iteración?

En realidad, en el código final, items.length no se evaluará en cada iteración porque el compilador lo optimiza. E incluso si no lo fuera, la longitud es un campo público en el objeto de matriz; acceder a él no cuesta.

  

Así que supongo que mi pregunta es esta: ¿hay un umbral cuando ya no importa > que sea apropiado? ¿Está bien decir que "siempre que se haga el trabajo, no me importa?"

Realmente depende de lo que esperas de tu producto final; La diferencia entre un producto promedio y un gran producto se basa en los detalles. Un auto como Tata Nano y un auto como Mercedes S "hacen el trabajo": lo lleva de un lugar a otro. La diferencia radica en los detalles: potencia del motor, confort, seguridad y otros. Es lo mismo con cualquier producto que exista, incluidos los productos de software; por ejemplo, ¿por qué alguien pagaría a Oracle, IBM o Microsoft por la base de datos de Oracle, DB2 o MS SQL Server, ya que MySQL y Postgre son gratuitos?

Si desea prestar atención a los detalles y obtener un producto de alta calidad, debería preocuparse por estas cosas (y sobre otras cosas, obviamente).

    
respondido por el m3th0dman 22.11.2012 - 08:28
1

Si estás programando en casa para ti mismo, quizás puedas cortar algunas esquinas; y cuando estás experimentando y probando, esto está completamente justificado.

Sin embargo ten cuidado. En el ejemplo que da, realmente no hay necesidad de cortar esa esquina, y debe tener cuidado. Esto podría iniciar una tendencia y los malos hábitos que usted hace en su casa podrían introducirse en su código en el trabajo. Es mucho mejor practicar y mejorar los buenos hábitos en el hogar y dejar que se filtren en su código en el trabajo. Te ayudará y ayudará a otros.

Cualquier programación que hagas y cualquier pensamiento que hagas sobre la programación es un ejercicio. Haz que valga la pena, de lo contrario volverá y te morderá.

Mira el lado bueno sin embargo. Has preguntado acerca de esto, así que quizás ya estés al tanto del punto que estoy haciendo.

    
respondido por el Daniel Hollinrake 28.11.2012 - 10:52
1

Si un fabricante de muebles estaba fabricando un mueble para usar donde la calidad no era lo más importante o donde la calidad podría pasar desapercibida, si aún así intentan corregir sus cortes y hacen un trabajo adecuado para unirse a la ¿piezas juntas?

Mucha gente ve el software como artesanía. Lo que construimos no solo debe realizar una función, sino que debe ser confiable, fácil de mantener y robusto. Hacer este tipo de software requiere habilidad, y esa habilidad viene de la práctica.

Entonces, aunque la elección de una construcción en bucle para lo que está trabajando hoy puede no importar, el hecho de que se esfuerce por usar las construcciones adecuadas en todo momento lo hará, con el tiempo, un mejor programador.

    
respondido por el Bryan Oakley 02.08.2013 - 19:15

Lea otras preguntas en las etiquetas