掘友等级
获得徽章 0
谈到重构，我跟我们组里的人常说的一句话是：你不用说以后重构，代码运行得好好的，你大概率是不会去重构的，要改现在就改！
重构的最佳时机并不是找出一个专门的时间，一般项目都很难争取到这样的机会（也不是没有，我们就有，只是不太容易），所以重构的最佳时间就在日常业务开发中，迭代开发评估时间时，额外多评估一点，把重构的时间留进去，遇到不合要求的代码，不要去管你的还是我的，该改就改，当然，你得holde住，不过这也是一种态度，让你在技术领域干一年抵三年的态度！
写好代码不容易，写好代码还能被长久维护更不容易，要做到这点，还得是日常事务中去求，正所谓道在蝼蚁！！！
《庄子•人间世》里有一句话：美成在久，恶成不及改，可不慎与！
想想那些线上Bug，修了一个又一个，你就说吧，老祖宗的话，该不该听...
弱者道之用，反者道之动。
看一个人技术怎么样，不看其同意了什么需求，要看其拒绝了什么需求，不看其写了多少代码，要看其删除了多少代码
夫道不欲杂，杂则多，多则扰，扰则忧，忧则不救。
写代码，做加法的多，做减法的少
搞工程项目，欲加人加快工程进度的多，欲去人加快工程进度的少
MCP协议的核心在于让模型自己去发现决定选择哪个接口服务，为什么非要用SSE呢？重点不应该在如何用模型解析参数，决定调用接口，进而使用普通http接口不行吗？
最近与人沟通，思考一个问题，搞开发，往主会遇到工期紧的情况，但真正原因是什么？
大部分人都在找外部原因，比如：上面安排的时间不合理，需求没讲清楚，沟通协作问题等，不可否认会有这类问题存在，但但凡有这类问题的人，往往不从自己身上找找原因，需求是否正确理解，边界是否确认清楚，设计是否合理，代码是否易于维护，线上问题收敛了没，等等，若一个系统能够做到线上问题极少，返工极少，需求做一个少一个，那么产品与技术之间形成互相信任，技术承诺都能兑现，产品就不必用时间压技术，技术不必疲于应付，和谐共处，遇事好商量，何愁工期问题？
再来问一嘴，有个Java开发岗空缺，主要做业务功能开发，涉及一些AI业务开发，团队技术架构稳定，系统规模也不算小，有人罩着，找个工作两三年的有缘人，坐标杭州，有意向的话私信。
最近有个岗位空缺，寻有缘的JYM，Java开发岗位，会涉及一些AI开发，但基本也就是些API，坐标杭州，有意向的话私信
