很多公司或者初创企业压根就没有测试代码，即使有，数量也很少。
为了让产品尽快上市，或者为了生存，很多初创公司忽略了早期的测试。
即使是那些看起来挺不错、赞助过开发者大会或开源项目的公司，它们的一些项目也都是只包含少量测试的大单体。
没有一家公司的技术栈是完美的。
每一家公司都有自己的问题，都逃不过技术债务，关键在于他们做了哪些事情来解决这些问题。
如果你在某些问题上缺乏实际经验，但又固执己见，这样就显得有点傲慢了。
我给人的印象是一个无所不知的人，并坚持一定要写测试代码，但我在这方面其实也没有大量的经验可言。
坚持原则固然重要，但也要试着开放心态，并真正从别人的经验和角度来看待问题。
很多大会演讲只涉及概念验证，并不是真实的案例。
如果你在某某技术大会上看到某一项很特别的技术，那并不意味着他们公司一定会在日常开发中使用这项技术。
通常，演讲者所使用的演示 App 并非真实的案例，所以要注意区分它们。
处理遗留代码是很正常的事情。
通常，人们会理所当然地认为别人的公司不需要处理遗留代码。
但在技术大会上与那些大公司的人交流过之后，我发现，他们和我们的处境是一样的。
有遗留代码是很正常的，相比从头开发 App，学会如何处理好遗留代码将会让你学到更多的东西，因为你会接触到更多你之前没有接触过的概念。
做到足够好就可以了。代码质量“好”到一定程度，它给我们带来的收益是递减的。
代码不需要完美，只要维护起来不像是一场灾难就可以了。
通常情况下，有点啰嗦的代码读起来反而更容易理解。
而且，“好代码”与“它看起来就像是我写出来的代码”是两码事。
看清整体架构比对细节吹毛求疵更重要。
少量有问题的代码可以加以改进，而架构方面的问题会导致更大的问题。
我想我在一开始就应该更加关注应用程序的整体结构，而不是代码的细节。
代码质量很重要，但请注意，代码质量并不是指我以前所认为的那些东西，比如 linting、格式化，等等。