>>No.63893819
肥哥，本串不做内容限制，想聊什么直接说就好，po尽力回答，也是沟通与提高。( ´∀`)
首先，赞美肥哥的开源精神，po写的很多东西最后都没有选择开源，因为不能保证自己长期维护。
>项目架构管理有没有什么好办法呢？
很抱歉，这个答案是“没有”。
不同项目适合的架构不同，项目在不同的发展阶段的适合架构也不同，没有一个架构能够完全通用。
同时也不推荐在一开始想太多，过分复杂的架构也会成为项目成长的阻碍，逐步去调整架构，或者在过于臃肿时果断推翻重写是比较常用的做法。（PS:实际上在规模达到边界时，推翻重写的成本和继续维护也差不多，有许多模块可以复用，只是调整调用逻辑，对于个人开源项目，修修补补反倒不如一个干脆地2.0来的更舒服，也有易于后续更新。）
同时在新的架构设计中，肥哥可以融入更多新的思想与新的实践，适当剔除曾经用不到的代码块，这样的产品是大家都乐意见到的，我相信也是肥哥更想要的东西。
>阅读真的有必要吗？
这里得问问肥哥，“在读什么东西？”。( `д´)σ
肥哥是想学习它的架构，想学习它的实践逻辑，还是想学习它的设计思路。
每个东西在项目中的占比其实都不大，肥哥觉得无从下手，很多时候是拿到代码就直接去看了，不够有目的性，一个项目都去看，代码量是极大的，并且会深陷其中越学越乱。
肥哥不如静下来先明确一下自己的需求，再去看相应的项目，这样肥哥也能知道自己到底在对比些什么。
同时肥哥也可以看明白它们为什么是好项目，到底好在哪，相近的项目的设计差异到底在哪里，学到东西，肥哥的能力自然就提高了。
>开发逐渐束手束脚。
这个我认为肥哥可以先了解一下SDL（软件开发流程），这样可以明晰自己需要做哪些事情。
同时肥哥考虑的实在是太多了，这反倒不好，因为你不是在做一个“完美的项目”，项目有问题是正常的，需要修改更是正常的，没有人能够保证自己做的东西“永远是最佳的”，所以肥哥也不要追求事实完美，先完成眼前的工作，之后有能力与时间再做调整。
拆开这几个小点聊聊。
1.希望被人在代码贡献时按照一定的规范。
肥哥可以直接讲明自己的规范规则，单独写一个共享代码的格式文档，讲明什么样式的代码更容易被认可，并且给出一两个例子。
说明不适合融入项目或融入成本较高的代码不会采纳就好了。
2.模块划分各有各的方法。
模块化最重要的是“有统一标准”，肥哥在本项目中使用同一套划分标准，所有模块的切割逻辑统一即可，不必要追求极致。
过度模块化也是目前项目的一个“误区”，有时候内部通信效率更高，也没必要完全分块，适度才是最难的。
3.软件如何进行测试。
软件测试的方法种类太多了，本身也是一个学科，很难细细讲清。
首先肥哥在代码上线前应当做好足够的测试，同时需要留出模块的测试接口。
测试要尽量保证覆盖全面，需要考虑多种使用情况等等。
上面只是开个玩笑。
肥哥在测试时需要逐步拓展，先保证基础功能可用，而后当功能出现异常时鲁棒性是否足够，安全性是否足够等问题再逐步加入进去，实在麻烦先保证基础功能可用，剩下的之后再议。
项目在人力不足时不要太“贪婪”，先做好能做的事情，再寻求拓展。
我以前在公司开发的项目，甚至一开始完全没有预留测试功能，测试工具还是后期单独写的，这不影响它曾经是一个不错的项目，贪多嚼不烂的道理肥哥肯定都懂，只是身在居中有些迷茫。
最后提醒一下肥哥，培养一个好的“孩子”的最好方式是放手让它自由成长，太限制自己的同时也会限制项目，有错就错了再改，有问题出现问题再解决，束手束脚有违初衷。|∀` )
PS:肥哥想了解的知识实际上都有对应的书籍去讲解，并不一定只能从别人的项目于代码中学习，从前人总结的内容系统性了解也是不错的学习渠道，学习效率也会更高。
肥哥在自己做了开发工作之后再读书也会有深入的理解，是与作者交流的过程。
例如:《代码之美》，《架构之美》，《软件测试之道》等。
