新人加入新创如何避免踩雷
新人加入大公司如何避免踩雷
老实说 有答案？
新创 和 大公司 不管是环境 或者 能发挥的影响力 或者 风景..etc 都完全不一样
人生这么短暂 都看看不好？
在新创练功完去大公司被电
难道大公司练功完去新创不会被电???
但
就如上面说明的 环境需求一堆都在不一样的基准点 那讨论谁电谁 有意义？
因为你可以找到一个例子 我也可以找到一个反例 那就代表你的论述是不一定会成立
最后讨论dirty code的问题
‘dirty code 存在 取决于 目前业务端的情况和属性 ’
对于连自己客户是谁都还不确定的新创而言 dirty code 我认为是有必要存在的
但不是100%的code base都是dirty code 而是有时候你必须要睁一只眼闭一只眼
我觉得 你既然要来新创 你必须要来了解新创的本质
怕热 就不要进厨房
这是心态没有调整好的问题
新创最重要的是什么？ 是生存，是找到客户付钱 好让公司和员工活下去
我发现很多从大公司过来的主管或资深工程师
很下意识的把他们之前在大公司的习惯带过来
例如 开发流程系统化 系统设计要严格 ...etc
但
创过业 或 待过早期创业团队的人 应该都会知道
老板知道前面有三条路 但真正是哪条 他自己也不完全确定
所以根据客户的需求更动 或者 甚至整坨功能打掉 在新创圈 屡见不鲜
在这种需求快速变动的情况下 做严格的系统设计 有时会造成 需求调整时的巨大成本
所以就会发生 BD会怪工程那么慢 工程会怪BD在那边乱改需求
到头来 根本原因 就是那些主导工程策略的人 自己不专业 还不自知
什么样业务规模 取决于下什么样的工程决策
没有BD面 管你系统设计在棒 根本毫无意义
所以不要怪老板 就是要快 dirty code也无所谓
因为他看的事情是生存问题
工程本来就是尽量跟BD面 配合 而不是起冲突
出社会也满多年了 很多事情 不管你在哪一个scale的公司
你面对事情 的心态绝对是最重要的 互相理解 互相站在对方的立场去想
努力做对的事 少抱怨
看到太多人 出社会很多年 自省的能力也没有培养起来 靠北靠母 都是They的错
然后这种人 最后 你会发现 很明显的就是自然而然 会在这个列车上
被多数人决定 放逐的人
结论
想加入大公司就去大公司 想加入新创就去新创
这世界的规则 就是
有些人特别幸运 有些人特别赛
考虑再多 老天爷一个突然安排 你还是无法控制
把自己的心态调整好 把 顺利 / 不顺 当作人生的风景 你只是过客
你会快乐多一些

dirty code 比较快我认为只是找借口掩盖自己能力不足而已没什么大小之分 只有强弱而已

没有CICD 怎么可能快得起来 没有测试 你debug花的时间你有办法评估？

你如果是要做B2B的生意，软件品质太烂在业界怎么生存？如果是被政府监管的行业，软件品质更要重视，quick and dirty都最后还是要付出代价

这东西也没办法量化 每个人快得方式不一样 大家都很快不过快然后 其他指标呢

有文件大家也确认规格没问题后 做起来才会快啊 所以我

省下的时间就是技术债，就跟大家买房通常会贷款一样

说大家快得方式不一样 没有订好短期验收目标的东西我不知道能多快 我是很慢啦

就算是 CRUD 前端一样要先知道怎么接 没文件只能通灵那你的这种新创 我没加入过 只能说辛苦了我也好奇变动这么快的模式 在业界很常见吗

新创需要的是快速迭代，不是陨石开发，如果需求一直毁灭那BD真的废

变动如此快 反正也只能是老板来扛起最后责任 那我避免加入这种公司

专案一直被陨石的，这个新创八成只是接案，哪里有钱往哪跑

接案就不能算新创了吧 我以为新创是有新的商业模式

然后会觉得CICD/测试是慢，根本就是写程式经验很菜

我的回复大部分是针对推文啦Dirty code 快 能够快多久？

回Moon大，接案公司也可能是新创可能是要开发商品但没啥资金烧只好接案过活看啥时有钱开发的公司

阿后来公司有做起来吗抱歉我是回此文 po

没，我已经逃出来了

新创感觉要加入拿到 A 轮后的 开始有稳定商业模式东西品质开始要求 不然 dirty code 我觉得对职涯发展蛮伤的但一切都是薪资问题 想到自己始终是打工仔就怀疑人生就你加入这种超早期新创的经验 有拿到超过 1% 的期权吗后来有行权吗非常感谢分享

认同原po，我也是有相同感觉！

新创其实应该找即战力,本身对feature就有过去的domainknowledge,而不是找菜鸟写一堆dirty code,在那边说文化如此如果新人进入新创就是学到dirty code,那以后只要新人问大公司还是新创该怎么选,新人一率大公司因为让新人写dirty code是为了公司生存,但对新人职涯并不利

前期需求会不断变动，又烂又快才是正确的，写再好都可能要砍掉重写所以要学着边写边重构，当然压力扛不住就是乱写，之后稳定后闲闲没事宁愿看股票也没心情填坑

公司面怎样是老板考量,员工要考量的是自己的职涯跟建议别人时,对方的职涯规划我的话中哪里有质疑为什么这时期的新创写dirty code对不对我的那边就是写下你的结论,新创这个时期就是dirty code再来新创做大这件事情回归台湾新创成功上市比例有多高案例不少,但看整体比例会是多高？

我目前只待过新创 不同意你的意见特别是我们新创被并购后 更是不同意现在新创被并购 有资源有人 结果拖慢整体进度的人就是我们带着这种dirty code time to market 但管理方法还在line用记事本 心智图截图法需求的老板现在并购 有jira 有ci cd 工程师也多 结果开个ticket现在还要请人开 不合理主观的需要求狂发 明明有一堆埋点工具不用老是听几使用者意见就带着团队花大把时间”去试”晚点回一片好了

十个新创九个雷可以调查一下新创的裁员比率有多高

完全同意这篇 我刚进来半年左右认为应该要把规矩订好 架构写好 但待了快一年之后 发现完全如同这篇所讲。不过我现在还是先尽量以能架构化为主 如果真的没办法就 hard code 或有点脏也没关系。这时 mongo 是个很好用的东西了 xd

我比较想知道开发途中有需求变更时，文件会怎样维护如果频繁的维护做白工的机率会很大吧

文件多多益善，解程式码问题才会顺手写测试改业务程式码

写 test 可以确保你写的东西可靠，速度慢我觉得是错觉，终究你都要想办法测你写的东西，形式不同而已。

不过会写dirty code的很大机率不用自己接后续维护多吃几次自己拉的屎后就会改进了

原po提的可以理解，但可惜的是很多case也是用这“说法”但实际上确不符合原po讲的情境

可理解但大家是不是忘了 dirty code 就是债而债是会拖累下次的开发速度的也许下次快 下下次呢 三个月后再回来改相关 code 呢如果公司快速成长又没文件当初写的人也走了那么新进成员在开发效率上势必会被拉慢

认同 dirty code有时只是时间成本的妥协 没有一定对错

有个极端例子就是均一教育平台虽然已经不算新创了但债爆到前阵子要上前后端社团征求志工处理

技术债本就是要还的 某些情况你不贷就直接倒 你贷不贷

处理的债的时间也是成本问题新创哪有不忙

dirty code 哪里有快, 是只能 dirty 来快的程度造成

新创有个特性，就是随时会 pivot ，烂 code 的技术债常常根本不用还，一 pivot 就整坨删除。关于文件的维护，最好的方式就是没有文件，然后做到程式码即文件，注解该写就写，commit log 认真写，这样就很够了。

dirty code要看程度，不会要求完美，但基本的一定要有

经验/能力不足才觉得dirty快的起来

dirty code不是不行,但不能一直用dirty code

dirty code的确很快 但只建立在不用还技术债的情形上

看 dirty 程度吧 有时候类似逻辑又还想不到整合 主管也会说先就保留两个版本 以后 feature 稳定再 refact

中肯文

不好意思给了个反推，自己待新创的经验是code quality太差反而到后期没办法快速迭待，也没办法快速scaleup. 重要的是MVP的观念，如何只做最重要的feature,尽可能把有限的资源做最大化而不是牺牲品质

如果能学会用标点符号更好

你戳破某些人的幻想泡泡了 XD

推 andykao，和我的经验一样，烂 code 一开始看起来很快，但实际上根本没办法应付不断新增和变动的需求。没 CICD 和自动化测试也是，烂 code 改 A 坏 B 是家常便饭，每天修 bug 就饱了。

写Dirty code很好啊,TMD别叫我接着去维护就OK

嗯 我发现我有点误会原po了 推回来

code常因为新创面向市场会被废弃掉的话, 那的确多个CICD没帮助一些极端情况不得不然

Dirty Code也分写的好不好的 写的好就是之后要改很容易不然一堆Hard code 最好是之后要改比系统化的容易

每个人的dirty code都不同啊XD 有些比dirty还惨

推。个人想法这篇其实重点不在细节执行面，比较像是在讨论新创不同发展阶段下的文化也好组织需求也好新创很多时候其实是在做POC概念验证，这时候的重点不在你用多漂亮的方法达到目标功能，而是这个功能符不符合目标价值，在这种情况下其实只要产品能动不要有大问题先验证功能能够满足需求满足价值，再来讨论怎样优化才有意义。 所以重点其实不是程式或方法脏不脏，而是如何尽可能用最小的资源去验证价值只是用最小资源的情况下"通常"程式或方法会比较脏而已

推

推

开发好像很快，结果脆弱的要死，技术债又一堆，越走越慢

这篇好！原原po不爽就嘘略失风度，小小格局有限。