首先你要知道你写code的目的是什么。你要解决的问题是什么。 我个人认为,一个好的coding,根本不需要太多的documentation,应该是旁人(当然是懂行的人)一看就明白在干什么,function是什么,input,output,解决了什么问题,一目了然。我个人是很讨厌,花里胡哨,旁人花力气才能看懂,维护起来也很麻烦的那种code。 我的工作title是software engineer。我对engineer的理解是我是来解决问题的。写code只是解决问题的一个步骤。找出问题的根本,设计解决方案,最后测试自己的方案这个流程才是灵魂。 所以想要让人觉得自己professional,那就得你的思想有engineer的高度。我个人认为,一个好的engineer,一上来先要define,需要解决的问题是什么。搜集资料,做research。然后再设计如何解决这个问题。从不同角度思考。最后定方案的时候,需要知道我为什么选择这个方案。在交流的时候你得言之有物。比如这么做可以延续原有的设计思路,或者这么做节省memory,或者这么做容易maintain。总之一个engineer对于自己采用的方案是有想法的。 等想清楚了以后,那才是coding的部分。其实coding的部分并没那么重要。我工作中用c++,c#。去解决一个问题,可以有不同的方式。就拿loop来说,我可以while,可以for,可以用foreach,等等,方式很多。这个不重要,能实现功能,不要有bug就可以了。但是你写的function,你的设计意图是否清晰,你有没有solve the problem,meet the requriement,你写的东西是否easy to maintain在我看来才是更重要的。
一开始不要野路子乱来,养成了坏习惯不容易改的。
你是认真的吗
2 minutes?
It takes time. 多看别人写的代码。
我个人认为,一个好的coding,根本不需要太多的documentation,应该是旁人(当然是懂行的人)一看就明白在干什么,function是什么,input,output,解决了什么问题,一目了然。我个人是很讨厌,花里胡哨,旁人花力气才能看懂,维护起来也很麻烦的那种code。
我的工作title是software engineer。我对engineer的理解是我是来解决问题的。写code只是解决问题的一个步骤。找出问题的根本,设计解决方案,最后测试自己的方案这个流程才是灵魂。
所以想要让人觉得自己professional,那就得你的思想有engineer的高度。我个人认为,一个好的engineer,一上来先要define,需要解决的问题是什么。搜集资料,做research。然后再设计如何解决这个问题。从不同角度思考。最后定方案的时候,需要知道我为什么选择这个方案。在交流的时候你得言之有物。比如这么做可以延续原有的设计思路,或者这么做节省memory,或者这么做容易maintain。总之一个engineer对于自己采用的方案是有想法的。
等想清楚了以后,那才是coding的部分。其实coding的部分并没那么重要。我工作中用c++,c#。去解决一个问题,可以有不同的方式。就拿loop来说,我可以while,可以for,可以用foreach,等等,方式很多。这个不重要,能实现功能,不要有bug就可以了。但是你写的function,你的设计意图是否清晰,你有没有solve the problem,meet the requriement,你写的东西是否easy to maintain在我看来才是更重要的。
我很菜。打个简单的比方,比如有几million的rows, check 每个row的missing value,然后fill in xx,我写的loop是要run一会。 反正当年人家帮我改完,我的崇敬之情有如滔滔江水。。。
反而是那种fancy的syntax,什么lambda啦,recurrsive的东西啦,tree啦,这种东西并没那么重要。比如我上学学过tree这个结构。但是在实际工作中几乎没用过。因为根本用不到。function,class写的简洁明了才是王道。easy test,easy debug,easy review。好的interface,用起来就跟说话一样,逻辑鲜明,功能简单,不容易让用的人出错。这些才是反应真正水平的东西。
难得看到这种回复
我是真叫别人花里胡哨的function给看恶心了,然后一到presentation就叽叽歪歪啥都说不清楚,也不知道解决了什么问题,就反复唠叨自己的input 和各种乱七八糟function
看别人的code,最主要是structure,github上下人家的solution看对我有帮助,我们是一般的应用层小系统,对速度和资源占用要求都比不了那些分布,及时的大应用。
先好好找工作,去个大厂,进个好组,然后去看组里senior的code。 对于有的对code要求不严的组,看还不如不看
多刷题比什么格式更管用,真的
谢谢mm! 听君一席话,胜读十年书! 你说的很多地方正好是我的问题。特别是在开始coding之前先有详细的规划,确实是我没有做到的
真是直达我这个起名废的痛点
我们是传统公司,不是IT大厂,我们整个组都是从统计转DS的,coding都挺水的。 IT部门的code我们看不到
写好code进大厂好组,和进大厂好组写好code,互为因果
前者不需要你把code写整齐。。
至少看看系统里以前的CR的comments
这个我们内部也讨论过, 为啥ds的python code 写得那么烂? 原因有几个吧:
大多数code 都是用完就扔的, 写完了弄出数据就好。 code review 都是pair program, 所以code里不需要太多的上下文。
要想提高,还是要多些production 的code, 需要维护的code 肯定要写的好一些。
Exactly!我们就是做完就扔, 而且基本是自己写自己用,不需要太多的合作,所以写得烂也能混。。。但也是限制自己发展的一个瓶颈,所以还是想突破一下
做完就扔也是有改进空间的,比如,这次做的和下次做的有没有相似的,可以抽象一下reuse的
是的,这些都是在改进的地方,所以需要学习
等想清楚了以后,那才是coding的部分。
-- 赞。
“现在公司” 里的要求是一天一变。。。写的model 出来还有去改,或者重新写。
所以很多coding 问题不是没有写好,而是没有时间去想, 然后写。 因为问题一直在变, 要求也在变。。