> Skim：浏览，有「 Read Quickly 」之意，希望能提供给用户高效的信息阅读体验。

我自己开的阅读器坑，也取名叫 Skim 。/握手
还没精力动手做，只整理了一些需求和信息，供参考： https://github.com/users/HuangJian/projects/1

核心问题：职权错配。
OP 现在相当于顶着「技术总监」的头衔，做半个「架构师」的事（只做规划，不推实施）。

建议解决方案一：主动要事要人要权，做真正独当一面的技术总监
精心准备一个工作汇报，跟大老板谈公司的机遇和问题（机遇为主，问题为辅）。
详细论证如果保持当前的技术管理体系，机遇将会如何错失，问题将会如何延续，新问题将会怎么发生。
提出自己的解决方案一二三，分别要做哪些事什么资源多长周期，在哪些里程碑节点可以达到什么可观测的质效指标。
如果大老板认可你的方案，就必须要给事给人给权；如果不认可，说明你与大老板的认知规划严重不符，早谋退路吧。

建议解决方案二：低调做事盘人谋权，以技术收复管理
既然什么资源都不给，那就别做中长期规划了，先把推到你手上的技术问题解决掉。
但要注意，这些问题不要大包大揽自己全部搞定。
每个问题，都带一两个小弟小妹一起做，美其名曰「传帮带」，共事时用你的经验技术人品征服他们。
要人了肯定会和产品规划的项目节奏有冲突，找准机会小吵几架，逐步谋取排期/分任务/打绩效/招人权。
如果能撑个一年半载，研发团队里人听你的事归你管了，自然而然就从产品团队里独立出来。

---
关于大老板：既然招了你进来，肯定是对现在的研发产出不满意。看你如何向他传递「破而后立」的思路了。

关于产品老大：你来了相当于分掉他一半的职权，从你行文来看，我不倾向于他会真心配合你开展工作，没必要舔。

关于研发组长：不知道研发团队规模，如果少于 15 人，这个岗位可以撤掉，你直接管理整个团队；如果多于 20 人，建议分成几个十人规模的小组，分别设一个研发组长向你汇报。

MBP 15' Mid 2015 ，A1398 ，官方免费更换一次的电池，使用三年后再次鼓包。

去年六月初 DIY 更换了京东买的绿巨能电池，实付 318 元。
作为生产力工具和主力娱乐工具，每日使用约 10 小时，其中拔电使用 2+ 小时。
用到现在体验良好，未感觉到与原厂电池有差别。

使用 [bclm]( https://github.com/zackelia/bclm) 设置最高充电至 90%，现在的使用情况：
Charge Information:
Fully Charged: No
Charging: Yes
Full Charge Capacity (mAh): 9289
State of Charge (%): 84
Health Information:
Cycle Count: 158
Condition: Normal

赞同楼主的想法！

我上半年做一个 STM32 的小板子开发，开发流程体验极差，效率很低：
- 没有支持 macOS/Linux 的工具链，需要远程桌面连接到 Windows 系统开发调试；
- 在 VSCode 上写代码；
- 用 Kail μVision 编译烧录；
- 用图形化串口工具 debug 。

主要痛点：
1. 没有跨平台的工具链；
2. Kail μVision 的开发体验过于远古；
3. VSCode 设置为普通的 C/C++ 项目，有些头文件没有包含进来，会提示编译错误；
4. 不能在命令行里编译/烧录/调试；
5. 串口工具不支持脚本自动化；
6. 项目配置麻烦，用不上 makefile 、gcc/llvm 编译选项、linter 、单元测试……

前段时间也动过折腾一个基于 VSCode 的跨平台开发工具链的念头，因为懒，调研了一些材料就搁置了。
- https://github.com/glegrain/STM32-with-macOS
- https://github.com/bbrown1867/stm32-makefile
- https://github.com/adamheinrich/cm-makefile
- https://www.davidrojas.co.uk/stm32f3discovery-on-mac-os-x-using-eclipse-gcc-arm-and-openocd/

如果 OP 打算以开源项目来推进这个想法，也许我能一起做些贡献。

Append：

我司目前开放的岗位，均需要不定期到办公室工作。
所以我们更倾向于和定居合肥的人才合作。

纯远程的合作方式虽然也还可以商量，但是需要是极其合适极其匹配的人才会考虑。

在面试过程中，我可以就这些内容引导面试官展开深入讨论，比如：
- 如何发现这些冗余代码的？ → 静态分析、代码覆盖率
- 如何保证删除代码之后系统仍然正常工作？ → 单元测试
- 为什么以前的系统性能那么差？使用了什么优化技术？ → 算法复杂度分析、C++内存管理
- 如何比较优化前后的性能？ → profile

能把握到这些亮点的面试官，肯定也对这些工作内容的过程和难点充满兴趣。

@wintercoder #37

PS. V2EX 的回复系统有问题……按回车就直接发布了。

在面试过程中，我可以就这些内容引导面试官展开深入讨论，比如：

> 比如「第二周开始优化重构老系统代码」、「负责「数据输入」模块的设计和开发，带领两位同事使用 C++重写 VB 老项目」 面试官可能会觉得重构很正常，没啥好问，但实际上里面遇到了难点，但简历没提

后面紧跟着的数据描述，「一个月内删简 4000+行冗余代码」和 「数据输入性能提升 90%」，就为后继面试埋下了伏笔。在面试过程中，我可以就这些内容引导面试官展开深入讨论，比如：

Chrome 上碰到过同样问题。

解决办法：Developer Tools 里，清空 Application 下的所有项目。

https://github.com/jorgef/engineeringladders

- Technology: knowledge of the tech stack and tools
- System: level of ownership of the system(s)
- People: relationship with the team(s)
- Process: level of engagement with the development process
- Influence: scope of influence of the position

---
如果非要凑够六个维度，也许可以加一项个人成长向的，比如自驱力？

@lamls #11
@orangy #12

我碰到过几次冬天早上无法唤醒的情况。原装电池，晚上室温大概 0~5°。
要充电几分钟才能开机，开机进系统显示电量 0%。

所以我怀疑「天冷掉电」是电脑锂电池的通病，不是第三方电池的锅。

我的处理方法：冬天夜里把 MBP 放卧室里（室温 > 10°）。

同 15’ MBP 2015 ，三年前通过苹果官方的电池召回计划换过一次。
https://support.apple.com/zh-cn/15-inch-macbook-pro-battery-recall

今年 8 月份发现又开始鼓包了。
苹果不支持再次召回了：「 您输入的序列号不符合这项计划条件。记录显示，您的设备已通过这项计划进行了维修。」

现在机器除了发热厉害点儿，日常使用需求都能满足。迫于穷，还想再让它继续服役一两年。

想问一下 OP 换的是什么品牌的电池，什么价位？
后继使用过程中如果有啥问题也希望 OP 能持续更新。
谢谢。

建议参考头部玩家的技术选型，比如 Discord 的数据库迁移历程：MongoDB → Cassandra → ScyllaDB

《 How Discord Stores Billions of Messages 》
> In July, we announced 40 million messages a day, in December we announced 100 million, and as of this blog post we are well past 120 million.
> The messages were stored in a MongoDB ……, we reached 100 million stored messages and…… see the expected issues appearing: the data and the index could no longer fit in RAM and latencies started to become unpredictable.
https://discord.com/blog/how-discord-stores-billions-of-messages

《 Discord Chooses ScyllaDB as Its Core Storage Layer 》
https://www.scylladb.com/press-release/discord-chooses-scylla-core-storage-layer/

> 重点来了，这次面试一开始面试官看完简历，就告知我他们做渲染图形方向的，好像不太匹配，问我要不要继续，我直接就拒了。全程持续 2 分钟。

一方面，面试官在面试开始前竟然不读候选人简历不针对性预设讨论内容场景，极不专业；
另一方面，方向不匹配 HR 也要联系面试，极不专业。

感觉字节（或者该部门？）的招聘流程极其混乱与傲慢，浪费人才时间精力。

感觉 Kotlin 是我用过的最舒服的语言。最喜欢的几点：
1. 语法糖: null-safety, lambda, `val`, standard library
2. coroutines
3. 设计好 DSL ，写代码犹如写文章
4. 全端开发

我最近一次写 kotlin 代码大概是两年前，印象中有这么一些劣势／限制：
1. 语法过于灵活很容易放飞自我， 普通开发者难以消化大量的 let/apply/run/also 和 filter/flatMap/associate/groupBy
2. 除 Android 和 backend 外，其它端的工具／生态／社区还是不够完善，能用但不够好用
3. 编译速度慢

基于以上因素，我建议只在独行侠项目中使用 Kotlin 。
如果能在团队中成功应用，也许需要是业界 top 10% 精英组成的超级团队。

@vczyh #37

> 情况 1：查询用户，带出对应的订单（造成 User 依赖 Order.getListByUserId(long userId)接口）
> 情况 2：查询订单，带出用户的某些信息（造成 Order 依赖 User.getSomeInfo(long userId)）

用户模块属于最基础的模块，不应依赖于其它业务模块。考虑两种情况：
1. 如果用户模块依赖于订单模块，那么添加支付功能就会依赖支付模块，添加消息功能就要依赖消息模块，最后用户模块就会成为一个「巨无霸类」，无法维护；
2. 如果把用户模块和订单模块拆分为独立的微服务，那么用户微服务里不应保存订单信息，所以用户模块也不应依赖订单模块。

回到「情况 1：查询用户，带出对应的订单」的问题。
从产品业务分析，我觉得这是标准的「基于用户 ID 查询订单」功能，应该由订单模块独立提供 API 接口和服务。
web/app 端拿到用户 ID 后调用这个 API 接口即可。

@20015jjw #12
@janus77 #22

似乎二位没有读完「 TL;DR 」的内容。

为了避嫌「躲闪回应关键问题」，我还是回复一下吧。
----

> 说白了就是没面满意 他就觉得你值这么多 你以为大家都闲着喜欢面着玩 浪费钱吗

没面满意就直接告知「本轮面试没通过，是否考虑我们的 xxx 职位？」，应该不难吧。
何必继续走完招聘流程浪费彼此时间精力呢。

> 至于压价，哪家不压价？段子上面写的“面试 10-20k ，实际就 10k”你以为仅仅是个段子吗？

我的情况是「面试 10-20k ，实际就 5k 」。
这已经不是压价的问题，说严重点叫招聘欺诈。
如果能以沟通职位的薪资下限发 offer （虽然竞争力不大，我不会接受），我也不至于对 HR 意见这么大。
----

如果两位觉得「未及职位要求，不告知应聘者，以低职级岗位完成面试及薪资调查流程」是合理的行为，那就好吧「您说的都对」。