结束语 | 写代码是一件可以一生精进的事
程序员精进之路
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
程序员精进之路是一场终身学习的旅程，需要持续追求技术的精湛和创新。在文章《代码的敏感度》中，作者郑晔分享了自己在编程领域的二十多年经验，强调了热爱编程的重要性。他指出，编程不仅是解决问题，更是一种智力活动，需要不断积累和探索。持续学习是关键，从基础知识到软件设计、编程语言和最佳实践，都是为了更好地写出优质的代码。作者认为写代码是一门手艺，需要不断打磨，保持对代码的敏感度，不断思考改进的可能性。他强调了持续学习和不断追求更好代码的重要性，这是程序员精进之路的核心。通过作者的经历，读者可以深刻理解编程技术的特点和精进之路的重要性。文章内容深入浅出，为读者提供了对编程技术的全面认识和启发，是一篇值得阅读的精彩文章。
《代码之丑》，新⼈⾸单¥59
全部留言(24)
- 最新
- 精选
qinsi个人感想： * 郑老师从业二十多年依旧在打磨编程手艺，瑞思拜！ * 依稀记得RUP刚出来的时候，就有人认为今后程序员会被淘汰，因为你甚至可以画画图就生成代码。二十多年过去了，为什么编程仍旧是一门手艺活，而不是大规模的工业化生产？ * 我觉得大厂们应该早就实现了工业化生产，毕竟好多年前就可以在一天之内复制粘贴出一个竞品App出来。那么在这样的大厂的工业化生产中，个人手艺的重要程度有多少呢？ * 说到磨练手艺似乎就会讲到匠人精神，讲到匠人精神大多会拿日本举例子。举个听来的日本刀的例子。职业的刀匠花费大量时间人工打磨的日本刀可以作为工艺品卖出高价，但如果要大规模装备军队的话，就只能依靠工业化生产降低成本。日本刀的收藏家会为刀匠的手艺买单，那么是否会有客户为编程的手艺买单呢？ * 通过文学编程来反对注释可能有些牵强，毕竟曾经有段时间通过在代码注释里写文档再把文档抽取出来（如JavaDoc）也被称为文学编程。程序员不爱写注释和不爱写文档的理由应该是一样的，那么解决的方法只有两种：要么代码像文档一样清晰，要么文档本身就是可执行的代码。郑老师讲的应该是前者，而个人理解的文学编程是后者。文学编程在数据科学/机器学习等研究性质的编程中用得较多（如Jupyter Notebook）。生产系统中要用的话，可能会是DSL的形式？（如Cucumber） * 散弹式修改和发散式变化，应该能够通过自动化分析提交历史得出，这样就不需要依赖个人判断了。不知道都有哪些工具实现了？作者回复: 手艺的重要性，取决于你给自己的定位。 从行业整体的角度上，写一个 App 或是网站的速度，确实是越来越快了。这是建立在我们现在有了大量的基础设施上的，有人在最初设计好了架构，其它的程序员都是在这个架构基础上进行构建。这就在建筑行业，有人是设计师，有人是负责施工，你想扮演什么角色呢？ 建筑的设计师，他们其实也是艺术家，但其实他们也是手艺人，市面的建筑工人可以找到很多，但建筑设计师却很难找到一大把。 在程序员这个行业里，优秀的架构师和普通的代码编写者之间并没有一个清晰的界限，他们都在写代码，但他们写的代码重要性是截然不同的，当然，他们的身价也是截然不同的。 你去问任何一个架构师，他绝对不屑于只完成功能，他肯定有更高的追求，无论是让系统的架构更有可扩展性，还是让系统承载更大的容量，抑或是让系统变得更快。这些都是一种不断打磨的手艺，需要不断地锤炼。 当你一不小心走到一个公司或是一个领域的最前列，能够给予你指导的，不再是别人已有的解决方案，而是你的品位，而品位的锤炼就是在日常中不断打磨出来的。 回到你的问题上，你可以选择永远做一名普通的编码者，在别人画好的圈子里面跳舞，但也没有资格抱怨，世界对你的不公，为什么程序员是有天花板的。你也可以让自己不断地提升，去追求更好的手艺，成为那个让别人可以依赖的人，去解决更多好的问题。
2021-02-09225
webmin关于注释最近我也冒出了困惑，事由是这样的新来了一位同事他写注释很勤奋，几乎达到一行代码一行注释，当时隐隐觉得不对劲，Review他的代码后，发现基上是业务怎么要求他就怎么翻译为代码，缺少聚合和封装，因为大家不是一个项目组，且我也不负责考核他，所以就没有去做进一步的事。 故事到这你肯定好奇我为什么会去关心他的代码和注释，这是因为这哥们做我背后，他打字手很重，就像一挺JQ在持续扫射，以我的经验除了聊天时大家打字有那么快以外，非除是遇到代码大神已经 把绝大部分的事想得很清楚一气合成所有的代码，要不都会在编码时有停下来一段思考的时间，在一天中不会连续高强度的持续输出有效代码。今天在看到"一个好的程序应该像一篇优美的文章，读起来自然流畅，二者背后有诸多相通之处，你会看到，许多优秀程序员都有着优秀的表达能力。"深以为然，作家在写作时是要经过反复构思来回修改的，形象点的说法叫磨稿。作者回复: 每每写专栏，于我自己而言，就是一遍痛苦的梳理过程。你们看到的稿子都是几经打磨之后的产物。
2021-02-096
穿越时间与空间的旅行家感谢老师的分享，由于最近项目重构，学了老师的课感觉受益非浅。中间又去听了10x程序员和软件设计之美。希望能早日看到老师的新课程。作者回复: 三合一味道最好
2021-02-096
ifelse
感谢郑老师，我把您成称作真正第一位教我怎么写代码的老师。自己以前写代码觉得别扭的地方，原来就是缺乏设计，体现了坏味道。看了老师的3篇专栏，让我茅塞顿开。还有老师的一篇 "程序员的测试课"" 专栏，我已经迫不及待要去学习了。作者回复: 欢迎捧场
2022-06-03归属地：陕西23
捞鱼的搬砖奇当年听你的10x 的做了个一份xmind https://gitee.com/meiyoudaima/xmind/tree/master/10X 现在这门课收尾了，准备整理下，再做一次记录 谢谢老师，期待下一门课程。 祝老师新年快乐。作者回复: 欢迎分享
2021-02-113
Jxin
1.结束得太快了。100章结束了，下一站做啥？期待下个专栏。 2.感谢郑老师的分享，我们下次再见。作者回复: 可能会考虑在这个专栏做个加餐，分享一些写代码的思考。
2021-02-093
小钟谢谢老师，从老师的文字可以看出老师对写代码的诚意。老师的三门课程都买了，有两门看完了。虽然课程名字和主题不算高大上，但是内容真的觉得很实用。希望老师可以继续写更多的专栏！作者回复: 多谢支持，我会继续努力的。
2021-03-272
sun老师，想请教一个问题，java8提供的函数接口中有了Supplier<T>,为什么还要再提供IntSupplier,DoubleSupplier...呢作者回复: 因为int、double这些类型是基础类型，如果使用标准版就变成了包装类型，有一个打包解包的过程，效率低。
2021-07-161
续费专用纸上得来终觉浅，觉知此事要躬行，老师的文章很有实际价值，我这段时间收获很多，希望后来的人也能读到这个专栏，动手实操，也能和我一样有很大的收获。作者回复: 动手的收获是真收获
2021-02-201
阿尔法郑老师，问个问题，我看一些好的开源软件各种继承、实现类关系很复杂，这些开源软件开发之前是需要建模吗？这么多关系怎么分配？作者回复: 这其实是一个设计问题，设计一开始都不会太复杂，只解决核心问题，随着需求的增长，设计才会一点一点复杂起来。
2021-02-191