Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
kingreatwill
open
提交
6a9b2e4a
O
open
项目概览
kingreatwill
/
open
通知
13
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
O
open
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
前往新版Gitcode,体验更适合开发者的 AI 搜索 >>
提交
6a9b2e4a
编写于
11月 09, 2021
作者:
kingreatwill
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
二十年老程序员的五条心得
上级
6279839d
变更
2
隐藏空白更改
内联
并排
Showing
2 changed file
with
45 addition
and
1 deletion
+45
-1
MachineLearning/Model-Selection.md
MachineLearning/Model-Selection.md
+2
-1
personal/README.md
personal/README.md
+43
-0
未找到文件。
MachineLearning/Model-Selection.md
浏览文件 @
6a9b2e4a
...
...
@@ -357,7 +357,8 @@ https://scikit-learn.org/stable/modules/classes.html#module-sklearn.inspection
## 模型可解释性工具(可解性模型/可解性工具/可视化工具)
### imodels
https://github.com/csinva/imodels
### DALEX
https://github.com/ModelOriented/DALEX
### ELI5
它可以为以下机器学习框架和软件包提供支持:
...
...
personal/README.md
浏览文件 @
6a9b2e4a
...
...
@@ -82,6 +82,49 @@
-
行业产品: 商业(10万家珠宝门店)、产品(互联网+新零售)、技术(微服务+大数据、技术竞争力)、团队建设和管理、风控
### 二十年老程序员的五条心得
#### 1. 我懂的并不多
“你怎么会不知道什么是 BGP?”“你难道没听说过 Rust?”
类似的问题可能每天都会出现在我们面前。没错,投身于软件行业的很多人之所以热爱这份工作,就是因为它敦促着我们终身学习。
在软件领域,无论我们朝哪个方向前进,都有着广阔的知识空间不断延伸而且每一天都有所变化。换句话说,这是一份能够承载我们度过几十年的职业生涯,而两位在类似岗位上分别工作了几十年的人之间也很可能存在巨大的知识差距。我们越早意识到这一点,就能越快摆脱“冒充者综合症”,成为一个乐于向他人学习、也乐于教导他人的积极分子。
#### 2. 软件里最难的部分,是构建正确的东西
我知道这种话大家肯定听过无数遍了,但大多数软件工程师仍拒不承认,理由是这种说法似乎在贬低他们的工作成果。我个人觉得这样的心态大可不必,这类表达其实是在突出软件开发环境中的复杂性与非理性因素,而这些都会加剧我们面临的挑战。我们当然可以设计出在技术上最令人印象深刻的东西,但却没人愿意用——这类困境随时都会出现。
软件设计主要是一种聆听活动,开发者往往身兼软件工程师、通灵师乃至人类学家等多重角色。而我们对这种设计能力的每一点投资,无论是引入专业的用户体验师还是接受更进一步的自我教育,都能给开发成果带来巨大提升。毕竟与打磨设计能力相比,开发一款“没人用”的软件成本还是太高了、太高太高。
#### 3. 顶尖软件工程师会像设计师那样思考
伟大的软件工程师会深入思考代码成果的用户体验。虽然使用的术语或者切入点不同,但无论是对于外部 API、编程 API、用户界面、协议还是其他接口,优秀的工程师都会考虑由谁来使用、为什么要使用、如何使用以及对用户来说哪些因素真正重要等。总之,牢记用户需求才是实现良好体验的核心所在。
#### 4. 最好的代码就是没有代码,或者说不需要维护的代码
“程序员就是管编程的”,而且跟其他专业人士一样,我们也会在自己最擅长的方面犯错。这是人的本性,没办法。大多数软件工程师编写出的代码总是有点错误,而且往往无法用非技术方案来解决。
另外有一种很神奇的现象,越是有大量相当成熟的解决方案存在,工程团队就越是想“重新发明轮子”。想表达自我、加快专业成长当然是好事,但还请大家分清场合与需求,过度泛滥的发明欲望恐怕不利于编写出无需维护的代码。
#### 5. 如果没法理解所有可能性,就设计不出优秀的系统
这也是我个人一直在努力解决的问题。我的职责变化导致自己距离常规软件工程任务越来越远,我发现跟上开发者生态的发展速度越来越难,有时候自己甚至不理解哪些趋势真正重要。总之,如果不能理解特定生态当中的那些可行性与可用选项,那么我们根本没办法为所有问题找到合理的解决方案。
总而言之,
**务必警惕那些已经很久没写过代码、也没设计过系统的所谓“大牛”**
。
### 统计分析 报表
http://opendigger-oss.x-lab.info/global-study.html
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录