Date/Heure et Internationalisation pour les applications d'entreprise -- Directives de développement

Question

Avec un autre développeur, je me suis lancé dans la création d'une application hébergée de type CRM qui s'adressera aux entreprises. Ces entreprises auront accès à notre application à distance et la nature hébergée de l'application nécessitera donc certaines fonctionnalités. Par exemple, pour garantir un niveau de service professionnel, les choses suivantes doivent être vraies :

• l'internationalisation nécessite plusieurs langues et la présentation de la date et de l'heure pour différents fuseaux horaires et lieux.
• capacité transactionnelle pour le traitement par lots des tâches et capacités de retour en arrière
• les problèmes de sécurité pour préserver la sécurité des données et la protection des invocations à distance contre les attaques
• etcetera, la liste est longue.

En raison de ces préoccupations et de mon rôle de développeur le plus responsable du développement côté serveur, je suis très intéressé par les choix que je fais dès le début. En ce qui concerne les fuseaux horaires et les langues par exemple, y a-t-il des problèmes liés à mon choix de base de données ou de champs de données ? Est-ce que je choisis d'utiliser un horodatage ou un champ de date UTC dans toute l'application et, dans ce cas, existe-t-il un format standard pour cela ? De même, en ce qui concerne les différentes langues, dois-je m'assurer que les données sont stockées dans la base de données en UTF-8 ou unicode ?

Je veux vraiment éviter de mettre en place l'infrastructure du système pour découvrir plus tard qu'une décision fondamentale était incorrecte ou pas assez grande, assez large, assez intelligente, etc. Quelqu'un peut-il m'indiquer la voie à suivre en ce qui concerne ces décisions fondamentales "précoces" ?

EDIT _ Ok j'apprécie les réponses larges et maintenant je vois que ma question était un peu trop peu spécifique. J'aimerais me concentrer sur les éléments plus spécifiques qui étaient présents dans la question, comme par exemple comment choisir le format approprié pour stocker une date/heure UTC ou comment sauvegarder mes données texte (dois-je spécifier un format UTF ?).

Answer 1

Si vous visez le CRM d'entreprise, vous aurez besoin d'un très haut niveau de personnalisation et d'intégrations avec toutes sortes de systèmes. Vous ferez des erreurs dans la conception. Votre seul espoir est d'isoler chaque petit morceau de code afin d'avoir une chance de le corriger plus tard.

En bref, les principes de base de l'ingénierie logicielle sont votre meilleur atout.

Answer 2

Comme vous n'avez pas mentionné ce que vous pensez de la question, vous trouverez peut-être ma réponse, ou des parties de celle-ci, plutôt basique.

1. Si vous n'en avez pas besoin, n'utilisez pas un langage de bas niveau. J'utiliserais généralement python pour la première version d'une application CRM (avec l'espoir qu'il soit suffisamment bon pour les versions suivantes), mais cette décision dépend aussi de la communauté du domaine.
2. Essayez d'écrire vous-même le code minimal, au lieu de vous reposer sur les bibliothèques de tiers. Les gens peuvent ne pas être d'accord sur ce point, mais j'écrirais le code moi-même en dernier recours. Mais le point suivant est important.
3. Lors du choix d'une bibliothèque ou d'un cadre de travail, assurez-vous de la pérennité du parti qui la soutient, de la stabilité de la bibliothèque et de l'adéquation de la licence du logiciel à vos besoins.
4. D'autres règles générales s'appliquent : se concentrer sur le client, utiliser l'intégration/les tests continus, etc., utiliser les bonnes pratiques logicielles comme la journalisation, etc.

Answer 3

Rien n'est jamais stocké en tant qu'"unicode", car il s'agit d'un concept abstrait. L'unicode est toujours stocké dans une sorte de format de transformation unicode (UTF) (ou bien UCS mais je n'ai jamais vu cela utilisé quelque part). L'UTF le plus couramment utilisé est l'UTF-8 mais je suggère d'utiliser le format natif/par défaut de votre plateforme. wikipedia

Answer 4

Ce dont vous parlez est appelé une application multi-locataires dans laquelle la même base de code est utilisée par plusieurs clients (locataires) avec une séparation logique ou physique des données. Rappelez-vous la règle fondamentale du développement : la flexibilité est liée à la complexité. Plus vous rendez le système flexible, plus il sera compliqué.

RE : UTC

Pour une application de gestion de la relation client (CRM) qui stocke des éléments tels que le moment où les appels ont été passés et celui où les réunions ont eu lieu, je stockerais certainement tous ces éléments en UTC et laisserais l'utilisateur définir son fuseau horaire local. Cependant, il se peut que vous rencontriez des dates qui ne tiennent pas compte du fuseau horaire et pour celles-ci, je stockerai la date qui a été saisie.

RE : Unicode

Oui, j'utiliserais Unicode pour toutes les données saisies par l'utilisateur. Cependant, cela ne vous permettra pas d'obtenir la localisation. Si, par exemple, pour une seule entreprise, vous avez un utilisateur à Hong Kong qui entre du texte en chinois et un utilisateur à Amsterdam qui entre du texte en néerlandais, vous n'obtiendrez pas de traduction automatique. Des éléments tels que les dates et les formats de chiffres peuvent être localisés, mais le texte brut, comme les noms utilisés dans les listes déroulantes et autres, peut être une corvée de localisation.