Category: Project Manament

The nodejs growing very fast recently. New library or framework added to nodejs  almost everyday, since it is very easy to build a nodejs based module and javascript is used very widely.

I have done the A/B testing of nodeJS vs Erlang mochiweb, Erlang misultin, Nginx static page on my poor VM machine, and got the following result:

Nodejs helloworld:                     724 qps

Erlang mochiweb helloworld:     430 qps

Erlang misultin helloworld:         690 qps

Nginx static page:                    1045 qps

You can see that nodeJS is bloody fast thanks to the good performance of V8 JavaScript engine.

Talk about server side javascript, you should say Rhino, but nodejs is 20x faster than Rhino. NodeJS is stable, and not seen a bug of the code, like Nginx. You can build asynchronous system based on nodeJS and drop Tornado. What is important is that you can reuse your code both on client side and server side.

NodeJS is good at heavy IO usage, but not heavy CPU usage. And you should not change your current web system to nodeJS since it is too young.You can build your JSON interface by NodeJS, construct JSON from data fetched from database or remote web service, output the JSON format result.

Nodejs library:

npm — A node package manager that uses CommonJS-compatible package.json files, written in asynchronous JavaScript.

Express — A robust feature rich web development framework inspired by Sinatra

nodemachine — A port of WebMachine to Node.js

Connect — A  middleware framework for node

Socket.io — WebSocket-compatible server and client with fallback for legacy browsers

node-mysql — A node.js module implementing the MySQL protocol

redis2json — Easily loads data from Redis into structured JS object

See more:

https://github.com/joyent/node/wiki/modules

时常回顾team的开发过程, 虽然总体还算非常顺利, 但是仍然有很多可以改进的地方, 找出其中的问题可以大大提高开发的效率。

项目开发中遇到的问题,或许也是很多团队遇到的问题:

通常一个feature需要比计划更多的时间来完成;

孤立看一个feature,很难估计相关联的任务量,所以通常一个看起来简单的特性需要更多的时间来完成。Bug产生和解决的反复会延长估计的时间。将一个feature放到整个项目中还需要考虑到context的分析的工作量。

不能孤立的分析一个feature, 一个feature的增加,可能需要对之前很多feature的修改,一个feature的变化,可能需要对之前更多的feature进行改进。

有些时候程序员的效率会比平时低;

这常发生在task频繁切换的时候,假如一个任务正在进行,又增加了另一个任务,同一个人做的情况下就会遇到task的切换,很多时间浪费在环境的分析回忆上。

文档过多或者过少;

文档过多会浪费很多时间在写文档上,这是敏捷开发的大忌,但是完全不写文档很难做到协同开发,即使是自己写的代码时间久了也会忘记细节。

会议不能有效解决问题;

会议需要进行日程计划,每次例会需要所有人了解议题,提前熟悉相关内容,否则复制的问题沟通会很困难。

PM认为问题很简单,而开发团队认为很难解决。

应该把问题分离到程序解决和业务流程解决两部分,有时候单纯用自动化的方式不比人工流程效率高。其实难题往往通过第三种方式来解决,需要花更多的时间在问题分析上。

程序员和非程序员思维有很大区别(实际参与编码的程序员):

程序员会考虑一个feature是不是会失败,而非程序员想的是一个feature是不是会成功,可以加上去。所以往往后者会不断的添加feature,前者会经常说实现这个很难,实现那个几乎没可能。

项目的开发,解决所有问题其实都是在一个现有的堆栈上进行的,这基于先前的开发经验或者网上能找到的参考的经验。也许问题是很简单,但是假如这方面的经验非常缺少,就会导致更大的开发风险,更大的难度。

非程序员往往从问题难度本身来看待开发的难度,而程序员则会根据经验来看待问题,比如现有技术堆栈和现有经验。

总之

项目的开发过程其实是ROI的控制和对细小任务风险的评估的过程,只有所有人能高效沟通,正确不断评估风险,正确审视投入产出比,才能真正做到开发的高效率。

转载请保留原文链接 http://blog.eood.cn/improve_communication_skills_and_development_efficiency

互联网产品的设计不同于桌面程序,也不同于移动设备之上的程序。需要遵循几个最基本的原则:

清晰易懂:给人的第一感觉要干净,清楚易懂,没有累赘的元素。

一致性:减少元素数量,多进行重用,切忌重新设计相同功能的元素。同一功能最好只设一个入口。

易用性:适合用户每天重复使用。

快速:快速有效的操作,减少等待。

减少选择:减少让用户选择A或B这样的操作。

有效:有效的设计是用户注意不到的设计,而是其中表达的内容。不应该让用户的精力放在设计本身。

转载请注明来自:http://blog.eood.cn