¿Con qué frecuencia reevalúa y actualiza su entorno de desarrollo y desarrollo? ¿herramientas?

Question

Tenía curiosidad sobre la frecuencia con la que otros desarrolladores de software reevaluaron sus entornos y herramientas de desarrollo. Solía ​​trabajar en una gran empresa con conjuntos de herramientas rígidos que todos odiaban, pero que no podían hacer nada al respecto. Entonces, nadie realmente actualizó sus entornos de desarrollo porque no podíamos en ese entorno.

Ahora que estoy en mi propia empresa inicial, puedo pasar un tiempo interminable evaluando nuevas herramientas y entornos de desarrollo, pero que realmente no debo ni puedo permitirme. Me he comprometido a pasar 1 día al mes buscando nuevas herramientas de desarrollo y probándolas para ver si vale la pena cambiar.

¿Con qué frecuencia prueba nuevos IDE, editores, herramientas de viradas de errores, depuradores? ¿O actualiza tus propias versiones más nuevas?

Answer 1

Solo me actualizo a menos que realmente me esté perdiendo una cierta funcionalidad, o me doy cuenta de que NO usar una herramienta en lugar de otra lleva a más tareas que requieren más tiempo y son menos eficientes.

Answer 2

Es un proceso continuo, pero no hago cambios importantes con más frecuencia que cada dos años más o menos. Un cambio importante implica demasiado tiempo, y la compensación no suele valer la pena. Los cambios importantes se pueden definir como el cambio de la arquitectura de objetivo o compilador completo y la cadena de herramientas para un proyecto existente.

Tenga en cuenta que pueden ocurrir cambios importantes entre proyectos: un nuevo proyecto puede establecerse en una arquitectura y una cadena de herramientas completamente diferentes sin un costo significativo. Pero se debe tener cuidado de no ir demasiado deprimido aquí. Se necesita un proceso de evaluación para evitar la selección de una configuración que no respaldará el proyecto más adelante a medida que el proyecto crezca en complejidad.

Pero para cambios menores, simplemente actualizo mis herramientas y el entorno cuando encuentro la oportunidad y la razón para hacerlo.

-Adam

Answer 3

Para mí, las actualizaciones son por eventos, no impulsada por temporizador. Mantengo mi oído en el suelo en busca de nuevas herramientas (bibliotecas, IDE, herramientas CASE, etc.) y las evalúo a medida que aparecen en mi radar.

Trabajando con las tecnologías de Microsoft, me muevo a la versión más reciente si no hay una razón de peso que me detenga. Con OSS, utilizo lo que sé a menos que haya algo convincente que me empuje hacia adelante.

Answer 4

En el trabajo, actualizamos una herramienta cuando nuestra versión llega al final de la vida útil del soporte. Actualizamos a la siguiente versión anterior.

En casa, realizo la actualización tan pronto como puedo encontrar una copia gratis de lo nuevo (es decir, algunas ofertas donde asistir a 3 webcasts le enviará una copia de la edición estándar vs2008, grupos de usuarios, etc.).

Answer 5

IDE. Tiendo a quedarme con uno que sé crecerá y apoyará mi lenguaje. En mi entorno de desarrollo es vim. Se desarrolla activamente, y tiene muchas secuencias de comandos (algo así como complementos), así como documentación para bricolaje. También inclinar un IDE toma tiempo, y ser bueno en eso, usarlo eficientemente toma más tiempo.

Revision Control. Intento quedarme justo debajo del borde sangrante. Los beneficios de las nuevas funciones son importantes. Por ejemplo, Subversion 1.4, solo admite la fusión rudimentaria. Subversion 1.5 ha revisado su sistema de fusión y ha agregado new features.

Gestión de tareas y proyectos. Tiendo a hacerlo solo cada dos años, y solo si hay un buen beneficio percibido. De lo contrario, continuaré actualizando mi sistema actual a la versión estable actual cada dos meses.

Bibliotecas. Son un lanzamiento. Dado que la mayoría de todo lo que hago no termina en un producto enviado. Me siento más libre de actualizar a menudo, pero tendemos a evitar la actualización cuando se rompe la comparabilidad hacia atrás.

Espero que mi $ 0.02 fuera útil.

Answer 6

IDEs - Esto puede ser complicado pero he progresado a través de los años. A veces, estar en un proyecto o una función específica puede desencadenar una actualización. Por ejemplo, alguien implementó una función utilizando LINQ, por lo que lo que era un proyecto ASP.Net 2.0 se convirtió en un proyecto 3.5 durante la noche. Otras veces, es solo lo que está actualmente en uso. Un punto aquí es que un cambio puede afectar a todo un equipo, por lo que no es un cambio que se realice a la ligera.

Herramientas de seguimiento de errores: también está en esa tierra de cosas centralizadas que debe manejarse con cuidado. Como se trata de una herramienta de control de calidad, espero que tengan sus propias políticas sobre la frecuencia con que buscar actualizaciones y cuándo instalarlas, ya que a veces las nuevas funciones pueden ser interesantes. El equivalente del equipo de desarrollo sería cuándo actualizar la wiki.

Control de versiones: se administran individualmente ya que la mayoría de nosotros usamos Tortoise SVN, por lo que cada uno de nosotros tiene una copia de cliente local. Entonces, las actualizaciones se hacen cuando alguien quiere hacerlo. Me gusta estar actualizado lo más posible, personalmente.

SO - Aunque parte de esto se puede controlar por departamentos, hay suficientes piezas diferentes para actualizar que a veces voy a ejecutar una actualización por mi cuenta. No estoy seguro de cuándo pasaremos a Windows 7, ya que sé que no vamos a Vista y creo que en algún momento saldremos de XP, ya que he estado en XP ahora durante aproximadamente 5 años como antes de eso, estaba en Windows 2000 Professional durante unos años y NT 4.0 antes de eso.

PC - Existe una política que cada 3 años tenemos máquinas nuevas, creo. Cuando comencé donde estoy ahora, estaba en una caja P4, por lo que la actualización a una caja de doble núcleo fue muy buena, así como un buen impulso de RAM de 2 GB a 4 GB.