TJamie-阅读作业2
英语太差，压力很大
废话不多说，直接上感想吧
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
这相当于 程序=算法+数据结构，而显然，软件工程≠算法+数据结构
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.
经过四周的团队开发，我不断的感受到工程跟程序的区别，看不懂框架，不理解接口，对说明文档有疑问，等等等等
Let us consider the inherent properties of this irreducible essence of modern software systems: complexity, conformity, changeability, and invisibility.
主要就说说changeability
我们团队最初看到的版本，是Glede的初始版本，然后Glede与Anran一样合计着开始写框架，定义接口
然而开项目进行的过程中，又反复改动及改进了多次
再加上我作为Dev在实现中碰到一些问题，再去联系Anran，提出一些新的想法，又再次改动
不可否认的是，在经过这次多次的修正之后，现在的框架比最开始有了不小的进步
但在不断的change中，也影响了项目的开发进度以及加大了成员的工作量
Object-oriented programming
在安然说自己的C#或者java程序员的时候，我只好默默的说我是Pascal/C程序员....
对于OO这一块的感知力依然很弱，但能感受到在加强，只能说慢慢积累经验吧
Managing the development of large software systems: concepts and techniques
开发方式多种多样，如果一个人也算团队的话，那一窝蜂模式挺好的
在学生团队中，最普遍的就是“明星模式”，其实会继续退化为只有明星干活
当然上面都是对团队分工的方式，下面就说对于工程本身的方式
瀑布模型就是“听上去很美”的一个方式
为什么说是“听上去很美”，其实这在于我们的能力有限
最简单的瀑布，就是水顺着流下来了，也没法再回流上去
显然，软件工程肯定不是一次性的，这个模型要改
那我们就加上回溯
加上回溯还不行，因为瀑布是顺着流的，最后一点肯定得最后流到
那我们总不能等水都流干净了才发现出问题了吧
这是一个多维的改进方式，很难面面俱到
作者提出了很多改进意见，其实是很多不同方向上的改进方法
对了我们的项目而言，可以近似的认为，使用了这样一种方法DO IT TWICE
我们只设计了一种机型，和一个场景，玩家也只有一个武器
然后我们就可以开始玩了，大家每个玩几遍，然后讨论讨论，还应该有什么飞机，场景应该怎么样，武器应该怎么办，等等
然后吸取经验，再来一遍，把要加的东西都得加上
不过我觉得，瀑布模型好像并不适合我们，接口不成熟，技术不成熟，反而是有时间多交流
这样实际上敏捷比较适合我们，关于敏捷，下面再说
我曾提到过，当年写C++大作业的时候，写到一半，决定全部推倒重来
按现在的说法，之前写的就是big ball of mud
focus first on features and functionality, then focus on architecture and performance
首先要完成嘛，然后才能说其它，而我们团队正是这么做的，老师也是这么要求的，先出alpha版，再过一个月出beta版
Users’ needs change with time.
这也是一直反复不断在提到的问题，并且还在一直困扰着我...可能，习惯了就好了吧
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.
我们在编码的过程中，经常会写到XXX未实现，这样累积累积累积，等到最后可能再修复起来难度会加大。
我想留着没实现的，至少要在签入时注释好，然后在讨论清楚后尽快实现。
CatB – Cathedral and the Bazaar
讲讲下面这5条吧
Every good work of software starts by scratching a developer's personal itch.
itch分好多种，最简单的可能就是谁想当PM\Dev\Test\UI，当然也要考虑谁能当PM\Dev\Test\UI
If you have the right attitude, interesting problems will find you.
联系上另一条，只有我们干有兴趣的事情的时候，才能干得漂亮
Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
在瀑布模型中就有提到，要经常与客户联系，我们做游戏，可以认为自己就是客户，我们也要不停的改进，然后自己感受一下
Release early. Release often. And listen to your customers.
发布晚，正是瀑布模型的缺点之一，而我们从短期上看处理得很好，长期的还有待考量
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.
我们组就是两个PM，同时他们也兼任Dev，我不能保证两个leader就一定比一个好
但至少我们现在合作得还算愉快
文中举了不少的例子，来证明他的观点：大多数人在集市中迷失了
看文章之后，我也顺带看了看评论
记得有人曾这样评论《设计原本》，“整部书都在讲些与他家盖房子有关的内容，简直就是骗钱。” ——此评论恰恰印证了作者所言，“真的，那些最需要看看《设计原本》的人，可能会发现这本书完全无法理解。”
软件系统，是自然演化出来的。用造一间房子的方式，去建设一座城市，大概只能是乌托邦，或者平壤。如果他认为这样不好那样不对，举个具体的成功例子，谁有能力作出他理想的系统？Windows？Java？OS X？还是要回到OS360的铁幕时代才有可能？
人认为这篇文章比较片面。今天Linux在整体OS市场上已经击败了windows, 大量各种open source软件都取得巨大的成功。web service取代software license成为重要的商业模式这个预言也获得了印证。libtool成为主宰恰是一直有人对它们负责。二进制兼容在unix商业时代就没有成功，不能怪到开源上去
回到我们的项目中，我们使用的cocos2d的引擎，但至少我还不太熟悉cocos2d提供的大量方法
以至于会重复一些不必要的工作，这就是门槛太低了吧，我貌似还不够格呀
Agile Method – by Martin Fowler
写到这里已经很疲惫了，但敏捷还是得多说两句
从敏捷开发的原则说起
Business people and developers must work together daily throughout the project.
敏捷，从中文的习惯上，听起来总感觉有点奇怪，但意思还是很容易理解，就是要快，速度是重要的
为了保证速度，大家坐在一圈一起干活就是最有利的了
最担心的就是你有个问题，发个E-Mail问，然后他明天才回你，那样何谈敏捷
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
我想这就是老师要求Daily Scrum的原因了吧
作为一个还不够格的Dev，之前理解框架一直很累
直到某一天，把周董安然都叫到1109，然后一点一点的提出问题，一个一个的解答，然后就豁然开朗了
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage
我可以说这是敏捷开发最大的不同之处吗？
瀑布模型是可以算是计划驱动的，要求的更多是崇尚秩序、按时交付，而敏捷开发则鼓励变化
刘俊伟觉得我们的项目是按瀑布模型，一步一步下来的
而我觉得，我们倒是愿意能一步一步下来，但由于经验以及能力的原因，经常改变，加之开发时间的集中性，好像敏捷更适合我们
■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.
原文中，是这样来描述敏捷方法的。我们希望的正是不断的改进，这也是我们组与其它组的区别之一
在我的理解下，做一个学习助手，发布的版本功能就算不多，但应该就是很完备的，不能有太多BUG的
但我们做游戏的话，可以经常更新（当然这不是说随随便便就交一个上去），我们还可以通常用户的反应，不断的更新
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.
通过这个课，我们每天做Daily Scrum，然后烧燃尽图看看什么时候能完工
我们也体验了一把敏捷的开发方式
A lot of people claim that agile methods can't be used on large projects.
这是最后要说的一点，比较瀑布模型和敏捷方法
大型的项目还是应该要慢慢来，谨慎点好，比较靠谱
小型的项目才能乱搞
阅读量确实很大
虽说老师要我们跟XXX学校比比，但他们看的是英文呀，英文是他们母语呀
要让我看这两倍的中文，其实也不算多呀
看英语实在是....能力有待提高
10061189 谭传奇
