20170710-几维晨规

==写代码

1.判断,嵌套是否可逆;流程是否可逆;代码上下文是否可调;判断条件是否可位运算

2.JSON拼接工具化

3.动态类型:null值判断

4.提交代码:冥想SourceTree自审提交

5.大if小else是可以调整的,转换条件,小if大else

6.逻辑优于补丁

7.一次actor方法调用是一次网络请求,一个方法里,一个actor最多承受两次方法调用获取值。

8.事件传值时,一个具体的事件,这次传值只是针对一个具体的使用时,是部分需要,不要传递大量的参数,或者说Event参数不要太多。

9.局部Demo验证

10、dynamic类型不可信

11、代码即客观

12、代码声明:

1)声明了立即用。或者说用时声明,声明即用。

2)不能立即用->延迟初始化:值类型只声明;引用类型(String除外)赋null;String用String.Empty

3)var变量;val变量;lazy变量

4)反向初始化

13、判断-分支

 

//return写的不好

 

 

 14、

1)工具类代码,注意异常信息的反馈。

15、优雅代码

1)AOP处理异常。

2)面向过程-方法:强命名重载方法

3)面向过程-方法:深化学习泛型与委托重构代码

4)面向过程-方法:异常也是方法的一种返回值

5)面向对象:设计模式;抽象类、接口的继承

16、规范Demo

17、面向接口编程是一种风格(1、习惯;2、功能目录);是一种约束性保障;解耦

18、改动了一行代码,就要对代码所在的方法,方法调用的上下文负责。

19、对整体代码有认识了,但还不细致,不够敏感。这些不细致、不敏感是效率、bug、束缚性思维存在的地方。

20、Best or better better。

21、能用一行代码解决的不写第二行。

22、数据库数据量很小的情况,可以一次全部读出,再在代码用linq查询。

23、完成一个Web接口:①发布;②提交;③写Tower;④通知前端

24、代码封装,框架评价的原则:封装之后留下的使用要点,便是语法-框架(工程实现)、原理(理论阐述)的核心要点;靠近原理(理解),方便记忆(记忆),方便使用(应用)。

补充:精要代码=专注+精简,用精要的代码,努力写精要的代码。

25、第三方消费性接口,做本地缓存。

26、try-catch

不要多个方法的异常交织处理

①当前方法异常,当前方法处理。

②异常统一处理。

27、接口:

①接口要归类,单一职责,要专一干净

②接口注意调用频率

③接口返回值格式要一致

28、代码原则:

①单一、干净(字段、方法、属性、返回值,用不到的就删掉,时刻保持单一干净原则)

②不重复自己

③代码原则:有原则,不妥协

29、方法:

①能在I/O控制的,不要在过程中控制;IO时考虑是否需要过滤-清洗;数据持久化是一种IO

②不按照约定使用,异常是应该的

③异常也是一种返回值

④代码逻辑重要的是注意脏数据

30、修改代码:

①什么条件下修改

②修改后会引发什么连锁反应

③逻辑优于补丁

[助记:if……then……or-better]

31、垃圾代码往外层移,越靠近内部越精密简短(这样才越清晰)

32、controller的action与actor里:修改(DAU)操作的事件(actor方法里产生的事件)只能产生一个,最终一致性,读取、计算可以多次;Handler里可以多次,失败了会重试,但要幂等性(ESGrain里面:protected async Task<bool> RaiseEvent(IEventBase<K> @event, string msgId = null, string mqId = null),msgId 记录了事件id,一系列事件里有一个出错,重新执行所有的)

例:Controller的action里产生了两个事件,如果一个成功了,一个失败了,那怎么算这个action是否成功?如果一个action里产生一个事件,就算这个操作成功(使用的最终一致性)。

33、actor里面禁止使用task.run,与actor里的线程调用冲突了,Orleans里有说明哪些可用,哪些不可用。

34、

公司框架内的代码:

 

①actor里面允许调用其他actor的方法

②actor里的代码,加上调用的其他actor的代码,最多只允许产生一个事件(最终一致性的原因)

③调用的actor是只读的方法的话,只要注意回流就好(只读方法不会产生事件,不会影响最终一致性)

④Handler里面可以产生多个事件

Orleans里的约定:

①actor里面允许调用其他actor的方法

②注意彼此互掉产生回流

35、SQL语句重命名,要用as

36、写DAL:

①核实Model属性

②核实SQL语句

③核实数据库连接

37、保证业务链路代码测试完整性。

38、搭建测试环境,No test no commit。

39、业务代码要在业务上下文中保证正确;通用代码要考虑各种情况。

40、高内聚、低耦合。

41、反思代码有何漏洞,举手之劳能防范,不要依赖约定。

42、做聚合,先match(where)。

43、格物逢学(平时学习),刈旗迭优(日常工作),知道-格物-致觉(职场学习方法)。

44、Region后面要写备注,不然折叠之后谁也不知道是干嘛的。

45、测试

 

46、只有修改state时才走Event=>使用actor内存计算的场景走event=>什么场景下用actor?

47、集合过滤:①从中选择目标项;②从中移除非目标项

示例:集合过滤相同项、null、empty。

 

48、知异同:异-->能抽象为一致?添加区分量:分类处理

49、设计付费的第三方接口,要有图片验证码,防止恶意攻击

==提交代码

1.去除调试痕迹

2.编译;查看resharp,辅助查看bug

3.拆掉思维的墙,会看到什么。

==工具

TOOL.LU

==生活

1.若有所得的出门。

2.拥有自己的身体节律和生活节律(为自己的生活建模)。

3.按照自己的频率生活。

4.作为一个独立的人生活。

5.工具化,机制化,局部Demo验证。

6.问的多说明想的少。

7.接收到一个信息后,努力尝试跟旧的信息建立联系。

8.拆掉思维的墙,不要束缚性思考。

9.我习惯于把问题推三层,找到一个疑问节点去询问,疑问节点被浅化三层后通常是个很简单的问题,问出这个问题后反推三层能解决自己的疑问,但问出的问题太浅会让人觉的水平太低,反思问问题的方式。

10.只谈客观只谈事,不带感情不论人。

11、与人交往,聊聊天,礼尚往来即朋友。

12、你并不需要掌握全部之后才能行动。

13、决定一个价值的不是老板,是市场。

14、交流(看书、看博客、询问、阅读源码)+格物(针对官方文档领悟)+自悟(以自己为原材料获得新知)

15、学习、选择、使用技术,是为了舒服的解决问题。

16、对文档负责

17、核心技术做到精要,其他的边边角角,适可而止,不要贪大求全,埋没了享受生活的时间;有识别核心内容的视野。

18、工程型学习模型-适可而止,格物逢学,学之以术,精要致觉。[上学时那个学习思路:理解-记忆-应用-致觉,有一个潜在假设场景,应对考试,百分百掌握,适合打基础,专家型学习模式,但贪大求全,难以精要]

19、活在当下,站在当下预测,塑造,引至未来。不是为了防范未来某一情景,不断地在今天忙碌,未来总不会在今天到来,那今天永远忙碌。

20、看到边界,看到轻重之后再学习。

==工作

1、工作主要是写接口:

读写接口:

①操作对象(表:哪张表,哪些字段;actor:哪个actor,哪些字段)

②输入参数;输出参数

③添加位置(前台还是后台;哪个Controller;哪个Actor;哪张表)

④附件说明(权限说明;注意事项)

业务接口:

①复杂的功能,了解应用场景

原文地址:https://www.cnblogs.com/CharlesZHENG/p/7696378.html