![](https://img-blog.csdnimg.cn/202009221648353.jpg?x-oss-process=image/resize,m_fixed,h_224,w_224)
br那点事
总结点br实践
小雷FansUnion
懂商业的技术合伙人。个人微信:FansUnion
微信订阅号:XiaoLeiFansUnion。
展开
-
94,96、先写则少错,少写则多错;多思则少算,少思则多算
xx时期,xx老师经常说一句话:做数学题,多思少算。少思,那就多算。对于dts这种技术密集型的项目,那些业务逻辑复杂的项目,在写代码之前,先写文档,写思路,非常有必要。为什么呢?对于复杂的事情,大部分人,大概率会遇到问题。解决问题,排查问题,会花很多时间。而如果提前去思考,写下自己的思路,设计,文档,然后再写代码,有很大概率,一次性就搞定了问题。94、定时任务,延时启动,减少项目的启动时间...原创 2021-12-31 10:35:55 · 247 阅读 · 2 评论 -
100、独立分析问题,解决问题,能力自然就提升了
个人成长之路:从我大学开始写代码以来,大多数情况,都是通过书本、网络资料、自己写代码、各种分析实践,把95%以上的问题,全都自己解决了。一般情况,也没遇到几个高精尖的技术问题,算法问题。自己动手,不指望依赖他人,解决的问题多了,能力就提升了。排查问题的速度也越来越快了。加上,不断的总结写作,基本的问题,很快就知道问题可能的原因了。关键点:降低对他人的依赖,自己独自解决。什么时候,可以指望他人:时间紧,任务重;问题情况比较复杂;自己排查很久,还没方向,陷进去了;...原创 2021-12-31 10:34:00 · 258 阅读 · 0 评论 -
99、怎样理解:程序员需要严谨
对于那些不懂技术,不需要关注实现的人来讲,只用从自己的角度,用着舒服,感觉正常即可。而对于程序员,尤其是后端程序员来说,必须努力、主动、有意识的,去考虑所有的场景、所有的情况,发生的、将要发生的、可能发生的。哎,有点累。只有尽可能考虑到所有的情况,才能去分析事情背后的运作逻辑。知道逻辑,才能去组织 自然语言,让小白理解。组织技术语言,去写代码实现,让机器执行。还有一个难题:表达问题,需要抓住问题的根本,三言两语说清楚问题的关键点。各种人士,比如:上下游相关人士,很多情况,原创 2021-12-31 10:33:24 · 435 阅读 · 0 评论 -
98、多人开会,是为了达成共识,不是为了讨论问题
一、多人开会,是为了达成共识,不是为了讨论问题开会,是为了工作;工作,不是为了开会。除了开会,代码功能 才是主要职责和劳动成功。多人开会,是为了达成共识,不是为了讨论问题。二、应该避免的开会1到2小时,了解彼此的想法,一边讨论,一边达成结论;甚至,无法达成结论,下次接着聊。三、高效率的1、如果需要讨论,可以私下少数2到3个人,交换意见即可。2、正式会议之前,有自己的思考、办法、建议、讨论素材3、讨论事项,矛盾点、争议点、冲突点,列1、2、3点。原创 2021-12-31 10:32:44 · 272 阅读 · 0 评论 -
97、技术人员在日常沟通表达中的挑战
一、基本背景技术人员,尤其是后端人员,更加侧重一个问题的具体技术实现。日常工作中,又需要同 后端技术人员、前端人员、测试、产品经理、运维等沟通交流。实际情况需要,技术人员,挑战1:在同对方交流的时候,需要考虑到对方的技术背景,选择合适的语言,让对方听明白:现在的问题是啥、性质、运作逻辑、问题的原因等。挑战2:面向不同背景的人,不断的切换表达方式。日常1:因为工作中,技术人员交流,用技术语言表达更有效率,习惯性用技术语言。日常2:和测试、产品等沟通,需要用更多的自然语言,会比较原创 2021-12-31 10:32:07 · 487 阅读 · 0 评论 -
95、越权查看数据,有风险
不要试图查看自己不应该看到的数据。如果需要看,走正当途径,走正门,莫走后门。1、有感而发:越权行为负责的xx系统xx模块,程序记录到了某人1年,手动构造了2个路径,一共3个请求,试图查看“没有权限”或“不应该查看”的数据。2、好奇心害死人:黑客行为技术人员,懂点技术的人员,总有种“黑客”的冲动行为。改改url,修改参数,试图查看更多的数据。一不小心,被系统记录了,可能给自己带来不好的影响。3、友情提示:老实本分低调、老实、本分、知道自己该知道的。4、我的“原创 2021-12-31 10:31:06 · 247 阅读 · 0 评论 -
93、如果一个业务需求,技术上很难实现,得首先怀疑下需求的合理性
1、如果一个业务需求,技术上很难实现的得首先怀疑下需求的合理性2、一点经验:技术设计是清晰的前提下,只要需求是合理的,大多数情况 都比较好搞定;如果技术上特别难实现,得首先怀疑下 需求的合理性了。3、大道至简现实世界的万事万物已经“良好”运作了,互相适应了,保持了当前的稳定关系。业务类的系统,也遵循着潜在的事物规律。技术设计上,简单的、简洁的、清晰的,则通常是 信息完整的、可扩展的、灵活的、具备发展基础的。此时,如果业务很难实现,那么很有可能是“需求不常见”、“需求不合原创 2021-12-31 10:29:48 · 271 阅读 · 0 评论 -
92、先比较,再更新,速度极快
一、问题一个系统,经常需要和上下游同步数据,比如账务dts从crm同步客户数据,新dts从老dts同步用户数据,ehr需要把xx数据写进redis。二、常见的办法1、数据库之间的同步先删除所有数据,再保存所有数据;整体作为一个事务。问题:速度很慢。如果表的id被其它业务关联了,也不方便。更好的办法:先从系统的数据库表,查询存在的数据;和需要同步查询的数据作比较, 判断哪些是新增的、哪些是删除的、哪些是修改的。即:先比较再更新。2、向es写数据最差的办法:删除所有数原创 2021-12-31 10:28:38 · 833 阅读 · 0 评论 -
91、信息量太大,怎么降低大脑压力
活得越久,信息量越大;死记硬背,不靠谱哎。解决办法:对信息进行维护,符合人的大脑存储方式。1、时间日记、编年体、流水账、新闻。人物、时间、地点、事情的起因、过程和结果2、主题新闻报道专题、数据挖掘的专题(人物客户)、纪传体史书(以人物为中心)3、分类电脑的文件夹、浏览器的书签,分类再分类,树状结构;图书馆的图书分类,方便查找4、逻辑和推理数学公式定理、警察破案、程序员排查bug、怎么解决一个问题、怎么写PPT5、艺术PPT汇报的艺术、诗词韵律...原创 2021-12-31 10:27:26 · 130 阅读 · 0 评论 -
90、不同系统,同一个事物的名称,最好保持一致
启发,经验:1、不同系统,同一个事物的名称,最好保持一致;2、代码中多用枚举,不写死汉字,英文字母3、上下游传输,多用数字枚举4、 界面展示的文案,可以做成可配置的。内部代码叫a,用户可能需要看到A相关例子:MD5,md5,Md5....原创 2021-12-22 16:34:15 · 209 阅读 · 0 评论 -
89、无数次的事实证明,单一职责,结构清楚,bug最少
无数次一次又一次的事实证明,只要不把代码写清楚,就容易出现各种问题。今天是复制粘贴,漏了一处改名的。 // 可能1个拆成2个 privateList<ResultRequest> resultRequest(ResultVo resultVo, Map<Integer, ProductVo> productMap, Map<Integer, CrmCustomerVo> customerMap) { ...原创 2021-12-22 16:33:15 · 100 阅读 · 0 评论 -
87-88,同一个项目的交互配置,维护成一个json和config对象,极简中的极简
87、同一个项目的交互配置,维护成一个json和config对象importlombok.Data;@DatapublicclassCsTokenConfig {privateString projectCode;privateString token;privateString fileUploadUrl;privateString fileDomain;}88、极简中的极简构造一个对象,构造集合,对象转换,...原创 2021-12-22 16:31:47 · 87 阅读 · 0 评论 -
86、提供辅助参数,方便排查确认问题
一、现象后端,经常给前端提供各种各样的业务数据查询接口。对于逻辑类的、规则类的,尤其是关键业务、特定业务,理解起来比较费劲。前端,可能只需要一个参数:是否,或者 一个url。但,这个值怎么来的,前端并不需要。所以,后端通常不给前端返回这个参数。二、问题接口开发完成了,怎么自测了,怎么知道对不对呢?没有过程信息、没有逻辑推理的参数,怎么确认结果一定正确呢?如果测试或产品或前端,提出一个疑问bug,怎么解释呢?是有bug,还是他们理解不对,还是存在歧义呢?如果是线原创 2021-12-22 16:29:03 · 504 阅读 · 0 评论 -
85、face to face,效率高。当面说,岂不美哉
我感觉web er稍微懒一些,都挂2个耳朵;有问题,都得上门服务。pm er,积极些,经常上门沟通。当面沟通,说的清楚一些,企业微信上,你滴 我嗒,经常扯不清。微信,适合 1,0,简单的通知。今天沟通人员:xxxxx...原创 2021-12-21 20:23:01 · 300 阅读 · 0 评论 -
84、一个表的更新,最好是 先比较,判断是否发生了变化。有变化 再更新,比较好
1、观点:一个表的更新,最好是先比较,判断是否发生了变化。有变化再更新,比较好。2、现象:项目刚刚启动,就大量的update语句。本来想调试看看某个地方的sql语句。3、场景很多数据库表,有定时更新的需求。比如,A系统维护客户,为了解耦或效率,同步到了B系统。但是,偶尔会变化,因此会定期更新,但更新并不是频繁。更新方法1:全量更新+mq更新更新方法2:定时全量更新。但,update语句太多,很容易导致数据库慢,系统慢。如果数据有几百万条,咋整?解决办法:先..原创 2021-12-21 20:17:05 · 696 阅读 · 0 评论 -
83、我为啥不喜欢在jira上维护任务的信息呢
我为啥不喜欢在jira上维护任务的信息呢?1、jira任务,现状,对开发人员来说,只是个记录。2、jira任务,基本是临时性的,项目上线后,回头看很少见。3、需求、业务、逻辑、设计,bug反思,都算是文档类的,习惯在wiki上维护。根本原因:时间有限or态度不佳or就是比较懒。办公和开发辅助的软件,比较多了。wiki、jira、人效、周报等,越来越多。工作类的信息,很多场景都需要,但没有很方便地打通。...原创 2021-12-21 20:15:21 · 118 阅读 · 0 评论 -
82、保持好奇心,多思考,知识和智慧总有派上用场的时候
一、强力的2点心得1、总结使人进步。每天日拱一卒,记录每天解决的问题,典型场景:bug、技术难题、推理过程。2、保持好奇心,多思考需求是否合理、公司业务、项目的发展。二、保持好奇心,多思考,最近1个例子:群组企业微信等社交软件,涉及到群、组等概念的时候,有“退群”等常见的功能。平时,除了作为普通用户使用它,还会从学习者的角度,看看他完成了哪些功能点。创新者、创业者、产品经理、研究人员等岗位,需要对日常事物,保持好奇心,发现闪光点。类比,技术人员,使用技术,学习框架原创 2021-12-21 20:14:32 · 144 阅读 · 0 评论 -
81、前后端等上下游岗位配合的思考和参考工作方法,望文知意,约定优于沟通
友情提示1、本文主要以 后端研发视角写的2、本文纯属一家之言,仅供参考、慎重参考3、本文主要探讨项目开发和配合。一、岗位链条,上下游需求-pm-前端-后端-测试-运维+boss。一荣俱荣,一损俱损。除非遇到相关人士,不配合、持续不配合、强烈不配合,还是多出点力,先搞定问题比较稳妥。二、前后端配合,合作典范目前,和前端的配合非常顺畅了,合作过的且在职的,大概5人。德坤徐娜春雨,基本都能秒懂。蒙蒙、明佳沟通交流较少,基本也没问题。合作方...原创 2021-12-21 20:13:07 · 1450 阅读 · 0 评论 -
80、20%时间写代码,80%阅读代码。代码写得一坨屎,后患无穷
权限控制,能单独维护就单独维护。权限逻辑分3部分,各自维护。哪里变化了,就只改某个子方法。20%时间写代码,80%阅读代码。代码写得一坨屎,后患无穷。每天瞎忙,没干几件事,更别提成长了。也没时间research&study。...原创 2021-12-16 17:08:35 · 203 阅读 · 0 评论 -
79、业务代码的结构、分类、分工
1、crud(开发人员的基本功) 2、高频查询(更清晰) 3、核心save方法(技术和业务能力的体现) 4、核心业务操作(技术和业务能力的体现) 5、纯工具方法(一辈子,可以只写一次) 6、业务工具kit方法(单个项目,公司相关的) 7、业务工具kit服务(单个项目,核心业务的辅助,周边业务) 8、辅助代码(所有项目通用,由于没RPC封装,暂时如此)1、crud(开发人员的基本功)基本的各种增删改查,没有业务逻辑,或逻辑比较少。Controller、Service、Mapper等..原创 2021-12-16 17:07:33 · 714 阅读 · 0 评论 -
78、读写分离,精心维护核心方法
1、百小融FAQ和运营助手FAQ,总体功能非常类似。70%是一样的,30%各自有定制化的代码。2、先直接复制粘贴,再修改,发现重复代码太多,不方便以后维护。把完全一样的代码,通常是那些业务逻辑无关的,比如 纯粹的crud、数据转换、格式化等,放到XxKit,XxKitService、XxEnum。3、还剩下261行代码,主要分为查询Query和修改Save 2大类代码。查询的,数据库表共用,但 业务类型bizType有区分、2个业务的字段有很多不同的,因此各自维护。修改类的,核心的是原创 2021-12-16 17:06:23 · 200 阅读 · 0 评论 -
77、实事求是,解决现实问题的一种简单可行的办法
日常生活中,学习中,工作中,经常有一些复杂的问题,需要处理。这样做,觉得不妥;那样做,也感觉不妥。比如,x,xx,xxx。显得非常纠结。为什么会纠结?因为,问题复杂了,参与的人多了,考虑问题的角度立场不同,主观思维就会越来越多。俗话说:众口难调。至少存在若干事情,不可能让所有人都满意,同等满意。针对以上这种情况,其它情况,至少有种比较简单可行的办法:实事求是。事情、事物、真相,是怎样的,就是怎样的。按照逻辑来处理,主次之分,因果关系,重要程度,时间顺序等考虑。原创 2021-12-16 17:05:02 · 294 阅读 · 0 评论 -
76、技术分享,积善积德。帮助他人,成就自己
技术分享,积善积德。帮助他人,成就自己。工作中遇到的问题,及时整理总结下,好处多多:1、加深印象,从根本上理解了问题2、日拱一卒,不断进步。普通人居多,成长是一天天积累的。3、纯技术问题,非公司特定业务问题,分享出来,既帮助了他人,也成就了自己。4、2016年,跳槽时,想去大厂深造下。正好有个网友,即将从jd离职,就顺手把我推荐给了boss,然后我就到了jd xx部门xx岗位。这个网友看过我的文章,也在xx社区和xx社区一起奋斗过。2021年9月26日,又一个网友反馈原创 2021-12-16 17:03:01 · 303 阅读 · 0 评论 -
72、价值和定位:百小融和运营助手,一点思考
本文纯属个人思考,仅供参考,轻喷。一、核心问题价值和定位百小融:解放职能岗位,引导用户向“智能机器人”提问,但实际上,只有少量用户,偶尔会问。二、为什么用的少1、公司人数不够多2、新员工入职初期,老员工偶尔遇到问题,才会问一下;老员工,大多数问题都已经知道了,或者内部问下身边同学和大哥。3、只会问标准问题,敏感问题,可能不会在这里,会有担心风险的情况吗4、百小融自身是否足够强大,覆盖了用户想要的问题;如果第一次没有,或者回答的问题有限,很快就不想用了5、问原创 2021-12-15 15:50:49 · 98 阅读 · 0 评论 -
70-75、推理永远都是万能大法
70、技术人员排查问题和警察破案非常像。推理永远都是万能大法技术人员排查问题和警察破案,非常像。根据反馈的现象问题,利用逻辑推理,结合现场调查,监控,得出事情的真相。71、岗位不同,工作事情相同我的经验:每个岗位做自己的本职的工作,一般压力不大。对共同的事情业务问题理解清楚一致,是比较困难的点。4种关键研发岗位:前端、后端、产品、测试。UI设计和运维,开发流程中的边缘角色。73、dev负责写功能,pm或运营负责线上数据维护,避免sql一点疑惑...原创 2021-12-15 15:48:29 · 648 阅读 · 0 评论 -
69、慢sql报警,每年“花”273.75元到2737.5元(应该算多了)
每天收到很多慢sql报警,但是这些慢sql,既不是我关心的,也不是我负责的,也不是我能推动解决的。真是头大。所以是“收了也是白收”,“花了也是白花”。这是个小事,但也是个大事。用事实说话,推理如下:今天收到慢sql报警6条+了。市场价格:一条报警短信大概3到6分钱次数:平均1天5次差不多假设1:1人1天就是1.5毛,保守5个人收到,价格是0.75元。假设2:公司这么多系统,平均每天有10到100个类似的慢sql,成本7.5元到75元。大概:1年365天,..原创 2021-12-15 15:42:22 · 862 阅读 · 0 评论 -
68、开发er每天工作的重点是:思考、规划、设计、验收,具体执行写代码反而相对轻松
一、用户绩效,当前处理人的逻辑调整二、绩效需求3阶段三、DMS提醒某人功能调研四、common-service,写文档五、上线TODO原创 2021-12-15 15:40:17 · 220 阅读 · 0 评论 -
67、后端开发er,不能想当然
xx同学说:Confluence空间里,每次输入@ 时,“wen.lei”, 大概意思:“总是在前面,自动出现”。有个结论:因为wen.lei比较活跃,导致 自己输入@时,出现上面说的情况。 当时,还找 wi.yn至少1个人确认过,或者 观察过。我半信半疑,有合理的地方“比如比较活跃”,但感觉逻辑有点不对劲。今天,研究“@”提醒某人的技术实现时,又想到这个问题,解决了这个疑惑。(不解决,总感觉大脑里,多了个包包)之前说过了:推理是万能大法。1、个人wen.lei用的时候,第.原创 2021-12-14 20:13:54 · 207 阅读 · 0 评论 -
66、相同的问题,真的真的,要避免2次入坑
同样的xx系统的账号和密码,不要向yy要2次;同样的逻辑,不要出现2次;同样的bug,不要重复推理2次;同样的代码,不要写2次;同样的算法,不要写2次。排序、比较、tree、hash等等等。.kit.treeKit.TreeKit...原创 2021-12-14 20:11:23 · 84 阅读 · 0 评论 -
65、开发er,需求-逻辑-实现-验证,4个环节都需要关注
PM:重点关注需求是怎样的,验收逻辑测试:需求,验收逻辑开发:1、需求是怎样的,需求会变化吗2、逻辑,规则是啥,流程3、自然语言上的实现过程,技术实现,怎么复用代码,需求变化了怎么办4、验证,做完怎么测试,怎么排查bug5、沟通,怎么和不懂技术的人,用自然语言把完成的业务说清楚,怎么让他们大概清楚技术实现的难度和技术实现的大概过程PM可以不懂需求,不知道所有的逻辑,但开发必须,不然需求错了,PM等人一句话,开发就得重来;PM可以不懂逻辑细节,知道大概就行了,但开发原创 2021-12-14 19:38:44 · 216 阅读 · 0 评论 -
63、推理 是万能大法,ywz网络无法上外网
现象:ywz网络无法上外网。观点:遇到问题,推理是万能大法。像警察破案一样,像程序员寻找bug一样,逐步定位到问题的根本原因。不断推理,排除不可能的情况,不断分析出可能的原因。推理:1、cz之前用的有线是好好的,这么两天,网线突然就坏了?网线的质量这么差么,为啥就熬不过这两天?显然,大概率不是 网络问题。2、运维没事干了,禁止网络,不可能的。网线有权限,没听说。3、wifi能上网,隔壁有线是好的,公司有线和无线的网络没问题。4、插上网线,能访问cas,不能访问百度。.原创 2021-10-14 10:05:09 · 365 阅读 · 0 评论 -
57,60,62,64:工作难、太复杂的需求、决不妥协、单一职责
57、工作难工作难呀。很多问题 一眼就看出来了,但是说了没用,只能由其他人吐槽才会改变。 批量提交不合适,之类的,很有预见性的,也是没用。 尽力而为。例子:上面没选中的色彩太亮了,没感觉吗?@xx刷新页面,有选中的,没有高亮。xx:昨天开其它系统的评审,有人说这个太刺眼了。一条蓝色的杠。60、太复杂的需求,往往都是有问题的关键经验教训:yy提了xx需求若干次x1、x2、x3,很复杂;做了N次,还在改动。yy却还反问,你们为啥不1次性做完,为啥通知这么多次。初步分析:太...原创 2021-10-14 10:03:58 · 263 阅读 · 0 评论 -
61、业务是第一位的,是创造价值的点,是萝卜坑的基础
分享点个人思考:普通的业务系统,技术含量不高,对追求技术的开发者,长期不利。但,短期,从各方角度来看,业务是第一位的,是创造价值的点,是萝卜坑的基础。如果对待业务,没有深入思考,bug多,效率低,公司层面会很不满意的。从高水平要求目标出发,积极思考业务,高效率完成,尝试不同的方法论,提升效率。然后必须抽空,提升技术,进入强者恒强,快者恒快的轨道,是正道。在我司的2年多,发现的1点现象是,咱们这个业务系统,看起来门槛很低。pm coder tester等,谁都能干。 但是,真...原创 2021-10-14 09:57:40 · 259 阅读 · 0 评论 -
职场工作第1点:给出明确的、正面的回答
1、学会对话别人提出问题,我给出明确的正面的回答。先说结论和观点;至少准备1个为什么;如果别人,感兴趣,列出1、2、3.2、业务公司-团队-项目-模块的业务是根本,是创造价值的点。业务逻辑、流程、规则,简洁、清晰,能让产品、前端、后端相关人士等听懂;除了面试,别人不关心你的技术水平、代码能力,就要一个好的工作结果。没有耐心、大概率没兴趣、也可能没能力,去了解你的细节。3、技术自己解决工作中的实际问题;换工作有用。工作重点是:理解意图,根据输入,得到输出...原创 2021-02-04 11:47:24 · 417 阅读 · 2 评论 -
56、坚持正确的做法,要有原则:端口号不是你想要就得给额
y项目对接x项目。y项目的pm需要知道x项目的host,向xx要一下x项目的端口号port。不动脑子的做法:你找我要,我就给你呗。正确的做法:分析问题,按照常理,y项目根本不需要配置端口号port。xx 认为,人家要,你就找到给人家呗。难道还涉及到安全保密?雷:1、了解意图,想干啥。2、根据经验,根本就不需要。当面确认,联系y项目和y项目的技术,确实不需要嘛。3、内部信息对外暴露的越多,今后反而麻烦。今天把端口号告诉你,我想换个端口号咋办?高内聚,低耦合。原创 2021-10-14 09:52:07 · 190 阅读 · 0 评论 -
51到55,用户角度、代码的掌控性、专业的程序员
51、简简单单才是真,没耐心听你叨叨半天开发Internet系统,简简单单才是真。如果我是用户,能快速知道怎么使用这个系统吗?多从最终的用户角度思考问题,而不是只围着“需求方”转。52、框架用的越多,对代码的掌控性就越弱框架用的越多,对代码的掌控性就越弱。总是去研究人家的原理,累死累活。百行代码就搞定,轻松快活。自己的事自己做,你就是原理你就是哥。53、多怀疑自己,少怀疑工具主流工具,用的人很多。低级bug,很少有。这个工具的用法:选择table之后,如果原创 2021-10-14 09:48:53 · 213 阅读 · 0 评论 -
46到50,砍瓜切菜、FAQ、遵循事情的发展规律、滥用高科技、工作todo
46、砍瓜切菜,横扫低含金量的技术业务问题1、上班一天的时间和周末一天的时间,竟然是一样的长,这是为什么呢?2、每天写代码,根本感觉不到有产出,写几篇文档才有,这又是为什么呢?3、及时总结,很多问题就像 砍瓜切菜。47、线上问题FAQ,列出123点每个系统都有线上问题需要关注,经常出现的问题就那么20%的;整理成FAQ,快捷高效。最妥的办法是,找出直接原因、间接原因、相关原因和根本原因,彻底解决;解决不了的,开发可以提高效率的工具。48、遵循事情的发展规律11原创 2021-10-13 20:31:23 · 176 阅读 · 0 评论 -
45、coding搬砖人员,5类日常工作和2种关键能力
Coding类工作,普通业务类系统,工作范围内容,很有规律。高科技高门槛的算法等高端智力类的工作,一般不是主要的。一、5类日常工作1、编写基础的原子API,CRUD的API,普通业务逻辑的API,最后组装各种各样的复杂业务API;2、工程(进度、质量、可读、可维护、可测试);3、协作(需求、任务、交流、协同、汇报);4、业务(行业、公司、项目、产品、业务规则);5、学习大数据Flink等各种技术的使用和原理;工程技巧;沟通交流;公司和项目的业务。学习怎么学习。二、2种原创 2021-10-13 20:26:10 · 316 阅读 · 0 评论 -
38-44,个人修养、个人心态、
38、提高个人修养,掌控个人心态同时遇到3个疑难杂症的时候,会让人有点抓狂,心情烦躁。类似的,其它烦心事比较多的时候,一个人的心情、心理、心态,容易爆炸,需要注意控制。最根本性的方法是:不断提高个人修养。39、闹钟响起来,好记性不如闹钟闹“ehr数据服务:数据库,k8s配置”下次得加闹钟。简单记记还是忘了哎可惜了40、尽量避免:因为自己而导致项目延期薪资小程序,下周二左右,会把后端接口尽快提供好。按照月底上线的目标去做。是否上线,能不能上线,...原创 2021-10-13 20:22:52 · 200 阅读 · 0 评论 -
代码歌第2篇:代码可读性差的根源
《代码歌-代码可读性》基础不牢,地动山摇。面条代码,效率不高。疲于奔命,东飞西跑。磨刀砍柴,方为正道。代码可读性差的根源1、对事物的理解不够清晰,表述不够简洁;2、缺少总结和反思;3、对做的事情没有兴趣;4、认识不到代码可读性不佳,对工作学习的重大负面影响。太多同仁,需要认真阅读《编写可读代码的艺术》、《重构-改善既有代码的设计》、《代码大全/Code complete/完成代码》这3本书了。读书看报,思想不老。知行合一,学习悟道。...原创 2021-03-06 14:26:50 · 570 阅读 · 4 评论