Quelles sont les pires choses auxquelles les développeurs inexpérimentés oublient de penser? [fermé]

En tant que jeune développeur, je trouverais utile d'obtenir des conseils sur les choses à penser pour développer une application de haute qualité. Dans mes cours universitaires, la plupart des enseignants ont mis l'accent sur la validation des entrées et certains ont parlé de problèmes de sécurité, mais personne n'a couvert l'importance de certaines autres choses, comme la journalisation par exemple.

Quelles sont les erreurs que les développeurs inexpérimentés ont tendance à commettre et qui pourraient être source de frustration pour les développeurs plus expérimentés?

Je trouve que la principale chose que les nouveaux développeurs oublient, c'est que dans le monde réel, ils travaillent souvent en équipe. Cela se montre comme ..

• Archiver du code qui rompt la construction
• Ne pas réutiliser le code qui existe déjà
• Faire les choses à sa manière plutôt que de la même manière que tout le monde - ce qui rend la maintenance coûteuse

Cela ne veut pas dire que leur code n'est pas à la hauteur de manière isolée, mais ils ne fonctionnent plus de manière isolée.

1. Tests.
2. Tests.
3. Plus de tests.
4. Contrôle de source
5. Taxes adaptées au programme que vous ciblez.

Sous Windows, ces taxes sont :

• Gérer les environnements à haute résolution
• Profils d'utilisateurs itinérants
• Changement rapide d'utilisateur
• Bureau à distance (par exemple, vous ne voulez pas utiliser la double mise en mémoire tampon lorsque RDP est en vigueur
• Bien jouer avec la gestion du stockage hiérarchique
• Moniteurs multiples
• Windows 64 bits

Sur à peu près toutes les plateformes, vous devrez gérer:

• Unicode
• Localisation
• Gestion de puissance

D'après mon expérience, la seule chose que presque tous les développeurs inexpérimentés ne gardent pas à l'esprit est que vous travaillez (presque toujours) dans un environnement commercial. Votre code doit être bon, mais pas parfait. La chose la plus importante n'est pas la perfection, c'est que votre code est expédié.

En d'autres termes, livrer le morceau de code parfait trois mois après la faillite de votre entreprise n'est bon pour personne.

À mon avis, c'est l'une des façons les plus importantes dont le développement dans le monde réel diffère du développement tel qu'il est enseigné à l'université.

Question vraiment large; répondre en détail est ... plusieurs livres.

Voici une liste de contrôle générale de définition des systèmes pour vous aider à démarrer -

• Quelles sont les ressources critiques du système et comment les exigences qui en découlent pourraient-elles changer?
• Quelles sont les capacités de performance du système et comment pourraient-elles avoir besoin de croître?
• Quels domaines d'exigence pourraient devenir inutiles et amovibles?
• Existe-t-il la possibilité d'avoir besoin de différentes versions du système avec des capacités différentes?
• Quelles sont les implications sur les ressources humaines et informatiques si les changements identifiés se produisent?
• Quel impact le nouveau système aura-t-il sur les systèmes d'exploitation existants?
• Quels domaines de fonction ont le plus de chances d'exiger des changements à la lumière de l'expérience avec le système?
• Qui sont les futurs utilisateurs du système?
• Quels sont les futurs mainteneurs du système?
• Quelles sont les améliorations futures que les futurs utilisateurs du système peuvent identifier comme probables?
• Comment le système s'intègre-t-il dans les plans globaux de l'utilisateur et comment devrait-il évoluer?

Le découplage net du système sur sa machine de développement, et la machine cible, pour que l'on ne se retrouve pas dans des situations "Eh bien, ça marche sur ma machine".

Et à quelle vitesse pouvez-vous reconstruire votre machine de développement?

• Connaissez-vous les packages dont vous avez besoin?
• Avez-vous une solution à bouton-poussoir pour reconstruire votre base de données?
• Avez-vous une solution à bouton-poussoir pour tester l'intégrité du code source?

Je pense que c'est probablement la conception - c'est-à-dire l'approche de penser à ce que vous allez faire avant de le faire.

Trop de codeurs inexpérimentés (rappelez-vous quand vous avez commencé) aiment se lancer et faire avancer les choses, puis en ajouter un peu plus et ajouter un peu plus et en ajouter un peu plus. Cette approche peut fonctionner si vous avez prévu de le faire de cette façon (chaque bit peut être testé au fur et à mesure), mais la plupart des codeurs inexpérimentés ne se concentrent que sur la partie qu'ils écrivent .. donc tous les ajouts ont tendance à être piratés en haut. Et nous avons tous vu du code qui a évolué comme ça!

L'organisation est la chose suivante, souvent ils sont trop concentrés sur le code qu'ils ont écrit pour se rappeler comment ils l'ont fait et ce qui était nécessaire. Ils oublient donc de regrouper ou de documenter une dépendance requise. Ils ont également tendance à mettre les choses où ils tombent, j'ai dû critiquer un junior la semaine dernière qui a vérifié son code dans le répertoire racine, y compris 3 wsdls, dont 2 étaient le même fichier, et un ensemble de dll tiers qu'il a commis dans un sous-répertoire et le répertoire racine. Le code n'était pas formaté selon une norme que vous pourriez imaginer non plus, et il y avait plusieurs fonctions présentes mais jamais appelées.

De toute évidence, il l'a fait fonctionner, mais ce n'était pas bien rangé, ce qui signifiait que l'installation et la maintenance auraient été gênantes.

Je pense que les plus grandes différences sont dans la technique de codage. Tout le monde a une approche légèrement différente, mais les développeurs inexpérimentés ont tendance à produire du code qui:

• ne gère pas les cas limites
• est beaucoup plus long que nécessaire
• présente de mauvaises caractéristiques de performances dans les scénarios pertinents
• a une mauvaise séparation des préoccupations
• manque de techniques d'autoprotection comme l'utilisation de const, scellé, en lecture seule, etc.
• façons bizarres de renvoyer des données et des collections de données
  • cela démontre davantage l'inexpérience avec une plate-forme

Parce que vous avez demandé les pires choses, ma réponse est la suivante:

1. Vous avez oublié de penser à désinfecter la machine de développement contre les spywares, les malwares et les virus de Troie.
2. Vous avez oublié de faire une sauvegarde régulière enregistrée dans des stockages sécurisés situés à différents emplacements géographiques.

Mon plus grand se souvient de planifier la flexibilité. En classe, les exigences sont presque toujours énoncées au début et ne changent jamais. Dans le logiciel, c'est souvent le contraire: vous obtenez un vague ensemble d'exigences, et elles changent souvent (même quotidiennement). La meilleure chose que vous puissiez faire pour aider à cela est de coder de manière flexible: couplage lâche, petites fonctions qui peuvent être utilisées de manière fiable dans plusieurs situations, et en évitant autant que possible de coder en dur.

Avec le temps, vous apprendrez probablement a) quelles sont les choses les plus susceptibles de changer, et inversement ce qui ne changera probablement pas, et b) comment anticiper les demandes de changement et les planifier.