大家晚安，因为本身没什么朋友在新创上班，自己也是第一次在新创
所以想在这边询问大家开发上的一些小疑问
开发环境是react.js + create react app + firebase
目前公司是MVP刚上线的状况还在补足一些功能
好让老板出去推销，尚未盈利也还没确认商业模式
不过在开发过程中其他工程师会提一些作法，说是为了未来着想
例如：
1. PR要merge的时候做Squash，因为这样git tree比较好看
2. function超过一百行，就想要拆出来
3. 完全遵照eslint的规范，任何warning都不能出现
4. 时常想回去重构程式
5. 想把所有异步的function都改成promise
6. 想导入TDD以及jest，让系统减少错误发生机率（目前没人会这东西）
7. 注解尽量删除，只留jsdoc，减少封装程式码
上面除了第六项其他都开始做了
不知道大家的公司的情况是怎么样
我没有想过这些东西的压力会远大过我思考服务架构的问题
这些东西让我觉得满烦的，没有制度化都是看个人喜好
可能哪天他看到一个别的觉得不错又要用了
还是说新创本来就是这样，可能我比较适合回去一般公司
这辈子第一次觉得写程式这么烦＝＝
作者:
xephon 2018-04-24 21:36:00这跟新创有什么关系?
职位一样，说过很烦，但还是会一直念到code改好为止因为我在一般公司没遇过,想说是不是新创技术人员都这样
作者:
Sunal (SSSSSSSSSSSSSSSSSSSSSSS)
2018-04-24 21:51:00这些都还好阿......
作者:
touurtn (vv)
2018-04-24 21:51:00这个问大家也没有用阿 难不成大家说好 你就会适应?
时程允许的话养成好习惯是好事，等真的推销出去想做更没时间了
这些都还好+1...不过新创有时间搞这些也是满神奇的
作者:
gn60311 (Peterman)
2018-04-24 21:54:00看时间允不允许比较重要+1,我的经验是刚上线的MVP应该是忙到没时间搞这个才对XDDD
作者:
Sunal (SSSSSSSSSSSSSSSSSSSSSSS)
2018-04-24 21:54:00比起这些 看到网络上一些新工具就急着导入还比较烦人MVP上线 补功能的时候 2 3 5 7也能同时做不是？
作者:
knives 2018-04-24 21:59:005 为什么不要直接跳await 就好，反正你都要重构了
刚起步的startup应该没时间管这么细才对XDDDD
大部分的新创真的都是这样子，然后，大部分的新创真的都会失败。FYI
作者:
othree (OOO)
2018-04-24 22:23:00await 也是接 promise 啊～ 这些我也觉得还好不过真的要说那个影响比较大，我会先从测试开始加上
作者:
ChoDino (Dino)
2018-04-24 22:24:00跟新创没关系，这些都说个人习惯的养成。
作者:
othree (OOO)
2018-04-24 22:24:00不一定要 TDD，不过有自动测试，未来改东西比较心安
楼上大错，这跟新创有绝对的关系新创TDD=To Die Die
这最基本...而且FUNCTION写到100行以上不拆真的是
作者:
naoomi (奈米)
2018-04-24 22:33:00新code可以照新规范但重构算了吧 新创先赚钱再烧钱r千行有点扯，可以看个clean code
作者:
ken1325 (优质水瓶男)
2018-04-24 22:34:00这家公司倒掉的机率高达87%
作者:
Argos (Big doge is watching u)
2018-04-24 22:36:00跟程式没有关系 先问 这间新创金主是谁倒不倒是看金主的
作者:
vencil (vencs)
2018-04-24 22:38:00好习惯可以养成，不过初期哪来的时间给他常常重构
作者:
vencil (vencs)
2018-04-24 22:48:00老板贷款活下来的也有...不过资金深度应该就...
作者:
Argos (Big doge is watching u)
2018-04-24 22:49:00哇 那就只好祝您 一路顺风 珍重再见 XDDD
作者:
vencil (vencs)
2018-04-24 22:50:00你的同事需要有认知，他想的未来可能远在公司的存亡线后了
作者:
mozume (米虫)
2018-04-24 23:01:00这些都还好吧，很多都只是习惯动作，eslint装工具不就好，test该写的部份还是要写，不然将来更麻烦
作者: WiseLin1125 (Wise) 2018-04-24 23:07:00
其实很难懂，为何新创总是喜欢先搞app…app很烧钱的…
你说的这种同事我有遇过，如果你有权力，请立刻开除他！有他在只是加速败亡！这种人只是在追求自己心中的理想世界，根本不在乎这个新创的成败可怜的是，新创很容易吸引这种败类
作者:
alihue (wanda wanda)
2018-04-24 23:21:00看环境，如果是用vs+c#，一个档案千行还是容易trace
作者:
lintsu (真闇の张钧法)
2018-04-24 23:23:00function 100 行要求好宽
作者:
NCUking (中大王)
2018-04-24 23:28:00工作十年了居然可以接受千行function XDDD
作者:
justben (BEN)
2018-04-24 23:30:00你是去上班吗 那就看谁比较硬 你比较强就不用鸟他没股份 没分红 新创这两个字也是唬烂而已 不用想太多
不是吧 他刚毕业 你毕业那么久了...怎还会有这种问题
作者:
NCUking (中大王)
2018-04-24 23:31:00不过程式码品质也要等公司活下来再考虑吧
作者:
justben (BEN)
2018-04-24 23:31:00回首才发觉 以前真的是帮公司想太多了 自以为老板 哈哈
作者:
NCUking (中大王)
2018-04-24 23:32:00阵亡了 程式再漂亮也没有用1到3没问题 本来就该有规范4在草创时期只是浪费时间5跟7要看情况6的话 TDD未必要实行 但无论如何至少有自动化测试程式不过产品上线才是第一优先
作者:
othree (OOO)
2018-04-24 23:40:00刚没仔细看，搞到 delay 是不好啦
作者: za755188 2018-04-24 23:43:00
我一个function 超过20行就觉得有点长了
作者:
senjor (哞哞)
2018-04-24 23:53:00public的方法里如果有不靠注解就不能懂的，就包成functionfunction的名字就命名成你想打的注解
作者:
guest0079 (SpongeBob SquarePants)
2018-04-25 00:05:00A大你怎么不出来嘴啊 说啥不照着规范做系统会不稳啊 要clean code啊 不然到时候程式会改不动啊 你怎么不骂po这篇的是写烂code的老屁股啊 怎么不幻想他是领底薪只会写简单网页的coder啊
function包的好 看的速度快很多又好测试 要改也容易
PR 不一定要 squash 而是不要 bug feature 喇在一起eslint 可以帮你抓很多typo的低级错误，code format可以改用 prettier 自动化处理重构的前提是有测试去防护
我的经验是能顺手做的就做需要多花时间的一律不做，你是满早期的新创就是要欠债抢时间测试市场，能不能活过下个月都是问题还在想未来根本无言。等到活下来有时间再重构还债简单来说早起新创不要求程式品质能动就好
但是不管是新创还是大公司 都要学着跟技术债和平相处也许在新创作这些边际效益不高，但也都是好习惯
我觉得你们应该要有个架构师或资深工程师来管这件事，新创老板贷款给工程师玩不熟的新技术？如果没delay一切好谈，delay就什么都不用谈啦
那我觉得你同事太激进要引入这些规范了 慢慢来比较好
作者: dnabossking (少狂) 2018-04-25 00:57:00
5跟7又不一定比较好
作者:
skizard ( )
2018-04-25 01:03:00认为新创不用先遵守3跟4 市场时机比较重要
作者: dnabossking (少狂) 2018-04-25 01:04:00
如果是全新的前所未有商业模式，我觉得不适合写TDD
作者:
Masakiad (Masaki)
2018-04-25 01:05:00还好啦 除了你上述的之外，我们还有coding style，function 行数30行内一堆规定。
作者: dnabossking (少狂) 2018-04-25 01:05:00
应该写BDD
作者: t64141 (榕树) 2018-04-25 01:16:00
很不错阿，如果能消化下来，可以借此养成一些好习惯
作者:
justben (BEN)
2018-04-25 01:31:00补充不用想太多的意思: 一个测试写一个星期也没差你有本事主导 你弄也没差 老板爽你有钱拿就好了吗? 公司成败不干你的事 不用去想那些 什么商业什么的都是幻觉 除非你有股份 有分红 或是其他东西 @@
作者: b004020018 (Rosalie Rabbit) 2018-04-25 01:55:00
人家想养的是个人能力啊 公司倒了他能活的很好的不会这样要求自己的工程师比较可怕...
其实除了4跟6之外，都是开发上顺路就能作，不需要多花多少时间的吧
作者:
x123356 (x123356)
2018-04-25 02:17:00所以这七点哪个具体拖慢了开发时程吗 看不出来欸是不是tdd先不说 不写测试你只是搞死自己做了十年了还不懂这点 你还真的只符合老屁股一点也许你适合回大公司养老 不要出来害人了
作者:
prag222 (prag)
2018-04-25 03:16:00function100行就想拆?业界要拆的不是都千行以上?
作者:
x123356 (x123356)
2018-04-25 07:59:00所以症结点在重构 是对系统有帮助的重构 还是单纯求好看如果是前者 是什么原因驱使必须重构 如果是后者 就挡掉菜鸟本来就容易为了重构而重构 资深人员应该阻止这件事
作者:
APTON (玮玮)
2018-04-25 08:13:00好奇问，你十年的经历中，都没写过测试吗@@？
作者:
a9564208 (YOU OUT!!)
2018-04-25 08:58:00我以为新创都是先上线再说...
作者:
aks (我白烂 固我在)
2018-04-25 09:17:00这些好习惯没养成 以后维护的人会更烦 眼光要放远 加油!
作者:
yongb (火系见习魔法师 )
2018-04-25 10:06:00请问是台北小巨蛋站附近的公司吗？
作者:
Ekmund (是一只小叔)
2018-04-25 10:22:00不错是不错 但怎么看都很花时程 能说服出钱的吗QQ毕竟是新创 验证概念能回本应该比扩展能力重要要是不赚 这么多初期投入不就吃土惹...虽然说就算公司倒掉 你有学到也ok啦...
作者: newways 2018-04-25 10:34:00
资金有问题还花时间在搞这些...赚到钱再请人重构阿
作者:
johnny94 (32767)
2018-04-25 10:39:00讲真的，这些都很重要没错，但你在新创阿连商业模式都还没确立，做这些只是工程师的自我满足而已。但如果你只是个打工仔，对这间新创也没什么热情，你就当累积经验 嘻嘻
作者:
deray (Deray)
2018-04-25 12:28:00你这个劣币
作者:
senjor (哞哞)
2018-04-25 12:39:00后来重新看看我的CODE，连超过30行的都很少 ww
作者:
chuegou (chuegou)
2018-04-25 13:18:00新创需求更改很频繁吧 现在就重构...是没其他事了喔...
作者:
frouscy (流浪吧。)
2018-04-25 13:32:00做这些和建置架构和解决问题没冲突R
作者:
art1 (人，原来不是人)
2018-04-25 14:14:00比较可怕的是没有写测试的经验却一直想重构
作者:
Ekmund (是一只小叔)
2018-04-25 15:15:00听起来你们老大有钱有闲 那就当赚到学学吧QQ
作者:
srwhite (鲁蛇阿白)
2018-04-25 16:31:00我倒很羡慕有制度的公司 不然每次改别人code都很厌世
作者:
TSW (翘班帝国)
2018-04-25 16:59:00大部分都是一些好习惯，虽然会增加工作量跟压力，但还是建议尽早适应吧。
作者:
Argos (Big doge is watching u)
2018-04-25 17:06:00没有什么差？开心就好 钱也照领 不是吗？XD
作者:
tsl3333 (我们都寂寞)
2018-04-25 18:35:00我觉得你同事观念很好 有机会绝不欠债
作者: ku399999 2018-04-25 20:30:00
4很难评断 但其他根本还好 什么好公司介绍一下？2 100行这数字也没什么必要连promise都懒得用写什么react...
建议以结果来论, 不管要怎么作, delay就是问题, 要嘛提早把要作的事估进来,中间再加而delay这很有问题然后你喜欢作架构,就把架构画好,彼此分工画清楚你的东西请他不要管,他的东西你也不用管只要彼此把承诺的接口作出来即可双向的沟通很重要, 同事间若无法沟通也无法尊重彼此就...请上级出来协调吧至于是他不沟通还是你不沟通看不出来,说不定他来po又完全是另一回事
作者:
Ghamu (猫丸)
2018-04-25 22:20:00说真的 有几点是基本职业道德吧？ func上百行code? 你他妈应该只有作者看得懂吧？
作者:
Argos (Big doge is watching u)
2018-04-25 22:49:00道德？等下楼上有人会回你 拎北出来是要赚钱讲啥道德？作功德吗？ XDDD最好一个func一千行 一个class一万行 整个APP只有10个class
新创绝对没有比delay更严重的问题 老板放任这样是有问题 建议还是勇敢跟老板沟通一下 请他出面解决
作者:
kinda (天天)
2018-04-25 23:52:00好公司介绍一下 找工作中~
作者:
sharku (明珠求瑕)
2018-04-26 00:18:00有个问题 他想重构的部分是谁的code?
作者:
upyours (hijos de puta)
2018-04-26 01:22:00不跳过promise直接await/async吗？
作者: jefflu 2018-04-26 02:01:00
我觉得都很合理耶 完全就是好习惯 这的大公司内部都说制度化 这些蛮正常的 你不喜欢反而是你的问题 其实你应该开心自己可以学到新东西跟好习惯推文乱了不好意思 大公司内部都有自己的规范 可能是全部也可能是某个组 我觉得这是必要的当然不是说全部的点 像100行是有点夸张 但整体来说是合理的
很多是为了避免技术债 你如果还过你就知道有多重要了XD
作者:
Argos (Big doge is watching u)
2018-04-26 09:45:00老实说啦 只是你不愿意学习而已 2 3 6 7这些做熟了根本不花时间 长期来看甚至更省时间 本来抓bug要三天现在只要3 hr什么新创不新创的也不是借口 因为其实根本不会慢那现在因为时间赶 你也大概不想学 我看就算了 他搞他的你写你的 不然就开履历囉
作者:
Ekmund (是一只小叔)
2018-04-26 15:09:002 3 4 5 6 都很花时间呀...从内文来看 并不是从头做是把旧有的打掉 顺便导入没人试过的新开发流程光错误尝试和测试就不晓得要绕到哪了当然新的东西进去时 最好遵照新的规则走会想重构一定有原因的QQ
作者:
Argos (Big doge is watching u)
2018-04-26 19:29:00改旧的 拆func跟删注解哪会花啥时间啊....？到底？新创产品是有多庞大？一周能不能做完？说不定三天就OK了
7不一定是好事. 有时有些功能近似的function, 在A,B,C都有做某事而在D选择不做的话, 会在那行附近写原因在JavaDoc写的话compile后外面的人会看到因此不会在那边写, 就样release版的错误信息不该有implementationdetail一样
作者:
KanoLoa (卡)
2018-04-29 14:18:00是你习惯不好啊 重构你的釦才拖慢大家