曾几何时，当领导找你去谈话，让你接手一个同事做过的项目时（当然该同事不在继续做
这个项目的原因有很多，有些你也能猜的出来）。
当你抱着好奇的心情打开该项目时，确发项目中的代码写的好像“潜伏”中余则成的密码。
临时变量到处横行，变量的命名也是拼写，英文和英语缩写齐上阵，好不热闹。当你好不容易
把变量定义声明这块看完之后，当走过函数那一块时才发现，一个大流水的method犹如“流
沙河”一样横在了你的面前，看来上西天拜佛求经还真是件“苦差事”。
其时这里变量的问题还是好说的，必定还有个注释（如前任开发者还有点职业素养的话）。
而对函数方法的阅读就真成了看“佛经”了。如果你不对项目的背影和业务流程一清二楚的话，
那么摆在你面前的就是一堆让你无从下手的“密码”而非代码。
经历这些年的开发洗礼之后，我越来越感觉对业务逻辑的理解才是key，而技术只是在将
这些业务逻辑以程序员能得懂的方式来进行“表达”。我这里决不是在降低技术的主导地位，
因为没有技术将管理者头脑中的概念变成实实在在产品的话，那可能马云现在还只能在大学里
教书呢。我推荐那种用非常质朴明晰的代码来表达“复杂”业务模型及逻辑，用优良的架构来
实现完善扩展已被市场验证可行或值得一试的商业模式，所以我的理解就是：
而对业务的不了解，甚至抱着边开发边学习的方式来上路，只能无形中增加试错成本，让
本该上西天取经的唐僧变成了东渡日本的鉴真。因为在不清楚业务逻辑的前提下，不进行前期
设计，而一上来就去编码，这种情况起步的越早代码“死掉”的就越快。不仅如此，在写这种
业务逻辑混乱的代码时，你正在高速运行着的大脑也会被这种“混乱”所“污染”，如果这时
有人“高调儿”的跳出来说，你的理解有问题时，让你把刚写完或写到一半的程序重新设计，
那种感觉只能用“泻气”来形容了。
我在前些年接手别人的开发代码时就遇到了类似的情况，而当我问及相关人员为什么代码
会是这种“奇怪样子”时，那些制定业务需求的同事要么已离开公司，要么也以“不记得了”
来推托。其实我也知道这是一种不负责任的态度。当然最后看那些代码到了忍无可忍的程度后，
上面领导说这个项目被废了，要推倒重新开发一个新的产品。这里先且不表公司上层那种你争
我斗而导致的项目“夭折”的情况，反正对于深陷“精神崩溃”边缘的我来说是种“超渡”了。
其实我相信园子里有不少人都遇到过类似的情况，我这里不想说如何处理这种情况，因为
在一些文章或书籍中（比如《走出软件作坊》）中已提供了一些可行并且有效的方案。我在这
里想说的是当我们抱怨别人开发的“密码”之后，你是否也在背地里制造着相类似甚至更差劲
的“密码”呢？这种情况不是有没有，可不可以有的问题，而是肯定有(这里没有“小沈阳”)。
所以抱着为自己的职业生涯“积点德”的想法，在这里冒昧说一句，在要离职或转到其它
部门工作的同行们，在您老先生走之前，能不能把屁股擦干净，不要让别人给你“擦屁股”。
我用我的嘴说，你用你的眼睛看，耳朵听。如果你不打算这么做，那就只当我没说。当然一开
始我就没抱什么太大希望，必定每个人的水平不同，经历不同。最终的结果可能还是那样：
“饭照吃，屁股照擦”。
好了，今天的内容就到这里了，有不同意见的朋友，可以在回复中与我交流。
扫一扫
3423
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
