¿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 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?"

Kai Qing
fuente
44
Es una cuestión de magnitudes. Intente crear bases de datos de varios terrabytes en el mundo real con búsquedas y agregaciones en tiempos de respuesta de segundos con miles de solicitudes por minuto. Tu problema no es lo suficientemente grande. Aunque su enfoque está bien, si sigue ese camino hacia su conclusión inevitable, es doloroso y lleva tiempo alcanzarlo.
Jimmy Hoffa
8
Si su idioma tuviera un bucle FOR real, ese problema de evaluación múltiple no estaría sucediendo. Desafortunadamente, la sintaxis de C lo requiere, porque no es realmente un bucle FOR; es un bucle WHILE con una peluca y gafas de nariz grande, y se requiere que acepte cualquier condición arbitraria (o ninguna) para la terminación del bucle.
Mason Wheeler
2
Veo su edición, pero si está tratando de argumentar que estar borracho e imprudente está bien en cualquier contexto, excepto salir de fiesta un viernes por la noche con un conductor designado, probablemente esté ladrando el árbol equivocado.
Robert Harvey
17
¿Cómo sabes que 'evalúa' item.length en cada iteración? Los compiladores son bastante inteligentes. E incluso si obtiene repetidamente item.length, ¿y qué? Odiaría ver código como 'int itemsLength = items.length; for (; i <itemsLength; ...) 'a menos que haya un problema de rendimiento medido.
Kevin Cline
66
Su elemento items.length no tiene absolutamente nada que ver con la "programación adecuada". Es una microoptimización, y los buenos programadores saben mejor que perder el tiempo con ellos hasta que hayan ejecutado un generador de perfiles y sepan dónde están los problemas reales de rendimiento. Las microoptimizaciones y el buen estilo de programación son a menudo opuestos, no lo mismo.
Michael Borgwardt

Respuestas:

65

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.

Robert Harvey
fuente
1
Tiendo a estar de acuerdo. En el trabajo no hago preguntas, está cruzado y punteado. Pero considere que muchas de las cosas que hago para trabajar son cosas que realmente no necesitan ser mantenidas. Pasando tendencia tipo de cosas. Aplicaciones de cumpleaños, cosas que van y vienen. Todo correcto allí, pero realmente no necesitan serlo.
Kai Qing
21
Se puede argumentar que ser disciplinado en todo momento hace que sea más fácil ser disciplinado cuando sea necesario. Algunas personas hacen preguntas sobre el desbordamiento de pila sin presionar nunca la tecla Mayús, utilizando la lógica de que pueden transmitir adecuadamente sus ideas sin ella, y que el idioma inglés es una cosa fluida y evolutiva de todos modos. No encuentro nada más irritante, excepto quizás los creadores de virus que piensan que mi tiempo de CPU es libre.
Robert Harvey
2
@KaiQing Alguien necesita entregarle una aplicación heredada de 5mloc que nació en pascal y se transfirió hacia adelante desde entonces, en su primer intento de agregar o cambiar cualquier funcionalidad en esta aplicación, inmediatamente se dará cuenta de por qué existen las mejores prácticas y se iluminará.
Jimmy Hoffa
55
@KaiQing, Angry Birds tiene que ejecutarse en múltiples plataformas, y si el juego se cuelga durante 2 segundos, el x% de la audiencia se dará por vencido, lo que se traduce en y menos dólares para la gente de Angry Birds. Apuesto a que ha sido escrito muy, muy cuidadosamente. Tal vez esto responde a tu pregunta. Si el código es solo para ti, ¿a quién le importa lo que hagas? Si hay dinero o tiempo de otras personas en juego, entonces es mejor que tengas mucho cuidado.
Charles E. Grant
2
@KaiQing Nadie puede decirle el umbral para eso, es variable de un proyecto a otro y en cada proyecto a lo largo del tiempo. El número de variables que afectan el umbral entre el sistema que se puede mantener y en el que no se confía: LOC, base de usuarios, base de desarrolladores, tipo de aplicación (criptografía vs. crud vs. controladores), robustez de la característica, requisitos de redundancia, criticidad del software (servidor de correo electrónico vs. . dispositivo de soporte vital frente a widget de reloj), plataformas compatibles, pila de tecnología, cantidad de datos que se están transaccionando o analizando, restricciones de auditoría histórica y muchas cosas más afectan cuán malo puede ser el código
Jimmy Hoffa
18

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.

Michael Shaw
fuente
No diría que prefiero el segundo. Alguien editó mi publicación para eliminar la parte de que yo haya hecho que este juego de Android esté casi completamente borracho (solo por diversión) y, como resultado, me sorprende ver que mis elecciones de borracho no hicieron ninguna diferencia en el rendimiento. Reemplacé algunas clases extrañas por otras apropiadas para probar. Sin embargo, estoy de acuerdo en que saber que existen las reglas es más importante que saber cuáles son las reglas ...
Kai Qing
Además, mi idea de la programación "adecuada" es la culminación de las opiniones repetitivas de la comunidad stackoverflow, así como la colección de programadores que llegaron y se fueron en la empresa para la que trabajo. Algunos con títulos de CI, algunos autodidactas. Hay una opinión común en la que basar las cosas y tiendo a estar de acuerdo con lo que todos dicen colectivamente antes de decidir que una forma es correcta y otra es incorrecta. Gracias por participar.
Kai Qing
1
Si parecía que te estaba regañando por romper las reglas, entonces lo expresé mal. Ninguna de las cosas de las que hablaste es algo a lo que me opondría. Intenté señalar que el "espíritu de la ley" es más importante que la "letra de la ley".
Michael Shaw el
Je, no, no pensé que me estabas regañando. Solo estaba siendo comunicativo. Hice esta pregunta por una razón y me alegra que tanta gente haya respondido sin votar cerrada.
Kai Qing
10

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.

Kaz
fuente
Muy bien escrito En mi caso nunca hubo un retorno planificado. Cualquier devolución puede ser incidental, pero no debe descartarse ya que creo que algunos de los mayores éxitos comenzaron como una casualidad. En términos de trabajo del cliente, donde no hay tanto dinero en juego, ya que puede haber un agravamiento si la aplicación se cuelga o algo se convierte en un inconveniente menor, es un umbral más grueso. Si los puntos de referencia se ven bien, pero se sabe que el código no es el más eficiente, entonces nadie vendrá a auditarlo antes de los tiempos de progreso del código y tal vez exija una migración de todos modos ... difícil de decir al respecto.
Kai Qing
En efecto. No siempre podemos hacer algún tipo de caso objetivo. No todos valoran el programa de la misma manera. Suponga que la utilidad principal del programa es el placer de trabajar en él. Eso podría no ser beneficioso para nadie más y nadie pagará por las mejoras (si incluso hay usuarios además del programador), pero es suficiente para justificar mejorarlo de alguna manera.
Kaz
Dos palabras útiles para agregar a su respuesta muy bien escrita - "Inversión especulativa" - lo hace porque especula que habrá un retorno en el futuro.
mattnz
@mattnz: lo que dices es cierto en el sentido de que nadie hace algo sin retorno, incluso si el retorno es una buena risa. Casi todos mis proyectos personales están hechos por el humor. Casi todos ganan lo suficiente para justificar sus requisitos. Ninguno de ellos me ha permitido renunciar.
Kai Qing
Exactamente a todos. Entonces, primero determinamos qué esperamos obtener al escribir este programa, o al continuar haciéndolo. Ese algo podría estar "pasando el tiempo de modo que sea divertido". Pero incluso entonces, podemos pensar: trabajar en tal y tal cosa en tal y tal programa es la mejor manera de lograr la mayor diversión, o dedicamos el tiempo a otra cosa.
Kaz
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 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
Eran Medan
fuente
1
Lamentablemente, hay otra en la lista de no preocuparse por ser adecuada que muchas personas tienen la bendición de no saber: cuando un cliente vomita un sistema antiguo a su cuidado y le dice que necesita hacerlo en una semana. A veces, el tiempo y / o el presupuesto no se prestan a una codificación adecuada y su atención en el proyecto es más una gracia que una transacción comercial. Por ejemplo, si su código usa métodos en gran medida obsoletos pero necesita algunos parches (hablando en un escenario web). No puedo arreglar todo. Debe ensuciarse.
Kai Qing
"Si no es apropiado que mantener el código se convierta en un problema comercial (altos costos de mantenimiento)". Este umbral es en realidad considerablemente más bajo de lo que la mayoría de los desarrolladores sin experiencia se inclinan a creer. Escribir código sólido a menudo se amortiza en cuestión de horas, no días o meses.
PeterAllenWebb
2

¿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?

Mike Dunlavey
fuente
Diría que mi única preocupación es que en mis pruebas no noté diferencias de rendimiento entre el uso incorrecto y adecuado de los tipos de datos para el escenario especificado. Como en su sugerencia, sobrecargué la clase con más datos para ver si era demasiado poco para hacer la diferencia. Al final, ambos se desempeñaron por igual. De acuerdo, solo estoy haciendo un juego básico de tipo RPG. No es como un software bancario o algo complejo. Pero me ha hecho preguntarme si sería mejor para las empresas no ser tan adecuadas todo el tiempo.
Kai Qing el
Dado que el rendimiento es su preocupación, debe preguntarle al programa qué debería estar mirando, no preguntar si su pregunta preconcebida marca la diferencia. Haga clic en este enlace y haga lo que dice. Le dirá en qué está pasando realmente el programa el tiempo, y eso le dirá cómo hacerlo más rápido.
Mike Dunlavey el
Bueno, el rendimiento fue mi base para el procedimiento de cuestionamiento, no necesariamente una preocupación. No estoy buscando un punto de referencia por decir. Simplemente observar que el código ineficiente no hizo ninguna diferencia de rendimiento. Es esencialmente transparente para el usuario cuán eficiente o ineficiente era el programa, por lo que la preocupación por tal perfil es irrelevante. Por supuesto, tenía que preocuparme por el punto de referencia en primer lugar, pero fue principalmente curiosidad. Y si el producto está terminado y es notablemente lento, entonces sí, un perfilador tiene sentido. Gracias por el enlace
Kai Qing
2

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?

Dan Perkins
fuente
1

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 ...

jmoreno
fuente
1
"nunca" y "siempre" se cancelan entre sí. Hacer que su respuesta sea buena y mala.
Tulains Córdova
@ user1598390: su cancelación mutua fue el punto. Cancele el dogma y quedará con lo que parece útil. Y te equivocarás y aprenderás de eso.
jmoreno
Quiero decir que estoy de acuerdo contigo, pero no lo habría llevado a tales extremos. No creo que a menudo solo se escupen, se escapen de las pruebas o la depuración. El hecho de que no esté optimizado y perfectamente diseñado no lo convierte en un producto menor si el rendimiento y la estabilidad no se ven afectados por el shortcust. Cuál es mi punto final y por qué me pregunto por qué todo el mundo apesta tanto a la codificación de ejemplos que no son de primera línea. Sucede mucho en stackoverflow.
Kai Qing
@KaiQing: las pruebas y la depuración ocurren, por supuesto, pero generalmente se limitan a lo que existe en este momento, por ejemplo, si el proceso puede fallar con un archivo que tenía una codificación UTF y ninguno de los archivos en los que está trabajando realmente no lo pruebes. La optimización debe hacerse cuando se ha identificado un problema de rendimiento. En cuanto a por qué un hedor sobre ejemplos de codificación que no son de primera línea en SO, creo que esa es una función de los objetivos del sitio. Su objetivo es ser un recurso permanente, por lo tanto, el código en las respuestas (e incluso las preguntas) se consideran como una plantilla que otros usan.
jmoreno
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, 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).

m3th0dman
fuente
Sin embargo, no creo estar de acuerdo con eso. En mi publicación no menciono ninguna diferencia en el rendimiento. Eso sugeriría que no hay un producto promedio o excelente, sino un equilibrio igual a pesar de las deficiencias de uno. Sin embargo, estaría de acuerdo con su declaración si hubiera un proyecto específico de gran importancia que todos estuviéramos utilizando como comparación. Pero, en resumen, la observación general es que en este proyecto anónimo, una clase decididamente ineficiente se desempeñó por igual con una optimizada. Entonces, ¿está bien adoptar una actitud floja sobre esto o defender la perfección cada vez?
Kai Qing
@Kai Qing Una sola clase no hace (o no debería) hacer una gran diferencia. Lo dije: si espera que su producto sea de alta calidad, preste atención a los detalles (incluso si esto significa una posible pequeña optimización o un diseño cuidadoso); Por otro lado, si lo único que desea es un sistema funcional, entonces probablemente no debería prestar mucha atención a los pequeños detalles.
m3th0dman el
Sí, tiene razón, no debería marcar la diferencia, incluso si solo se pone un poco de cuidado en su diseño. Pero puede hacer una diferencia dependiendo de su propósito o si en general su propósito se transformó con el tiempo y se convirtió en algo que no estaba destinado a ser. Visto eso antes, pero solo voy por una tangente aquí. Para ser justos, un producto puede ser de alta calidad sin tener que ser más que funcional.
Kai Qing el
1

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.

Daniel Hollinrake
fuente
1
Sí, lo sé, pero el punto de la pregunta es principalmente que en el contexto más pequeño y contenido no parece haber una razón para ser tan apropiado. En todos mis años de programación, realmente no ha habido mucho retroceso para mordernos. Dudo que seamos tan apropiados. Creo que es que los idiomas y las expectativas cambian como el software normal. Algunos menos que otros. Pero al final, la ineficiencia de un proyecto solo puede darse cuenta cuando el proyecto está en el pasado y ya no es esencial. Hace que sea difícil justificar el dolor de cabeza de ser tan rígido.
Kai Qing
Ese es un punto justo. Las reglas de hoy pueden ser las restricciones de mañana. No disfruto que me digan qué hacer, pero sí respeto a los demás que se han ido antes y han aprendido por las malas. A veces, aunque puede ser interesante averiguar qué reglas son útiles y cuáles han pasado su fecha de caducidad.
Daniel Hollinrake
1

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.

Bryan Oakley
fuente
Encontré instancias en la programación donde el código no necesitaba ser mantenible o funcionar fuera de las necesidades. Al igual que las utilidades de kiosco para ferias o eventos que son muy específicos y que probablemente no se reutilizarán. En el caso de mi propio juego, soy el único que lo mantiene, por lo que ese argumento puede no ser el más aplicable. Todavía tengo dudas sobre la perspectiva común del "mejor programador" porque el cumplimiento rígido de las directrices, la mantenibilidad y el uso adecuado de los tipos de datos pueden ser un desánimo suficiente para no completar el proyecto. Si el código funciona como se esperaba, ¿por qué perfeccionarlo?
Kai Qing
Incluso si el software que está construyendo correctamente no necesita mantenimiento, escribir el software como si lo hiciera fortalece sus habilidades de codificación. Cuando finalmente tenga que escribir código que se pueda mantener, podrá hacerlo más fácilmente.
Bryan Oakley el
Tengo que escribir código mantenible todo el tiempo. Solo en algunos casos no tiene que ser así. Sin embargo, tengo mucha experiencia, así que normalmente sé cuándo y dónde cortar esquinas. El objetivo de esta publicación era provocar una conversación sobre el umbral de lo apropiado y descuidado para cualquier propósito. Mi ejemplo solo se aplica ligeramente, ya que el ejemplo dado es mayormente inofensivo en una aplicación más pequeña. Sin embargo, si estuviera escribiendo software bancario, nunca sería tan descuidado.
Kai Qing