合理的分工可以提高总体产能
因为员工可以专注，大幅度提高生产效率，再通过合理的过程将不同技能的员工组织起来，总体产能就可以大幅度提高。
在软件开发业，分工的效果似乎并不象制造业那么明显。
主要是由于双重复杂度引起的，即业务复杂度和技术复杂度。
由此形成了两个主要的分工模式
分析、开发、测试的分工方式可以分离技术复杂度，但无法分离业务复杂度。
第三方产品、框架在不同的层次上分离业务复杂度，在部分框架极为成熟的领域，如三维设计、游戏开发，团队主要关心业务复杂度，而次要关心技术复杂度。
分工后就会产生新的对人力资源的需求，由于分离了复杂度，从而对人力资源需求的高度可以有所降低。
就目前而 ...
看到一篇文章，提到学术PK(academic PK)，简称APK
觉得挺有趣的，可能适合用于公司内的新技术推广
1 APK 参与者为三队，K队为问题/论题主讲方，是自以为掌握了该问题的人（king of this problem），想通过APK来验证，加深自己的理解。
P队为挑战方，主要是由想深入掌握该问题的人组成（不排除也自以为熟悉该论题而想挑刺为乐的人 pauli type），也愿意为了P赢而事先做点准备，准备一些基于指定核心材料相关的问题（如个人疑点）。
A队为听众audience，不愿花太多时间只想了解下的人，除了选几个代表评判记分和笔记，其它都临时随意，这倒有点类似研究生的论文答辩 ...
勾股定理是大家都很熟悉的，课本上也有证明。
从一般知识获得的角度，事情就到此为止了，接下来就是如何应用这个知识了。
然而从数学研究的角度，有很多个方向可以不断深入：
1、是否有其他的证明方法？通过不同的证明方法的讨论可以获得更多的思路
2、该定理是否“放之四海而皆准”？是否有隐含的“必要条件”（勾股定理只在欧氏空间中成立，在非欧空间中不成立），如果必要条件不满足，那么是否有同样的结果？
3、该定理是否可以进一步推广？（费尔马大定理是该定理的一种变化的n阶推广）
……
转换到软件开发领域，第1点对应的就是重构，第二点对应的是需求获取中的完备性，第三点是软件开发较少考虑的，属于业务分析的 ...
看来大家对数学还是很有兴趣，但我还是很遗憾的看到大多数人对数学和软件开发的理解还是数学算法这个层面。
那么我继续尽我所能来揭示数学和软件两者思考的共通性。
这次考虑的是重构，要点之一是不要重复，因此需要找出几段代码之间的共同点。
从数学角度考察两个多项式
x^2-5x-6和x^2+4x+3
哪一部分是重复的呢？
从表象上看似乎是x^2，但是深入的考察发现两者可以被改写为以下的形式
(x-6)(x+1)和(x+1)(x+3)
那么x+1也是一个共同点，而且从数学直观上来讲,x+1是更“简洁”的共同点。
如何从各类形式上类似甚至形式上不类似的代码中发现其“本质”的共同点，是需要一点洞察力 ...
数学和软件
在我个人的软件开发过程中，自认为得益于数学基础训练较多，但具体有何联系，又感觉说不太明白。
正好论坛中有人提及，借此机会整理一下自己的思路，和大家共享。
用户说：金额大于50万的合同，需要部门经理审批，金额大于100万的合同，需要总经理审批。
用数学语言表述，可以相当于这样一个函数
处理流程=F(合同金额)，根据合同金额的差异进行不同的处理
一般情况下，合同金额可以视为一个自然数集合（从1到无穷），很明显的，<大于50万>和<大于100万>不是这个自然数集合的完备划分。
第一：这两个集合有交叉，大于50万的集合显然包括大于100万的集合
第二 ...
主要由分析和设计人员，分析人员负责用户沟通和谈判，兼用例级别的测试，设计人员兼开发和单元测试
4小组轮流不间断实施，2-4对一组，6小时一换。
另外有独立的公共支持组，专门负责过程中的各类记录和分析/后勤支撑。
一年工作六个月，三个月训练/培训/学习/模拟新战术，三个月纯休假。
系统涉及部门很多，有使用部门、维护部门、多个软件开发商、硬件厂商、系统软件厂商等等
有时系统会出问题，出了问题不能随便修，一旦修坏了就要背好大的责任，一定要先写问题报告，而这份报告的写法就很有讲究了。
又分为两类，一类是问题还没有解决，另一类是问题已经解决
对于问题还没有解决的
1、整体情况说明。
要点：突出情况已经得到控制（影响范围必须是明确的，必须有解决方案）
2、问题陈述。要点：客观，不要在这一节指责任何人。
3、处理过程。
这一部分是最最有讲究的，要精确、客观，隐约体现出责任归属。
例如：1月2日凌晨3：05，接用户报障电话，称系统于1：00左右出现故障，无 ...
试图将用户需求合理的划分到M/V/C各个层次上，往往不是那么轻松的事情。
一个很简单的例子：人员管理。对象包括部门、人员。一个部门下可以有多个人员。
在普通的增删改查操作下界限是清晰的。
需求1
要求在部门列表、部门编辑时展现部门内的人员总数。
这个值加在哪里？
M:将这个统计数视为部门对象的一部分。这种设计思路一直是很有争议性的
C:临时性获得这个值，似乎是比较正统的做法。
V:需要显示这个值，基础框架搭的好的V很可能不用变动代码。
需求2
要求在部门列表、部门编辑时针对不同的人员总数的值显示不同的颜色，0-10个人的部门用黑色，11-50的部门用黄色，51以上的部门用红 ...
clamp
- 浏览: 49262 次
- 详细资料
搜索本博客
最近加入圈子
最新评论
-
数学和软件
对我们一般程序员来讲，如果将两者结合起来，是有相当难度的。不但要掌大量高等数学知 ...
-- by blackanger -
数学和软件
我觉得软件开发有个三个主要问题：做什么；怎么做；为什么这么做。数学有助于后两个问 ...
-- by cookoo -
数学和软件
hurricane1026 写道庄表伟 写道数学<>逻辑学 软件开发，更 ...
-- by cookoo -
数学和软件(3)——从勾股 ...
不否认软件和数学有一定的关系，但是这样的对应关系是不是有点牵强了。。。 。。。 ...
-- by blackanger -
数学和软件
我的理解是： 数学好的人，可以把软件用纯数学的语言来描述，这种方式也许只能数学水 ...
-- by blackanger
评论排行榜