※ 引述《wandallin (万大林)》之铭言：
: 大家晚安，因为本身没什么朋友在新创上班，自己也是第一次在新创
: 所以想在这边询问大家开发上的一些小疑问
: 开发环境是react.js + create react app + firebase
: 目前公司是MVP刚上线的状况还在补足一些功能
: 好让老板出去推销，尚未盈利也还没确认商业模式
: 不过在开发过程中其他工程师会提一些作法，说是为了未来着想
: 例如：
: 1. PR要merge的时候做Squash，因为这样git tree比较好看
我自己是没意见，因为懒，但我会照做，这没什么好争论的，管专案时程与掌控
细节的人有需要的话，这种程度的overhead 可以吞
: 2. function超过一百行，就想要拆出来
我是写Java的，即使是古早时代写Eclipse Plugin那种超复杂的Desktop GUI Program
我都可以压在50行内，到目前为止，只要是‘程式码要持续维护超过半年’的情况，
我看不出有任何借口一个Method可以超过100行
: 3. 完全遵照eslint的规范，任何warning都不能出现
: 4. 时常想回去重构程式
我的重构发生在：
1. 那个地方已经变成Error Prone，照三餐来烦你，不修整就是天天给他出代志
2. 加新功能，重构本来就是‘新功能实作’的一部分，把原本的结构锯掉一块然后硬插
东西上去就说新功能做好了，这算哪门子做好？这样搞的人到底是在抢功劳、讨好老板，
还是好好做事？明天要Demo那我没话讲，但这不会去说它做好了。
3. 可以预见未来会有很多地方都依赖这个部分，那就是照三餐做重构，特别是API的切
分与命名，doc要补齐，当然我说的‘很多’，指的就是至少三个跨instance的Module
4.重构绝大多数不是改架构，通常只是把责任切分清楚，让该在一起的在一起，一段
程式码不要同时得考虑太多不同层次的业务与工程需求，当然这有能耐的问题，对我来说
开个interface透过polymorphism把service内不该看到的东西遮掉，把合约订清楚是了
不起一个下午的事，但有些人就是会用上两天，那就是自己能力范围内做好
: 5. 想把所有异步的function都改成promise
我不晓得你的语言环境这块是不是已经很成熟，Java的话是没啥好谈的，我知道的就至少
有三四个成熟的方案能选，用哪一个都可以，自己的玩具程式还是测试才会用Thread硬干
选择的重点在于程式码是用在什么场景？简单的问，就是你是开发自己的App？还是开发
给人用的lib、甚至是framework？
这个程式码会跑在哪几种container里？
Servlet? Android? Spark? Spring? 凡是有Component lifecycle的都要想一下他所处的
环境的水电基础能不能支援这种接口
然后测试是重要的，如果你决定让自己的interface去依赖别人开发的lib，这种async的
东西测试用的utilities、await()该做的都要做
: 6. 想导入TDD以及jest，让系统减少错误发生机率（目前没人会这东西）
大部分pure code我是不写测试的，我认为静态强型别的语言使用要义，就是透过型态
约制与meta programming，利用compiler 与IDE来帮开发者预先纠错，会搞TDD只有在：
1. 核心逻辑复杂度极高，比如说开发DSL Interpreter、rule engine等需要用上finite
state machine的场合
2. 重构写太脏需要大清扫的程式码的时候
有side effect的程式码我写测试粗分三类：
(随便写，不然认真写下去不晓得多少字，叫qrtt1来补好了)
UI、Persistence、Downstream portocol
UI我个人经验(偏见)是：他基本没救，搞那种起虚拟环境去按键精灵的成本非常的高，
startup还是认命自己点吧，要稍微有救一点的从E2E test开始，前提是model view
presenter的view abstraction不能偷工太多，不然protocol不清楚的东西测试也是乱写
Persistence的测试除了效能测试以外的都是在确定异质系统(DB, HDFS, 其他)是不是
如同你想像的，把DB或File System Mock掉的测试是没什么意思的，除非在测异常处理
逻辑
Downstream portocol一般就是有切Micro Service，上下游都是同一家人写的，也
就是两造间该怎么讲话还有乔的空间，通常这些测试就是真正的规格，可以拿来画押、
拿来当教学、拿来保证重构完不会死人
即使是startup，测试异常与正常的比例经验上也至少得2:1到5:1，完全只考虑happy
path那是明天要给大客户做demo才这样搞
最能写code不会错的人，都是预先知道要测该测哪里的人，那人要怎么知道该测哪？
就是平常写够多测试写出心得啊，不然难不成靠掷杯吗？
这就是我说的：‘平日经常练习举100KG，今天突然要赌110KG才有机会’的意思
: 7. 注解尽量删除，只留jsdoc，减少封装程式码
每个function body都小于30行，就会发现注解就是method signature，重构等价
于写注解
: 上面除了第六项其他都开始做了
: 不知道大家的公司的情况是怎么样
: 我没有想过这些东西的压力会远大过我思考服务架构的问题
: 这些东西让我觉得满烦的，没有制度化都是看个人喜好
: 可能哪天他看到一个别的觉得不错又要用了
不试肯定不行，连SI都会试了startup还不试那是要拿啥赢别人？
一直乱试当然也不可以，这是在做生意，不是在玩
拿捏这之间的分寸就是tech lead的价值，看老板的眼光一部分就是在看这个
: 还是说新创本来就是这样，可能我比较适合回去一般公司
: 这辈子第一次觉得写程式这么烦＝＝
凡事总有第一次的，习惯就好