[/b]. Managers, customers and programmers are becoming increasingly impatient. Everything that needs to be done needs to be done right away. Because of this, rapid repair becomes very urgent.
no time to conduct proper unit testing of a new function? Well, you can finish a test run first, and then you can come back and test it at any time.
will you encounter strange object reference errors when accessing the Y attribute? Anyway, put the code in the try/catch statement block. We're going to catch big fish!
is it a deja vu? That's because we've done it all the time. And in some cases, it is beyond reproach. After all, we have deadlines, and we have to meet customers and managers. But do not operate too frequently. Otherwise, you will find that your code is unstable, and there are many hot fix, logical repetition, untested programs and error handling. In the end, you can either get things done or finish things well.
[b] 6., and then [/b]
"agile development" has been frequently abused recently, often used by programmers to mask the bad planning / design phase of their software development. We are designers and we should be glad to see that the product has made substantial progress in the right direction. But it is surprising that UML diagrams and use case analysis do not seem to satisfy our wishes. So when we do not know what we are doing or where we are, our developers often write code in a confused way.
it's like you have to go to dinner, but you have no idea where to eat. Because you are too hungry, you can't wait to find a restaurant and make a table. Then you get on the train and drive along the road (looking for a place to eat). Just, it will take more time, because you're going to have more U bends, stop in front of the restaurant, and probably end up waiting too long to eat. To be sure, you should be able to find a place to eat at the end, but the meal you may eat is not what you want to eat, and the time it takes may take longer than a restaurant you want to go directly to.
[b] 7. if your only tool is a hammer, you tend to see all the problems as a nail [/b]
see? I have long said that dynamic records are very effective in this project.
programmers have a tendency to narrow their horizons when it comes to their tools. Once a method is "feasible" on one of our projects, we will use it in all subsequent projects. Learning new things seems to be a torment, sometimes even uneasy. From beginning to end, I was thinking, "if I do it in my previous way, this will not be so troublesome." We must discard this idea and do what we know, even if it is not the perfect solution.
stick to your own knowledge is very simple, but in the long run, choose a suitable tool for this job is much easier. Otherwise, you will be out of tune with your career.
[b]8. silence that agrees with
[/b]
[/b]I've seen nothing! I didn't see it!