¿Cuál es la cosa más importante, útil o esclarecedora que aprendió en los últimos 12 meses? [cerrado]

Aprendí que solo se necesita un administrador podrido para arruinar todo el proyecto, pero se necesitan muchos buenos programadores para limpiar el desastre después.

Después de aprender algunos Clojure , comencé a darme cuenta de la utilidad de la programación funcional , y mi estilo de codificación Java tiene Ha sido muy afectado por eso. Contrariamente a la creencia popular, un lenguaje de programación funcional no es un requisito previo absoluto para realizar una programación funcional.

Es posible incorporar bastantes elementos de la programación funcional en un lenguaje imperativo como Java, y aunque no siempre sea idiomático, puede ser muy beneficioso en algunos problemas. Por ejemplo, las clases anónimas son aproximadamente iguales a los cierres, como se describe en wikipedia . La evaluación perezosa debe ser una norma más que algo inusual. La inmutabilidad difícilmente puede ser usada en exceso. Simplemente supere la idea (casi) obsoleta de que construir objetos nuevos en lugar de mutar los existentes es costoso debido al consumo de GC y heap: en el 99.9% de los casos simplemente no es relevante. De hecho, el procesamiento paralelo puede cambiar incluso el argumento de la eficiencia de otra manera: crear nuevos objetos inmutables puede ser más barato que mutar los existentes, porque se elimina el bloqueo.

Más información sobre cómo hacer FP en Java puro aquí , aquí , aquí y aquí .

Incluso si tiene un equipo excelente y una administración competente para ese equipo, su trabajo aún no es seguro. La alta gerencia todavía puede hacer cosas tontas, como disolver toda su Dirección.

En resumen: la política importa y, a veces, la política que te afecta no puedes controlarla.

Aprendí que el propósito de las pruebas de software es encontrar errores . Es no verificar que el sistema sea correcto.

Hay factores psicológicos importantes en juego: si tu objetivo es mostrar que el programa es "correcto", gravitarás hacia las pruebas que sabes que pasarán. Pero si su objetivo es encontrar errores, gravitará hacia las pruebas que realmente llevarán a su sistema a los límites.

Incluso hay un cambio importante en el idioma que usas. Si una prueba encuentra un error, debe llamarlo exitoso . Si la prueba no lo hace [es decir, el programa pasa], lo llamas no exitoso . Me sorprendí yendo a lo largo de las líneas de pensamiento de "verificación", y hace una gran diferencia.

Este efecto psicológico se discute más en El arte de las pruebas de software , un libro clásico que recomiendo ampliamente. El autor, Myers, también recomienda que quienquiera que esté probando un programa no debe ser el autor, ni siquiera en la misma cadena de administración. Puedes hacer esto si estás programando por tu cuenta, por lo que requiere disciplina.

Realizar el desarrollo basado en pruebas desde el principio en una entrega al cliente para ver cómo afectaría a la calidad del código, y solo ejecutarse desde el iniciador JUnit en Eclipse. Resultó en un mejor producto.

El verdadero valor de la programación sin ego.

En algún nivel siempre supe que el ego y la programación no se mezclan, pero nunca razoné las consecuencias. La noción de que tiene que revisar activamente y encontrar fallas en sus propias prácticas es algo que apenas comencé a comprender el año pasado. También estoy aprendiendo a buscar activamente críticas de mis diseños (tanto en la interfaz de usuario como en el código).

Sin embargo, para ser honesto, todavía estoy aprendiendo cómo abandonar el ego, y probablemente estaré aprendiendo cómo hacerlo para el resto de mi carrera en programación.

Aquí está mi respuesta a mi propia pregunta:

Hace aproximadamente un año, hizo clic en que las pruebas de aceptación automatizadas no eran versiones automatizadas de las pruebas que nuestros evaluadores habrían hecho manualmente. Enfocarse en pruebas contra especificaciones individuales en lugar de tratar de obtener el mayor impacto posible en una sola pasada hizo que las pruebas fueran mucho más simples, más fáciles de leer y también ayuda a fomentar la entrega incremental.

Aprendí cómo un concepto matemático como Semirings se aplica a los algoritmos. Con esto, puede mostrar cómo algunos algoritmos son iguales, excepto por el uso de un semiring diferente. Esto no debería ser tan extraño para mí como programador, pero me volaron la cabeza.

Además de la política Frank Shearar mencionó , recientemente descubrí QUnit y JSCoverage que fue mi día. Y mes Nunca pensé que sería posible realizar una prueba unitaria de JavaScript con cobertura de código, pero ahí está ... :-)

Mis tres primeros agradecimientos por el último año de programación irán a lo siguiente (en orden descendente de importancia y agradecimiento):

• el paradigma de programación funcional para abrir mi mente a otras formas, a menudo más elegantes y concisas, de expresar ideas y algoritmos en código. Siento que mi habilidad general de programación ha mejorado mucho en muy poco tiempo, gracias a las ideas de programación funcional.

  (Mi agradecimiento personal a Tomáš Petříček por su excelente libro Programación funcional en el mundo real .)

• tanto inyección de dependencia como pruebas unitarias me han enseñado que la composición de objetos es posiblemente la mejor manera de crear sistemas complejos (orientados a objetos) (y que la herencia de clase no es '' Casi tan importante como solía pensar). Ambos me han enseñado y me han hecho pensar en cómo componer mejor los sistemas y cómo escribir componentes que sean fáciles de usar, pero que sean lo suficientemente flexibles como para reutilizarlos.

  (Si tuviera que mencionar un buen recurso de enseñanza, diría que Arte de la Unidad de Pruebas de Roy Osherove .)

Todos estos tomados en conjunto me han llevado a escribir un código que generalmente tiene menos errores que antes, porque ahora estoy escribiendo un código que es mucho más fácil de entender y equivocarme de lo que dije anteriormente.

Cualquiera que sea el cambio en la industria del software en rápida evolución, la curva de aprendizaje siempre está aquí. "Si solo hubiera una forma de aprender sin dedicar tiempo a aprender".

Aprendí que venderse a una nueva compañía puede mejorar su trabajo. Mi organización fue comprada a nuestra antigua compañía en mayo y las cosas parecen seguir mejorando. La nueva compañía ha ahorrado poco o ningún gasto en nuestra nueva oficina, reemplazó nuestras máquinas de desarrollo obsoletas con equipos del siglo XXI, mostró flexibilidad en la administración de nuestros proyectos y, en general, nos hizo sentir más que bienvenidos.

Se siente un poco deprimente venderse (un poco como un siervo que tiene un nuevo señor feudal porque está atado a una tierra que cambió de manos), pero el resultado final ha sido mucho mejor de lo que esperaba.

Yo diría que usar las pruebas de unidad de Microsoft en Visual Studio 2010.

Me resultó muy fácil depurar un método de prueba específico.

Podría ejecutar en cualquier momento mi proyecto de prueba para ver si la aplicación de capa empresarial funciona bien. El proceso de prueba garantiza que mi equipo no debería tener problemas al implementar la solución completa para los visitantes de nuestro sitio web.

• Python básico aprendido (usándolo para escribir scripts rápidos a veces)

• ArchLinux instalado en VM (tuve Ubuntu en VM antes, ¡mi PC es rápido ahora!)

• Comenzó con MATLAB (especialmente para trazar gráficos y verificaciones numéricas rápidas)

• Cambiado a Mercurial (de SVN) (¡bifurcándose y fusionándose!)

Aprender el patrón de MVVM me ayudó a ser un hack menos.

Tuve que empezar a mantener una aplicación web de Python, así que decidí que también era un buen momento para aprender Vim . Ahora estoy usando el complemento de IdeaVim para Intellij para mi desarrollo de Java y Flex y definitivamente creo que ha hecho mi escritura más rápida y eficiente.