VOLVER
Hace ya un tiempo que pusimos un botón de pausa en nuestra revisión semanal de artículos tecnológicos de gran valor, probablemente debido a la sobrecarga de trabajo de los proyectos. Sin embargo, aquí vamos de nuevo en una misión para encontrar, revisar y entregar a usted el contenido semanal de gran valor para los líderes de ingeniería y desarrolladores de software.
Compartir conocimientos es crucial para desarrollar habilidades tecnológicas y nos importa.
Para ayudar a los responsables de ingeniería a encontrar las soluciones que necesitan para tomar decisiones basadas en pruebas en sus proyectos de software.
Creemos firmemente en el poder de la autoeducación, esforzándonos siempre por aprender cosas nuevas y fortalecernos, 1% a la vez.
Hay montones de contenidos tecnológicos en la red que merecen más atención, y vamos a darles el crédito que se merecen.
Construir un hoja de ruta para esta serie, he realizado una encuesta en LinkedIn para preguntar CTOs y directores de ingeniería sobre sus principales retos en un 2020 ya bastante difícil y más allá.
Esto es lo que dijeron:
"Su sistema tiene un cuello de botella. En algún sitio". - cuando luchamos por mejorar el rendimiento de la aplicación, nos olvidamos de las limitaciones clave del sistema, tal vez no sean los elementos más populares de la aplicación, pero pueden tener un efecto negativo en el resto y el escalado puede no ayudarnos en este punto.
"La monitorización es fundamental para los sistemas escalables" - no podemos estar ciegos en nuestro negocio y es mejor para nosotros conocer el problema antes de que nos lo comuniquen los usuarios o nuestro CEO. La monitorización es la clave de la fiabilidad.
"La capa de datos es la más difícil de escalar" - La base de datos es el corazón de nuestra aplicación y, como todo corazón, es difícil cortarlo sin afectar a nuestro sistema venoso por lo que suele ser nuestro cuello de botella. Por otro lado, cuanto más tiempo estamos en el mercadoCuantos más datos procesemos, más difícil será mantener el rendimiento esperado.
En el citado artículo, el autor destaca algunos aspectos específicos de la arquitectura de aplicaciones de alto rendimiento. A lo largo de los años, hemos aprendido a utilizar soluciones como AWS o Azure, pero incluso los mejores nube no nos protege de nosotros mismos. Cuando creamos una aplicación, no nos centramos en resolver los problemas que no existen, previéndolos de antemano. Por lo tanto, nos encontramos con muchos problemas más tarde, cuando nuestra aplicación crece. El autor del artículo nos da muchos consejos valiosos sobre dónde buscar la optimización, cuál es el mayor problema y cómo afecta a tu aplicación. Poniendo en juego mis muchos años de experiencia en el sector, estoy totalmente de acuerdo con Ian. También me gustaría añadir que los consejos proporcionados en el artículo se aplican a todas las aplicaciones que mantenemos. Poner en práctica estas directrices aportará beneficios proyecto a nivel de su fiabilidad y previsibilidad, que es una característica importante para el crecimiento empresarial.
- Las medidas de rendimiento más utilizadas no son estrictamente técnicas
- La velocidad de entrega del software es medible, pero los indicadores utilizados deben interpretarse adecuadamente para que la optimización obtenga el efecto deseado
- Lo más eficaz equipo es un equipo bien coordinado y conectado: los responsables de ingeniería deben comprender los problemas y motivaciones de los desarrolladores y viceversa para lograr efectos saludables y sinérgicos.
Juan Pablo Buritica ha planteado un tema que todavía parece de nicho. Las personas que gestionan proyectos de TI suelen adoptar algunas medidas de eficiencia (como el gráfico burndown básico de JIRA), pero siguen sin estar estrechamente correlacionadas con las entregas de código partes para optimizar el proceso de entrega de software basándose en ellos. Por lo general, la optimización se refiere a la distribución de tareas y la comunicación dentro del equipo, pero es raro hacer un seguimiento de los indicadores estrictamente técnicos que menciona el autor, por ejemplo, el "tiempo de fusión". En la era de los ganchos web de GitHub y los sistemas de gestión de tareas abiertos a la integración, este tipo de enfoque resulta relativamente fácil de aplicar: los datos están al alcance de la mano, sólo hay que alcanzarlos y procesarlos de la forma adecuada.
El autor señala, con razón, que las estadísticas que describe pueden volverse rápidamente en contra del equipo de desarrolloPero esto sólo ocurre cuando el personal directivo no comprende del todo las particularidades del trabajo del programador. Por lo tanto, es importante que el PM o PO tenga conocimientos técnicos y sea capaz de percibir lo que hay detrás de las tareas individuales en el sistema.
En la era de la pandemia, en la que un gran número de empleados han pasado a trabajo a distancia configuración, debemos prestar aún más atención a la seguridad de nuestros datos. Un buen ejemplo es la situación citada por Dan en la que los usuarios utilizan las mismas contraseñas o contraseñas muy similares en todas partes y no son conscientes del peligro que ello conlleva.
Si utilizas las mismas contraseñas en muchos sitios, puede ocurrir que uno de los sitios tenga "problemas de seguridad", que la base de datos se filtre a Internet o simplemente que alguien te vea teclear una contraseña que accidentalmente te abra todas las puertas. En mi opinión, todos los servicios en línea deberían informarte del peligro que supone introducir la misma contraseña durante el proceso de registro.
El Single Sing On (SSO) o el uso de gestores de contraseñas como One Identity o LastPass son muy útiles para mantener los estándares básicos de higiene y seguridad online, protegiendo a nuestros empleados y lugares de trabajo de vulnerabilidades y amenazas digitales.
¿Formas a tus empleados sobre la gestión consciente de contraseñas?
Gracias por leer hasta el final y permaneced atentos al próximo episodio, que llegará muy pronto.
Spanish 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Japanese 
Korean 
Dutch 
Estonian 
Greek