在看完这篇文章后，还有一点让我印象深刻。分工的重要性，说道分工那就不得不提组长这个职位，一个团队中
必须选出一个决策者，这样在遇到大的事情时才会有人做决定，组长在团队中起到了领头羊的作用，组长必须根据
每个成员的特点对其进行分工，只有一个好的分工才能保证项目又快又好的完成。分工完成后就到了团队成员的磨
合期了，每个人有每个人的主见和思想，所以在很多事情上可能会争执起来，这时候该组长出面了，组长既要做一
个正确的决定还得安抚好每个成员的情绪，让每个人不能把情绪带到工作中去。作为这个组的一个成员，我觉着每
个人也应该控制一下自己的小情绪，在一个团队中，只要每个人都能够包容一点，那么无论大事小事都不会产生伤
和气这种事。
我认为一般有过面向对象编程的人，认为最难也最头疼的就是设计了。一个好的项目，设计至少可以占到百
分之五十甚至更多。关于设计的争论由来已久，在我看来，这是由行业性质决定的，软件行业毕竟是为其他行业服
务的，因此分门别类，随着经验的增长业务能力逐渐要大过编程的能力，因此，程序决定业务还是业务决定程序就
成了唯物和唯心的交火点，虽然近年来业务决定项目的争论已经拔得头筹，但是旧恶难消，仍有不少人坚决维护先
决定项目框架，再分析业务配套相关技术的思路，这部分人，如果不是面向过程的年代发展过来的，一定是书呆子
。业务决定项目，项目决定框架，框架决定编程语言，话说到底，根本原因是软件行业是服务行业。这是根本，不
要迷惑。
作为一个程序员的资历和价值并不是以你所知道的东西来衡量的，而是通过你做出多少成就来衡量的。这两者是
相关的，但又有本质的不同。你的价值是你如何推动项目前进，如何鼓励你的团队也这样做。在我十五年的开发生涯
中，我从来没有需要实现一个冒泡排序算法和短链算法。不过，我花费了成千小时来编写和重构账户管理工具，编辑
套件，缓存逻辑，邮件接口，测试套件，部署脚本，JavaScript分层，分析架构和文档。这些都是有价值的事情，完
成了这些事情推动了我们的前进。
那些微小的组件是构建项目的砖瓦和沙砾，需要成百上千小时的辛劳工作来组建。尽管它们被用来组装复杂系统，它
们本身却不应该是复杂的。你应该将简化这些组件作为目标。多年来，我学会简单可以通过假以时日的不断工作和重
构来达到，而这比纯粹“灵感一闪”的思考更容易得多。
简单和卓越通过一些事情或者任何可以让工作完成并从回头重新审视这样的过程来不断完善，这是最可靠的路径。这
也是那些公司和MVP试图深入我们意识观念的真谛，软件也是如此。从一些可工作但丑陋的解决方案开始，你不断应用
这个丑陋和怪异的方案，不断重构它为最简单的形式。简单从工作中比“灵光一闪”来得更为可靠。通过写代码比费力
思索更加可预期。简单来自努力。