¿Los ingenieros de software de las principales compañías tecnológicas como Microsoft, Google, Oracle, Amazon, Yahoo y Apple realmente escriben código con algoritmos eficientes, dado que los productos de cada una de estas compañías son lentos o tienen otras desventajas?

Todas las principales compañías de software (Google, Apple, Microsoft, Facebook, etc.) tienen una combinación de ingenieros excelentes y buenos, y algunos mediocres (los pobres generalmente se filtran). Un buen porcentaje de esos ingenieros, de hecho, escribe código sobresaliente y altamente eficiente. Pero está haciendo una generalización muy mala de que un grupo de personas que escriben código excelente se unirán y escribirán software excelente. Los dos están libremente correlacionados, en el mejor de los casos.

El sello distintivo de un gran software es menos sobre el código eficiente y más sobre la abstracción. Ningún gran proyecto se construye con un código perfecto en la primera iteración. Está bien si un elemento de una pieza de software se reparó rápidamente, siempre y cuando se pueda mejorar fácilmente más adelante; sin tener que mejorar también un ejército de dependencias o pasar meses revisando un desorden de código de espagueti para descubrir qué hace qué. De esta manera, un buen software también permite que los equipos de ingenieros trabajen juntos de manera eficiente y solo sepan vagamente lo que los otros equipos están haciendo. A veces se da el caso de que el código más eficiente se sacrifica a favor de un modelo abstracto, y esto es generalmente (pero no siempre) una buena compensación.

Usted mencionó IE, que es un buen ejemplo. IE se mantuvo mal después de que MS ganó la guerra del navegador original con Netscape. El código de IE estaba lleno de fragmentos fantásticos de código, pero la arquitectura general del software era un desastre. Cuando Google lanzó Chrome, MS tardó un poco en enderezarlo para que pudieran progresar, y para entonces estaban jugando a ponerse al día. Esto no fue una falla de ingeniería de software, fue una falla del producto. Perdieron el barco en el mercado y perdieron la oportunidad de limpiar su deuda tecnológica, una opción que les costó la posición de liderazgo en el mercado. Peor aún, esta elección posicionó a Google para ir después de Office, e indirectamente, de Windows. Chrome, como contraejemplo, realizó algunas compensaciones de diseño desde el principio que lo harían intensivo en memoria. No sé si fue deliberado o no, pero en retrospectiva, esa compensación fue muy buena. La pérdida de memoria no fue suficiente para disuadir a los clientes, y la extensibilidad que Chrome aportó a la mesa se ha convertido en la piedra angular de la estrategia de Google que hasta ahora ha desafiado con éxito el dominio de Microsoft en las aplicaciones de productividad de Office. Entonces, si crees que Google realizó un WRT de compensación incorrecta para el software optimizado, diría que es posible que todavía no entiendas el software.

Finalmente, dado todo esto, ¿por qué te preguntan si puedes escribir código optimizado? Cada proyecto bien dirigido tiene que hacer compensaciones. Algunas veces codificará rápido y sucio para poner algo en frente de un cliente; otras veces lo tomará con calma y lo compilará correctamente, escribiendo código altamente optimizado en el proceso. Si desea contratar un gran equipo de software, necesita personas que puedan hacer ambas cosas.

Si. Existe el consejo de que se habla a menudo “no optimice prematuramente” pero también está el consejo “no se pesimice prematuramente”.

Este consejo se puede aplicar a la eficiencia algorítmica en sistemas grandes. Si bien ajustar su algoritmo para el último 5% de rendimiento es difícil y puede llevar algo de tiempo, lograr que su algoritmo alcance la eficiencia de la línea de base a menudo solo requiere un poco de reflexión inicial.

Muchas ineficiencias pueden ser detectadas por la revisión del código. Seguro que su código ineficiente puede verse bien para usted, pero para un buen crítico crítico (Google está lleno de ellos) lo captarán. La revisión de código es una necesidad en buenas empresas de software.

Cuanto más utilizado sea su software, más desarrolladores de software tendrá para mirar su código. A partir de esto, construirás una reputación en cuanto a tu nivel de habilidad. ¡Es mejor que no despliegue su O (n ^ 2) algo y dígame que escalará a un millón de usuarios!

De alguna manera, la eficiencia algorítmica está integrada en el proceso social.

Más

Una cosa que debe tener en cuenta sobre las principales empresas de tecnología es que son muy grandes. Un solo ingeniero trabaja en un pequeño código que tiene que interactuar con un gran ecosistema que es muy complejo. Por lo tanto, la eficiencia del código escrito por un solo ingeniero no solo está determinada por la eficiencia algorítmica del código; También está determinado en gran medida por cómo ese código interactúa con el ecosistema que consiste en miles de líneas de código escritas por miles de otros ingenieros.

La descomposición del código se convierte en un problema importante en un sistema como este, el código es parcheado y reparado por muchos ingenieros diferentes y tiende a deteriorarse a menos que se invierta tiempo para limpiar las inevitables discrepancias que se acumulan.

Entonces, la pregunta de si cada ingeniero individual escribe un código eficiente no es realmente la pregunta correcta. La pregunta es realmente si el sistema está diseñado para soportar la evolución efectiva de las buenas prácticas de codificación. Creo que este es el verdadero problema con el que luchan las principales compañías tecnológicas. Contratar ingenieros muy inteligentes y reflexivos proporciona una buena base para que el código evolucione en una dirección positiva.

Por experiencia personal en Amazon, puedo decir que es crucial dejar un fragmento de código en mejor forma de lo que lo encontró. Solo ser un codificador eficiente no es suficiente, es necesario ser proactivo en la batalla contra la entropía. Uno solo espera que la codificación de las entrevistas sea un medio razonablemente efectivo para seleccionar el tipo de ingenieros que se preocupan lo suficiente como para mejorar las cosas progresivamente.

“La primera regla de optimización de programas: no lo hagas. La segunda regla de optimización de programas (¡solo para expertos!): No lo hagas todavía”. – Michael A. Jackson
Desde

¿Los ingenieros de software escriben código eficiente? Para un ingeniero de software, esta es una pregunta un tanto vaga. ¿Qué hace que un código de pieza sea eficiente? ¿Es el más rápido? ¿Es el más compacto? ¿Utiliza la menor cantidad de recursos? Incluso estas preguntas son bastante vagas. Cuando dices más rápido, ¿te refieres a ciclos de CPU o tiempo real? ¿En cuántas CPU (o núcleos) diferentes se ejecutará el código? Escribir código para un único procesador es diferente de escribir para concurrencia. Dependiendo de su cliente objetivo, la cuestión de qué es “Eficiente” variará mucho.

Los buenos ingenieros de software realmente optimizan su código para otros ingenieros de software. Este es un diseño principal, a menudo denominado “No optimizar prematuramente” u “Optimizar para facilitar la lectura”. Una gran cantidad de optimización (y lo que intenta optimizar depende de sus clientes objetivo), en realidad sucede automáticamente, ya sea por el compilador o por herramientas designadas. La mayor parte (dependiendo de la definición específica del proyecto de “Eficiente”), se realiza en base a mediciones, generalmente resolviendo cuellos de botella, o cuando hay un impacto significativo. Para resumir este punto, para los buenos ingenieros de software, en cierto modo, el código más eficiente es el código que es más fácil de entender y mantener para otros ingenieros de software.

¿Por qué las grandes compañías elegantes tienen un código aparentemente ineficiente en sus productos? Las respuestas pueden variar. Parte de esto tiene que ver con las prioridades (usar más memoria para reducir el tiempo de cálculo). Parte de esto tiene que ver con tener una gran audiencia. Intentar complacer a todos tiene un costo. Ejecutar un programa en una pieza de hardware muy específica le permite más optimización que un programa que se puede ejecutar en cualquier dispositivo, por ejemplo. El soporte de interfaces antiguas (para que aún pueda ejecutar sus complementos desde la última versión) tiene un costo. Los cambios en el entorno (por ejemplo, la memoria se vuelve más barata / más cara) también tiene su efecto. Entran en juego muchos más factores, y para cada proyecto hay prioridades y compromisos.

Entonces, ¿por qué estas grandes compañías elegantes le preguntan sobre algoritmos y estructuras de datos en las entrevistas? Porque les brinda una forma relativamente estandarizada de evaluar sus habilidades, sin haberlo contratado primero. Quieren ver cómo abordas un problema, que haces las preguntas correctas, que eres consciente de las compensaciones involucradas en la solución y que puedes describirlo de manera articulada.

Ser un gran ingeniero de software no se trata de escribir el código más rápido o más pequeño, se trata de proporcionar valor a los clientes y aportar valor a la empresa para la que trabaja. Se trata de utilizar las herramientas adecuadas para el trabajo y tomar los compromisos y decisiones correctos, en función de las limitaciones y los requisitos del proyecto.

No trabajo en la lista mencionada de las compañías que ha resaltado … sin embargo. No lo hice o no solicité.

Puedo ver claramente que puede actualizar mentalmente esta página para obtener una respuesta de un respetado Quoran, que tal vez incluso haya trabajado en una de estas compañías, para gritar “No, no lo hacen. Cuando escriben código, el Los ingenieros de esas compañías se comen toda la RAM que les arrojan, hacen que el caché del sistema de archivos llore lágrimas de sangre y se deleitan sádicamente al hacer que la latencia de la red sea marginalmente mejor que cuando Chiristopher Columbus descubrió que no aterrizó en India “.

No vayas por el camino.

Hacia dónde se dirige es hacia la racionalización de sus fallas actuales. O peor, deleitándose con el placer culpable de ver a los ingenieros en la lista mencionada de empresas arruinarse de una manera importante, para que pueda justificar que fue más inteligente o más afortunado de no trabajar con ellos.

El siguiente paso será:

1) “Las empresas L, M, N escriben códigos malos y aún ganan. El mundo es tan injusto
que es peor que un apocalipsis zombie que mata a la humanidad y deja a los pequeños gatitos peludos sin hogar y hambrientos “.

2) “ABC ni siquiera sabe qué es X, Y y está trabajando en Z .. ¡Jaja!”.

Simplemente acepte que probablemente sean mejores que usted actualmente y trabaje duro para mejorar para convertirse en un mejor científico informático.

Deja ir el ego y sometete a algún tipo de trabajo disciplinado e infunde placer en el mismo. El puente se cruzará más rápido.

La vida es demasiado corta para buscar foros de internet para que las anécdotas de ingenieros en estas compañías respetadas se arruinen de mala manera. Usted, francamente, podría ser el próximo.

Las grandes empresas tecnológicas a menudo están al borde de problemas que a) los sistemas estándar no funcionan o b) no hay nada que satisfaga su caso de uso o c) su escala es tan grande que es rentable desarrollarla algo en casa

Por ejemplo, Facebook tiene tantas fotos que les resultó más rentable construir algo optimizado para sus necesidades, dijo Haystack. http://techcrunch.com/2009/04/30 … O Facebook estaba llegando a los límites de memcached, y en base a sus reglas especiales de privacidad, necesitaban una versión de memcache con gráficos, por lo que crearon TAO. https://research.facebook.com/pu …

Sin embargo, como mencionan algunas de las otras publicaciones, aún prevalecen consideraciones prácticas. El objetivo es encontrar algo que funcione mejor para volúmenes reales o pronosticados, no el algoritmo teórico más ideal. El objetivo también es enviar, por lo que los casos de esquina ineficientes pueden diferirse hasta que valga la pena resolverlos. Los ingenieros deben ser conscientes de cuándo ocurre esto y reconocer la elección.

A veces, especialmente en sistemas heredados, los problemas surgen con el tiempo o las compensaciones se vuelven más aparentes o las condiciones cambian. Por ejemplo, Micorosft quería reducir los errores de incompatibilidad, por lo que desarrollaron la carpeta WinSXS https://support.microsoft.com/kb… . Sin embargo, al diseñar esta carpeta, Microsoft predijo que los tamaños de los discos duros continuarían creciendo, por lo que eran un poco vagos con el espacio que ocupaba. Sin embargo, el aumento de las unidades de estado sólido (SSD) cambió esa suposición. Microsoft luego tuvo que intentar rediseñar WinSXS, que es más complicado que hacerlo bien la primera vez, ya que ahora no pueden romper nada.

A veces, si las condiciones comerciales lo requieren, se deben reconstruir sistemas completos. Las grandes empresas tecnológicas están constantemente reemplazando y reconstruyendo sistemas. Es como reconstruir un avión en el aire. 5 años después, quedará muy poco de lo que hay hoy.

Yo trabajo para Microsoft.

Un buen ingeniero de software entiende que el 99% del tiempo se gasta en el 1% del código, y la optimización de la sección incorrecta del código para la velocidad es en realidad un gran error. Sin embargo, optimizar ese código para mantenerlo es algo bueno, incluso si significa que el código se ejecuta más lentamente.

Habrá, por supuesto, una sección de código del 1% donde el rendimiento sí importa, y alguien tendrá que optimizarlo. Y tendrán que ser buenos para escribir algoritmos eficientes. Esa es una habilidad importante. Pero la mayor parte del tiempo y el esfuerzo en un proyecto de software significativo se debe dedicar correctamente a la optimización de la eficiencia de la ingeniería.

He visto a los ingenieros pasar semanas optimizando una rutina, solo para darse cuenta de cuándo habían terminado su optimización es completamente indetectable por el usuario final.

En las entrevistas, es algo más fácil medir la habilidad algorítmica que la habilidad de diseño, por lo que muchas preguntas de la entrevista se centrarán en eso con la esperanza de que ambas estén correlacionadas. No es perfecto, pero es común. Ambas habilidades son necesarias.

No hay una respuesta simple y directa a esta pregunta. Pero si trato de responderlo desde la perspectiva de un desarrollador (que utiliza varias herramientas y tecnologías), me vienen a la mente las siguientes cosas.

Los algoritmos eficientes (velocidad del procesador y gestión de la memoria) son obviamente uno de los trabajos principales de los desarrolladores que trabajan en estas empresas, pero la producción general del producto también depende de muchos otros factores cruciales.

La arquitectura del producto y el diseño de características (eliminando todos los requisitos innecesarios y complicaciones) teniendo en cuenta el producto final es un factor importante que determina el resultado.

Y también asegurándose de que el producto se pueda enviar teniendo en cuenta los objetivos / métricas deseadas (independientemente del modelo / proceso de ingeniería elegido por la gerencia ejecutiva). En otras palabras, la validación para un acabado liso y un excelente rendimiento también son obligatorios.

Escribir código laborioso que carece de dirección a una velocidad muy alta no es deseado y, por lo general, da como resultado un promedio de salidas por debajo del par (según mi experiencia en este modelo de desarrollo durante un corto período de tiempo).

No puede generalizar sus comentarios sobre una compañía o compañías en particular basadas en pocos productos que haya observado. He visto varias herramientas y tecnologías de terceros que son peores que los productos de los que hablaba (en términos de eficiencia, seguridad, etc.).

Los productos de los que hablaba de varias compañías podrían ser los productos horneados a medias. Las razones pueden ser muchas =>
> Gestión deficiente / incompetente, sin seguir los fundamentos (los fundamentos básicos) del desarrollo de software
> Limitaciones de tiempo (como resultado de los plazos de entrega fijados por la administración y la presión debido a la dinámica del mercado)
> Los agujeros de seguridad explotados por los piratas informáticos con los virus (implementados por piratas informáticos o similares para robar información, monitorear ciertas cosas o hacer el ataque básico dos) que se ejecutan como parte del producto.

Para resumir, la respuesta breve a su pregunta es => Sí, los desarrolladores (puede que no sean el 100% de ellos \ U0001f60a) en esas compañías escriben algoritmos eficientes (centrándose en la velocidad del procesador, la gestión de la memoria y varios otros recursos como un mejor uso de tarjeta gráfica, batería, ancho de banda de red, etc.)

Sostén tus caballos. Su experiencia subjetiva del rendimiento del explorador de Internet y la observación objetiva del amor de Chrome por la RAM tienen muy poca importancia aquí. Dejame explicar:

IE es bastante rápido, dado todo el legado con el que tiene que lidiar. Hay muy pocos ingenieros en el mundo que podrían haber creado un navegador de ese calibre: un contenedor de componentes genéricos que hace renderizado y composición en tiempo real. Y recuerde que Microsoft inventó efectivamente DHTML.

Chrome es una pieza de software aún más fantástica, y tengo pocas dudas de que su uso de RAM es el resultado de una cantidad muy considerada de compensaciones. El trabajo técnico en ese producto también es excelente.

Entonces, desacoplemos su experiencia personal (o la de cualquiera) de una pieza de software de la experiencia agregada Y de la calidad del código, sin importar cómo se mida.

Después de haber trabajado en Microsoft (en el equipo de Entity Framework), puedo dar fe de que hay ingenieros de clase mundial que escriben código increíble. Heck, los ingenieros de ese equipo han avanzado para construir motores de big data en google y sistemas en facebook. En la parte superior, es todo un grupo de talentos altamente refinados de personas increíbles. 🙂

Los algoritmos y las estructuras de datos son solo partes de las habilidades para construir un gran producto, incluso no las partes más importantes. Si mira hacia atrás y hacia adelante, ¿cuáles son los excelentes productos creados en base a los algoritmos eficientes de las principales empresas? La respuesta es: NINGUNO .

• No inventaron / crearon ningún gran lenguaje de programación, como C / C ++ / Java / Python … C # y Go son un montón de mierda.
• Windows / Office, Google search / Map se convirtió en productos mejores / excelentes después de muchas iteraciones. El iPhone probablemente fue impulsado por el diseño / enfoque de Job.

Ninguna de estas grandes empresas ha creado un producto que pueda dar a la gente la sensación que aportan las músicas de Mozart, las teorías de Einstein o las imágenes de Vincent van Gogh. Si miras hacia atrás desde hace decenas de años, son solo algunos buenos productos de software, como Windows 95 / IE en 2o años atrás. Todos estos productos se basan en ideas, no en una mente genial / hermosa.

He trabajado en Oracle, nunca tuve la oportunidad de escribir algoritmos complejos en el código de producción real. Aunque pude trabajar con algunos Datstructures y Frameworks geniales allí.

Trabajé anteriormente con Huawei. Allí, solíamos escribir cada línea de código con extrema precaución y cuidado, y cada línea de código solía ser inspeccionada por eficiencia y confiabilidad.

Desde mi experiencia, lo que puedo entender es que cada organización tiene sus puntos de enfoque. He visto que la división de aplicaciones de Oracle se enfoca más en agregar más funciones al producto, lo cual es importante para ellos que escribir el mejor código posible porque eso es lo que atraerá a sus clientes empresariales. Si bien Huawei es una empresa de telecomunicaciones, la confiabilidad es la principal preocupación que desean que sus servicios y aplicaciones web se ejecuten para siempre con un tiempo de inactividad mínimo o nulo. Igual es el caso con las compañías de internet solo que aquí los servicios tienen que responder realmente rápido.

Tengo amigos en Amazon y Yahoo. Sé que se centran mucho en la calidad de su código. Pero dudo si realmente escriben algoritmos complejos en su código de producción, pero estoy seguro de que todos se enfocan mucho en escribir el mejor código posible. Y tienes que entender que todos ellos no están tratando de resolver un problema trivial. Si el navegador web fuera una aplicación fácil de hacer. Microsoft no tendrá problemas para conseguir que la comunidad le guste al explorador de Internext ni Chrome necesitará mucha memoria.

“He extendido la carta más de lo habitual, porque no tengo tiempo para acortarla” – Blaise Pascal

Producto de calidad y código de calidad son dos aspectos diferentes. Los usuarios pueden juzgar la calidad de estos productos pero nunca pueden juzgar la calidad del código simplemente porque no podemos ver el código.

Mi suposición es que los codificadores de estas organizaciones escriben mejor código que otras organizaciones. Un producto de buena calidad puede tener un código incorrecto y un producto malo puede tener una buena calidad de código.

Internet Explorer puede tener la mejor calidad de código. nunca sabemos.

Existe una compensación entre una fecha límite y la calidad del producto. Los plazos son plazos, la calidad viene después. Hacer que las cosas funcionen es de suma importancia. .

¿Por qué no todos aman a Internet Explorer?

Steve Jobs dijo una vez en una entrevista que si un producto ganaba el monopolio, llegaría a su fin debido a una mala gestión. Internet Explorer es uno de esos ejemplos. Hace algunos años, Internet Explorer disfrutaba del monopolio del mercado. La administración de Microsoft podría haber sentido que era un producto para quedarse. Entonces, ¿por qué molestarse en mejorar el producto? El énfasis pasó de las cosas técnicas a los trucos de marketing y ventas. El personal de marketing y ventas tiene más voz que los desarrolladores y diseñadores con respecto a las decisiones sobre el producto.

Es por eso que una vez que los grandes productos se arruinan. Puede encontrar muchos ejemplos de este tipo en IBM.

Trabajo para Microsoft y he entrevistado a muchos candidatos para nuestros roles de ingeniería de software. Por lo general, elijo un problema técnico (algorítmico) real resuelto en uno de nuestros productos (Windows / Office / Xbox, etc.) y tengo una discusión con el candidato sobre las posibles formas de resolverlo. Entonces, si su pregunta es sobre “¿Por qué preguntar sobre estructuras de datos y problemas de algoritmos si nadie los va a usar realmente en problemas del mundo real?”, Ese no es el caso.

Realmente depende de la estrategia.

A veces, el foco está en el rendimiento, a veces no. Por lo general, el rendimiento se logra a través de múltiples iteraciones y no viene primero. Por ejemplo, el tiempo de arranque de Windows ha mejorado significativamente de Vista a Windows 10 versión por versión, pero Vista estaba allí para poner el marco para el desarrollo futuro. Tienes que empezar por algo.

La eficiencia no es de naturaleza algorítmica, por lo que nadie puede escribir código algorítmicamente eficiente.

Además, los algoritmos son procedimientos matemáticos, funciones que describen un proceso paso a paso.

Aunque dos algoritmos diferentes que logran el mismo resultado pueden funcionar a costos diferentes, y uno puede realizar la tarea a un costo menor que el otro, un solo algoritmo no tiene una medida de eficiencia por sí mismo.

A lo que realmente se refiere es a la implementación del algoritmo en código y / o hardware. El mismo algoritmo puede implementarse de formas infinitas, algunas mejores que otras, minimizando la memoria, o la velocidad o la precisión o lo que sea.

Desde mi experiencia personal, qué tan eficiente debe escribirse un código depende únicamente de los requisitos del sistema que se está construyendo.

Escribir un código eficiente no siempre es necesario y hacer algo innecesario es una pérdida de tiempo.

Suponga que el problema es escribir un programa para ordenar 10 millones de números, prácticamente buscaría el sistema al que se dirige.

Si el programa tiene que ejecutarse en una súper computadora, es una pérdida de tiempo codificar un algoritmo de clasificación eficiente. Yo escribiría Bubble Sort. Sin embargo, si tiene que ejecutarse en un escritorio, pensaría en una solución eficiente como Merge Sort.