Que souhaiteriez-vous que les développeurs fassent différemment? [fermé]

En tant que développeur, je passe le plus clair de mon temps à penser au code, à l'interface utilisateur, aux structures de données, etc., mais (je l'avoue courageusement), je n'ai pas tendance à considérer les implications de mon application pour les administrateurs systèmes et les administrateurs de base de données jusqu'au moment du déploiement. l'application.

Tout d'abord, je suis désolé. Deuxièmement, que souhaiteriez-vous que les autres développeurs avec lesquels vous faites affaire fassent différemment? Qu'est-ce qui vous faciliterait la vie, causerait moins de problèmes, encouragerait la coopération et réduirait les accidents, les problèmes de performances et les cauchemars de la configuration?

1. Pensez et intégrez la sécurité dès le jour 0.
2. Utilisez le contrôle de version pour tout: code source, documentation, configuration, etc.
3. Documentation, documentation, documentation.
4. Installation et désinstallation simples, à l'aide d'un emballage natif de la plate-forme
5. Séparer les données de configuration des bibliothèques et des exécutables
6. Prise en charge de l'exécution de différentes versions en parallèle pour les tests et la migration
7. Enregistrement robuste et configurable
8. Surveillance légère, précise et sécurisée
9. Vérification et sauvegarde d'applications
10. Comment votre application réagit-elle aux problèmes: manque de mémoire, système de fichiers plein, panne de réseau, fichiers de configuration manquants / corrompus, décalage temporel?
11. Ayez toujours des environnements de développement, de test et de production distincts. Avec tout le logiciel gratuit VM, il n'y a aucune excuse!

Rappelez-vous que votre application a probablement plus d'états que haut ou bas. Dessinez un diagramme d'état. La plupart des applications ont des états tels que:

• vers le bas
• initialisation
• récupération
• up-but-accepting-work
• attendre
• point de contrôle
• En traitement
• finir
• éteindre
• vers le bas

Pensez à ce qui se passe si le système se bloque pendant chaque état. Comment un administrateur système surveille-t-il et contrôle-t-il les transitions d'état?

Distinguer "l'utilisateur" de la SA.

Un "utilisateur" a besoin de savoir comment utiliser votre logiciel. Les utilisateurs ne se soucient pas de l'installation de votre logiciel, par exemple.

Le SA ne se soucie pas de l'utilisation de votre logiciel, mais a besoin de connaître quelques détails critiques sur la façon d'installer le logiciel.

Rédigez la documentation séparément pour chacun de ces rôles, y compris les informations pertinentes pour chacun d’eux.

L'un de mes souhaits est l'inclusion de messages appropriés dans les exceptions et les codes d'erreur. C'est complètement opaque pour quelqu'un qui n'a pas développé l'application quel JimmyNotAtHomeException: it's late!moyen.

Mais un message comme celui-ci Unable to find jimmy - initial manual call_mother procedureest très utile.

Communication, communication, communication. Chaque problème entre un administrateur système et un développeur peut presque toujours être lié à un manque de communication. Si, avant un projet, les administrateurs système (ou un représentant de ceux-ci) et les développeurs se réunissaient et menaient une bonne discussion sur le cadre, SOOOOOOOOOO permettrait d'éviter de nombreux problèmes plus tard. Je ne peux pas vous dire combien de choses sont encrassées parce que vous développez tout le monde sur une boîte en développement uniquement pour la regarder flamber en prod car l'application est ensuite séparée en serveur d'applications + serveur de bases de données + serveur d'interface, etc. Félicitations pour avoir abordé ce sujet.

Engagez-nous tôt dans le projet. Comme de vrais vrais débuts, au stade des spécifications fonctionnelles.

Quelqu'un d'autre a mentionné devoir installer manuellement sur chaque PC, mais il en va de même pour la configuration et les modifications de configuration. Si vous choisissez de stocker quelque chose comme des chaînes de connexion côté client et que vous devez les mettre à jour régulièrement, nous voudrons probablement vous tuer .

Choisissez la technologie qui peut être gérée et configurée correctement de manière centralisée, pour la même raison. Assurez-vous qu'il s'intègre bien aux outils de gestion centralisés que nous utilisons.

Toujours tester en utilisant le plus petit dénominateur commun. Cela signifie qu’en tant que non-administrateur, les systèmes d’exploitation, les suites d’applications et les navigateurs les plus primitifs sont couramment utilisés. Nous n'aimons pas avoir la mise à niveau de navigateur requise pour tous nos utilisateurs atterri sur nous à la dernière minute possible.

Ne sautez pas pour nous en vouloir lorsque les choses tournent mal. Dans mon ancien travail, chaque fois qu'une application tombait en panne, les développeurs nous pointaient instantanément du doigt. "Vous avez installé un nouveau correctif, vous ne mettez pas à niveau les navigateurs, votre sécurité est trop stricte" ou autre chose. Cela génère une atmosphère destructive. En réalité, nous sommes du même côté et nous souhaitons travailler avec vous pour y remédier, mais nous ne pouvons pas dans de telles circonstances.

Ne soyez pas élitiste.

« Ne pas perdre mon temps, mon pote Tu es juste un sysadmin larbin;. J'écris le logiciel et vous simple service il donc se taire avec vos préoccupations mesquines et ce que je dis, OK.? »

Un développeur m'a réellement dit ces mots une fois (1). Par email. CC'd à un grand groupe de distribution. L'implication était claire: en tant que développeur, il était le maître et le maître de tout l'univers logiciel; et j'étais simplement un journalier embauché pour faire face à des tâches trop triviales pour lui faire perdre son temps précieux. Bien sûr, c’est un exemple presque pire, mais vous savez, j’ai entendu des échos forts et faibles de ce commentaire émanant de nombreux développeurs à la fois avant et depuis (2).

Vous pouvez gagner plus d'argent que moi (mais ne le supposez pas!). Mais il faut une équipe pour concevoir, exploiter et entretenir les systèmes sur lesquels nos utilisateurs s'appuient. En fin de compte, nous les servons tous.

Je comprends que votre travail et vos compétences sont différentes des miennes. Je respecte tes capacités. J'espère que vous répondrez à mes questions, même si elles vous semblent élémentaires et stupides. Je vais retourner gaiement cette courtoisie!

Je ne suis pas dans une folle aventure de pouvoir, comme de nombreux mauvais développeurs (ou simplement indifférents) l'ont dit, ont pensé et posté sur différents forums. Mais mes préoccupations sont différentes des vôtres et mes questions et suggestions ne sont pas au service de mon ego. En effet, mon travail consiste à vous donner une meilleure apparence en maintenant vos applications dans des conditions optimales, disponibles et réactives pour tous les utilisateurs. Pour ce faire, je dois garder le reste du réseau et des systèmes en parfait état de fonctionnement.

Je suis pleinement conscient du fait que vous avez rencontré des administrateurs stupides, fous de pouvoir et / ou tout simplement paresseux dans le passé. J'essaie de ne pas en être un et de ne pas en ressembler. Si vous laissez de la place à cette possibilité et que vous le reconnaissez quand vous le voyez, je suis presque sûr que vous obtiendrez ce dont vous avez besoin pendant que ces autres abrutis en veulent encore plus à leur imbécile de connard.

(1) Il insistait également sur le fait que son programme (un outil pour écrire et gérer les exigences logicielles) avait besoin de privilèges d’administrateur de domaine pour l’installation et l’exécution. C'était un risque de sécurité majeur .

(2) J'ai également travaillé avec de nombreux développeurs géniaux qui pourraient enseigner si nécessaire et apprendre si nécessaire.

Respectez le fait que les administrateurs système ont un travail à faire et laissez-les faire leur travail. Beaucoup d'entreprises ont des administrateurs système incompétents et ce n'est souvent pas réaliste. Mais j'ai vu des développeurs arrogants ignorer les conseils des groupes de systèmes, même après que les administrateurs système aient prouvé leur compétence.

Discutez de la conception d'un nouveau système avec les administrateurs système. Il y a souvent des idées précieuses. Les développeurs examinent souvent les discussions avec les administrateurs système et considèrent les exigences initiales comme une "optimisation prématurée". En fait, j’ai vu le responsable d’un groupe de développement dire qu’il perdait son temps à discuter des exigences relatives aux nouveaux serveurs de base de données avec des administrateurs système et des administrateurs de base de données, allant même jusqu’à décrire s'il s'agissait d'une charge à écriture intensive ou à lecture intensive, ou combien de stockage serait nécessaire.

Discutez des problèmes de performances avec les administrateurs système. Honnêtement, seuls les administrateurs système sont capables d'interpréter correctement les métriques de performance sur les systèmes. J'ai vu des développeurs décider que Linux perd toujours de la mémoire, car la mémoire disponible signalée par "free" diminue toujours, même après la dixième fois, la sortie de "free" est expliquée.

Ne tirez pas de conclusions sans en discuter avec les administrateurs système. J'ai vu des développeurs se coincer dans des théories telles que "les bases de données sont toujours liées à un disque" (ils ne savaient même pas qu'iostat existait), "RAID 5 est plus rapide pour les charges de travail transactionnelles" (basé sur le rappel d'un système de base de données déplacé d’une plate-forme matérielle à une autre - c’était un travail intensif en lecture, la solution RAID5 disposait de plus en plus de disques plus rapides, répartis sur un plus grand nombre de contrôleurs.

Ne concevez pas de solution à un problème système sans en discuter avec les administrateurs système. J'ai travaillé dans un environnement pathologique où les développeurs concevaient une solution et venaient demander une petite assistance pour la mise en œuvre. Les membres du groupe Unix, outre moi-même, le chef du groupe Unix et son chef, souhaitaient traiter les développeurs comme des "clients", non comme des collègues qui s'efforçaient de faire fonctionner une infrastructure globale. Le client ayant toujours raison voulait dire qu'il ne fallait pas se demander ce qu'il faisait ou pourquoi. J'étais le seul à insister pour que le problème soit décrit afin qu'une solution correcte puisse être déterminée. Ne pas agir de manière à créer des environnements pathologiques tels que celui-ci. Cela ne crée pas d'avantage net: les gestionnaires de systèmes agiront de manière défensive et tout le monde en souffrira.

Tu n'es plus à l'école. Ce sont des systèmes du monde réel et ils n'agissent pas de manière idéale. Par exemple, tout n'a pas une latence nulle. Lorsqu'un administrateur système vous avertit que les solutions de clustering servent uniquement à des fins politiques et que la complexité accrue du système diminue la fiabilité globale, prenez-le au sérieux. Vous devez concevoir des modes de défaillance réels, par exemple lorsque vous perdez le serveur avec lequel vous parlez via TCP, la connexion ne sera probablement pas réinitialisée pour vous. Les administrateurs système comprennent les modes de défaillance réels.

Écoutez ce que votre administrateur système vous dit ou faites savoir à la direction que vos administrateurs système sont incompétents et doivent être licenciés. Ignorer votre administrateur système n'a aucun sens.

Considérez comment vous allez déployer votre application. Réalisez qu'il est logique de discuter de cela avec vos administrateurs système. Si vous avez 100 serveurs identiques, ne différant que par un seul fichier de configuration, vous pouvez envisager de stocker les copies principales de ces fichiers de configuration dans un emplacement central. Réalisez à quel point tout le monde est mieux si votre application est facile à redéployer. En cas de problème avec un système, préférez-vous le redéployer en moins d'une minute ou attendez-vous une éternité pendant que le système défectueux est réparé? Si vous pouvez redéployer votre application, le système d'exploitation peut être mis à niveau plus facilement et en toute sécurité. Vous pourriez vous soucier de cela à l'avenir.

Si vous pensez que le problème provient du système d'exploitation, appelez immédiatement l'administrateur système pour le vérifier. Mais après une enquête superficielle ne révèle rien, vous avez le devoir d'expliquer le problème.

Comprenez qu'il y a une différence entre "réagir lentement" et "ne pas répondre du tout".

Configurez et organisez les choses de manière prévisible avec des moyens prévisibles de les modifier pour le système d'exploitation (en) pour lequel vous développez. Cela signifie tout. Par exemple: OpenLDAP a une manière étrange de faire des loglogels; certains serveurs IMAP n'ont même pas de fichiers de configuration mais doivent avoir des options compilées; certains paquets veulent que leurs fichiers soient dans un chemin de répertoire particulier, ce qui va inévitablement rompre les conventions d'un système d'exploitation particulier. Ces choses se démarquent toutes comme des verrues sur mes configs habituelles.

C'est une règle générale, mais ne supposez pas que vous êtes spécial, et donc heureux de briser les conventions générales de la façon dont les progiciels fonctionnent généralement sur votre plate-forme, à moins que votre logiciel ne contienne une raison abondamment bonne qui l'exige. "Je crois fermement que cela devrait être le cas" n'est pas assez bon pour casser la configuration habituelle de tout le monde; ce doit être une raison liée à la fonction que votre logiciel tente d’exécuter.

Lorsque des communications entre serveurs sont impliquées dans l'application, veuillez inclure au moins un administrateur système dans la phase de conception. De plus, documentez clairement les dépendances sur d’autres services: SQL, SMTP, HTTP, etc.

S'il vous plaît permettre de déployer votre logiciel sur des dizaines ou des centaines de systèmes de manière automatisée. Si une organisation a besoin d'un progiciel, les administrateurs système n'ont presque certainement pas le temps de l'installer manuellement sur chaque boîte. Si un fichier doit contenir des informations de licence, il serait très utile de documenter la manière de le fournir.

Adobe a toujours eu des installateurs avec lesquels il était difficile de travailler ; s'il vous plaît visez plus haut que ça!

Pensez à la mise à l'échelle dès le premier jour. Les administrateurs système peuvent faire des merveilles en injectant de l'argent / du matériel sur un problème de performances, mais parfois rien de tout cela ne va aider - en particulier penser au verrouillage - parfois, vous ne pouvez pas vous acheter un problème de verrouillage. Merci d'avoir demandé si :)

Oh, et essayez d’être autant que possible en 64 bits et multi-thread aussi :)

Conception pour les opérations.

Au-delà de tout le reste ici ...

• Demandez un environnement de production simulé (un serveur de développement ou une machine virtuelle avec la même configuration que le serveur réel), puis utilisez-le pour tester le processus de publication. Ensuite, communiquez-nous ce processus de publication, y compris une liste des modifications et l'ordre dans lequel elles doivent être appliquées (c.-à-d. 1. Entrez en mode de maintenance, 2. appliquez la mise à jour SQL, 3. le source de mise à jour vers la version X, 4. quittez le mode de maintenance, 5. prier
• Assurez-vous de disposer d'un mode de maintenance qui peut expulser les utilisateurs pour préserver l'intégrité des données. Vous ne voulez pas que nous exécutions une mise à jour système volumineuse sur plusieurs serveurs avec des utilisateurs connectés et en train d'exécuter des transactions ... c'est la recette de l'échec dans la plupart des cas.
• Utilisez un modèle de développement quelque peu standardisé. Par exemple, toutes nos nouvelles applications au travail (groupe Web) utilisent Zend Framework.
• Fournissez-nous des journaux des modifications que nous pouvons lire, y compris une liste des bogues corrigés que nous pouvons rechercher pour avoir une idée de l'étendue des modifications. Parfois, nous pouvons identifier des problèmes potentiels simplement parce que nous avons un point de vue différent.

Bien que peu réaliste, il serait utile que les développeurs soient contraints de travailler dans un rôle de sysadmin ou dba de production avant de se lancer dans le monde.

Tant d'applications spécialisées que je traite n'ont aucune idée de l'installation dans un environnement géré ou commettent des atrocités de la conception de la base de données.

1) Le fichier journal qui enregistre les erreurs dans les détails. ou un bon système de suivi des erreurs comme ELMAH.

2) La documentation détaillée pour l'installation, la mise en œuvre et le guide SA.

3) Plus les choses mentionnées ci-dessus provenant d'autres SA incroyables. :)

C'est tout ce à quoi je peux penser maintenant.

Le livre Release It! a une belle sélection d'histoires d'horreur sur ce qui peut aller de travers en production. Sa lecture peut fournir une inspiration / des idées pour concevoir avec des opérations à l’esprit. (C'est écrit par Michael Nygard, qui a travaillé sur le développement et les opérations.)

• Ne pas développer sans spécifications
• Documentez (ou assurez-vous que ceux qui le font le font avec précision)
• N'ayez pas peur de soutenir le client (en tant que niveau d'assistance supérieur)

D'après mon expérience, la différence serait que les développeurs envisagent le déploiement dès le premier jour. Dès que vous commencez à concevoir une nouvelle fonctionnalité dans l'environnement de production / client, commencez à réfléchir à la manière dont elle sera déployée. environnement, et comment il va fonctionner.

Une fois dans le processus de développement, il n'est pas trop tard, mais cela peut prendre un certain temps avant qu'ils soient capables de changer leur point de vue aussi loin; ils ne réalisent pas à quel point ils voient le code de manière abstraite jusqu'à ce qu'ils soient forcés de le confronter. Dans leur esprit, c'est juste un "composant". La manière dont il sera déployé dans un environnement préexistant , exécutant la version précédente (ou antérieure!) Du logiciel, présente un intérêt particulier . Les discussions de déploiement peuvent avoir un impact significatif sur la manière dont l'architecture est ajustée pour s'adapter à la nouvelle fonctionnalité.

Quelque chose que j'aime et que je n'ai pas encore vu est configurable. Si vous avez une application qui utilise n'importe quel fichier de configuration, rendez tout configurable.
Dans mon entreprise, j'ai écrit une application simple qui exportera une partie de la base de données. La semaine suivante, je la réécrivais pour permettre à une petite partie d'être désactivée. Chaque semaine depuis, j'ai dû réécrire des pièces et les reconstruire simplement pour modifier une petite fonctionnalité. J'ai à peine ajouté un fichier de configuration XML, et il est maintenant beaucoup plus facile de le redéployer.
J'adore les fichiers de configuration.

Je souhaite que les développeurs aient une meilleure séparation des tâches d'assurance qualité. Je pense que c’est bien quand un développeur est capable de créer des cas de tests unitaires pour un projet sur lequel il travaille, mais il serait bien que ces tests soient passés à QA. En fait, c’est bien quand les développeurs aident un peu les ingénieurs QA parce que cela profite au final à DEV.

Assurez-vous qu'il est supportable: en plus de tout ce qui est mentionné ici, consultez ce message sur SO - https://stackoverflow.com/questions/205374/what-are-the-core-elements-to-include-in-support- Documentation/