Click here
martes, 2 de agosto de 2016
Sending Push Notifications from a Drupal site
With this article I want to share how to integrate the management of push notifications on your Drupal site using the Apple and Android notification services.
Click here
Click here
Modern Web Development
With this article I want to share a compilation of some well known top technologies that can be used today to develop a modern web application. The web development world has changed a lot because of its adaptation to the mobile and social media context, and a lot of new technologies, including servers, databases, development frameworks, and libraries have emerged to help us to resolve several new problems and challenges.
Mi experiencia como Scrum Master en una entidad financiera
Introducción
Con este post pretendo describir mi gratificante experiencia como Scrum Master de uno de los equipos de IT de una entidad financiera. Durante 6 meses he desarrollado esta tarea dando soporte y colaborando con un equipo de 5 personas, 4 desarrolladores y un ingeniero QA, en una conocida e internacional entidad financiera.
El equipo pertenece el área de Sostenibilidad de Clientes. En este área se tratan de canalizar las iniciativas que surgen como respuesta a las peticiones de mejora, sugerencias, quejas , etc, provenientes directamente de los clientes de la entidad financiera, y que son recibidas a través de los diferentes canales de comunicación con los clientes, como oficinas, sucursales, redes sociales, email, reclamaciones, etc, siempre orientadas a evolutivos ( correctivos, perfectivos, adaptativos, preventivos, etc ) en la zona transaccional (privada) de su principal canal online.
Esta entidad tiene experiencia previa aplicando Scrum en los proyectos IT desde hace casi dos años, por lo que ya existe un marco de trabajo en torno a la metodología que suelen utilizar la mayoría de los equipos del área de IT.
Las principales características del proceso son las siguientes:
Roles
Sponsors : En este caso son dos personas pertenecientes al área de Gestión del Cambio, y son las que determinan qué iniciativas deben estar en el Product backlog y la prioridad de las mismas. Los sponsor son los que reciben las iniciativas desde las diferentes unidades de negocio , terminan de refinarlas y las detallan mínimamente para que estén preparadas para entrar en el Product Backlog.
Product Owner : Miembro del área de Sostenibilidad de Clientes de la entidad, es una persona con un perfil muy orientado a negocio. Su trabajo principalmente consiste en definir y priorizar las diferentes historias de usuario que forman parte del product backlog del equipo ,así como determinar qué historias son susceptibles de ser abordadas en cada Sprint.
Scrum Master: En esta entidad el S.M , además de ser un facilitador cuya misión principal es que se cumplan las ceremonias determinadas por la metodología y tratar de minimizar las distracciones y bloqueos para que el equipo pueda cumplir con lo planificado en cada sprint, y así aportar valor sprint tras sprint, tiene una componente técnica bastante importante, convirtiéndose en el líder técnico del equipo, y la referencia para el análisis técnico preliminar de las historias de usuario.
Equipo de Desarrollo: Formado por 4 desarrolladores full stack , dos senior y dos junior. El perfil técnico de estos desarrolladores incluye, en la parte Front, conocimientos en Responsive Design, Stylus, Backbone, Marionette, Dust JS, Gulp , Karma, Jasmine , y en la parte Back con Java Spring MVC, APIs Rest y SOAP , PL SQL y Oracle. Las herramientas que se utilizan en el dia a dia son WebSTorm (o Sublime Text, según las preferencias de cada uno) , Jira Agile, y como no, la consola de usuario. Los desarrolladores utilizan equipos Windows (es el único homologado para desarrollo en la entidad).
Ingeniero de QA (Tester) : Interesante perfil perteneciente al equipo cuya principal misión consiste en realizar pruebas uat en el entorno de Preproducción de todo lo que ha sido desarrollado, aprobado en demo e integrado en el sprint anterior, y a partir de esas pruebas dar el ok o en caso contrario , abrir defectos asociados a las historias de usuario que ha probado. Por decirlo de otra forma, el tester siempre va un sprint por detrás, probando en el sprint actual la funcionalidad que se desarrolló en el anterior. Las pruebas las realiza en todo tipo de navegadores (I.Explorer, Firefox y Chome, Safari) y en diferentes tipos de dispositivos (Desktop, Tablet y Mobile) , de diferentes fabricantes , usando para la realización de los planes de pruebas y para aportar las evidencias de las mismas, la herramienta Quality Center.
Herramientas
Jira Agile
Herramienta que se utiliza como repositorio de información de todo lo relacionado con el marco de trabajo. Apoyándonos en los dashboards de Jira Agile, en esta herramienta :
- Se Dan de alta las iniciativas -épicas- , y las historias de usuario asociadas a cada iniciativa.
- Se gestionan tanto el product backlog como el sprint backlog.
- Se refleja la talla y los puntos de historia de cada historia planificada.
- Se asignan las historias - esto lo realiza el propio equipo de desarrollo, como S.M en este equipo nunca he tenido que asignar personalmente el trabajo, ellos mismos son autosuficientes y se reparten las historias planificadas o las realizan entre todos -.
- Se crean todas las subtareas necesarias por cada historia de usuario.
- Se avanza el estado tanto de las subtareas como de las historias (todo, in progress, integration, testing, done..).
- Se realiza el “log work”, o lo que es lo mismo, la imputación de las horas reales dedicadas a cada subtarea dentro de una historia de usuario.
En los sprints en los que se manejan un número grande de historias de usuario, solemos apoyarnos de un tablero físico que ubicamos en la zona donde están los miembros del equipo.
Quality Center
Herramienta que utiliza el Ingeniero de QA para, entre otras cosas, por cada historia de usuario planificada, describir el plan de pruebas asociado a la misma, adjuntar las evidencias de estas pruebas, así como para abrir defectos asociados a las historias - si procede - en la fase de pruebas uat.
Accurev
Herramienta SCM, parece ser que bastante utilizada por las entidades financieras, que permite trabajar de la misma forma que con git. Flujo de trabajo basado en streams distribuidos , con una relación de herencia entre ellos. Esto consiste en que si hay dos streams (o branches) que tienen una relación de herencia, cuando se sube un cambio al padre lo heredan los hijos automáticamente, evitando así que haya diferentes versiones del código en diferentes streams. Como ejemplo, si se sube un cambio como fix a pre al stream de Preproducción, lo heredarán automáticamente los stream que están por debajo, esto es integración, y todos los streams de cada uno de los desarrolladores, estando todo el mundo actualizado en todo momento.
Jenkins
Jenkins es un software que proporciona el marco necesario para poner en práctica la integración continua para el desarrollo de software. Es un sistema corriendo en un servidor que soporta herramientas de control de versiones como Accurev, CVS,Subversion, Git, Mercurial, Perforce y Clearcase y puede ejecutar proyectos ( jobs) basados en Apache Ant y Apache Maven, así como scripts de shell y programas batch desarrollados con lenguajes como Perl o Python. En el banco se suele utilizar para facilitar las labores de promoción de funcionalidad entre entornos, no teniendo actualmente definido un pipeline de integración contínua. La integración se realiza al final del sprint.
Proceso
Sprint de dos semanas de duración
Comenzando los lunes y terminando los viernes de la siguiente semana. Los Lunes y los viernes, días de la Planificación y del Sprint Review (Demo) , no cuentan a la hora de determinar la capacidad del equipo para abordar historias de usuario, ya que están reservados para las ceremonias, y para la integración del trabajo finalizado.
Ceremonias
Las ceremonias son las típicas de cualquier proceso Scrum, y son:
Refinamiento (Next Sprint Refinement)
Se celebra el miércoles anterior al principio del siguiente sprint, y en ella el Product Owner presenta un conjunto de historias de usuario que son susceptibles de ser abordadas en el siguiente sprint.
El PO presenta cada historia, la explica funcionalmente y resuelven todas las dudas que pueda tener el equipo para entender la funcionalidad descrita. En esta ceremonia, se determina si las historias cumplen la definición de READY, esto es, si están preparadas para ser abordadas por el equipo en el siguiente sprint.
En la mayoría de los casos, el Scrum Master se suele llevar trabajo fruto de esta ceremonia, ya que debe profundizar en la solución técnica de cada una de las historias para que cuando se haga la planificación, el equipo de desarrollo pueda estimar de forma más acertada en base a los requerimientos no funcionales que deriven de este análisis.
Sprint Planning
Se celebra el primer día del sprint, en este caso los Lunes, con una duración aproximada de 2-3 horas. El Product Owner acude a esta ceremonia con un conjunto de historias de usuario priorizadas y previamente refinadas. Los pasos de esta ceremonia, son los siguientes:
Determinar la capacidad de desarrollo que tendrá el equipo: teniendo en cuenta el número de desarrolladores que participarán en el sprint, si han solicitado algún día de vacaciones o si hay algún día festivo en el sprint., se calcula la capacidad en horas y en puntos de historia (velocidad) que se tendrá en el sprint.
Por otro lado, para el cálculo neto de esta capacidad, se tiene en cuenta el factor de foco, que es el porcentaje de tiempo real - descontando desperdicio - que se podrá dedicar realmente a que el equipo desarrolle y haga pruebas unitarias. El factor de foco actual es del 80%, ya que de la capacidad bruta se descuenta el tiempo dedicado a ceremonias, problemas con los entornos (más comunes de lo esperado la mayoría de las veces), etc.
Por último, para calcular la capacidad neta del equipo (o velocidad esperada) , se reserva algo de capacidad para bug fixing, teniendo en cuenta que es posible que haya que abordar algunos “fixes a pre” como consecuencia de las pruebas que realizará el tester en entorno uat. Normalmente se reservan 16 horas para esta labor, aunque en realidad depende de complejidad de la funcionalidad que probará el tester, pudiendo oscilar hasta las 40 horas de capacidad. Los fixes a pre suelen tener prioridad sobre cualquier desarrollo, ya que deben estar corregidos,probados y promocionados antes del último miércoles del sprint. Si un defecto que se detecta en PRE no se corrige, acaba promocionando a producción, ya que la release train no se detiene. Para que un defecto no sea abordado, debe ser asumido por el Product Owner.
A partir de este punto, y de forma iterativa se procede a:
Estimar la duración de cada historia de usuario: en esta tarea participan todos los miembros del equipo dando su estimación para la historia. Se tiene en cuenta la estimación de todos, obteniéndose el promedio, que finalmente, se fija como estimación de esfuerzo para esa tarea.
Estimar el esfuerzo para realizar las pruebas uat de esa tarea: El tester, que probará esta historia en el siguiente sprint, estima cuánto tiempo le llevará describir el plan de pruebas y ejecutar las pruebas. Esta tarea es importante, ya que la capacidad del tester para realizar pruebas es limitada, y hay veces que la estimación del tiempo de pruebas que hay que realizar para todas las historias planificadas en un sprint supera esta capacidad, debiendo el Product Owner plantear esta situación a los Product Owner de otros equipos, para tratar de cubrir este sobre esfuerzo apoyándose en el Tester de otro equipo que pueda ayudar.
A partir de esta estimación, se va descontando de la capacidad del equipo y así iterativamente hasta que no haya capacidad disponible, con lo que la planificación del sprint habrá terminado.
Daily Scrum meeting
Ceremonia que se celebra todos los días del sprint, salvo el día de la planificación ( primer lunes) y el día de la integración (último viernes), teniendo una duración de 15 minutos máximo.
A ella acuden los miembros del equipo , el Scrum Master y el Product Owner. Por un espacio aproximado de dos minutos, cada participante cuenta:
- Qué labores desempeñó ayer.
- Qué labores tiene previsto desempeñar hoy.
- Cuales son los bloqueos o impedimentos que tiene o percibe que puede tener, si hay alguna dependencia que pueda bloquear su trabajo. Es labor del Scrum Master facilitar en todo lo posible que estos bloqueos desaparezcan.
Sprint Review
El último viernes del sprint, aproximadamente a las 10:00h, tiene lugar esta ceremonia en la que cada uno de los desarrolladores hace una demo de las historias de usuario que ha completado. Si han colaborado varios desarrolladores en una historia, la presenta uno de ellos, elegido democráticamente entre los participantes.
A esta ceremonia acuden el Product Owner, los sponsors que haya creído conveniente convocar, el Scrum Master y todos los miembros del equipo, incluído el tester. Últimamente, debido a que el equipo de desarrollo se ha ubicado físicamente en una oficina diferente a la del PO, los sponsors y el tester, este demo la realiza el tester.
El resultado de la demo, por cada historia de usuario, es OK o KO. Normalmente, solo se enseñan aquellas historias de usuario que se está practicamente seguro de que se va a obtener un OK. Para ello, el día anterior a esta ceremonia, se hace una pre-demo junto con el Product Owner, para que se si percibe que falta algún detalle, de tiempo a completarlo antes de la demo oficial, al día siguiente.
Después de la demo, el equipo de desarrollo procede a integrar estas historias en el siguiente entorno dentro de la cadena del release train, esto es , el entorno de Integration. Para ello se apoyan en la herramienta JENKINS y la serie de jobs que permiten y facilitan esta labor. el sprint se puede dar por concluido cuando las integraciones han finalizado.
Si sobra tiempo después de todo esto, los miembros del equipo proceden a ayudar al refinamiento (via análisis técnicos) de las historias del backlog que se refinaron dos días antes, y que son susceptibles de ser planificadas para el siguiente sprint, posibilitando así que cuando llegue la planificación se puedan hacer estimaciones más acertadas.
El Scrum Master se encarga de comprobar que el dashboard del sprint se ha actualizado de acuerdo a los resultados de la demo y del sprint, revisa que se hayan introducido las horas reales en cada historia, dando por cerrado este.
Sprint Retrospective
Ceremonia que se celebra los viernes último día del sprint, y a la que acuden todos los miembros de equipo, el Scrum master y el Product Owner. Solemos utilizar un tablero específico con el siguiente formato:
Las tareas que se llevan a cabo en esta ceremonia son:
Cálculo de la nota media del sprint: Esta métrica se utiliza para medir el grado de satisfacción de los diferentes miembros del equipo con respecto al resultado del sprint tanto en fondo como en forma. Cada miembro del equipo asigna un nota al sprint (entre 1 y 10), se calcula la media y se coloca en el tablero. Tanto el que ha asociado la nota más baja como la más alta explican al resto de compañeros los motivos que les han llevado a asociar esta nota..
Reflejar aspectos positivos y negativos: Cada miembro del equipo se levanta y va colocando un post-it por cada aspecto positivo y negativo que ha percibido en el sprint, explicando con detalle el porqué de esta apreciación.
Determinar y planificar acciones de mejora del proceso: De todas los aspectos negativos, menos buenos o mejorables, se determina abordar una serie de ellos asociandolos a la zona del TODO. Del resto, lo que están en DOING de otros sprints, se estudia si pueden promocionar a DONE,y los que están en DONE se retiran del tablero.
Reporting
El equipo tienen unos objetivos determinados por cada sprint, que debe tratar de cumplir.
Cumplimiento : porcentaje de cumplimiento de los puntos de historia comprometidos vs los puntos de historia entregados en demo ( y aprobados) en el sprint. Debe ser mayor del 80% sprint tras sprint.
Calidad : Porcentaje de defectos vs puntos de historia. El ratio que debe cumplir el equipo es de 0.1 defectos por puntos de historia entregado, o lo que es lo mismo, en un sprint en el que se han planificado 25 puntos de historia por desarrollador (100 puntos de historia para los 4) , se podrían abordar hasta 10 defectos sin comprometer este ratio.
Satisfacción : Este indicador lo da la puntuación obtenida por el equipo en la retrospectiva. A veces se pueden cumplir los indicadores de cumplimiento y calidad, y obtener un valor muy bajo en este indicador, reflejando así que a pesar del buen trabajo realizado hay algo que debe mejorar en el equipo (ambiente, colaboración, etc..), aunque lo normal es que si el cumplimiento es bajo este indicador salga también bajo.
El último día del sprint es labor del Scrum Master tener toda la información preparada en JIRA para que el lunes siguiente se pueda generar automáticamente este informe.
Release Train
El ciclo de vida y los entornos por los que promociona cualquier funcionalidad son los siguientes:
Desarrollo : Entorno donde se consolida la funcionalidad que se ha desarrollado en un determinado Sprint. En este entorno se debe jacer pruebas unitarias y de desarrollo, y tanto en varios navegadores como en distintos dispositivos moviles.
Integración : Entorno donde al final de cada Sprint todos los equipos involucrados consolidan sus desarrollos. Aquí en donde se producen los conflictos en el código y donde se deben hacer los merges ya sean automáticos o manuales.
Pruebas UAT : Entorno donde el incremento producido en un sprint y que se ha integrado, permanece durante 2 semanas para las pruebas de los tester. Estos someten a pruebas exhaustivas todo lo desarrollado en integrado.
Release : Después de pasar por el entorno de pruebas UAT, el siguiente entorno donde promociona la release es este, aquí permanece solo unas horas.
QA : Entorno donde se realizan pruebas automáticas tanto de funcionales como de rendimiento, para testear que las funcionalidades críticas no se han roto y que no se ha afectado al rendimiento de loas mismas.
Producción : Entorno final donde se despliega la release. Este despliegue se hace los Jueves por la noche a las 2 de la madrugada.
El ciclo de release train tiene una duración de 30 días, desde que se comienza a desarrollar una funcionalidad, hasta que esta se ha puesto en producción. Quizás no es un tiempo corto, pero no olvidemos que se trata de una entidad financiera que por las características del negocio no es un entorno muy cambiante, y si todo se planifica, entra dentro de unos tiempos aceptables. Se está trabajando en hacer que el tiempo de release se acorte al menos una semana, para ello se está trabajando en la automatización de las pruebas funcionales y pruebas de integración. Por otro lado se está migrando la arquitectura de un enfoque monolítico a un enfoque basado en microservicios.
viernes, 30 de mayo de 2014
Egoless programming en javascript
Leyendo los primeros párrafos del PDF de la página https://leanpub.com/socra que amablemente nos ha referenciado Carlos de madridjs-list@meetup.com, me ha refrescado el tema de la "Egoless Programming" , o programación sin arrogancia. En este mundillo del javascript en el que parece que solo se buscan "Ninjas" o "Estrellas del rock", esta bien recordar que los buenos profesionales (según mi parecer) son aquellos que nunca piensan que lo saben todo, que respetan a los que saben menos, y les ayudan, que comparten su conocimiento, que el hecho de que critiquen nuestro código no es malo, ya que siempre se puede mejorar, que el código que escribimos dentro de un equipo no es nuestro, sino de todos....
Parecen nimiedades, pero en todos los años de experiencia que llevo es una de las cosas mas complicadas de poner en práctica, ya que solemos tener por lo general poco sentido de auto-crítica (me incluyo). E incluyo también a las empresas que buscan "Cristianos Ronaldos" de la programación javascript, ya que desde mi punto de vista es una equivocación, y deberían mirar otro tipo de cualidades que complementaran a las técnicas, porque esas si que es difícil aprenderlas leyendo manuales. Lo normal es que las de la experiencia, pero una experiencia que sepa mirar hacia atrás y asimilar los errores que todos cometemos, y trate de minimizarlos.
Solo sé que no se nada y, al saber que no sé nada, algo sé; porque sé que no sé nada (Sócrates)
lunes, 28 de mayo de 2012
Arquitecturas SOA
¿Que es una arquitectura SOA?
Todos los componentes de la arqutectura son diseñados para ser usados como servicios
A partir de esta aproximación, podemos definir una aplicación como un conjunto de servicios interoperables
Esto contrasta con los "silos" software que conforman los APIs internos (In-process)
Un ejemplo real y que toda la comunidad del software conoce es el de Amazon
Su CEO estableció las siguientes premisas a los equipos de desarrollo de la compañía : (traducción literal del email que envío el CEO a todos sus empleados de las divisiones de software)
1. " Todos los equipos a partir de ahora deben exponer sus datos y la funcionalidad a través de interfaces de servicio.
2.Los equipos deben comunicarse entre sí a través de estas interfaces.
3.No habrá otra forma de comunicación entre procesos: no debe haber vinculación directa, ni lecturas directas del almacenamiento de datos de otro equipo (ejemplo, aplicación de backend leyendo de base de datos de front-end, por ejemplo) , no hay un modelo de memoria compartida, no hay puertas traseras de ningún tipo. La comunicación sólo se permite es a través de las llamadas de interfaz de servicio en la red.
4.No importa que tecnología (protocolo del API) se utilice. (SOAP, REST..)
5. Los interfaces del servicio , sin excepción, deben ser diseñados desde cero para ser externalizables. Es decir, el equipo debe planificar y diseñar para poder exponer la interfaz a los desarrolladores en el mundo exterior. No hay excepciones.
6. Cualquiera que no haga esto será despedido.
7.Gracias, ! y que tengas un buen día "!
¿ Consecuencias de esto? Amazon tiene uno de los sistemas mas abiertos de los existentes, donde se potencia la reusabilidad de las funcionalidades, aumentando la productividad de sus equipos.
Todos los componentes de la arqutectura son diseñados para ser usados como servicios
A partir de esta aproximación, podemos definir una aplicación como un conjunto de servicios interoperables
- Es mas sencillo formar a los usuarios de los servicios cuando hay una nueva versión
- Mas sencillo recuperarse de errores cometidos en el diseño, ya que los cambios importantes no se "ven" desde fuera, ya que la capa de servicio puede mantener la comptibilidad hacia atrás
Esto contrasta con los "silos" software que conforman los APIs internos (In-process)
Un ejemplo real y que toda la comunidad del software conoce es el de Amazon
Su CEO estableció las siguientes premisas a los equipos de desarrollo de la compañía : (traducción literal del email que envío el CEO a todos sus empleados de las divisiones de software)
1. " Todos los equipos a partir de ahora deben exponer sus datos y la funcionalidad a través de interfaces de servicio.
2.Los equipos deben comunicarse entre sí a través de estas interfaces.
3.No habrá otra forma de comunicación entre procesos: no debe haber vinculación directa, ni lecturas directas del almacenamiento de datos de otro equipo (ejemplo, aplicación de backend leyendo de base de datos de front-end, por ejemplo) , no hay un modelo de memoria compartida, no hay puertas traseras de ningún tipo. La comunicación sólo se permite es a través de las llamadas de interfaz de servicio en la red.
4.No importa que tecnología (protocolo del API) se utilice. (SOAP, REST..)
5. Los interfaces del servicio , sin excepción, deben ser diseñados desde cero para ser externalizables. Es decir, el equipo debe planificar y diseñar para poder exponer la interfaz a los desarrolladores en el mundo exterior. No hay excepciones.
6. Cualquiera que no haga esto será despedido.
7.Gracias, ! y que tengas un buen día "!
¿ Consecuencias de esto? Amazon tiene uno de los sistemas mas abiertos de los existentes, donde se potencia la reusabilidad de las funcionalidades, aumentando la productividad de sus equipos.
viernes, 25 de mayo de 2012
SaaS
¿Que es SaaS?
Software tradicional: codigo binario que se instala y se ejecuta en el dispositivo cliente.
SaaS: entrega datos y sw como un servicio a través de internet vía un pequeño programa (ej, navegador) que ejecuta en el dispositivo cliente.
Busquedas, Redes sociales, video...
Ahora existen versiones de software tradicional que tiene su versión SaaS :
Ej: Microsoft Office 365
Motivos para SaaS
No es necesario preocuparse sobre si disponemos de la capacidad y potencia del HW, del SS.OO
No es necesario procuparse de perdidas de datos (backup)
Es mejor para trabajo en grupo, para comprtir datos.
Permite centralizar la gestión de grandes volúmenes de datos.
1 sola copia del Sw hace tener un entorno HW controlado.
1 copia del software, mejor para despliegues, actualizaciones.
Saas esta muy ligado a las metodologías Ágiles y los lenguajes de programación modernos.
Las actualizaciones frecuentes de Saas se integran bien con las iteraciones de ciclo de vida de las metodologías Ágiles
Hay muchos frameworks para Agile /Saas (ej, Ruby On Rails )
Software tradicional: codigo binario que se instala y se ejecuta en el dispositivo cliente.
SaaS: entrega datos y sw como un servicio a través de internet vía un pequeño programa (ej, navegador) que ejecuta en el dispositivo cliente.
Busquedas, Redes sociales, video...
Ahora existen versiones de software tradicional que tiene su versión SaaS :
Ej: Microsoft Office 365
Motivos para SaaS
No es necesario preocuparse sobre si disponemos de la capacidad y potencia del HW, del SS.OO
No es necesario procuparse de perdidas de datos (backup)
Es mejor para trabajo en grupo, para comprtir datos.
Permite centralizar la gestión de grandes volúmenes de datos.
1 sola copia del Sw hace tener un entorno HW controlado.
1 copia del software, mejor para despliegues, actualizaciones.
Saas esta muy ligado a las metodologías Ágiles y los lenguajes de programación modernos.
Las actualizaciones frecuentes de Saas se integran bien con las iteraciones de ciclo de vida de las metodologías Ágiles
Hay muchos frameworks para Agile /Saas (ej, Ruby On Rails )
Productividad en el desarrollo de software
Productividad en el desarrollo de software
Por: Ricardo Trujillo Rodriguez
¿Que podemos hacer para ser productivos en el desarollo de software?
Escribir código claro siendo concisos. Esto en algunos entornos se conoce com KISS (Keep It Simple Stupid!). Parece fácil, pero a muchos desarrolladores les cuesta hacer esto, complicando cada vez mas su código según va evolucionando este. Lo normal es que si no esta bien diseñado, sea muy dificil conseguir esta sencillez y claridad, obligándonos la mayoría de las veces a hacer un refactoring para devolver a ese software al camino de la claridad y la mantenibilidad.
El propio lenguaje de programación que hemos elegido para desarrollar nos puede ayudar o ser una gran barrera para conseguir nuestros objetivos en cuanto a ser productivos. La mayoría de las veces no podemos elegir el lenguaje para el desarrollo, ya que nos es impuesto por diferentes motivos, pero si somos capaces de elegir, es neceario acudir a lenguajes de 4ª generación o a los nuevos lenguajes de desarrollo muy productivos, como pueden ser Ruby o Groovy. Si a estos lenguajes les unimos los frameworks de desarrollo que se han creado basándose en ellos (Ruby On Rails , Grails) , nuestro rendimiento como desarrolladores mejorará muchísimo.
Sintaxis más corta y sencilla de leer. No es lo mismo escribir:
assert_greater_than_or_equal_to(a,7)
que
a.should be ≥ 7
Aumentar el nivel de abstracción.
Utilizar lenguajes con un nivel de abstracción alto.
Gestión automática de la memoria (Garbage Collector de Java vs C).
Sintesis.
Metaprogramación: La metaprogramación consiste en escribir programas que escriben o manipulan otros programas (o a sí mismos) como datos, o que hacen en tiempo de compilación parte del trabajo que, de otra forma, se haría en tiempo de ejecución. Esto permite al programador ahorrar tiempo en la producción de código. (ver Metaprogramación Wikipedia)
Reutilización.
Reutilizar codigo antiguo vs escribir nuevo codigo.
Refactorizar codigo antiguo para poder ser reutilizado.
Metodos, Objetos, librerías , design patterns, frameworks.
Automatización y herramientas.
Automatizar al áximo tareas repetitivas (generar versión, hacer tests). Para ello las herramientas de integración contínua ayudan y mucho.
Utilizar herramientas nuevas, hacer selección en función de su independencia, calidad de la UI. Tenemos un ejemplo bueno con el Visual Studio 2013. Eclipse tambien introduce mejoras en este sentido, generador de codigo.La calidad de un editor y sus herramientas, nos pueden ayudar mucho a mejorar nuestra productividad a la hora de escribir líneas de código.
Un buen desarrollador Sw debe cotinuamentre aprender a utilizar nuevas herramientas de desarrollo para ser productivo.
DRY
No repetir codigo.
No hacer copy / paste.
¿ Que lenguaje puede reunir todo este compendio de requisitos que buscamos para ser productivos en nuestro trabajo?:
Ejemplo: Ruby, un lenguaje de scripting moderno, orientado a objetos, funcional, con gestión automatica de la memoria, tipos diniamicos, reutilización vía mix-ins y sintesis por medio de la metaprogramación.
Por: Ricardo Trujillo Rodriguez
¿Que podemos hacer para ser productivos en el desarollo de software?
Escribir código claro siendo concisos. Esto en algunos entornos se conoce com KISS (Keep It Simple Stupid!). Parece fácil, pero a muchos desarrolladores les cuesta hacer esto, complicando cada vez mas su código según va evolucionando este. Lo normal es que si no esta bien diseñado, sea muy dificil conseguir esta sencillez y claridad, obligándonos la mayoría de las veces a hacer un refactoring para devolver a ese software al camino de la claridad y la mantenibilidad.
El propio lenguaje de programación que hemos elegido para desarrollar nos puede ayudar o ser una gran barrera para conseguir nuestros objetivos en cuanto a ser productivos. La mayoría de las veces no podemos elegir el lenguaje para el desarrollo, ya que nos es impuesto por diferentes motivos, pero si somos capaces de elegir, es neceario acudir a lenguajes de 4ª generación o a los nuevos lenguajes de desarrollo muy productivos, como pueden ser Ruby o Groovy. Si a estos lenguajes les unimos los frameworks de desarrollo que se han creado basándose en ellos (Ruby On Rails , Grails) , nuestro rendimiento como desarrolladores mejorará muchísimo.
Sintaxis más corta y sencilla de leer. No es lo mismo escribir:
assert_greater_than_or_equal_to(a,7)
que
a.should be ≥ 7
Aumentar el nivel de abstracción.
Utilizar lenguajes con un nivel de abstracción alto.
Gestión automática de la memoria (Garbage Collector de Java vs C).
Sintesis.
Metaprogramación: La metaprogramación consiste en escribir programas que escriben o manipulan otros programas (o a sí mismos) como datos, o que hacen en tiempo de compilación parte del trabajo que, de otra forma, se haría en tiempo de ejecución. Esto permite al programador ahorrar tiempo en la producción de código. (ver Metaprogramación Wikipedia)
Reutilización.
Reutilizar codigo antiguo vs escribir nuevo codigo.
Refactorizar codigo antiguo para poder ser reutilizado.
Metodos, Objetos, librerías , design patterns, frameworks.
Automatización y herramientas.
Automatizar al áximo tareas repetitivas (generar versión, hacer tests). Para ello las herramientas de integración contínua ayudan y mucho.
Utilizar herramientas nuevas, hacer selección en función de su independencia, calidad de la UI. Tenemos un ejemplo bueno con el Visual Studio 2013. Eclipse tambien introduce mejoras en este sentido, generador de codigo.La calidad de un editor y sus herramientas, nos pueden ayudar mucho a mejorar nuestra productividad a la hora de escribir líneas de código.
Un buen desarrollador Sw debe cotinuamentre aprender a utilizar nuevas herramientas de desarrollo para ser productivo.
DRY
No repetir codigo.
No hacer copy / paste.
¿ Que lenguaje puede reunir todo este compendio de requisitos que buscamos para ser productivos en nuestro trabajo?:
Ejemplo: Ruby, un lenguaje de scripting moderno, orientado a objetos, funcional, con gestión automatica de la memoria, tipos diniamicos, reutilización vía mix-ins y sintesis por medio de la metaprogramación.
Suscribirse a:
Entradas (Atom)