摘要：
只有在将任务分解给参与人员后他们之间不需要互相交流的情况下，人数和时间才是可以互换的。在实际软件项目中，只要项目具有一定规模，不论是设计、开发、测试、部署各个阶段都会有分解任务给不同人员，而且这些阶段本身也属于一种任务的分解，在不同人员间分解任务就不可避免的引发额外的沟通成本——培训和相互沟通。因为 阅读全文
摘要：
7. Herzberg, F., B. Mausner, and B. B. Sayderman. The Motivation to Work, 2nd ed. London:Wiley, 1959.8. Cox, B. J., “There is a silver bullet,” Byte ( 阅读全文
摘要：
在对于任务分解上，看似越多的人会减少个人工作的时间，实则不然，人员的增多会导致其他方面诸如培训和交流之间的开销的增加，导致很快会消耗掉任务分解所节省下来的时间，有时未必会减少时间。不要妄图以减少时间为目的进行相关的人员方面的变动，或是项目上的调整，提速是可以的，但是首先不要贪心，其次记住欲速则不达。 阅读全文
摘要：
经过长达7天多的时间，从Android studio的安装碰到很多的问题，真的很不走运，别人安装Android studio都是一气呵成，我的Android真的没话说 把自己的这些天的开发成果展示一下 做的还是很粗略，感觉自己应该多敲一些代码啦，敲代码太慢了，还有很多不懂的， 现在我总结一下这些天遇 阅读全文
摘要：
今天继续研究了一下制作了一个简易小相册 代码附上 mainActivity.java package com.example.xiangce; import androidx.appcompat.app.AppCompatActivity; import android.os.Bundle; imp 阅读全文
摘要：
一个目标产品本身能有多大的代码量大致不会和预算的相差很多. 这时我的经验, 当然也有一些连代码量也估算不准的LEADER. 我们通常会最终会将代码量分解到每个模块, 并且根据程序员的工作能力来分配进度要求. 在很多情况下, 遇到进度失衡的时候, 第一反应是增加人手. 但是事实上增加人手的项目不到10 阅读全文
摘要：
人们总是希望一切的事情都尽在掌握之中，所以总是试图在制定完美计划之后一路顺风顺水地执行下去。但是软件维护是一个提高混乱度（增加熵）的过程，所以出现前进两步，后退一步；甚至前进一步，后退一步都是很正常的。而且随着维护的深入，会发现用在修复原有设计上瑕疵的工作量越来越少，而早期维护活动本身所引起的漏洞的 阅读全文
摘要：
软件内在特性： 复杂度：没有两个软件的部分是相同的，软件不存在重复的部分。软件实体的扩展会导致软件元素一非线性递增的方式交互，软件必然会越来越复杂。复杂度不仅导致技术产生苦难，还引发了很多管理上的问题。因为管理者越来越难以完整的理解问题。 一致性：软件领域不存在像物理学那样“对于事物简化的解释”，软 阅读全文
摘要：
文章提到了编程行业提供了乐趣、苦恼的说明，也印证了自己的一些想法。其中，对我而言：”面对不重复的任务、持续学习的乐趣“最为贴切。这也是推动我内心 — 多学一点、多付出一些，你就比别人更牛一点的潜在动力（个人认为：开发靠的还是硬实力，长久来看，薪资待遇和能力总会成正比！）。然而，痛苦却句句扎心?，都说 阅读全文
摘要：
给我很大的启迪：我们选择让一个人完成一个构想的基础功能很容易，但是想让其演化成通用的工具、乃至产品，投入的成本要比想象大的多，且不可一蹴而就，需要不断的衍变，并非一次性设计而来，当然这个过程中，对于文档的投入也是一个重要的部分。（个人比较坚信：好的架构源于不停地衍变，而非设计） 阅读全文