工作后的困惑：复杂一点的项目就写不好
目前开始工作了有一小段时间，担任前端开发，在之前练习算法以及写前端小demo时思路会很清晰，甚至可以达到bug free的状态。
但是在工作中，接触到的需求都稍微有些复杂，需要结合之前实现过的代码，以及正在采用的组件库来实现预期的需求，这种情况下我的实际开发就有点吃力了。
我大致总结了下原因：
1、对以前的代码不是特别熟悉，只是看了看哪一块大致实现的是什么内容
（当然有些之前的代码很乱，这就让我感受到地狱难度了）
2、思路不是很清晰，听完需求后感觉只要先这样再那样就可以了很简单，但在实际写的时候遇到苦难重重
3、前后端的职责分的不是很清楚，一些处理数据的功能可能都要交给我来做
目前的情况不知是否哪块能力有所缺失，希望大佬们能给点练习和提升的建议
回答：
这个总结很好，都是很突出的问题。
- 阅读旧代码，尤其是前端业务代码本来就很复杂，一部分原因对于业务开发理解就会有差错，开发过程中，交互开发细节太多（也就是有大量的业务之外的代码），这简直就是天然的代码加密，再加上js语法自由，每个人都可能有自己的代码开发风格，这就更好玩了，再加上CV党的泛滥。所以我很少维护旧代码，有时间就重构。
- 对于需求的理解，需要很多细节把握甚至包括你对于需求提出人的讲话风格的了解，沟通这个事情是一个很深的活计，也是需要足够的经验积累。
- 前后端分离，是这些年互联网发展，尤其是大量2C业务发展来的，以前的程序开发哪来什么前后端的区别。 不要限制自己的技能，前后端都是需要的，至于一个功能两边都可以做，这个对于整个系统来说是好事情，很利于合理利用开发资源，谁有时间就谁做啊。前提是有足够的能力做好评估。
回答：
问题一：
“以前的代码”你指的是别人写的吗？如果是自己写的隔几天都不认识了，可能你就要挨打了（手动滑稽）。
弱类型语言就是这样，Coding 一时爽，Debug 火葬场。后期维护会很痛苦。
再加上前端项目往往没什么整体上的架构规划。一方面是团队协作无法避免代码质量良莠不齐，如果没有良好的制度去约束，很容易就形成“屎山”。
另一方面是国内很多项目的负责人信奉所谓的“敏捷开发”，问题是人家微软脸书的团队是啥素质？你那团队是啥素质？人家是提前有了清晰思路和迭代规划，为了小步快跑用的敏捷；你那是啥都没想好就想先赶紧弄出一个东西来给老板交差。这种情况下，前端、甚至后端的开发人员，很难有时间去思考怎样进行自顶向下的设计，项目里也往往会充斥着每次迭代时的“胶水补丁”，日积月累，越来越难以维护了。
这个不单是你的问题，而是大部分人都有的痛苦。确实没什么好的方式，如果你是 Leader，你可以在条件允许内增设各种软件工程上的手段来尽量减少“屎山”的形成；如果你不是，那我只能说，管好你自己。
问题二：
我想来认为，开发人员一定也要熟悉业务，不要觉得这这是产品或运营的工作。
一个不熟悉业务的开发人员，是很难写出好项目的。
这个问题只有多沟通一条路解决。
问题三：
这个问题其实不是前后端的问题，其实就是数据提供方和数据使用方的职责问题。
在后端同样有这个问题：服务间调用时，两个服务两隔团队做的，数据格式、通信方式、调用流程，听谁的？
在前端本身里还是有这个问题：写公共组件的人和写业务代码的人，大项目里往往是不同的人，到底是组件去适配业务、还是业务去适配的组件？
上述问题的答案，没有公论。一个好的技术 Leader 是去评判、去取舍、去沟通这些问题的人。
以上是 工作后的困惑：复杂一点的项目就写不好 的全部内容， 来源链接： utcz.com/p/936157.html
