1.7 面对技术我们纠结的那些事儿
人生需要面对很多纠结我们都是在纠结中磨练自我意志的。
纠结容易让人浮躁容易让人犯错但是纠结同样会让人成长纠结是黎明前的黑暗。
学会将纠结化作成长的力量在逆境中能生存的强者才是真正的“老A级程序员”。
1.7.1 为什么我这里好用那里不好用
“为什么我这里好用那里不好用”
小鬼你是不是经常说这句话如果是那你“中标”了。
你怎么知道我经常这么说呀
这句话要么是老鸟说要么是小鸟说同一句话老鸟说的意思和小鸟的得意思完全不一样哦
有啥不一样呢
小鸟通常是碰到问题就说这句话而老鸟通常是解决问题后才说这句话小鸟说这句话是纠结继续跟自己过不去老鸟说这句话是为了搞懂本质和原理整合事实与理论证明自己的结论总结自己的知识。
小鸟还是不懂这是为什么好可怜。
小鸟啊小鸟你想想你还不会飞还没有走出你的窝怎么能看清楚这个世界这个世界上万物生灵的成长你提出的为什么只是虚幻没碰过的。老鸟已经在天空中翱翔数年它们拥有自己的生存与自然界经验深知自然界的生命循环与弱肉强食的道理知道什么是好与坏知道什么是美与丑知道什么是天敌与猎物。你若想要了解这个世界“努力锻炼自己拥有一双可以翱翔的翅膀去感悟这个世界吧”。
可能从一只小鸟成长起来会经历沉默然而不在沉默中爆发就会在沉默中灭亡。当你成长为老A的时候你应该知道的是在解决问题后才会提出相关性问题而不是在解决问题前所以真正的一个老A、一只老鸟可以说这样的话。
反过来讲要提出问题也需要有点水平才能真正切入主题将问题说清楚有的小鸟喜欢占主动权问问题的时候想要牵着老鸟的鼻子走老鸟会问小鸟想知道的问题细节但小鸟继续说自己想说的结果是老鸟不知道小鸟要什么也搞不清楚问题是什么。老鸟逼于无奈而且自己还有事情最后就装着什么也不知道小鸟就经常会说老鸟有什么用啊什么问题都搞不定当自己发现低级错误的时候还可能得意地想“不就是一个低级错误吗老鸟竟然解决不了。”
无论如何我们离不开的是实际场景要根据实际的工作背景来解决问题这样才能达到较好的效果同时在一些代码bug的修复上可能还会分析实际场景中代码修改的相关影响。在运维层面可能是保留现场后直接重启再通过copy的现场做模拟在一些长远问题上可能我们需要慢慢来分析。
这就是胖哥讲的老鸟与小鸟的故事如果你是小鸟你懂了吗
1.7.2 你的程序不好用你会不会用环境有问题
“你的程序不好用你会不会用”
能说出这句话也许你是一只老鸟了但是不一定是一个老A。
这是一个对自己充满自信的程序员在面对别人提出质疑时的第一反应可能作为老鸟你会说自己不是这样的人那么你真是一朵“奇葩”或者你真的升华到了“大师”级别修身养性的境界非同一般。在众多老鸟之中我们都有一股“程序员的野性”这种野性通常来自于自己研究了许多东西以及在相关领域待的时间很长所赋予自己的强烈自信感。
学海浩瀚无边任何人即使是大师也有犯错的时候所谓“老虎也有打盹的时候”尤其是在工期要求很紧的时候“一流高手”和“二流高手”体现的水平不会有多大的区别因为他们都是“老鸟级”的人物代码编写速度和问题解决能力都是非常强的而更高境界上的区别在这种情况下是体现不出来的。
在面对别人提出质疑的时候第一反应其实是看你的内心世界是否足够强大。别人质疑你的第一句话有可能是顶住你心窝的话有可能是将你苦思冥想的方案瞬间彻底否决的话有可能是将你很长时间的辛苦付出瞬间说得毫无价值的话有可能是将你的成果瞬间打入无底深渊的话也许是对你和大家都认可的事情简单敷衍的话。这些话相信比质疑你的代码有Bug会更加重一点吧这个时候你会如何想呢
或许一颗强大的内心需要去磨练小胖哥也在不断磨练中成长自我。也许你会觉得很累因为这是在挑战自己的个性改变自我是最痛苦的事情。也许这个时候我们可以看看别人是如何修身养性的别人能做到我们同样可以做到。
代码有问题我们就看原因不论是不是自己的问题都要告诉真正的原因。有问题没关系我们不怕犯错误而是怕错了不改反反复复犯同样的错误可能还是同样低级的错误。
如果反反复复有人提出同样的问题而绝大多数情况下都知道不是自己的问题那么就将它以文档的方式呈现出来因为代码是我们写的使用者通常不知道所有的细节。
如果没有任何规约就意味着可以随便“乱搞”事实上逻辑的东西暂时是不可能做到这一点的就算是写代码也得遵循基本的语法规则用数据库也得遵循它的基本规约而不能乱删除东西用接口需要遵循接口规约“乱搞”的结果就是东西越多、问题就越多做一件事情来解决问题但是带来了更多的问题。
这个“乱搞”的底线是什么完全是看系统的设计思路也就是软件的伸缩性你需要让用户知道不能去做或不建议去做的事情我们可能会提供但是不完全保证它的正确性或安全性为什么不保证也许某些用户也想要知道。
回过头来对于自己来讲最重要是冷静面对事情的真相客观面对我们所面临的事情加上对业务本身的熟悉程度、技术功底的配合、冷静思考、量化的判断、全局性影响的分析逐步突破层层技术和业务难关相信我们可以很“酷”地解决绝大部分的问题。解决问题的手法也会多种多样而并非等闲之辈。
1.7.3 经验是否能当饭吃
通过对前面几节内容的介绍胖哥就是想让你知道也许某些经过试验论证或曾经解决问题得到的结论不是很靠谱或者说并不是“永远靠谱”的。
前面也提到了其实在技术的发展过程中我们都是站在前人的肩膀上做进一步的事情它们虽然以“平台、插件、思想”的方式提供给我们作为基础但是通常也都是代码可以先不说“只要是代码肯定就会存在Bug”但是软件程序在不断更新换代的过程中肯定会存在各种逻辑的复杂性来满足更多的需求就像一个系统做复杂了的道理一样。
随着实际代码的复杂性增强就会产生各种各样的运行逻辑此时如果API写得过分简单那么许多程序员可能就不知道这个API下面的许多细节也没有那么多精力来关注每个细节因此就可能会导致很多不可预见的问题。在某种场景下我们可能将问题解决了但是也许并不是因为看到了问题的本质而有可能是因为某种巧合走到了一条正确的执行路径上。
除了上面的例子曾经有不少人在“乱码”上经常出现怪异的问题小胖哥也曾经为此纠结过很久很多人在遇到乱码后都会像小鸟一样说“为什么我这里好用另外一个地方却不好用呢”这类问题在网上通常有很多方法大多要求你将数据库、应用服务器、接口、环境变量、页面等输入/输出的字符串全部统一。其实这种方法只能解决某些局部问题并未看到问题的根本。
为什么说只能解决某些局部问题呢
因为在某些场景下系统会连接不同的数据库、缓存、分布式存储、应用方、中间件等它们都有可能会提供不同的字符集输入输出我们也无法控制别人提供的服务必须用什么字符集。换句话说你或许在某种程度上可以保证自己的应用系统使用什么字符集来避开许多问题但是当面对复杂的分布式环境时你不得不去知道字符集的根本所在。只有搞清楚这类问题的本质才能在遇到类似的问题时去定位分析。
关于乱码更多的介绍
乱码问题不是本节讨论重点关于乱码方面的问题在本书后文中第2.6节中有更多的介绍在第4章的通信里面提到一些相关的基础知识在下册的专门介绍“坑”的章节会有另一个侧面的说明。
再换位思考一下软件在不断革命的过程中内在的逻辑在不断变化也变得更加复杂它们提供的一些参数可能发生改变即使是同样参数的API的内在实现也有可能与以前大不相同。此时随着技术的发展一些经验开始变得“不太靠谱”包括我们曾经记录下来的经验值、默认值甚至是官方标准它们都可能在一个小的版本变化中变得不靠谱。
因此我们需要新的学习是否会觉得很累呢我们在不断学习别人提供的东西在不断记忆别人的东西前一样东西还没掌握清楚新的又来了肯定很累。但这需要方法也需要功底当你懂得它的根本与发展的方向和模式基本就知道它要做什么了也基本知道会怎么做了自己也可以实现只是没必要而已。一些开源软件中常见的参数不会太多而更多的参数当你知道它的根本后通过某些命令和文档查阅是非常快速的我们学习的代价不应该太大。
回过头来总结一下我们应当“站在前人的肩膀上看问题不仅仅是要沿用前人写好的东西更需要看到他们所遇到的那些坑”。在理论指导的基础上比前人看得更高、更远社会和技术才可能向前发展和进步新一代程序员不必都经历上一代程序员所经历的同样的坑那样只是延续而没有任何发展。新一代程序员即使要经历坑也是经历一些更新的坑去挖掘更新的东西而不是走老路。
小胖哥说了这么多话有什么用呢就是想要告诉读者朋友经验可以用以借鉴和参考但经验不能用来当饭吃同时别人告诉你的是他的经验也同样是一种参考和借鉴我们需要学会去看问题本质的方法与习惯。也许你不太认同小胖哥的观点可能你和小胖哥看待问题的角度不一样胖哥也很希望你有不同的自我见解但也相信我们会有一些共同的认识。
接下来我们用轻松的方式来论道谈论老A的那些事老A在面对逆境时是如何面对的。