[JAVA] Ce que j'ai appris avant un ingénieur système qui ne pouvait pas respecter la date de livraison était un peu fiable sans délai

en premier

Cet article a été publié car je n'ai pas pu respecter la date limite. Au moment où vous cessez de retarder et aidez vos juniors à retarder Décrivez ce que vous avez appris, ce que vous essayez de faire et ce que vous avez échoué. Je vous serais reconnaissant si vous pouviez le lire pour tuer le temps.

Hypothèse: combien n'a pas pu être fait

・ La fonction que je trouvais cool a été retardée d'une semaine et a été couverte de plus de bugs. ・ Le développement de la version prototype a pris trop de temps et a été retardé en raison de changements de spécifications. -Les fonctions que les utilisateurs voulaient n'étaient plus nécessaires presque en même temps qu'elles étaient terminées.

Le contenu de cet article est souvent subjectif et empirique. L'auteur est au mieux un ingénieur en milieu de carrière Par conséquent, le contenu de la description n'est pas toujours utile.

Ce que j'ai étudié

Négociation et estimation

** ・ Reconnaissez qu'une estimation précise du travail est "impossible". ** ** Avant de créer réellement une fonction, il est absolument confirmé que «tout ce qui peut être fait». À ce moment-là, même si vous pensez que vous pouvez le faire en n jours à partir de l'expérience passée, cela échoue généralement. C'est parce qu'il est rare de créer exactement la même fonction deux fois. Même si tu as fait quelque chose d'assez proche Il y a toujours une différence par rapport à la dernière fois. Et la plupart du temps, cela devient un gros goulot d'étranglement et meurt. Puisque vous devez faire une estimation à ce sujet, ** au moins le nombre de jours que vous pensez pouvoir + 2 jours doit être à l'envers ** (Souvent appelé un tampon.)

Surtout si vous êtes inexpérimenté ou si vous venez de changer d'emploi ou d'être envoyé et que vous ne connaissez pas le contenu du système Il est également efficace de dire: "Pourquoi l'avez-vous retourné pendant 5 jours?" ~~ C'est subjectif, mais je pense que c'est amusant quand tout le travail peut être parfaitement estimé. ~~

** ・ Combien de temps cela peut-il être fait? Lorsqu'on lui a demandé ** ** C'est en fait un gros piège. Ne répondez pas immédiatement. ** Tout d'abord, "Je vais chercher un peu - cela peut prendre environ un jour" Rendons les choses boueuses. Au contraire, quand vous êtes un leader, quand on vous répond rapidement sans être confus, si vous demandez un petit doute Souvent, le résultat était réussi.

** Tampon inversé estimé pour chaque modèle de développement ** Je n'ai d'expérience que dans le développement en cascade et le développement agile, donc je ne peux parler que de ces deux-là. ・ Pour le développement de la cascade, jusqu'à votre estimation + 5 jours ou délai ・ Pour le développement agile, jusqu'à la deuxième revue de sprint de la fonction dont vous êtes en charge Le taux d'accidents a été réduit en visant un état dans lequel 70% a été achevé après la moitié du temps. Ce serait encore mieux si les deux pouvaient être faits tout en recevant des suggestions appropriées. Si cela est difficile, vous pouvez faire des ajustements pour augmenter le nombre de personnes ou donner du temps à des experts.

Conception

** Répondez à toutes les exigences. Pensez seulement à ça. ** ** Contrairement au code source, les documents créés lors du processus de conception peuvent être livrés ou non. De plus, s'il est spécifié comme élément de livraison, le format est généralement fixe. ~~ Et le format est souvent médiocre. ~~ En d'autres termes, il y a un endroit pour faire des efforts, mais comment faire des efforts Pas ** pour faire un document sympa ** ** Solidifier l'image du processus de fabrication ou faciliter les choses dans le processus de fabrication ** Vous devez vous concentrer sur. D'après mon expérience, c'est bien d'avoir un document de conception de mise en page propre, Le contenu essentiel était trop pauvre et finalement une retouche s'est produite. Il y a eu plusieurs fois. Concurrencons le contenu. De plus, si d'autres membres fabriquent sur la base de celui créé ici, C'est mieux étant donné que la personne est facile à faire.

** Ne faites pas d'erreurs ou d'omissions typographiques ** Ceci est également bien fait, mais les erreurs typographiques et les omissions gaspillent plus d'efforts que vous ne pouvez l'imaginer. Document de conception avec des erreurs typographiques → Erreurs typographiques signalées dans les indications de révision → Corriger et réexaminer → Confirmer et terminer Et ** je ne peux pas garder un œil sur les échecs de conception et les omissions de conception que je devrais vérifier ** Dans de nombreux cas, vous subirez plus de dégâts que vous ne pouvez l'imaginer, ce qui est la cause du retravail = retard imminent. Porter une attention particulière. Si vous y réfléchissez par programme, c'est la même chose que de faire une demande d'extraction dans l'état d'une erreur de compilation.

** Permettre de légères différences d'apparence ** C'était au moment de l'examen, mais j'ai continué à le souligner sans permettre aucune différence d'apparence Je suis conscient que je ne serai pas un critique qui mange l'effort. Parce que, comme mentionné ci-dessus, le contenu est important et il y a une légère différence d'aspect. Il se termine à un niveau qui vous tient à cœur (à moins qu'il ne soit désigné comme une livraison). Par conséquent, il n'est pas recommandé de revoir avec l'esprit de souligner même si ce n'est pas le cas.

Fabrication

** Pincez et mangez différents paradigmes ** Par exemple, je gère principalement les backends en utilisant Java et Python, Les deux sont des langages appropriés pour les programmes orientés objet. (Les deux sont multi-paradigmes ces jours-ci) Ainsi, en apprenant les mérites de la programmation fonctionnelle à votre rythme habituel et en incorporant certains d'entre eux, Il peut être décrit de manière plus concise, et parce qu'il est concis, il y a peu de bugs et même si une erreur se produit lors de la fabrication C'est facile à gérer. Ce sont toutes de bonnes choses comme. Ici, je n'expliquerai pas l'idée ou les détails de la programmation fonctionnelle ~~ (je ne peux pas le faire car c'est trop profond) ~~ Si vous utilisez généralement un langage orienté objet -Si la valeur transmise à l'argument est la même, la valeur renvoyée est également la même. -Réaffecter les variables le moins possible 2 points ・ Utilisez abondamment les fonctions de la bibliothèque standard Le simple fait d'en être conscient réduira considérablement la difficulté du post-processus.

sample.java


    //Processus basé sur l'argument passé. Si l'argument est Hello, le résultat sera toujours HelloWorld.
    //Il est facile à tester car le résultat peut être connu en fonction de la valeur de l'argument. (Le nombre magique est ton amour)
    public String convertGreetingMsg(String msg) {
        return msg + "World";
    }

    //Processus basé sur la valeur d'entrée. Puisque la valeur change en fonction de la valeur d'entrée, elle a tendance à être un foyer de bogues.
    //Si vous devez utiliser ces fonctionnalités, il devrait y avoir une conception plus efficace
    public String convertGreetingMsg(String msg) {
        Scanner inputScanner = new Scanner(System.in);
        return msg + inputScanner.toString();
    }

    //Si vous connaissez le contenu de la méthode que vous appelez, vous pouvez le voir en le regardant.
    //Même si un bug se produit, la cause est facile à comprendre en regardant simplement ce qui est passé en argument
    public int sumNumberStream(List<Integer> numList) {
        return numList.stream().mapToInt(Integer::intValue).sum();
    }

    //Quiconque connaît la syntaxe de base peut la lire, mais ce qu'ils font s'ils ne lisent pas le processus une fois
    //Relativement déroutant
    public int sumNumberLoop(List<Integer> numList) {
        int sumResult = 0;
        for (Integer num : numList) {
            sumResult += num.intValue();
        } 
        return sumResult;
    }

** Touchez d'autres langues non utilisées dans la pratique ** C'est peut-être une évidence pour les ingénieurs, mais comme ci-dessus En sachant "ce que vous ne savez pas", vous pouvez créer votre code source habituel plus rapidement. Il ne fait aucun doute que la qualité s'améliorera. En apprenant Python tout en développant en Java et en apprenant les idées de Python J'ai eu une meilleure compréhension de Java et un codage plus facile. Un cas, il semble qu'il ne soit pas directement lié au "maintien de la date de livraison", L'amélioration de la qualité pendant le développement réduit les erreurs et le manque de considération, ce qui entraîne une réduction des effectifs. Recommandé pour ceux qui ne voient généralement pas d'autres langues.

sample.py


	''' 
Si vous écrivez le Java ci-dessus en Python ...
C'est un peu parce que l'exemple est mauvais, mais je remarque que Python est plus court car il n'y a pas de type
Mais je veux un moule ...
	 '''
	def convertGreetingMsg(msg) :
		return msg + "World";

	'''
	stream()Et mapToInt()Il est plus facile de comprendre ce que vous faites que le montant de la diminution
	'''
	 def sumNumberFunc(numList) : 
		return sum(numList);

À la fin

C'est mon avis et je ne pense pas que cela s'applique à tout le monde. Cependant, si vous avez du mal à respecter la date de livraison, quel processus pouvez-vous échouer? Si vous analysez s'il y en a beaucoup, et sachez que c'est écrit ici en fonction du résultat Il n'y aura aucun retard et on peut compter sur vous. ~~ Nous ne garantissons pas. ~~

Recommended Posts

Ce que j'ai appris avant un ingénieur système qui ne pouvait pas respecter la date de livraison était un peu fiable sans délai
Machine learning putain d'amateur que j'ai appris en 2 mois jusqu'à la sortie du produit
Lors de l'écriture dans un fichier csv avec python, une histoire que j'ai fait une légère erreur et n'a pas respecté la date de livraison