文摘加感悟：中年程序员给年轻程序员的忠告

最新推荐文章于 2020-12-11 14:02:38 发布

勇敢的仙人掌

最新推荐文章于 2020-12-11 14:02:38 发布

阅读量844

点赞数

分类专栏：职业规划文章标签：职业规划开发流程程序设计

本文链接：https://blog.csdn.net/jieming2002/article/details/83478725

版权

职业规划专栏收录该内容

5 篇文章 0 订阅

订阅专栏

开发流程

好代码就是能够自解释的代码。没有注释，代码就是最好的注释。但是做到这一点，很难。
Keras 之父 Francois Chollet 说过：代码不仅仅是用来运行的，也是团队交流的一种方式，是向他人描述问题解决方案的一种方式。
所以命名很重要，避免使用过于笼统的名称，避免使用过于冗长的命名，避免歧义。
尽量使用业内常见的命名。
写代码要避免功利性，应该专注于解决问题。
如果你的代码对于这个产品想要达到的目标没有明显的帮助，就不要添加进去。
以简洁为美。用最少的代码实现功能。
要时刻提醒自己：我们真的应该这样做吗？
仅仅因为有人要求做某个特性，并不意味着你就应该这么做。
必须从整个项目的角度出发，兼顾整体性和原则性。
用户关注的仅仅是他们自己的特定应用场景。你应该考虑总体影响。
在保证软件可用性的同时，你要采取措施来解决这些问题。
构建正确的基础设施，才能不断地持续集成，完整的单元测试覆盖。
先试点，再推广。
事先不要急着计划好一切，先试一下看看结果如何，这样可以尽早对错误的选择进行回退。
使用最简单的解决方案，避免不必要的复杂性。
问题看起来很复杂，并不意味着解决方案必须很复杂。好的软件使复杂的事情变得简单。
做任何事情都要有本源思维。什么是本源思维？
明确说明开发规则，与团队共享。避免隐式规则。避免冲突。
复杂的事情简单化，简单的事情自动化。

API 设计

要站在用户角度思考问题。API是有用户的，要考虑用户体验。
大道至简：尽量减少用户的认知负荷。
减少参数，封装细节，设计简单一致的工作流。
使得用户无需查找教程和文档，即可完成工作。
简单的事情不要复杂化，复杂的事情要简单化。
不要为了少量特殊的应用场景而增加普通应用场景的认知负荷。
API 要与用户的心智模型相匹配。
API 的设计不要整一些高大上的新概念，应该符合业内常识，人家一看就能明白。
选择适合其领域的数据结构。
参数应该是面向用户的、面向问题的。大家一看就能明白。
而不是面向底层实现、面向内部细节，让大家不知所云。
好的 API 应该是模块化和层次化的：易于使用，并具有表现力。
最强大的心智模型是模块化和层次化的：在高层次上很简单，在细节上很精确。
设计端到端工作流，而不是一组原子特性。
什么是端到端工作流？
什么是原子特性？
不要提供一堆功能让用户选择，应该针对使用场景设计最佳工作流。
不要因为有人可能需要它，而添加某个功能。
要谨慎地设计 API 的错误消息。
交互性和反馈是用户体验的一部分。
高质量的文档，能带来高回报。
最好的代码就是不需要文档的代码，只对业内人士有效。
对于小白用户，高质量的文档就很重要了，业内人士也会喜欢的。
文档不要讨论代码是如何工作的，而应该展示如何使用 API，示例代码非常重要。

职业生涯

关键不在于形式，而在于实质。
事业的进步不在于你管理了多少人，而在于你产生了多大的影响，具体地说是你的劳动成果具有多大的影响力。
或者你掌握的技术具有多大的影响力，比如给公司带来多大的业绩增长。
善于合作
软件开发是团队作战，不仅关乎技术能力，而且关乎人际关系。
工作过程中，要保持沟通，有效沟通。
把你的价值观融入你的作品中。
任何产品都不是中立的，都可能对世界产生影响，而这种影响是有道德导向的。
在软件产品中看似无害的技术选择可能会影响使用动机、有人受益、有人受害。
所以技术选择也是伦理道德选择，你要慎重和明确选择支持的价值。
自我管理：要掌控你的工作和环境。
活如逆水行舟，不进则退。职业选择不主动，就会很被动。
寻找机会拓宽你的生活经验，更好地看到世界需要什么。
认知决定了人的发展速度和质量。有用的东西才会发展起来。
应该创造世界所需要的产品，而不是闭门造车出门不合辙。
虽然快速决策和执行的生产力很高，但是错误决定的代价大于等待的代价。
方向正确越快越好，方向错误越快越糟。
经验是生产力的关键，更高的生产力将提供更多的经验：这是一个良性循环。
所以，不要原地踏步，不要故步自封，妹妹你大胆地向前走啊，向前走。。。