第一:
需要解决比较复杂数学问题的时候,请直接找数学专业人士,而不是自己跳坑。
比如:汽车工业界几十年来都想消除 NURBS 曲面上的曲率突变,结果丘成桐直接从理论上证明他们是痴心妄想,后来业界就关注怎么用里奇流来最优化突变数量了
比如:汽车工业界几十年来都想消除 NURBS 曲面上的曲率突变,结果丘成桐直接从理论上证明他们是痴心妄想,后来业界就关注怎么用里奇流来最优化突变数量了
- 函数不要超过50行。
- 不要一次性写太多来不及测的代码,而是要写一段调试一段。
- UT和编码要同步做。
- 多写注释方便的往往是自己。
- 碰到一堆问题时,一次只尝试解决一个问题。
- 没把握一眼看出问题症结的时候,老老实实单步调试。
- 设计模式是个好东西,但不要强行使用。
- 没造成可观的损失前不要尝试做性能优化。
- 没事别重复造轮子,例如去前端范这类的网站找找经验。
- 大多数情况下Boss不关心技术含量,而且往往简单的解决方案更快更有效果。
- 不要害怕接触新知识,因为害怕也没用,不管你愿意不愿意,你现在会的东西5年后就会过时。
-
第三:
领导问什么时候可以完成的时候,把你心里的完成时间乘以3之后,再告诉领导。
深入理解行业知识很重要,在关注技术的同时,要深入了解行业知识,做到这一点才能脱颖而出。
我赞同的他人回复(不知道把别人的答案放在这里是不是不好,如果不好,大家告知一下,我删掉):
函数行数尽量少
less is more
最不靠谱的需求最后做
IDE比你想象中要更强大,编译器和标准库比你想象中要更聪明
什么达夫设备速度快啊,*dst++=*src++速度更快啊,for里面++i比i++要快啊,!a比a = -a要快啊,a = 0非得写成a = a ^ a啊,:?表达式比if要快啊,都是扯
什么达夫设备速度快啊,*dst++=*src++速度更快啊,for里面++i比i++要快啊,!a比a = -a要快啊,a = 0非得写成a = a ^ a啊,:?表达式比if要快啊,都是扯