English bad, a lot of pressure
Ado, directly on the feel of it
No Silver Bullet: Essence and Accidents of Software Engineering
The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions
This is equivalent program = algorithm + data structure, and apparently, Software Engineering ≠ algorithm + data structure
I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.
After the development team around, I constantly feel the difference with the engineering program, read the frame, do not understand the interface, there are questions about the documentation, etc., etc.
Let us consider the inherent properties of this irreducible essence of modern software systems: complexity, conformity, changeability, and invisibility.
Mainly to talk about the changeability
Our team first saw the version is the initial version Glede then Glede with Anran as the total began to write the framework and define the interface
However, the process of opening the project in, and repeated a number of changes and improvements
The fact that I encountered in the implementation as Dev problems, go to contact Anran, put forward some new ideas, and change again
It is undeniable that, after this correction several times, and now the frame than most start with no small progress
But in constant change, but also affected the progress of the development of the project and increased the workload of members
Object-oriented programming
Enron said his java or C # programmer, I have to say I am quietly Pascal / C programmer ....
For an OO This perception is still very weak, but it can be felt in strengthening can only say it slowly accumulate experience
Managing the development of large software systems: concepts and techniques
Develop a variety of ways, if a person can be considered the team, then rush mode is fine
In the student teams, the most common is the "star model", in fact, we will continue to degenerate into work only star
Of course, above all for the team division of the way, say the following way for the project itself
Waterfall model is the "sounds beautiful" in a way
Why is it "sounds beautiful", in fact, this is the limited ability of our
The easiest waterfall, is the water flow down along, they are unable to go up again reflux
Clearly, software engineering is certainly not a one-off, to change the model
Then we add back
Plus back is not enough, because the waterfalls are along the stream, and finally, to the last point certainly have
And so that we can not clean water to flow only to find it a problem
This is a multi-dimensional way of improvement is difficult to cover everything
The authors suggest a number of improvements, in fact, it is to improve methods on a lot of different directions
On our projects, we can approximate that the use of such a method DO IT TWICE
We just designed a model, and a scene, the player has only one weapon
Then we can start to play, we each play a few times, and then discussing, what should also be aircraft, the scene should be how weapons should be how to do, etc.
Then learn from experience, do it again, something had to be added together
But I think, like the waterfall model is not suitable for us, interfaces immature, immature technology, but there is a time more exchanges
This is actually more suitable for our Agile, Agile, say the following
I've mentioned, then write C ++ great job when wrote half, we decided to reinvent the wheel all
Now press statement, written before that big ball of mud
focus first on features and functionality, then focus on architecture and performance
Well first of all to complete before you can say other, but our team did just that, so teachers are required, the first alpha version, another month a beta version
Users’ needs change with time.
It also has been mentioned over and over again in question, and also has been bothering me ... probably, get used to it it
Overgrown, tangled, haphazard spaghetti code is hard to comprehend, repair, or extend, and tends to grow even worse if it is not somehow brought under control.
We are in the process of encoding, often written XXX unrealized, so the cumulative cumulative cumulative, and then wait until the last possible fix up the difficulty will increase.
I did not want to keep to achieve, at least in good comments checked in, then as soon as possible after the discussion clearly.
CatB - Cathedral and the Bazaar
Talk about this below 5 bar
Every good work of software starts by scratching a developer's personal itch.
itch good variety of points, is probably the easiest Who wants PM \ Dev \ Test \ UI, who of course have to consider when PM \ Dev \ Test \ UI
If you have the right attitude, interesting problems will find you.
Another on contact, only we are interested in doing things, to well done
Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
There is mention in the waterfall model, to be in regular contact with our customers, we play games, he is considered to be the customer, we have to constantly improve themselves and feel
Release early. Release often. And listen to your customers.
Released late, one of the drawbacks is the waterfall model, and we handled it well from the point of view of short-term and long-term remains to be considered
Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.
Our group is two PM, at the same time they also serve Dev, I can not guarantee you two must be better than a good leader
But at least we now have fairly pleasant cooperation
This paper cites many examples to prove his point: Most people lost in the bazaar
After the article see, I also looked at the passing comment
I remember someone once remarked, "original design", "the whole book is talking about his family build a house with some related content, is simply to get money." - this comment just confirms the author said, "Really, the most need to look at the "original design" of the people, you might find this book totally incomprehensible. "
Software system is a natural evolution out. Build a house with a way to build a city, probably only be utopian, or Pyongyang. If he did not think that this is not good, give specific examples of success, who has the ability to make him the ideal system? Windows? Java? OS X? Or to return to the era of the Iron Curtain OS360 it be possible?
People think that this article one-sided. Today in the overall OS market, Linux has defeated the windows, a large variety of open source software has achieved great success. web service to replace software license has become an important business model also has been confirmed this prediction. libtool become the master of precisely the people have been responsible for them. Binary compatibility is no success in the era of commercial unix, blame to go open source
Back to our projects, we use cocos2d engine, but at least I'm not familiar with a number of methods of providing cocos2d
That will repeat some unnecessary work, which is the threshold too low, and I looks good enough ah
Agile Method – by Martin Fowler
I write to you very tired, but still much more agile say a few words
Speaking from the principles of agile development
Business people and developers must work together daily throughout the project.
Agility, from the Chinese habit, it sounds always feel a bit strange, but the meaning is very easy to understand, is to be fast, speed is important
In order to ensure the speed, we sit in a circle to work together is the most favorable of the
Most worried about is you have a question, send E-Mail asked, and then he came back to you tomorrow, so what about agile
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
I think this is the reason Daily Scrum teacher asked the bar
As a further unqualified Dev, has been very tired before the framework for understanding
Until one day, the Enron called Jay to 1109, and then little by little, ask questions, answer one by one, and then suddenly see the light
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage
I can say this is the biggest Agile differs from it?
The waterfall model can be regarded as program-driven, more demanding is respect for order, on-time delivery, and agile development are encouraged to change
Liu Junwei think our project is based on the waterfall model, step by step down
And I think we'd like to be able to step by step down, but due to the experience and ability, often change, coupled with the development focus of the time, it seems more suitable for our agile
■Agile methods are adaptive rather than predictive. Engineering methods tend to try to plan out a large part of the software process in great detail for a long span of time, this works well until things change. So their nature is to resist change. The agile methods, however, welcome change. They try to be processes that adapt and thrive on change, even to the point of changing themselves.
Original text, is described agile methods. We hope it is continuous improvement, and this is one of our group differences with other groups
In my understanding, to be a learning assistant, releases features even if not much, but it should be is very comprehensive, can not have too many of BUG
But we do play, you can regularly update (of course this is not to say casually to pay a go), we can also usually the user's reaction, constantly updated
In today's environment, the most common methodology is code and fix. Applying more discipline than chaos will almost certainly help, and the agile approach has the advantage that it is much less of a step than using a heavyweight method. Here the light weight of agile methods is an advantage.
Through this lesson, we make every day Daily Scrum, and then burn burndown can see when completed
We also experienced an agile development methods
A lot of people claim that agile methods can't be used on large projects.
This is the point, more agile and waterfall method final say
Large projects or should be slowly, cautiously good, more reliable
Small projects can fucks
Really a great amount of reading
Although the teacher asked us to Bibi with XXX school, but they see it is in English, English is their native language it
I let the Chinese see it twice, in fact, it is not too much
English look really needs to be improved ....
10,061,189 Tan Zhuanqi
Reproduced in: https: //www.cnblogs.com/buaashine/archive/2012/11/13/2768819.html