C#-[分割中英文字串]

超簡單只要一行程式碼

string[] eachChar = content.Select (x => x.ToString ()).ToArray ();

好文分享~ 循序渐进地代码重构

原文連結:  http://ronjeffries.com/xprog/articles/refactoring-not-on-the-backlog/?utm_source=wanqu.co&utm_campaign=Wanqu+Daily&utm_medium=website

原文連結(翻譯) :
https://www.sdk.cn/news/5514

循序渐进地代码重构

业界资讯 来源：SDK.cn 发布：2016-10-21

摘要：对于如何进行代码重构，一直有着很多种说法。很多人都认为应该将重构代码放在backlog里。但是其实，这并不是一个理想的方法。

对于如何进行代码重构，一直有着很多种说法。很多人都认为应该将重构代码放在backlog里。但是其实，这并不是一个理想的方法。

在项目刚刚开始的时候，你的代码很干净。

即使有的时候需要小小的绕一下路，但是这个时候我们可以轻松、平稳的添加功能。这个阶段一般都不会出现问题，而且由于我们比较着急，所以即使出现了一些小问题，我们也不会注意到。

然而，随着项目做的时间变长，这些小的问题就会累计起来。这就是人们所说的“技术债务”。其本质，就是并不算特别好的代码，但是这个时候其问题还没有完全显现出来。

但是，随着我们一直添加新功能，这些问题就会逐渐显现出来，我们不得不小心翼翼的绕开他们。

不可避免的，我们的开发速度会被拖慢。但是为了追求速度，我们开始变得越来越不小心，不久之后，问题也会越来越多。

这些问题会像积木一样累计起来，层层叠叠，让我们的开发速度变得更慢。虽然我们终于意识到了问题的存在，但是没有时间彻底解决它。我们只能继续小心翼翼的绕开它们。

很快，我们会发现半数以上的代码都与那些小问题有交集，它们无时无刻不在影响我们的开发速度。直到有一天，你发现自己没法继续绕开它们。

不得不做点事情了。我们必须要进行复杂的代码重构，让我们重新获得干净的代码。你不得不向上级申请时间进行代码重构。其实这种工作方式并不好，我们花时间去填自己以前挖的坑。而且有的时候，公司并没有让你去重构代码的时间。

即使公司给你时间了，你也很难很好的对代码进行重构。要知道，重构代码所需的时间，往往要远高于你的预期。如果这些纷乱的代码是你用了10周写出来的，那么你很难再用10周的时间对它们进行重构。

由此可见，这种代码重构的方式并不好。那么我们应该怎么做呢？

很简单，那就是每遇到一个问题，就马上解决它，而不是选择绕过它。完善当前正在使用的代码，那些还没有遇到的问题，就先不要理它。在当前前进的道路上，清除所有障碍，以后你肯定还会再一次走这条路，下次来到这里的时候你会发现路上不再有障碍。软件开发就是这样。

或许解决这个问题需要你多花一点时间。但是从长远来看，它会帮你节省下更多的时间。

在添加新功能的时候，我们就先清理这个功能所需要的代码。花一点时间，用滴水穿石的方法逐渐清理代码，随着时间的推移，我们的代码就会越来越干净，开发速度也会越来越快。

一段时间之后，你会发现之前所有的技术债务都不见了，所有的坑都被填平了。这种循序渐进的代码重构的好处开始显现，编程的速度明显加快

这才是代码重构的正确打开方式！

好文分享~ 陈皓：什么是工程师文化？

原文連結: http://coolshell.cn/articles/17497.html

四年前，我在QCon上演讲了一个《建一支强大的小团队》（整理后的PPT分享于这里）提到了工程师文化，今天，我想在这里再写一篇关于工程师文化的文章，一方面是因为我又有了一些想法和体会，另一方面，因为我也正走在创业的道路，毫无疑问，要建一个有浓重的工程师文化的团队或公司，所以有必要把自己的相关想法形有成白底黑字的“字据”，以供打自己的脸——“要是未来没有做到，这篇文章就打我未来的脸” || “这篇文章太幼稚了，未来的我会打我现在的脸”，当然，如果要打脸，我希望是前者。

Again，这篇文章不是招人的贴子，因为我觉得，招聘第一重要的事，不是发招聘广告或是找猎头挖人，而是先得让自己变成一个能配得上真正工程师的公司，然后再谈吸引人的事。

为什么要工程师文化

看看最近二十年来社会的发展，计算机和互联网已经渗透到了这个社会的每一个角落，各式各样的计算机技术成为了整个世界发展的强大引擎，各式各样的创新，无论是业务创新还是技术创新，都是依托于技术的快速演进，技术成了解放生产力提高社会运作的效率的中坚力量。以美帝为首的技术创新公司着着实实的改变着这个世界和人类的生活和生产习惯。

今天，每个从事计算机行业的技术人员都应该感到幸运，因为，我们不但选对了行业，也出生在了正确的时代，可以感受到前所未有的刺激和变化，相比起我们的父辈，我们的人生，能经历这样的时代，实在是一种幸运。所以，选对了职业并出生在了正确的年代的我们，此时只需要思考的一个问题，那就是，我是否呆在了正确的地方用正确的方式做事？

在我看来，这个世界上有三种商业公司，

• 运营或销售驱动型的公司。这类的公司以运营和营销见长，技术对于他们来说，更多的只是为了支持大规模的营销活动，以及成本上的控制，所以，基本上来说不太需要技术创新。这种公司最大的问题就是缺乏安全感。

• 产品驱动型的公司。这类公司以产品见长，通过创造能提升用户生活体验的产品见长，技术对于他们来说，除了支持大规模的在线用户之外，他们会更多的去寻找那些为了增强用户体验，提高整个业务流程效率的技术创新。比如：UI的交互方面的，整个业务流程方面的。这种公司最大的问题，就是容易被别人模仿和抄袭。

• 技术驱动型的公司。这类的公司相信技术能改变世界，他们更多的是用强大的工程技术来创造有颠覆性的东西，更多的是用各种自动化的技术取代人类。比如：近代的蒸汽机技术取代了大量的人工，数字技术取代了大量信息传递的人工，现代，这类公司还希望通过人工智能来取代愚蠢的人类来做决定。这种公司最大的问题就是可能做出叫好不叫座的东西。

这三种公司都可能成功，也都有问题，但是，无一例外，他们都需要强大的技术支撑，只不过，他们把技术所放在的位置不一样。

无论你有多么的看不起技术人员，你都无法否认，你今天的生活相当的依赖这帮工程师，没有他们，你恐怕都不知道怎么生活了。邓爷爷几十年前就说过——“科学技术是第一生产力” ，无论什么样的科学技术的理论要落地都会依赖于工程技术有多先进。

所以，在今天，作为一个IT或互联网公司，“工程师文化”不是一个问题，而是一个常识！

工程师文化的特征

我下面罗列的这些特征，来源于：Google的《重新定义公司》，我在Amazon的工作经历，37Signals的《Rework》，Quora上的 What Makes Good Engineering Culture?  Slideshare上的 What Makes Good Engineering Culture，以及我最近这半年来的一些实践。

简单说来，我可以简单的把这多的工程师文化的总结成两大类：“自由” 和 “效率”。

本来还应该有个“创新”，但我个人认为，创新的前提是——在自由的环境下对提高效率的痴迷，就一定会发生创新。

创新不是凭空出现新的东西，其实，观察一下人类的发展史，不难发现，几乎所有的创新基本上跳出原来的思维模式用新的思维模式对原有问题的效率进行质的提升。比如：通信、交通、医疗、教育、生活……几乎全都是在优化效率。

所以，如果你的精神不自由，你很难跳出老的思维模式，你用老的思维模式你一定不会想到新的方法和方式，如果不是对效率的提升，这个创新可能会不接地气。

因此，我认为，工程师文化就是自由加效率！

自由

首先，工程师文化意味的创新文化，工程师都是有创新冲动的人，因为手里有创造技能的人通常都会有想创造点什么的冲动。而创新的源泉水来源于精神的解放，精神自由才会引发各式各样的奇思怪想，才会有常人觉得不可能的疯狂想法和想像力，而这些想法和想像力导致了创新。

精神上的自由具体表现在：

• 自我驱动。自己管理自己是最好的管理。最失败的管理就是家长和保姆式的管理。兴趣出发的工作才可能迸发出真正的动力。

• 灵活的工作时间和地点。工程师们更多的是脑力工作，而不是体力工作，工作上时间和地点的自由安排可以让工程师们的脑力工作更有效。Remote是一个很不错的工作方式，开源社区基本上都是这钟方式。和Remote有关的话题可参看37Signals的这本书《Remote》

• 信息平等。这意味着，全体员工得到的是原始信息，而不是被管理者们层层加工消化后的信息，信息的屏蔽很容易造成误解和完全错误的行为。信息的平等，大的包括战略、方向、目标、财务，小的包括文档、代码、和知识的共享等。同样，也表现在意见表达上，任何人都有可能表达自己的意见和建议的平等机会，这样才会激发出更多的思路和思辩，从而有不同的更好的思路出现。而不是，大家都看到了问题，而没有人敢说。在Google除了代码全员共享，还有Thanks God, It’s Friday的文化，每周五，高管们会出来，任员工提各种尖锐的问题，在Amazon，代码和文档基本上全员开放，包括财务报表也对员工开放，另外，除了所有的NB的Principle SDE隔三岔五都会有一个Principle Talk（有很多Talk相当令人开脑洞），还有Amazon内部的Up the River文化，每年会选出一批公司最聪明最有想法的人集思会，讨公司下一步的和战略，并可以把相应的KPI直接按给Senior VP。

• 不害怕错误。处理错误的正确的姿势是分析总结教训，而不是惩罚故障人。前者让人改善进步，后者让人萎缩不前。最大的错误就是不敢犯错，最大的问题就是不敢直面问题。

• 宽松的审批系统甚至没有审批系统。审批通常暗示着三件事，1）对人的不完全信任，2）繁琐的流程，3）思维上的束缚。这些都是创新和想像力的天敌。一个公司的监管、审批、流程越重，这个公司的活力也就越差。

• 20%的自由时间。这是Google公司提出来的，员工有20%自由的时间做自己想做的项目，Gmail就是这么出来的。

效率

工程师天生是追求效率的。有人说认为程序员花大量的时间做自动化的工具，还不如人肉的效率高，比如，写自动化的脚本花5个小时，而重复做这件事200次只花3个小时。有这样的理解的人根本不懂工程。

一方面，这个工具可以共享重用，更多的人可以从中受益，这次我花5个小时开发这个工具，下次只用1小时改一下就可以用在别的地方，这是着眼于未来而不是眼下的成本。更重要的是，这是一种文化，一种提高效率的文化，他会鼓励和激发出更多的这样的事情发生。如果你因为一个程序员花大量的时间开发自动化的工具，而认为这个程序员没有效率，对之批评甚至惩罚的话，那么你就扼杀了提高效率的文化（关于效率，大家可以看看我的另一篇文章《关于加班和效率》，你会真正了解什么是效率）

人类之所以比别的动物聪明就是会使用和发明工具，而古语也有云：“工欲善其事，必先利其器”，看看美军的装备你就知道战争工具的好坏有多重要了，一个公司的强大之处在执行力，而执行力的强大之处在于你有什么样的支持工具。这些，已经不是工程师文化，而是人类发展的文化。

针对于工程师文化来说，尤其是软件工程，提升工程效率的具体表现如下：

• 简化。简化不是简陋，简单的东西通常意味着用户更好理解，也意味着更容易的维护和运维。就像阿里推行的“小而美”，就像乔布期推崇的“没有产品手册简单易用的产品”，就像Amazon推行的Working Backwards里说的那样，一个新的产品或功能，产品经理需要写三个文档：媒体公关文、用户手册、常见问题，三个文档总共加起来不超过两页A4纸，且不准用任何图片说明，目的就是为了让产品简化和容易使用。

• 残酷无情的推行自动化。编写程序的最本质的目的就是自动化，看看人类发展史上自动化了多少东西。对于自动化来说，不仅仅只是消除人肉的重复劳动，更重要的是，很多事情人完全干不过机器。比如：加一台机器，程序在秒级就可以完成，而人是永远不可能达到这样的速度的，再比如：电商中用程序管理数量巨大的订单的自动化系统，加再多的人都完成的不可能像机器那样完成的又好又快。自动化需要大力开发提高生产力的工具，比如：持续集成，持续部署，自动化运维，基础自动化运维，甚至自动化的运营工具。（Amazon的软件工程中对自动化和简代相当迷恋）

• 避免无效率的组织架构和无效率的管理。这体现在这些方面：1）扁平化的组织架构，2）努力用自动化工具取代支持型的工作，3）不超过10个人的全栈小团队，4）不按人员的技能分工而是按其负责的产品或功能分工（关于分工，请参看《让我们来谈谈分工》），5）开会不是解决问题，开会是表决提案，6）通过产品的目标或信条Tenets来减少沟通和决策过程（Amazon里的每个部门，每个团队，每个产品都有自己的Tenets，这个Tenets标明了要什么不要什么，这样可以避免很多扯皮和难缠的trade-off的决择，比如：AWS的几个信条：运维是最高优级的——这意味着只要是会让运维变得复杂的需求都可能会工程团队被拒掉，Throughput & Latency不能更差——这意味着，功能要为性能让路，因为性能变差了，用户就要买更多的资源）

• 正确的组件抽象。抽象是简化的一部份，一方面，抽象意味着重用和通用，另一方面抽象意味着强大的扩展性，以适配各种可能性。最重要的是，抽象意味着技术能力的输出，无论是内部的其它团队还外部的团队。比如：Google的MapReduce/BigTable/ProtoBuffer，FaceBook的Thrift，还有Amazon内部的WebService框架Coral Service、处理日志监控的Timber，以及全线AWS产品都用到的Amazon Lock Framework（一个分布式锁框架）……

• 开发高质量的产品。因为高质量的代码，不但可以容易的修改和维护，还可以因为少处理线上故障，从而有更多的时间去为未来做更多创造性的工作。这意味着需要有非常严谨的Design Review，Code Review，以及测试，关于Code Review，可以参看这篇文章《从Code Review 谈如何做技术》，关于严谨的测试，可以参看这篇文章《如何做性能测试》

• 不断的提高标准以及招聘最好的人。取法其上，得乎其中，取法其中，得乎其下，取法其下，法不得也。如果一个公司或一个团队想变得越来越好，越来越强大的话，就必需要不断的提高自己的工作标准，提高工作标准意味着要不断地培养和招聘更好的人。在Amazon和Google的招聘官中都有一个叫Bar Rasier的人，这个人就是为了提高招聘标准而设立的。

• 创建一个持续改善的文化。一个好的组织，一个好的团队，是需要不断反思前进的，这需要全体员工一起来的。微观层面上，在项目做完后需要有一个总结会分析项目中的得失，在故障出现后，需要有故障分析会，反思得失，在Amazon，严重的故障，需要写一个COE（Correction of Errors）的文档，其中有一节叫“Ask 5 Whys”，让你自己问自己至少5个为什么。在宏观层面，一个公司每年都应该做一定的工作数据分析或是员工调查，比如，是否招聘到了不错的人、工作的投入产出比，员工在哪些地方花时间了，等等，然后不断的用技术手段来改善。（Amazon每年的工程师员工调查表是我活那么大见过的最细最细的调查表了， 问题除了对公司、经理、文化的，还有从，日常工作、开发环境、持结集成，测试自动化、产品质量、软件架构、软件维护、线上问题处理、年度计划、数据仓库建设、通用工具投票……这个员工调查直接导致公司的对工程的投资方向）

工程师文化如何落地

如果你要让任何文化在公司内得到执行，你有下面几个手段可以选择：

• 通过政治手段：你需要把住三个地方——招聘、绩效考核 & 升职。比如，你要落地工程师文化中的简化和自动化，那你你在招聘的时候，你需要把懂简化和喜欢自动化的人招进来，然后在绩效考核和升职的地方设置上一条硬性指标——你今年简化了什么？自动化了什么？如果没有，对不起不但不能升职，绩效可能还不达标。

• 通过经济手段：让不做这事的成本 > 要做这个的成本。然后，正常的人类都会选择成本低的方案。比如，如果你要推行Design/Code Review/UT以提高质量，你就把QA和OPS团队全挪到一边去，让Dev团队自己测试，自己负责，这样等这些Dev重复多次手动测试，处理多次线上的弱智故障，他们就会自然而然的写自动化测试和做Code Review了，而QA和OPS团队只是帮Dev你做工具罢了，而测试和运维的事全是你DEV的Ownership，出了故障也是Dev自己负责，于是，他们就会发现，不做Code Review和UT的成本远远大于做C Code Review/UT的成本，他们就会去做成本低的事的。

最后，工程师文化要落地，还有几个小条件，

• 第一，团队要小，Ownership很重要，Eat Your Own Dog Food。 没有人帮你擦屁股，自己的屎自己吃，没有痛苦，不会产生想进步的动力。

• 第二，热爱学习和尝试，学习尝试新的技术，开拓眼界，学习尝试新的思维方式，否则，呆在原地，原有的思维方式只会让你在原地打转转。

• 第三，老板更多的相信技术而不是管理。相信技术会用技术来解决问题，相信管理，那就只会有制度、流程和价值观来解决问题。

其它

说了这么多，时代还在发展，不过，这是我这么多年经历或看到的工程师文化的东西了。最后吐几个槽——

对于996和加班这个事，对于工程师来说从来都不是问题，在解决技术问题或是创造的时候，工程师是个很自觉的群体，基本不需要有别人驱动，工程师是最乐意Work Hard的人了。我相信几乎所有走上编程这个职业的人来说，基本上都是兴趣所至，觉得编程很有趣，但却被各个公司996搞得对编程毫无兴趣。为什么，你们这些公司要向中国的教育学习呢？人家本来对这事有比较高的兴趣的，但就是要通过考试/KPI/996这些东西把人家的兴趣一点一点的磨灭掉，把人变成机器、奴隶、牲口，让人对学习和工作产生了厌倦和讨厌，会是你们这些管理者们所希望的？是不是只有把人变得不思进取了，你们才会管理？就像《软件开发中的两种管理方式》中说的第一种人一样？

另外，我不知道，为什么我一说这些东西，就会有很多人（包括程序员自己）来和我说我是个理想主义者，这些已经不是什么理想了，已被很多成功的公司用了很多很多年了。只是你没有见到过罢了。还有的人说，因为中国的国情不同。这更让我费解了。这让我想到了当年大清朝派了一堆人出国考察后回来后，说外国的那套共和的东西不符合中国国情，最终也在历史的潮流中被淹没掉了。另外，什么叫“中国的国情不同”？中国有全世界数一数二的互联网用户，也有全世界数一数二的市场，不再是以前那个一穷二白的年代了，中国的国情到底有哪些不同呢？

我不知道各位工程师是为什么活的？但我觉得，我们选择了一个刺激的职业，也赶上了这个行业大发展的时代，我们不妨扪心自问一下，你是否愿意让自己的能力、青春和热情就这样被磨灭了？

（全文完）

Visual Studio - 註解快捷鍵

可以選取很多行 一次性寫註解

註解: Ctrl + K , Ctrl + C
反註解 Ctrl + K , Ctrl + V

Visual Studio - 查看Tab , Space

顯是空白: Ctrl+R, Ctrl+W

結果出現下面藍藍小箭頭

自動排版: Ctrl+K, Ctrl+D

C# Coding Standards ( Coding 標準 )

參考 MSDN 的coding style 以下是整理最 基礎 , 常使用 的部分

基礎規則：

• 使用大駱駝 Pascal( 如 : "VirtualDesign" )及小駱駝Camel( 如 : "virtualDesign" )
• 不要使用分隔符號( 例如底線 "_" 或連字號 "-" )來做命名 ( EX: (X) User_Name_Api_Path )
• 可讀性優先於簡潔性( CanScrollHorizontally 優於 ScrollableX )，並參考常用的命名( HorizontalAlignment 優於 AlignmentHorizontal )。
• 避免使用匈牙利命名法( 如 : "strName", )
• 不要使用型態前致詞( ex: (x)strName ,)
• Bool 例外 "Can" , Is 或 "Has"( EX: (O)bool isPlay )
• 使用後致詞
• System.EventArgs :  AppleEventArgs    
• System.Exception :  WtfException
• System.Attribute : LoginAttribute
• Instance (Field): CubeInstance
• 正確的使用縮寫 (沒事不要用縮寫)
• 兩字皆為大寫( 如 : "IO" , "DB" , system.IO  )
• 三個字以上 ( 如 : "Xml" )

物件命名規則:

• Interface : 前面+I ( EX: Car : ICar )
• Generic (泛型) : 前面+T , K ( EX:  class List <TKey , TValue > )
• Field :
• public : 大寫開頭 ( EX : public string UserName )大駱駝
• private :  ( EX: private string _userName )_小駱駝
• private Const -> WTFUSER ;
• Local Variable : 小寫開頭 ( EX: string userName )小駱駝
• Const (static readonly) Variable 全大寫_ (EX: WTF_PATH = “@C:\” )
• Parameter : 小寫開頭 ( EX: userName )
• var 不可以寫在成員 public private

工廠模式&策略模式 差別

工廠模式-> 創建物件 ->

車工廠 -> 跑車 , 國產車

通過車工廠可以直接拿取跑車

呼叫者不需研究跑車如何組裝 , 國產車如何組裝

優點: 新增老爺車時 實例化只需關注介面( 剎車 起跑 換檔 ..)

調用車子 ->不須關心車子如何組裝 如何實體化

缺點: 更改介面時 所有車子都要改

策略模式-> 封裝方法 ->

皮卡丘.上() 皮卡丘.下() 皮卡丘.左() 皮卡丘.右()

小火龍.上() 小火龍.下() 小火龍.左() 小火龍.右()

到真心鎮的策略->可能是 上右右上右下 -> 也可能是 上下下右右右上

優點:抽換策略 , 只關心策略演算