- En la programación competitiva, usted escribe la solución, la arroja al juez y una vez que obtiene una marca verde, entonces tira su solución. Eso es todo y eso es todo. En el mundo real, se supone que no debes hacer eso. Una vez que empuje su código a producción, no obtendrá una marca verde. Si piensa que la garrapata verde “funciona correctamente”, entonces podría volverse roja. Pueden ocurrir cosas inesperadas como un aumento repentino de la carga en el servidor. Nunca sabes. Además, se supone que el código se ejecutará durante mucho, mucho tiempo hasta que sea reemplazado por el mejor sistema.
- En la programación competitiva, las restricciones son fijas y no habrá ambigüedad en la declaración del problema. En el mundo real, la ambigüedad es la norma más que una excepción. Además, las restricciones cambian con el tiempo, se vuelven más estrictas. Tienes que escalar. Toma Facebook, por ejemplo. Comenzó con una base pequeña y ahora tiene miles de millones de usuarios. ¿Sabían que esto sucedería? Diablos no!
- A menos que trabaje con plazos muy ajustados, no importa qué tan rápido produzca el código. En la programación competitiva, la corrección se trata de obtener una marca verde . El sistema no se preocupa por las pérdidas de memoria, sin importar cuán desenfrenado esté en su código. El sistema no se preocupa por las abstracciones que usas.
- En la programación competitiva, la entrada no válida es el problema del emisor del problema. En el mundo real, manejar los casos de entrada no válida es su problema . No puede culpar al usuario por ingresar algo que no debería.
- En la programación competitiva, estará bastante seguro de que al menos alguien ha resuelto el problema. Es decir, sabes que la solución existe. Pero en el mundo real, no tienes esa red de seguridad .
- En la programación competitiva, lo único que le importa es utilizar el algoritmo y la estructura de datos correctos para exprimir su solución dentro del límite de tiempo y espacio. En el mundo real, no se trata solo de algoritmos y estructura de datos, sino que también habrá problemas de diseño y arquitectura . Las fallas arquitectónicas pueden ser muy difíciles de corregir una vez que implementa la solución.
- La mayoría de las soluciones de programación competitivas son solo archivos individuales, con un máximo de 300 líneas de código. Pero los proyectos del mundo real abarcan cientos de miles, a veces millones de líneas de código. Es en conjunto una escala diferente. ¿Alguna vez ha encontrado términos como “infierno de dependencia” en la programación competitiva? Apuesto a que no lo has hecho. En la programación competitiva, todo lo que usa es una biblioteca estándar. En el mundo real, puede usar bibliotecas para simplificar la tarea. Pero cada dependencia puede dificultar las cosas.
- Muchos problemas no son de naturaleza algorítmica . Como programador competitivo, responda estas preguntas sobre confiabilidad (esto es solo un ejemplo).
- ¿Has pensado en fallas de la red o congestión en la red?
- ¿Has pensado en el bloqueo del disco?
- ¿Has pensado en máquinas muriendo y recuperándose de tales situaciones?
- La mayoría de las competencias de programación tratan de escribir programas de subproceso único. En el mundo real, su código tiene que aprovechar los recursos de hardware tanto como sea posible. El código distribuido, concurrente y paralelo tiene un montón de problemas como livelock, deadlock, carreras de datos, condiciones de carrera, etc. Bonus: ¿Has oído hablar del término ‘heisenbug’?
¿Por qué los programadores experimentados dicen que la programación del mundo real es completamente diferente a la programación competitiva?
Related Content
Cómo hacer un juego de programa de asesor de IA en Unity3D
¿En qué situaciones alguien usaría Dijkstra sin un montón sobre Dijkstra con un montón?
¿Cuándo es bueno representar un árbol binario como una matriz?
Porque esos “programadores experimentados” no experimentaron un proyecto que requería habilidades suficientemente similares a las que las élites de programación competitivas son buenas (¡tal vez porque no los poseen en primer lugar!), O excluyen a aquellos de la “programación del mundo real “.
En lugar de decir “programación del mundo real”, déjenme decir “programación sin restricción de una competencia”. Allí, todavía se necesitan muchas tareas en la programación competitiva, y muchas de las virtudes de los programas que necesita cuando está en una competencia aún son válidas.
En la programación competitiva, debe solicitar una aclaración de las declaraciones de problemas vagos, pensar en algoritmos centrales, hacer diseños, crear subproblemas e implementar y probar cada parte. Debe discutir dentro de su grupo para asegurarse de que sea la mejor solución a la que tenga acceso. Debe escribirlos de manera que los socios puedan depurarlos y comprenderlos. Lo mismo en el mundo real.
Pero cuando no estás en una competencia, generalmente tienes más flexibilidad. Ya no hay un juez jugando a ser dios y tienes que hacer todo lo que exige. Puedes negociar. Puede solicitar computadoras más potentes si la solución que obtiene no es tan eficiente como se esperaba. Puede discutir con sus clientes si se pueden reducir algunos requisitos para hacer un tiempo de entrega más temprano. Puede buscar en la web si no está familiarizado con un algoritmo o alguna sintaxis. Puede usar una biblioteca avanzada para que no necesite depurarlas. Y así.
También encontrará que necesita interactuar más con otro software. En las competiciones, los problemas suelen estar restringidos porque tienen que ser neutrales a los lenguajes de programación utilizados por los concursantes. Esto se levanta cuando no hay marco de competencia. Por lo general, interactuará con el sistema operativo, la plataforma, los servicios en la nube, otros programas en el sistema, otras bibliotecas, etc. Esto significa que necesita comunicación entre hilos, procesos y computadoras mucho más, y por lo tanto una gran cantidad de técnicas y precauciones cuando haciendo tales cosas.
Y cuando no está en una competencia, el tiempo de programación no es tan limitado. Como resultado, se le permite pasar más tiempo y trabajar en problemas mucho más grandes. Y para satisfacer la extensión de su programa, agregará técnicas para automatizar parte de su proceso de programación: realiza comprobaciones automáticas contra el estándar de codificación, crea un repositorio de código para registrar y combinar cambios, crea pruebas automatizadas y las ejecuta al comprometerse o todas las noches (dependiendo de cuánto tiempo necesiten ejecutarse las pruebas), crea un proceso automatizado para implementarlos en servidores reales, etc. Ninguno de ellos es imaginable en una competencia.
Dependiendo de la tarea que tenga, las habilidades algorítmicas que necesita pueden ser (y generalmente) menores que en la competencia, aunque aún le darán una ventaja. Y hay algunas habilidades y métodos adicionales que se vuelven importantes cuando el mundo no está restringido por una competencia de programación. Eso es todo.
La programación en el mundo real se trata de manejar errores de todo tipo posible: usuario agregado, red agregado, sistema agregado, base de datos agregada y muchas más fuentes que conocerá solo cuando comience a trabajar para una organización.
No terminas un proyecto del mundo real en una semana y luego te relajas. Tendrá revisiones de código, fase de validación con informes de errores que deben analizarse y lo mejor que puede suceder es Legacy Code . A menos que sea un desarrollador superestrella, tiene la posibilidad de trabajar en el código heredado para el 50-90% de su exceso de antigüedad en cualquier organización (excepto las startups).
El código heredado será lo que otros hayan escrito antes que usted y lo más probable es que su primer proyecto sea un proyecto heredado, sin importar cuán buen programador sea. Raramente se asigna un nuevo desarrollador a un nuevo proyecto, a menos que esa sea la única razón por la que fue contratado. El código heredado significa decenas de miles de líneas de código y probablemente lakhs, que debes saber como el dorso de tu mano. Debería poder predecir el cambio en el comportamiento del software si alguno (o se modifican / eliminan más líneas). No hablar de encontrar y corregir errores en estos miles y miles de millones de líneas de código, cuando el autor original ya ha abandonado la organización. Mi primer proyecto fue algo como esto.
Tendrá que trabajar en equipos, lo que ya puede estar haciendo en la programación competitiva. En el mundo real, el nivel de pares puede no ser tan inteligente como usted o más inteligente que usted. Los conflictos de ego y la diferencia de opiniones sobre cómo hacer cosas en el código se reducirán a menos que realmente sepa cómo manejar a los demás. Créame, esta es la parte más difícil del trabajo: ¿manejar y administrar compañeros de trabajo?
Tendrá un gerente que siempre encontrará que llega tarde a la oficina y demora en sus entregas. Si este mes termina un proyecto en 2 meses que se suponía que tomaría 3 meses, la próxima vez se espera que haga un trabajo similar en menos de 1.5 meses. Ahora tienes experiencia, ¿verdad?
Para resumir, programar para organizaciones no es solo programar. Es mucho más y puede ser aburrido. Necesitarás dosis de automotivación todo el tiempo.
Imagine que las competencias duraron una cantidad de tiempo indefinida, y los organizadores podrían llamarlo cada seis meses más o menos para decirle que las reglas han cambiado y que necesita actualizar su programa.
Desenterra tus archivos de la competencia del año pasado y mira tu código. Sé honesto conmigo: ¿cómo te sientes acerca de la propuesta anterior?
¿Es su código general, bien documentado y obvio, o es especializado, carece por completo de comentarios (no importa los documentos de diseño) e inteligente? ¿Cuánto tiempo te lleva descubrir qué demonios estabas pensando cuando lo escribiste? ¿Usó (ab) alguna propiedad de los datos / problema, que resultó en un código realmente rápido y ajustado, pero ahora significa que debe reescribirse desde cero?
En la programación del mundo real, cuando la gente te dice que tu código parece inteligente, eso no es un cumplido, ¡están esperando que te justifiques!
Los programadores experimentados han hecho programación en el mundo real.
Se trata de escribir código libre de errores a una velocidad rápida. Entonces, ¿qué hay de malo en eso?
Bastante.
Sí, desea escribir un código libre de errores, y debe hacerlo dentro de un plazo, pero programar en el mundo real es mucho más.
Debe comprender los dominios, los requisitos comerciales, en muchos campos, deberá lidiar con el cumplimiento y las regulaciones. Si trabaja en la industria financiera, cada país tiene sus propias regulaciones, debe comprender e implementar soluciones que las satisfagan a todas.
Fiabilidad y mantenibilidad a largo plazo.
La escala de los proyectos es mucho mayor, en una competencia de programación competitiva, digamos que haces una noche completa y escribes 1000 líneas. Ahora, piense en un proyecto de 100,000 líneas, o más grande, y lleva años .
No solo necesita escribir código, necesita escribir productos .
Hay una frase muy relevante …
No sabes lo que no sabes.
No quiero ser grosero, pero tienes acceso a mucha experiencia en Quora, es una gran oportunidad, pon tu ego a un lado y escucha.
Te perdiste un rasgo importante, que se busca en grandes proyectos: ¡ mantenibilidad ! Y, programación en la corriente principal del lenguaje / plataforma ( programación idiomática ).
En el mundo real, rara vez es un espectáculo individual . Además, los requisitos cambian todo el tiempo. Habrá muchos factores, pero para decirlo simplemente: ¡no es suficiente para un programador escribir un buen código! La comunicación efectiva con su equipo, manteniendo el código maleable y sus interfaces limpias y fáciles de usar también es importante.
Si uno es un buen programador, escribe código fácil de entender, bien documentado, fácil de mantener y robusto, con casos de prueba de unidad que cubren todos los casos de esquina y borde; entonces, no importa si él / ella también es un programador competitivo (tiene otra vida ) o no. Además, las habilidades no técnicas: tiene que ser un buen jugador de equipo, eficaz en la comunicación, etc.
Descargo de responsabilidad: nunca he trabajado [profesionalmente] con ningún programador competitivo.
Los 99.99% programadores competitivos fallarán en este problema comercial:
“Existe una función f, de modo que afirma ordenar una lista entera. Probar la función f ordena una lista, dada una lista de entrada y una lista de salida que sale de la función f “.
Ese es el mundo real. No hay cosas elegantes, cosas muy simples. Y todos fallan. Casi. Intentalo.
Una cosa más. La lista puede tener un par de millones de artículos. Solo lo digo. Intentalo.
Son dos cosas: el tipo de problemas y la naturaleza de las soluciones.
Los problemas no son como los del mundo real. Son demasiado pequeños y demasiado abstractos, como un rompecabezas.
Un problema típico para mí podrían ser los anuncios de automóviles de la tienda para que pueda proporcionar decenas de millones de visitas a la página y permitir a los usuarios buscar cualquier atributo, hasta 24 7
Las soluciones pueden ser el código de golf más corto, el más inteligente de alguna manera, el tiempo de ejecución más rápido de ese tipo de cosas.
Esas restricciones son secundarias en el mejor de los casos, y se oponen al código mantenido por el equipo en el peor.
Es solo diferente.
Por la misma razón que golpear pelotas de béisbol contra una máquina de lanzamiento solo está marginalmente relacionado con el béisbol, ya sabes.
La programación competitiva es para el desarrollo de software del mundo real, como lo es la ortografía para el periodismo. En el mundo real, la escala de las aplicaciones en las que trabaja es generalmente mucho mayor. Los requisitos a menudo son poco claros, incorrectos o simplemente incompletos. Debe tratar con usuarios normales, que solo quieren hacer su trabajo con el mínimo esfuerzo mental. A menudo trabajará en equipo y necesitará coordinar su esfuerzo. Su código debe funcionar durante años y ser mantenible durante ese tiempo.
El desarrollo de software del mundo real se centra en resolver problemas de usuarios y negocios, y las soluciones son algoritmos complejos y de múltiples capas, no inteligentes.
Por un lado, la programación profesional requiere un conjunto de habilidades más grande que la programación competitiva. No importa qué tan rápido pueda resolver pequeños rompecabezas curiosos si no conoce SQL, por ejemplo. Y los problemas son totalmente totalmente diferentes en tamaño y alcance. Puede resolver un problema en 10 minutos. Escribir una solicitud profesional es algo que puede llevar meses fácilmente. Es como comparar tallar con una navaja de bolsillo para construir la estatua de la libertad.
Creo que las personas a las que les va bien en estos concursos también pueden hacerlo bien en la programación del mundo real. El problema es más para que alguien pueda tener una gran aptitud para la programación en el mundo real, pero no lo haga bien en estos concursos.
Líneas de código es una medida muy cruda de productividad, pero aun así, un programador que podría escribir 50,000 líneas de código de calidad en un año sería muy productivo. Eso promedia alrededor de 200 líneas de código por día. Creo que estos concursos generalmente le dan menos de 8 horas, y una buena solución al problema involucra más de 200 líneas de código.
Prueba esta analogía para ver el tamaño.
Una persona puede ganar un concurso de ortografía, pero eso no la convierte en una buena escritora.
More Interesting
¿Los programas que simulan la evolución tienen algún efecto en los creacionistas?
Cómo entender un algoritmo de búsqueda CSP
¿Qué algoritmos de máquina requieren escala / normalización de datos?
¿Qué es una explicación intuitiva de IDA * (profundización iterativa A *)?
¿Podría hacerlo sin espacio adicional y en tiempo de ejecución O (n)?
¿Qué algoritmos pueden detectar si dos imágenes / objetos son similares o no?
¿Cuáles son algunos libros que debe leer un experto en algoritmos?
¿Cuáles son las aplicaciones del algoritmo de la Torre de Hanoi?
¿Cómo se puede resolver el coeficiente binomial usando programación dinámica y tabla hash?
