远凡的读书笔记和投资实盘第207天总盈亏：12.97% 《人月神话》
展开
今天是实盘记录的第207天。
期末资产：338921.00元 累计盈亏：12.974% 今日盈亏 4922.87元
相对沪深300超额 11.891%， 相对中证2000超额 10.818%
目前几天最主要的事情，应该就是今晚美国cpi怎么“编”了。
感觉我自己没能力解读这个，所以准备借助今晚到周五的各种产品走势，以及其他人，尤其是美国几个主要投行的说法，再慢慢看下。
然后对于这个账户，我倒是有点奇怪，就是感觉中泰的这个结算，怎么出现整数的频率有点不对。直接是整块钱，0角0分的频率这么高？这让我感觉他们的结账系统是不是有问题？尤其是是否有我根本没能力校验的，账户资金因为记账导致的额外损失或者丢失？
这不是我瞎担心，而是这本就是程序员违法的最常见形式。被抓住的，远比这么干的要少很多。（另一种程序员常见违法就是所谓的“肉鸡”，别问我怎么知道的，^_^。）
不过就算我怀疑，我也没有能力、更没有精力来检验这个。所以不管到底是什么情况导致的，我的做法就只能是把资金分在不同的券商。可能这么做解决不了任何问题，只是我自己的惯或者说毛病吧。
今天准备偷懒下，就只有这么多，然后抓紧处理其他工作。
说明：
目前实盘展示的是一套量化交易系统。正常每天分别买入和卖出六只股票。偏小市值股票。
我有参加淘股吧实盘比赛，实盘比赛用的系统，就是展示的这个。数据相同。
下面是目前账户截图：
读书笔记部分：
（《人月神话》（The Mythical Man-Month）是弗雷德里克·布鲁克斯（Frederick P. Brooks）于1975年出版的经典著作，基于他在IBM领导System/360操作系统开发的经验写成。书名中的"人月"指的是用人力和时间来衡量软件开发工作量的单位，而"神话"则直指一个核心观点：向一个已经延期的软件项目增加人手，只会让它延期得更严重。）
被誉为「软件工程圣经」的《人月神话》，有哪些理论过时了？
（pansz）
一个都没有过时，反而价值更高了，无愧于是圣经。
观点一：人月不可互换，10个人一个月无法完成一个人10个月完成的任务。
现在没过时，就算10个人带着AI，也同样不可能一个月完成一个人带着AI需要10个月完成的任务。
观点二：向进度落后的项目中增加人手，只会使进度更加落后。
现在也没过时，增加人手确实无法改变进度落后的现实。哪怕有了AI，每个工程师的思路依然不相同，10个人各自指导AI依然比不上1个人指导AI更长时间。然而单个人的精力有限，你给它更多的AI并不能让他加速。
观点三：系统设计必须保持概念一致性，由少数精英（"贵族"）负责架构设计，大多数人负责实现。好的设计需要简洁性，一个系统最好由少数几个核心设计师把控，避免"设计委员会"式的折中妥协。
现在也没过时，因为整个系统的概念一致性依然重要，可能比以前更重要，因为当软件规模上涨较慢时，很多工程领域的规则看起来很教条。但一旦软件规模可以被AI快速上涨时，那些工程领域的经验突然就会变成了真理。
观点四：用小型精干团队（1 位主刀医生 + 辅助人员）替代大型团队，以解决沟通效率问题。大型项目应通过多个这样的小型团队并行协作，而非组建一个庞大的扁平团队。
现在更加没过时，因为小型精干团队恰恰就是AI最擅长的领域。
观点五：架构师设计的第一个系统往往过于谨慎、功能不足。第二个系统则容易过度设计、堆砌功能，导致复杂度和成本失控。提醒人们对第二个系统保持警惕。
现在依然没过时，你跟AI多聊几遍就懂了。但这句话没说的是，如果咱们可以获得第三个系统，第四个系统，结果会如何。
观点六：团队规模扩大时，沟通成本（会议、文档、协调）会急剧上升。新人加入后，需要培训才能有效产出，而培训本身会消耗现有成员的产能。
现在更加没过时，为什么宁可裁员或者让程序员加班也不愿意招新人？因为人月神话早就说了新人加入的成本。
观点七：没有银弹（No Silver Bullet）。没有任何单一技术或管理方法能在十年内使软件生产力提升一个数量级（10 倍）。软件开发的根本困难在于概念性设计（思考做什么），而非实现（编码），后者可以通过工具改进，但前者难以被自动化。
现在不但没过时，而且还成为了圣经，因为「实现」环节确实如他所说被工具改进了，但这改变的是偶然复杂度，但软件开发的本质复杂度没有因此而改变。而这部分并不能被工具改进与提速。
有的朋友觉得自己可以几个小时内搞一个原型级别的小应用，但他可能不知道，就算在AI到来以前，这种级别的东西自己到众包去找程序员接单，也是可以又便宜又快的。
观点八：书面规格说明和文档是团队沟通的核心媒介。口头沟通不可靠，必须通过文档固化决策、传递设计意图。
这也同样，不但不过时，还成了圣经。
观点九：软件项目估算往往过于乐观，因为人们倾向于假设一切顺利。实际项目中，调试和测试往往占去比预期多得多的时间。建议采用"1/3 计划、1/6 编码、1/4 组件测试、1/4 系统测试"的时间分配。
这显然没过时，「编码时间仅占六分之一」是人月神话在很多年前就已经提出的观点，然而很多人就是不相信也不想相信，同时，「测试时间是长常规编码时间的三倍」也有很多人不相信，但现实中必须撞这个南墙才能懂。哪怕你把编码时间优化到零，整个项目的其它时间也并没有缩短，何况，实际上编码时间并没有减少太多，写代码的时间转化为写prompt的时间并不会无限制的提升开发效率。
观点十：区分了程序（Program）、编程产品（Programming Product）、编程系统（Programming System）和系统产品（Systems Product）四个层级。真正的商业软件是"系统产品"，其复杂度远非一个独立程序可比。
这就更加没过时。
总结：在AI时代，由于具体软件技术栈的重要性下降，软件工程的重要性变得无与伦比，而软件工程圣经的含金量，得到了无与伦比的提高。
简化诠释：软件工程的根本挑战在于管理的复杂性（尤其是沟通和概念一致性），而非单纯的技术实现；在技术实现上出大力优化，并不是解决软件工程的万能药，反而可能是毒药。
期末资产：338921.00元 累计盈亏：12.974% 今日盈亏 4922.87元
相对沪深300超额 11.891%， 相对中证2000超额 10.818%
目前几天最主要的事情，应该就是今晚美国cpi怎么“编”了。
感觉我自己没能力解读这个，所以准备借助今晚到周五的各种产品走势，以及其他人，尤其是美国几个主要投行的说法，再慢慢看下。
然后对于这个账户，我倒是有点奇怪，就是感觉中泰的这个结算，怎么出现整数的频率有点不对。直接是整块钱，0角0分的频率这么高？这让我感觉他们的结账系统是不是有问题？尤其是是否有我根本没能力校验的，账户资金因为记账导致的额外损失或者丢失？
这不是我瞎担心，而是这本就是程序员违法的最常见形式。被抓住的，远比这么干的要少很多。（另一种程序员常见违法就是所谓的“肉鸡”，别问我怎么知道的，^_^。）
不过就算我怀疑，我也没有能力、更没有精力来检验这个。所以不管到底是什么情况导致的，我的做法就只能是把资金分在不同的券商。可能这么做解决不了任何问题，只是我自己的惯或者说毛病吧。
今天准备偷懒下，就只有这么多，然后抓紧处理其他工作。
说明：
目前实盘展示的是一套量化交易系统。正常每天分别买入和卖出六只股票。偏小市值股票。
我有参加淘股吧实盘比赛，实盘比赛用的系统，就是展示的这个。数据相同。
下面是目前账户截图：
读书笔记部分：
（《人月神话》（The Mythical Man-Month）是弗雷德里克·布鲁克斯（Frederick P. Brooks）于1975年出版的经典著作，基于他在IBM领导System/360操作系统开发的经验写成。书名中的"人月"指的是用人力和时间来衡量软件开发工作量的单位，而"神话"则直指一个核心观点：向一个已经延期的软件项目增加人手，只会让它延期得更严重。）
被誉为「软件工程圣经」的《人月神话》，有哪些理论过时了？
（pansz）
一个都没有过时，反而价值更高了，无愧于是圣经。
观点一：人月不可互换，10个人一个月无法完成一个人10个月完成的任务。
现在没过时，就算10个人带着AI，也同样不可能一个月完成一个人带着AI需要10个月完成的任务。
观点二：向进度落后的项目中增加人手，只会使进度更加落后。
现在也没过时，增加人手确实无法改变进度落后的现实。哪怕有了AI，每个工程师的思路依然不相同，10个人各自指导AI依然比不上1个人指导AI更长时间。然而单个人的精力有限，你给它更多的AI并不能让他加速。
观点三：系统设计必须保持概念一致性，由少数精英（"贵族"）负责架构设计，大多数人负责实现。好的设计需要简洁性，一个系统最好由少数几个核心设计师把控，避免"设计委员会"式的折中妥协。
现在也没过时，因为整个系统的概念一致性依然重要，可能比以前更重要，因为当软件规模上涨较慢时，很多工程领域的规则看起来很教条。但一旦软件规模可以被AI快速上涨时，那些工程领域的经验突然就会变成了真理。
观点四：用小型精干团队（1 位主刀医生 + 辅助人员）替代大型团队，以解决沟通效率问题。大型项目应通过多个这样的小型团队并行协作，而非组建一个庞大的扁平团队。
现在更加没过时，因为小型精干团队恰恰就是AI最擅长的领域。
观点五：架构师设计的第一个系统往往过于谨慎、功能不足。第二个系统则容易过度设计、堆砌功能，导致复杂度和成本失控。提醒人们对第二个系统保持警惕。
现在依然没过时，你跟AI多聊几遍就懂了。但这句话没说的是，如果咱们可以获得第三个系统，第四个系统，结果会如何。
观点六：团队规模扩大时，沟通成本（会议、文档、协调）会急剧上升。新人加入后，需要培训才能有效产出，而培训本身会消耗现有成员的产能。
现在更加没过时，为什么宁可裁员或者让程序员加班也不愿意招新人？因为人月神话早就说了新人加入的成本。
观点七：没有银弹（No Silver Bullet）。没有任何单一技术或管理方法能在十年内使软件生产力提升一个数量级（10 倍）。软件开发的根本困难在于概念性设计（思考做什么），而非实现（编码），后者可以通过工具改进，但前者难以被自动化。
现在不但没过时，而且还成为了圣经，因为「实现」环节确实如他所说被工具改进了，但这改变的是偶然复杂度，但软件开发的本质复杂度没有因此而改变。而这部分并不能被工具改进与提速。
有的朋友觉得自己可以几个小时内搞一个原型级别的小应用，但他可能不知道，就算在AI到来以前，这种级别的东西自己到众包去找程序员接单，也是可以又便宜又快的。
观点八：书面规格说明和文档是团队沟通的核心媒介。口头沟通不可靠，必须通过文档固化决策、传递设计意图。
这也同样，不但不过时，还成了圣经。
观点九：软件项目估算往往过于乐观，因为人们倾向于假设一切顺利。实际项目中，调试和测试往往占去比预期多得多的时间。建议采用"1/3 计划、1/6 编码、1/4 组件测试、1/4 系统测试"的时间分配。
这显然没过时，「编码时间仅占六分之一」是人月神话在很多年前就已经提出的观点，然而很多人就是不相信也不想相信，同时，「测试时间是长常规编码时间的三倍」也有很多人不相信，但现实中必须撞这个南墙才能懂。哪怕你把编码时间优化到零，整个项目的其它时间也并没有缩短，何况，实际上编码时间并没有减少太多，写代码的时间转化为写prompt的时间并不会无限制的提升开发效率。
观点十：区分了程序（Program）、编程产品（Programming Product）、编程系统（Programming System）和系统产品（Systems Product）四个层级。真正的商业软件是"系统产品"，其复杂度远非一个独立程序可比。
这就更加没过时。
总结：在AI时代，由于具体软件技术栈的重要性下降，软件工程的重要性变得无与伦比，而软件工程圣经的含金量，得到了无与伦比的提高。
简化诠释：软件工程的根本挑战在于管理的复杂性（尤其是沟通和概念一致性），而非单纯的技术实现；在技术实现上出大力优化，并不是解决软件工程的万能药，反而可能是毒药。
主题股票：
主题概念：
声明：遵守相关法律法规，所发内容承担法律责任，倡导理性交流，远离非法证券活动，共建和谐交流环境！
