1.为什么你可以大胆的源码删除代码呢？
2.详解如何用源代码安装软件，以及如何卸载它
为什么你可以大胆的代码删除代码呢？
为什么你可以大胆的删除代码呢？一般的话删除代码都有以下操作删除代码的最佳方法
这看起来似乎是明显的，但我不这样认为，删除因为开发者会使用大量的源码其他方式来删除代码。 删除代码的代码方式如下:
选择编辑器中的代码块，单击Backspace键，删除中转服务器软件源码然后就完成了。源码
许多开发人员不愿意删除已经写出的代码东西，他们想要保存大量的删除代码块以免再次用到。毕竟在编写这些代码块的源码时候他们付出了很多工作，在调试的代码时候，它们可以工作。删除他们不想轻易的源码php橱窗源码将它们扔掉。
这些开发者希望能够保存他们老的代码代码，所以他们使用一些方式将这些代码失效：注释掉，删除条件执行，或者仅仅是不再调用。
对于那些开发者，我想说“使用源（控制），Luke”，一个源代码控制系统（例如 Git， Mercurial，或者 Subversion），意味着你永远不需要担心一些东西会永远丢失。当你再次需要的订购网站源码时候你的储存库会给你提供哪些老代码。
如果你没有一个 源代码控制系统(!?!?!)或者仅仅不想因为查找历史记录而被麻烦，那么可以将代码块复制到一个单独的文件区域，并保存。但是不要让代码留在他们不应该在的地方：在你的源代码里。
What"s the big deal?
如果你有一块不再需要的代码，有一个需要删除它而不是将它处于失效状态的重大原因：减少噪音和不确定性。一个开发者会碰到一些最糟糕的敌人就是代码中的噪音和不确定性，因为未来这些会导致代码不能有效地运行。
失效状态的代码块会引起不确定性。它会对其他开发者带来疑惑：
§ 这个代码过去为什么是这个方式？
§ 为什么新的方式更好？
§ 我们需要需要换回就的方式吗？
§ 我们怎么决定？
如果这些问题的答案需要人们知道，那么写一个注释说明它。不要让你的rails 项目源码合作者猜测你的用意。
注释掉代码
注释掉一行或者两行（甚至行）代码是非常简单的：
// OldWayStepOne(fooey);
// OldWayStepTwo(gooey);
NewWay(fooey, gooey);
这些注释是糟糕的。注释应该用于给读者提供他们阅读或者编写代码时需要的信息。注释应该用于帮助未来将会使用这些代码的开发人员。但是上面的注释并没有起到这些效果。事实上，它们的作用刚好相反。在将代码从编译中移除的同时，这些注释增加了代码的混乱、不确定性以及可质疑性。
后续的开发人员在查看这个代码时会知道它老的运行方式，也会知道它新的运行方式，但是河狸家 源码它们不知道为什么老的运行方式依旧被保存着：
§ 可能新的方式只是一种实验？如果是这种情况，那么更好的代码是什么？最终版本的代码是如何以及何时保存的？
§ 或许老的方式是更好的，但是有一些错误？如果是这样的话，错误在哪里？是老的方式中代码有问题，还是我们调用时产生的问题？何时会被修复？
§ 或许设计以及改变了，所以老的方式不足以胜任？
任何的注释掉的代码都是一个潜在的问题“为什么它仍然存在？保留一块注释掉的代码是有理由的，比如当你知道很快就会恢复或者那些并不确定的修改。保存代码通常没问题，但是你需要表明为什么保留，注释是为了给别人看的，而注释中的代码并不能告诉任何人任何事情。
不要在没有任何解释的情况下注释掉一段代码 (in the comment).
下面这种方式会不会更好？:
// OldWay did a better job, but is too inefficient until MumbleFrabbitz
// is overhauled, so we"ll use NewWay until the M4 milestone.
// OldWayStepOne(fooey);
// OldWayStepTwo(gooey);
NewWay(fooey, gooey);
现在，谁知道是否MumbleFrabbitz真的会迎来M4里程碑式的大修？或许这种情况不会发生。但是没关系，谁能知道未来会出现什么情况？至少通过这种方式开发者会知道代码被保存下来的原因。通过对改变的解释以及老代码存在的原因说明，开发者会知道他们可以安心的使用新方式，或者何时他们可以有到更好的解决方法。
详解如何用源代码安装软件，以及如何卸载它
在Linux环境中，自编译源代码安装软件和卸载它们是掌握高级技能的一部分。本文将指导你如何从头开始，包括从GitHub获取源代码，理解构建系统，以及处理可能遇到的问题。
首先，从GitHub上找到你需要的源代码，如NodeJS 8.1.1，这是一个特定版本，可能在官方仓库中未提供。GitHub是一个版本管理平台，你可以通过分支和标签轻松导航到不同版本。
下载源代码后，你需要理解软件的构建系统，这通常涉及configure和make工具。configure检查系统配置，make则执行构建和安装。对于NodeJS，它使用GNU风格的构建系统，允许你定制安装路径，遵循FHS标准。
如果你选择在/usr/local安装，可能会导致文件混淆，所以推荐在/opt下创建专用目录。在编译过程中，任何非“ok”信息都可能暗示错误，需逐行检查并重新构建。
遇到依赖问题时，可以通过包管理器或安装相应的开发工具来解决。比如，Debian可能需要build-essential包，而在CentOS中可能是Development Tools组。
如果你想修改源代码，可以在编译前做改动，然后重新编译。确保在二进制文件中看到你的更改，以确认安装了新版本。
最后，为了让shell能找到你编译的软件，可以添加到PATH环境变量或创建指向二进制文件的符号链接。卸载则只需删除编译后的目录，注意不要误删重要文件。
尽管自编译过程中可能遇到依赖地狱的问题，但在NodeJS等简单项目中，这个问题并不显著。对于更复杂的情况，包管理器和发行版的贡献者已经尽力去解决依赖问题。
本文提供了一个基础的指南，对于高级话题如依赖管理，作者邀请读者在评论区分享兴趣和问题，这将是更深入讨论的起点。
