@kop1989smurf #9

> 技术合伙人和其他高管不同，他的最大价值很大程度上只存在于企业初创期。
是的。文中技术男取代号「沃码农」，其实就是类比苹果的沃兹尼亚克。

> 如果 CTO 的权利过早保障，那么很大程度上 CTO 的利益方向就会与资方、CEO 方面不一致。
同意。所以沃码农建议借鉴行业惯例。但是库克星并不了解或者不认可互联网科技公司的惯例。

@westoy #7

> 野生创业者和投资人的追求存在根本分歧
同意。沃码农在前几轮交流中也试探了几个潜在伙伴的思路。

一方面，乔帮主和瓦天使间分歧不大。
乔帮主曾是瓦天使上市公司创办时的顾问和高管，合作两年后为全身心耕耘社会事业而选择离开。
（乔帮主的精神和执着，是沃码农愿意参与创业的首要原因）
瓦天使的公司业务与这次创业机会基本无交集，他的天使投资更像是想帮助挚友实现人生理想。

另一方面，库克星就表现出纯粹的生意人态度，夸夸其谈的都是要占据多少个市场实现多少营收以多少估值再融资几年内上市。
以他的风格大概率会导致你提到的分歧。但是乔帮主就是那么放心地让他负责公司运营和资本运作。

@qeqv #3

总结到位 👍

股权退出机制算是三个根本矛盾之一吧。
另外两个是潜在的运营理念分歧和工作习惯磨合风险。

股份方案如果能谈妥的话，另外两个还可以尝试去妥协磨合变革。

@bcql #1

> 所以最终是一拍两散了？
是的。

后继库克星就非常冷淡地回应沃码农的消息，包括沃码农最后整理的思考和建议（因为认可该事业的社会价值，希望它成功）。
这应该就算是「礼貌性回绝」了吧。

楼主提供的信息太少，感觉更像是感情宣泄。
网友就算想帮忙回答你的问题，也很难匹配到你的关注点……

> 我现在自学 java ，零基础
「零基础」是指没有学习过任何计算机科学课程？还是有别的语言基础只是没接触过 java ？

> 生活压力很大，一边学习一边工作，还要养家养孩子
每周能有多少时间放到学习 java 这件事上？预计能坚持半年还是两年？

> 为了能多赚点钱，学习 java ，希望薪资高一些
现在收入是什么水平？期望掌握 java 后达到什么水平？

> 你们觉得我还来得及吗？
码农入行对外部资源依赖很少，主要靠自己努力。
如果有决心有毅力家庭支持，任何时刻开始都是来得及的。

但仅从楼主行文信息来看，转行码农的成功率可能不会太高。
如果真正零基础，按最佳情况去分析的话，我猜测你需要两年左右时间才能真正入行：
1. 半年左右自学啃一遍计算机科学教程（或培训班课程）
2. 找一个小团队 996 一年，学会看需求写代码改 bug 发版本（一线城市也许能拿个 8k~10k/m ）？
3. 换一个稍微有些规范的成熟团队，自我革命半年学会团队协作开始追求质量（一线城市也许能拿个 12k~15k/m ？）
4. 如果没有非常好的境遇，再过三四年可能就到达码农生涯的顶点了，当个小 leader 吵吵架摸摸鱼（一线城市 < 30k/m ？）

我们家逢年过节送礼都是这么操作：

1. 老婆选好加购物车，我来支付；
2. 娘家婆家同样配置一视同仁。

> 10 分钟 20 万人和 4000 医护在线
按这个数量级，并发数 1k 都不到，算不上「高并发」。
系统设计的好的话，单机 16C32G 带数据库都能撑住。

不了解 PHP 生态，但是作为一个主流成熟的框架，laravel 不至于连 1k 并发都撑不住。 → 不建议伤筋动骨换开发框架。
---

盲猜这些问题是设计开发没有质量管控，代码堆叠错乱导致的。
临时方案：先上个应用性能监控工具找出性能瓶颈吧，New Relic 或者 SkyWalking 之类，根据监控数据针对性地做优化、测试、压测。
长期方案：建立系统的软件质量管控体系。

@nnegier #218

县城高中老师的利：
1. 出身教师家庭，熟悉和喜欢校园环境
2. 能传播知识和见解，满足自己好为人师的习惯倾向
3. 生活安逸，可能有充分业余时间继续发展爱好
4. 在当地能形成一点人脉，也许能照顾大家庭

县城高中老师的弊：
1. 年复一年作固定知识的简单重复，无法满足求知欲和事业心
2. 八线县城，交际面很难获得思想共鸣和新事物的冲击
3. 体制僵化，外行领导内行，大学里都不能教授治校，何况高中
4. 天花板低，要获得职业突破免不了挤去一线城市或者省会城市，但是回去了再想出来更难

我应该会尝试做一个高中老师。

10 年前在国企煎熬的很多个不眠夜里，我就非常严肃地思考了回高中母校教书的可行性和利弊。

不过后来投身「自由职业者」后就不再有这方面的烦恼了，哈哈。

@evilStart #19

确实是反面案例，用以佐证我的观点：
自动化检测工具需要支持本地化运行，最好有 IDE 插件实时检测；如果只支持云端检查非常影响开发效率和体验。

@wu67 #13

你举的「逻辑写法」内容应该也能工具化规范化解决。

> 遍历数组都能写出 7 8 种写法
eslint-plugin-github 有 "Prefer for...of statement instead of Array.forEach" 规则。
https://github.com/github/eslint-plugin-github/blob/main/docs/rules/array-foreach.md

> 还有在非变异方法里面通过引用改变原数组值的
似乎 eslint 的 no-param-reassign 搞不定这种情况，要上 typescript 的 readonly T[]
https://eslint.org/docs/2.0.0/rules/no-param-reassign
https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html#improvements-for-readonlyarray-and-readonly-tuples

---

有些代码规范的工具化，需要引入新工具甚至新语言（ javascript → typescript ），成本不菲。
这就引申出进一步的问题：如何平衡代码规范和开发体验？

引入代码规范最好能循序渐进持续增强，切忌大破大立，很考验领导者的平衡艺术。

@ChefIsAwesome #11

> 可实际上，你问他们，怎么写出来不像屎一样的代码，他们根本不知道。
是的，这对很多团队来说属于 "unknown unknowns"。
即使感觉到了痛点，也总想走捷径，不愿意花精力去学习了解（就像我的巨子同学）。

> 只可惜“如何写好代码”，学校不教，面试不问，工作不查。
哈哈，我面试的最后一个问题都是「对于提高团队的整体代码质量，你有什么经验和心得？」。
进而引出对源代码检测、单元测试、code review 的讨论，判断他的技术追求和团队适性。

@l00t #7

你是说直接复制粘贴第三方源代码进项目的情况吧？

两种处理方式：
1. 所有第三方源代码文件置于一个特定目录，在工具里配置不检测这个目录的内容。

2. 粘贴复制后修改使其符合规范
2.1 粘贴复制 git commit -m 'Add a class for xxx, copied from https://xxx'
2.2 修改使符合规范 git commit -m 'refactor it to follow our code style'

@FrankHB #3

你的关注点已经是「规范的合理性」了，这通常是精英级团队才会考虑的问题。
精英团队完全可以自行裁剪组合甚至新建能符合自己团队项目情况的规范。

对于平均水平团队，初次引入「代码规范」的情况来说，有规范总比没有规范好。
不喜欢 google style 可以找找别的。

@jorneyr #4

> 规范定制容易，怎么执行才是核心。

非常同意。这也是我再三强调自动化工具及持续集成的原因。

员工可以就使用过程中的不便提意见，需要带明确的反对理由、业界实践、修改建议。
未被采纳前就要按现在规范严格执行。

@fengzl #1

已修正，谢谢提醒。

赞美 OP ！

建议：增加「 N 日最多感谢回复贴」的筛选功能
https://github.com/v2hot/v2hot.github.io/issues/5
---

很多时候回复贴比主贴价值更高，特别是感谢数很多的回帖。
但是现在 V2EX 原生的内容组织形式似乎没有办法挑选出来。

如果 v2hot 能实现这个功能就太好了。
或者简单一点，在 top 热帖里增加显示合计感谢数？