articles
articles copied to clipboard
zhengguorong
蟹老板的小经验
**为什么企业中管理模式分为等级管理和扁平化管理呢？这两种模式优缺点在哪里，在哪个阶段应该采取哪种模式？**   书中作者认为，等级制度能够让社会团队的行为具有高度的一致性，但是过强的等级制度可能会限制底层个体的创造力，很可能会扼杀明知的思想。根据需求灵活地运用等级制度，可以提升一个团队的整体竞争力。作者发现，在强等级制度的约束下，天才多了反而会影响团队的整体战斗力，因为他们会相互竞争，使效率下降；在弱等级制度的约束下，天才成员就越多越好，因为他们基本都是独立表现，不太依靠他人。   我个人认为，在团队创建初期，可以形成一定的等级制度，例如一名技术比较资深的开发担任主管角色，管理6个人以下开发团队，同时因为组织赋予了资深开发一定权力，他可以利用该权力较方便的制定开发规范，代码审查，开发流程等。   如果一开始团队都是资深的开发，没有等级制度的加持，可能会造成谁也不听谁的局面，代码风格各种各样，维护成本将极高，同时损害合作关系。   团队成熟后，可以采用扁平化管理，充分发挥团队成员的创造力，因为负责该项目的成员，最清楚他的项目，也最清楚他的客户，此时对其权力下发，对项目开发会有较大好处。   目前B公司实行严格的等级制度，虽然能够快速执行上级的命令，但是创造力严重缺失。在目前同质化严重的市场环境下，未能对客户作出快速响应与定制化市场营销，造成发展滞后。   在人才管理上，因为采用等级制度，员工较多时间在执行上级命令，导致个人成就感偏低；同时薪酬因等级的限制，员工工作几年后，未能升迁，就会产生人员流失。
最近因为需要实现衣物识别，需要大量不同衣物的图片。 爬取淘宝/京东的产品图片应该是最快捷的收集方法。 #### 第一次尝试 开始的时候，打算通过分析淘宝链接规则来提取页面信息，但是淘宝的URL比较复杂，计算按页面的URL请求，返回的也浏览器访问的dom结构不一样，加入请求头也没用，所以选择放弃。 #### 换一个方法 capser是基于phatomjs封装的更高级的库，平时可以用来做自动化测试等等。 反正就是模拟一个正式的浏览器访问环境，获取dom结构，分析URL，提取图片啰。 #### github地址：https://github.com/zhengguorong/productPic 还是直接看代码吧，详细解释看注释 ``` // 抓取图片的宽高 var imageSize = '_200x200' // 抓取的分类 var queryKey = ['棕色 衬衫', '棕色 t恤', '棕色 外套',...
### 简介 **Rollup官方解析:** Rollup 是一个 JavaScript **模块打包器** ，可以将小块代码编译成大块复杂的代码，例如 library 或应用程序 **webpack官方解析:** webpack 是一个现代 JavaScript 应用程序的静态模块打包器(module bundler)。当 webpack 处理应用程序时，它会递归地构建一个依赖关系图(dependency graph)，其中包含应用程序需要的每个模块，然后将所有这些模块打包成一个或多个 bundle。 ### 应用场景对比 **使用Rollup的开源项目：** - vue - vuex - vue-router **使用webpack的项目：**...
由于最近在开发前端日志监控系统，对接口负载有较高的要求。 我们需要模拟高并发的环境下，接口承受的最大负载。 后端接口使用nodejs部署，服务器为1核2G腾讯云。 如果是ubuntu系统，可以用下面命令安装 ``` sudo apt install apache2-utils ``` ``` // 下面为输入ab后的帮助命令 Usage: ab [options] [http[s]://]hostname[:port]/path Options are: -n requests Number of requests to perform -c concurrency Number of...
上篇文章说到用ab做压力测试，单台服务器出现cpu瓶颈。 为了提高并发，可以从两方面扩展，纵向扩展（提升单台服务器性能），横向扩展（增加机器）。 纵向扩展，成本是比较大的，而且容易到顶，随着业务增加，还是撑不住。 所以我们要做分布式方案，这样可以随着业务扩展，租用更多机器来扛住压力。 目前软负载比较简单的方式就是用nginx了，当然你也可以硬负载，不过我没接触过，只是听过而已，据说很贵。 那我下面就介绍nginx配置方法。 我两台机器配置都没1核1G内存。 直接看nginx配置吧 ``` upstream backend // 这个名字随便起，用于下面做反向代理 { server 10.104.136.40; // A机器的地址 server 10.104.243.10; // B机器的地址 } // 监听80端口，做反向代理 server { listen 80 default_server;...
由于最近换了新工作，新公司的代码在结构和规范上都不是很好，于是希望后续通过重构来优化代码。 但是重构的标准是什么？什么才叫好的代码呢，如果单凭经验，容易陷入个人喜好主义，那和之前的代码有何区别呢？也许别人看你重构的代码也和你现在看别人代码一样呢，这样不就变成一个死循环了吗。 因此，在重构前，我觉得有必要阅读相关资料，寻找理论依据去支撑我的行动。业界评价度颇高的一本叫《重构》的经典著作里面的观点，应该是大家达成共识最好途径。 下面摘录了部分阅读中感触比较深的段落。 ### 《重构—改善既有代码的设计》 ### 何时重构 最近跟同事经常的对话是： 我：小明，你知道那块代码是什么意思吗，代码有点混乱，我没法弄懂。 小明：那块代码很复杂的，现在已经能跑，你就别动它了。 下面是书上提到何时应该重构，看下面的场景，是不是和我目前的状况非常相似呢。 > 你的态度也许倾向于尽量少修改程序：不管怎么说，它还运行得很好。你心里牢牢记住那句古老的工程谚语：“如果它没坏，就不要动它。”这个程序业务还没坏掉，但它造成了伤害。它让你的生活比较难过，因为你发现很难完成客户所需的修改。这时候，重构技术就该粉墨登场了。 ### 怎么跟经理讲重构 最近跟产品经理讨论，我们需要抽取时间进行代码重构，产品经理的观点是以完成工作为优先，重构工作其实没那么重要。但是我是不同意他的观点的，今天刚好读到了这一个话题，给我提供了一个完整的理论基础。 > 很多经理嘴巴上说自己“质量驱动”，其实更多是“进度驱动”。这种情况下我会给他们一个较有争议的建议：不要告诉经理！ 软件开发者都是专业认识，我们的工作就是尽可能快速创造出高效软件。对于创造软件，重构可带来巨大帮助，如果需要添加新功能，而原本设计却又使我无法方便地修改，先重构再添加新功能会更快些。受进度驱动的经理要我尽可能快速完事，至于怎么完成，那就是我的事了。 ### 关于技术债务 我以前理解的技术债务只是有不良的代码，需要抽时间进行偿还。书上说，债务是会产生利息的，确实是这样，不良的代码就像债务，会产生利息，时间越长，利息越高，最后将会无法偿还，直到破产。 >“技术债务”：把未完成的重构形容为“债务”，很多公司都需要借债来使自己更有效的运转，但是借债就得付利息，过于复杂的代码所造成的维护和扩展的额外成本就是利息。你可以承受一定程度的利息，但如果利息太高你就会被压垮。
## 前言 你是否经常碰到业务反馈，线上的小程序某个页面打不开了，订单没法结算了，但是你当时测试的时候都是好好的。 由于线上环境复杂，一些问题只会在特定网络环境或者设备上发生，对于这类问题，异常信息的收集就显得格外重要了，我们不但希望收集**错误的堆栈信息，还需要用户操作流程，设备信息**等，以便复现错误。 ## 简单收集 小程序App()生命周期里提供了onError函数，可以通过在onError里收集异常信息 ``` App({ // 监听错误 onError: function (err) { // 上报错误 wx.request({ url: "https://url", // 自行定义报告服务器 method: "POST", errMsg: err }) } }) ```...