工作后的困惑:复杂一点的项目就写不好

royalpioneer
  • 46

目前开始工作了有一小段时间,担任前端开发,在之前练习算法以及写前端小demo时思路会很清晰,甚至可以达到bug free的状态。

但是在工作中,接触到的需求都稍微有些复杂,需要结合之前实现过的代码,以及正在采用的组件库来实现预期的需求,这种情况下我的实际开发就有点吃力了。

我大致总结了下原因:

1、对以前的代码不是特别熟悉,只是看了看哪一块大致实现的是什么内容
(当然有些之前的代码很乱,这就让我感受到地狱难度了)

2、思路不是很清晰,听完需求后感觉只要先这样再那样就可以了很简单,但在实际写的时候遇到苦难重重

3、前后端的职责分的不是很清楚,一些处理数据的功能可能都要交给我来做

目前的情况不知是否哪块能力有所缺失,希望大佬们能给点练习和提升的建议

回复
阅读 530
2 个回答

这个总结很好,都是很突出的问题。

  1. 阅读旧代码,尤其是前端业务代码本来就很复杂,一部分原因对于业务开发理解就会有差错,开发过程中,交互开发细节太多(也就是有大量的业务之外的代码),这简直就是天然的代码加密,再加上js语法自由,每个人都可能有自己的代码开发风格,这就更好玩了,再加上CV党的泛滥。所以我很少维护旧代码,有时间就重构。
  2. 对于需求的理解,需要很多细节把握甚至包括你对于需求提出人的讲话风格的了解,沟通这个事情是一个很深的活计,也是需要足够的经验积累。
  3. 前后端分离,是这些年互联网发展,尤其是大量2C业务发展来的,以前的程序开发哪来什么前后端的区别。 不要限制自己的技能,前后端都是需要的,至于一个功能两边都可以做,这个对于整个系统来说是好事情,很利于合理利用开发资源,谁有时间就谁做啊。前提是有足够的能力做好评估。

问题一:

“以前的代码”你指的是别人写的吗?如果是自己写的隔几天都不认识了,可能你就要挨打了(手动滑稽)。

弱类型语言就是这样,Coding 一时爽,Debug 火葬场。后期维护会很痛苦。

再加上前端项目往往没什么整体上的架构规划。一方面是团队协作无法避免代码质量良莠不齐,如果没有良好的制度去约束,很容易就形成“屎山”。

另一方面是国内很多项目的负责人信奉所谓的“敏捷开发”,问题是人家微软脸书的团队是啥素质?你那团队是啥素质?人家是提前有了清晰思路和迭代规划,为了小步快跑用的敏捷;你那是啥都没想好就想先赶紧弄出一个东西来给老板交差。这种情况下,前端、甚至后端的开发人员,很难有时间去思考怎样进行自顶向下的设计,项目里也往往会充斥着每次迭代时的“胶水补丁”,日积月累,越来越难以维护了。

这个不单是你的问题,而是大部分人都有的痛苦。确实没什么好的方式,如果你是 Leader,你可以在条件允许内增设各种软件工程上的手段来尽量减少“屎山”的形成;如果你不是,那我只能说,管好你自己。


问题二:

我想来认为,开发人员一定也要熟悉业务,不要觉得这这是产品或运营的工作。

一个不熟悉业务的开发人员,是很难写出好项目的。

这个问题只有多沟通一条路解决。


问题三:

这个问题其实不是前后端的问题,其实就是数据提供方和数据使用方的职责问题。

在后端同样有这个问题:服务间调用时,两个服务两隔团队做的,数据格式、通信方式、调用流程,听谁的?

在前端本身里还是有这个问题:写公共组件的人和写业务代码的人,大项目里往往是不同的人,到底是组件去适配业务、还是业务去适配的组件?

上述问题的答案,没有公论。一个好的技术 Leader 是去评判、去取舍、去沟通这些问题的人。

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
宣传栏