极客观点
项目管理
HarmonyOS
几个月前写的代码，现在再看发现看不懂了......
新手上路，请多包涵
当然有
避免这个问题 注释要严谨
1.要注明整个功能的用途 便于再次遇到后，可以直观的知道这个类，或者这部分代码的用途
2.对于存在复杂逻辑条件的代码，要精细注释每个条件逻辑的作用
3.如果存在非常复杂的内容，需要单独将这部分逻辑的阐述加到文档中
4.每个类的开头部分可以增加修改日志的注释，便于了解这个类的发展史，当然这部分也可以在提交代码时，将每个提交注释清楚，在git中就可以通过修改日志，来了解改动
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
- 最好有文档,需求文档,设计文档,阅读文档回忆.
- 如果没有文档, 查看有的代码注释, 解释代码的设计思路, 输入输出的数据含义.
- 实在上面两个都没有,找一下以前的沟通的聊天记录和相关人员回忆下对应的开发场景.
- 如果还是不了解, 就跑一下代码, debug理解一下代码的逻辑.
- 如果代码都跑不起来, 那估计就难看的懂了.
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
当然会有的，甚至会说，谁写的这么垃圾的代码， 一看是自己， 哈哈哈哈
写注释 ！ 写注释 ！ 写注释!
时间允许的情况下，写写周报和日报记录一下，当完了看到就不会懵了。 哈哈哈
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
这个很正常。有时候甚至感觉不像自己写出来的东西。
开发过程中，我们可以在关键代码加上注释，然后遵守良好的命名规范。也可以组织团队定期搞一搞code review
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
The proper use of comments is to compensate for our failure to express ourself in code.
-- Robert C. Martin 《Clean Code》
通过代码进行阐述，是注释否定论的核心思想。当你花功夫来想如何写注释，让这段代码更好的表达含义时，我们更应该重构它，通过代码来解释我们的意图。每一次注释的编写，都是对我们代码表达能力上的差评，提升我们的归纳、表达、解释能力，更优于通过注释来解决问题。当代码足够优秀时，注释则是非必须的。并且需求在不断调整，代码一定会随之变动，但注释可能慢慢被人遗忘，当代码与注释不匹配时，将是更大的灾难。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
重要的事情，楼上已经强调了不止三遍了【写注释，写注释，写注释】
其次，还要注重代码风格，这样即使是很久以前的代码也不会看起来像s-h-i一样~
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
所以代码最佳实践最重要，总的说来，个人认为可读性代码很重要，主要体现在以下几个方面:
- 每个函数和方法都应该有明确的注释说明函数和方法是干什么用的。
- 每一个代码块完成了什么功能或者什么任务，都应该注明完成了什么。
- 如果采用了复杂算法，则更要写注释说明这个算法是干什么的。
- 尽量不使用黑科技，如果使用黑科技，也应该写注释说明。
具体到代码的话，个人认为就应该做到如下几点:
- 变量和函数名应该尽量语义化，例如，car，能够让人一眼就看懂这就是一个car变量，表示汽车，再如getCarName方法名表示获取汽车的名字。
- 变量的类型也要注明，如果使用typescript这没什么可说的，如果没有使用，那么有三种方式表明。
2.1 初始化值给定一个默认值，因为这也代表了以后这个变量就是这个类型，例如let bool = false能够让人一眼就看出来这就是一个布尔值。
2.2 使用匈牙利表示法，定义变量带前缀表示类型，例如let bStatus = false,其中b前缀就是Boolean的意思，代表布尔值。
2.3 使用多行注释标明类型，例如:let bool /*boolean*/ = false - 解耦HTML与CSS还有Javascript
也就是说HTML,CSS,Javascript各自做各自的事情，没有必要耦合在一起。比如:
<!-- 使用<script>造成 HTML/JavaScript 紧密耦合 -->
<script>
document.write("Hello world!");
</script>
<!-- 使用事件处理程序属性造成 HTML/JavaScript 紧密耦合 -->
<input type="button" value="Click Me" onclick="doSomething()"/>以上代码很显然是不好维护的，如果将HTML和js解耦，那维护起来就比较容易了。
- 解耦事件处理程序和应用程序逻辑
例如:
function handleKeyPress(event) {
if (event.keyCode == 13) {
let target = event.target;
let value = 5 * parseInt(target.value);
if (value > 10) {
document.getElementById("error-msg").style.display = "block";
}
}
}和如下代码:
function validateValue(value) {
value = 5 * parseInt(value);
if (value > 10) {
document.getElementById("error-msg").style.display = "block";
}
}
function handleKeyPress(event) {
if (event.keyCode == 13) {
let target = event.target;
validateValue(target.value);
}
}哪个更好维护显而易见。
- 尊重对象所有权，不要给对象实例或者原型添加属性和方法，也不要重定义已有的方法。
- 尽量避免声明多个全局变量。比如如下代码:
// 两个全局变量：不要！
var name = "eveningwater";
function sayName() {
console.log(name);
}可以修改成:
// 一个全局变量：推荐
var MyApplication = {
name: "eveningwater",
sayName: function() {
console.log(this.name);
}
};- 具体变量类型应该具体判断，例如判断数组，可以采用Array.isArray方法，而不应该仅仅判断它是否是一个对象。
- 多多使用常量，如果程序当中有重复出现的值，以及一些用户界面的字符串，还有URL和任何可能变化的值都可以分离出来写在常量中，这样做的目的就是实现数据与逻辑的分离。
做到如上几点，基本上代码就很好维护和可读了，哪怕就算是一年前的代码，一年后再去看，也可以自信的说，这代码写的真棒，很好维护。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
这段时间要么你的技术水平有提高了，觉得以前写的就是shit，要么就是以前写的太烂了，注释没有，代码质量不够，能写注释尽量还是要写注释的好，尤其是复杂的功能逻辑。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
良好的开发习惯会减少这种状况的出现，语义化、文件头部的功能说明及业务代码中适当的备注是不能少的。
但是不管怎么样因为长时间不接触仍会出现遗忘的情况。特别是在一些复杂的业务当中，甚至需要专门书写业务说明文档来防止业务逻辑遗忘或者后继者无法接手。
所以尽量在第一遍开发的时候就按照可读性的方式去开发，如果你不知道什么是可读性，就抱着写出来的业务代码需要让其他人能读得懂的想法来就可以。
这样即使未来遗忘了也可以重新阅读代码而回忆起当时的思路。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
确实很正常。如果说代码逻辑比较复杂，又没有写注释，就比较操蛋了。如果你记忆力很好，多看一会代码，理一下逻辑可能就清楚了。如果真的记不起来，有些代码是干嘛的，可能就只有重新打断点走一遍，才能理清楚。
所以经验教训告诉我们，如果逻辑复杂一点，一是一定要写清楚注释，二是最好写设计文档。设计文档中写清楚数据结构的设计，逻辑流程图、关系图等。三是一定要上TS，至少说TS的大部分类型定义，会让你清楚一些函数和变量是干嘛的，不至于完全蒙蔽。
最后就是本身写的代码，要简洁、逻辑条理清晰，不要绕太多弯路。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
感觉是程序员都经历过，磨练磨练后面会好很多，毕竟当时写代码跟各种因素有关系，比如产品的临时紧急改动、喝多了、心情不好等等，导致写出了一些能用就行的代码。
哪怕是加了注释或者TODO标签，大概率也是自欺欺人，很少可能性会及时去跟进。
等到一段时间去看时，发现已是”人是代码非“。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
有这个经历，不光是这个，还有之前写的功能，现在忘记当时为什么要加这个了，解决了什么问题。隐隐约约有些印象，但就是想不起来……
所以还是多写注释，多写文档吧。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
有啊，经常！要不是git又提交记录，我都会骂一句，“这谁呀~写的这是个啥玩意儿啊！”，然后鼠标一放过去，定睛一看，提交人是我自己。。。
所以，平时开发前写技术文档、开发中写注释、开发后写总结，还是很有必要的！
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
撰写回答
你尚未登录，登录后可以
- 和开发者交流问题的细节
- 关注并接收问题和回答的更新提醒
- 参与内容的编辑和改进，让解决方法与时俱进
被 1 篇内容引用
窝巢，这烂代码居然稳定运行了这么多年
窝巢，原来这里有个BUG，可是竟然没触发过
窝巢，这里明明可以一行代码搞定的，竟然用了三行
窝巢，竟然没写注释，真为现在维护我代码的人感到悲哀
窝巢，手写红黑树也只有刚毕业的孩子能干得出来了
窝巢，原来C语言解析一个配置都这么麻烦，我用Python后都不知道怎么写C了
窝巢，当时我这么努力，老板为什么看不到
窝巢，看这头文件注释，原来都过去了这么多年了
窝巢，当年我写这个代码的时候的女朋友不知道现在怎么样了 /(ㄒoㄒ)/~~
已参与 「极客观点」 ，欢迎正在阅读的你也加入。