问题分析

以下都是我个人观点，难免有失偏颇，请老板谅解，为了节约字数我自动省略我认为，我觉得这样的开头了。

一、web 端开发问题分析

问题一:开发框架。

目前，我们的项目并没有使用流行的前端开发框架来做，通过逐步了解代码和业务，我也理解了其中的原因，就现在来说彻底推倒不利于当前的业务发展。 

但是我认为或许推倒是早晚要做的事，我和师傅讲过一个问题，就是现在的比较年轻的前端开发，很有可能开始就接触的是框架，我之前在好未来的小朋友都是这样。用框架的好处就是门槛较低，易上手，融合进项目成本低。我不知道未来我们web团队会有几个人，人越多现在的项目越不容易维护。举例说明，类似页面生命周期的工作，现在我们的项目是在viewController和moduleHandler里做的，如果在同一个页面修改不同模块，哪怕不同的人做不同模块，一样会涉及频繁多人修改同一个文件的情况，我觉得继承解决不了这个问题。

问题二:前后端分离。

前后端理想的状态，就是所有通信都是通过api调用，通过完全的数据化来实现两端业务同步。

前后端耦合在一起给项目造成的问题：1.前端工程化构建，做不了，前端开发还需要花很大精力去维护项目结构，这都是无法在工作产出体现出来的额外的成本。

2.js的新语言特性用不了:写同样的逻辑时，效率低，代码可读性差。拿遍历数组来说，本来有很多基于使用场景的方法，一看就知道想通过对数组的操作，来得到什么，现在基本只能用for循环，不结合上下文很难理解代码想做什么事情。

3.没有状态管理:页面状态基本是后端在控制。

4.加载速度慢:现在核心页面如所见所得加载太多资源，太多js文件，这问题不做前端工程化不好解决。

5.代码暴露:现在在网页端可以直接看到我们的代码。同样不做工程化不好解决。

6.不方便调试:没有本地环境调试很不方便，都需要提交到服务器去看效果。

问题三:项目代码管理与维护。

目前我们的项目需要对不同版本书作支持，因此有相当多重复的代码，会给阅读的人造成较大的困难。我希望能把用不到的代码去掉，不然以后理解成本会越来越高。就现在来看应该没时间做这事。

二、开发问题分析

问题一：重构。

大部分程序员可能都会经历代码重构。人员变动，技术革新，基础架构支持，都会导致这件事的发生。重构这个工作，我认为隔一段时间就要进行一次，区别在于范围的大小。

重构的好处:

1.项目发展过程中，总会有没有考虑到的业务易发生变动的部分，或者代码架构不够稳定导致容易出现bug的情况，这些问题往往是在预期工作时间范围之外的情况，重构，可以使得这部分内容得到改善，比如把易变动的逻辑改写的扩展性更好，把硬编码完全去除等等；

2.对人的提升，重构对参与重构人有非常大的好处。

从业务角度：对那一部分业务逻辑更加熟悉，而且理解的更加深刻。如果是人员稳定的公司，好处则更加显而易见，每个人都熟悉了公司业务，能抵抗人员变动对项目造成的风险。

从技术角度： 重构让技术人员有机会尝试一些更加合理的技术框架和更新的解决方案。毕竟，新东西的出现和流行，一定是因为它解决了以前东西解决不了的问题。

问题二:技术驱动和业务驱动。

从业务角度:

我们现在的情况，基本是业务驱动，业务需求出来，怎么想办法用现在已有的东西把业务拼凑出来。这样做的好处，就是做的比较快，不好的地方，就是需要在需求上做取舍，一般都不能实现的比较完美。

从技术角度:

没有太多进行技术探索的机会，开发人员技术不容易通过业务提升。产品的科技感不容易体现，产品细节不容易有亮点。

问题三:技术分享。

技术分享的好处是:一个人深入了解某个技术点，带领一群人对这个技术点有印象。从眼前看，似乎没什么用，但是跨端了解技术知识从长远角度来说好处很大，能降低沟通成本。而且我理解的一个技术团队，不是互相有事没事都陪着一起加班，而是能有共同进步、共同学习的意识，这点是技术团队的基因，如果从一开始就没有，我担心以后也不容易有。

结语:技术和业务，永远是两难，想结合的很完美真的不容易。业务是公司生存的根本，技术是产品立足的根基，哪一边都不能瘸腿。

三、团队管理方面的想法

目前我认为公司处于一个正在从扁平化管理，员工直接向CEO汇报，转向产生中层管理，CEO逐步脱离过于细碎繁琐事务处理的阶段。这个时候，其实需要中层管理者让CEO看到没有她参与的项目迭代周期，也可以无差别交付结果的，所以这个时候需要的是更加严苛的管理，CEO这时需要的是安全感，可以放心的把后背交给战友。从我的角度，这个阶段出现的一切人的冲突和事的冲突都是正常现象，就像换挡需要重新磨合一样。所以现在觉得项目经理和产品经理都很不容易，夹在中间会有较大压力。理解归理解，问题我认为也有一些：

1.工时提前估算：

比较快速的项目迭代，需求其实是十分不稳定的，如果要求工时估算准确，那么需求就也要准确，个人认为这无法形成闭环。根据个人经验，SWOT法则在项目迭代中，威胁往往容易被忽视，实际经历的这一期迭代也验证了我这个看法。比如方形相册，我开始对产品不熟悉，只在需求评审上听大家说，跟照片书一样，结果后来我理解，只是针对编辑态基本一致。核心的内容一定会衍生许多附属的内容，这些是威胁，容易被忽视，在需求评审时候，小师傅会考虑的更多更全面。

2.对于项目管理的理解：

项目管理，我觉得不光是对事的管理，还应该包括对人的管理，甚至对人的管理更加重要，因为人的提升对于公司业务是一个长期的利好，而项目的进度仅仅是这一阶段的任务。

3.复盘会:

大多数时候只是对事的复盘，我不觉得对以后做项目有特别大帮助，因为人其实是很健忘的，如果不在项目过程中潜移默化的去影响每个团队成员，仅靠一次复盘会可能作用不大。

4.对于加班的理解:

加班很正常，如果我就住在附近，就也没什么问题，只是综合时间和钱来说，成本有点高。

时间成本:我个人并不是要以技术为终点的人，因为我不确定五年后我是否还能靠这个吃饭，需要做一些准备，所以下班会花时间看各种东西。工作和生活还是不太容易权衡。

5.代码成就感:现在研究逻辑的时间远大于写代码的时间，有时候自己也觉得很挫败，总打扰师傅也觉得不合适，毕竟都有任务在身。

四、产品方向的想法。

最近我们的产品，比如照片冲印，需求来源于竞品吧。我在想我们能不能优化现有产品的交互，加一些小而精致的内容在现有产品里，而不是累加新东西。这点想法是我个人对产品的体验。除了平台性产品，其他任何产品吸引我的大部分都是一个点，不是一堆复杂的内容。举例说web端，基本没有什么特效，十分古老，主要现在这个项目也很难加进去这些内容，没有做样式分离。

总结一下，其实目的很简单，就是高效并高质量的完成业务需求，但是，面对最后的产出，我觉得老板可以面向结果，但是公司和员工的发展需要面向过程。