胶水工的困惑——读“为什么很多公司都不用linq”有感
本帖最后由 x_wy46 于 2012-03-14 23:23:06 编辑
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写的
------解决方案--------------------做管理软件,业务才是关键,技术也重要,但技术是为业务服务的......