¿Qué desea que los desarrolladores hagan de manera diferente? [cerrado]

Como desarrollador, paso la mayor parte del tiempo pensando en el código, la interfaz de usuario, las estructuras de datos, etc., pero (lo admito valientemente) no tiendo a considerar las implicaciones de mi aplicación para los administradores de sistemas y los DBA hasta que llegue el momento de implementar la aplicación.

En primer lugar, lo siento. En segundo lugar, ¿qué le gustaría que yo, y otros desarrolladores con los que trata, hicieran algo diferente? ¿Qué cosas le facilitarían la vida, le causarían menos problemas, alentarían la cooperación y reducirían accidentes, problemas de rendimiento y pesadillas de configuración?

1. Piensa y crea seguridad desde el día 0.
2. Utilice el control de versiones para todo: código fuente, documentación, configuración, etc.
3. Documentación, documentación, documentación.
4. Instalación y desinstalación limpias, utilizando empaques nativos de la plataforma
5. Separe los datos de configuración de las bibliotecas y los ejecutables.
6. Soporte para ejecutar diferentes versiones en paralelo para pruebas y migración
7. Registro robusto y configurable
8. Monitoreo ligero, preciso y seguro
9. Solicitud de verificación y respaldo
10. ¿Cómo reacciona su aplicación ante los problemas: falta de memoria, sistema de archivos lleno, red inactiva, archivos de configuración faltantes / dañados, falta de tiempo?
11. Siempre tenga entornos de desarrollo, prueba y producción separados. ¡Con todo el software VM gratuito, no hay excusa!

Recuerde que su aplicación probablemente tenga más estados que arriba o abajo. Dibuja un diagrama de estado. La mayoría de las aplicaciones tienen estados como:

• abajo
• inicializando
• recuperación
• arriba-pero-no-aceptando-trabajo
• esperando
• punto de control
• tratamiento
• terminando
• Apagando
• abajo

Piense en lo que sucede si el sistema se bloquea durante cada estado. ¿Cómo supervisará un administrador de sistemas y controlará las transiciones de estado?

Distinguir el "usuario" de la SA.

Un "usuario" necesita saber cómo usar su software. Los usuarios no se preocupan por cosas como cómo instalar su software.

A SA no le importa cómo usar su software, pero necesita conocer algunos detalles críticos sobre cómo instalar el software.

Escriba la documentación por separado para cada uno de esos roles, incluida la información relevante para cada uno de ellos.

Uno de mis deseos es la inclusión de mensajes adecuados en excepciones y códigos de error. Es completamente opaco para alguien que no ha desarrollado la aplicación, lo que JimmyNotAtHomeException: it's late!significa.

Pero un mensaje como Unable to find jimmy - initial manual call_mother procedurees muy útil.

Comunicación, comunicación, comunicación. Cada problema entre un administrador del sistema y un desarrollador casi siempre se puede rastrear hasta la falta de comunicación. Si antes de un proyecto, los administradores del sistema (o un representante del mismo) y los desarrolladores se reunieron y tuvieron una buena discusión sobre el marco, SOOOOOOOOOO podrían evitarse muchos problemas en el futuro. No puedo decirte cuántas cosas se ensucian porque desarrollas a todos en una caja en desarrollo solo para ver cómo se incendia en producción porque la aplicación luego se separa en Servidor de aplicaciones + servidor DB + servidor de interfaz, etc. Felicitaciones por mencionar este tema.

Involúcranos temprano en el proyecto. Como real muy temprano, en la etapa de especificaciones funcionales.

Alguien más mencionó la necesidad de instalar manualmente en cada PC, pero lo mismo se aplica para la configuración y los cambios de configuración. Si elige almacenar algo como las cadenas de conexión en el lado del cliente y necesita actualizarlas regularmente, probablemente querremos matarlo .

Elija tecnología que se pueda administrar y configurar de manera centralizada de manera adecuada, por la misma razón. Asegúrese de que se integra bien con cualquier herramienta de administración central que usemos.

Siempre pruebe usando el mínimo común denominador. Eso significa que no es administrador, en el sistema operativo más primitivo, el conjunto de aplicaciones y la plataforma del navegador de uso común. No nos gusta tener una actualización de navegador requerida para todos nuestros usuarios que aterrizaron en nosotros en el último minuto posible.

No saltes para culparnos cuando las cosas van mal. En mi antiguo trabajo cada vez que una aplicación se rompía, los desarrolladores nos señalaban al instante. "Instalaste un nuevo parche, no actualizarás los navegadores, tu seguridad es demasiado estricta" o lo que sea. Esto genera una atmósfera destructiva. Estamos del mismo lado, de verdad, y queremos trabajar con usted para solucionarlo, pero no podemos hacerlo en ese tipo de circunstancias.

No seas elitista.

"No perder el tiempo, amigo Estás a un administrador de sistemas dogsbody;. Yo escribo el software y que simplemente servicio de ella Así que cállate con tus pequeñas preocupaciones y haz lo que digo, en Aceptar.?"

Un desarrollador realmente me dijo esas palabras una vez (1). En email CC'd a un gran grupo de distribución. La implicación era clara: como desarrollador, era señor y maestro de todo el universo del software; y yo era simplemente un jornalero contratado para ocuparse de tareas demasiado triviales para que él perdiera su valioso tiempo. Por supuesto, este es un ejemplo de casi el peor de los casos, pero ya sabes, he escuchado ecos fuertes y débiles de ese comentario de varios desarrolladores tanto antes como desde entonces (2).

Puede ganar más dinero que yo (¡pero no lo asuma!). Pero se necesita un equipo para construir, operar y mantener los sistemas en los que confían nuestros usuarios. En definitiva todos los servimos.

Entiendo que tu trabajo y tus habilidades son diferentes a las mías. Respeto tus habilidades. Espero que respondas mis preguntas incluso cuando te parezcan elementales y estúpidas. ¡Alegremente le devolveré esta cortesía!

No estoy en un loco viaje de poder, como tantos desarrolladores malos (o simplemente indiferentes) han dicho, pensado y publicado en varios foros. Pero mis preocupaciones son diferentes a las suyas, y mis preguntas y sugerencias no están al servicio de mi ego. De hecho, mi trabajo es hacer que te veas mejor, manteniendo tus aplicaciones en óptimas condiciones de funcionamiento, disponibles y receptivas para todos los usuarios. Para hacerlo, tengo que mantener el resto de la red y los sistemas también en perfecto estado.

Soy plenamente consciente de que te has topado con administradores estúpidos, locos por el poder y / o simplemente perezosos en el pasado. Estoy tratando de no ser uno y no parecer uno. Si dejas espacio para esta posibilidad y la reconoces cuando la veas, estoy bastante seguro de que obtendrás lo que necesitas mientras esos otros imbéciles todavía están furiosos por lo idiota que es su administrador de sistemas.

(1) También insistía en que su programa (una herramienta para escribir y administrar requisitos de software) necesitaba privilegios de administrador de dominio para instalar y ejecutar. Fue un gran riesgo de seguridad.

(2) También he trabajado con muchos desarrolladores increíbles que pueden enseñar cuando sea necesario y aprender cuando sea necesario.

Respete que los administradores de sistemas tienen un trabajo que hacer y déjelos hacer su trabajo. Muchas empresas tienen administradores de sistemas incompetentes y esto a menudo no es realista. Pero he visto a desarrolladores arrogantes ignorar los consejos de los grupos de sistemas incluso después de que los administradores de sistemas hayan demostrado su competencia.

Discuta el diseño de un nuevo sistema con los administradores de sistemas. A menudo hay información valiosa. Los desarrolladores a menudo miran las discusiones con los administradores de sistemas y dan los requisitos iniciales como "optimización prematura". De hecho, vi al jefe de un grupo de desarrollo decir que era una pérdida de tiempo discutir los requisitos para los nuevos servidores de bases de datos con administradores de sistemas y DBA, incluso hasta el punto de describir si se trata de una carga intensiva de escritura o lectura, o cuánto almacenamiento se necesitaría.

Discuta los problemas de rendimiento con los administradores de sistemas. Honestamente, solo los administradores de sistemas son capaces de interpretar adecuadamente las métricas de rendimiento en los sistemas. He visto a los desarrolladores decidir que Linux siempre pierde memoria porque la memoria libre informada por "libre" siempre disminuye, incluso después de la décima vez que se explica la salida de "libre".

No saque conclusiones sin discutirlo con los administradores de sistemas. He visto a los desarrolladores atascarse en teorías como "las bases de datos siempre están vinculadas al disco" (no sabían que incluso existía iostat), "RAID 5 es más rápido para las cargas de trabajo transaccionales" (basado en una recolección de un sistema de base de datos que se movió de una plataforma de hardware a otra: era una carga de trabajo de lectura intensiva, la solución RAID5 tenía unidades más y más rápidas distribuidas en más controladores. Pero olvidaron estos detalles y solo recordaron la conclusión).

No diseñe una solución a un problema de sistemas sin discutirlo con los administradores de sistemas. Trabajé en un entorno patológico donde los desarrolladores diseñarían una solución y vendrían pidiendo asistencia para la implementación. Los miembros del grupo Unix además de mí, el jefe del grupo Unix y su jefe, querían tratar a los desarrolladores como "clientes", no como compañeros de trabajo que intentan hacer que una infraestructura en general funcione. El hecho de que el cliente siempre tuviera razón significaba no cuestionar lo que estaban haciendo o por qué. Yo era el único que insistiría en que se describiera el problema para poder determinar una solución correcta. No actúes de manera que cree entornos patológicos como este. No genera un beneficio neto; en cambio, los administradores de sistemas actuarán a la defensiva y todos sufrirán.

Ya no estás en la escuela. Estos son sistemas del mundo real y no actúan de manera ideal. Por ejemplo, no todo tiene latencia cero. Cuando un administrador de sistemas le advierte que las soluciones de agrupamiento son solo para fines políticos, y la complejidad adicional del sistema disminuye la confiabilidad general, tómelo en serio. Debe diseñar para los modos de falla del mundo real, por ejemplo, cuando pierde el servidor con el que está hablando a través de TCP, la conexión probablemente no se restablecerá. Los administradores de sistemas entienden los modos de falla del mundo real.

Escuche lo que le dice su administrador de sistemas o reclame ante la gerencia que sus administradores de sistemas son incompetentes y deben ser despedidos. Ignorar a su administrador de sistemas no tiene sentido.

Considere cómo desplegará su aplicación. Tenga en cuenta que discutir esto con sus administradores de sistemas tiene sentido. Si tiene 100 servidores idénticos, que difieren solo en un único archivo de configuración, puede considerar almacenar las copias maestras de estos archivos de configuración en una ubicación central. Date cuenta de lo mejor que está todo el mundo si tu aplicación es fácil de volver a implementar. Si hay un problema con un sistema, ¿preferiría volver a implementarlo en menos de un minuto, o esperar durante años mientras se repara el roto? Si puede volver a implementar su aplicación, el sistema operativo puede actualizarse de manera más fácil y segura. Puede que te importe esto en el futuro.

Si tiene un problema que cree que podría deberse al sistema operativo, tiene sentido llamar de inmediato al administrador del sistema para verificarlo. Pero después de que una investigación superficial no revela nada, tiene el deber de explicar el problema.

Comprenda que hay una diferencia entre "responder lentamente" y "no responder en absoluto".

Configure y diseñe las cosas de manera predecible con formas predecibles de cambiarlas para el sistema operativo (en) para el que está desarrollando. Esto significa todo. Por ejemplo: OpenLDAP tiene una forma extraña de hacer loglevels; ciertos servidores IMAP ni siquiera tienen archivos de configuración pero deben tener opciones compiladas; algunos paquetes quieren que sus cosas estén en una ruta de directorio particular, lo que inevitablemente romperá las convenciones de un sistema operativo particular. Todas estas cosas se destacan como verrugas en mis configuraciones habituales.

Es una regla general, pero no asuma que es especial y, por lo tanto, tiene la bendición de romper las convenciones generales de cómo los paquetes de software generalmente funcionan en su plataforma, a menos que haya una razón inherentemente buena para su software que lo requiera. "Creo firmemente que esto debería ser así" no es lo suficientemente bueno como para romper la configuración habitual de todos; Tiene que ser una razón relacionada con la función que su software está intentando realizar.

Cuando haya comunicaciones entre servidores relacionadas con la aplicación, incluya al menos un administrador del sistema en la fase de diseño. Además, documente claramente las dependencias de otros servicios: SQL, SMTP, HTTP, etc. No nos haga adivinar qué está haciendo o no podemos ayudarlo cuando algo no funciona como esperaba.

Haga posible implementar su software en docenas o cientos de sistemas de manera automatizada. Si una organización necesita un paquete de software, los administradores de sistemas casi seguramente no tienen tiempo para instalarlo manualmente en cada caja. Si un archivo necesita tener información de licencia, documentar cómo proporcionarlo sería un gran beneficio.

Históricamente, Adobe ha tenido algunos instaladores con los que fue muy difícil trabajar ; por favor apunte más alto que eso!

Piensa en escalar desde el primer día. Los administradores de sistemas pueden hacer maravillas arrojando dinero / hardware a un problema de rendimiento, pero a veces ninguna cantidad de esto ayudará, en particular, piensa en el bloqueo, a veces no puedes salir de un problema de bloqueo. Gracias por preguntar :)

Ah, e intente ser de 64 bits siempre que sea posible, y multiproceso también :)

Diseño para operaciones.

Más allá de todo lo demás aquí ...

• Solicite un entorno de producción simulado (un servidor de desarrollo o VM con la misma configuración que el servidor en vivo) y luego úselo para probar el proceso de lanzamiento. Luego, bríndenos este proceso de lanzamiento, incluida una lista de cambios y el orden en que deben aplicarse (es decir, 1. Ingrese al modo de mantenimiento, 2. aplique la actualización de SQL, 3. actualice la fuente a la versión X, 4. salga del modo de mantenimiento, 5. rezar)
• Asegúrese de tener un modo de mantenimiento que pueda expulsar a los usuarios para conservar la integridad de los datos. No quiere que ejecutemos una gran actualización del sistema en varios servidores con usuarios conectados y ejecutando transacciones ... esa es una receta para fallar en la mayoría de los casos.
• Use un modelo de desarrollo que sea algo estandarizado. Por ejemplo, todas nuestras nuevas aplicaciones en el trabajo (grupo web) usan Zend Framework.
• Bríndenos registros de cambios que podamos leer, incluida una lista de errores corregidos que podemos buscar para tener una idea del alcance de los cambios. A veces podemos identificar problemas potenciales solo porque tenemos un punto de vista diferente.

Aunque no sea realista, sería útil que los desarrolladores se vieran obligados a trabajar en un sistema de producción o dba antes de ser liberados en el mundo.

Muchas aplicaciones especializadas con las que trato no tienen ni idea de la instalación en un entorno administrado o cometen atrocidades en el diseño de la base de datos.

1) El archivo de registro que registra los errores en detalles. o buen sistema de seguimiento de errores como ELMAH.

2) La documentación detallada para la instalación, implementación y guía de SA.

3) Además de las cosas mencionadas anteriormente de otras SA increíbles. :)

Eso es todo lo que puedo pensar en este momento.

El libro Release It! tiene una buena selección de historias de terror sobre lo que puede salir mal en la producción. Leerlo puede proporcionar inspiración / ideas para diseñar teniendo en cuenta las operaciones. (Está escrito por Michael Nygard, quien ha trabajado tanto en el lado del desarrollo como en el de las operaciones).

• No desarrolles sin especificaciones
• Documento (o asegúrese de que quienes lo hacen lo hagan con precisión)
• No tenga miedo de apoyar al cliente (como un nivel más alto de soporte)

En mi experiencia, lo que haría la mayor diferencia es que los desarrolladores piensen en la implementación desde el día 1. Tan pronto como comience a concebir una nueva característica en el entorno de producción / cliente, comience a pensar cómo se implementará en ese entorno y cómo se ejecutará.

Una vez que ingresan al proceso de desarrollo, no es demasiado tarde, pero puede pasar algún tiempo antes de que puedan cambiar su perspectiva hasta ese punto; no se dan cuenta de cuán abstractamente están viendo la base de código hasta que se ven obligados a enfrentarla. En su opinión, es solo un "componente". De particular interés es cómo se implementará en un entorno preexistente , ejecutando la versión anterior (¡o anterior!) Del software. Las discusiones de implementación pueden tener un impacto significativo en cómo se ajusta la arquitectura para acomodar la nueva característica.

Algo que me gusta y que aún no he visto es configurable. Si tiene una aplicación que utiliza cualquier tipo de archivo de configuración, haga que todo sea configurable.
En mi empresa, escribí una aplicación simple que exportará una parte de nuestra base de datos. La semana siguiente lo estaba reescribiendo para permitir que una pequeña parte se apagara. Desde entonces, todas las semanas he tenido que reescribir partes y reconstruirlas solo para cambiar una pequeña característica. Apenas agregué un archivo de configuración xml, y ahora es mucho más fácil volver a implementar.
Me encantan los archivos de configuración.

Deseo que los desarrolladores tengan una mejor separación de las tareas de control de calidad. Creo que es bueno cuando un desarrollador puede crear algunos casos de prueba unitaria para un proyecto en el que está trabajando, pero sería bueno si esas pruebas se pasaran al control de calidad. De hecho, es bueno cuando los desarrolladores dan un poco de ayuda a los ingenieros de control de calidad porque al final beneficia a DEV.

Asegúrese de que sea compatible: además de todo lo demás mencionado aquí, mire esta publicación en SO - https://stackoverflow.com/questions/205374/what-are-the-core-elements-to-include-in-support- documentación/