1: use a distributed version management system
if you feel that you don't need to use a version management system, then there will be a generation gap in our communication, if you are a fan of cvs, svn, or have not used a distributed version management system for some reason, such as git, then it is strongly recommended that you go to see "why git is better than x".
2: one-click publishing
The target location for release here can be either a development machine for local testing, a test machine, a forest ready for QA to catch bugs; or a production environment (or beta environment) for direct user access.
like the deep xp one-click recovery system, one-click release needs to automate a lot of work: code automation testing (development stage), packaging and compression, compilation (testing stage), data synchronization (extranet). there may be a lot of work to add, but the core is whether all the processes can be completed with the execution of a single script, which is crucial. if there are a few more environments in the middle, it will definitely introduce a release disaster in the future.
3: Please be responsible for the code you wrote yourself
Don't, as long as you can get feedback on the operation of the code you wrote in time, and you don't need to cover the test case all at once. For code that doesn't have any unit tests, it will be difficult to introduce unit tests in the future! If, you think testing is all about QA, then you spend a lot of money to recruit a large QA group, hoping that they will make you lazy.
4: use a reliable bug recording tool
although the potential of the human brain is unlimited, the cerebral cortex only responds efficiently to data entering the buffer. no matter how good the memory is developed, it may also be tortured by various cow ghosts and ghosts to forget yesterday's pain (the bug that once occurred). therefore, from the first test of the team, it should use a reliable bug record to work. the so-called good memory is not as good as bad writing is this truth.
that one reliable bug logging tool should record this data:
- the entire operational process of bug recurrence
- normalcy in product demand
- after the bug appears, it becomes the situation
- who will be responsible for fixing this bug
- bugs were last fixed without
as for how to fix the bug, whether it is a redesign or a missed commit of the code, i think it does not matter. if the experience of fixing a bug is worth sharing, you can do a separate team technical sharing, which is often caused by insufficient access to the (technical or other) information of the existing product.
5: fix bugs as soon as possible
my development experience has taught me that the later a bug is fixed, the less likely it is to be fixed and the greater the likelihood of future harm. just think, the code you just tested or released, the bugs that appear, often you can get the fastest time to solve its needs, and time is very important in project management. on the other hand, if you accumulate a lot of bugs and have a certain amount of time, then fixing it requires an understanding of all the relevant systems, which will cost you a lot of good time that you can use for vacation and entertainment. so, implementing this from the beginning of the team can release the pressure on members to fix bugs.
6: give team members a quiet environment
Recently, many classmates told me that there is basically no efficiency during the day and they are always harassed by various kinds. Let's make a hypothesis: if it takes 30 minutes for Classmate A to get into his best shape, then if he is miserable, and he is always interrupted during the 30-minute interval, then he will not be able to work the most efficiently for a day. Or classmate B google query a technical question, it takes 2 minutes to solve, but ask classmate A as long as 20 seconds (well, classmate A is very clear). In this way, Classmate B saves 100 seconds, while Classmate A loses at least 30 minutes.
from this hypothesis, it is not difficult to find that if the team member can avoid being harassed by external information, he may be able to work more efficiently and write a better product. common sense tells us that people can't work efficiently all the time, so we should use the time that we can't concentrate on to communicate. but it is obviously very difficult to distinguish this boundary, so i think it is better to stipulate a quiet period of time every day, during which no one else can disturb the classmate, and during the non-quiet period, it can be visited at will, so that the classmate can form a new biological clock (the body's self-regulation ability is very strong).
7: give employees the best tools
Do the same thing, if you use tool A, the consumption time is 5 minutes, and with tool B, the consumption time is 1 minute, then I must provide the employee with tool B, even if the price of tool B is 5 times that of tool A. Because, if the resistance time of a person in continuous and efficient work is 1 minute, it means that tool B can ensure that the time of efficient work is continuous, while A will probably distract the user' energy, resulting in more time to enter the best state. In fact, the reason for better CPUs, bigger memory, better compilers, better editors, and multiple monitors is to get programmers back to the core business as quickly as possible and spend less time waiting.
at the same time, don't forget that a good chair is also a guarantee for longer and efficient working hours, so don't be stingy, give employees a better chair, they will feel your warmth.
No comments:
Post a Comment