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

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 se hace por mí.

Durante el desarrollo, seleccioné descuidadamente los tipos de datos para algunos procedimientos. Usé 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 en Stack Overflow, veo a muchas personas simplemente leyendo las preguntas que usan un cierto tipo de datos cuando otro es técnicamente "adecuado". Como usar una ArrayList porque no requiere límites definidos versus 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 lugar del adecuado, sigo el tutorial y utilizo los tipos de datos exactos sugeridos por la comunidad. Los resultados: lo mismo. Promedio 45 fps. Abrí todas las aplicaciones en la pestaña del teléfono y la galaxia. Ninguna diferencia.

Entonces, supongo que mi pregunta es la siguiente: ¿hay un umbral cuando ya no es importante ser apropiado? ¿Está bien decir: "mientras haga el trabajo, no me importa?"

Escribes un programa para resolver un problema. Ese problema se acompaña de un conjunto específico de requisitos para resolverlo. Si se cumplen esos requisitos, el problema se resuelve y se logra el objetivo.

Eso es.

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

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

En el extremo opuesto del espectro están las 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; piratean la cosa juntos, la ejecutan y continúan con lo siguiente.

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

Hay una vieja y sabia cita: "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 que no debe poner una prueba que podría recalcularse repetidamente en un ciclo for como ese. 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 para 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 que preocuparse por la diferencia de rendimiento.

Prefiero la primera respuesta correcta, y parece que prefieres la segunda. No te equivocas con eso. Creo que está equivocado en su idea de lo que se trata la programación 'adecuada'. No se trata de seguir un conjunto de reglas seleccionadas al azar que no lo ayudan y no tienen ningún propósito. Si no arregla el bucle for en el ejemplo, en realidad está siguiendo una muy buena regla contra la optimización prematura.

La verdadera programación adecuada consiste en seguir buenas reglas que tengan sentido de manera inteligente.

La forma correcta de ver esto es la disminución de los beneficios: 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.

¿Puedes hacer un caso de negocios para items.lengthsalir del forcírculo? Económicamente, ¿puede ese cambio incluso justificar el tiempo dedicado a tratar de justificarlo? Como no hay diferencia en la experiencia del usuario, nunca obtendrá nada ni siquiera por el tiempo dedicado a medir (aparte de una lección útil para recordar). A los usuarios no les gustará más el programa que a ellos, y no se venderán más copias como resultado de ese cambio.

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 ser víctimas de factores no considerados que solo serán obvios en retrospectiva. Los cambios propuestos pueden ser completamente no triviales, de modo que hacen una gran diferencia.

El tipo de pensamiento de rendimientos decrecientes puede equivaler a una búsqueda de excusas para no tomar alguna medida, y evitar correr riesgos, lo que en retrospectiva podría ser una serie de oportunidades perdidas.

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

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 le paguen)
• MVP / POC: si escribir el código adecuado significa perder tiempo en un concepto antes de saber cómo ganar dinero con él (si pasas años y 45 millones de dólares escribiendo tu aplicación y terminas cerrando la tienda porque no tenía mercado, a nadie le importa cómo apropiado fue el código)
• Al tener una situación que amenaza la vida (por ejemplo, el prototipo 1 de Iron Man era un truco sucio, pero lo sacó de la cueva, ¿verdad?)
• o si simplemente no sabe cómo escribir el código adecuado (si alguien logra ganarse la vida escribiendo un código incorrecto, en el desempleo de hoy, digo, es mejor escribir un código incorrecto que no tener hogar)
• si simplemente sabes lo que estás haciendo o crees que puedes salirte con la tuya fingiendo que lo haces

Cuando escribir el código apropiado

• Si tendrá un impacto comercial significativo, por ejemplo, el rendimiento afectará los ingresos o evitará las ventas.
• Si no es correcto, mantener el código se convierte en un problema comercial (altos costos de mantenimiento)
• Si eres un programador conocido que trabaja en un gran proyecto de código abierto
• Lo mismo para una gran empresa que contribuye con una biblioteca interna al mundo.
• Si quieres mostrar tu trabajo como un portafolio en futuras entrevistas

¿Es el rendimiento su 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 hacerlo más rápido, eso es adivinar. Si está preguntando "¿Debería usar esta clase de contenedor o aquella?", O "¿Debería ponerme lengthen condición de bucle?", Es como un médico que atiende a un paciente e intenta decidir qué tratamiento administrar sin realmente interrogar o examinar al paciente.

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

En cambio, deje que el programa mismo le diga cuál es su problema. Aquí hay un ejemplo detallado.

¿Ves la diferencia?

Su pregunta es "siempre y cuando haga el trabajo, ¿no me importa?"

Mi respuesta es: "nunca se sabe lo que sucederá con su código". He estado involucrado en muchos proyectos que comenzaron como "oye, déjame escribir esto rápido para solucionar el problema de un usuario". Escríbelo, publícalo, nunca lo pienses más.

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

Me doy cuenta de que "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 su 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 vilipendia en tableros de mensajes como este?

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

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

Siempre es importante porque la programación adecuada es una herramienta que lo ayudará a alcanzar sus objetivos. La forma correcta de hacer las cosas es simplemente reconocer que hacerlo de otra manera causa más dolor a largo plazo de lo que ahorra.

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

Las herramientas únicas generalmente se realizan lo más rápido y sucio posible, con poca o ninguna verificació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, etc. .

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

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?

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 fuera así, la longitud es un campo público en el objeto de matriz; acceder a él no cuesta.

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

Realmente depende de lo que esperes de tu producto final; La diferencia entre un producto promedio y un gran producto se basa en los detalles. Un automóvil como Tata Nano y un automóvil como Mercedes S "hacen el trabajo", lo llevan de un lugar a otro. La diferencia radica en los detalles: potencia del motor, comodidad, 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 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, debe preocuparse por estas cosas (y por otras cosas, obviamente).

Si está programando en casa para usted mismo, entonces tal vez pueda cortar algunas esquinas; y cuando experimentas y pruebas las cosas, esto está completamente justificado.

Sin embargo ten cuidado. En el ejemplo que da no hay realmente ninguna necesidad de cortar esa esquina, y debe tener cuidado. Esto podría iniciar una tendencia y los malos hábitos que haces en casa podrían colarse en tu código en el trabajo. Es mucho mejor practicar y mejorar los buenos hábitos en casa 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 ejercicio. Haz que valga la pena, de lo contrario volverá y te morderá.

Mira el lado bueno sin embargo. Has preguntado sobre esto, así que tal vez ya estés al tanto del punto que estoy haciendo.

Si un fabricante de muebles estaba haciendo un mueble para usar donde la calidad no era de suma importancia o donde la calidad podría pasar desapercibida, ¿deberían tratar de hacer sus cortes rectos y hacer un trabajo adecuado uniendo las piezas?

Muchas personas ven el software como un trabajo artesanal. Lo que construimos no solo debe realizar una función, debe ser confiable, fácil de mantener y robusto. Hacer dicho software requiere habilidad, y esa habilidad proviene de la práctica.

Por lo tanto, 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 utilizar las construcciones adecuadas en todo momento, con el tiempo, lo convertirá en un mejor programador.