Programmer Misc

https://www.quora.com/Why-do-you-need-a-big-screen-for-programming

And it doesn’t stop there. Especially if you are debugging graphical applications it really really nice if you can have the app you are debugging on a separate screen. It’s kind of annoying if you constantly have to switch windows back and forth and back and forth ……

Programming is about reading things three times as much as writing.

If you are a programmer, you usually have the following open at work

a) The IDE
b) A window in which you test your application
c) Web browser to look up online resources. Also, to keep track of CI/CD builds
d) Email client
e) Chat application

Out of these a) b) and c) need to looked at frequently. Frequentlt switching screens can he headache-inducing. Also, the bigger the IDE screen, the better. The more code you can see at onetime, the better it is to visualize it working in your head.

https://mp.weixin.qq.com/s/heFyKmlmhYz2dzCgPzRUiw

和大部分 app 一样，猿题库最早的时候使用的 MVC 架构。这个朴素的架构在早期发挥了他糙快猛的优良作用，但很快就把我们的 app 变得异常难维护。一个 VC 里面最长有 1k5 行代码，这对我来说是非常难以忍受的。

思考很久之后，秉承最小表现力原则，在尽可能不增加架构复杂度的基础上，心里默念没有什么问题是不能通过加一个中间件解决的思想，在原来的 MVC 架构上，增加了一些分层，使得各层的职责更明确，解耦更彻底：

M-S-DC-VC-VM-V
Model：数据模型
Service（Agent，ModelDataController）: 数据逻辑
DataController: 界面逻辑，和 VC 一一对应
ViewController: 控件布局和一些胶水代码，和 DC 一一对应。
ViewModel：控件展示 Model
View: 控件

我认为，架构的目的首先在于统一，然后是效力。这个架构比起当时业界流传的各种新架构，最大的优势就是非常好理解，非常好实施，推广和切换的成本非常低。本质上来说这就是一个 MVC 的变种，没有双向绑定，没有不可控的第三方库，没有难以理解的概念。我在团队推广这个架构不到半年时间，就已经把项目里的大部分代码都切换到这个架构

https://juejin.im/post/5949ea4aa0bb9f006b0588df

•低效研发体系：把技术团队简单当资源使用，简单的任务派发。为什么要做这个需求，需求的价值是什么一概不知。
•高效研发体系：让技术团队觉得是在一起做一件有价值的事, 讨论清楚需求的前因后果。每次需求上线后，需求的效果有完整的数据跟踪，根据数据来总结本次项目的得失。
•低效研发体系：业务，产品和技术的观点不在一个维度上：业务的观点在业务拓展、收益上；产品的观点在需求、产品功能上；技术的观点又在产品特性，功能实现上。
•高效研发体系： 大家都聚焦在一个点上：”SHOW ME THE MONEY”，大家的沟通思路都围绕在提升产品收益或者降低营收成本，技术的所有工作都应该紧密围绕“提升收益”和“降低成本”这两个方向。
•低效研发体系： 需求评审会上，业务和产品唱“独角戏”，技术同学没有自己的想法。
•高效研发体系： 在需求评审会上，产品和技术会明确需求是否完整，确认产品功能的正常场景，是否形成闭环；异常场景的处理流程；产品细节是否考虑周全。