软件开发工具一览
郭晓峰
我不是很懂CMM之类的东西，只能按我平常开发的流程跑个烂砖头，希望勾出大家有意思的东西来。这个帖子，也是我入伙的时候就很想写的了。我们可以先high-level的讨论一下有那些类，哪些工具。然后以后具体化的开thread一个一个工具讨论过去。
我做的比较土，本来还有点核心的，现在越做越应用了。做核心的时候很是天马行空，不过test啥的还是都有，只是很多时候犯懒，总是依赖我们QA帮我些。现在做应用了，这些东西一个都不能少，要不出了问题客户直接就追到头上了，没有人帮我擦屁屁。慢慢养成了习惯，觉得还是蛮有用的。
首先是test！test已经成我的代码核心了，现在test : src -> 2 : 1了。而且feature
deliver之后，因为QA的bug，test会越写越多，绝对是重中之重。这个是影响开发进度的，所以现在基本上老板已经不push我的delivering了，因为我经常delay的。（感谢国家，感谢党，感谢老板，感谢team）
test包括unit test / regression test (smoke
test)等等，我不是QA，也没法全懂。自己的code，unit test是肯定免不了的。100%
coverage总是求之不得，特别是一些multithreading的，大家如果有特别好的办法，记得共享一下。Java底下的，我们自己还有一些可以定这个thread
run到这个method挺一下之类的来check status，C++就完全无解。我写code很马大哈，所以C++
multithreading，我一般就直说我恐怕写不好，虽然以前发paper聊啥minimize critical
section一套一套的。
接下来是repository。SourceSafe / CleanCase / cvs / svn / perforce /
git都用过，不过现在就比较熟git和perforce了，svn工具多，也可以玩一玩。用了几年的cvs，现在一眼看去，是大不解了。别的bazaar啥的，只能把code
check out下来编一编。个人很拜git，确实好用。自己的服务器上放到git
repository使用gitosis，还比较简单。这个每个人各有喜好，也没啥好讨论的，就是放堆code的地方吗。git最好的就是没有每个目录给我来一个.svn这样的鬼东西，perforce也是，所以我比较喜欢这两个，仅此而已。（有那个东西的话，我找起东西来，还需要把伊滤掉，like:
find . | grep -v "\.svn" | xargs grep -nH "xxx" {} \;
（这个命令不做准啊，xargs大意如此，因为我平常只要find . -exec grep -nH "xxx" {} \;就行的）
接下来是code review。感谢国家，感谢党，感谢公司，我们可以用一个command很容易的发patch给相应的人，而且有一个online
system做side-by-side的comparing，对效率大有帮助。谈code review不得不谈coding
style，一个软件公司，应该有自己的coding
style，保证code到哪看上去都差不多。有些人写code比较牛，比如一个函数一行就写完了（我是说很复杂的那种，我有个朋友以前一行可以写1000多个字的），到了组织里，只能不好意思，拉回去重写了。一个project，铁打的营盘流水的兵，要是你的code太牛，后面的人接不了手，再牛的project也只能扔到垃圾堆里，所以coding
style是必要的。现在有很多lint工具可以保证coding style，我个人更希望工具能把coding
style都包括进去了，否则一个team里，有些边缘的不同点，很容易伤了大家和气，影响以后的士气。不过貌似做lint的人都不怎么喜欢parsing
code，所以做出来的lint都还不是特别精确。这方面java好些，有lint / checkstyle / findbug /
...一系列很好的工具，而且即使code已经进去，还是可以用Hudson / Jenkins之类的东西发现。
对于code review的几个原则：reviewer如果看不懂code，一定要弄懂，否则就不要盖章了。reviewer不光要弄懂code，还要理解design，这是最后的design
review，这个时候roll-back，远比code出去了再这么干更好一点。reviewer态度一定要nice一点，人总是在不断鼓励中提高的，你打击人几次，人以后就伤了。关于CR的tool，review
board / gerrit (Android用那个）等等等等，现在已经有好多，没有装的，赶紧装一个。（对了，以前svn有post code
review的概念，个人不太喜欢，code review就是要side by
side，有record的把意见啥的记下来，其实这是很好的提高水平的方法）
接下来是CI。没啥好说的，没有CI赶紧去搞一个，你不希望你的软件今天好明天坏，每天的时间都用来抓bug吧？谁出的问题，第一时间报出来总是好的。
还漏了不少，下次慢慢补了。其实，喜欢project，一心想把project做好，才是最重要的东西。
最近top-language =>
top-company中，发个贴应应景，让大家有点topic讨论讨论。也许跟lang没啥关系，但是大家不都是码农吗，也还是本行吧。
HaoPeiQiang
2011/5/3 郭晓峰 <lam...@gmail.com>:
--
Tinyfool的Blog http://tiny4.org/blog/
Tiny4Cocoa http://tiny4.org/cocoa/
myTwitter: http://twitter.com/tinyfool
Eric Miao
Nelson
On May 2, 9:19 pm, 郭晓峰 <lamu...@gmail.com> wrote:
> 软件工程事实上越来越标准化了。
>
> 我不是很懂CMM之类的东西，只能按我平常开发的流程跑个烂砖头，希望勾出大家有意思的东西来。这个帖子，也是我入伙的时候就很想写的了。我们可以先high- level的讨论一下有那些类，哪些工具。然后以后具体化的开thread一个一个工具讨论过去。
>
> 我做的比较土，本来还有点核心的，现在越做越应用了。做核心的时候很是天马行空，不过test啥的还是都有，只是很多时候犯懒，总是依赖我们QA帮我些。现在做 应用了，这些东西一个都不能少，要不出了问题客户直接就追到头上了，没有人帮我擦屁屁。慢慢养成了习惯，觉得还是蛮有用的。
>
> 首先是test！test已经成我的代码核心了，现在test : src -> 2 : 1了。而且feature
> deliver之后，因为QA的bug，test会越写越多，绝对是重中之重。这个是影响开发进度的，所以现在基本上老板已经不push我的deliverin g了，因为我经常delay的。（感谢国家，感谢党，感谢老板，感谢team）
>
> test包括unit test / regression test (smoke
> test)等等，我不是QA，也没法全懂。自己的code，unit test是肯定免不了的。100%
> coverage总是求之不得，特别是一些multithreading的，大家如果有特别好的办法，记得共享一下。Java底下的，我们自己还有一些可以定这 个thread
> run到这个method挺一下之类的来check status，C++就完全无解。我写code很马大哈，所以C++
> multithreading，我一般就直说我恐怕写不好，虽然以前发paper聊啥minimize critical
> section一套一套的。
>
> 接下来是repository。SourceSafe / CleanCase / cvs / svn / perforce /
> git都用过，不过现在就比较熟git和perforce了，svn工具多，也可以玩一玩。用了几年的cvs，现在一眼看去，是大不解了。别的bazaar啥的 ，只能把code
> check out下来编一编。个人很拜git，确实好用。自己的服务器上放到git
> repository使用gitosis，还比较简单。这个每个人各有喜好，也没啥好讨论的，就是放堆code的地方吗。git最好的就是没有每个目录给我来一 个.svn这样的鬼东西，perforce也是，所以我比较喜欢这两个，仅此而已。（有那个东西的话，我找起东西来，还需要把伊滤掉，like:
> find . | grep -v "\.svn" | xargs grep -nH "xxx" {} \;
> （这个命令不做准啊，xargs大意如此，因为我平常只要find . -exec grep -nH "xxx" {} \;就行的）
>
> 接下来是code review。感谢国家，感谢党，感谢公司，我们可以用一个command很容易的发patch给相应的人，而且有一个online
> system做side-by-side的comparing，对效率大有帮助。谈code review不得不谈coding
> style，一个软件公司，应该有自己的coding
> style，保证code到哪看上去都差不多。有些人写code比较牛，比如一个函数一行就写完了（我是说很复杂的那种，我有个朋友以前一行可以写1000多个 字的），到了组织里，只能不好意思，拉回去重写了。一个project，铁打的营盘流水的兵，要是你的code太牛，后面的人接不了手，再牛的project也 只能扔到垃圾堆里，所以coding
> style是必要的。现在有很多lint工具可以保证coding style，我个人更希望工具能把coding
> style都包括进去了，否则一个team里，有些边缘的不同点，很容易伤了大家和气，影响以后的士气。不过貌似做lint的人都不怎么喜欢parsing
> code，所以做出来的lint都还不是特别精确。这方面java好些，有lint / checkstyle / findbug /
> ...一系列很好的工具，而且即使code已经进去，还是可以用Hudson / Jenkins之类的东西发现。
>
> 对于code review的几个原则：reviewer如果看不懂code，一定要弄懂，否则就不要盖章了。reviewer不光要弄懂code，还要理解design，这 是最后的design
> review，这个时候roll-back，远比code出去了再这么干更好一点。reviewer态度一定要nice一点，人总是在不断鼓励中提高的，你打击 人几次，人以后就伤了。关于CR的tool，review
huan yi
--
now: Asiainfo-Linkage
prev: HUST
机械唯物主义 : linjunhalida
一个流程如果没有实际作用, 那么就变成官僚主义了.
最好还是要看: 一个流程解决了什么问题, 是否有更好的方式来处理?
量化考核和指标, 从名字上看就有点恐怖了... 量化可以, 用来考核的话, 十有八九会走歪.
我个人觉得, 开发者能够根据需要加入和去掉流程是最重要的, 流程本身只是产物.
2011/5/3 huan yi <hy86...@gmail.com>:
Chunlin Zhang
On May 3, 12:19 pm, 郭晓峰 <lamu...@gmail.com> wrote:
> 对于code review的几个原则：reviewer如果看不懂code，一定要弄懂，否则就不要盖章了。reviewer不光要弄懂code，还要理解design，这是最后的design
> review，这个时候roll-back，远比code出去了再这么干更好一点。reviewer态度一定要nice一点，人总是在不断鼓励中提高的，你打击人几次，人以后就伤了。关于CR的tool，review
> board / gerrit (Android用那个）等等等等，现在已经有好多，没有装的，赶紧装一个。（对了，以前svn有post code
目前用上了 gerrit 感觉不错,不仅 android 代码库可以用,其他的一样可以.
> review的概念，个人不太喜欢，code review就是要side by
> side，有record的把意见啥的记下来，其实这是很好的提高水平的方法）
>
> 接下来是CI。没啥好说的，没有CI赶紧去搞一个，你不希望你的软件今天好明天坏，每天的时间都用来抓bug吧？谁出的问题，第一时间报出来总是好的。
这个我刚搞了个 buildbot 感觉还不错.
郭晓峰
而且，比如findbug / checkstyle之类的东西的话，是非常提高生产力的。
2011/5/3 机械唯物主义 : linjunhalida <linjun...@gmail.com>:
郭晓峰
gerrit是通用的，我只是说Android用它。
buildbot看上去很像hudson/jenkins。收了，最后出summary的时候我会加上去。
还有人有更有意思的东西吗？
2011/5/3 Chunlin Zhang <zhangc...@gmail.com>:
翁翊成
最开始做持续集成,我们做到的只是持续编译,随着开发的深入,对不同测试环境的依赖,我们加入了自动打包和自动发布.
Luke
一般而言，工具能够非常提高生产力，争议较少，但一说到流程，涉及到对人的管理，争议就很大了。不管是管理者，还是工程师自发的推动出来，所谓的流程管理本身就跟项目内容，团队大小和人员素质，甚至文化习俗关系很大。
--
Regards,
Luke
oliver yang
--
Cheers,
Oliver Yang
Twitter: http://twitter.com/yangoliver
Blog: http://blog.csdn.net/yayong
--------------------------------------------------------------------
An OpenSolaris Developer
郭晓峰
工具的目的就是减少争议，这也是engineer喜欢工具的原因。有问题，是eng这边的，理应fix；不是eng的，也不会被逼着做一些莫名其妙的东西。比如我花了不少篇幅写的coding
style，就是减少code review争议的。
当然，工具只是一部分，如果你的team里本身有问题，或者说本身eng就只是把项目当成是挣钱的工具，那什么流程、工具都是浮云。
Best Regards,
Xiaofeng
2011/5/5 oliver yang <yango...@gmail.com>:
Julian Qian
control这些做完整的还没有。不过这也可能和项目有关系，如果是一个新项目的话，很容易统一规范；但如果维护一个老项目（甚至10年以上的）的话，基本各种风格做法都有，甚至有一个大项目的子项目里能用多种版本管理工具，这你就很无奈了，所以能够利用工具和规范提高生产力是一件很幸福的事情啊。
BTW，写自己的小工程时，我也喜欢用git，毫无压力的branch和本地commit让人感觉很畅快 :P
2011/5/3 郭晓峰 <lam...@gmail.com>:
--
Best Regards.
Julian Qian
Stanley Xu
Larry, LIU Xinyu
想起《程序员》杂志有一段时间，每期搞个我的工具箱的文章了。
流程这个东西的特点是，新的流程出来时候，总是被人追捧，大家眼睛一亮，觉得革命来了。
然后就是自上而下的强制推广，培训，认证，然后流程就给做烂了。
最后发现，好的软件总是那几个人做出来的，不管他们用什么流程，而有人能够用最革命的前沿流程生产垃圾，也是一个有趣的现象。
最后说起testing， 有没有人听说过invariant test?（不知道这个词是不是我发明的）
例如，你写了一个sort函数，通常的UT大致如下：
assert(sort([]) == [])
assert(sort([1]) == [1])
assert(sort([1,2,3] == [1,2,3])
assert(sort([3,2,1] == [1,2,3])
...
如果是invariant testing大致如下：
function sorted(list)
if list == [] return true
else
for i from 0 to length(list)-1
for j from i+1 to length(list)
if list[i]>list[j] return false
return true
function test_sort()
loop 100000 times
assert(sorted(sort(generate_random_list()))
给一些参考：
http://stackoverflow.com/questions/766867/can-invariant-testing-replace-unit-testing
http://dan.bravender.us/2009/6/21/Simple_Quickcheck_implementation_for_Python.html
http://pypi.python.org/pypi/paycheck/0.4.2
http://www.haskell.org/haskellwiki/Introduction_to_QuickCheck
--
LIU
https://github.com/liuxinyu95/AlgoXY
On May 17, 2:27 pm, Stanley Xu <wenhao...@gmail.com> wrote:
> 用perforce做SCM, online command for code review, 你在google是吧
>
> Best wishes,
> Stanley Xu
>
> 2011/5/3 郭晓峰 <lamu...@gmail.com>
Shuo Chen
On May 17, 3:29 pm, "Larry, LIU Xinyu" <liuxiny...@gmail.com> wrote:
> Hi,
>
> 想起《程序员》杂志有一段时间，每期搞个我的工具箱的文章了。
>
> 流程这个东西的特点是，新的流程出来时候，总是被人追捧，大家眼睛一亮，觉得革命来了。
> 然后就是自上而下的强制推广，培训，认证，然后流程就给做烂了。
>
> 最后发现，好的软件总是那几个人做出来的，不管他们用什么流程，而有人能够用最革命的前沿流程生产垃圾，也是一个有趣的现象。
>
> 最后说起testing， 有没有人听说过invariant test?（不知道这个词是不是我发明的）
> 例如，你写了一个sort函数，通常的UT大致如下：
>
> assert(sort([]) == [])
> assert(sort([1]) == [1])
> assert(sort([1,2,3] == [1,2,3])
> assert(sort([3,2,1] == [1,2,3])
> ...
>
> 如果是invariant testing大致如下：
>
> function sorted(list)
> if list == [] return true
> else
> for i from 0 to length(list)-1
> for j from i+1 to length(list)
> if list[i]>list[j] return false
> return true
>
> function test_sort()
> loop 100000 times
> assert(sorted(sort(generate_random_list()))
>
> 给一些参考：http://stackoverflow.com/questions/766867/can-invariant-testing-repla...http://dan.bravender.us/2009/6/21/Simple_Quickcheck_implementation_fo...http://pypi.python.org/pypi/paycheck/0.4.2http://www.haskell.org/haskellwiki/Introduction_to_QuickCheck
>
> --
> LIUhttps://github.com/liuxinyu95/AlgoXY
Larry, LIU Xinyu
酷爱跑题，最近接触一家公司，他们在搞封闭开发。我不由得又想起上期《程序员》杂志专访ErLang的发明人Joe Armstrong的一个文章。
Armstrong说，他回忆起来，他写过的最好的程序都是在状态最好的时候写的。以前也熬夜写过，但是后来再看，那种方式写出的东西大部分
都是垃圾。
我对此深有同感，我大部分自己满意的程序都是在头脑清晰，身心健康的时候写的。有时一个问题困住了，如果硬拼，反而是头昏脑胀没有结果。
我有好几次都是在回家或者去上班的路上，一边散步，一边看景色，一边想出答案的。大自然秀美的景色能促进思维。
我很难想象程序员在封闭开发的环境下，熬夜苦斗能产生卓越的代码。
另外，对于趣题的解题时间，多长合适？是否在面试的几十分钟内能碰撞出思维的火花？也许我老了，我认为一周时间是一个比较理想的时间。
我记得Rechard Bird在他的书functional programming pearls里有好几次提到，他在班上或者沙龙提出一个趣题，
几天后有学生或者
其他朋友给出了答案。
为此我认为top coder或者google interview那种方式更多测试的是一种程序员的应激能力，当然另一种可能是我的确老了，不适合这
种
游戏，前阵面试google后，反馈说我的hands on coding能力太差...
乱喷了一通，抱歉。最后说一句： 的确有楼天成这样的天才适合在top coder/ACM竞赛中驰骋。祝他们能越走越远。
--
LIU
https://github.com/liuxinyu95/AlgoXY
On May 17, 3:29 pm, "Larry, LIU Xinyu" <liuxiny...@gmail.com> wrote:
> Hi,
>
> 想起《程序员》杂志有一段时间，每期搞个我的工具箱的文章了。
>
> 流程这个东西的特点是，新的流程出来时候，总是被人追捧，大家眼睛一亮，觉得革命来了。
> 然后就是自上而下的强制推广，培训，认证，然后流程就给做烂了。
>
> 最后发现，好的软件总是那几个人做出来的，不管他们用什么流程，而有人能够用最革命的前沿流程生产垃圾，也是一个有趣的现象。
>
> 最后说起testing， 有没有人听说过invariant test?（不知道这个词是不是我发明的）
> 例如，你写了一个sort函数，通常的UT大致如下：
>
> assert(sort([]) == [])
> assert(sort([1]) == [1])
> assert(sort([1,2,3] == [1,2,3])
> assert(sort([3,2,1] == [1,2,3])
> ...
>
> 如果是invariant testing大致如下：
>
> function sorted(list)
> if list == [] return true
> else
> for i from 0 to length(list)-1
> for j from i+1 to length(list)
> if list[i]>list[j] return false
> return true
>
> function test_sort()
> loop 100000 times
> assert(sorted(sort(generate_random_list()))
>
> LIUhttps://github.com/liuxinyu95/AlgoXY
Larry, LIU Xinyu
function sorted(list)
if list == [] return true
if len(list)==1 return true
for i from 0 to length(list) - 2
if list[i] > list[i+1] return false
return true
还有一个写法：
function test_sort()
loop 100000 times
xs = generate-random-list()
assert(soft(xs)=xs.sorted())
也就是用我的sort和系统库的sort对比。
Larry, LIU Xinyu
反思了一下，是什么导致了那个O(N^2)的sorted，这是由于，根据定义，sorted表达为：
sorted X = {for all i < j, ==> X[i] <= X[j]} where
1<= i, j <= length of X
而实际上，这个可以简化为X is in non-decrease order的表述：
sorted X = {for all i, ==> not X[i+1] < X[i]} where
1<= i <= length of X - 1
另: 这里X的下标从1开始
--
LIU
https://github.com/liuxinyu95/AlgoXY
SevenCat
还有很多项目最重要的是结构设计和类设计，这些好了后基本上也不需要卓越的代码，。
顺便说一下，我一直认为软件开发工具只是用来辅助或者帮助项目管理人员的，要是项目管理人员本身不会管理，那么再好的工具也没有用。
On 5月17日, 下午3时47分, "Larry, LIU Xinyu" <liuxiny...@gmail.com> wrote:
> Hi,
>
> 酷爱跑题，最近接触一家公司，他们在搞封闭开发。我不由得又想起上期《程序员》杂志专访ErLang的发明人Joe Armstrong的一个文章。
> Armstrong说，他回忆起来，他写过的最好的程序都是在状态最好的时候写的。以前也熬夜写过，但是后来再看，那种方式写出的东西大部分
> 都是垃圾。
>
> 我对此深有同感，我大部分自己满意的程序都是在头脑清晰，身心健康的时候写的。有时一个问题困住了，如果硬拼，反而是头昏脑胀没有结果。
> 我有好几次都是在回家或者去上班的路上，一边散步，一边看景色，一边想出答案的。大自然秀美的景色能促进思维。
>
> 我很难想象程序员在封闭开发的环境下，熬夜苦斗能产生卓越的代码。
>
> 另外，对于趣题的解题时间，多长合适？是否在面试的几十分钟内能碰撞出思维的火花？也许我老了，我认为一周时间是一个比较理想的时间。
> 我记得Rechard Bird在他的书functional programming pearls里有好几次提到，他在班上或者沙龙提出一个趣题，
> 几天后有学生或者
> 其他朋友给出了答案。
>
> 为此我认为top coder或者google interview那种方式更多测试的是一种程序员的应激能力，当然另一种可能是我的确老了，不适合这
> 种
> 游戏，前阵面试google后，反馈说我的hands on coding能力太差...
>
> 乱喷了一通，抱歉。最后说一句： 的确有楼天成这样的天才适合在top coder/ACM竞赛中驰骋。祝他们能越走越远。
>
> --
> LIUhttps://github.com/liuxinyu95/AlgoXY
>