我正在参加「掘金·启航计划」
简介
一个程序员它的实力不仅仅是来自自身的技术水平。
好的程序员 必然拥有着一些非技术能力 ，我们将其称为软技术。
人生是你自己的 希望大家在阅读完这篇文章后都能有所收获！
作者作为一名学生，所以一些观点仅仅是从学生角度 出发 看待事物缺乏包容性 望包涵！
正文
务实的哲学
首先，你要明白 你的事业是你自己的，更重要的 你的人生 是你自己的。 所以 不要放弃提高自己 ，不要放弃阅读、不要放弃学习。
就像本文作者我一样，我也已经45天没有再继续写文章，30天的时间没有去敲过代码了，在过去的一个月 我把我的时间用在软考中，but 鬼知道为什么今年的题目这么♂！
但是 我还是要说 不要放弃学习 就算你跌倒了（深有体会） 但是你一定一定要爬起来 （晚一点开始没关系，不要放弃）！
?人生是你自己的
我活着不是满足你的期望，也正如你不是因为我的期望而活着——李小龙
在书中，作者同很多沮丧的开发者进行过交谈，有的开发者在抱怨工作环境、有的开发者在吐槽自己技术的过时，有人觉得自己没有得到应有的重视。
对此、我们总是给出相同的答案——
“为什么不尝试着去改变呢？”
软件开发在任何职业列表中 都会是你最容易掌握的职业之一，我们的技能供不应求，我们的知识不限于地域，我们可以远程工作 我们 无所不能。
?我的源码被猫吃了
在所有的弱点中，最大的弱点就是害怕出现弱点——J.B.Bossuet
在你的职业发展、学习教育 以及你的项目、每天的工作等各方面对你自己负责，对你的行为负责，这是务实哲学的基石之一。一个务实的程序员能完全掌握自己的职业生涯，从不害怕承认无知和错误。有些事会令人不快，但却必然会发生。
知识是永无止境的，保持谦逊 ，承认自身的无知。
信任你的团队（不仅仅局限在工作中）
承担你应该承担的责任（不要把问题归咎在其他人身上，不要寻找借口 ）
?软件的熵
不要放任破窗
不要搁置“破窗” （糟糕的设计、错误的决定 低劣的代码）不去修理。每发现一个就赶紧去修 如果你没有足够的时间修好 那么就将其钉起来。
你或许会觉得，没人有时间来来回回清理项目中的所有碎玻璃，如果你真的这么想，劝你还是今早的多想想如何料理这个项目的后事，或者直接离开是非之地，而不要让熵赢得最后的胜利。
?够好即可的软件
为了追求更好，我们损毁了原已经够好的——莎士比亚《李尔王》
现实世界不会让我们生产出太多真正完美的产品，尤其是没有bug的软件。时间、技术、急躁合力对抗着我们。
然而 莫要沮丧 如《IEEE 软件》 杂志上一篇由爱德华.尤登写的文章《够好即可的软件就是最好的》：
你能训练自己写出够好即可的软件——对用户、未来的维护者来说够好即可，只要的好的成度能够让你内心平静即可，你会发现 你变得更加的有效率，用户也更加快乐。 而且，可能让你更开心的是，更短的孵化期促使你的程序实际上更好了。
?让用户参与权衡
让更多的测试者、用户 参与进来。 因为 一个产品的好的程度 往往客户更加清楚！
而在某些方面，编程就像绘画，你从一张空白的画布开始，只有一些非常基础的原料，你柔和了科学、艺术、工艺手段 来决定这些原料用来做些什么。你勾勒出一个整体的形状，绘制出潜在的基调 然后在装点细节，你不断的带着批判的眼光来回顾自己已经完成的部分。你会时不时扔掉一些画布，然后重新开始。
不过艺术家会告诉你，如果你不知道什么时候该停止，那么所有的努力都将白费。如果你不断的一层叠一层，细节盖细节，绘画将迷失在颜料里。
不要让过度的修饰和精炼侵蚀掉一个完美的程序。继续前行，让代码在它该有的位置驻留一段时间。它或许并不完美，不要紧的——它就算永不完美也没关系。
?知识组合
投资知识、收益最佳——本杰明.富兰克林
- 正规投资者有定期投资的习惯
- 多样化是成功的关键
- 聪明的投资者会平衡保守型和高风险高回报投资的组合
- 投资者用低买高卖来收获最大的回报
由上可知：
定期投资—— 我们就可以理解成 每个月读一本书?
多样化—— 增加自己的知识广度
低买高卖—— 在一项新兴技术开始变得流行前就开始学习，可能和发现一只被低估的股票一样困难，但是所得到的收获会和此类股票的收益一样好。在Java刚发明的时候就去学习 可能会有很大的风险，不过当Java流行后，那些早期用户都获得了相当丰厚的回报。
务实的方法
?优秀设计的精髓
优秀的设计比糟糕的设计更加的容易变更
能适用使用者的就是好的设计，对于代码而言 就是要顺应变化。因此要信奉ETC原则（Easier To Change）——就该如此。
据我们所知，无论什么设计原则，都是ETC的一个特例。
为什么解耦很好？因为通过隔离关注焦点，可让每一部分都容易变更——此为ETC。
为什么单一职责原则很有用？ 因为一个需求变化仅体现在某一单一模块上的一个对应变化——此为ETC。
为什么命名很重要？因为好的命名可以使代码更容易阅读，而你需要通过阅读来变更代码——此为ETC。
ETC是一种价值观念，不是一条规则。
?DRY——邪恶的重复
詹姆斯.T.柯克船长在对抗人工智能掠夺者时，最喜欢用的方法就是给电脑两条自相矛盾的知识。不幸的是，这一原则用来击溃你的代码同样有效。
作为程序员 我们能做的就是收集、组织、维护以及治理知识 我们把知识文档化 写进规范 通过运行代码赋予知识的活力，在测试过程中 运用知识去知道应提供哪一些的检查
不幸的是，知识并不稳定。知识会改变 而且频率会很高。我们只需要记住一个原则 —— 不要重复自己！
?正交性
如果想构造出易于设计、构造、测试和扩展的系统，正交性是一个至关重要的概念。
在计算机科学中，这个术语象征着独立性或解耦性。对于两个或多个事物，其中一个的改变不影响其他任何一个，则这些事物是正交的。在良好设计的系统中，数据库相关的代码应该和用户界面保持正交；你可以改变界面 但是不应影响数据库，切换数据库 而不必更换界面。
?提示：消除不相关事物之间的影响
我们希望设计的组件自成一体；独立自主 有着单一的清晰定义的存在 当组件彼此隔离 你知道变更其中一个组件而不必担心影响 到其他组件。
?原型和便签
许多不同的行业都使用原型来尝试特定的想法，原型制作比完整的产品制作要便宜得多。例如汽车制造商可能会为了一款新车的设计制造许多不同的原型。每个原型都是为了测试一个特定方面——空气动力学、造型、结构特征等等。
原型设计是为了学习经验。它的价值不在于产生代码。而在于吸取的教训。这正是原型的意义所在！
不要把原型用于产品！
在开始任何基于代码的原型开发之前，请确保每个人理解 正在编写的是一次性代码。原型可能有着欺骗性的外表，对那些 不知道这只是原型的人产生吸引力。你必须非常清楚 表面 该代码 是用完即弃的，它并不完整也不可能做到完整。
基础工具
?纯文本的威力
作为务实的程序员，我们的基础材料不是木头或铁块，而是知识。
我们把需求以知识的形式收集起来 然后在设计、实现、测试 和文档 中表达这些知识！我们相信纯文本是将知识持久地存储下来的最佳格式。
?Shell 游戏
每个木工都有一个优秀、坚固的工作台 对于程序员来说 在操作文本文件的时候 指令shell 就是 工作台 。
你可以在shell里启动应用程序、调试器、浏览器 编辑器和工具 可以搜索文件、查询系统状态，并将结果过滤后输出。此外你可以通过shell编程构建出发杂宏指令，来处理经常要干的事情。
对于在图形界面 和 集成开发环境(IDE) 中长大的程序员来说，这样干显得有点极端，毕竟通过点击一样能做好一件事情不是吗？
答案很简单——不能。 图形界面非常棒 对于一些简单的操作来说 干起来可以更快更加的简单。但是如果使用图形界面去完成所有的工作就会错失环境的全部能力。
提示?：发挥shell的威力
试着投入一些时间、精力 去学习一下shell 并利用shell 去完成一些工作！
?版本控制
进步，远非寓于改变之中，而是依赖于保持。那些不能铭记过去的人，注定要重蹈覆辙。——乔治.桑塔亚那
在用户界面中，我们最期待的一个东西就是undo键——一个可以原谅我们犯下错误的按钮。如果环境支持多级撤销和重做就更好了，这样就可以从几分钟前发生的错误中恢复过来。
但如果这个错误发生在上周呢？？？
提示?：永远使用版本控制 即使你只有一个人且项目一周就结束。
分支出去
版本控制不只是保存着一份项目的单一历史，它最强大和有用的特性之一，有办法让你可以把开发过程中的一个个孤岛隔离到称为分支的东西中。你能在项目历史中的任何一个时间点创建分支 然后你在这个分支上所作的任何操作 都已和其他分支隔开。在未来的某个时间 你可以将手头上的分支合并回另一个分支，这样分支就包含了你在分叉出去的分支上所作的修改。甚至多个人可以在同一个分支上工作。
?调试
看着自己的麻烦，清楚地知道，是你，就是你自己，而非他人所致。这真是件痛苦的事情——索福克勒斯《埃阿斯》
调试心理学
对于许多开发人员来说，调试是一个敏感的、情绪化的主题。你可能会遇到拒绝、指责、站不住脚的借口或习惯性的漠视，而不是把它当作一个有待解决的难题来攻克要接受这样一个事实:调试只是在解决问题并为此攻关
有人在发现了别人的 Bug之后，会费时费力地把责任推到罪魁祸首身上。在一些工作场所，这就是文化的一部分，而且或许有助于宣泄。然而，在技术领域，我们宁愿把精力集中在解决问题上，而不是归咎于他人。
调试心态
最容易欺骗的人就是自己。一爱德华·鲍沃尔-利顿，The Disowned
在开始调试之前，正确的心态非常重要。你需要关闭许多平日用来自我保护的防御机制，排除可能面临的任何来自项目的压力，让自己放松下来。首先，请牢记调试的首要法则:
- 不要恐慌 （良好的心态）
- 从哪里开始 （找到错误发生的范围）
- 调试策略 （复制、修改bug）
?文本处理
学习一门文本处理语言 比如 markdown
多使用文本记录 总结！！！
务实的偏执
?你无法写出完美的软件
每个人都觉得，地球上只有自己一个好司机。全世界都在闯红灯、实线变道、不打灯就转弯、开车发短信，总之都不符合我们的标准。所以我们需要防御性驾驶。在麻烦发生之前就做好准备，预料到意料之外的事情，永远不要把自己置于无法自拔的境地。与编程类比，上述理论也明显成立。我们不断地与他人的代码交互，代码可能不符合我们的高标准，或需要处理可能有效也可能无效的输入。所以我们被教导要防御式编程一一有任何疑问，都要去验证我们得到的一切信息;使用断言来检测错误数据，不信任任何可能来自潜在攻击者或有恶意者的数据:做一致性检查，对数据库的列设置约束一一做完这些，我们通常就会自我感觉良好。
?断言式编程
自责中往往有种奢侈。我们自责时，总觉得别人无权再责备我们。一奥斯卡·王尔德《道林·格雷的画像》
似乎每个程序员在职业生涯早期，都一定会记住一句魔咒。我们学着将这句咒语作为计算领域的基本原则，一种基础信念，运用到需求、设计、代码、注释及所做的任何事情中。它念起来像是这样的
这件事绝不会发生·····
“这个应用程序绝不会在国外使用，所以为什么要做国际化?”“count 绝不会为负数”写日志绝不会失败。”
不要再这样自我欺骗下去了，特别是在编程的时候。
使用断言去预防不可能！
?不要冲出前灯范围
做预测很难，关乎未来时尤其困难。——尤吉·贝拉，转述自一句丹麦谚语
夜深了，天很黑，下着倾盆大雨。一辆双座汽车在弯弯曲曲的山间小路上来回急转,几近失控。这时，出现了一个急转弯的提示牌，汽车错过了它，撞向稀疏的护栏，冲入下面的山谷后燃起大火。赶到现场的那些交警里，有个高级警官惋惜地摇着头说:“一定是冲出了前灯。”
超速行驶的双座汽车是不是跑得比光速还快?当然不是，没有什么能超过光速。这名警官提及的是，司机在前灯照射范围内及时停车或控制方向的能力。
前灯有一定的照射范围，被称为投射距离。过了临界点，光的扩散就会太分散，难以维持效果。此外，前灯只在直线上投射，不会照亮任何偏离轴线的东西，比如道路上的急转弯、山丘或斜坡。据美国国家公路交通安全管理局称，近光灯照射的平均距离约为 160英尺。不幸的是，时速 40 英里时的停车距离是 189 英尺，时速 70英里时的停车距离是 464 英尺’。所以事实上，你很容易就会超出前灯范围。
在软件开发中，我们的“前灯”照明同样有限。我们无法看到遥远的未来，离照射轴越远，就越黑暗。
小步前进——有始至终
宁弯不折
生活不会裹足不前，我们写的代码也不会。为了跟上当今近乎疯狂的变化速度，我们需要近一切努力编写尽可能宽松、灵活的代码。否则我们很快就会发现 我们的代码很快过时，或是因为太脆弱而无法在出错后修复，最终都可能在疯狂的冲向未来的过程中被抛在后面。
?解耦
当我们试着单独挑出一个事物的时候，总会发现它与宇宙中一切都存在着关联。——约翰.缪尔《夏日走过山间》
解耦让代码改变更加简单
?继承税
你想要一根香蕉，但是得到的却是一只拿着香蕉的大猩猩，甚至还有整片丛林。——乔.阿姆斯特朗
多用接口 而不是继承
提示?：尽量使用接口来表达多态
?配置
物归其所，事定期限。-本杰明·富兰克林《富兰克林自传》，十三条美德
如果代依教某些值，而这些值在应用程序发布后还有可能改变，那么就把这些值放在想序外部、当应用序于不同的环境中运行，而且面对不同的用户时，将和环境天，用户相关的值做在应用之外，通过这种方式来参数化应用程序，让代码适应其行的环境。
不要写出渡渡鸟般的代码
如果没有外部配置，代码的适应性和灵活性就会大打折扣。这是一件坏事吗? 在现世界中，不适应环境的物种会死亡。
毛里求斯岛上的渡渡鸟因为不适应岛上出现的人类和家畜，很快就灭绝了。这是被记录的首个因人类活动而灭绝的动物物种。
不要让你的项目(或事业) 走上渡渡鸟的老路。
并发
为了大家达成几个共识 先说明几个定义：
并发性指的是两个或更多个代码段在执行过程中表现得像是在同时运行一样。并行性是指它们的确是在同一时刻一起运行。
想获得并发性，需要在一个特殊的环境下运行代码。当代码运行时，这个环境可以在其不同部分之间切换执行过程。这样的环境通常基于纤程、线程、进程来实现。
想获得并行性，则需要有可以同时做两件事情的硬件，通常是同一 CPU 上的多个被心、同一机器上的多个 CPU，或是连接在一起的多台计算机。
一切都会并发
在一个规模适度的系统中编写代码，完全不涉及并发方面的事情，几乎是不可能的并发可能是外显的，也可能埋藏在库内部。如果希望你的应用程序能够在由异步构的现实世界中打拼，那么并发性是一个必要条件:用户在交瓦中，数据在获取中，部服务在调用中，所有这些都是同时进行的。如果强迫这个过程串行一一一件事发后才能进行下一件事，以此类推，则系统的反应会变得迟钝，运行代码的硬件也可难以充分发挥自己的能力。
当你编码时
?听从蜥蜴脑
只有人类才能睁眼说瞎话，即使已经有了能做出准确预测所需的全部信息，甚至已经瞬间做出了准确的预测，却还是说不是那样的。一加文·德·贝克尔《恐惧给你的礼物》
- 倾听你的直觉
- 倾听你的内心
- 不仅仅是你的代码 （拿来别人的用）
- 不仅仅是代码 （生活中等更加宽阔的领域）
?巧合式编程
你看过以前的黑白战争片吗? 疲惫的士兵小心翼翼地走出灌木丛。前面有一块空地:那里有地雷吗?能安全通过吗?没有任何迹象表明这是雷区一一没有标记牌，没有铁丝网，也没有弹坑。士兵战战兢兢地用刺刀戳着前方的地面，以为会爆炸，然而并没有。于是他费力地向前走了一阵子，边走边戳。最后，他确信这片土地是安全的，于是便挺起腰板，昂首阔步，不料却被炸成了碎片。
士兵最初的探雷行动没有发现任何东西，但这只和运气有关。他得出了一个错误的结论一一结果是灾难性的。
作为开发者，我们也在雷区工作。每天都有数百个陷阱等着我们掉进去。记住那个士兵的故事，下结论时要保持警惕，以免出错。我们应该避免通过巧合编程，因为靠运气和意外来获得成功是行不通的，编程应该深思熟虑。
?测试
- 单元测试 （每写一个就写一个测试）
- 集成测试
- 系统测试 （全体测试）
- 临时测试（调试器交互 console.log() ? ）
- 基于特性测试 等等
项目启动之前
在项目的最早期，你和团队需要了解需求。仅仅是被人告知要做什么或是倾听用户是不够的:读一下需求之坑，学习如何避免常见的陷阱。
处理无法解决的难题介绍的是传统智慧和约束管理。无论是在需求采集、分析、编码环节，还是在测试环节，都会出现一些困难的问题。大多数时候，它们不会真如最初看起来那么难。
当那个不可能完成的项目出现时，我们就会求助于秘密武器:携手共建。我们所说的齐心协力”，并不是指共享大量的需求文档、发送大量抄送的邮件或无休止地开会，而是指在编码时一起解决问题。我们会告诉你需要谁以及如何开始。
尽管《敏捷宣言》开篇就说“个体与互动高于流程与工具”，但几乎所有的“敏捷”项目都始于对将使用哪些流程和工具的吐槽。但是，无论“敏捷”经过了怎样的深思熟虑，包含了多少“最佳实践”，都没有可以取代思考的方法。你不需要任何特定的过程或工具，真正需要的是敏捷的本质。这些关键的问题如能在项目启动之前解决，就可以更好地避免“分析痪”，从而真正开始(并完成)一个成功的项目。
?不要跳出框框思考
找到你要解决的问题的框框
?跳出自身的局限
有时你会发现自己正在解决的问题比想象的要困难得多。也许会感觉到自己走错了路一定有比这更容易的方法!也许你已经在原计划上延误很久，或者已感到绝望，觉得系统不可能再正常工作，因为解决这个特殊的问题是“无法做到的”。
这是暂时做点别的事情的理想时间。做点不同的事情，比如遛遛狗;先让自己放空-下，晚一点再继续。
主管意识的那部分大脑认识到了这个问题，但你的这个意识脑真的有些愚蠢(无意冒犯)。所以是时候给你真正的大脑，那个潜藏在你意识之下的神奇的联想神经网络，腾出一些空间了。你会惊讶地发现，当故意分散注意力的时候，答案总是会突然出现在你的脑海里。
可能你觉得这太神秘主义了，其实不是。《今日心理学》’杂志这样报道:
简单地说，注意力分散的人在解决复杂问题时比有意识的人做得更好。
如果你就是不愿意让这个问题搁置一段时间，那么最好的办法就是找个人去解释一下这个问题。通常情况下，围绕它的简单谈论就可以让你分心，从而得到启迪。
让他们问你一些问题，比如:
。为什么你在解决这个问题?
。解决这个问题有什么收益?
。你遇到的问题是否与边界情况有关?你能消除这些边界情况吗?
?幸运眷顾有准备的人
永远不要懈怠、不要放松！！！
务实的项目
一个好的项目肯定离不开一个好的团队
- 管理并且领导好团队
- 融入团队氛围
