¿Un algoritmo apropiado realmente ayuda a mejorar la calidad y, en última instancia, la eficiencia de un programa?
¿Podemos seguir produciendo un programa de buena calidad sin el algoritmo?
¿Un algoritmo apropiado DEBE estar en la programación moderna?
Creo que esta pregunta tiene una perspectiva histórica.
En los "viejos tiempos" (de los cuales no soy un testigo personal, así que esta es solo mi reconstrucción de esa era; siéntase libre de corregirme si experimentó las cosas de manera diferente). . Así que todo la gente escribió entonces tenía que ser muy eficiente. Por lo tanto, tenían que pensar mucho e investigar para inventar los mejores algoritmos para lograr el espacio / tiempo necesario para realizar el trabajo. Otro factor en esto fue que los desarrolladores estaban trabajando principalmente en lo que podríamos llamar infraestructura : sistemas operativos, pilas de protocolos, compiladores, controladores de dispositivos, editores, etc. Todo esto es usado por mucha gente , así que el rendimiento realmente hace una diferencia.
Hoy en día, tenemos un increíble HW con procesadores multinúcleo y Gigabytes de memoria, incluso en una computadora portátil básica (diablos, incluso en un teléfono móvil). Lo que naturalmente significa que, en muchos casos, el rendimiento, por lo tanto el algoritmo, dejó de ser el problema central, y es más importante proporcionar una solución rápida que proporcionar una solución rápida. OTOH tenemos montones de marcos que nos ayudan a resolver problemas, y encapsulan una gran cantidad de algoritmos al mismo tiempo. Así que incluso cuando no estamos pensando en los algoritmos, es posible que estemos usando muchos de ellos en segundo plano.
Sin embargo, todavía hay áreas donde el rendimiento es importante. En estas áreas, aún debe pensar mucho acerca de sus algoritmos antes de escribir código. La razón es que el algoritmo es el centro del diseño, que determina una gran cantidad de estructuras de datos y relaciones en el código circundante. Y si descubre demasiado tarde que su algoritmo no está escalando bien (por ejemplo, es O (n 3 ), por lo que se vio bien y rápido cuando lo probó en 10 elementos, pero en la vida real lo hará. tener millones), es muy difícil, propenso a errores y lleva mucho tiempo reemplazarlo en el código de producción. Y las microoptimizaciones no lo ayudarán si el algoritmo fundamental no es el adecuado para el trabajo.
Solo para señalar algo:
Un algoritmo es en sí mismo una solución general paso a paso de su problema. Por lo tanto, si resolvió el problema, de hecho utilizó un algoritmo.
El punto más importante aquí es que debe usar algoritmos para resolver problemas, de una manera u otra. La mayoría de las veces es mejor pensar en su problema antes de pasar a la codificación; esta fase a menudo se denomina diseño. Pero, cuánto y de qué manera vas a hacer esto depende de ti.
Además, no debe mezclar el concepto de algoritmo con diagramas de flujo (sospecho que esto está ocurriendo aquí). Los diagramas de flujo son solo una representación gráfica que se puede usar y se usó en los días anteriores para ilustrar un algoritmo. Es bastante obsoleto hoy en día.
EDIT:
De hecho, hay muchas formas de representar un algoritmo y el código del lenguaje de programación es una de ellas. Sin embargo, a menudo es mucho mejor o más fácil no resolver todo el problema de una vez, sino solo un esquema y luego llenar los espacios en blanco a medida que avanza.
Mi favorito personal aquí es pseudo código, y sólo para cubrir un general esquema abstracto del algoritmo en pregunta - es ridículo conseguir en detalles con pseudocódigo , eso es para qué es el código real.
Pero se puede usar código real para el contorno. Por ejemplo, a las personas de TDD les gusta para diseñar el algoritmo a medida que codifican, y como no pueden resolverlo todo en Una vez bien, diseñan un esquema. de la ejecución del programa en real. código, y use objetos simulados (o funciones, métodos ...) como espacios en blanco para ser completado más tarde.
Los diagramas de actividad UML parecen ser una Encarnación moderna del estilo antiguo. diagramas de flujo con notación añadida para Las nuevas cosas como el polimorfismo y multihilo Realmente no puedo decir Qué útil es esto, ya que no lo hice. Realmente los uso mucho - solo soy mencionándolo por completo.
Además, si está basando su algoritmo en el cambio entre estados, entonces un diagrama de estado es bastante útil.
En general, cualquier medio que tengas que simplemente esbozar la idea detrás de un determinado algoritmo es una buena manera de proceder.
Una buena analogía es que debes conocer una receta antes de comenzar a cocinar. Ok, puedes modificarlo a medida que avanzas, pero aún debes saber qué quieres hacer antes de comenzar. Si quiero hacer un estofado de cordero, estaré haciendo cosas muy diferentes que si quiero hacer una hogaza de pan.
El código implementa algoritmos. Intentar escribir código sin haber diseñado el algoritmo es como intentar pintar una casa antes de construir las paredes. Los algoritmos han sido "DEBEN" desde el comienzo de la programación.
Tener fluidez en su idioma ayuda a mejorar la calidad y la productividad. Y resolver pequeños problemas algorítmicos es mucho más útil para eso que repetir el mismo material de MVC 100 veces.
Aunque, supongo que hay otras formas de lograr la fluidez.
¿Se convertirá el algoritmo en DEBE en el dominio de programación moderno?
Ya es un 'must', a menos que estés 'php ninja' escribiendo 'cool codez'. Todas las "mejores" compañías (Google, Amazon, etc.) prueban su experiencia algorítmica en una entrevista, y me imagino que no lo harían sin ninguna razón.
Pero volviendo al punto original, deberías desafiarte constantemente si quieres mejorar. Y dado que los trabajos normales (también conocidos como "ahora escriba a los administradores de CRUD para 100 objetos más") no siempre ofrecen un buen desafío, los algoritmos lo compensan.
Yo diría que necesita al menos una idea inicial de un algoritmo antes de comenzar a codificar. Es probable que revise su idea mientras codifica según las estructuras de datos, etc.
Más tarde, puede revisar el código nuevamente si el perfil sugiere que hay un problema de rendimiento en esa área.
El motivo es que es más rápido corregir errores antes de que hayas escrito el código erróneo.
Más prosaicamente, se miden rutinariamente 10 a 1 diferencias de productividad entre diferentes programadores. Cuando miras a los programadores que están en el nivel de productividad 10 veces, pasan la fracción más pequeña de su tiempo en la codificación. El tiempo para escribir el código no debe ser el cuello de botella. En su lugar, pasan una fracción mayor de su tiempo para asegurarse de que tienen requisitos directos, planificación, pruebas, etc.
A la inversa, cuando observa a los programadores que se sumergen en la codificación sin pausa, inevitablemente tienen que escribir el código una y otra vez, ya que se encuentran con problemas totalmente previsibles, y el resultado final es menos fácil de mantener y tiene más errores. (¿Por cierto, sabía que un promedio del 80% del dinero gastado en el desarrollo de software se encuentra en la fase de mantenimiento? Hacer que las cosas sean fáciles de mantener. Mucho.)
Por lo general, primero los algoritmos y las estructuras de datos, luego el código. Pero depende mucho del dominio de programación. Solía hacer un montón de cosas de tipo matemático aplicado, y realmente miraba el modelo de cascada que prevalecía en ese momento. Esto se debía a que los algoritmos de nivel bajo a medio rara vez podían darse por sentado. Diseñe una estructura grande alrededor de la existencia de subsistemas no escritos, y luego descubra al final del juego que las matemáticas para uno de esos subsistemas cruciales no funcionan (es inestable o lo que sea). Así que siempre pensé en los subsistemas más desafiantes primero, y si había alguna razón para dudar, escribí y la unidad los probé primero. Pero, para algunos dominios con problemas, puede seguir adelante sin mucha planificación.
Diseñe un algoritmo en secciones, luego divida esas secciones y codifique cada una de ellas individualmente. De esa manera puedes mezclar ambos puntos de vista:
Para mí, es prácticamente todo el código. Creo que eso es cierto para los programadores más productivos. Puedo escribir código tan fácilmente como escribo texto.
En la medida de lo posible, trato de capturar requisitos como pruebas ejecutables (código). El diseño es solo una codificación de alto nivel. Es más rápido y preciso capturar el diseño en el idioma de destino que capturarlo de alguna otra forma y luego traducirlo.
Descubrí que la mayoría de los usuarios no pueden revisar efectivamente los requisitos textuales. Lo hacen bien con los casos de uso secuenciales, pero los casos de uso no pueden capturar todos los aspectos de la interfaz de usuario. Por mucho, lo mejor es tomar un primer corte en la implementación, dejar que los usuarios lo prueben, obtener sus comentarios y modificar el código en consecuencia.
Cuando te sientas y comienzas a codificar, tienes un algoritmo en mente, ya sea "diseñado" o no.
Si se sentó y comenzó a codificar sin tener en mente ningún algoritmo completo, estaría haciendo uno de los siguientes:
1) purgar las teclas al azar. Esto probablemente producirá un error de compilación
2) escribiendo código compilable que probablemente haga cualquier cosa excepto lo que quieres que haga
3) escribir código para resolver pequeñas partes del problema y desarrollarlo a medida que avanza de manera agregada, pero sin realmente pensar en el futuro, por lo que finalmente el problema se resuelve, pero el código no es muy eficiente , y con la posibilidad de tener que retroceder y perder tiempo en el camino
Por lo general, las personas programan con un algoritmo en su cabeza. Puede haberse desarrollado o razonado en papel o en algún otro medio.
Puede ser una buena disciplina pensar acerca de su ataque a un problema alejado del teclado, especialmente en sus primeros días como programador. Como han señalado otras respuestas, a medida que adquiere más experiencia, puede mejorar la codificación de algunos trozos más manejables del problema "sobre la marcha". Sin embargo, para problemas grandes o grandes, pensar y diseñar fuera del teclado es útil: cuando se involucra con el código, es más probable que piense en términos de constructos del lenguaje y en cómo abordar la tarea más inmediata en el campo. problema. Mientras que pensar en el problema con, digamos, un lápiz y un papel, te libera más del aspecto del código del idioma y te permite pensar en un nivel más abstracto y abstracto.
Debe dejar de ver la construcción de software como algo fundamental de la construcción de cualquier otra cosa de valor. No lo es. Por lo tanto, como en cualquier otra cosa, siempre se necesita un plan o diseño bien pensado, sin embargo sucinto,
¿Un algoritmo apropiado realmente ayuda a mejorar la calidad y En última instancia, la eficiencia de un programa?
¿Un plan / esquema de construcción apropiado ayuda a construir una casa de calidad de manera eficiente?
¿Podemos seguir produciendo un programa de buena calidad sin el algoritmo?
¿Puede construir una casa de buena calidad de manera eficiente sin un plan de construcción adecuado? Según el Teorema del mono infinito , de forma probabilística, sí (al igual que un millón de monos que escriben al azar por toda la eternidad eventualmente escribirán el completo Obras de Shakespeare.
¿Un algoritmo apropiado DEBE estar en la programación moderna?
Si no quieres ser un mono del código y quieres asegurarte de no entregar un software que se vea y funcione como una mierda, sí, es un deber. Todos los proyectos que he tenido que salvar (porque el código parecía una mierda que puede mantenerse) han comenzado invariablemente con una respuesta negativa a esa pregunta.
De hecho, la programación moderna ha sido el alejamiento del ingeniero de software de programación de cowboy, donde la planificación es de algún tipo si es necesario.
Incluso cuando tiene una biblioteca de algoritmos y estructuras de datos a su disposición (.ie. Boost en C ++ o la biblioteca de colecciones de Java), tiene que saber cómo funcionan esas cosas para usarlas adecuadamente y para componerlas de manera razonable. , algoritmos de nivel superior.
No es mejor. Es mejor no "diseñar" nada. Eso es para las personas que no escriben programas. Ya sabes, las personas con experiencia real del problema en cuestión. Si usted es un matemático, ingeniero o un logístico, está bien, necesita trabajar en el proceso en otro lugar. Pero eso no es 'programación'.
Ponga primero en su lugar algún tipo de prueba y punto de referencia.
Entonces escribe algo, cualquier cosa. Reproduzca-reescriba -loop hasta que se agote el tiempo o ya no pueda mejorar.
Si bien muchos parecen pensar que uno puede hacer cosas con una computadora sin hacer nada en la computadora, creo que este es uno de los mitos más comunes que existen. Arquitectura astronautismos.
Además, no puede optimizar sus algo antes de que se escriba.
IOW, "mantente cerca del metal".
Lea otras preguntas en las etiquetas algorithms