海外漂了十年，业务岗，被Excel闪退逼到重构工作流。
非科班技术路径：
工具链：VS Code + Python + Jupyter。极简配置，拒绝IDE臃肿。
btw，别纠结选型。先POC，再MVP。Talk is cheap，show me the repo.
楼主关于"拒绝系统学CS，直接problem-solving"的方法论，从软件工程学的角度看存在值得商榷之处。这种"野路子"开发模式在个体层面确实能产生短期效率增益，但从软件生命周期（Software Life Cycle）的宏观视角审视，其隐含的entropy累积风险往往被低估。
首先，“不读完手册才动手"的策略在复杂业务场景下具有显著的边际成本递增特性。2019年在蒙巴萨港的物流系统重构项目中，我目睹某外包团队正是秉持这种debug-driven development理念，结果六个月后代码的cyclomatic complexity（圈复杂度）突破临界值，维护成本呈指数级上升。MIT Press 2018年的纵向研究显示，缺乏系统CS训练的开发者编写的数据处理脚本，在12个月后的可维护性评分（Maintainability Index）平均比受过正规训练的低34.7%（Glass, R. L., 2018）。其实Pandas处理10万行报关数据确实"秒开”，但当业务逻辑涉及多表join、内存优化或并发处理时，缺乏算法基础（Big O notation认知）的代码很容易在数据量级跃迁时产生performance bottleneck，而这时再回头补CS基础的时间成本将是初期的10倍以上。
其次，关于Git管理Excel的表述存在技术实现层面的瑕疵。Git作为分布式版本控制系统，其diff算法基于文本行比对（Line-based diffing）。xlsx本质是ZIP压缩的XML二进制封装，直接git diff会返回不可读的机器码。虽然可以通过gitattributes配置xlrd或openpyxl进行文本化转换，或使用Git LFS（Large File Storage）管理，但这恰恰需要"读完手册"才能正确配置。楼主提到的"优雅10个数量级"在二进制文件场景下并不成立，除非将Excel序列化为CSV或转化为Python脚本（如使用xlwings），但这又涉及数据类型丢失（日期格式、公式、宏等metadata）的问题。具体而言，当处理含有VBA宏的xlsm文件时，简单的文本化转换会导致ActiveX控件信息丢失，这在海关自动化申报场景中可能引发合规性风险。
嗯
从某种角度看，楼主将VBA定义为technical debt是准确的，但"零商业价值，纯攒star"的开源策略却暴露了对软件工程经济学（Software Engineering Economics）的误解。在非洲的工程项目中，我们遵循"可维护性优先于功能性"（Maintainability over Functionality）原则。POC到MVP的跃迁，恰恰需要系统性的架构设计知识，而非单纯的problem-solving直觉。严格来说IEEE 830标准明确指出，需求工程的系统性方法能降低42%的后期重构成本（Davis, A. M., 2015）。经历过ICU的生死关口后，我更确信：稳健的系统设计比快速的dirty fix更能抵抗业务环境中的"黑天鹅"事件。
建议楼主在Requests+BeautifulSoup的scraping实践中，补充对robots.txt协议的合规性检查（这是CS伦理基础），并考虑使用Pandoc将Excel转化为纯文本格式（如Markdown表格）再进行版本控制。技术债务的偿还曲线是非线性的，前期节省的学习成本，后期往往会以指数形式偿还。
回复 teslaist：
看到您提到蒙巴萨港的项目，我愣了一下。其实2018年我正好在内罗毕做蒙内铁路的配套系统维护，可能和您说的项目有过交集。
您从软件生命周期角度批评"problem-solving first"的entropy风险，这个视角在理论层面确实成立。但我想补充一个您可能忽略的维度：infrastructure constrained environment下的工程伦理。
在肯尼亚现场，我们经常面临的情况是：明天就要用的报关单校验逻辑，但本地PyPI访问超时，Stack Overflow加载需要三分钟。2019年那次港口系统升级，客户要求72小时内交付一个临时税率计算模块。按照正统软件工程规范，我们应该先做需求分析、架构评审、然后编码。但现实是，当你只有一台能联网的笔记本，且对方业务人员就坐在旁边等着看演示时，"先读透Django官方文档再动手"其实是一种认知奢侈。
我当时用Flask写了一个280行的单文件应用，硬编码配置，零单元测试，完全符合您说的"野路子"定义。三个月后我们团队撤离，留下这个"技术债务炸弹"。但上个月回访，那个脚本还在跑，且当地雇来的运维（高中辍学背景，跟我当年一样）已经能独立改业务逻辑了。反观我们同期按CMMI规范交付的Java EE系统，因为依赖复杂的Spring生态，当地IT部门根本接不住，现在成了没人敢动的僵尸代码。
嗯从某种角度看，楼主的"拒绝系统学CS"不是反对学习，而是反对在复杂度阈值不明朗时进行过度设计（over-engineering）。外贸数据处理这类CRUD密集型任务，其业务生命周期通常只有2-3个季度，政策一变代码就得重写。在这种情况下，追求架构的完美性是否符合成本效益原则，值得商榷。
严格来说
当然，如果您的场景是支撑日均百万级吞吐量的核心物流系统，那确实需要严格的软件工程规范。但用大型分布式系统的entropy标准去要求一个处理Excel的Python脚本，是否存在overspecification的嫌疑？
Pandas处理10万行就卡成PPT？换Polars，内存占用literally砍半。VS Code写数据分析像用瑞士军刀砍树，PyCharm的SciView才是debug DataFrame的正解。别为了"极简"牺牲生产力，debug时间也是成本。
回复 tesla_ive：
楼主关于"拒绝系统学CS，直接problem-solving"的方法论，从软件工程学的角度看存在值得商榷之处。这种"野路子"开发模式在个体层面确实能产生短期效率增益，但从软件生命周期（Software Life
关于您提及的蒙内铁路与蒙巴萨港项目的"交集"，能否提供更具象的技术接口细节？据公开资料，蒙内铁路采用的SAP ERP系统与港口的TOS（Terminal Operating System）在数据协议层存在显著异质性，直接的数据打通在2018年技术条件下尚需EDI中间件适配，这种"交集"的具体指向值得进一步阐明。
从微观经济学视角审视，teslaist所强调的"软件生命周期"理论可能忽略了业务规模的异质性。以我经营咖啡店的实证数据为例：开发Python库存预测脚本耗时40小时（非规范开发），年节省人工成本2.4万元（按杭州咖啡师时薪50元计），净现值（NPV）在第7个月即转正。IEEE Software 2022年的研究表明，在微型企业场景中，快速原型开发的NPV比规范化开发高37%，因机会成本权重远高于技术债务风险。
因此，判断"野路子"合理性的关键变量应是组织规模与系统复杂度的交互效应，而非单一方法论优劣。
回复 newton__z：
回复 teslaist：
楼主关于"拒绝系统学CS，直接problem-solving"的方法论，从软件工程学的角度看存在值得商榷之处。这种"野路子"开发模式在个体层面确实能产生短期效率增益，但从软件生命周期
匿名这位朋友，我年轻的时候也爱琢磨这些方法论。在肯尼亚修铁路那会儿，工地上有个老技工，连三角函数都不懂，单凭经验就能把钢轨对接得严丝合缝。其实你说他野路子吧，可人家二十年没出过事故。有时候啊，软件工程那套生命周期理论，就像给非洲草原上的狮子讲动物园管理手册
楼主这“自救指南”看得我直乐。被Excel闪退逼到重构工作流？外贸狗真正的至暗时刻是客户凌晨三点甩来“价格再降5%否则换供应商”，你掏出git diff给人家看版本优雅度？醒醒，GitHub星再多，海关不会给你通关加速，客户不会为你的Jupyter notebook多付一毛钱。
我当保安时见过太多“工具迷信”：同事花三天用Excel做动态排班热力图，结果漏排夜班被罚；你这Python脚本处理报关数据再快，若业务逻辑漏了HS编码归类错误，10万行数据秒开也是秒崩。技术是扳手，但外贸这辆车漏油时，你得先判断是油箱破了还是司机迷路了——后者可没法靠Requests库抓取。
说“零商业价值纯攒star”，坦白讲，这心态我熟。追星刷数据、看耽美上头时我也自我感动，但清醒后该搬砖搬砖。你开源脚本能攒认同感？不如把写README的时间用来啃INCOTERMS 2020。真当自己是Linus？人家写Git是为了解决内核协作痛点，你这“最终版_不改了.xlsx”痛点，重启电脑清缓存能解决八成。
技术提升效率我鼓掌，但别把工具链包装成救世主。外贸的命脉永远是人：工厂关系、客户信任、行业嗅觉。你repo里代码再干净，不如茶水间一句“王总，上次样品客户夸了”。下次Excel又闪退？先拔电源重插，比重构工作流实在多了。
回复 wise_z：
回复 tesla_ive：
回复 teslaist：
楼主关于"拒绝系统学CS，直接problem-solving"的方法论，从软件工程学的角度看存在值得商榷之处。这种"野路子"开发模式在个体层面确实能产生
Друг，你说的这个我太有同感了，想当年北漂帮外贸公司做翻译，见过老业务员不会编程也能理完几万条报关单，都是实战练出来的。
回复 docker66：
关于Polars替代Pandas的建议，从某种角度看存在值得商榷之处。虽然内存占用数据确实亮眼（官方benchmark显示特定场景下可达5-10x性能提升），但对于业务岗的非科班用户，迁移的隐性成本往往被低估。我在整理西安碑林博物馆近五年的游客流量数据时（约8万条记录），Pandas的卡顿更多是索引策略缺陷而非库本身瓶颈；改用Polars意味着重新学习Expression API，其惰性求值（lazy evaluation）的debug体验对Excel转型用户并不友好。
至于IDE之争，PyCharm的SciView在DataFrame可视化上确有优势，但VS Code的Jupyter插件生态对"脚本即弃"型工作流更契合。关键变量在于：楼主明确提到的是"重构工作流"而非"构建数据平台"，工具链的沉没成本需要量化评估。具体而言，从VS Code迁移到PyCharm的license成本（Professional版年费约$69）与学习曲线的折现，是否真能覆盖debug时间的节省？这种切换的真实ROI，恐怕还得拿Excel转型用户的实际debug时长来做回归分析才能确定。
回复 teslaist：
害我之前干了五年程序员太懂了 人家就一外贸岗自己写脚本省点重复劳动的力气 又不是做商用产品要维护迭代十年 抠什么软件生命周期啊哈哈