这两天接了个新项目-ARM指令仿真项目，开发时间预期在两个月左右。这次将继承沿续自己以前做Cortex-A8、A9内核仿真项目时的方法，用日志纪录在开发过程中的各种问题解决方案和体会。限于某些原因，技术细节不会纪录。并且我认为技术细节上的收获并不会给以后带来太大的价值，所以主要以纪录做事方法和问题解决方法为主。
这个项目持续时间较长，估计期间会产生数篇文章，最终形成一个系列。这些文章将会不定期的发布在此。
一个没有立项的项目这个项目没有经过公司的立项，自然也没有走什么复杂的流程。一切全凭上司一句话，说要做这个，给大致两个月的时间，然后给个VC工程，就开始干了。
这倒也简化不少，省得去走公司复杂的流程。不过在是否应该将这个项目当成“项目”的问题上，我曾有过疑问？之前自己已经处理过类似的好几个项目了，但总感觉没有经过公司的立项，不够正式，更不好意思拿出去跟别人说做了项目。以后换工作写简历时，是否应该将这些作为正式项目写上去？
这个项目的特点是除了没有立项外，还只是作为已有产品做的一个功能性增加。增加的功能主要用于为使用仿真器的用户提供不受限制于硬件资源的调试手段。因而，确切来说，这只是一个维护性的项目。
项目的市场分析自然是没有的，不值得去做市场分析，费时费力，成本很大。需求分析也省略，用户和要实现的功能都很明确。正因如此，才有了前面上司一句话决定做这个项目的事。
估计有不少人遇到过类似的状况，只要老大觉得有需要或者有市场，就立即派人动手去做。可能那种完整的项目过程大多存在于大公司吧。
对这种该项目应该持何种态度虽然这种项目不正式，完成了也不会有太大成就感；不过我觉得还是值得一做的。原因很明显：
- 不做意味着不服从上司安排，弄不好会被当成工作态度不好。今后就算有正式的项目也不会丢给我；
- 失去了一次项目实践的机会；
- 产品的生命周期中总会有这些维护性的工作要做，不可能只开发新产品。
另外，没有经过立项并不意味着这个项目的价值不高或者无意义。相对而言，现在这位上司比较了解市场，思维面和眼光要比我的厉害很多，他提出来的项目绝大多数情况下都是靠谱的。既然提出来了，总是有一定道理的。
从公司项目管理部门来看，这个项目不算是个“项目”，不过我还是愿意将它看成是正式的项目。我认为只要满足以下条件就能算得上是“正式的”。
在指定的时间范围内利用可用资源完成要做的事情或实现某种功能、产品。
最关键的还是自己能从项目中获取得什么，获得多少；而不是它能够公司创造多大价值。当然，如果能同时满足这两点是最好的。
项目开始第一天的总结今天是项目正式开始的第一天，上司丢给我一个VC工程，让我先熟悉熟悉。虽然一开始很有立即想动手改代码的冲动，不过意识里还是制止了自己。因为我意识到了这个问题：
我平时工作的一大特点是接到一项新任务后或新东西后，喜欢一头扎进细节当中，立即动手去做、去改；而不是先想好大致的框架，想好应该怎么做。这往往会花费更多的时间、带来很失败的结果。
另外，我也喜欢完全重新自己搞一套，而不是直接拿现成的东西来用。这往往更加费时费力。
曾经上司说我做熟悉的东西速度很快，但一遇到不熟悉的，速度就慢下来了。原因可能正是上面这点。
在这个部门呆了三年，与上司一同工作的期间，一直“被”其强调做事的规范性，还有“搭好框架”的重要性，以避免后期的失败。这次意识到了这点，不急着动手。而是先熟悉大致的工作流程，然后运行起来，能够完善地运行一个最简单的功能。如果说这个简单的功能都能运行良好，那基本的框架就已经比较熟悉了。
之后是修改和添加代码的工作了，特别注意以下几点：
- 尽可能不要对原有结构做出大的改动。相对而言，自己建立框架比在已有的结构上改成就感要低很多。但不可否认的是，已有的结构已经经过实际验证，如果自己再重新搞一套，问题可能多多，还得重新验证；
- 尽可能保留原有的处理流程、尽可能多的保留原始代码。前人已经写好的东西，直接拿来用就好，可以很大程度上减少工作量；
- 总会有些枯燥并且没有技术含量的事情。其实之前有花了两天三时间做了一些统计工作，翻阅ARM体系结构手册，将三百多条指令的格式一条条整理到Excel表格中。这个过程很枯燥，但又必不可少。后续还会有类似的工作，并没有高技术难度的问题。
其实整个项目都没什么技术难度，关键的还是要有足够的耐性、细心。但是做出来后却能给产品增加非常好的亮点，同时也消除了某仿真方面的一大弱点。
我希望能从这次项目中了解到的是如何利用已有资源快速的完成工作，同时改一改以前那种想一切自己重头干的毛病。
本文同步发表在：javascript:;
