写点自己的感受吧，总喜欢把现在的项目的各个方面与之前的项目做个比较。之前做的是日本外包项目，也许很多人会感受日本外包项目就是没有技术含量，只能体力劳动而已。但我没有感觉到，可能不同公司接的项目不太一样，至少我见到过并参与过很多大的项目，当然也有小的项目。

由于之前做的是东芝公司的外包项目，项目一般规模都很大，东芝会把整个项目分成几个部分分别发给印度、中国等的软件公司，每个公司做独立开发，测试；但整个项目的进度控制严格按照进度计划执行，所以不会存在项目不能按时提交；个人认为这点非常重要。

做一个大的项目，学到的是软件工程的整个流程，项目的管理控制，版本控制，项目的设计思想，成员之间的配合和协助的各个方方面面。

其实大的项目中，每个人只承担的是一小部分，但自己没有拘泥于自己做的一小部分，需要了解整个项目的完成的任务，然后在逐步了解项目的每个大的模块，根据系统设计书了解各个模块之间是怎么相互配合工作的（unix系统一般是把每个模块做成一个进程，整个系统之间通过各个模块（进程）之间的通信配合完成这个业务功能）。

既然是很多模块（进程），可能就需要有个管理这些进程的进程，监视这些进程的进程，提供网络通信的进程；写日志的进程；还包括一些辅助进程，如查看系统信息，查看各个进程的状态等的系统详细信息。（其实，oracle系统，tuxedo中间件也都是类似的这样的模块结构）。

也许你还会觉得也不难，其实把上面的每一个模块详细展开，都会有很多很多的内容，包含很多的技术和理念。（我看过的很多的书，但没有系统的去分类，思路也不是很清晰哦，呵呵）。

每一个模块的实现都需要考虑很多方面的事情，比如日志模块，日志模块应该系统的操作记录、bug的跟踪等很多方面很重要吧，写文件是公认的很消耗时间的操作（想想为什么？），如果过多的写日志操作放在业务进程中会严重影响到系统的性能，如果通过消息队列、共享内存等进程之间通信的方法，把写的日志发送到专门写日志的进程中，这样就不会影响到处理进程的性能。日志的等级，如致命错误、严重错误、一般错误、调试信息等；还有日志文件的大小的限制（太大了，不便于以后查看等），日志文件的备份归档等。

通信模块考虑的也有很多，进程级别的通信还是机器间的，局域网间的就暂不考虑了；服务器模式是用并发服务器、迭代服务器和进程池等，多服务器之间的同步和负载均衡；选择用TCP还是UDP通信，选择共享内存、消息队列还是管道等进程间通信等。

业务知识也很重要；首先要知道要做什么，要做的东西的详细流程这是业务知识；然后根据客户的描述，再加上自己的经验去把你所理解的反应给客户，看看她说的和你理解的是不是一个意思，要做什么就比较明确了。但是这只能功能，客户要达到什么样的性能和客户能接受的系统报价，综合以上给去一个折中的方法给各户一个解决方案。客户认可以后就可以进行系统设计了，包括各个模块的划分，模块之间的相互关系等。然后就是模块的详细设计、编码、单元测试、结合测试、模块测试、集成测试等。

要学习的东西还很多，操作系统，数据库、文件系统、网络通信、虚拟机的原理和实现等。

钻研过linux 内核0.11版源代码，学习过ingres数据库源代码，对minix文件系统有一定得了解，正在学习hex虚拟机的实现，对TCP/IP协议、smtp、pop、http等应用协议也比较熟悉。