Get best of the week

Todo es sorprendente en software, pero todos están descontentos



Hay una posición típica que se puede encontrar en Habré y no solo: "aunque el hardware es mejor a lo largo de los años, la humanidad ha reducido el efecto a nada escribiendo peor el software".

Al igual, hay más núcleos en los procesadores, pero se ralentiza más que nunca. Electron y Slack son criaturas de la oscuridad que han venido a robarnos la felicidad y la memoria. Las aplicaciones móviles se han vuelto más voraces que los sistemas operativos más antiguos. Y en los sistemas operativos en sí realmente no hay progreso, pero por alguna razón continúan aumentando de tamaño. ¡Ya fuera cuando la gente supiera cómo encajar el sistema operativo en un disquete!

Diré directamente: cuando veo tales declaraciones, me bombardean. En mi opinión, se pierden una serie de factores importantes. Y al final, la situación se asemeja al discurso clásico de Louis X Kay " Todo es increíble y nadie está contento"": Todo fue sorprendentemente bueno, y la gente está sentada y quejándose.

Por lo tanto, decidí describir estos factores perdidos. Como el texto resultó ser duro, quiero enfatizar que mi opinión es puramente personal (aunque me refiero a las conferencias de la compañía en la que trabajo).

Selectividad de memoria


Se sabe que hay un efecto nostálgico "antes la hierba era más verde y la música era mejor". Pero, en mi opinión, para muchos este efecto adquiere proporciones aterradoras, cuando las sensaciones divergen dramáticamente de la realidad.

Estoy hablando de declaraciones como esta: "Casi todo en una computadora se siente más lento que en 1983". A juzgar por los miles de Me gusta, esta no es una opinión aislada, sino masiva.


Mi primera reacción: "Bueno, ¿cómo fue la transmisión de video 4K en 1983?" Es decir, para empezar, recordemos que la mayoría de las aplicaciones informáticas de hoy en día eran imposibles, incluso solo por la velocidad. Una vez, una película (ni siquiera en 4K, sino en 1080p) tendría que descargarse durante meses, y luego la computadora no podría reproducirla con 24 FPS. ¿Y cómo comparar la velocidad actual con una que sería tan prohibitivamente baja que no existiera en absoluto?

Segunda reacción: sí, algunas cosas que se han movido desde la línea de comando a la GUI pueden tomar más tiempo allí. Estoy listo para creer que Word en 2020 comienza más lentamente que el editor de consola vi en 1983 (no puedo compararlo personalmente: era la primera vez que estaba en mi computadora en los años 90). Pero si esto es tan importante para usted, también puede usar la línea de comando para muchas "tareas de los 80" en 2020. Estoy escribiendo este texto ahora mismo en vim, un excelente editor que el ecosistema de complementos ayuda a mantenerse al día. Se ve muy bien en la retina moderna iMac: las letras se han vuelto muy claras y aún funcionan al instante. ¿Cuál es el problema?

Pero lo más importante ni siquiera está en las dos cosas nombradas. Más importante es lo siguiente: en mi opinión, comenzamos a olvidar cuánto ralentizaron las computadoras. Cuando algo comienza a desacelerarse con más fuerza, lo notamos de inmediato, pero cuando algo se vuelve más rápido o más fácil, simplemente damos por sentado y nos olvidamos del pasado.

A todas las personas que escriben "todo solía ser más rápido", tengo esta pregunta: ¿recuerdan, por ejemplo, esto?


Lo admito honestamente: yo mismo no recuerdo especialmente esto. Cuando apago la computadora hoy, no pienso en el hecho de que me senté y esperé hace veinte años entre presionar un botón en el sistema operativo y presionar un botón en la unidad del sistema. Simplemente di por sentado que ahora no es tan necesario y me olvidé de lo que era diferente.

Con el tiempo que la computadora comenzó, también hubo grandes cambios. Ahora me siento en el aimak, presiono una tecla y, después de un segundo, está listo para funcionar (gracias a SSD y modo de suspensión). Cuando en la infancia esperaba que Windows se iniciara desde el HDD, difícilmente hubiera creído que viviría para ver eso.

"Cuando en una carta hay cientos de imágenes, se abre muy lentamente, ¡a veces incluso diez segundos!" Entiendo que esto puede ser molesto, pero escuche, en el año 2000, para revisar el correo, primero disfruté de los trucos del módem por un minuto, luego esperé hasta que la página principal del correo se cargó lentamente, y luego la carta en sí tampoco se cargó al instante, y no fue así. No hay imágenes, solo texto. Hoy, esto se abriría sin demora. ¿Tal vez simplemente no necesita introducir en mil imágenes un medio de comunicación inventado para otro? Y antes de declarar "todo salió mal", pensemos: ¿cuánto tiempo se abriría una carta con tantas imágenes en 2000?

O aquí hay otro recuerdo perdido en el tiempo, como lágrimas en la lluvia. Tal broma fue popular en la década de 2000: "Una computadora lenta es cuando se conocen los nombres de todos los desarrolladores de Photoshop". Para aquellos para quienes esto no significa nada: entonces el Photoshop espiral era muy popular en Rusia, y cada vez que se lanzó, los rusos tuvieron que mirarlo durante mucho tiempo:


Oh, me di cuenta ahora que conozco a una de estas personas: Sean Parent habló en nuestro lugar C ++ Rusia

Ahora compara. Hoy bromean "una vez que se necesitaron dos kilobytes de memoria para lanzar a un hombre a la luna, y ahora se necesitan dos gigabytes para lanzar Slack". Suena mal, pero ¿notas la diferencia? No importa la cantidad de RAM que Slack consume, los usuarios no se encuentran con la situación "puedes ir a tomar el té al comienzo del programa". Todo mejoró, pero no lo notamos.

O aquí hay un artefacto histórico revelador: la serie de Masyanya "Descargar" (2002). Los héroes están terriblemente preocupados por la desconexión, en la que tienes que descargar el archivo nuevamente.


Tenga en cuenta: el archivo que están descargando pesa 591 kilobytes. Los personajes están preocupados por tener que recargar medio megabyte. Esta es la situación real en 2002.

A modo de comparación, un nuevo ejemplo de la vida. Tuve un pequeño problema técnico en mi Mac, en Stack Overflow encontré el consejo "para instalar Xcode y aceptar sus términos de uso". Mi reacción: es extraño descargar un IDE de 8 gigabytes con un solo clic, pero si ayuda, ¿por qué no?

Es decir, el tamaño de los programas ha aumentado a lo largo de los años (en el momento de Masyan del "IDE de 8 gigabytes" las personas se movían el pelo), pero se hizo mucho más fácil descargarlos y nuestra vida mejoró mucho.

Bueno, el último ejemplo en esta parte es sobre "aplicaciones móviles hinchadas". Publicaciones indignadas como "A veces" escriben sobre esto.Los tamaños de las aplicaciones están fuera de control ":" ¿desde cuándo LinkedIn comenzó a ocupar 275 megabytes en el teléfono? En 2018, fue posible leer la queja "después de instalar las aplicaciones, solo me quedaban gigabytes para las fotos".

No mentiré, estos 275 megabytes de LinkedIn también me están causando preguntas. Pero recuerdo cómo en 2010 en Habré escribieron que Alfa-Bank tenía una aplicación móvil. Pesaba 30 megabytes, hoy tal tamaño no habría planteado ninguna pregunta. Y luego en los comentarios escribieron:



¿Sabes por qué? En esos días, un usuario ruso podía caminar, por ejemplo, con HTC Hero. Veamos sus características: "almacenamiento: 512 MB, 165 para aplicaciones". ¡165 megabytes en total para todas las aplicaciones instaladas! En tales circunstancias, tenía que elegir constantemente cuáles eran más importantes y cuáles no. Y para instalar uno de 30 megabytes, uno tendría que demoler varios otros a la vez. Fue un dolor

Y si pudiéramos volver a 2010, acercarnos a las personas que están experimentando este dolor y decirles la frase de 2018, "después de instalar las aplicaciones solo me quedan gigabytes para las fotos", creo que sería golpeado. Estas palabras no sonarían una queja, sino una burla y jactancia.

E incluso desde 2018, cuando apareció esta queja, la situación logró mejorar: ahora el presupuesto de Xiaomi Mi A3 en la versión básica está equipado con 64 gigabytes, por lo que, después de instalar las aplicaciones, obviamente habrá mucho más que uno gratis.

Sí, las aplicaciones han crecido significativamente durante 10 años. Pero el volumen de espacio al mismo tiempo ha crecido CIENTOS. Es decir, la vida se ha vuelto diez veces mejor.

¿Y recuerdas lo que era usar un teléfono inteligente en 2010 y cuántos dolores diferentes "todo se ralentiza" allí?

  • Una pequeña cantidad de RAM significaba que la aplicación tenía que ejecutarse constantemente desde cero, y no cambiar inmediatamente a una que ya se estaba ejecutando.
  • Y los procesadores de baja potencia los lanzaron muy lentamente desde cero.
  • No quiero recordar la velocidad de Internet móvil.
  • , USB 2.0 .

Usar un teléfono inteligente parecía una expectativa constante: no importa lo que quieras hacer, esto incluye períodos de "estar de pie y tonto". Si estás en la calle y necesitas un mapa, te quedas quieto y primero esperas hasta que la aplicación se inicie, y luego espera cuando el mapa en él se digna para cargarse. Y paga significativamente por el tráfico consumido al mismo tiempo.

Comparado con esto, ahora todos vivimos en condiciones celestiales, pero al mismo tiempo nos estamos quejando activamente. Parece "problemas del primer mundo", algo así como "Quiero leer Twitter acostado, sosteniendo el teléfono sobre mi cara, pero luego puedes soltarlo accidentalmente". Bueno, simpatizo, pero decir en tal situación "todo ha empeorado" parece una falta de respeto por el pasado y el presente.

: « » . , , . .


«»


Hay otra situación típica. La gente dice que "el software se está volviendo cada vez más inflado y lento, aunque para el usuario no hay casi nada que mejore para mejor", y al mismo tiempo no son completamente conscientes de lo que realmente está sucediendo allí.

Como un pequeño ejemplo ilustrativo. En 2018, hubo un texto sensacional de Nikita Prokopov sobre "software estropeado", y entre otras cosas estaban las palabras "Servicios de Google Play que no uso (no compro libros, música o videos allí) - 300 MB que simplemente se sientan aquí y que no se puede eliminar ".

Al leer esto, quiero estar lleno de ira justa, sí. Pero hay una advertencia: de hecho, Google Play Services no se trata de "comprar libros". Incluye muchas API diferentes y, como se informóWikipedia, "Todos los principales servicios de Android están controlados por Google Play Services". Es decir, con toda probabilidad, Nikita está utilizando activamente este software, sin saberlo él mismo, es solo que Google le dio un nombre confuso.

Mi objetivo aquí no es criticar una publicación específica, sino mostrar un enfoque general: a menudo declaramos que "las aplicaciones aumentaron / se ralentizaron sin una buena razón", sin entender completamente estas razones. Agregaron algo a la aplicación, sus desarrolladores tienen información detallada sobre qué exactamente y por qué, pero no lo tenemos, pero por alguna razón nos consideramos más competentes que ellos en este asunto.

Pero adentro hay mucho de lo que no es obvio desde afuera. Tomemos como ejemplo a los editores de texto: parece que las personas los han estado haciendo desde tiempos inmemoriales en el hardware más débil, todo ha sido claro con ellos durante mucho tiempo y no hay nada que desacelerar, "lo que podría ser más fácil". Por lo tanto, desde el exterior se ve así: si algo no funciona instantáneamente, entonces estos desarrolladores corruptos han olvidado cómo la humanidad ya es experta. Pero si profundiza en el tema (de alguna manera publicamos un mensaje sobre esto), se revelan claramente muchos matices no obvios , y las palabras "lo que podría ser más simple" dejan de parecer convincentes.

O una cosa más. Las noticias sobre sistemas operativos móviles a menudo provocan tal reacción: “En los últimos ocho años, no se ha hecho nada útil allí. Cada año, con un escándalo, lanzan una nueva versión que pesa más que la anterior, pero por las diferencias solo veo nuevos emojis. En el ataúd, vi estos emojis, devolví la versión anterior, fue mejor ".



Escuche, bueno, parece que todos los especialistas en TI lo saben por experiencia: puede invertir mucho esfuerzo en la refactorización justificada del backend, y el usuario ni siquiera lo notará, o puede cambiar un par de íconos en la interfaz en media hora, y comenzarán discusiones acaloradas entre los usuarios. Es decir, sabemos que "fuera" solo algunos cambios son notables, y a menudo no son los más importantes. ¿Por qué, entonces, no nos damos cuenta de que si nosotros mismos solo notamos emojis en la nueva versión del sistema operativo, entonces esto habla más sobre nosotros que sobre el sistema operativo?

Tomemos, por ejemplo, Project Treble de Android 8.0. Se sabe que Android tiene un gran problema: mientras que los iPhones se actualizan fácilmente a las nuevas versiones del sistema operativo, los teléfonos Android generalmente permanecen para siempre con la versión preinstalada, porque sus fabricantes no quieren perder el tiempo. Y Google comenzó una alteración a gran escala de toda la arquitectura para simplificar la vida de los fabricantes y estimular las actualizaciones. Y aunque Treble no resolvió el problema por completo, las estadísticas muestran una mejora notable. Es decir, para hacer frente a un problema urgente, Google invirtió mucho trabajo (refactorizar un coloso así no es bueno para ti en la ventana), y la situación ha mejorado parcialmente. En mi opinión, la empresa solo necesita lidiar con problemas dolorosos, hicieron todo bien.

Ahora dime: si no eres un desarrollador móvil, ¿has oído hablar de esto? Cuando compró un teléfono con Android 8.0+, ¿afectó de alguna manera su opinión sobre la nueva versión? Es poco probable, porque en los primeros meses de uso del teléfono, esto no le parece nada al usuario. Solo puede notar después de un tiempo cuando se lanzará la nueva versión de Android. Y solo si el fabricante del teléfono es uno de los que Treble ha podido actualizar dispositivos. E incluso en este caso, el usuario puede no darse cuenta de que la actualización se debe a Google, y aún así decir "no se ha hecho nada útil durante ocho años".

Y esta situación es típica: la "parte submarina del iceberg" es generalmente grande. Cuando Android presentó la batería adaptable (definición "inteligente", qué aplicaciones pueden tener una batería en segundo plano), ¿midió si el consumo de energía de su teléfono ha cambiado? Cuando Google Play Protect en segundo plano se ocupa de su seguridad, ¿recuerda que no era antes? Cuando agregó soporte para el códec de video AV1, ¿pensó que el futuro con este códec es muy probable y tal soporte es útil? ¿O simplemente levanta el teléfono y los emojis son sorprendentes, pero el soporte AV1 no es sorprendente?

Después del lanzamiento de esta publicación, apareció un hilo maravilloso delanyese software aumenta en gran medida debido al manejo de situaciones raras. Y luego, qué sucede: en el 1% de los casos en que surgen estas situaciones, todo mejoró mucho, pero el 99% de las personas que no se encuentran con estas situaciones raras no pueden evaluar adecuadamente los cambios.



Y de esto se deduce que cuando juramos en masa todas las "aplicaciones inflamadas e inhibitorias", en muchos casos hubo razones objetivas para esto. En algún lugar, durante las horas de trabajo, la gente consideró cuidadosamente todos los pros y los contras, los discutió entre ellos y llegó a la conclusión de que los profesionales superan. Y luego llegamos, no tenemos idea de lo que estaba en la balanza, no vamos a pasar tiempo en un estudio reflexivo, solo vemos el tamaño cambiado, y llegamos a una conclusión segura de que "todo salió mal".

La conclusión general: algunas de las afirmaciones sobre "software infundado sin sentido" son causadas por malentendidos. Y hacer tales declaraciones sin un estudio exhaustivo de las causas no es la estrategia más sensata.


Atención al rendimiento


Las declaraciones sobre el "software estropeado" suenan como si los desarrolladores solían ahorrar energía informática, pero ahora todos querían escupir en la optimización. Por ejemplo, solo es importante que funcione, y que los requisitos para el hierro sean altos, por lo que la ley de Moore de alguna manera lo arruinará todo. Si el código se ejecuta lentamente, consume memoria como si fuera parte de sí mismo y ocupa mucho espacio, y así sigue, nadie se preocupará por eso y mejorará algo.

Escucha, esto simplemente no es cierto. Como un ejemplo separado: Facebook Messenger ha sido reescrito recientemente, y se informa que la productividad se duplicó y el tamaño disminuyó cuatro veces. Y según las palabras anteriores que la aplicación de LinkedIn pesa 275 megabytes, lo revisé ahora y vi las palabras "195.4 MB" en la App Store, parece que también lograron reducirlo una vez y media. Es decir, ambas compañías claramente pensaron en el consumo de recursos y asignaron una gran cantidad de mano de obra para reducirlos, lo que podría gastarse en "cortar las características".

Y dado que trabajo con conferencias para desarrolladores e interactúo con muchos de ellos (y de diferentes grupos), puedo ver qué temas les interesan. De qué escuchan los informes, de qué hablan y escriben publicaciones.

Y la productividad es exactamente uno de esos temas. Por los nombres de informes como "Optimización del tiempo de lanzamiento de aplicaciones iOS"se puede ver: los desarrolladores están dispuestos a pasar 60 minutos para escuchar milisegundos.

Hablan de productividad en todas partes, incluso en el mundo de JavaScript ( "Rendimiento de JavaScript a través del catalejo" ), al menos en el desarrollo móvil ( "Cómo encajar un millón de estrellas en un iPhone" ). Pero sobre todo dicen en el backend. Creo que esto se debe a que los usuarios compran teléfonos inteligentes para ellos mismos, pero en el back-end, la compañía paga por la potencia informática, por lo que existe una poderosa motivación financiera para optimizar.

Recientemente hice un experimento simple: abrí el programa de nuestro JPoint de conferencia Javay miró cuántas descripciones de rendimiento había sobre el rendimiento. Más tarde, debido al coronavirus, pospusimos la conferencia a junio, para que el programa pueda cambiar, pero los resultados son indicativos en cualquier caso. Son:

  • "Esta charla será sobre el ajuste del rendimiento del productor".
  • "Considere los métodos de optimización de E / S de archivo"
  • "¿Quizás para uno de los módulos desea más rendimiento del que puede extraer de Java?"
  • "¿Qué optimización relacionada con el punto seguro hace HotSpot JVM?" ¿Qué deben recordar los desarrolladores para evitar pausas no deseadas?
  • "Proyecto Valhalla, tipos en línea y todo lo que los rodea, desde el modelo de software hasta el rendimiento"
  • "Optimizar el rendimiento de la consulta, el rendimiento y el consumo de memoria"
  • "El informe está dedicado a un análisis detallado de cómo se produce el proceso de escritura en la base de datos de Apache Cassandra en términos de rendimiento".

Escucha, si realicé este experimento como un juego de beber, al final me habría emborrachado. A simple vista, puede ver: a los desarrolladores de Java les importa cómo hacen que su código no solo funcione, sino que también sea rápido.

Además: ¡a menudo incluso los excita demasiado! De personas que están estrechamente involucradas en el desempeño, he escuchado repetidamente que es fácil exagerar. Por ejemplo, en aras de un ligero aumento en la productividad, las personas usan algún tipo de trucos sucios, que al final crean más problemas de los que resuelven. Bueno, al respecto fue en la hermosa nota clave de Alexey Shipilev en JPoint 2017, hicimos el descifrado de Habr .



Para resumir: mientras Internet lamenta "los desarrolladores fueron flojos y dejaron de pensar por completo en los frenos", en realidad, muchos desarrolladores piensan más en ellos de lo necesario .


Significado y conveniencia


Y ahora, en mi opinión, la tesis más importante.

Sí, las aplicaciones a lo largo del tiempo requieren cada vez más recursos, a veces por órdenes de magnitud. Sí, comenzamos a arrastrar mucho más en nuestros proyectos, incluso cuando hay algo no demasiado necesario allí, en lugar de perder tiempo en aislar lo "estrictamente necesario". Es verdad.

Pero creo que las aplicaciones desarrolladas no hacen que los desarrolladores de hoy sean tontos ineptos. Además, lo contrario es cierto: los

desarrolladores serían tontos si las aplicaciones NO hubieran crecido.

Imagine un mundo en el que el hardware se está desarrollando activamente, y el enfoque para el desarrollo de software sigue siendo el mismo. Los programas aún encajarían en el volumen del disquete, aunque nadie hubiera usado el disquete en sí. En nombre del rendimiento, casi todo se escribiría en C ++. Todos los desarrolladores bajarían constantemente a niveles bajos y conocerían cada lugar donde se pueden extraer un par de bytes. No existe "ahora instalaremos cinco bibliotecas para esta tarea", solo soluciones que se han verificado cuidadosamente para un proyecto específico, en el que no hay una línea adicional. En general, unas vacaciones de optimización y un enfoque cuidadoso de los recursos. Todo lo que ahora se lamenta como una "habilidad perdida".

¿Sabes qué impresión me causa esta imagen? Una familia numerosa se vio obligada a vivir en una habitación pequeña, por lo que aprendió a colocar las cosas con precisión milimétrica y dominó el arte secreto de crear camas de cinco niveles. Y luego se mudó a un espacioso apartamento de varias habitaciones, pero por costumbre solo tomó una habitación allí, dejó todas las demás vacías. La gente todavía está sentada en la cabeza del otro.

Pregunta: ¿Crees que esto es una locura? Si fue posible darles a todos mucho espacio, ¿por qué guardarlo? ¿Quién mejor de la artesanía antigua de las camas de cinco niveles, si al mismo tiempo no hay ningún lugar para invitar a alguien a visitar? ¿Es hora de dominar la nueva habilidad de elegir una cama king size?

Lo mismo es cierto en el software. Si en una era en la que incluso los teléfonos inteligentes de bajo presupuesto tienen 64 gigabytes cada uno, experimentaremos "el tiempo de ejecución de Kotlin aumentará nuestra aplicación en megabytes", entonces nos convertiremos en esta familia. Relájate, un lugar para eso es necesario para que haya algo en él. Si se desperdicia, no hace a nadie mejor. Si hay mucho espacio y, por alguna razón, se necesita un piano, puede configurarlo de forma segura sin preocuparse por los centímetros cuadrados.

Slack: este es el piano. De acuerdo, él consume mucha memoria, pero ¿has oído a personas que no son de TI quejarse de él como solían quejarse de Photoshop? Según mis sentimientos, los usuarios comunes ya tienen suficiente espacio para que este "piano" no les impida "caminar por la habitación". Sí, puede reemplazarlo con un piano y ahorrar espacio. Pero si vives en un palacio, y con los años el área del palacio se vuelve aún más grande, entonces ¿por qué?

En mi opinión, debido a Slack, son personas de TI en su mayoría con experiencia que necesitan RAM para otras tareas difíciles. Pero las personas de TI son una historia diferente: desarrollando una metáfora de un departamento, estas son personas cuyo taller está hecho de un departamento. Bueno, sí, no importa qué palacio proporciones, todas las habitaciones estarán ocupadas con algo muy importante. Y luego el piano puede interferir, porque puedes poner un torno en su lugar. Pero la mayoría de las personas en el mundo viven de manera diferente, no necesitan tornos en casa y ya hay suficientes recursos para su estilo de vida.

Y en tal situación, es febril evitar todo lo que ocupa memoria, cuando ya hay mucha, es como con los administradores de tareas móviles, donde los usuarios golpean las aplicaciones en ejecución para "borrar la RAM". Muchas veces, los creadores de plataformas móviles han dicho: “Detente, locos. El sistema mismo eliminará las aplicaciones si no hay suficiente memoria, y ¿por qué deberían enclavarse antes? ¿Cuál es el punto de comprar un teléfono inteligente con una gran cantidad de RAM y luego mantenerlo vacío y no usar lo que pagó?


Se ve optimizado. Quieres vivir aqui

Y también recuerdo la historia con el "error 2000". Alguien de especialistas en TI de mediados del siglo XX en la vejez recordó: “Estábamos entre los que lo dieron a luz. Luego guardamos cada byte. Y cuando se nos ocurrió la idea de que puedes mantener el año en dos números, no en cuatro, nos sentimos muy inteligentes. ¡Guardamos dos bytes en un montón de lugares! Y solo hacia fines de siglo las consecuencias se hicieron claras ”.

Sí, en ese momento registrar el año en dos dígitos probablemente parecía una decisión razonable. Y encarna directamente a todos los que abogan por un enfoque "cuidadoso". Aquí es donde realmente llegaron al límite en el cuidado de los recursos.

Pero luego, muchos años después, otras personas tuvieron que gastar muchos recursos para determinar las consecuencias de esta decisión y evitar problemas.

Y ahora, cuando los dos bytes guardados ya no ayudarán a nadie, y se conocen las consecuencias negativas, sería muy extraño mantener un año como este.

Entonces: gran parte de lo que quiero cantar hoy como "conservación racional de los recursos" en el futuro se verá como el mismo "ahorro en partidos", que gastó más recursos de los que ahorró. Por ejemplo, porque el tiempo del desarrollador también es un recurso muy valioso, y a menudo no se incluye en los cálculos aquí. Si ha ido más allá de la alineación de datos, y su aplicación se ha vuelto un poco más pequeña y más rápida, pero pasó una semana en esto, que podría haber sido una función útil, ¿mejoró o empeoró al usuario?

, « , , ». .

— . , , .

, - ( ), . .



Anticipo la objeción en los comentarios: "Pero la tarea X comenzó a realizarse más lentamente para mí que hace 13 años, devuélvame mi 2007".

No me malinterpreten: no estoy tratando de decir que no hay tales tareas. Hay . Y el uso excesivo de dependencias sucede. Y sucede el bloatware. Cuando escucho que hay edición de video en Photoshop, siento el mismo "por qué" que tú. Cuando leí que crear cualquier aplicación con create-react-app significa inmediatamente 4304 directorios con 28678 archivos, también tengo una pregunta si nos hemos ido a otro lado. Hay muchos problemas reales de los que vale la pena hablar.

Mi único reclamo es que, en relación con estos problemas, existe una especie de secta radical que cree en el extremo cercano del mundo debido a la proliferación de software. Reescriben la historia en esta secta ("solía funcionar más rápido"), no entienden lo que está sucediendo ("por qué Windows ha crecido tanto a lo largo de los años, nada ha cambiado realmente"), se dicen cosas inmerecidas sobre los desarrolladores ("no quieren optimizar nada" ") E ir a los extremos" guardemos cada byte, incluso cuando empeora a los usuarios ". No hagamos eso.

Mis objeciones a la posición radical, por supuesto, también resultaron ser algo radicales (solo en la dirección opuesta). También puede encontrar fallas en ellos, y también se les puede llamar una secta. Pero el propósito de esta publicación no es hacer que cada palabra mía se considere la verdad última. Su objetivo es hacer que las personas estén menos involucradas en las sectas.

La conclusión principal es aburrida y banal, pero no menos correcta: todo depende de la situación específica. La optimización no es el mal absoluto ni el bien absoluto. Ambos pueden ayudar y dañar. Hay situaciones donde las optimizaciones claramente valen la pena, y situaciones donde claramente no valen la pena. Y hay situaciones intermedias en las que diferentes personas considerarán "vale la pena o no" de diferentes maneras, y ninguna de ellas tendrá más razón, y esto es normal.

Y si alguien, incluyéndome a mí, te dice lo contrario, este es un sectario, persíguelo en el cuello.

More articles:


All Articles