Partager certaines de mes propres expériences en matière de développement d'entreprise

Je ne sais pas si le mot principe dans ce titre est correct ou non. Laissez-moi l'appeler principe. Pour ceux d'entre nous qui écrivent du code, j'appellerai cela un standard plus tard, mais après y avoir réfléchi, pour d'autres aspects, cela peut être un principe, d'accord, ne vous emmêlez pas et allez directement au sujet.

Je suis dans la nouvelle entreprise depuis plus d'un mois. Le jour de mon arrivée était le début d'une itération. Jusqu'à hier, la version backend avait été synchronisée avec le réseau public. car il fallait le revoir, mais le test interne Il bat également son plein. Je viens de passer à un autre environnement, et le modèle de développement, les spécifications du code, le mode de soumission du code, etc. dans le nouvel environnement sont tous nouveaux. La chose la plus profonde chez moi est naturellement la méthode de soumission du code. Je suis habitué à la méthode de révision de code précédente. Après être venu ici, il n'y a pas de tel mécanisme obligatoire, donc je me laisse un peu aller. À cause de cela, je me suis détendu.

Le prix du laxisme est un peu tragique. Ce n'est qu'hier, à la veille du lancement de la version, que j'ai vraiment compris que beaucoup de choses nécessitent des principes, des règles et des standards. Sans règles, il n'y a pas de cercle. Sans normes, le code ne peut pas être qualifié de bon. Je développe des produits pour Android, donc naturellement je ne peux pas produire une bonne application. Permettez-moi d’abord de parler de réglementation, de mon point de vue. Du point de vue des normes de programmation, en particulier des normes de programmation Java, les pointeurs nuls sont l'un des problèmes les plus courants si un champ est ajouté à l'arrière-plan, mais que la version APP souhaite d'abord se connecter à l'ancien arrière-plan et comparer les fonctions avant et après. , cela n'a pas été fait pour le moment. Après avoir entré les paramètres pour juger, vous pouvez imaginer quel sera le résultat, l'APP plante. Si le jugement est porté, alors OK, du moins du point de vue de l'expérience utilisateur, l'APP n'a pas de problèmes fatals. Cependant, la saisie du jugement des paramètres n'est qu'une étape. Sans juger nul, cela peut également l'empêcher de planter. Il s'agit d'une astuce que l'on peut trouver sur Internet et qui utilise des constantes comme condition préalable au jugement. En fait, quand j'ai écrit ce paragraphe, les camarades de classe qui l'ont lu ont dû penser qu'une chose aussi simple était facile, et c'était bien. Cela signifiait que j'étais stupide pour cette petite erreur. C’est aussi le premier sentiment profond que j’ai ressenti après mon retour à la maison hier. Ce n’est pas que tu ne sais pas ou que tu ne comprends pas, mais que tu n’as pas fait attention et qu’un petit détail a provoqué un meurtre.

Les jugements non nuls et les exceptions hors limites des tableaux sont des problèmes qui surviennent facilement en Java et en C. Je me souviens que dans l'équipe de projet précédente, il y avait des réglementations militaires pour Java et C. Ces erreurs de bas niveau devaient être éliminées. Un bon moyen d'éviter cela est la révision du code. Même une entreprise aussi géniale que Google doit le faire, sans parler de nous. Je me souviens que lorsque je suis arrivé dans l'entreprise de Hangzhou, mon collègue m'a demandé de faire une évaluation. Je n'ai pas répondu pendant un certain temps. Plus tard, je me suis progressivement familiarisé avec le processus et j'ai répertorié certaines erreurs courantes comme conditions préalables à l'évaluation. J'ai lu de nombreux articles sur la soupe au poulet sur Internet et l'importance des critiques a été mentionnée à plusieurs reprises. Lire davantage sur les codes des autres est également un moyen d'améliorer vos capacités. La révision du code était autrefois un must pour l'équipe de projet, mais maintenant, comme elle n'est pas appliquée, je me suis relâché et il y a des problèmes avec le code lorsque la nouvelle version est mise en ligne. En fait, je peux également me soustraire à cette responsabilité. Il y a eu une erreur dans le backend lors du lancement de la version. Il a fallu trois restaurations pour la corriger. Cependant, certains paramètres n'étaient toujours pas configurés, ce qui a entraîné une configuration incorrecte et des paramètres incorrects obtenus. par l'APP. Logiquement parlant, dans une situation où l'APP et le backend sont fortement liés, je l'ai en fait confirmé avec le backend auparavant, mais la raison est irrésistible, donc cela ne veut pas dire que les collègues backend vous disent qu'il n'y aura pas de problème, vous doit être convaincu à 100%, c'est aussi un problème. Ce type de capacité d'auto-jugement vous oblige à respecter strictement vos propres normes et principes de programmation internes. Peu importe quand et où, vous devez élaborer un plan complet pour l'APP. et garantir l’expérience utilisateur.

La première fois que j'ai participé au lancement d'une nouvelle version de l'entreprise, le client a rencontré un crash causé par le fait que les paramètres d'entrée n'étaient pas jugés comme non vides et que la longueur du tableau n'était pas jugée. En fait, cela s'était produit auparavant. Opérations nécessaires, cette fois, le problème était entièrement dû au fait que je ne l'avais pas suivi strictement. Heureusement, il n'a été que pré-lancé et le problème a été résolu en interne. Je ne connais pas grand-chose aux problèmes d'arrière-plan, mais je sais que cela a été annulé à plusieurs reprises. Heureusement, c'était sous contrôle et il n'y avait aucun danger. Pour autant que je sache, la plupart des problèmes de back-end sont dus au fait que la configuration n'est pas synchronisée et que le code n'est pas synchronisé en ligne. Soudain, j'ai découvert un problème courant : le jour du lancement de la version que j'ai rencontrée, le développement était en pleine alerte. Il y avait toujours des problèmes, petits ou grands, que ce soit lors du déploiement ou lorsque l'APP était soudainement testée. je sais si quelqu'un a vécu ça, haha.

Pour l'avoir vécu pour la première fois, je connais aussi la routine. Je souhaite également partager une autre de mes sensations. Fabriquer des produits est une affaire très sérieuse. Je me souviens encore que lorsque je développais avec plusieurs nouveaux collègues, parce que l'un d'eux se relâchait, le patron du groupe disait devant tout le monde lors de la réunion du matin : Notre développement de produits ne sera plus comme le projet de fin d'études à l'école. . Oui, tout le monde doit être conscient du produit. Depuis, j'ai gardé cette phrase en tête, mais malheureusement, je ne l'ai pas bien fait moi-même, surtout lorsqu'il s'agit d'écrire du code, et j'ai perdu la conscience du produit dans ma relaxation personnelle. Pour fabriquer un produit, écrire du code n'est qu'une des choses. Il y a aussi l'analyse des besoins, l'évaluation des besoins, et même des organigrammes, etc. Je vais tirer le meilleur parti de ce que j'ai appris au cours des trois dernières années pour améliorer le produit. . J'ai aussi utilisé l'expérience de sortir une version pour la première fois pour me prévenir, ne perdez pas le principe de tout ce que vous jetez, sinon ce que vous ferez toujours n'est qu'une application, pas un produit.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!