Investigación documental y de campo

Informe finalOptimización de aplicaciones en el desarrollo de software

Oscar Daniel Madrid Ramírez

Lunes 27 de Mayo, 2019

IndiceIntroducción.................................................................................................5

Objetivo....................................................................................................5

Objetivos específicos............................................................................5

Metodología.................................................................................................6

Aplicada....................................................................................................6

Explicativa................................................................................................6

Campo......................................................................................................6

Inductivo..................................................................................................6

Planteamiento..........................................................................................6

Delimitación.............................................................................................7

Plan de Trabajo........................................................................................7

Resultados....................................................................................................7

Best Practices para el desarrollo de Software..........................................8

1. YAGNI: " No lo vas a necesitar ".......................................................8

2. Las pruebas no necesitan pruebas...................................................8

3. La tercera vez que escriba el mismo código es el momento adecuado para extraerlo en un ayudante de propósito general (y escribir pruebas para él)......................................................................9

4. Cuando se trata de diseño de API (cara externa y API de objeto): las cosas simples deben ser simples;.........................................................9

5. Falla rápido.......................................................................................9

6. Pruebas unitarias prueban la unidad de comportamiento, no la unidad de implementación..................................................................9

7. Para las pruebas unitarias (incluidas las pruebas de infraestructura de prueba), se deben probar todas las rutas de código. 100% de cobertura es un buen lugar para comenzar.......................................10

8. El código es el enemigo: puede salir mal y necesita mantenimiento............................................................................................................10

9. Inevitablemente, los comentarios de código se convierten en mentiras con el tiempo......................................................................10

10. Escribe a la defensiva...................................................................11

11. La lógica es fácil de realizar una prueba unitaria si no tiene estado y no tiene efectos secundarios...........................................................11

12. Los globales son malos.................................................................11

13. Usar los tipos incorporados..........................................................11

14. La inyección de dependencia es un patrón de codificación útil para aclarar cuáles son sus dependencias y de dónde provienen... . .12

15. Cuanto más tienes que burlarte para probar tu código, peor es tu código.................................................................................................12

16. Las API externas son donde el "diseño por adelantado", y la consideración sobre futuros casos de uso, realmente importa.........12

17. Si una función o método pasa las 30 líneas de código, considere dividirlo..............................................................................................12

18. No trabaje en constructores de objetos, que son difíciles de probar y sorprendentes.....................................................................13

19. DRY (Don't Repeat Yourself) importa mucho menos en las pruebas que en el código de producción...........................................13

20. Refactoriza cada vez que veas la necesidad y tengas la oportunidad.......................................................................................13

21. Hacer el código correcto primero y rápido segundo....................13

22. Las pruebas unitarias más pequeñas y con un ámbito más restringido brindan información más valiosa cuando fallan: le dicen específicamente qué es lo que está mal............................................14

23. "No se ha inventado aquí" no es tan malo como la gente dice....14

24. La propiedad del código compartido es la meta;.........................14

25. ¡ Generadores de rock!................................................................15

26. ¡Seamos ingenieros!.....................................................................15

27. Las pruebas que fallan de manera intermitente..........................15

28. Particularmente en las pruebas, esperar un cambio específico en lugar de dormir durante un período de tiempo arbitrario.................15

29. Siempre ve tu prueba fallar al menos una vez.............................16

30. Y, finalmente, un punto para la administración: la función constante de características es una manera terrible de desarrollar software.............................................................................................16

Conclusiones y recomendaciones..............................................................17

Referencias................................................................................................18

Anexos.......................................................................................................19

Aplicación de Entrevistas.......................................................................19

Entrevista 1........................................................................................19

Entrevista 2........................................................................................21

Aplicación de Encuesta..........................................................................23

Introducción

El desarrollo de software, ha permitido la integración de elementos visuales, conexiones online en todo momento e incluso reforzar el look & feel de un sitio, sistema o aplicación. En buena medida, se ha buscado desarrollar una aplicación llamativa, visualmente atractiva, pero muchos desarrolladores han dejado de lado la optimización visual, o de procesos, que permitan eficientar el desempeño de nuestra aplicación, sobre-saturandola de recursos que hacen prácticamente imposible su uso.

ObjetivoEs necesario impulsar el desarrollo de aplicación o sistemas, basándose en los principios (o best practices), que permitirán tener una aplicación más estable, sin redundancias, que para el usuario final sea la aplicación deseada, y que para el área de desarrollo de software sea una aplicación de fácil mantenimiento y extensibilidad.

Objetivos específicos Investigar los diferentes aspectos a considerar para desarrollar una

aplicación de forma optimizada. Conocer parte de las mejores prácticas, que nos permitan que el

desarrollo de nuestra aplicación, cumpla con los objetivos requeridos, y pueda, además, ser una aplicación fluida.

Dar a conocer el resultado de la investigación, con la intensión de propagar el conocimiento.

Orientar a los desarrolladores principiantes, para que desde un inicio puedan aplicar dichas técnicas.

La optimización de software busca adaptar los programas informáticos para que realicen sus tareas de la forma más eficiente posible. Virtualmente, existen infinitas maneras de desarrollar una misma aplicación, y uno de los factores más influyentes a la hora de crear el diseño es la arquitectura de hardware con la cual se desea trabajar. En pocas palabras, conseguir el mejor rendimiento en una plataforma enfocada en el tipo y la cantidad memoria es muy diferente a hacerlo en una cuyo fuerte es la velocidad de los procesadores.

Metodología

Se realizaron diversos métodos de trabajo para poder realizar la investigación, que fueron:

AplicadaCon la intensión de mejorar la formación de desarrolladores que apliquen las mejores prácticas para el desarrollo de software, debemos aplicar dichas prácticas.

ExplicativaEs importante identificar cuáles fueron las causas que nos acercaron a la situación actual, por ello se formularon preguntas, al inicio abiertas, y al final, muy cerradas, para conocer los factores que influyeron.

CampoEs necesario el dialogo directo con los desarrolladores, conocer su punto de vista, identificar las necesidades de ellos, y además, identificar los puntos de mejora.

InductivoComo consecuencia de las enrevistas y encuestas, se pudo llegar a determinadas consecuencias, que si bien no es una regla general o aplicable para todos, nos permite un acercamiento sobre los puntos de mejora que debemos tener en nuestros equipos de trabajo.

PlanteamientoLa optimización de software busca adaptar los programas informáticos para que realicen sus tareas de la forma más eficiente posible. Virtualmente, existen infinitas maneras de desarrollar una misma aplicación, y uno de los factores más influyentes a la hora de crear el diseño es la arquitectura de hardware con la cual se desea trabajar. En pocas palabras, conseguir el mejor rendimiento en una plataforma enfocada en el tipo y la cantidad memoria es muy diferente a hacerlo en una cuyo fuerte es la velocidad de los procesadores.

DelimitaciónSin enfocarnos a un lenguaje en específico, plataforma, interfaz y tampoco SO, buscaremos ahondar en las técnicas que pueden ser aplicables en cualquiera de las anteriores. Se trata de crear conciencia en la investigación de procesos, no tanto a nivel plataforma.

Plan de TrabajoActividad DuraciónDelimitación del tema y plan de investigación.

Del 3 al 7 de mayo del 2019.

Recopilación de información.Análisis y abstracción de información.

Del 8 al 12 de mayo del 2019.

Bitácora de información.Planeación y aplicación de entrevista.

Del 13 al 17 de mayo del 2019.

ResultadosHe trabajado en el área de Desarrollo de Software desde hace más de 10 años, por supuesto al inicio, al ser un novato en el área, procuré mantener siempre la mente abierta, conocer, identificar buenas y malas prácticas, con la intensión de ser un buen desarrollador de software.

Conforme ha pasado el tiempo y junto con ello llegó la experiencia profesional, llegó el momento en que tuve personal a cargo, y como en cualquier otra área de una empresa, siempre habrá personas destacadas, no solo por sus conocimientos técnicos, sino que cada quien con su propia metología (aprendida, ya sea en la escuela, en algún otro trabajo, o incluso sin haberla aprendido nunca), podía destacar, tanto positiva como negativamente.

Como parte de la aplicación de diversos métodos para conocer a la gente (desarrolladores de software) con los que actualmente trabajo, la interacción con ellos surgida a raíz de la presente investigación, me ha permitido identificar diversos puntos de mejora, tanto para ellos, como para mí.

Best Practices para el desarrollo de Software

Estas reglas de ingeniería de software y las mejores prácticas de prueba pueden ayudarlo a ahorrar tiempo y dolores de cabeza.

En general, los programadores somos un grupo de opiniones, y las opiniones fuertes a menudo son un signo de gran pasión. Con esto en mente, no dude en estar en desacuerdo con estos puntos, por lo que sin duda, siempre habrá mucha información que pueda ser complementada.

1. YAGNI: " No lo vas a necesitar ".

No escriba el código que cree que podría necesitar en el futuro, pero aún no lo necesita. Esta es la codificación para futuros casos de uso imaginarios , e inevitablemente el código se convertirá en código muerto o se deberá volver a escribir porque el futuro caso de uso siempre funciona de manera ligeramente diferente a como lo imaginó.

Si coloca el código en un caso de uso futuro, lo cuestionaré en una revisión del código. (Puede, y debe, diseñar API, por ejemplo, para permitir futuros casos de uso, pero ese es un problema diferente).

Lo mismo es cierto para el código de comentarios; si un bloque de código comentado entra en una versión, no debería existir. Si es un código que se puede restaurar, cree un ticket y haga referencia al hash de confirmación para eliminar el código. YAGNI es un elemento central de la programación ágil . La mejor referencia para esto es Explicación de programación extrema , por Kent Beck.

2. Las pruebas no necesitan pruebas. Infraestructura, marcos y bibliotecas para pruebas de pruebas de necesidades. No pruebe el navegador o las bibliotecas externas a menos que realmente lo necesite. Prueba el código que escribes, no el código de otras personas.

3. La tercera vez que escriba el mismo código es el momento adecuado para extraerlo en un ayudante de propósito general (y escribir pruebas para él). Las funciones de ayuda dentro de una prueba no necesitan pruebas; cuando los rompes y los vuelves a usar, necesitan pruebas. Por tercera vez que has escrito un código similar, tiendes a tener una idea clara de qué forma es el problema de propósito general que estás resolviendo.

4. Cuando se trata de diseño de API (cara externa y API de objeto): las cosas simples deben ser simples; Las cosas complejas deberían ser posibles . Diseñe para el caso simple primero, preferiblemente con configuración cero o parametrización, si es posible. Agregue opciones o métodos de API adicionales para casos de uso más complejos y flexibles (según sean necesarios).

5. Falla rápido. Verifique la entrada y falle la entrada sin sentido o el estado no válido lo antes posible, preferiblemente con una excepción o respuesta de error que aclare el problema exacto a su interlocutor. Sin embargo, permita casos de uso "innovadores" de su código (es decir, no realice la comprobación de tipos para la validación de entrada a menos que realmente lo necesite).

6. Pruebas unitarias prueban la unidad de comportamiento, no la unidad de implementación. El objetivo, aunque no siempre es posible, es cambiar la implementación, sin cambiar el comportamiento o tener que cambiar cualquiera de sus pruebas. Por lo tanto, cuando sea posible, trate sus objetos de prueba como cajas negras, probando a través de la API pública sin llamar a métodos privados o jugando con el estado.

Para algunos escenarios complejos, como probar el comportamiento en un estado complejo específico para encontrar un error oscuro, eso puede

no ser posible. Escribir las pruebas primero realmente ayuda con esto, ya que te obliga a pensar sobre el comportamiento de tu código y cómo lo vas a probar antes de escribirlo. Las pruebas primero alientan unidades de código más pequeñas y más modulares, lo que generalmente significa un mejor código. Una buena referencia para comenzar con el enfoque de "probar primero" es Test Driven Development by Example , por Kent, de Kent.

7. Para las pruebas unitarias (incluidas las pruebas de infraestructura de prueba), se deben probar todas las rutas de código. 100% de cobertura es un buen lugar para comenzar.

No puede cubrir todas las posibles permutaciones / combinaciones de estado (explosión combinatoria), por lo que eso requiere consideración. Solo si hay una buena razón, las rutas de código deben dejarse sin probar. La falta de tiempo no es una buena razón y termina costando más tiempo. Las posibles buenas razones incluyen: genuinamente no comprobable (de cualquier manera significativa), imposible de alcanzar en la práctica o cubierto en otra parte en una prueba. Código sin pruebas es una responsabilidad. Medir la cobertura y rechazar los RP que reducen el porcentaje de cobertura es una forma de garantizar un progreso gradual en la dirección correcta.

8. El código es el enemigo: puede salir mal y necesita mantenimiento. Escribe menos código. Eliminar código. No escriba el código que no necesita.

9. Inevitablemente, los comentarios de código se convierten en mentiras con el tiempo. En la práctica, pocas personas actualizan los comentarios cuando las cosas cambian. Esfuércese por hacer que su código sea legible y auto-documentado a través de buenas prácticas de denominación y un estilo de programación conocido.

Código que no puede hacerse obvia-trabajo en torno a un error desconocido o condición poco probable, o una Optimization necesaria no es necesario comentar. Comente la intención del código y por qué está haciendo algo en lugar de lo que está haciendo. (Este punto en particular acerca de que los comentarios son mentiras es controversial, por cierto. Sigo creyendo que es correcto, y Kernighan y Pike, autores de The Practice of Programming , están de acuerdo conmigo).

10. Escribe a la defensiva. Siempre piense en lo que puede salir mal, lo que sucederá con una entrada no válida y lo que podría fallar, lo que le ayudará a detectar muchos errores antes de que ocurran.

11. La lógica es fácil de realizar una prueba unitaria si no tiene estado y no tiene efectos secundarios. Divida la lógica en funciones separadas, en lugar de mezclar la lógica en un código con estado y lleno de efectos secundarios. La separación del código con estado y el código con efectos secundarios en funciones más pequeñas hace que sean más fáciles de simular y realizar pruebas de unidad sin efectos secundarios. (Menos gastos generales para las pruebas significa pruebas más rápidas.) Los efectos secundarios hacen que necesite pruebas, pero las pruebas una vez y burlándose de ellos hacia fuera en todas partes es generalmente un buen patrón.

12. Los globales son malos. Las funciones son mejores que los tipos. Es probable que los objetos sean mejores que las estructuras de datos complejas.

13. Usar los tipos incorporadosSerá más rápido que escribir tus propios tipos (a menos que estés escribiendo en C). Si el rendimiento es una consideración, intente

averiguar cómo usar los tipos incorporados estándar en lugar de objetos personalizados.

14. La inyección de dependencia es un patrón de codificación útil para aclarar cuáles son sus dependencias y de dónde provienen. (Los objetos, los métodos, etc., reciben sus dependencias como parámetros en lugar de crear una instancia de los objetos nuevos). Esto hace que las firmas de API sean más complejas, por lo que es una compensación. Terminar con un método que necesita 10 parámetros para todas sus dependencias es una buena señal de que su código está haciendo demasiado, de todos modos. El artículo definitivo sobre inyección de dependencia es " Inversión de contenedores de control y el patrón de inyección de dependencia ", de Martin Fowler.

15. Cuanto más tienes que burlarte para probar tu código, peor es tu código. Cuanto más código tenga para crear una instancia y ponerlo en práctica para poder probar un comportamiento específico, peor será su código. El objetivo es pequeñas unidades comprobables, junto con pruebas de integración y funcionales de nivel superior para probar que las unidades cooperan correctamente.

16. Las API externas son donde el "diseño por adelantado", y la consideración sobre futuros casos de uso, realmente importa. Cambiar las API es un dolor para nosotros y para nuestros usuarios, y crear una incompatibilidad hacia atrás es horrible (aunque a veces es imposible evitarlo). Diseñe las API externas con cuidado, manteniendo el principio de "las cosas simples deben ser simples".

17. Si una función o método pasa las 30 líneas de código, considere dividirlo. Un buen tamaño máximo de

módulo es de unas 500 líneas. Los archivos de prueba tienden a ser más largos que esto.

18. No trabaje en constructores de objetos, que son difíciles de probar y sorprendentes. No ponga el código en __init__.py (excepto las importaciones para espacios de nombres). __init__.py no es donde los programadores generalmente esperan encontrar el código, por lo que es "sorprendente".

19. DRY (Don't Repeat Yourself) importa mucho menos en las pruebas que en el código de producción. La legibilidad de un archivo de prueba individual es más importante que la capacidad de mantenimiento (romper fragmentos reutilizables). Esto se debe a que las pruebas se ejecutan y leen individualmente en lugar de formar parte de un sistema más grande. Obviamente, la repetición excesiva significa que los componentes reutilizables pueden crearse por conveniencia, pero es una preocupación mucho menor que para la producción.

20. Refactoriza cada vez que veas la necesidad y tengas la oportunidad. La programación tiene que ver con abstracciones, y cuanto más cerca esté su mapa de abstracciones del dominio del problema, más fácil será comprender y mantener su código. A medida que los sistemas crecen orgánicamente, necesitan cambiar la estructura para su caso de uso en expansión. Los sistemas superan sus abstracciones y estructura, y no cambiarlos se convierte en una deuda técnica que es más dolorosa (y más lenta y con más errores) para solucionar. Incluya el costo de liquidar la deuda técnica (refactorización) dentro de las estimaciones para el trabajo de características. Cuanto más tiempo deje la deuda, mayor será el interés que acumula. Un gran libro sobre refactorización y pruebas está Trabajando eficazmente con Legacy Code , por Michael Feathers.

21. Hacer el código correcto primero y rápido segundo. Cuando trabaje en problemas de rendimiento, siempre haga un perfil antes de hacer arreglos. Por lo general, el cuello de botella no es exactamente donde pensabas que estaba. Escribir un código oscuro porque es más rápido solo vale la pena si has perfilado y probado que realmente vale la pena. Escribir una prueba que ejecute el código que está perfilando con la sincronización hace que sea más fácil saber cuándo ha terminado, y se puede dejar en el conjunto de pruebas para evitar regresiones de rendimiento. (Con la nota habitual de que agregar código de tiempo siempre cambia las características de rendimiento del código, lo que hace que el rendimiento sea una de las tareas más frustrantes).

22. Las pruebas unitarias más pequeñas y con un ámbito más restringido brindan información más valiosa cuando fallan: le dicen específicamente qué es lo que está mal. Una prueba que levanta la mitad del sistema para probar el comportamiento requiere más investigación para determinar qué está mal. En general, una prueba que demora más de 0.1 segundos en ejecutarse no es una prueba unitaria. No hay tal cosa como una prueba de unidad lenta. Con el comportamiento de prueba de las pruebas unitarias de ámbito estricto, sus pruebas actúan como una especificación de facto para su código. Idealmente, si alguien quiere entender su código, debería poder recurrir a la serie de pruebas como "documentación" para el comportamiento. Una gran presentación sobre las prácticas de prueba de unidad es Prueba rápida, Prueba lenta , por Gary Bernhardt (https://youtu.be/RAxiiRPHS9k)

23. "No se ha inventado aquí" no es tan malo como la gente dice. Si escribimos el código, entonces sabemos lo que hace, sabemos cómo mantenerlo, y somos libres de ampliarlo y modificarlo según lo creamos. Esto sigue el principio de YAGNI: tenemos un código específico para los casos de uso que necesitamos en lugar del código de propósito general que tiene complejidad para cosas que no necesitamos. Por otro lado, el

código es el enemigo, y poseer más código del necesario es malo. Tenga en cuenta la compensación al introducir una nueva dependencia.

24. La propiedad del código compartido es la meta; El conocimiento aislado es malo. Como mínimo, esto significa discutir o documentar decisiones de diseño y decisiones de implementación importantes. La revisión del código es el peor momento para comenzar a discutir las decisiones de diseño, ya que es difícil superar la inercia para hacer cambios radicales después de que se haya escrito el código. (Por supuesto, todavía es mejor señalar y cambiar los errores de diseño en el momento de la revisión que nunca).

25. ¡ Generadores de rock! En general, son más cortos y fáciles de entender que los objetos con estado para iteración o ejecución repetida. Una buena introducción a los generadores es " Trucos de generadores para programadores de sistemas ", de David Beazley.

26. ¡Seamos ingenieros! Pensemos en diseñar y construir sistemas robustos y bien implementados, en lugar de crecer monstruos orgánicos. Sin embargo, la programación es un acto de equilibrio. No siempre estamos construyendo un cohete. La ingeniería excesiva (arquitectura de cebolla) es tan difícil de trabajar como el código de bajo diseño. Vale la pena leer casi cualquier cosa de Robert Martin, y Arquitectura limpia: una guía para la estructura y diseño de software del artesano es un buen recurso sobre este tema. Design Patterns es un libro de programación clásico que todo ingeniero debería leer.

27. Las pruebas que fallan de manera intermitente erosionan el valor de su conjunto de pruebas, hasta el punto en que eventualmente todos ignoran los resultados de las pruebas porque siempre hay algo que falla. Reparar o eliminar las pruebas que fallan de forma intermitente es doloroso, pero vale la pena el esfuerzo.

28. Particularmente en las pruebas, esperar un cambio específico en lugar de dormir durante un período de tiempo arbitrario. Los sueños de vudú son difíciles de entender y ralentizan el conjunto de pruebas.

29. Siempre ve tu prueba fallar al menos una vez. Coloque un error deliberado y asegúrese de que falla, o ejecute la prueba antes de que se complete el comportamiento bajo prueba. De lo contrario no sabes que realmente estás probando nada. Accidentalmente, escribir pruebas que realmente no prueban nada o que nunca pueden fallar es fácil.

30. Y, finalmente, un punto para la administración: la función constante de características es una manera terrible de desarrollar software. No dejar que los desarrolladores se sientan orgullosos de su trabajo garantiza que no obtendrá lo mejor de ellos. No abordar la deuda técnica ralentiza el desarrollo y da como resultado un producto peor y más defectuoso.

Conclusiones y recomendaciones

Sin lugar a dudas, es de vital importancia continuar con la preparación una vez que se termina una carrera profesional, sea la que sea. En el caso de las áreas relacionadas a la tecnología, es de vital importancia la actualización, tanto en la mejora de procesos, actualizaciones de versiones, innovaciones, etc.

Como parte del trabajo de los líderes técnicos, sin duda se debe agendar que los conocimientos ó técnicas de programación eficientes, deben ser heredadas.

Se debe estar siempre abierto a la crítica, y dependerá de cada uno la forma en que se enfoca, no es un tema de conocimiento técnico, sino de actitud y propuesta por la mejora.

ReferenciasMichael Foord https://opensource.com/article/17/5/30-best-practices-

software-development-and-testing. (24 May 2017). Obtenido de https://www.conocimientosweb.net/portal/article2958.html: https://www.conocimientosweb.net/portal/article2958.html

https://www.conocimientosweb.net/portal/article2958.html. (13 de 12 de 2014). Obtenido de https://www.conocimientosweb.net/portal/article2958.html: https://www.conocimientosweb.net/portal/article2958.html

https://www.snyxius.com/optimizing-your-software-development-lifecycle-for-the-best-possible-results/. (s.f.). Obtenido de https://www.snyxius.com/optimizing-your-software-development-lifecycle-for-the-best-possible-results/: https://www.snyxius.com/optimizing-your-software-development-lifecycle-for-the-best-possible-results/

La Rosa, A. (s.f.). https://blog.pandorafms.org/es/optimizacion-de-rendimiento-web. Obtenido de https://blog.pandorafms.org/es/optimizacion-de-rendimiento-web: https://blog.pandorafms.org/es/optimizacion-de-rendimiento-web

Pérez Porto, J. (s.f.). https://definicion.de/optimizacion/. Obtenido de https://definicion.de/optimizacion/: https://definicion.de/optimizacion/

Rongala, A. (s.f.). https://www.invensis.net/blog/it/20-best-practices-for-successful-software-development-projects/. Obtenido de https://www.invensis.net/blog/it/20-best-practices-for-successful-software-development-projects/https://www.invensis.net/blog/it/20-best-practices-for-successful-software-development-projects/: https://www.invensis.net/blog/it/20-best-practices-for-successful-software-development-projects/https://www.invensis.net/blog/it/20-best-practices-for-successful-software-development-projects/

Savvycom. (25 de 05 de 2017). https://savvycomsoftware.com/10-signs-your-business-needs-an-optimization-software/. Obtenido de https://savvycomsoftware.com/10-signs-your-business-needs-an-optimization-software/: https://savvycomsoftware.com/10-signs-your-business-needs-an-optimization-software/

Trivedi, A. N. (s.f.). https://www.techjini.com/blog/lean-software-development/. Obtenido de https://www.techjini.com/blog/lean-software-development/: https://www.techjini.com/blog/lean-software-development/

Anexos

Aplicación de EntrevistasTuve la oportunidad de entrevistar el mismo día, a mis dos representantes del equipo de trabajo, lo hicimos en una sesión aquí en el trabajo, con el permiso de mi gerente.

Mis preguntas básicas fueron las siguientes:

– Háblame un poco de como decidiste dedicarte al desarrollo de software

– ¿Cuánto tiempo llevas desarrollando de manera profesional, y cuál fue tu primer trabajo.

– ¿Qué opinas acerca de las best practices para el desarrollo de software? ¿Las usas?

– Hoy en día, he notado que en muchas empresas, siempre hay momentos en los que hay que optimizar o eficientar algun proceso, ya sea por que es lento, o incluso por que afecta el rendimiento de otros procesos. ¿Que recomendaciones harías tú, para evitar que eso sea una constante?

Entrevista 1En la primer parte de la entrevista, se hace a un desarrollador Junior (con un nivel de expertise menor, pero con todas las capacidades para ya desarrollar en una empresa)

– Háblame un poco de como decidiste dedicarte al desarrollo de software

Inicialmente fué por un tío, él se dedicaba a ésto y ganaba muy bien, sé que fuimos varios los primos que nos llamó mucho la atención, varios nos metimos a la carrera, pero todos ellos descartaron, yo fuí el único que terminó, y estando dentro, realmente me gustó, y por eso seguí

– ¿Cuánto tiempo llevas desarrollando de manera profesional, y cuál fue tu primer trabajo.

Este es mi segundo trabajo, en total llevo dos años trabajando, aunque empecé desarrollando desde la Uni, siempre buscaba la manera de destacar con mis programas, me gustó más el desarrollo que las redes o el hardware, sin duda lo mío es esto.

– ¿Qué opinas acerca de las best practices para el desarrollo de software? ¿Las usas?

He leído de ello, son como de rigor, y tal vez uno procura seguirlas, pero hay cosas que siento que son obsoletas, o que incluso ya no aplican a lo de hoy, por decir, la verdad es que el tema de documentar los procesos, es una verdadera lata, sé que son útiles hasta cierto punto, pero creo que es mucha pérdida de tiempo.

– Hoy en día, he notado que en muchas empresas, siempre hay momentos en los que hay que optimizar o eficientar algun proceso, ya sea por que es lento, o incluso por que afecta el rendimiento de otros procesos. ¿Que recomendaciones harías tú, para evitar que eso sea una constante?

Sin duda la migración, hay lenguajes ya muy viejos en algunas empresas, en donde estaba había incluso programas todavía en Cobol, estoy seguro que si eso lo pasaramos a lo de hoy, las cosas serían muy diferentes. Hay que mejorar muchas cosas, ir a la vanguardia, sé que hay riesgos en las migraciones, pero no puedes seguir dándole soporte a lenguajes de antaño, para éso hay frameworks ya muy especializados, que sin duda podrían optimizar recursos. Además, también se tiene que invertir en hardware, en ocasiones nos piden que hagamos programas bonitos, pero estando en un servidor viejo, pues simplemente no corre.

Entrevista 2En la segunda parte de la entrevista, lo hice con un Project Manager que al menos tiene 25 años de edad más que yo, que lejos de estar en un puesto directivo, sigue trabajando muy de cerca con los desarrolladores. Me interesó mucho entrevistarlo a él, por que está en medio, convive diario, tanto con los directivos, como con los desarrolladores.

– Háblame un poco de como decidiste dedicarte al desarrollo de software

Realmente no existía como tal, la carrera de desarrollo o algo parecido, yo estudié Ingeniería en Electrónica, y al entrar a trabajar en el IMSS, ahí fué donde aprendí, me gustó, y no me fue difícil, recuerdo que aprendí de muchas personas, fueron varios los que me enseñaron, y hay algo que tenían todos ellos en común y yo les admiraba; ellos eran muy muy ordenados, muy cuidadosos, muy metódicos, en aquel tiempo no era tan fácil programar, bueno, es que utilizabamos cobol, en mainframe, no era nada de lo que hoy era, creo que antes era más dificil, hoy en día ya se les facilita demasiado a los jovenes, con el internet y todo eso, realmente es ya muy fácil para ellos.

– ¿Cuánto tiempo llevas desarrollando de manera profesional, y cuál fue tu primer trabajo.

Pues trabajando en sistemas, tal vez 30 años, o más, yo cuando empecé a trabajar no estaba en sistemas, sino que como que me absorbieron para allá, sino realmente llevaría más tiempo.

– ¿Qué opinas acerca de las best practices para el desarrollo de software? ¿Las usas?

Creo que por algo se han ido creando esas reglas, no se crean a lo tonto o nada más por fastidiar, hay muchas cosas que deben seguirse, no brincartelas nada más por que te parezcan aburridas.

– Hoy en día, he notado que en muchas empresas, siempre hay momentos en los que hay que optimizar o eficientar algun proceso, ya

sea por que es lento, o incluso por que afecta el rendimiento de otros procesos. ¿Que recomendaciones harías tú, para evitar que eso sea una constante?

Un sistema siempre, siempre requerirá de mantenimiento, sino, simplemente morirá; todas las empresas requieren de mejoras, por eso los sistemas siempre requerirán estar en constante optimización, eso no lo podremos nunca evitar. Pero hay algo que incluso creo que hoy es peor que hace 10 años, los muchachos son en su mayoría desordenados, hacen las cosas al aventon, sienten que no les puedes decir nada por que luego luego se ofenden y se van de trabajo, por eso es que ahora he notado que tardo mucho más en reclutar a la gente, hoy en día actúan como si nos etuvieran haciendo un favor, y su actitud es complicada. Por eso es que, cuando llega alguno bueno, con buena actitud, tienes que moldearlo, enseñarle a analizar, a que visualice todo el cambio, en donde le puede pegar, que no se trata nada más de tirar lineas de código, ésta actividad es más que eso, no puedes hacer las cosas al aventón, y ese es parte de nuestro trabajo, y si no lo hacemos, imagina como serán los sistemas en 5 o 10 años?

Aplicación de Encuesta1. Usted, como usuario de aplicaciones. ¿Qué prefiere?

2. Usted, como usuario, le disgusta que una aplicación, estéticamente no sea estilizada, pero que funcionalmente sea idónea y cumpla su cometido?

3. Usted, como usuario, ¿confía más en una aplicación web, que en una app que pueda instalar en su cel?

4. Usted, como usuario, ¿Ha desinstalado una app por ser estéticamente desagradable?

5. Usted, como usuario, ¿Ha desinstalado una app por ser lenta (funcionalmente hablando)?

6. Usted como desarrollador de software, utiliza las “best practices” para el desarrollo de software?

7. Usted como desarrollador de software, ¿Con tal de entregar en tiempos, es capaz de sacrificar un buen análisis o un buen desarrollo?

8. Usted como desarrollador de software, ¿ejecuta los test de performance antes de hacer alguna liberación productiva?

9. Usted como desarrollador de software, podría enlistar en este momento, 5 best practices para el desarrollo de software?

10. Usted como desarrollador, ha tomado cursos que pudiera mejorar el desarrollo de software, en cuánto la optimización de código?