Comment DBAS pourrait-il être plus "sympathique"?
Les réponses et les commentaires sur la version dba.se et version programmeurs.se de la question "Quels sont les arguments contre ou pour la mise en place La logique d'application dans la couche de base de données? " sont très révélatrices sur la fracture entre les DBA et les programmeurs dans certains lieux de travail.
Qu'est-ce que DBAS pourrait faire différemment pour mieux fonctionner avec les programmeurs sur des questions telles que celle-ci?
Devrions nous:
- Étudiez les outils et les langues que nos programmeurs utilisent pour comprendre leurs difficultés rencontrées, en particulier lorsque vous travaillez avec des bases de données bien conçues?
- Encouragez les programmeurs à mieux éduquer sur les bases de données et les avantages de la logique commerciale au niveau de la base de données?
- Modifiez la façon dont nous définissons les interfaces à nos données, telles que en utilisant plus d'API transactionnelles conviviales de programmeur (par exemple, pour des problèmes tels que la compatibilité à l'envers)?
Du point de vue du programmeur, je dirais que la chose que nous voulons que la plupart soit cohérente, bien définie et mise en œuvre de normes pour la manière dont la couche de données sera conçue et construite. Je suis prêt à jouer votre chemin 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 la même chose pour tout le monde, même superprogrammergose. Si vous faites des exceptions pour lui, vous voulez que je puisse le soutenir et le changer, mais la mise en œuvre de la bonne façon qui ne fonctionne pas pour moi.
Et s'il vous plaît ne me disiez pas de ne pas le faire de cette façon et de partir. Travaillez avec moi pour me montrer ce que vous voulez et pourquoi votre chemin est meilleur. Si je comprends, je vais me conformer à chaque fois. Quand je ne comprends pas, c'est plus difficile de se conformer. Je ne veux pas être un DBA. J'aime la programmation Je ne veux pas de votre travail et si vous êtes un bon dba, alors je serai votre plus grand fan.
J'ai été un DBA mysql depuis 6,5 ans. J'ai également passé environ 16 ans en tant que développeur et j'ai interagi avec de nombreux DBA. Beaucoup d'entre eux pragmatiques. Certains d'entre eux odieux. Quelques-uns n'ont aucune idée de ce que cela signifie être un DBA.
Je suis venu à cette conclusion:
Techniquement, les DBA qui ont une ou plusieurs des qualités suivantes sont les meilleures pour travailler avec:
- Passé des années comme des développeurs eux-mêmes
- Avoir une compréhension de la théorie de la base de données
- Avoir une bonne compréhension de la façon dont le SGBDS fonctionne en interne
- Avoir une connaissance supérieure du système d'exploitation
Les DBAS très disciplinés et compétents ont beaucoup à partager et à offrir. Ils peuvent voir les performances de la base de données d'une perspective non vraiment considérée par les développeurs. Les développeurs savent ce qu'ils veulent de la base de données. Les dabas savent comment être "poli" à la base de données.
En ce qui concerne les personnalités, il y aura toujours des conflits, une manette et peut-être même envier. Une chose est sûre: dans aucun ordre particulier, les DBA et les développeurs sont comme des maris et des épouses (j'ai été marié avec plaisir depuis 16 ans avec des projets en cours [4 enfants]).
Peu importe qui est considéré comme le mari et qui est considéré comme la femme, ces principes s'appliquent:
- il faut consulter l'autre
- il faut valoriser la perspective de l'autre
- il faut prendre des décisions pour le bien des deux parties
- il faut soutenir et non sabatoge, la décision prise
- il ne faut pas dénigrer l'autre si les décisions résultent de mauvaises conséquences
- il faut se réjouir de la contribution des deux parties au succès des décisions
- il faut consulter une autorité supérieure (ha) si une décision ne peut être convenu d'un commun accord
Ces sept (7) principes s'appliquent tout autant sur le lieu de travail, en particulier dans le domaine informatique.
En communiquant à chaque étape, tout devrait:
- la mise en page leurs attentes
- engendrer le respect de la capacité de l'autre partie à faire leur part en fonction des performances passées
- avoir confiance et confiance que l'autre partie peut compléter leur mission
- vivre à nos propres attentes
- acquiesté sous la direction de l'HA (voir principe n ° 7)
Il n'y a pas de place pour la micromanie dans ce domaine. Dbas ne doit pas le dire Développeurs Comment penser comme DBAS. Développeurs ne doit pas dire DBAS Comment être développeurs. Les décisions finales sur Les performances de la base de données et l'utilisation doivent reposer avec DBAS . Les décisions finales sur Les besoins de l'application doivent reposer avec les développeurs . Ceci Symbiose doit toujours être maintenu.
DERNIÈRES PENSÉES
Le principe n ° 7 nécessite une participation et une surveillance active par l'autorité supérieure (l'HA), c'est-à-dire chef de projet, chef d'équipe, développeur principal. Votre HA SAVOIT savoir comment les deux parties travaillent individuellement et comment les deux parties devraient travailler ensemble. Si l'HA n'établit pas les règles de base pour les deux parties, ni si les HA ne guident pas les parties individuellement et ensemble, des projets s'arrêtent toujours à un moment donné et mettront en danger l'existence même du développeur, le DBA, ou même les ha.
Avoir des équipes siégeant dans différentes sections/planchers semble en quelque sorte évoquer la mentalité "américaine".
Assis Un DBA en plein milieu de l'équipe de développement est un excellent moyen de démolir le mur programmeur/DBA. Le DBA et les programmeurs en bénéficieront à la fois, s'ils restent ouverts d'esprit et mis de côté leurs egos.
La communication face à face, en particulier lors du partage des idées, est beaucoup plus efficace que le courrier électronique et a moins de chance de causer des sentiments difficiles en raison de malentendus.
En tant que programmeur Comprendre la base de données, mieux m'a fait un meilleur programmeur. Quand je suis devenu un administrateur de base de données, il est devenu encore plus important, je crois donc que l'éducation est la clé.
Les DBA devraient patiemment guider les développeurs les traiter comme des professionnels compétents. Peu de programmeurs lors de la diffusion de la différence entre une opération définie et une ligne par ligne de ligne sur le côté du client dépousseront à l'idée. Nous partageons certains des mêmes objectifs - la vitesse de l'application, la sécurité des données, la maintenabilité, etc. Ceci s'applique non seulement à la question de la logique de l'application, mais également à tous les aspects de l'interaction de la base de données. Les programmeurs veulent mieux utiliser leurs outils et plus le DBA peut leur montrer comment utiliser l'outil de base de données mieux plus ils bénéficieront.
Quelle que soit l'infrastructure que nous soutenons, nous devons en soutenir les utilisateurs. Beaucoup d'utilisateurs sont des développeurs, nous soutenons donc les développeurs pour leur permettre de tirer le meilleur parti possible de cette infrastructure. Pour pouvoir faire cela, nous devons nous comprendre, avec les différentes idées et points de vue à l'esprit. Avoir un aperçu des points de vue des deux côtés aide à améliorer les choses pour l'entreprise et c'est notre objectif combiné. Faites-le soutenir l'entreprise aussi efficace que possible.
Dans de nombreuses organisations, nous voyons des types de DBA en mode Dieu. La plupart des temps, ce ne sont pas ceux qui marquent très bien si la compétence est mesurée ..... souvent, ils cachent leur - manque de connaissances derrière un mur de mots.
À mon avis, cela n'a rien à voir avec "programmeur sympathique" plus avec être professionnel. Pour un DBA, cela signifie que nous devons pouvoir expliquer pourquoi nous faisons les choses que nous faisons et que nous sommes prêts à reconsidérer le contrat de location si cela aide, sans perdre les objectifs normaux comme la disponibilité, l'évolutivité, la récupération et la performance. Pour le programmeur, cela signifie qu'il doit communiquer à la DBA, parfois pour enseigner à la DBA, parfois à apprendre du DBA. Ma devise sur ceci est: Laissez le premier jour que je n'apprends pas une chose soit le jour où le cercueil se ferme au-dessus de ma tête. La collaboration normale, après avoir combiné des équipes avec des développeurs et des DBA, aidez certainement à faciliter les choses.
Je pense qu'une partie du problème est une perspective. Les analystes et les développeurs de données DBAS et de données doivent faire face aux données au fil du temps. Les développeurs d'applications s'inquiètent de la manière de faire fonctionner les choses lorsqu'ils l'envoient à la production. Ils ne s'inquiètent pas tant de savoir ce que les données ressembleront dans six mois tant qu'il n'y a pas d'erreur lorsqu'il est déployé.
Mais les personnes de données doivent vivre avec les résultats des décisions à courte vue qui provoquent les données de perdre de l'intégrité ou de provoquer des enregistrements en double pour être insérés, puis d'essayer d'expliquer pourquoi les données sont mauvaises. Les DBA sont ceux qui doivent faire face au problème de performance du processus qui a fonctionné bien lorsqu'il n'y avait que mille enregistrements, mais prend maintenant des heures avec 100 000 000 enregistrements.
Les bases de données sont plus difficiles à refracteur. Les DBA sont donc préoccupés par la première fois. Les développeurs ne voient aucun problème dans la refactoring sur la route.
Les développeurs ne voient aucun problème avec la création de la base de données comme s'il était orienté objet, les personnes de 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 que d'un petit sous-ensemble d'enregistrements, mais pas aux importations de données importantes/exportations ou à la notification. Les choses qui fonctionnent bien pour entrer un enregistrement, ne fonctionnent pas lorsque vous parlez d'importation d'un million. La logique commerciale dans l'application (qui n'est souvent pas accessible à la demande de rapport) n'aident pas le rédacteur de rapports à obtenir les mêmes résultats pour un million d'enregistrements que ce qui est indiqué à l'écran un enregistrement à la fois.
Une autre partie du problème est le manque de respect des deux côtés. J'ai rencontré plus de quelques développeurs d'applications qui pensent que les données de données ne sont pas difficiles ni intéressantes et qui croient que vous ne feriez que ce travail si vous ne pouvez pas le pirater dans leur monde. Les gens ont tendance à ne pas bien réagir pour être traité comme si elles sont stupides et inutiles. Certains DBA ont également tendance à traiter les développeurs d'applications ayant également un respect et ont tendance à mettre en place leurs tâches d'examiner ce que les développeurs font à la base de données comme une priorité faible (lorsque vous avez de grandes bases de données complexes, cela peut être). Ils peuvent refuser d'entendre ou d'être réactif. Qui veut que tout son projet soit mis en attente jusqu'à ce que le DBA l'examine deux semaines plus tard? Et puis il vous dit que c'est inacceptable et vous devez réécrire le tout?
En tant que développeur, tout ce dont j'ai besoin de vous, c'est savoir comment vous voulez que je communique ce dont j'ai besoin. Si je demande quelque chose de ridicule, j'ai besoin de vous dire - et si vous me le dites, je vais le croire parce que vous avez un record de piste pour l'intégrité. Si vous ne comprenez pas ce que je demande, prenez le temps de m'expliquer ce que vous pensez que je veux dire - et je prendrai le temps d'écouter.
... Thème commun, Droite ... Communication ... Communication ... Communication.
Il n'y a vraiment pas de meilleur moyen de le mettre. Les développeurs sont cochés parce que "que DBA m'a dit que cela ne pouvait pas être fait - j'en ai vraiment prouvé la dernière fois." Les dabas se font cocher parce que "que le développeur ne comprend pas ce que je dois faire à chaque fois qu'il change ses spécifications."
Les développeurs et les DBA, comme @Rolando ont déclaré, doivent se comprendre. Quand tout cela revient, nous parlons tous les deux "Ones & Zeros" - vous penseriez que ce serait un bon match. Nous avons 2 domaines de responsabilité: Les DBA ont des données, les développeurs obtiennent le reste de l'ordinateur. Mais sans données, les programmeurs n'auraient vraiment pas beaucoup à faire.
Nous n'avons pas de DBA et il est parfois douloureux. Ce morceau de moi qui voulait être un dba il y a une décennie il y a une décennie quand je vois certaines des choses que nous faisons. Si nous avons embauché un DBA demain, je pense que j'embrasserais le terrain, il/elle marchait.
Au cours des nombreuses années, depuis que j'ai commencé avec SQL Server (1998), de nombreux développeurs me disent comment faire mon travail. Il est intéressant de dire qu'ils tous savent plus que moi aussi Superbe .NET Développeurs. En fait, ils architectes aussi et devraient faire plus de choses que le code monkeying.
Peut-être que c'est la mauvaise attitude de moi: mais c'est une attitude de développeur assez courante dans de nombreux magasins. Ils se font aussi, rappelez-vous: regarder les combats commencer lorsque vous suggérez des critiques de pairs.
Je laisserai les corrections à d'autres réponses (je suis d'accord à 100% avec le 2 jusqu'à présent), mais ajoutez que la gestion de la gestion et de la boutique Doit Support et collaboration aussi.
Dans certaines entreprises, peut-être beaucoup, le développement de produits a tendance à ignorer quiconque n'écrire pas dans une langue compilée. Venez le temps de relâchement, il y a une résistance car les administrateurs de réseau, les dabas, les administrateurs du système, le support utilisateur, etc. chacun a leur diligence raisonnable à compléter. Il y a souvent des maux de tête car les aspects clés de l'environnement n'étaient pas considérés. Cela provoque naturellement des tensions entre les équipes.
Qui est à blâmer ici? Mme Communication.
Les développeurs doivent comprendre que le code de l'environnement sera déployé. Les gens doivent avoir une avertissement équitable pour s'adapter. Lorsque l'environnement ne peut pas s'adapter à quelque raison que ce soit (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 heureux. Si cela ne commence pas avant le temps de déploiement, c'est un monde de blessures.
Oui, les équipes doivent parler (et écouter) l'autre, mais le chef/chef de produit doit créer un environnement cela peut arriver.
J'ai eu de la chance, dans la plupart des endroits où j'ai travaillé, le respect mutuel et la communication font partie de la culture.
Une chose qu'un bon dba doit comprendre est la politique des données. J'ai enseigné la programmation de la base de données et la conception des programmeurs chevronnés et quelques DBA rédigés depuis quelques années. Une question qui se poserait régulièrement était la suivante: comment se retrouve toutes les bases de données à ma boutique sont si politiques?
Voici ma réponse standard: si la base de données est utile, vous partagez des données. Si vous partagez des données, vous partagez le pouvoir. Lorsque le pouvoir est partagé, la politique se produit.
Peu importe que vous aimiez la politique ou la politique de la haine. Si vous allez faire de la bonne base de données, faites-vous vous y habituer.
Incidemment, certains d'entre vous n'ont travaillé que dans un environnement de développement. Il y a des dabas qui travaillent du côté de la production de la clôture et 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 belles bases de données de production ont tendance à être grandes et critiques d'entreprise.
Un peu d'humilité pourrait aider à certains d'entre vous. ;)
Il existe évidemment des arguments valables pour une approche, je vous suggère de commencer par reconnaître cela. Le développement de logiciels consiste à faire le bon compromis. S'il s'agit d'une rue à deux sens, peut-être que DBAS devrait également garder un esprit ouvert aussi.