写在之前：今年年初给自己安排了任务，每个月写一遍感悟性的文章。促使自己沉淀并思考。 这篇文章的内容本来只是一些想法， 想想还是记下来。几年以后自己再读这篇文章也许是另一种体会吧
编程和软件工程之间有三个关键的区别：时间、规模和权衡
1. 了解时间变化
When a novice is learning to program, the life span of the resulting code is usually measured in hours or days. Programming assignments and exercises tend to be write- once, with little to no refactoring and certainly no long-term maintenance. These programs are often not rebuilt or executed ever again after their initial production. This isn’t surprising in a pedagogical setting. Perhaps in secondary or post-secondary education, we may find a team project course or hands-on thesis. If so, such projects are likely the only time student code will live longer than a month or so. Those developers might need to refactor some code, perhaps as a response to changing requirements, but it is unlikely they are being asked to deal with broader changes to their environment.
大意：当新手学习编程时，编码的生命周期通常以小时或天为单位。编程作业和练习往往是一次编写的，几乎没有重构，当然也没有长期维护。这些程序通常在初始生产后不再重建或再次执行。这在教学环境中并不奇怪。也许在中学或中学后教育，我们可以找到团队项目课程或实践论文。如果是这样的，项目很可能是学生们的代码生命周期超过一个月左右的时间。这些开发人员可能需要重构一些代码，也许是为了应对不断变化的需求，但他们不太可能被要求处理环境的更大变化。
上面的这段话是很多人都有亲身经历， 在中国一个软件维护5年以上很少.一个连续工作多年的开发人员可能有10年的开发经验，鲜少或根本没有维护任何预期存在超过两年的软件的经验。web应用和移动应用有可能更短。可见很多的开发人员都是短期代码的开发人员。短期项目的开发人员对系统维护和系统升级并不了解。
实际上一些项目周期很长，甚至是无生命截止日期， 比如京东商城，天猫超市，金山WPS等。参与一个长期项目会有更多的不同感受，下图展示了项目生命周期和升级的重要性的。当做一个短期项目时，比如一个创业项目，项目会考虑快速完成， 升级并不重要，因为一段时间后项目就废弃了。当项目时间变长以后，为了提供更好的性能，扩展性，安全性等因素，“系统升级”变得十分重要。低点和高点表明某处有一个过渡,当到达一定阶段的时候，项目必然要对外界变化因素（需求变更、技术更新等）做出反应
随着时间拉长应用系统必须得到升级， 有一项定律就变得尤为重要。 海勒姆定律(Hyrum's Law)也叫隐式接口定律， 维基百科中对此定律的解读是:有足够数量的API用户，您在公约中承诺的并不重要：系统的所有可观察行为都将取决于某人。 也就是说当API有很多的使用者时，API的某些说明和未说明的内容都会变成依赖的部分。
维基百科的解读怎么理解呢 ？举一个例子，我参与的某个项目中有个API接口， 当接口检测某些业务异常的时候，就会返回一些异常描述。调用者一般都会直接提示描述信息。 当使用此API接口的人多的时候，总会出现有人因某个特殊原因做一些特殊处理， 比如用正则或者其他匹配规则将某些提示归类然后再实现自己的业务。 虽然这个API接口中没有声明的有哪些异常，但这个异常一旦发生变化，就会影响到某些调用者的业务。这就让系统升级变得很难。很多情况下牵一发而动全身
海勒姆定律是软件随时间变化必然会发生的，不可避免。因此需要时刻意识到，API总会有人用意想不到的方式来使用，所以尽可能的降低影响范围
2. 规模与效率
One of the broad truths we’ve seen to be true is the idea that finding problems earlier in the developer workflow usually reduces costs. Consider a timeline of the developer workflow for a feature that progresses from left to right, starting from conception and design, progressing through implementation, review, testing, commit, canary, and eventual production deployment. Shifting problem detection to the “left” earlier on this timeline makes it cheaper to fix than waiting longer, as shown in Figure 1-2.
大意：我们看到的一个普遍真理是，在开发人员的工作流程中发现的问题，通常可以降低成本。考虑开发人员工作流程的时间表，从左到右，从概念和设计开始，通过实施、评审、测试、提交、金丝雀和最终的生产部署来进行。在此时间线之前，将问题发现转移到“左侧”会使修问题解决成本更低，如图所示
当规模扩大后，项目管理往往比项目开发更能提高效率， 软件项目管理又不得不提到“左移原则” 。即 安全问题不能推迟到开发过程的最后阶段，必须要求“在安全上向左转移”，提交之前通过静态分析和代码审查发现的bug要比投入生产的bug成本更低。在开发过程的早期提供高质量、可靠性和安全性的工具和实践是许多基础架构团队的共同目标
下图是一个反例，这是一年的外网问题统计，当我们减少了项目流程以达到快速交付了项目的目的。开发阶段人员自测不足，测试阶段没有完整测试，自从化测试范围不不等因素造成项目后期BUG数量飙升， 维护成本飙升，团队疲于奔命排查问题，客户抱怨问题太多质量不足。 这个项目并不是软件工程“最佳实践”，它违反了左移原则。虽然从交付时间上看软件开发的项目效率提高了，但是项目整体效率却是降低的。
3.权衡
Finally, the most precious asset of a software organization—the codebase itself—also needs to scale. If your build system or version control system scales superlinearly over time, perhaps as a result of growth and increasing changelog history, a point might come at which you simply cannot proceed. Many questions, such as “How long does it take to do a full build?”, “How long does it take to pull a fresh copy of the repository?”, or “How much will it cost to upgrade to a new language version?” aren’t actively monitored and change at a slow pace. They can easily become like the metaphorical boiled frog; it is far too easy for problems to worsen slowly and never manifest as a singular moment of crisis. Only with an organization-wide awareness and commitment to scaling are you likely to keep on top of these issues.
大意： 最后，软件系统最宝贵的资产代码库本身也需要扩展。如果你的构建系统或版本控制系统随着时间的推移呈超线性扩展，也许是由于内容增长和不断增加的变更日志历史，那么可能会出现无法持续的情况。会持出现许多问题，如“完成完整构建需要多长时间？”、“拉一个新的版本库需要多长时间？”或“升级到新语言版本需要多少成本？”都没有受到有效的监管，并且效率变得缓慢。这些问题很容易地变得像温水煮青蛙；问题很容易慢慢恶化，而不会表现为单一的危机时刻。只有在整个组织范围内提高意识并致力于扩大规模，才可能保持对这些问题的关注。
这段原文中，对“系统最宝贵的资产是代码库” 这句话有很深的理解，之前的公司理有个系统运行了近十年。（没有升级的原因有很多，这里不做讨论），因为框架限制，导致一些核心业务开展受到了影响，因此系统必须要升级。 公司领导作了一个决定，他们决定在最新框架下重新开发一套新的系统。2年后系统终于上线，上线后问题又程指数增长。升级整体成本巨大
我想一个核心软件完全抛弃代码库重新开发的做法并不一定是最佳实践，舍弃原来的代码，也许是认为重写比维护容易吧。但舍弃了原有代码库其实就是舍弃了积累的经验，我认为软件工程中经验是很宝贵的财富。 一蹴而就的完成系统替换也不是最佳实践， 开发周期很长看不到落地。
409
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
