#从工程上理解coding---我对软件工程的理解
##语言只是工具
对于刚刚开始学习计算机程序的我。多少还是有些迷茫。曾经一度认为代码是神圣的不可侵犯的，或者说，是一个我所不能够理解的范畴，是那些大牛们才能够理解的才能
够明白的，初入大一，我学习了c和c++，虽然没有挂科，但对于到底什么是程序仍然是一头雾水，我似乎只会在那个黑框框里做一些简单的加减乘除的预算，除此之外，别无
他技。但如果从工程的角度来看，我所学到的却是神奇的与计算机交流的方式，途径。有了这些我就能够给计算机表达我想让他做的事情，那这么多的编程语言到底是
做什么的呢？-----语言只是工具，语言没有好或者坏：成天讨论这门语言好那门语言坏的人，甚至是可悲的。
##团队缺乏的不只是管理
同样的，在之前我认为一个team和个人之间的区别不就是有没有一个领导。
以及。
领导的才能一定是比下边的技术职员要高，领导的工资一定是比下边的职员工资要高。
看来，这种想法是错误的。
做管理起码得能够承担责任，这才是最基本的素质。
引用书中的一个例子：你的项目经理职位又没有让给别人做，你拿的经理级工资又没有分给别人，那项目失败了，你为什么要把责任推到别人头上呢？
三人团队中的那个领导，不是要像程咬金一样的牛人，而是要像李离一样的死士。项目完成不了，切脑袋的事儿倒不必做，递交辞呈的那点勇气还是要有的。
“简单来说就是要勇于承担你应有的责任。“
##第一次真正的思考
程序=算法+加数据结构。
得出来的重要的结论：积极工作和勤于思考都要占时间。
这个公式的精妙之处，在于他没有提到丝毫的code。甚至。代码是不存在的。
>>>>>存在的只是思想<<<<<<
对啊，code的过程不过是一个体力活。只要思考到位了，剩下的就只是简单的体力活了。
##老板不懂技术
正如上边所说，经理的coding能力或许还不及职员。
在EHM模型中，老板处于最右端，而开发者处于最左端，在两者之间没有相同的关注点。
而项目经理要做的，就是架起这座沟通的桥梁。
##知律而变
“道”是规律，如果“道”可以变化无穷，那么这样状态下的软件工程才是活的。
自勉，DON`T BE A COPY&PASTER !
知律是在于知道原理，明白为什么是这样，为什么不是那样。不要像一部分人一样，用着不知道所以然的方法和技巧，一旦出了问题，就责怪方法不好技巧不对。不要因为
不明白方法规律的原理而不能变通，不知道回避错误。
所以我写下了这一篇随笔。