胶水工的困惑——读“为什么很多公司都不用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写的
------解决方案--------------------
做管理软件，业务才是关键，技术也重要，但技术是为业务服务的......