论”高仿产品，是否该保存其代码，在既有基础上开发“

如果要高仿竞争对手的 Web 产品，是否该“保存页面源码，在既有代码基础上修改”呢？

不该

下面，我将抛却版权问题和法律纠纷，单从项目的发展角度上进行解释。

---

代码有两种形态：

1. 线上形态（产品形态）
2. 工程形态

线上形态，面向终端用户，要解决交互问题，实现：

1. 代码安全（尽可能地保护核心代码）；
2. 快速响应

要实现代码安全，需要“丑化”代码；满足“快速响应”，则需要合并、压缩文件。

工程形态，面向开发人员，要解决开发及维护问题，实现：

1. 高内聚，低耦合；
2. 尽量避免大文件，尽可能地以文件为单位分离模块；
3. 工程的可持续迭代能力；
4. 工程的可读性；
5. 工程的可复用性（尤其是做项目的公司，更要具备高复用能力）

由此可见，这两种形态的代码在表现形式上基本上是完全相悖的。

由工程形态向产品形态转化，是水到渠成，自然而然的过程，可以借助成熟的构建工具（如：gulp.js，grunt.js等）合并、压缩和丑化代码。
而由产品形态向工程形态转化，则是相当困难的，或者是高投入低产出。

举例子来讲，一粒种子长成参天大树的过程中，其每个时间点的形态都可以用其之前的形态进行解释，是确定的一条成长轨迹。但由参天大树向种子推演，却有无数种可能。
放在软件开发中，为了解决性能问题而加入的一段“魔法代码”，在反向推演其上下文所在的业务逻辑时，可能就会造成很大困扰。

内化同时的代码，需要时间和精力。没有段落和注释者更甚。更何况内化竞争对手的产品呢？

另一方面，没有人能保证“与XXXX一样就可以了”的需求边界，更不能确定那就是产品的最终形态，因为：

1. 样式或版面需要调整；
2. 功能需要调整或丰富。

而项目需求的满足，是建立在对工程强有力的控制的基础之上的。
一些特性看似简单，但实现起来可能牵一发而动全身。如果对工程的结构，以及模块之间的关联关系没有80%之上的掌握，那么会有相当大的几率把项目做失败。因为你无法预料每一步行动的后果是什么。