当前位置:Gxlcms > PHP教程 > 程序员如何挽救日渐失控的项目?

程序员如何挽救日渐失控的项目?

时间:2021-07-01 10:21:17 帮助过:5人阅读

回复内容:

以上的情况,都遇到过。
典型的一个业务导向的公司,糙猛快的开发习惯,缺乏懂技术通产品,能控场能抵抗业务压力的技术话事人。随着时间流逝,开发无规,代码堆积,人员流动,能力下滑,架构腐化,逐渐走向结构性崩溃的场景:业务压迫带来了贴膏药的代码,膏药代码导致更大的技术压力,人才流失,疲于奔命,然后带来更大的业务压力。就像飞机掉入了失速螺旋,怎么也改不出来。
曾经花了半年时间,带团队花大代价改出过这样的恶性循环,花了大几百个人日全面重构一个有7、8年历史的老系统,代价是自己的当时绩效对外不好看。
所谓善战者无赫赫之功,此之谓也。
前人栽树,后人乘凉。 干这种活,没有识货的老板,是吃力不讨好。

千言万语,凝聚成一句话:全公司要有靠谱的技术管理和技术文化。这是CTO的职责。
给你归纳翻译一下,问题简化为这些:
  1. 如何提高代码质量?【开发能力】
  2. 如何提高架构水平?【架构能力】
  3. 如何控制产品需求的合理性和迭代节奏?【项目管理-需求分析/项目规划】
  4. 如何降低加班强度?【项目管理-资源管理】
  5. 如何积累知识库,降低口传心授的依赖?【团队建设-知识库建设】
  6. 如何提倡团队合作文化?【团队建设-价值观建设/绩效设计】
  7. 如何培养团队技术梯队,不强依赖几个核心员工?【团队建设-梯队培养】
  8. 如何避免自有通过QA才能保障产品质量的困境?【开发能力-质量保障】
  9. 如何提升系统稳定性和可用性?【架构能力】
  10. 如何通过产品大图整理出清晰的业务模型?【架构能力-产品规划】
  11. 如何拒绝业务方的不合理需求?【项目管理-需求管理】
  12. 如何降低人员流失率【团队建设-可惜离职率】
  13. 如何在飞速发展的业务环境下回答以上问题?【可落地方案】


自顶向下,依次需要解决的点是:
  1. 价值观建设
    1. 提倡团队合作。提倡合作?然并卵,谁鸟你,一句现在很忙就把你憋死。作为leader,还是要搞好人际关系,靠刷脸去推合作。
    2. 提倡敬业和激情。自己先要成为榜样,不过重要的还是看激励政策。
  2. 绩效设计原则
    1. 重视拿结果,更重视执行过程。发现、表扬、提拔代码写得好,业务也玩的溜的人。管理不能停留在表面上,要到代码里去。
    2. 重视个人技术能力,更重视技术传承、培养人。诶,说你呢,没带过人的同学别想加工资,想晋升给我先带3个徒弟出来。
    3. 重视技术创新。天天重复自己的人,再老资格也要给他敲警钟,该fire就fire。挤出项目的时间余量给有想法的人做点不一样的事;必须要有一支发明家队伍,而不是码农队伍,所以,搞条鲶鱼进去动动风水,会有好处的。
  3. 产品研发流程
    1. 流程保护。和产品团队、业务团队磨合出固定的迭代流程和节奏,并能坚持下来,坚决抵抗不合理的需求和节奏,有理有据地向上反馈。
    2. 产品话语权。一个产品设一个技术owner,要具有对该产品的需求评审,设计评审权,开发人员要参与业务调研/业务分析,影响产品设计,争取产品规划和业务模型的话语权。避免成为单纯的技术资源,疲于奔命。
    3. 跨部门沟通。提前和产品部门沟通双方的预期和能力,将产品规划和技术规划结合起来考虑,3个月协调一次。
  4. 团队建设
    1. 人才梯队建设。高手不能太多,也不能太少。微妙,自己意会,橄榄形社会最有活力。
    2. hire and fire。60%流失率,这窟窿!还是先加工资要紧,狠狠加,先把队伍拉起来,才有余力做重构的活。
    3. 团队文化建设。不管是美国还是中国,哪个总统/主席,都得有个施政口号,让人知道你要干什么,分清敌我。
    4. 团队技术能力发展。先把人找齐了。。。
  5. 项目管理
    1. 敏捷也好,瀑布也要,反正要找个合适自己的项目流程,并严格灵活地执行下去。
    2. 加强项目复盘环节,code review。
    3. 维持一个合适的工作松紧度。
    4. 项目管理的精髓是什么》》》我个人认为是制度化,制度化的坏处其实非常多,但有一条好处,就值得我们采用:那就是有强大的理由能按我安排的时间、我安排的地点来打仗。优秀的pm无一不是时间管理的高手,敢于向试图越过制度胡乱插手的领导说不,这就是项目团队的福音。
  6. 系统架构
    1. 与实际需求相关,无非就是提升稳定性,可用性、可维护性、安全性的那些架构招数,譬如SOA、服务治理、中间件、负载均衡、降级等等。一个简单清晰可靠、可快速横向扩展的系统架构是基石。
  7. 业务架构
    1. 业务模型重构
    2. 模块化,插件化设计
    3. 平台化架构
  8. 产品质量
    1. 编程规范
    2. 设计模式
    3. 单元测试和自测
    4. QA 和 code review
    5. 故障复盘
  9. 组织发展
    1. 知识传承
    2. 挖掘技术深度和创新意识
    3. 内部培训和外部培训
    4. 鼓励创新的机制
写完回顾一下,自己都觉得好笑,有点空列大纲无法落地的感觉,呵呵,实际的困难肯定远远超出预期。要想改变一条船的航向,首先你得有舵手的影响力(成功资历,直接管理技术团队),其次获取船长(老板)的支持,再次你得真的知道正确的航向(怎么做),接着得到船员的支持(公司其他团队的理解),优化调动自己的力量(所有开发都认同你的理念,招聘合适的人才),然后还要避开暗礁(别让项目失败),通过一次次的胜利来巩固你的正义。

太他妈的难了,所以很多人都劝你开溜,他们是对的,因为99%的老板都看不懂以上这些文字和它们的价值,但老板还知道加人加工资,说明有希望。~~

问问自己,有这个实力吗,确信,扑上去。 这就是所谓的“技术债务”。
就跟公司债务不能全靠会计解决一样,程序员能发挥的作用有限。
当然,作为一个程序员,职业道德里确实应该包含《Clean Code》里说的"童子军规则":以当童子军为荣,以有女朋友为耻!(错了,错了,不是这个,是 当你离开一个地方的时候,要让它比你来的时候更整洁干净。)
不要重构!不要重构!不要重构!(三体人从半人马座发来遥远的问候~~) 题主接触这个项目多久了?是空降进来的还是一直在做的?

如果是空降来的。依个人经验,越是复杂的项目,不同的人对项目的判断就越容易产生偏差。尤其是之前有一些质量相对高些的项目的经验的人,反而可能会先入为主的对旧项目的表面质量产生要求,但实际并不一定能够找到症结所在,找到了也不一定能制定出周全的方案。

如果是一直在做成长到负责人的,项目做砸有你一份:)那么之前的做法肯定有不合理的地方。这时候可能已经知道项目有诸多问题,但受人在此山中思维定势的影响,已经撞到了手段的天花板了。不接受新方法新思路的熏陶,只能一筹莫展。

个人建议是,起两个团队:一批外部调任招聘为主,技术水平要高,主做支持系统;一批项目内抽调为主,业务理解要精深透彻,主做核心业务重构。两个团队要保持高度沟通随时交换经验,同时要顶住压力不被抽掉去攻坚新业务(苦了剩下的人了:P)。节奏上建议选择有代表性的核心模块,一直做到藕合度满意为止。

通常第一步是最难的,第一个业务拆分结束后,成本投入和实施步骤都有谱了,业务架构的方法论也有了,后面第 N 个依法泡制就行了。 与大多数人相反,我认为这反而是大展身手的时候。

首先,难道你们都没发现“项目在赚大钱”这一点吗?面对一座金矿,难道你一定要买来全世界最好的镐头才能开始挖?你就不怕被别人挖光了?

第二,没有多少公司有google那么牛逼可以只招全世界最顶尖的人才。几个牛人带着一堆普通人才是业界常态。这种情况下,代码质量不可避免的会有所降低。讲句不好听的,就算是google,随着时间的推移,也会有一堆不知所云的垃圾代码和冗余架构。各位鼓励跳槽的,难道就不担心下一个公司的代码也是如此烂吗?在国内,就算是bat这个级别的公司,烂代码也是不少见的。到时候难道又跳槽吗?

难道你就这么自信一辈子只写好代码不写烂代码?只与顶尖高手合作不搭理刚毕业的菜鸟?

所以,必须学会在高速行驶的汽车上换车胎(以下只关注技术部分,至于跨部门合作/与产品 扯皮之类经验,美女rd可以靠姿色,土豪rd可以靠请客,屌丝rd可以靠同为屌丝的同情心,总之,各村有各村的高招,只可意会不可言传)。

具体来讲,无非就是几个方面:

1. 深刻理解业务。这是一切的前提,这一点决定了你“能不能成为一个架构师”。在理解业务的基础上,你才能进行架构,才知道哪些模块是可以热替换的。事实上,很多庞大的系统其实真正不可热替换的部分只有那么一小点儿,其他东西都是可以通过热替换逐步改善的。当80%的东西都改善以后,剩下的20%也就不难处理了。

2. 打好技术基础。如果说第一点决定了你“能不能成为一个架构师”,那么这一点就决定了你“能不能成为一个好架构师”。有足够的技术基础,你精心refine的架构才不至于又变成别人口中的垃圾,你的继任和属下才不会发出跟你一样的感叹。

3. 代码很脏很乱这一点,是最不重要的点。在有了良好的架构的情况下,代码不管多脏多乱,其影响范围也只有自己模块那一小部分。如果代码已经烂到会影响整个架构的情况,那有以下几点可供参考:a. 你的架构是否藕合度仍然太高?b. 你是否派不够资深的人承当了非常重要的任务?

事实上我认为真正的架构师是绝不会脱离代码一线的。一个系统中最难最有挑战性的部分,正应当是架构师亲自coding的部分。如果你亲自coding的结果都不够满意,那你应当考虑的是,你所拥有的资源是否足够搞定这个项目?是否应当降低项目追求的目标?

4. 架构是一个trade off的过程,过于追求低冗余度和过于追求性能都会导致很高的实现与维护成本。成本是架构师第一该考虑的东西。

5. 可能你并不是架构师。完全没有关系,人人都应当站在架构师的角度去考虑问题。当你站在架构师的角度考虑问题的时候,“代码脏乱”,“架构冗余”,这些问题看上去又会有更深一个层次的感受。你也就不至于在面对庞大而表面上无序的系统的时候,感觉看不到方向,而无从下手了。

总之,还是那句话,放着金矿不挖天理不容。有金矿的前提下,架构乱你才有机会。这么乱的架构都能挣大钱,你把架构随便改善一些,岂不是更能挣大钱? 像这种系统,我们TFS上面一大堆(十来个吧?!反正绝对超过十个)

大部分都是纯手写的哦(当然不是我写的,我是专门来擦屁股和优化的)。
随随便便开一个aspx都千把行JS,随随便便开个js文件都3K+行JS,随随便便开个.cs文件都几千行,随随便便展开个方法都几百行,你跟我说推了重写~~?!
别想了,就这套破玩意也是百多号人用了几年才写出来的,现在每天还在迁入大量的Code呢。

实在忍不了,大不了直接走人,没什么大不了的事情~~ 少吐槽,多干事。 划分成模块,混成一团就划分一个大模块,只对公共接口写好文档,这样即使里面一坨屎,也没用办法修改,但是还可以继续用,修改就新建一个模块实现新的功能。这样就把那坨屎个从今后的开发中隔离了出去 辞职跑路,祝你早日解脱。 没什么可建议的,你能救的只有自己。

赠几句良言与你:

1. 不在其位不谋其政,钱没给够别瞎找事
2. 没break就别轻易推倒重来
3. 戒掉代码洁癖,dirty fix也是一种方法
4. 再牛逼的架构也不能解决所有问题
5. 做事看人,成事看天
6. 对自己好点,提升自己,爱护自己

我相信你是很有理想的,我也是,但别把一腔热血洒在垃圾堆里,不值得。 跳槽吧

人气教程排行