Cinco tendencias aterradoras del diseño moderno.

El hábito es una fuerza terrible. Te hace resistir el cambio, impide el desarrollo. Pero en TI, nos encanta estar a la vanguardia de la tecnología, nos encantan los desafíos, nos encanta implementar lo que se extenderá a otras áreas en solo unos pocos años.

Estamos listos para lo nuevo y es posible que no esperemos hasta que llegue el futuro, y tendremos que adaptarnos a él. Podemos avanzar, para saber solo en qué dirección.

Egor Bugaenko sabe lo que hay que hacer ahora para seguir siendo un programador codiciado en 5–10 años. Sus ideas, como siempre, pueden parecer controvertidas. No necesita estar incondicionalmente de acuerdo con ellos, pero pensar, por ejemplo, en el proyecto de mascotas no volverá a doler. Y el hecho de que el programador necesita inglés, difícilmente puede haber opiniones diferentes. Pero en los puntos restantes será interesante conocer la opinión de la comunidad en los comentarios.



La siguiente es la versión de texto del informe de Egor sobre AppsConf , pero se refiere no solo y no tanto al desarrollo móvil, sino a la industria en general. Egor Bugaenko, fundador de Zerocracy, desarrollador de Cactoos, Takes Framework, JCabi y otros proyectos de código abierto. Escribió una serie de libros llamados "Objetos elegantes", mantiene un blog provocativo y ofrece informes que invitan a la reflexión como este.



Comenzaré con una historia sobre cómo no hace mucho tiempo decidí comenzar a desarrollar software para dispositivos móviles y rápidamente colisioné con que no sabía cómo hacerlo. Por lo tanto, decidí pedir ayuda a alguien que me dijera cómo crear una aplicación en un formato completo. Es decir, cree una aplicación que estará disponible en Apple Store.

Me preguntaba cómo ensamblar la aplicación en un paquete, es decir, no solo dibujar algunos botones en la pantalla, sino hacer una aplicación completa . Obviamente, el código, por ejemplo, en Swift y el producto en el teléfono móvil, son dos cosas completamente diferentes: la primera es muy pequeña y la segunda es muy grande e incluye tales preguntas:

• Pruebas unitarias
• análisis estático;
• Integración continua
• gestión de dependencia;
• Entrega continua;
• Entorno de estadificación;
• Proceso de aprobación de la aplicación en Apple Store
• proceso de montaje de defectos de producción, etc.

Cómo organizar los botones en la pantalla es fácil de leer en Internet. Necesitaba un especialista, un experto que me ayudara a ensamblar toda la tubería. Para mí, como programador, esto es más importante que organizar los botones en la pantalla.

Encontré a tal especialista, pero él me dijo: “¿Por qué estás pensando en esto? Dibuja la aplicación primero. ¿Qué es la integración continua? Espere hasta que con las pruebas unitarias, haga que funcione ¿Qué es una tubería de entrega? Por qué TestFlight: utiliza un simulador ".

Seguramente es un buen programador, pero en su opinión, en mi opinión, todo está al revés . Él piensa que el código es importante y el resto del paquete es secundario. En mi opinión, este es un gran problema, y ​​quiero hablar sobre esto.

Por alguna razón, muchos desarrolladores creen que el código en sí es importante, y el ensamblaje es lo que hace el ingeniero de DevOps u otra persona. Por lo general, cuando vienes a un equipo, ya está hecho y configurado. Te encuentras en un proyecto donde escribes código, sin saber cómo todo termina en producción. Creo que el hecho de que los programadores no vean el ciclo completo de ensamblaje, no sepan cómo funciona, es un problema.

Primero despliegue, luego codifique

Escribo libros sobre programación, y sé por mí mismo que un libro funcionará bien si primero lo diseñas maravillosamente . Es decir, diseño el libro antes de escribir. Primero hago un archivo MAKE, que directamente desde la línea de comandos recoge todo el libro de los archivos en LaTeX, prepara textos, imágenes, carátulas. Paso mucho tiempo y lo hago para que con un solo comando recopile todo el libro en un archivo PDF. Presto mucha atención a cómo se verá, dónde están las sangrías, qué bloques de texto y la distancia entre ellos, cómo se numerarán las páginas. Cuando me gusta todo esto, veo que todo está bellamente ensamblado y todo en este producto está completo, incluso si solo se ha escrito una página hasta ahora, solo entonces comienzo a escribir un libro, y solo entonces me da placer.

Muy a menudo, los programadores hacen lo contrario: escriben, ejecutan en el simulador, verifican el trabajo. Creo que es más correcto implementar primero, luego el código .

Daré un ejemplo más. Un desarrollador novato se ofreció como voluntario para hacer un proyecto de código abierto con nosotros. Él eligió Flutter, hizo la primera iteración, comenzó, dijo que todo era genial y se ofreció a mirar. Preguntamos: “¿Cómo probar algo? Aquí está el iPhone: ¿dónde empujar? Lo que comenzó a explicar, a dónde ir, qué descargar, fue un proceso largo.

Esto nos pareció incómodo y, al final, estuvo de acuerdo en que la aplicación realmente debe cargarse en TestFlight. Después de un tiempo, mostró la aplicación en TestFlight. Apreté los botones y noté algunos defectos. No trabajé con Flutter y realmente no quería hacerlo, pero quería arreglar rápidamente lo que noté. Pregunté cómo hacer esto, dónde y cómo enviar una solicitud de extracción. Abro el repositorio, archivo readme: "Esta es una aplicación genial ... haga clic en descargar ...".

Las instrucciones eran complicadas e incomprensibles, nuevamente pregunté cómo implementar todo esto en mi computadora. Solo quería modificar el código de otra persona con un simple clic de unos pocos botones en mi computadora, iniciar el simulador y enviar una solicitud de extracción. Ese tipo fue a describirlo todo, y nunca regresó.

Esta situación ilustra que sus cualidades como programador son buenas: pudo ejecutar la aplicación. Pero sus cualidades, como persona que ve todo el proyecto, dejan mucho que desear. Como resultado, el proyecto no solo me perdió como colaborador, sino también a muchos otros. Este programador no recibió devoluciones de otros, trabajó como un solitario.

En mi opinión, estar solo está mal en este momento. El mercado se está moviendo hacia equipos poblados más grandes: habrá más personas en ellos, vendrán y se irán más a menudo.

La dinámica de los recursos humanos se está moviendo hacia una mayor rotación, por lo que cada persona que viene al proyecto nuevamente necesita verlo en su totalidad, no solo el código que se ejecuta en los simuladores.

Un novato debe entrar en un entorno amigable para él desde el punto de vista del ensamblaje: necesita abrir un archivo léame y comprender en unos minutos cómo hacer que todo comience en el simulador. En qué hacer clic para verificar si todo está construido desde la línea de comandos, no desde IDE complejos que deben configurarse durante varias horas más. Debería ser posible escribir make / build / etc en la línea de comando. Después de eso, todo se recopila e imprime una línea verde (todo está listo) y luego se retira la solicitud. Este es el primer pensamiento que quiero compartir hoy.

Por supuesto, dirá que no está trabajando solo, no como los únicos fundadores de proyectos, no como CTO. Trabaja en equipos y no puede simplemente decir que ahora se ocupará de la implementación, TestFlight, y que necesita comprender urgentemente CI. Esta no es su tarea, no se le dará tiempo para ello, etc.

Por lo tanto, le recomiendo que haga sus propios proyectos de mascotas, proyectos que haga para su propio placer, para comprender todo en su totalidad.

Solo el 20-30% de los programadores tienen su propia aplicación publicada, y todos deberían tenerla. Si te consideras y quieres ser un programador muy solicitado, te recomendaría hacer tu aplicación móvil y pasar por todo el ciclo de su entrada en el mercado: controles en Apple Store, CI, empaque y todo lo demás. Que sea de código abierto para que las personas puedan contribuir y mostrarle cómo fallan.

Vea cómo trabaja con el mercado, intente comprender qué tipo de programadores es usted. Creo que un programador que no tiene proyectos favoritos es malo.

O no está interesado en su profesión, o no le importa, o no puede o tiene miedo. Es un miedo ver todo el ciclo. Tenemos miedo de ver el proyecto como un producto listo para el cliente. Y el cliente para nosotros en muchos casos es otro desarrollador, ya que en mi ejemplo fui desarrollador de clientes en Flutter.

El segundo miedo, en mi opinión, es el dinero.

¿Cuánto código escribirás por $ 100?

Trabajo con muchos programadores en la plataforma Zerocracy y noté que a menudo tienen miedo al dinero. Están acostumbrados a pagar a fin de mes, y son bastante dolorosos cuando se valoran en dinero. Muchos no pueden responder la simple pregunta: "¿Sabes cuánto puedes hacer código por $ 100?"

Seguramente sabes cuánto quieres ganar por mes. Imagine cuánto cuesta un mes completo de su vida: un apartamento, un automóvil, pagos regulares, el grado habitual de comodidad y entretenimiento.

Los desarrolladores de pago fijo a tiempo completo se están quedando sin tiempo.

Creo que trabajaremos cada vez más en equipos reunidos temporalmente, donde las personas vienen mientras son necesarias, y vamos más allá después de eso. La era de los desarrolladores que se sientan en un lugar se va porque la compañía los contrató hace muchos años, simplemente aman a esta compañía y, por lo tanto, están con ella, no importa qué tecnología use la compañía.

Conozco ejemplos de tales proyectos que se escribieron en C ++ durante muchos años, y luego me di cuenta de que necesitaban escribir en Java. Y las mismas personas, en la misma oficina, para el mismo cambio de dinero de los inversores, se vuelven a capacitar durante medio año y comienzan a tambalearse en Java. Este es un enfoque del pasado. En mi opinión, en el futuro tales enfoques dejarán de existir, porque no tendrán sentido.

El mercado se está volviendo global ; el acceso remoto al mercado laboral se está volviendo cada vez más fácil. Una empresa con sede en Moscú será poco interesante y no rentable para volver a capacitar a las personas, por ejemplo, de iOS a Android o de C ++ a Java. Es más fácil contratar nuevos especialistas que vendrán como autónomos, completarán la tarea y se irán.

Creo que este formato de proyectos será popular: proyectos temporales, donde los freelancers se reúnen, resuelven sus tareas: un experto en esto, otro experto en eso y se van.

De los programadores, este nuevo tiempo espera:

• La capacidad de comprender cuánto vales. Es decir, calcule cuánto vale su hora de trabajo, cuánto valor creará para ella.
• Capacidad para trabajar en condiciones temporales.
• Habilidades para venderse, presente correctamente. Un desarrollador independiente en el mercado global debe tener una "ventaja comercial" y un precio.

Muchas personas tienen miedo de crear currículums, miedo de venderse. Como dije, creo que el resumen definitivamente debe incluir el elemento del proyecto favorito.

Los proyectos propios serán el primer indicador de valor en el mercado , y no donde haya estado desarrollando software que heredó durante 5 años seguidos. Creas un proyecto de Mascota desde cero, y no importa de qué se trata, qué tan complicado es o cuántas descargas tiene en la Apple Store. Deje que sean 0 me gusta y 2 descargas, pero este es un proyecto integral que usted mismo creó.

Para mí, como empleador, esas personas son más valiosas que las que han estado en la oficina durante muchos años y tienen un currículum con uno o dos empleadores. Me resulta difícil entender qué hacer con esta persona, cómo evaluarla. Sé que quiere que lo tome durante todo el mes y que sea amigo de él, independientemente del resultado. Para mí, este formato ahora es inaceptable, para una gran cantidad de empleadores en el futuro también será incómodo.

Por lo tanto, la recomendación es contar dinero, tratar de trabajar en contratos . Tal vez esto no sea del todo adecuado para sus empleadores, pero intente estar a tiempo completo y sentado en la oficina, al mismo tiempo que busca algunos microproyectos para un trabajo a tiempo parcial. No por dinero, sino para entender si el mercado te necesita como profesional independiente o no, si lo necesitas como experto o no. O solo necesita a su jefe, que tiene miedo de perderlo, porque solo usted sabe cómo funciona el código del proyecto.

Busque alternativas, vea, intente, venda . Al principio no te comprarán, habrá problemas, ¡muchos problemas! Pero al resolver estos problemas, se convertirá en un programador más buscado en un nivel superior.

Desafortunadamente, no solo los programadores mismos no pueden determinar el precio del trabajo, sino también los clientes. A veces me sugieren que realice ciertas tareas como experto. Y a menudo el cliente que me ofrece un trabajo no entiende cómo evaluarme. La mayoría de las veces, las personas solo quieren más barato, como $ 50, no $ 100, por hora. Entiendo que una persona con este enfoque todavía no comprende cuánto escribiré en tiempo real durante esta hora. Entonces estoy de acuerdo y simplemente multiplico el número de horas por 2. Como resultado, obtengo todo lo que originalmente quería.

Sé mi valor real y velocidad. Los clientes no están listos para cantidades de $ 100-500 por hora, para ellos 20 ya es mucho, porque están acostumbrados al formato de empleo a tiempo completo con el tiempo. Es decir, cuando una persona recibe dinero por el tiempo que supuestamente dedica al desarrollo.

No sé sobre ti, pero no puedo sentarme durante 8 horas escribiendo código. Estoy seguro de que cada uno de ustedes confirmará que de las 8 horas de trabajo que están en la oficina o en la computadora, en realidad escriben mucho menos código. Y pagan estas 8 horas, y el cliente piensa que son 8 horas de trabajo. Este es un sistema de doble engaño: están contentos de ser engañados, y nosotros los estamos engañando. Por lo tanto, uso el factor de multiplicación. Trabajaré durante al menos 20, pero luego haré 3 semanas lo que realmente puedo hacer en 2 horas.

Enseñe a sus clientes y aprenda a contar el dinero usted mismo.

Los buenos programadores escriben código, lo mejor - entradas

Tanto los clientes como los programadores están acostumbrados a la comunicación informal.

La comunicación informal en forma de chats, llamadas telefónicas, manifestaciones, correo electrónico es una forma de comunicación que destruye el proyecto y solo empeora al cliente y al programador.

La comunicación informal permanece en el aire, no se registra en la documentación, no se supervisa, es difícil volver a ella y hace que el proyecto sea difícil de mantener. Cuando un equipo cambia, y como dije antes, el equipo debe cambiar y cambiará más intensamente, se vuelve muy importante cuán comprensibles sean las comunicaciones pasadas en el proyecto.

Si llego a un proyecto en desarrollo, quiero entender lo que se ha hecho durante el año pasado, no solo en forma de código, sino también tener algún tipo de explicación para este código: por qué se eligió dicho marco o algoritmo, que ya ha expresado su opinión sobre este algoritmo Y no estaba de acuerdo. Quiero ver todo esto y no buscar en la oficina o conversar con alguien que me explique todo. Necesito la oportunidad de leer esto directamente en el repositorio o sistema de tickets.

Desafortunadamente, la mayoría de las veces los programadores siguen el ejemplo de los clientes. Por supuesto, en interés del cliente tener la oportunidad de comunicación informal con el desarrollador. Y nos encontramos lo suficientemente débiles y seguimos su ejemplo, escuchamos por teléfono lo que se debe hacer, respondemos, escuchamos, respondemos ... y luego vamos y lo hacemos.

Luego pasan 2-3 semanas y ya no recordamos lo que acordamos. El cliente dice que no quería esto, estamos tratando de demostrar que esto es lo que solicitó, estamos buscando alguna mención en el chat: comienza la captura de pulgas.

Creo que la razón es el miedo a los sistemas de tickets. Muchos programadores con los que trabajamos (por supuesto, esto también le concierne a usted) no saben cómo, no les gusta, no quieren formular tareas en forma de ticket: claro y conciso.

Es más fácil para la gente decir: "¡Hablemos!" Celebraremos un mitin, nos sentaremos juntos y decidiremos todo. En 3 horas nos entenderemos y luego iré a codificarlo. Recordaré lo que hemos acordado y programaré todo ". No olvides nada, nos vemos de nuevo. Y así, de alguna manera, nos extenderemos de rally en rally.

Esto esta mal. Nosotros, como programadores, debemos convertir cualquier comunicación informal en tickets. Hablamos con el cliente (cliente, propietario del producto, otro programador), descubrimos qué se debe cambiar: convertimos cualquier comunicación en un ticket limitado por el marco de nuestro sistema (Jira, GitHub, etc.), donde anotamos: qué no funciona, cómo necesita arreglarlo, por qué necesita arreglarlo, qué motivación, y luego trabajamos en este boleto.

La incapacidad de un programador para estructurar el trabajo en tickets puede indicar sus bajas calificaciones. Creo que hay dos tipos de desarrollo:

• Desarrollo continuo - programación de 9 am a 5 pm: llegué, encendí la computadora, luego hice algo, allí, almuerzo, también codifiqué, al final del día, bueno, mañana continuaré. Es decir, programamos mientras haya energía, tiempo y fuerza.
• El desarrollo incremental es diferente: existe la tarea número 13, la haré hasta el final y luego veré qué tarea es la siguiente. De esta forma, la tarea (ticket) siempre se completará. Pero si no hay un ticket, no hay una tarea documentada formulada, el proyecto no se mueve, el código no está escrito y la solicitud de extracción no aparece.

A menudo me encuentro trabajando en el primer escenario. Me gusta programar, en la mañana enciendo la computadora y me fui. Luego freno, pare, dividámoslo en tareas, determinemos a qué tarea nos trasladaremos.

En la segunda versión, cada ticket finaliza con una solicitud de extracción: aquí está el problema, su descripción, discusión en el campo de este problema, un cambio en el código. Solicitud de extracción enviada, verificada, aceptada: boleto cerrado, puede pasar a la siguiente.

Por lo general, las personas trabajan en ambos sentidos. Pero por alguna razón, uno de los principales problemas que enfrentamos: las personas simplemente no saben cómo dividir la tarea en otras más pequeñas.

Algunas personas creen erróneamente que el desarrollo incremental necesariamente significa una tarea de 2 semanas, y que el ticket debe finalizar con una solicitud de extracción de 5 mil líneas cambiadas. Este no es un desarrollo incremental. Incremental es una tarea de 0.5 a 2 horas, y al final de una solicitud de extracción de 50 a 100 líneas de código. Continuo, por el contrario: trabajas durante mucho tiempo (días, semanas) y produces poco.

Por lo tanto, digo que los buenos programadores escriben código, pero los mejores escriben tickets. Escribir código es más fácil que un buen boleto : esta es una buena explicación de por qué este código debe hacerse. Por lo tanto, si desea desarrollar y elevar su nivel, concéntrese en la capacidad de explicar a otro programador lo que debe hacerse y la capacidad de escuchar a un cliente o cliente y traducir sus pensamientos en tickets.

Daré un ejemplo de la vida. Recientemente, tuvimos un cliente que, como muchos otros, quería explicar la esencia del proyecto por teléfono. Habló por teléfono con uno de nuestros arquitectos varias veces. Después de una semana, descubrí que, a pesar de la discusión en curso, tal vez incluso se está escribiendo algún tipo de código, solo hay un ticket en el sistema. Esto es un error de un arquitecto que recibió una secuencia de información y no la estructuraron. Entonces, si hay problemas en el proyecto, no tendremos nada que responder al cliente insatisfecho. No levantaremos los registros de las conversaciones telefónicas.

Esto es solo un error de un arquitecto. El cliente no necesita saber esto. El cliente es una criatura caótica e indisciplinada que comprende poco durante el proceso de desarrollo. Él debería ser así. Pero nuestra tarea es ser más disciplinados , así que escriba tickets, estructura.

¿Qué lenguaje de programación aprender primero? Ingles!

El siguiente problema que encuentro a menudo y al que quiero prestarle atención es el idioma inglés. Muchos desarrolladores de habla rusa ignoran el idioma inglés, lo consideran algo secundario y no quieren aprender, o les es difícil darlo. En el ámbito de TI, hay una comunidad de habla rusa con la que, me parece, debemos luchar con todas nuestras fuerzas. Habr, como pionero de esta comunidad, ofrece un mal servicio.

Por supuesto, el idioma ruso es nuestro idioma nativo, y no hay necesidad de rechazarlo. Pero en el campo de los mismos boletos, códigos, conferencias, libros que lees, creo que deberíamos cambiar al formato solo en inglés .

Como dije, el mundo del desarrollo se está globalizando, habrá cada vez menos programadores de Moscú: solo habrá programadores, por ejemplo, en Swift, y habrá pocas personas que se preocupen por ti desde Moscú. Los programadores se venderán en todo el mundo a través de Internet, en lugar de a través de entrevistas de oficina. De una forma u otra, este mercado vendrá, incluso después de 5-10-15 años, y es posible que se quede fuera.

Crees que es más fácil comunicarse con un compatriota en ruso. Telegram-, , . — , . , , .

, . , .

, .

. , , .

. . , -, . , , , . — . . , , , .

. , , , . , .

— . Twitter, , Telegram- . , . .

, , , , . , , , , , — .

5-10 . 2 , , .

, . — . , , .

GitHub —

, open source , 10–15 open source, (NASA ).

, .

open source . , — . : , pull requests , , GitHub, .

open source- . open source-, , , .

, , . — open source, ? , , , — .

, — , . , , . open source- . open source community: , -, , pulll request, .

open source-, : , , — - . 2 300 followers GitHub — , 6 .

— , . -, , . , .

, . , . , , , , . — , 25 , , community .

, . , . , full-time, . , .

— , . , 20 Twitter 2 GitHub, . open source-, , . .

— .

2000 , 2019. 2029 . , , followers, , .

, . DevOpsConf Russia , , QualityConf . Saint TeamLead Conf .

— . .