This article has been published since I was unable to meet the deadline. By the time you stop delaying and help your juniors delay Describe what you have learned, what you are trying to do, and what you have failed. I would appreciate it if you could read it to kill time.
・ The function that I thought was cool was delayed by one week and was covered with bugs. ・ It took too much time to develop the prototype version, and it was delayed due to specification changes. -The functions that users wanted were no longer needed almost at the same time as they were completed.
The content of this article is often subjective and empirical. The author is a mid-career engineer at best Therefore, the description content is not always helpful.
** ・ Recognize that accurate man-hour estimation is "impossible". ** ** Before actually creating a function, it is absolutely confirmed that "how much can be done". At that time, even if you think that you can do it in n days from past experience, it usually fails. This is because it is rare to create the exact same function twice. Even if you've done something pretty close There is always a difference from the last time. And most of the time, it becomes a big bottleneck and dies. Since you have to make an estimate in that, ** at least the number of days you think you can + 2 days should be upside down ** (It is often called a buffer.)
Especially if you are inexperienced or have just changed jobs or been dispatched and do not know the contents of the system It is also effective to say, "Why did you turn it upside down for 5 days?" ~~ It's subjective, but I think it's fun when all the work can be estimated perfectly. ~~
** ・ How long can it be done? When asked ** ** It's actually a big trap. Don't answer immediately. ** First of all, "I'll look it up a bit-it may take about a day" Let's make it muddy. On the contrary, when you are a leader, when you are answered promptly without being muddy, if you ask a little doubt Often the result was successful.
** Estimated upside down buffer for each development model ** I have only experience in waterfall development and agile development, so I can only talk about those two. ・ For waterfall development, your estimate + 5 days or up to the deadline limit ・ For agile development, until the second sprint review of the function you are in charge of The accident rate was reduced by aiming for a state in which 70% of the cars were completed after halfway through. It would be even better if both could be done while receiving appropriate suggestions. If that is difficult, you can make adjustments to increase the number of people or give time to experts.
** Meet all requirements. Only think about that. ** ** Unlike the source code, the document created in the design process may or may not be delivered. Also, if it is specified as a delivery item, the format is usually fixed. ~~ And the format is often poor. ~~ In other words, there is a place to put effort, but how to put effort Not ** creating cool documentation ** ** Solidify the image of the manufacturing process, or make things easier in the manufacturing process ** You need to focus on. As for my experience, it's nice that it made a design document with a beautiful layout, The essential content was too poor and eventually a rework occurred. There were several times. Let's compete with the contents. Also, if other members manufacture based on the one created here, It's better considering that the person is easy to make.
** Do not make typographical errors or omissions ** This is also done well, but typographical errors and omissions waste more man-hours than you might imagine. Design document with typographical errors → Typographical errors are pointed out by review indication → Correct and re-review → Confirm and finish And ** I can't keep an eye on design failures and design omissions that I should check ** In many cases, you will suffer more damage than you can imagine, which is the cause of rework = approaching delay. Pay close attention. If you think about it programmatically, it's the same as making a pull request with a compile error.
** Allow slight differences in appearance ** This was at the time of the review, but I continued to point out without allowing any difference in appearance, I am aware that I will not be a reviewer who eats up man-hours. Because, as mentioned above, the contents are important, and there is a slight difference in appearance. It ends at a level that you care about (unless it's designated as a delivery). Therefore, it is not recommended to review with the spirit of pointing out even if it is not.
** Pinch and eat different paradigms ** For example, I usually mainly handle backends using Java and Python, Both are suitable languages for object-oriented programs. (Both are multi-paradigm these days) So, by learning the merits of functional programming in your usual time and incorporating some of them, It can be described more concisely, and because it is concise, there are few bugs and even if an error occurs during manufacturing It's easy to deal with. It is all good things like. Here, I will not explain the idea or details of functional programming ~~ (I can not do it because it is too deep) ~~ If you usually use an object-oriented language -If the value passed to the argument is the same, the returned value is also the same • Minimize variable reassignment With two points ・ Use the functions of the standard library abundantly Just being aware of this will significantly reduce the difficulty of the post-process.
sample.java
//Process based on the passed arguments. If the argument is Hello, the result will always be HelloWorld.
//It is easy to test because the result can be known depending on the value of the argument. (The magic number is your love)
public String convertGreetingMsg(String msg) {
return msg + "World";
}
//Process based on the input value. Since the value changes depending on the input value, it tends to be a hotbed of bugs.
//If you have to use these features, there should be a more efficient design
public String convertGreetingMsg(String msg) {
Scanner inputScanner = new Scanner(System.in);
return msg + inputScanner.toString();
}
//If you know the contents of the method you are calling, you can see it by looking at it.
//Even if a bug occurs, the cause is easy to understand by just looking at what is passed as an argument
public int sumNumberStream(List<Integer> numList) {
return numList.stream().mapToInt(Integer::intValue).sum();
}
//Anyone who knows the basic syntax can read it, but what they do if they don't read the process once
//Relatively confusing
public int sumNumberLoop(List<Integer> numList) {
int sumResult = 0;
for (Integer num : numList) {
sumResult += num.intValue();
}
return sumResult;
}
** Touch other languages not used in practice ** It may be a matter of course for engineers, but as above By knowing "what you don't know", you can create your usual source code faster. There is no doubt that the quality will improve. By learning Python while developing in Java and learning the ideas of Python I've had a better understanding of Java and easier coding. One case, it seems that it is not directly related to "keeping the delivery date", Quality improvement during development reduces error occurrence and lack of consideration, resulting in reduction of man-hours. Recommended for those who don't usually read other languages.
sample.py
'''
If you write the above Java in Python ...
It's a little because the example is bad, but I notice that Python is shorter because there is no type
But I want a mold ...
'''
def convertGreetingMsg(msg) :
return msg + "World";
'''
stream()And mapToInt()It is easier to understand what you are doing than the amount of decrease
'''
def sumNumberFunc(numList) :
return sum(numList);
This is my opinion and I don't think it applies to everyone. However, if you are having a hard time keeping the delivery date, what process can you fail? If you analyze whether there are many, and be aware that it is written here according to the result There will be no delay and you may be relied on. ~~ We do not guarantee. ~~
Recommended Posts