Les problèmes qui surviennent dans le processus de production attirent progressivement l'attention des cadres intermédiaires et supérieurs. Que vous soyez développeur ou architecte, vous devez accorder suffisamment d’attention aux éléments suivants pour éviter de vous retrouver dans des situations embarrassantes à l’avenir. Vous pouvez également l'utiliser comme note de dépannage.
#1. N'externalisez pas les propriétés de configuration dans les fichiers de propriétés ou les fichiers XML. Par exemple, le nombre de threads utilisés par le traitement par lots n'est pas défini pour être configurable dans le fichier de propriétés. Votre programme batch peut fonctionner correctement que ce soit dans un environnement DEV ou dans un environnement UAT (User Acceptance Test), mais une fois déployé sur PROD, lorsqu'il est utilisé comme programme multithread pour traiter des ensembles de données plus volumineux, une exception IOException sera levée. , soit à cause des différentes versions du pilote JDBC, soit à cause du problème évoqué au point 2. Si le nombre de threads peut être configuré dans un fichier de propriétés, il devient très simple d'en faire une application monothread. Nous n’avons plus besoin de déployer et de tester des applications à plusieurs reprises pour résoudre des problèmes. Cette méthode convient également à la configuration de l'URL, du serveur et du numéro de port, etc.
# 2. La taille de l'ensemble de données utilisé dans le test est inappropriée. Par exemple, un scénario typique pendant la production consiste à utiliser seulement 1 à 3 comptes pour les tests, alors que leur nombre devrait être compris entre 1 000 et 2 000. Lors des tests de performances, les données utilisées doivent être réelles et non recadrées. Les tests de performances qui ne sont pas proches de l'environnement réel peuvent entraîner des problèmes imprévisibles de performances, d'expansion et de multithread. Ce n'est qu'en testant l'application avec un ensemble de données plus important que vous pourrez garantir qu'elle fonctionne correctement et qu'elle répond aux SLA (normes de niveau de service) pour les attributs non fonctionnels.
#3. Croire naïvement que les services externes et internes appelés dans l'application sont fiables et toujours disponibles. Ne pas autoriser les délais d'attente et les tentatives d'appel de service affectera négativement la stabilité et les performances de l'application. Des tests de panne de service appropriés sont nécessaires. Ceci est important car les applications actuelles sont pour la plupart distribuées et orientées services, nécessitant un grand nombre de services réseau. Demander sans cesse des services indisponibles peut nuire à votre application. L'équilibreur de charge doit également être testé pour s'assurer qu'il fonctionne correctement afin de maintenir l'équilibre de chaque nœud.
# 4. Les exigences minimales de sécurité ne sont pas respectées. Comme mentionné ci-dessus, les services réseau sont omniprésents, ce qui permet aux pirates informatiques de les exploiter facilement pour mener des attaques par déni de service. Par conséquent, lorsque vous utilisez Secure Sockets Layer, vous devez effectuer une vérification de base et effectuer des tests d’intrusion à l’aide d’outils tels que Google skipfish. Non seulement une application non sécurisée menace sa propre stabilité, mais elle peut également avoir un impact négatif sur la réputation d'une entreprise en raison de problèmes d'intégrité des données, comme par exemple une situation dans laquelle le client « A » peut consulter les données du client « B ».
#5. Aucun test de compatibilité entre navigateurs. Les applications Web d'aujourd'hui sont pour la plupart des applications riches d'une seule page qui utilisent le langage de programmation JavaScript et des frameworks comme Angular JS. Pour que le site Web que vous créez fonctionne correctement sur différents appareils et navigateurs, vous devez mettre en œuvre une conception correspondante. Ainsi, pour garantir que votre application fonctionne sur tous les appareils et navigateurs, sa compatibilité doit être testée.
# 6. Ne pas externaliser les règles métier qui peuvent changer fréquemment. Par exemple, les lois fiscales, les exigences gouvernementales ou liées à l'industrie, les taxonomies, etc. Vous pouvez utiliser un moteur comme Drools pour traiter les règles métier, ce qui vous aide à externaliser ces règles métier en les stockant dans une base de données ou Excel. Une fois que les entreprises maîtrisent ces règles commerciales, elles peuvent répondre rapidement aux lois fiscales ou aux exigences connexes avec un minimum de modifications et de tests.
#7. Les documents suivants ne sont pas fournis
En plus du COS (Conditions de Satisfaction), un formulaire créé par MindMap, il existe deux formulaires de documents principaux en développement agile , 1 et 2.
# 8. Ne pas avoir de plan de reprise après sinistre ni de stratégie de surveillance et d'archivage du système. À mesure que les échéances des projets approchent, ces éléments sont souvent oubliés dans la précipitation pour déployer le projet. Ne pas mettre en place une surveillance adéquate du système avec Nagios et Splunk menace non seulement la stabilité de votre application, mais entrave également les diagnostics actuels et les efforts d'amélioration futurs.
#9. Il n'existe pas de conception de colonne pratique pour la table de base de données , telle que create_datetm, update_datetm, create_by, update_by et timestamp. Elle ne fournit pas non plus de colonnes d'enregistrement de suppression ordonnée, telles que la colonne "supprimée" qui peut prendre "Y" ou. 'N'. Ou vous pouvez prendre la colonne 'record_status' de 'Actif' ou 'Inactif'.
# 10. Échec de l'élaboration d'un plan de retracement approprié. Par conséquent, lorsque le système tombe en panne, il n’existe aucun moyen de restaurer le système à un état stable avant le déploiement. Ce plan doit être soigneusement étudié et signé par l'équipe concernée. Les plans incluent le retour à une version précédente du logiciel, la suppression de toutes les données insérées dans la base de données et de toutes les entrées du fichier de propriétés.
# 11. Échec de l'élaboration d'un plan de capacité avant le début du projet. Aujourd'hui, lorsqu'on décrit les exigences d'une plate-forme, il ne suffit pas de simplement dire « nécessite un ordinateur Unix, un serveur de base de données Oracle et un serveur d'applications JBoss ». Votre demande doit être précise
#12 ci-dessous provient d'un commentaire de "David DeCesare" de "java.dzone",
# 12. "N'utilisez pas le meilleur outil pour le travail." Dans de nombreux cas, les développeurs utiliseront un langage ou un outil qu’ils souhaitent apprendre dans un système de production. Ce n’est généralement pas la meilleure option. Par exemple, utiliser des bases de données NoSQL pour des données déjà réellement relationnelles. N'oubliez pas que quel que soit l'outil que vous adoptez, vous devrez entretenir votre produit pendant les 3 à 5 prochaines années (voire plus).
#13. Manque de réserves de connaissances suffisantes dans 16 domaines techniques clés. Ces domaines incluent l'identification et la résolution 1) des « problèmes de concurrence », 2) des problèmes de transaction et 3) des problèmes de performances. Dans de nombreux entretiens, je me suis appuyé sur ces trois aspects des connaissances pour décrocher de nouveaux contrats.