香榧 （fěi）是中国特有树种，也是世界上稀有的经济树种 .
人类借助发明的工具来满足生活生产的需要,使用生产生活更高效便捷.IT界也不离外,从打卡纸带到图形界面,再到AI.但这个过程中,并没有因为工具的先进带来个人能力的相对飞升,反而是工具越强大,很多基本技能就没有了.
宝塔让大部入门的人,忘记了安装基本运行环节.Jenkins的全自动测试,发版.让很多人根本不知己写的程序是怎么运行在服务器上的.很多人就变成了CRUD BOY,最后就成’水货’了.
最终在工作N年后,才发现,基础才是最重要的,其他的,只是构建于基础之上的”浮云”. 慢慢卷
网络,计算机运行原理,算法,数据结构…
本周小侄女降生 ,^_^. 文章由AI辅助生成
在编写代码时，统一的代码风格和命名方式有助于提高代码的可读性和可维护性。以下是一些建议：
一致性： 保持代码的整体一致性，使得整个项目的代码看起来更为统一。这包括缩进、空格使用、注释风格等。
命名清晰： 使用清晰、具有描述性的变量和函数名。避免使用过于简单或过于复杂的名称，让人容易理解变量或函数的用途。
驼峰命名法： 对于变量名、函数名等标识符，建议使用驼峰命名法（camelCase），即第一个单词小写，后面的每个单词首字母大写。
下划线命名法： 对于常量或全局变量，可以使用下划线命名法（snake_case），即单词间用下划线连接。
避免缩写： 尽量避免过多的缩写，除非是广泛认可的缩写。使用清晰的命名可以提高代码的可读性。
统一注释风格： 使用一致的注释风格，例如使用双斜线注释（//）或块注释（/* */）。注释应该清晰、简洁，解释代码的目的或特殊处理。
代码缩进： 选择一种缩进风格（例如，使用空格或制表符），并在整个项目中保持一致。通常，使用四个空格作为一个缩进的标准。
括号使用： 在控制结构（if、for、while等）中，保持一致的括号使用风格，例如在新的一行开始或在同一行。
文件命名规范： 采用有意义的文件名，并保持一致。文件名可以反映文件内容的主要功能或目的。
版本控制规范： 在使用版本控制时，采用一致的提交信息规范，以便更容易追踪和理解代码的变更历史。
这些建议旨在提高代码的可读性和可维护性，使团队成员能够更容易地理解和协作。在项目中，与团队一起制定并遵循一致的代码规范是一个良好的实践。
离立冬只有3天,但天气预报显示,最高温度有29度,真是太热太反常了.
对于X-Y Problem的意思如下：
1）有人想解决问题X
2）他觉得Y可能是解决X问题的方法
3）但是他不知道Y应该怎么做
4）于是他去问别人Y应该怎么做？
简而言之，没有去问怎么解决问题X，而是去问解决方案Y应该怎么去实现和操作。于是乎：
1）热心的人们帮助并告诉这个人Y应该怎么搞，但是大家都觉得Y这个方案有点怪异。
2）在经过大量地讨论和浪费了大量的时间后，热心的人终于明白了原始的问题X是怎么一回事。
3）于是大家都发现，Y根本就不是用来解决X的合适的方案。
举几个例子：
1 | Q) 我怎么用Shell取得一个字符串的后3位字符？ |
再来一个示例：
1 | Q）问一下大家，我如何得到一个文件的大小 |
再来一个示例：
1 | Q) x工,我们想在这个地方加一个搜索 |
这里有篇文章说明了X-Y Problem的各种案例说明，我从其中摘出三个来让大家看看：
1 | 你试图做X，并想到了用Y方案。所以你去问别人Y，但根本不提X。于是，你可以会错过本来可能有更好更适合的方案，除非你告诉大家X是什么。 |
1 | 有些人问怎么做Y，但其它他想做的是X。他问怎么做Y是因为他觉得Y是最好搞定X的方法。 于是大家不断地回答“试试这个，试试那个”来帮助他，而他总是在说“这个有问题，那个有问题，因为……”。基本不同的情况，其它的方案可能会更好。 |
1 | X-Y Problem又叫“过早下结论”：提问者其实并不非常清楚想要解决的X问题，他猜测用Y可以搞定，于是他问大家如何实现Y。 |
其实这个问题在我之前的《你会问问题吗》里提到的那篇How To Ask Questions the Smart Way中的提到过，你可以移步去看一下。
所以，我们在寻求别人帮助的时候，最好把我们想解决的问题和整个事情的来龙去脉说清楚。
我们不要以为X-Y Problem就像上面那样的简单，我们不会出现，其实我们生活的这个世界有有各种X-Y Problem的变种。下面我个人觉得非常像XY Problem的总是：
其一、大多数人有时候，非常容易把手段当目的，他们会用自己所喜欢的技术和方法来反推用户的需求，于是很有可能就会出现X-Y Problem – 也许解决用户需求最适合的技术方案是PC，但是我们要让他们用手机。
其二、产品经理有时候并不清楚他想解决的用户需求是什么，于是他觉得可能开发Y的功能能够满足用户，于是他提出了Y的需求让技术人员去做，但那根本不是解决X问题的最佳方案。
其三、因为公司或部门的一些战略安排，业务部门设计了相关的业务规划，然后这些业务规划更多的是公司想要的Y，而不是解决用户的X问题。
其四、对于个人的职业发展，X是成长为有更强的技能和能力，这个可以拥有比别人更强的竞争力，从而可以有更好的报酬，但确走向了Y：全身心地追逐KPI。
其五、本来我们想达成的X是做出更好和更有价值的产品，但最终走到了Y：通过各种手段提升安装量，点击量，在线量，用户量来衡量。
其六、很多团队Leader都喜欢制造信息不平等，并不告诉团队某个事情的来由，掩盖X，而直接把要做的Y告诉团队，导致团队并不真正地理解，而产生了很多时间和经历的浪费。
所有的这些，在我心中都是X-Y Problem的变种，这是不是一种刻舟求剑的表现？
作者许晓斌是《Maven实战》作者，很多见解都很有深度。
研发效率下降的背后，核心因素是来源于软件复杂度的上升。
作者借用《人月神话》的论述，将软件复杂度分为本质复杂度（Essential Complexity）和偶然复杂度（Accidental Complexity）。
本质复杂度，指的就是来自问题本身带来的复杂度，比如用户规模过大，技术难度很高；而偶然复杂度则来源于解决方案本身，例如你选择的技术带来的，比如你选择某前端需要去学习，选择了某分布式框架引入了复杂度，还有团队成员的工程管理、项目管理等等。
而要解决复杂度带来的问题，应对方法不对可能会治标不治本。
比如常见的一个错误方式就是设置不靠谱切不可更改的Deadline，即使靠加班和缩小需求范围也无法达成，最终只有牺牲软件质量，反而是大幅提升了偶然复杂度。
还有一种错误方式就是用所谓“先进”技术，例如微服务，或者某个新出的前端框架。但如果你面临的问题从业务的角度来说，正好是这种先进技术所能弥补的，那么没问题，但如果你的问题是研发效率问题，先进技术不仅不能帮忙，还反而因为新老技术切换带来更多的偶然复杂度。
那么什么是正确的应对方式。
一种方式是宏观层面。
将一些复杂的系统，分离出去，通过购买或使用第三方成熟系统来降低复杂度，例如数据库、调度系统、消息队列等等。
通过对系统架构和组织架构的调整，将系统的复杂度层层分解，将复杂的系统拆分成相对简单的模块，同时组织架构和系统架构保持一致。
一种方式是微观层面，提升代码质量、增加单元测试的覆盖，并且从团队的流程、工程文化上下功夫，借助好的流程，例如CI/CD和代码审查；激励消除复杂度的行为；让增加、降低复杂度的行为透明。
我觉得文章中提出的复杂度问题都是很现实的问题，从宏观和微观两个层面入手也是很好的思路，但还是需要根据团队的情况自己调整。
#软件工程之美#
