日期:2014-05-20  浏览次数:20897 次

胶水工的困惑——读“为什么很多公司都不用linq”有感
2010年毕业,从业将近两年,说实话我一直认为自己是工人而已,什么“三角猫的程序员”,“伪程序员”都不敢称

曾经以为写程序是一件非常美妙和圣神的事,自己可以去实现各种各样的功能,死活也不愿意做维护类的工作

后来发现不是这样的

web和winform都做过一点,用的最多的就是网格控件之类的,把数据塞进数据库中,读出来,改一下,再塞进去之类的

代码的概念似乎只是if和else

工作中我发现一个问题,就是似乎大家伙都永远纠缠在业务中,

需求说实现A功能,噼里啪啦写出来A功能,客户说这样不对,立马改成B功能,通常就是任务多、时间紧、变更大

工作的中心似乎永远就是业务,遇到问题的时候不是想用什么优雅的代码来完成,而是用什么最快的办法实现

后来我开始慢慢反思,自己到底适不适合在这个行业发展,因为时间也不短了,快两年了,对程序的认识仅限于控件和if else

有时候自己也会静下心来研究研究一些理论上的东西,什么委托了,匿名函数了,异步了,多线程了

可是工作中完全不是这样,没人管理代码写的多有效率,多漂亮(现在用vs05)

人家对你的评价似乎就是实现了多少功能,写了多少行代码,改了多少BUG,完成了多少个变更。

累也就累了,更可恶的是你时时刻刻要提防着周围的人,问题的责任归属是一个非常严重的问题

这样的工作实在提不起兴趣,自己也没多少提高,身心俱惫

后来想往数据库方面发展,就拼命低学习数据库方面的东西,c#基本上就放着在那了,遇到不会的问题就狗哥

心想做数据库的话应该跟业务的耦合度会低一点,

因为我管尼玛什么业务,管尼玛什么循环,管尼玛什么校验,

你数据进来了才是我的事,数据库性能,安全,稳定性才是我关注和感兴趣的

不知道这样的想法是否可行?还是在逃避现在?

还有一个问题就是HR们一直认为跳槽频繁要命就是能力低下,要么就是不会处事

想想自己其实这两方面都有,两年两公司,但是你们HR又没有想过客观上的原因?难道完全是求职者的问题吗?

------解决方案--------------------
慢慢领悟,多学习优秀的代码。就会跳出工人的圈子。
------解决方案--------------------
曾经以为写程序是一件非常美妙和圣神的事,自己可以去实现各种各样的功能,死活也不愿意做维护类的工作
=============
做维护类的工作很有好处,让你看到设计不合理之处,容易出bug之处,注释的重要性。。。我做了一年维护,受益匪浅,总结了几十条避免bug的技巧,一个异常处理的大致框架,对于kiss(Keep It Simple and Stupid)等设计原则也有了些感性认识。


工作的中心似乎永远就是业务,遇到问题的时候不是想用什么优雅的代码来完成,而是用什么最快的办法实现
=============
业务整明白就很不错了。而且长远来说,其实迅速,合理的系统建模,开发出的东西最大程度上符合需求,比优雅的代码重要得多。

有时候自己也会静下心来研究研究一些理论上的东西,什么委托了,匿名函数了,异步了,多线程了
=============
这些严格来说还算不上理论。而且注意kiss原则(上面说了),复杂性的增加往往也增加调试的困难和出错可能性的增加!
要研究理论,搞些算法,学点编译

------解决方案--------------------
惧怕客户需求变化,是软件生产手段落后的表现

代码写的"好不好看"不是为了方便以后修改的,而是为了自己能够更快的通过测试,
如果复制粘贴手段在一个团队中居然是最高效的开发手段,那尽情的粘贴就是了,
不要让程序员去承担抽象啊,重构啊,这些不相干的职责,他们少得可怜的工资不包含这些
------解决方案--------------------

如果在其他领域遇到困难,广大的胶水工是你的后盾
------解决方案--------------------
探讨
惧怕客户需求变化,是软件生产手段落后的表现

代码写的"好不好看"不是为了方便以后修改的,而是为了自己能够更快的通过测试,
如果复制粘贴手段在一个团队中居然是最高效的开发手段,那尽情的粘贴就是了,
不要让程序员去承担抽象啊,重构啊,这些不相干的职责,他们少得可怜的工资不包含这些

------解决方案--------------------
数据库怎么会跟业务没关系呢?我们的业务处理都是stored precedure写的
------解决方案--------------------
做管理软件,业务才是关键,技术也重要,但技术是为业务服务的......