如何在没有编译器的电脑上编写程序？

如果您想在没有编译器的电脑上编写程序，有以下几种方法可供选择：

使用在线编辑器：网上有很多在线编辑器，您可以使用这些工具来编写程序。例如，可以使用在线IDE（Integrated Development Environment）工具，比如CodePen、Repl.it等。这些工具不需要您在本地安装编译器，可以直接在浏览器中使用。

使用文本编辑器：如果您的电脑上有文本编辑器，比如Notepad、Sublime Text等，您也可以使用它们来编写程序。不过，这样需要您在本地安装编译器，并且需要自己手动编译和运行程序。

使用语言自带的命令行工具

40267">

我从编程写软件学到的 7 件事，其实学习编程不难，写软件也不你那，就看我们如何看待了！

我正在一点一点的从一个工程师转型为管理者。别弄错了，虽然我在转管理，但我仍然在每天写代码。不过我发现自己在会议和电话中会花越来越多的时间去分析讨论，试着去组织团队，并且为全局部署而不是具体战术而烦恼。

当然这不是一件坏事。高层次的决策往往比单个的类和函数的细节更有影响。让一个团队更有效率，比仅仅让自己更有生产力有更高的杠杆作用。但我想我已经从我多年来的编程中吸取到了一些经验。我希望大部分经验可以应用于管理方面。

1、没有规定（rules），只有公案（koans）

译注：公案（Koan）有五种重要的涵义： 作悟禅的工具； 作考验的方法； 作权威的法范； 作印证的符信； 作究竟的指点。）

举个例子：DRY，意思是「不要重复你自己」。作为软件的基本规则这很好理解，因为很多话可以证明：“我做 X 是因为它没有重复。”这说得通，不是吗？如果你有两个或者两个以上部分的代码在做相同的事情，说明你正在浪费。而且如果当你需要改变它们其中一个的时候，你可能也需要改变其他的，并且你很可能会忘记这么做。当它们不同步时，你会得到一个怪异的 bug。因此很显然你不能重复你自己。

然而，在使用了几年之后，人们开始怀疑它的普遍适用性。假如你的两个方法中包含相同的代码块，所以你将其拿出来形成一个单独的函数。通常那些方法会开始朝不同的方向发展…接着你发现自己要在函数中加入更多的参数，很可能为结果立了更多 flags……然后下一个接手的程序员会因为分离出来的函数以及它所带的特定的参数和结果，而出现认知负载。你会意识到如果当初允许自己重复，并让两块代码自然的发展为不同的个体，你生成的代码将会更简单直观。

这意味着 DRY 不好吗？当然不是！通常在合适的环境下使用 DRY 是正确的…好吧，也许。我个人的经验是：“重复一次是可以的，超过一次就不太好了…当然这取决于所处的环境。”因为所有事都取决于环境。DRY 的目的并不是为了 DRY。如果你迷信于此，小孩儿，那你还有太多要学。DRY 的目的为了让你了解 DRY。那当然不是规定，仅仅是公案。

（让我重申一遍：我在讨论的是软件。在我的经验中，硬件规定的确更倾向于是我们所理解中的规定。这就是我为什么要从电气工程转到软件的原因）

细想我最喜欢的两个计算机科学“定律”。第一：“计算机科学中没有一个问题是不能通过添加另一层抽象来解决的！”这句话完全正确吗？当然不。这在现象学上是正确的吗？实际上，的确是。这是否意味着抽象是解决任何问题的正确途径？不，不是。它是一个公案，可以启发思想。

还有我历来最喜欢的：“第一优化定律：不要这样做。第二优化定律（对专家而言）：不要又这样做。”这显然是一个公案，却称自己为法规。是时候让你的代码运行的更快吗？不。是时候让你的代码运行的更快吗？还不是。什么意思？意思是要考虑到时间，复杂性，认知负载，具体结果，生活意义，人类存在的意义。并且三思而后行，小孩儿。但不要花太长时间，我们还有工作要做。

2、要想得到他人的信任，先信任他人

这不仅仅针对于管理者。虽然它对管理者尤其重要。信任是你真正拥有的唯一价值。如果你的公正、判断、理解、诚实不被信任。接下来你组织的成员将把你视为祸害并绕着你走。然而，如果你是个有能力但不被信赖的开发者，你可能还有一些价值。虽然你在每个决定上做的努力都会被大大消减。

不过更重要的一点是：一个团队的成员需要互相信任。当 Natascia 说：“我来解决那个问题单（ticket）”，你必须相信她会去做。当你说：“Peter 能在截止时间前完成的。”，你必须相信那会实现。当某人说，“我有一个疯狂的点子”，他们必须信任他们会被尊重和认真对待，尽管那点子的确很疯狂。

你是如何建立和得到信任的？答案很简单：你去信任他人。你相信那个说他可以学会这个新库并且在周一前会整合完的人。你相信那个说他需要提前离开，因为家里有事而会错过明天工作的人。你相信那些想在截止日期前一个月休假的人，因为他们觉得自己已经开始筋疲力尽了。你相信说想要解决难题的初级程序员。

但你不总是正确的。有些时候人在工作上存了坏心。你需要揭露这些人的真面目，让他们尽早离开。有时候你要信任那些真心想成功的人，虽然他们会失败。但违反常识的是，长远来看这通常是个胜利。因为那些人会记住你的信任，他们会尽一切努力来报答你。

3、简单比优雅重要的多

我也喜欢紧凑优雅的代码。我喜欢灵活的框架，有如此多抽象层次随时待命，无论抛出什么改变的需求都能解决。我喜欢使用位向量、位位移、略微复杂的数据结构和不太流行且古怪的小语言特性，但在特定环境下十分实用。

然而你并不只是为了你自己写代码。即使它只是个“原型”。（我已经记不清我有多少“原型”在多次对层 *** 作和润色的过程中出现问题。）而且你不仅仅是为了解决当前的问题编写它。你正在为了下一个接手的开发者可以使用它来解决下一个问题而编写。把你写到那五行代码扩充为十行可以增强其可读性，你知道吗，也许扩展为十五行效果会更好。

你可以提前尝试并用灵活且充满抽象的框架解决它们。但是也许预言不是你的强项，也许你关于下一个问题的概念的想法完全是错误的。也许仅仅编写足够简单的代码才是最佳选择。有一个命名约定和一个编码风格，让它读起来像英语一样。也许不是添加一个类，而是下一个开发者在试图跟随你的控制流程时必须保持另一个文件的开放。你应该用愚蠢的方式，不雅的方式，简单的方式。

4、动力比大多数事都重要

我们都曾见过这种情况。一周里每个人都在检查代码，构建显而易见的雏形，每天不断增加特性，测试覆盖率越来越高。疏忽也随着生产的想法和解决方案而出现。不知怎么的下一周所有事都变得缓慢起来。关于 A 的决定，会影响到 B、C和 D。当人们可以运行D、E 和 F 时，它们不是逻辑序列发展上的一部分。于是需要做更多的假设，认知负载加重，你不得不模拟出一堆东西来写出非模仿代码。一些人需要做这个决定。

或许不是决定会瘫痪，是你上周所做的一切都在错误的基础上，是一个“地震多发区”的技术负债。你需要停止所有事返回并重构它。而且你必须马上开始，因为等的时间越长，事情会变得越糟糕。没人想看到这种事发生 。但他们宁愿现在面对也比下个月知道的好。让暴风雨来的更猛烈些吧。

也许上周每个人都拼劲全力，现在实在撑不住了。你知道该怎样吗？得让他们休息一下，每个人，休息一整天。我保证，这会给你接下来的“长跑”节省时间。

I我们很难定义、衡量以及说明动力。但它在软件开发中是真实存在的东西。而且它的缺失会成为造成首要影响，导致我们需要去解决很多根本问题。别忽略它，也别期望或假装它会神奇地回来。察觉警报并迅速采取行动。

5、与和你互补而不是像你一样的人一起工作

每当我看到人们根据“文化契合度”来找人的时候，我就会拼命翻白眼。你知道大多单一栽培会发生什么吗？他们遭遇了他们不知如何解决的病原体，然后嗝屁死翘翘了。

你不会希望你的所有开发者、设计者、 QA人员、产品人员、销售人员和执行官是彼此的克隆人。你肯定不想。每个人都有自己的长处和短处、优点和缺点。你想要雇佣的是他们的长处，让其他人的长处弥补他们的短处。

比如说我，写代码非常快，擅于沟通，读写文章都奇快。我在任何时候都能熟悉很多编程语言和框架。我理解东西透彻且迅速，有丰富的经验。然而我还是一个在特定领域、框架和语言缺乏深刻专研、精通掌握的全才。我是一个真正从别人身上获益的建筑师，跟踪所有需要，在骨骼构建好之后添加肉体和润色。我还是个 UX 盲（等一下，你说那些还没对齐？），这一直被当作同事之间的玩笑。

像我这样的人非常难找到也是及其被需要的。但一个由我和九个像我一样的克隆人组成的公司是从一开始就注定要失败的。唔，我们会把很多事情做好，但只需要一个集中的盲点，一个灾难性的空隙就足以毁灭公司。大多数人承认有些事情他们做不好，另一些人可能需要照应。这些人往往是寻找“文化契合度”的人，并试图雇佣和他们一样的人。真令人哭笑不得。

6、任何决定都比没决定强

别犹豫，当你拿不准主意时，去做就好了。当然，这可能不适用在生产代码的时候。但它可以应用于除此之外在软件开发里的任何方面。我们在历史上发展最快的行业里工作。我们生活在以指数形式发展的世界里。时间不等人，别浪费它。

这与低级决策的高级讨论一样真实。在高水平的讨论里，比如“我们应该实现特性 A 还会说 B？我们要用哪种方式实现呢，X 还是 Y？“，常常会产生这样的对话，”让我们先跳过这个…下周再对它进行讨论…“，或者更阴险的，”让我们先研究一下其他人做了什么再来讨论一次。“这样的问题极少情况下会有正确答案。大多时候，像这么说才是正确的，”我会在今天之前决定尝试哪一个，这样我们就可以明天开始行动了。

甚至 A 选项基本上是错误选择，开始进行 A 大概也比啥都不做强。这和直觉是相悖的，但它通常也是正确的。以实际上手的方式去理解 A 的本质是一个更好的办法，这个道理始终是正确的。这样的理解可能会引导你做出更好的决定。

对于低级决策，那就更应该如此了。“规范没有说明我们应该如何处理错误条件 X，或者错误信息应该是什么。”(规范似乎是为一个有抱负的乌托邦写的，在这种乌托邦中，错误条件和独角兽一样罕见。)“我知道，我只是想插一句，回去问问他们在这种情况下想做什么!”

这非常诱人。如果你这么做，没人能指责你哪里做错了。但这么做是错误的。宁愿继续自己做决定，尽管有些鲁莽，也不要什么都不做等着问别人。让它们在你做已经写好的程序和你学到的教训里迭代，虽然你知道这并不完美，也好过从头开始错误认知。它们和项目将会变得更好。快速尝试，快速改变方向。

7、保持谦虚，但要自信

你不需要所有的答案。甚至是我也不得不勉强承认我不会有全部的答案。可恶，我甚至连它们的大多数也没有，不过我有自信，只要给我足够的时间和精力，我能弄清楚大部分。并且你也可以。

我们无法都成为 Jeff Dean（谷歌大牛）、中本聪（比特币创始人） 或是 Margaret Hamilton（登月计划中的女程序员）。我们在一个充斥着真正的天才和自称天才的地方工作。没人知道所有的事情，每个人都敏锐地意识到他们所不知道的一切。幸运的是，大多数情况下，我们不是科学家。我们的工作不是去寻找新突破。我们的工作是实践他人的发现，使东西运转，希望服务于人们真正想要的东西。也许你永远不会发明任何东西，像是布隆过滤器或默克尔树。不过大多与你共事的人们也不会。而且这不是重点，重点是使用布隆过滤器和默克尔树，亦或是在它们之上建个抽象层，来实际的完成它们。

所以假设你懂的会比在座的人都多是错误的，就算你觉得他们违背直觉的想法很疯狂，他们的语言选择很糟糕。假设人家比你懂的多也是错误的，即使真是那样，也没关系。世界上多的是聪明人因为一些不可思议的原因什么实际东西也没做出来。（开个廉价的玩笑╮(╯▽╰)╭：这就是为什么我们有学术界的原因。）

如果你真的做出了一些东西，在面对那些令人眼花缭乱的理论知识，或是和你相似甚至比你做的更糟糕的人时大可不必谦虚。在一天结束之时，正是那些在战壕中的开发者——构建、测试和开发了代码的人，真正做了事情。话说那些发现自己远离战壕的人，那些没有和你一起并肩作战的逃兵，你有权利鄙视他们。并且向你的伙伴致敬，而不是上司。

原文标题：做好这7件事 让你学编程写软件不在难

原文链接：http://www.epx365.cn/peixun/software/201840267.html

理论上狠简单，直接建立个TXT文件，然后，直接写汇编或者机器码的代码了，写完后，然后更改文件的后缀成EXE或者DAT了。你的代码正确就能直接跑了。问题是现在编程的有多少人还能那么流利的懂底层代码的编写吖。

---