Qué idioma de servidor elegir ... para un desarrollador móvil

Usted le dirá cuál es el problema al desarrollador móvil antes de escribir el backend. Lo principal es que la API debe ser conveniente, comprensible y flexible. Pero no lo creemos así.

En AppsConf, todos pensamos que a veces necesitamos ir más allá del desarrollo móvil y bombear el sombrero de la letra T en el modelo en forma de T. Aquí, por ejemplo, conozca los idiomas del servidor un poco más profundo que: "Escuché que Ruby murió". Y un poco más amplio, es decir, no solo con los populares, sino también de las segundas filas e incluso las subterráneas.

Para inspirarte con la idea de la canción introductoria, grabamos una entrevista con Nikita Sobolev. Iban a hablar sobre lenguajes de programación, pero resultó sobre programadores. Entra en el corte si crees que es mejor ser solo un buen desarrollador, y no un desarrollador de Android o iOS, y especialmente si no estás de acuerdo con esto. El viernes es el momento de discutir.

- ¿Qué le parece la idea de una pista completa de informes de revisión sobre diversas tecnologías desde el backend hasta el frontend en la conferencia sobre desarrollo móvil, que llamamos introductoria?

Nikita Sobolev CTO en wemake.services, autor de la metodología del Proceso de desarrollo de software repetible, organizador de ElixirLangMoscow, miembro del comité del programa Moscow Python Conf ++ , orador frecuente en conferencias de TI y defensor de la calidad del código .


En mi opinión, esta es la mejor pista en una conferencia móvil.

Realmente no me gusta la idea de especialistas limitados. Estoy mucho más cerca de la idea de una persona en forma de T, es decir, una persona que conoce bien una cosa, pero con un amplio horizonte de comprensión de los problemas en el área temática.

Desafortunadamente, me parece que los desarrolladores móviles en este sentido están solos. El asunto se agrava por el hecho de que dependen mucho del proveedor. En términos generales, Apple cerrará, se irán en el frío.

Por lo tanto, me gusta mucho la idea de la pista introductoria y el hecho de que los invitados a la conferencia están invitados a mirar alrededor, descubrir lo que otros tienen, adoptar su experiencia y mejorar como especialistas en términos de amplitud de puntos de vista.

- ¿Para qué otras conferencias es relevante esta idea?

Para muchos Tengo a mano un ejemplo de Python. La última vez invitamos a Go, Elixir y Julia. Este año quiero invitar al front-end y al Haskellist (por cierto, Call for Papers ya está abierto ). Debido a que los desarrolladores de Python también son diferentes, muchos de ellos funcionan como full-stack, también es útil para ellos obtener conocimiento del exterior.

- ¿Crees que los desarrolladores móviles se han vuelto más dispuestos a mirar a su alrededor, porque se ha vuelto necesario para el desarrollo profesional, o siempre ha sido así, solo la comunidad ha madurado?

Me resulta difícil juzgar con precisión la última vez que escribí una aplicación móvil en 2010. Mi lenguaje principal era Java, tomé Objective-C y escribí una aplicación para iOS. Estaba inspirado, pensé, ahora comenzaré a hacer todo esto. Pero no: no había gestión de memoria, no había bibliotecas, no había gestión de dependencias, el sistema de compilación era asqueroso. Desde entonces, no he examinado cuidadosamente esta área.

Y ahora veo varias tendencias que naturalmente atraen a los trabajadores móviles a la "programación seria".

En el pasado, los idiomas estaban altamente especializados en esta área. Objective-C fue solo para el desarrollo de Apple. Y ahora, por ejemplo, están tratando de atraer a Swift al servidor y hacer algo al respecto. Java para el backend y para Android eran dos idiomas diferentes. Y ahora Kotlin es más o menos similar para ambos. JavaScript apareció en el mundo del desarrollo de aplicaciones móviles, y este es algún tipo de lenguaje de servidor y, al mismo tiempo, un lenguaje para la interfaz.

Hay una única infraestructura que comienza a interesar a las personas. Si antes (en mi caso, esto es 2010) el desarrollo móvil estaba completamente fuera de contacto, ahora todo es diferente.

Además, el acercamiento es en ambos lados. La integración más estrecha de la plataforma brinda a las personas la capacidad y la necesidad de seguir esta integración.

- Pero si la integración en sí va al desarrollador móvil, ¿por qué debería entender los idiomas para el backend?

Tengo una respuesta filosófica a esta pregunta.
Si quieres ser un desarrollador de Android, entonces probablemente no necesites entender el backend. Y si quieres ser solo un desarrollador, por supuesto, es necesario.
Un desarrollador es alguien que resuelve problemas del mundo real con código. En consecuencia, las decisiones pueden ocurrir en todas partes, incluso en una aplicación móvil, en un servidor, en una interfaz. Un buen desarrollador puede resolver en principio cualquier problema del mundo real utilizando herramientas de desarrollo.

Está claro que hay una entrada para cada una de estas herramientas, la acumulación de práctica, etc., pero la fijación rígida en una tecnología, en mi opinión, es perjudicial para la persona que se dedica a esto.

Al menos la tecnología se está volviendo obsoleta. Los idiomas que eran populares hace 15 años ahora casi nunca se usan. La habilidad de desarrollar y aprender constantemente cosas nuevas, mirar a los vecinos, es de vital importancia para cualquier desarrollador. En particular, es importante entender el backend, porque el backend es fundamental para todo el desarrollo, hoy todo se comunica de alguna manera con el servidor.

Además, los usuarios de movilidad se sienten incómodos con otros desarrolladores a quienes les resulta más fácil encontrar un lenguaje común. El front-end y el back-end están aún más cerca que el desarrollador de aplicaciones móviles de cualquiera de ellos. Mi informe ayudará en cierta medida a cerrar el problema de la comunicación humana, ayudar a integrar.

Qué tan profunda o superficial necesitas entender es otra pregunta. Especialmente si estamos hablando de un desarrollador móvil que, sea lo que sea que uno diga, necesita profundizar en su campo.

Estoy a favor del hecho de que necesita mirar activamente a su alrededor y en el pasado. Es importante estudiar la historia del software y la programación. Si no conoce la historia, reinventará muchas cosas que ya se le ocurrieron y abandonó por razones completamente objetivas. Dirijo un canal de telegramas donde comparto enlaces a proyectos geniales de código abierto sin estar ligado al idioma, trato de resaltar ideas importantes.

- ¿Tiene un desarrollador de aplicaciones móviles suficientes ideas generales o no?

Depende, en primer lugar, del medio ambiente. Si una persona tiene la necesidad de influir directamente en el backend de su empresa: para establecer tareas más correctas para ellos, para participar en el proceso, tal vez para administrar a estas personas, entonces tendrá que resolverlo profundamente.

Pero si solo participa en el desarrollo móvil, es suficiente tener una idea superficial de lo que está sucediendo allí, qué idiomas, problemas y soluciones populares son. Para esas personas, también se calcula mi informe sobre Saint AppsConf. Naturalmente, una presentación profunda no se puede dar en un informe.

- ¿Qué más necesita un desarrollador para ser un desarrollador genial?

  • La capacidad de leer y comprender lo que se lee.
  • Capacidad para escribir, expresar sus pensamientos por escrito.
  • La capacidad de hablar para expresar estos pensamientos verbalmente.
  • Capacidad para escuchar y escuchar a otras personas.
  • Comprender el área temática. El desarrollador debe entender lo que está haciendo, porque resuelve el problema de la vida de manera técnica.
  • Y, por supuesto, entender la técnica.

Estas habilidades, me parece, son suficientes. Todo lo demás puede deducirse de estos o descartarse.

- ¿Entonces crees que necesitas entender el tema?

Limitado, por supuesto, pero necesario. Por ejemplo, simultáneamente tenemos 3-4 proyectos, por supuesto, no los entiendo todos a la perfección, pero entiendo los conceptos básicos con los que trabajo. Cómo están interconectados, cómo afectan el dinero, dónde está el gasto, dónde están los ingresos, por qué es todo esto necesario para los negocios.

Y también aconsejo a otros desarrolladores. En nuestra empresa, elaboramos documentación para ellos, cómo funciona el negocio, qué problemas resolvemos, por qué esto no se puede resolver con las manos. A veces, contratar a una persona para que una vez, por ejemplo, haya revisado un directorio de productos, es más barato. Si automatizamos el proceso, debe comprender por qué.

- Veamos un ejemplo. Si escribe un servicio de entrega para una panadería, debe comprender cómo funciona la entrega, pero no tiene que comprender los tipos de bollos que hornea esta panadería.

Y en algunos tipos de bollos también. Porque algunos bollos se pueden almacenar durante una hora y unos dos días. En consecuencia, su entrega será diferente.

- En su informe, promete considerar varios idiomas populares a la vez, varios idiomas de la segunda fila y varios idiomas del subsuelo. ¿Qué idiomas serán?

No tomaré esos idiomas que los participantes de la conferencia ya pueden conocer: Kotlin, Java, JavaScript. No tiene sentido hablar de ellos si la mayoría de la audiencia ya está familiarizada con ellos. Decidí hablar sobre idiomas que la gente no sabe, porque las aplicaciones móviles no les escriben en absoluto. Hay mucho para elegir.

Básicamente me encantan los lenguajes de programación. Sin una tarea específica. Me gusta el lenguaje de programación como idea. Algunas personas pensaron: “Hay un conjunto de problemas de este tipo, se pueden combinar y resolver de una vez. Hagamos un lenguaje para esto. Resolverá una lista específica de problemas. Y otro idioma resolverá otros problemas, porque generalmente no se pueden resolver todos los problemas a la vez.

Realmente me gusta ver qué problemas resuelve cada idioma y por qué puede ser necesario en la práctica. El lenguaje mismo se convierte en un objeto de arte intelectual para mí. Un gran número de personas trabajó, pensó, diseñó, optimizó. Esto es muy interesante, así que sigo muchos lenguajes de programación.

Los idiomas que elegí para el informe tienen varias características interesantes. En primer lugar, son controvertidos. Ninguno de ellos es un lenguaje que, en última instancia, sea bueno en todo en la conciencia de la comunidad.

Todo el mundo sabe que Python es lento, pero sigue siendo el lenguaje más popular, se usa en todas partes. Trataré de explicar por qué se usa.

Y hablando de Ruby, lo primero que dice la gente es que Ruby está muerto. De hecho, los desarrolladores de Ruby ahora se molestan más que en cualquier otro idioma con la arquitectura e implementan una gran cantidad de ideas de otros lenguajes: funcionales, orientados a objetos y hacen algo muy interesante.

Si hablamos de Go, entonces Go tiene un ámbito de aplicación muy limitado, pero a raíz de la exageración, todos comenzaron a escribir sobre él.
Cada uno de los idiomas que he elegido representar durante el discurso tiene algún tipo de conflicto.
Como personaje en una buena historia. Y la esencia del conflicto es que algunas cosas funcionan bien y otras no. Este conflicto estará a la cabeza del informe.

- ¿Crees que necesitas elegir tu idioma para cada tarea, proyecto?

Esta es una buena idea, pero no funciona en la práctica. Exactamente donde empezamos. Hay programadores de Android, hay programadores de Python que, cuando les muestras el código Ruby, que es lo mismo, solo en el perfil, dicen: "Oh no, todo es incomprensible, no quiero entender".

Por supuesto, me gustaría que las personas sean más versátiles y puedan elegir un instrumento para la tarea, pero resulta que las personas saben una cosa y siempre toman esta herramienta.

El factor de contratación también se agrega aquí. Por ejemplo, en nuestra empresa, no pudimos elegir entre TypeScript y Python. Pero, si necesito contratar a un desarrollador de Elixir, lo buscaré toda mi vida. Conozco a tales desarrolladores, pero no tanto, y no para poder atraerlos rápidamente hacia mí. Por lo tanto, debe moderar sus ambiciones y adaptarse al mercado y a los clientes, que también tienen una pila limitada de acuerdo con el mercado.

- Prometes una mirada subjetiva a casi 10 idiomas completamente diferentes. ¿Estás realmente familiarizado con todos ellos? ¿Escribiste algo sobre todos ellos?

Con cada uno de diferentes maneras, pero, por supuesto, los probé todos al menos hasta cierto punto.

Por ejemplo, en Rust escribo código abierto, y en pony escribí 15 líneas de código, leí el tutorial, lo admiré y ahora quiero mostrarles a los participantes de la conferencia. Para que ellos también se inspiren en la idea.

- Obviamente, en un informe no podrá dar una imagen completa y la comprensión de cada idioma. ¿Por qué la gente debería ir a su informe y no googlearlo?

La razón es que cuando una persona viva te lo dice, es completamente diferente. Un informe hasta cierto punto es siempre un espectáculo. Cuando las personas acuden al programa, reciben no solo contenido, sino también emociones. Cuando googleas, solo obtienes contenido. Si está interesado en él, lo buscará en Google de todos modos. Y el formato del discurso de una persona viva permite popular y fácilmente obtener conocimientos interesantes.

- ¿Cuáles serán los elementos principales de tu "show"?

Hay muchos idiomas, todos son geniales, pero no hay nada sobre lo que escribir.

Existen muchos idiomas populares para resolver sus problemas comerciales: contratación, clientes, bibliotecas. Pero todos se hicieron populares por una razón. Como regla general, la razón principal es que son muy simples. Se basan en conceptos simples que son fáciles de comenzar, pero difíciles de continuar.

Hay lenguajes de nicho, y ya están apareciendo conceptos complejos muy interesantes sobre los que puedes construir algo grande y confiable: Rust con su excelente compilador, Elixir con su máquina virtual absolutamente perforadora, Haskell con su sistema de tipos, etc. Pero no pueden volverse populares solo por el alto umbral de entrada.

La mayoría de los desarrolladores que quieren aprender algo toman idiomas populares y les escriben. Y no surge la pregunta de por qué podría necesitarse algo más, porque en los proyectos con los que trabajan, no se requiere nada más complicado.
Es muy importante para el desarrollador comprender las limitaciones de la herramienta.
Para comprender la limitación, debe descansar contra su frente, combatir un problema y luego retroceder y mirarlo desde la distancia. Solo en los informes de personas que han trabajado con algo durante muchos años se manifiesta esto. Y conozco bien a estas personas, he acumulado varios casos y sé dónde descansar. Y puedo resumir mi experiencia y la experiencia de otras personas.

- Escribir "Hola mundo" en Haskell ya es una gran hazaña, pero ¿no es suficiente?

Sí, necesitas hervir en la comunidad de funcionarios. Para escuchar qué problemas resuelven, qué informes hacen, para que pueda comprender la sección.

Por ejemplo, en la comunidad Haskellist, el problema de entrada es muy grave. Todavía no pueden resolverlo y hacer que su idioma sea más amigable para los principiantes. Históricamente, Haskell usa una sintaxis completamente diferente y reglas completamente diferentes, solo para escribir al menos algo. Incluso un desarrollador experimentado al principio no estará completamente claro qué está sucediendo en este código.

Y el asunto no es solo en la programación funcional. Si comienza a familiarizarse con las funcionalidades de Elixir, será mucho más fácil. Elixir es muy similar en sintaxis a Ruby. Al principio, no verá la diferencia, puede escribir de la misma manera que en Ruby. Y solo entonces queda claro que este es un lenguaje funcional. No lo notas hasta cierto punto, y luego descubres oportunidades adicionales para ti. Usted comprende que, de hecho, está construido sobre principios completamente diferentes. Conociendo esta base, se vuelve fácil cambiar a un lenguaje funcional menos amigable.

El orden es importante.

- Además de los idiomas populares y los idiomas, como usted dice, de la segunda serie, que al menos se escucha en cierta medida, presentará otros completamente desconocidos. Por ejemplo, ¿qué es este pony?

Pony es un lenguaje de programación de código abierto, orientado a objetos, modelo de actor, capacidades seguras y alto rendimiento. Es decir, fuertemente tipeado, seguro para la memoria, lenguaje de actor. Es muy joven y muy interesante.

Sus desarrolladores crean un lenguaje en el que puede crear una gran cantidad de actores, como en Elixir, pero estos actores tienen garantizado la escritura segura. Los límites de aplicabilidad de este lenguaje aún son completamente incomprensibles. Pero yo diría que puede golpear Go, y yo apoyo activamente todo lo que pueda golpear a Go.

- Si todos los idiomas tienen defectos y limitaciones, ¿qué hacer? ¿Qué hacer al respecto?

A sufrir Y sigue buscando la excelencia técnica. Este es un sueño inalcanzable para cualquier ingeniero, pero el proceso de encontrar esta excelencia es un gran objetivo.

Saint AppsConf después de 10 días. El Comité del Programa seleccionó 35 informes y 12 reuniones, entre las cuales cada desarrollador móvil encontrará ideas útiles para resolver problemas cotidianos y para su desarrollo profesional y personal. ¡Nos vemos el 21 y 22 de octubre en San Petersburgo!

Una pregunta extra para aquellos que desean compartir su experiencia, pero por alguna razón aún no se han convertido en oradores. A menudo hablas, ¿por qué lo necesitas y qué te motiva?

Tengo tres objetivos:

  • Diviértete, me gustan mucho las conferencias, es divertido e interesante.
  • Local: encuentre desarrolladores y clientes.
  • Global: para mejorar nuestra industria . Veo muchos problemas y quiero influir positivamente y sacar lo bueno de lo malo.

Un orador en una conferencia puede influir en una industria a través de una audiencia. Él desde la tribuna puede probar su punto de vista y motivar a las personas a cambiar.

Source: https://habr.com/ru/post/471070/


All Articles