Posts Categorized: Programming

本来要学老王，取名叫乱炖，老王一直执着的用这个词，那我就换一个吧。一个多月没写博客了，前面一段时间是因为实在太忙，后面是懒，疯狂加班之后回家就什么都不想动，过了经过差不多一个多星期的正常人生活，现在终于缓过神来了。这个项目差不多是我加入以来我做过的最大的项目，很累，也很疯狂，项目还在继续，迭代一轮一轮的进行中。留下点笔记，记个印象。 1、项目开始的时候往往思想很宽泛，这个想要，那个想要，每一个功能都是无敌的，每一个功能都是必须的。我一直不赞同一开始就把产品设计的看上去很大很全，主要基于两个理由： 第一，产品一开始设计得大而全，会导致开发周期被拉长，在没有经过市场检验或者最终用户使用的时候，过长的周期会导致开发人员效率降低，没有人愿意做一个看不到前景的产品，没有来自最前线新的需求刺激，没人知道这个东西是不是靠谱的，很长的开发周期还会导致开发人员的疲惫，当然这个可能有些公司不一样，如果人手充足，这个情况或许不那么明显，但据我所知，所有的公司都是缺人的，特别是IT公司，为项目加班是常事，如果这个项目周期再长一点的话，估计就崩溃了。 第二,产品一开始就设计得大而全会导致设计出很多无用的功能，每个人都知道一个产品存在的意义在于其20%的功能，或许有人要反驳，我不预先搞多一点功能，我怎么知道那20%的功能是什么。这个疑问是有道理的，问题就在于，如果我们不能找出最精华的20%功能是什么，那么我们或许可以把圈子放大到30%，40%，甚至更大一点的范围，我们的工期也会缩短很多，避免做无谓的工作。 2、关于开发周期，我觉得最好不要超过一个自然月，一个月20个工作日，除掉UI和页面部分设计，再除去测试和修Bug时间，留给研发的时间大约40%~60%，也就是8~12个工作日，如果只需少量页面方面工作，留个研发的时间会多3~5个工作日。研发工作大约两个星期的，大部分正常上班时间是完不成工作的，不可控的因素有很多，所以这个阶段，可能会加班加点，稍微放松的时刻留在bug修复阶段和后续迭代的UI及页面设计阶段，这个阶段如果稍作控制，可以避免研发人员加班，有至少一个星期的时间让心情得到释放。 3、以上两点基本上接近了敏捷开发的管理流程，敏捷开发在最大限度的保证质量和兼顾项目人员之间的平衡，套用一句话，如果实施了敏捷开发，员工没有离职，那一定是加工资了，如果没有加薪，那一定会离职。需求的不断刺激和短周期的迭代，会导致项目人员情绪的紧张和工作的高压。 4、关于Zend DB，这个玩意的可移植性确实不错，稍作整合，就能嵌入其他框架，但是这玩意最好还是别用在复杂的项目中，而且由于Zend DB本身的设计问题，很多东西你不得不去搞个很变态的方式去解决，比如计算符合条件记录总数。可能由于出于降低耦合度的目的，Zend DB 本身不自动设置缓存，每次需要在action，在新建的每个Model中都要去写和缓存相关的代码，当然解决办法也是有的，就是自己在为Zend DB增加一个组件，将接口和数据库操作给整合进去，然后新建的Model不再继承原先的Zend_Db_Abstract，而是继承你增加的那个组件，从而做到相对优雅的使用缓存。不过我还是推崇，直接写SQL，虽然看起来不那么优雅，但是更容易掌控，对项目日后的调优，非常有益，在复杂逻辑的时候表现优越，如果只是单表操作，ORM依然是不错的选择。至于怎么选择，取决于你的需求，和你项目组人员的整体水平。 5、关于Zend Cache，这个玩意是个好东西，让我们在本地写程序的时候可以方便的使用文件缓存，到服务器上也很方便的改成memcache缓存，少排了好多二氧化碳，Zend组件最优越的地方就是可以轻松的整合，偷懒少写了好多代码，唯一用的不爽的地方是Zend Cache的Tag功能，这个功能本来是个很cool，很有用的功能，但是因为大部分key-value缓存不支持这个玩意，这个东西变成了只有文件缓存时可用，但是在每次save一个缓存的时候，如果需要给这个缓存加个过期时间的话，就得这样写:$cache->save($data, $cache_key, $tag, $expire)，因为memcache不支持这个玩意，这时候每次传入的tag就是一个空的数组，我就一直不明白为啥$tag不放到最后一个参数，毕竟所以的缓存类型都支持过期时间，而只有文件缓存才支持Tag 6、关于Tornado（被墙了）,我不知道国内用的人多不多，源代码hosting在github上，从邮件列表来看，似乎国内用的人不多，在华莽用户组这样的Python社区里面都几乎没有人提及，这个玩意非阻塞性的Web Server，集成了Web Framework 和 Web Server，我有幸能在我的试验性项目中使用这个东西，提供一组数据，没啥用处，供需要的人参考，单个进程大约能支持1.2K左右的活动链接，当然，要在Linux服务器上，并且支持epoll，多进程可以到2K，占用内存在100M以内，服务器没有任何异常，有进一步挖掘的潜力，我估计能超过3K，当然不建议你这么做，因为Server的后端可能处理不过来了，如果你想动手实现一个Web IM 之类的应用，Tornado是最佳选择之一，另外，如果用来做Web游戏的Server，也是非常合适的，Tornado的Web Framework这一块还很简陋，非高级人员+非Geek人员，不建议用来做产品开发 7、如果你还在寻找一个项目管理工具，我建议你使用Redmine，这玩意能够显著帮助你的团队减少抱怨，减少无效沟通，能够让上下游的同事更自如的安排计划，当然，这一切还需要你做一个布置，平台是死的，需要大家往里面填充属于自己的东西