Comment les administrateurs de base de données pourraient-ils être plus «conviviaux pour les programmeurs»?

Réponses et commentaires sur la version dba.se et la version programmers.se de la question "Quels sont les arguments contre ou pour placer la logique d'application dans la couche base de données?" sont très révélateurs de la division entre les administrateurs de base de données et les programmeurs sur certains lieux de travail.

Qu'est-ce que les administrateurs de base de données pourraient faire différemment pour mieux travailler avec les programmeurs sur des problèmes de ce type?

Devrions nous:

• Étudiez les outils et les langages utilisés par nos programmeurs pour comprendre leurs difficultés, en particulier lorsque vous travaillez avec des bases de données bien conçues?
• Encourager les programmeurs à mieux s'informer sur les bases de données et sur les avantages de disposer d'une logique métier au niveau de la base de données?
• Changer la façon dont nous définissons les interfaces avec nos données - par exemple en utilisant davantage d’API transactionnelles plus conviviales pour les programmeurs (par exemple, pour des problèmes tels que la compatibilité ascendante)?

En tant que programmeur, je dirais que ce que nous voulons le plus, ce sont des normes cohérentes, bien définies et mises en œuvre concernant la conception et la construction de la couche de données. Je suis prêt à jouer comme vous le souhaitez dans votre bac à sable, il vous suffit de me dire ce que vous voulez et de ne pas changer les règles tout le temps. Il devrait être mis en œuvre de la même manière pour tout le monde, même les superprogrammes. Si vous faites des exceptions pour lui, vous voulez que je le soutienne et que je le modifie, mais que vous le remettiez en œuvre de la bonne manière qui ne fonctionne pas pour moi.

Et s'il vous plaît ne me dites pas de ne pas le faire de cette façon et de partir. Travaille avec moi pour me montrer ce que tu veux et pourquoi ton chemin est meilleur. Si je comprends bien, je vais me conformer à chaque fois. Lorsque je ne l'obtiens pas, il est plus difficile de s'y conformer. Je ne veux pas être un DBA. J'adore programmer, je ne veux pas de votre travail et si vous êtes un bon administrateur de bases de données, je serai votre plus grand fan.

Je suis administrateur de base de données MySQL depuis 6,5 ans. J'ai également passé 16 ans en tant que développeur et interagi avec de nombreux administrateurs de base de données. Beaucoup d'entre eux sont pragmatiques. Certains d'entre eux sont odieux. Quelques-uns n'ont aucune idée de ce que signifie être un DBA.

Je suis venu à cette conclusion:

Techniquement, il est préférable de travailler avec les administrateurs de base de données possédant une ou plusieurs des qualités suivantes:

1. A passé des années en tant que développeurs
2. Maîtriser la théorie des bases de données
3. Bien comprendre le fonctionnement du SGBDR en interne
4. Avoir une connaissance supérieure du système d'exploitation

Les DBA très disciplinés et compétents ont beaucoup à partager et à offrir. Ils peuvent voir les performances de la base de données d’un point de vue qui n’est pas vraiment pris en compte par les développeurs. Les développeurs savent ce qu'ils veulent de la base de données. Les administrateurs de bases de données savent être "polis" envers la base de données.

En ce qui concerne les personnalités, il y aura toujours des conflits, des mesquineries et peut-être même de l'envie. Une chose est sûre: sans ordre particulier, les administrateurs de base de données et les développeurs sont comme des maris et des épouses (je suis mariée avec bonheur depuis 16 ans avec des projets en cours [4 enfants]).

Peu importe qui est perçu comme le mari et qui est perçu comme la femme, ces principes s'appliquent:

1. l'un doit consulter l'autre
2. on doit valoriser la perspective de l'autre
3. il faut prendre des décisions pour le bien des deux parties
4. il faut soutenir et non sabatoge la décision prise
5. l'un ne doit pas dénigrer l'autre si les décisions ont de mauvaises conséquences
6. il faut se réjouir de la contribution des deux parties au succès des décisions
7. on doit consulter une autorité supérieure (HA) si une décision ne peut pas être mutuellement convenue

Ces sept (7) principes s’appliquent tout autant sur le lieu de travail, en particulier dans le domaine informatique.

En communiquant chaque étape du chemin, tous devraient:

1. mettre en forme leurs attentes
2. susciter le respect de la capacité de l'autre partie à faire sa part en fonction des performances passées
3. avoir confiance que l'autre partie peut mener à bien sa mission
4. à la hauteur de nos attentes
5. acquiescement sous la direction de la HA (voir principe 7)

Il n’ya pas de place pour la microgestion dans ce domaine. Les administrateurs de base de données ne doivent pas expliquer aux développeurs comment penser comme des administrateurs de base de données. Les développeurs ne doivent pas dire aux administrateurs de base de données comment être des développeurs. Les décisions finales sur les performances et l'utilisation de la base de données doivent appartenir aux administrateurs de base de données . Les décisions finales sur les besoins en applications doivent appartenir aux développeurs . Cette symbiose doit toujours être maintenue.

DERNIÈRES PENSÉES

Le principe 7 exige une participation et une surveillance actives de la part de la SUPERER AUTORITY (HA), c’est-à-dire du chef de projet, du chef d’équipe et du développeur principal. Votre agent de santé sait mieux comment les deux parties travaillent individuellement et comment elles doivent travailler ensemble. Si l’AH n’établit pas de règles de base pour les deux parties, ou si l’AH ne guide pas les parties individuellement et ensemble, les projets s’arrêteront toujours à un moment donné et mettront en danger l’existence même (emploi) du Développeur, le DBA, ou même le HA.

Avoir des équipes assises dans différentes sections / étages semble en quelque sorte encourager la mentalité "nous contre eux".

Assister un DBA en plein milieu de l'équipe de développement est un excellent moyen de démolir le mur du programmeur / DBA. Tant les administrateurs de base de données que les programmeurs en bénéficieront s'ils restent ouverts et mettent leur ego de côté.

La communication face à face, en particulier lors du partage d’idées, est beaucoup plus efficace que le courrier électronique et a moins de chance de créer des sentiments négatifs en raison de malentendus.

Ce genre de chose varie énormément d'un endroit à l'autre. Sur mon site actuel, la ligne de démarcation entre les développeurs et les administrateurs de base de données est très floue: nous (les administrateurs de base de données) écrivons aussi en PL / SQL, et ils (les développeurs) dissèquent les plans de requête. Nous nous considérons tous comme des pairs dotés simplement de compétences et de responsabilités différentes. C'est très amusant: la société a récemment pris le train en marche de DevOps . La communauté de base de données ne comprend pas du tout cela; nous avons toujours travaillé comme ça. Inutile de dire que nous sommes extrêmement productifs si nous travaillons comme ceci: le niveau base de données est de loinla partie la plus fiable de la pile technologique de la société, elle est facile à utiliser (car nous possédons les compétences de l’équipe DBA pour comprendre l’application en profondeur, et les développeurs ont la possibilité d’être DBA pour comprendre les opérations 24/7/365 et comment structurer leurs applications pour cela).

Mais je sais ce que vous voulez dire quand vous parlez du "mauvais" type de développeur. Il est autodidacte, ce qui en soi est une chose noble, mais au fil du temps, il s'est méfié de toute sorte d'instructions formelles. Il ne sait pas ce qu'il ne sait pas et il en veut à quiconque tente de l'éclairer, il y voit une insulte à son auto-apprentissage. Il a appris le style de programmation impératif, car vous pouvez l’apprendre sans aucune de ces théories sur lesquelles les types CS ne cessent de parler (bon, mal; tout le monde a besoin de savoir grand-Oet des morceaux de théorie similaires). Il a également appris un peu le langage OO, simplement parce qu'il doit utiliser Java. Mais un bon professionnel des bases de données - développeur ou administrateur de base de données - doit être à l’aise dans un style déclaratif, en pensant à la théorie des ensembles, aux formes normales, voire en mesure de comprendre l’algèbre et le calcul relationnels. Il est très, très difficile de communiquer avec ces personnes, car elles sont activement hostiles à tout ce qui pourrait les sortir de leur zone de confort, qui se limite généralement à la façon de formater quelque chose sur une page Web. S'ils pensent aux bases de données, ils pensent qu'une table est comme une classe et qu'une ligne est comme un objet. Ces gars vont littéralement juste faire SELECT * FROM TABLEet filtrer et trier les résultats dans leur propre code. Ils ne comprennent vraiment vraiment pas pourquoi une base de données est meilleure qu'un fichier plat (et ils ne pensent pas si secrètement que quiconque utilise une base de données relationnelle est un idiot).

Permettez-moi de vous donner un exemple concret: récemment, je parlais avec l'un de ces types des problèmes liés à la rétrogradation d'une version de notre logiciel après sa mise en production, si un problème avait déjà échappé à l'assurance qualité. J'ai expliqué que même si nous pouvions restaurer son application (l'une des nombreuses applications accédant à la base de données), il faudrait qu'elle puisse fonctionner avec la base de données toujours déployée. Il a demandé pourquoi, et j'ai dit: dans ces nouvelles tables et colonnes, il y aura de vraies données sur les clients. Il a ensuite dit, copiez-le simplement dans une table temporaire, quel est le problème. Je le regardais avec incrédulité: lorsqu'un client appelle pour me dire que mon argent a disparu de mon compte, que lui dit-on, que ça va, qu'il est dans une table temporaire? Il n'a tout simplement pas compris que lorsque vous traitez avec l'argent des autres, vous devez vous comporter en adulte responsable. Pour autant que je sache, il ne le sait toujours pas. il n'est plus avec nous.

Le camp MySQL a été comme ça pendant longtemps; ils diraient que vous n'avez pas besoin de transactions, de clés étrangères, etc., si vous pensiez le faire, c'était uniquement parce que vous n'aviez aucune idée de ce que vous faisiez, etc., etc. Ce sont les types de personnes pour lesquelles les ORM tels qu'ActiveRecord ou Hibernate ont été développés, afin de pouvoir écrire des applications de base de données sans avoir à toucher à SQL. Je considère que l’utilisation de ces technologies est un drapeau rouge: ce n’est pas une entreprise qui valorise les compétences de DBA. Ce qu'ils veulent vraiment, c'est une baby-sitter ...

En tant que programmeur, comprendre la base de données m'a permis de devenir un meilleur programmeur. Lorsque je suis devenu administrateur de base de données, cela est devenu encore plus important. Je pense donc que l'éducation est la clé.

Les administrateurs de bases de données doivent patiemment guider les développeurs qui les traitent comme des professionnels compétents. Peu de programmeurs constatent la différence entre une opération définie et une opération ligne par ligne côté client. Nous partageons certains des mêmes objectifs - vitesse d'application, sécurité des données, maintenabilité, etc. Cela s'applique non seulement à la question de la logique d'application, mais également à tous les aspects de l'interaction de base de données. Les programmeurs souhaitent mieux utiliser leurs outils. Plus l'administrateur de la base de données peut leur montrer comment mieux utiliser l'outil de base de données, plus ils en bénéficieront.

Quelle que soit l'infrastructure que nous soutenons, nous devons en supporter les utilisateurs. De nombreux utilisateurs sont des développeurs. Nous les aidons donc à leur permettre d’utiliser au mieux cette infrastructure. Pour pouvoir faire cela, nous devons nous comprendre, en tenant compte des différentes idées et points de vue. Avoir un aperçu des points de vue des deux côtés contribue à améliorer les choses pour l'entreprise et c'est notre objectif combiné. Faites en sorte que le support informatique de l’entreprise soit aussi efficace que possible.

Dans de nombreuses organisations, certains types de dba fonctionnent en mode divin. La plupart du temps, ce ne sont pas ceux qui obtiennent de très bons résultats si on mesure la compétence ..... Souvent, ils cachent simplement leur - manque de - connaissances derrière un mur de mots.

À mon avis, cela n’a rien à voir avec le fait d’être «amical envers les programmeurs» mais plutôt avec le fait d’être professionnel. Pour un fournisseur de base de données, cela signifie que nous devons être en mesure d'expliquer pourquoi nous faisons ce que nous faisons et d'être prêt à revoir la décision de location si cela peut aider, sans perdre les objectifs habituels tels que la disponibilité, l'évolutivité, la capacité de récupération et les performances. Pour le programmeur, cela signifie qu'il doit communiquer avec le dba, parfois enseigner le dba, parfois apprendre du dba. Ma devise est la suivante: que le premier jour où je n’apprenne rien du tout soit le jour où le cercueil se fermera au-dessus de ma tête. Une collaboration normale, la combinaison d'équipes avec des développeurs et dba contribue certainement à faciliter les choses.

Je pense qu'une partie du problème est la perspective. Dbas, les analystes de données et les développeurs de bases de données doivent traiter les données au fil du temps. Les développeurs d’applications s’intéressent à la façon de faire fonctionner les choses lorsqu’ils l’envoient en production. Ils ne s'inquiètent pas trop de la présentation des données dans six mois, tant qu'il n'y aura pas d'erreur lors de leur déploiement.

Mais les utilisateurs de données doivent vivre avec les résultats des décisions à courte vue qui causent la perte d'intégrité des données ou provoquent l'insertion d'enregistrements en double, puis tentent d'expliquer pourquoi les données sont mauvaises. Les administrateurs de base de données sont ceux qui doivent faire face au problème de performance du processus qui fonctionnait bien lorsqu'il n'y avait qu'un millier d'enregistrements, mais qui prend maintenant des heures avec 100 000 000 d'enregistrements.

Les bases de données sont plus difficiles à refactoriser, aussi les administrateurs de base de données sont-ils soucieux de bien faire les choses du premier coup. Les développeurs ne voient aucun problème à la refactorisation ultérieure.

Les développeurs ne voient pas d'inconvénient à ce que la base de données agisse comme si elle était orientée objet. Les responsables de la base de données savent que ce n'est pas le moyen le plus efficace ou le plus efficace de stocker ou d'obtenir les données.

Les développeurs d'applications ne traitent souvent qu'un petit sous-ensemble d'enregistrements, mais pas d'importations / exportations de données volumineuses ou de rapports. Les choses qui fonctionnent bien pour entrer un enregistrement, ne fonctionnent pas quand vous parlez d'importer un million. La logique applicative de l'application (qui n'est souvent pas accessible à l'application de génération de rapports) n'aide pas le rédacteur de rapport à obtenir les mêmes résultats pour un million d'enregistrements que ceux affichés à l'écran, enregistrement par enregistrement.

Le manque de respect des deux côtés est une autre partie du problème. J'ai rencontré plus de quelques développeurs d'applications qui pensent que le travail de données n'est pas difficile ou intéressant et qui pensent que vous ne le feriez que si vous ne pouvez pas le pirater dans leur monde. Les gens ont tendance à ne pas bien réagir quand ils sont traités comme s'ils étaient stupides et inutiles. D'autre part, certains administrateurs de base de données ont tendance à traiter également les développeurs d'applications avec un manque de respect et à donner la priorité à leur tâche consistant à analyser ce qu'ils font avec la base de données (ce qui peut être le cas lorsque vous disposez de bases de données de production complexes et volumineuses). Ils peuvent refuser d'entendre ou d'être réactifs. Qui veut que tout son projet soit suspendu jusqu'à ce que la DBA le revoie deux semaines plus tard? Et puis il vous dit que c'est inacceptable et que vous devez réécrire le tout?

Au cours des nombreuses années écoulées depuis le début de SQL Server (1998), de nombreux développeurs m'ont expliqué comment faire mon travail. Il est intéressant de noter qu'ils savent tous plus que moi et qu'ils sont également d' excellents développeurs .net. En fait, ils sont aussi des architectes et devraient faire beaucoup plus que du singe du code.

C'est peut-être la mauvaise attitude de ma part: mais c'est une attitude assez commune chez les développeurs dans de nombreux magasins. Souvenez-vous: regardez les combats commencer lorsque vous suggérez des examens par les pairs.

Je laisserai les solutions à d'autres réponses (je suis d'accord à 100% avec les deux jusqu'à présent), mais j'ajouterai que la culture de la gestion et des magasins doit également soutenir et favoriser la collaboration.

En tant que développeur, tout ce dont j'ai besoin de vous, c'est de savoir comment vous voulez que je communique ce dont j'ai besoin. Si je demande quelque chose de ridicule, il faut que vous me le disiez - et si vous me le dites, je le croirai parce que vous avez des antécédents en matière d'intégrité. Si vous ne comprenez pas ce que je demande, prenez le temps de m'expliquer ce que vous pensez, et je prendrai le temps de vous écouter.

... Thème commun, droit ... Communication ... communication ... communication.

Il n'y a vraiment pas de meilleur moyen de le dire. Les développeurs sont cochés parce que "le DBA m'a dit que cela ne pouvait pas être fait - je lui ai prouvé le contraire la dernière fois." Les administrateurs de bases de données sont cochés parce que "ce développeur ne comprend pas ce que je dois faire chaque fois qu'il modifie ses spécifications".

Les développeurs et les DBA, comme @Rolando l'a déclaré, doivent se comprendre. Quand tout se résume à cela, nous parlons tous les deux de "Des uns et des zéros" - on pourrait penser que ce serait un bon match. Nous avons deux domaines de responsabilité: les administrateurs de base de données ont des données, les développeurs obtiennent le reste de l'ordinateur. Mais sans données, les programmeurs n'auraient vraiment pas grand chose à faire.

Nous n'avons pas de DBA et c'est parfois douloureux. Ce morceau de moi qui voulait devenir DBA il y a une dizaine d'années va se faire mal lorsque je vois certaines de nos tâches. Si nous avons embauché un DBA demain, je pense que j'embrasserais le sol sur lequel il / elle a marché.

Dans certaines entreprises, peut-être beaucoup, le développement de produits a tendance à ignorer ceux qui n'écrivent pas dans un langage compilé. Au moment de la publication, il y a de la résistance, car les administrateurs de réseau, les administrateurs de base de données, les administrateurs de système, le support utilisateur, etc. ont chacun leur devoir de diligence. Il y a souvent des maux de tête parce que les aspects clés de l'environnement n'ont pas été pris en compte. Cela provoque naturellement des tensions entre les équipes.

Qui est à blâmer ici? Mme communication.

Les développeurs doivent comprendre que le code d’environnement sera déployé. Les personnes doivent recevoir un avertissement juste pour pouvoir s’adapter. Lorsque l'environnement ne peut pas s'adapter pour une raison quelconque (sécurité, équipement, politique), le logiciel doit s'adapter. Si cela se produit pendant le processus de conception et de mise en œuvre, tout le monde est content. Si cela ne commence pas avant le déploiement, c'est un monde de souffrance.

Oui, les équipes doivent se parler (et s'écouter), mais le chef de projet / produit doit créer un environnement dans lequel cela peut se produire.

J'ai eu de la chance, dans la plupart des endroits où j'ai travaillé, le respect mutuel et la communication ont fait partie de la culture.

Une bonne chose qu'un DBA doit comprendre est la politique des données. J'ai enseigné la programmation et la conception de bases de données à des programmeurs chevronnés et à quelques DBA rédigés pendant quelques années. Une question qui se posait régulièrement était la suivante: comment se fait-il que toutes les bases de données de mon magasin soient si politiques?

Voici ma réponse habituelle: si la base de données est utile, vous partagez des données. Si vous partagez des données, vous partagez un pouvoir. Quand le pouvoir est partagé, la politique se produit.

Peu importe si vous aimez la politique ou détestez la politique. Si vous voulez faire un bon travail de base de données, s'y habituer.

Incidemment, certains d’entre vous n’ont travaillé que dans un environnement de développement. Il y a des DBA qui travaillent du côté de la production de la barrière et qui ont peu d'interaction avec les développeurs. Vous pourriez penser qu'il y a moins de politique dans la production. Il y a plus. Les grandes bases de données de production ont tendance à être globales et critiques.

Un peu d'humilité pourrait aider certains d'entre vous. ;)

Il existe évidemment des arguments valables pour l'une ou l'autre approche, je vous suggère de commencer par le reconnaître. Le développement de logiciels consiste à faire les bons compromis. S'il s'agit d'une rue à double sens, les administrateurs de bases de données devraient peut-être aussi garder l'esprit ouvert.