This article is excerpted from "Flash MX professional 2004 Step 1》 (Written by Chen Bing)
Chapter 18 Understanding Programming Work in Flash
Mom, this door is so majestic and brilliant. Where does it lead to?
Baby, it leads to the world of programming, that is a world of magic, and enters there, and you will become a great magician.
After experiencing a full seventeen chapters of learning, we finally came to the door to the programming world, and the door was open. Obviously, it has been waiting for our arrival.
18.1 Thinking about problems like software designers
I believe many of you have little or no programming foundation, otherwise you wouldn't have chosen the book "The First Step" I wrote. We already know that writing scripts in Flash using ActionScript is no different than programming in other languages. To eventually train to become an excellent software designer, the first thing you need to do is to remind yourself to think about problems like a software designer.
18.1.1 Don't always think about escaping programming
For programming in Flash, the most important thing to think about problems like a software designer is not to always think about realizing your ideas by evading programming. Many people always try to use non-programming means to complete all the problems they face. For this reason, they can spend a lot of time at any cost. They will come up with countless workarounds to bypass programming. If these methods can also be called algorithms, they will definitely surprise many software designers.
In fact, in many cases, using programming methods can save a lot of time by non-programming methods and produce more realistic effects. A very typical example is to show various random movements, such as the falling of a large number of snowflakes and the swimming of fish.
18.1.2 Carefully prepare the design manual
To think about problems like a software designer, you must try to describe the idea you want to achieve in logically clear language. This process is a very important process of writing design instructions in software development.
It sounds a bit arrogant, but after you complete a detailed design instruction manual, 95% of your work is done. Whenever someone asks me if an idea can be realized, I always answer that as long as he can describe it in detail, I can make it up. For development in Flash, all of a design manual is a detailed and rigorous description of how Flash movies will be executed and performed. A good instruction manual will take a lot of time and work, but it is worth it. When it is done, it will assume the responsibility of the work blueprint.
One person’s idea of how detailed the information should be, may be different from another person, but the more detailed the better. When you put extra energy into the early stages of your work, it will not only save you time on the way, it will also reduce the chance of rework.
One problem with writing an extremely detailed instruction manual is that it is difficult for you to fully describe the final procedure, because a written instruction manual is very different from the final Flash movie. To put it simply, it is impossible to describe the colors in a drawing in words or describe the sound of a song without some musical equipment, and there are errors in explanation here. But that doesn't mean you should sloppyly give up the whole process of writing the manual. Instead, you just need to write it in detail enough to make you confident to rely on it to unfold your work. Also, you must know that the work you have done before will leverage the work you will work in the future. A slight mistake can often lead to a huge mistake by irresponsible design instructions.
18.1.3 There are other possibilities to think of
Sometimes, an implementation seems to have a clear logic, and it seems that it is obvious that you should write programs according to the algorithms and logic you designed. However, when the development progresses to a certain step, you seem to encounter a wall and cannot go further. Many beginners who are new to programming will invest a lot of time here, constantly checking the logic of the algorithms they designed and the writing of the program code, making countless minor modifications, and eventually falling into the quagmire.
However, an experienced software designer will quickly realize that there may be fundamental errors in his initial judgment in this case. Many times, behind complex things is simple logic, while behind simple things is complex logic. Thoroughly abandon your original algorithm, change your mind, and try your best to guess another possibility, and you will find that the wall is beginning to disappear.
People are always willing to use simple methods to solve things, and the same is true in programming. This is the correct idea, but sometimes, when simple methods don't work, you have to realize that this may have to be achieved in complex methods.
Don’t always think things are so simple, always think that there are other possibilities.