xloger

首先是要有意识，Git 切换分支是比较轻量的，所以是可以多分支开发。
一个简单的协作方式是：dev 分支当开发分支，然后每个人自己一个 dev-xxx 分支，某个人每次开发完一部分把代码合并到 dev ，需要的时候也从 dev 拉代码到 dev-xxx 分支。
这种是比较简单省事不容易出问题学习成本也不高的方式。

另一种更简单的方式就是其他人说的，push 的时候选 rebase ，在 IDEA 里也是一键的事。

笑死，JVM 的那题我都没答出来。这种题确实是纯恶心人了，该骂。
首先，如果是纯粹地过滤出发烧友，靠答题来增加门槛，这个我个人是支持的。但是你看这些题是为发烧友设计的么？
我都能脑补出这个功能的实现场景：是一群用着 iPhone 并不发烧的产品经理，他们不理解小米为发烧而生是什么含义，只觉得吵闹。然后题目就随便交给某个研发出几个，然后那几位不负责的研发想“不就是要考倒人嘛，我去找几个面试八股文”，然后就弄成这个鬼样子了。

十分符合我对小米公司做事态度的印象。

这件事其实是比较旗帜鲜明的两派的。
我的个人观点是：我又不是跟这个公司绑死在一起，我认真做事好好写代码首先是对自己负责，其次才是对公司负责。这就跟高考一样，使心眼跟同学竞争毫无意义，你的对手是整个省。
如果日常开发也是能凑合就凑合，那哪天你想写简洁易懂的代码就能信手拈来么？人的能力都是锻炼出来的。
如上面所说，裁员来的时候一般是大势，个人的这些“小技巧”无足轻重。我认为提高自己的竞争力才是关键。（可能互联网行业就不存在养老的说法吧......）

我记得前些年有个梗：淘宝是旗舰机都带不动的 App 。
当年我还是挺伤感的，阿里仗着自己市场份额给用户喂屎。包括深色模式也是一直没支持。
前些天看到阿里跟拼多多的市值对比新闻，虽然我对拼多多也没啥好感，但不由还是开心：善而终有报，阿里的傲慢终究是反噬到了自己。
[我在等腾讯的报应了

@niceyuri 好的，我昨晚搜了一下这本书，看着确实很适合。不过完全没啥电子版不能先预览一下，不过我看当当京东有卖，到时候买来看看，但又要考虑凑单好烦...


@py2ex 虽然软件工程的内容我忘得差不多了，但是当初我上课的回忆还在脑海：
教我们各种图怎么画，继承用这种箭头，组合用这种箭头，实现用这种箭头。然后论文这里写啥那里写啥，每个类你要写个表格把属性返回值全列上。
甚至整个流程都是在我写完了代码后对着代码画出来的。我觉得是完全起不到辅助我改善代码质量的作用。
当然，我知道这更可能是我这个辣鸡学校的问题，国外的公开课应该会好一些。但是我个人担心这类又太基础（面向的都是学生），不能针对我的痛点“程序员自身希望能靠学习些工程知识辅助我更好地编写高质量代码”。
相比之下我觉得楼上推荐的那些书籍的部分章节应该会对我有帮助，因为面向的本身就是程序员。
当然也谢谢你的建议，等我先看看那几本书，之后再找点公开课查漏补缺。


@johnhuangemc2 谢谢，目前简单看了一下，似乎对模块拆分之类的很有帮助，我之后仔细了解一下。


@LBLK 谢谢，这确实是一本知名的但是我还没看的书。刚刚瞄了几眼面向对象和函数式相关的阐述，确实很透彻，加深了我对一些做法的理解。比如可变性的隔离和事件溯源。

@sleepm #6 好的，谢谢，那本 UML 我看了下目录，有部分章节应该对我有帮助，我到时候挑着看看。
《发现问题的真正所在》这本不错，对日常分析问题估计也有帮助，我仔细看看。
是的，您说的这些是实在的锻炼方式，我也在这样努力。然后就感觉自己分析的时候如果没有更优质的经验学习，那往哪个方向就不太明了了。就像我刚毕业那几年自己会琢磨怎么写代码比较好，直到某次阅读了 Effective Java 惊为天人，很多我苦苦思索也不知道哪样更好的东西，它清晰完整地解释出来了。
路肯定是要自己一步一步走的，但有前人的经验肯定能走得更好。
当然，对我来说如果有这么一个理想的能让我受益匪浅的资料是惊喜，没有那我也还是慢慢锻炼总结吧。

@tool2d 是啊，我也觉得很难，不同项目、岗位的差异都是很大的。所以我的思路是学习后取其对我有用的，比如“可监控、可回滚、可灰度”，这里面我身为 Android 客户端开发，是完全没有回滚灰度需求的（靠版本控制而不是代码控制了）。
但是我觉得这种意识对我的平常开发帮助还是很大的。如正文所说，我会在开发时有意识让我的代码是“可回滚”，可以方便地切换新旧逻辑供调试（而不是频繁切换 Git ），“可监控”就是让我有意识地让代码的逻辑完整，比如对一些不可能的逻辑不直接 if xxx return ，而是会加个埋点，如果真的发生不该走的逻辑能及时发现。

模块分层确实是永远的难点，这个我就确实不指望能学到啥就能一劳永逸了，只能靠经验分析，成长。这个我当初看到过一个文章对我的帮助还是挺大的：<https://www.maguangguang.xyz/layered-architecture>



@jones2000 嗯是的，这些目前是有的，不过侧重点在产品那边。我司现在的产品他们需求分析做的挺好，竞品对比也很完整，不用我太操心这些。我现在困扰的地方在于需求到代码之间的这个桥梁，如何用更好的工具和文档辅助。


@sordidclown 谢谢，大概扫了一眼，很全面很理论。书应该是好书，我努力看看能不能看下去吧


@xuanbg 我个人（个人观点）一直不太习惯思维导图，因为我感觉思维导图承载的信息量有点小，我个人更习惯 h1 、h2 、h3 这样的一个一个列下来，然后顺着目录看也挺方便。当然我们的思路是一致的，靠工具来辅助自己梳理思路，工具适合自己习惯就行。

@MyComputer 嗯我问了一下，它的回答是：

《代码大全》：这是一本非常经典的软件开发书籍。从需求分析、设计到编码实现，再到测试和维护，书中都有深入的讨论。书中还强调了代码质量的重要性，给出了很多实用的代码优化技巧。

《重构：改善既有代码的设计》：这本书主要讲解如何通过重构技术改善已有代码的设计，使其更易于理解和维护。书中提供了很多重构的实例，可以帮助你进一步理解和掌握重构技术。

《敏捷软件开发：原则、模式与实践》：这本书从原则和模式两个角度介绍了敏捷软件开发方法。书中讲解了很多设计模式和编程原则，可以帮助你更好地设计和实现代码。

《软技能：代码之外的生存指南》：这本书讲解了很多软件开发之外的知识，包括职业发展、学习方法、人际交往等。这些知识对于提升你的软件开发水平也非常有帮助。

阮一峰的网络日志：阮一峰是国内知名的程序员，他的博客中有很多关于软件开发的文章，包括编程技巧、设计模式、前沿技术等，都非常值得一读。

陈皓的博客：陈皓是 CSDN 的创始人，他的博客中有很多关于软件开发的文章，从软件开发的基本原则到设计模式，再到软件开发的最佳实践，都有涉及。你可以从他的博客中学到很多实用的知识。

这几本书我觉得不太适合我的地方在于：
前两个，我这其实不是代码层面的技巧了，而是靠一些“工程意识”去辅助写代码。而敏捷开发的问题在于，我改变不了整个项目的开发流程，我只能也只打算管好我自己，那这些需要配合的策略不适合我。
那本软技能就是一些面试之类的其他技巧，有点偏了。

这很明显是温水煮青蛙吧，公司现在这发展节奏目测熬个两三年也差不多倒闭了，那假如转外包了，过两三年你再出来找工作，你觉得哪种选择更好。