Browsed by
标签: 程序员

聊聊团队协同和协同工具

聊聊团队协同和协同工具

这两天跟 CaliRather 做了一个线上的 Podcast – Ep.5 一起聊聊团队协同。主要是从 IM 工具扩展开来聊了一下团队的协同和相应的工具,但是聊天不是深度思考,有一些东西我没有讲透讲好,所以,我需要把我更多更完整更结构化的想法形成文字。(注:聊天聊地比较详细,本文只是想表达我的主要想法)

国内外的企业 IM 的本质差别

国内企业级在线交流工具主要有:企业微信、钉钉、飞书,国外的则是:Slack、Discord这两大IM工具,你会发现,他们有很多不一样的东西,其中有两个最大的不同,一个是企业管理,一个是企业文化。

企业管理

Slack/Discrod 主要是通过建 Channel ,而国内的IM则主要是拉群。你可能会说,这不是一样的吗?其实是不一样的,很明显,Channel 的属性是相对持久的,而群的属性则是临时的,前者是可以是部门,可以是团队,可以是项目,可以是产品,可以是某种长期存在的职能(如:技术分享),而拉群则是相对来说临时起意的,有时候,同样的人群能被重复地拉出好几次,因为之前临时起意的事做完了,所以群就被人所遗忘了,后面再有事就再来。很明显,Channel 这种方式明显是有管理的属性的,而拉群则是没有管理的

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (104 人打了分,平均分: 4.35 )
Loading...
“一把梭:REST API 全用 POST”

“一把梭:REST API 全用 POST”

写这篇文章的原因主要还是因为V2EX上的这个贴子,这个贴子中说——

“对接同事的接口,他定义的所有接口都是 post 请求,理由是 https 用 post 更安全,之前习惯使用 restful api ,如果说 https 只有 post 请求是安全的话?那为啥还需要 get 、put 、delete ?我该如何反驳他。”

然后该贴中大量的回复大概有这么几种论调,1)POST挺好的,就应该这么干,沟通少,2)一把梭,早点干完早点回家,3)吵赢了又怎么样?工作而已,优雅不能当饭吃。虽然评论没有一边倒,但是也有大量的人支持。然后,我在Twitter上嘲讽了一下,用POST干一切就像看到了来你家装修工人说,“老子干活就是用钉子钉一切,什么螺丝、螺栓、卡扣、插销……通通不用,钉枪一把梭,方便,快捷,安全,干完早回家……不过,还是有一些网友觉得用POST挺好的,而且可以节约时间。所以,正好,我在《我做系统架构的原则》中的“原则五”中反对API返回码无论对错全是200的返回那,我专门写下这一篇文章,以正视听。

这篇文章主要分成下面这几个部分:

  1. 为什么要用不同的HTTP动词?
  2. Restful 进行复杂查询
  3. 几个主要问题的回应
    • POST 更安全吗?
    • 全用 POST 可以节省时间沟通少吗?
    • 早点回家的正确姿势
    • 工作而已,优雅不能当饭吃

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (259 人打了分,平均分: 4.59 )
Loading...
谈谈公司对员工的监控

谈谈公司对员工的监控

今天看到微博上有一个热点事件, 是一个关于某公司做的一个监控员工离职倾向的软件,从截图中可以看到员工访问招聘网站的次数,还有投递的简历以及搜索的关建词等等信息,通过这些信息分析员工的离职倾向。然后我发一个微博,说了一下,我以前工作过的公司无论外国公司还是中国公司都有这样的情况,收到一些人来问我相关的情况,所以,我想还是写篇文章详细地说一下,我对这种事情的看法。

本文分成下面个部分:

  • 公司监控员工的技术手段有哪些?
  • 为什么要监控员工?
  • 外企和国企有什么不一样?
  • 我对此事的看法

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (102 人打了分,平均分: 4.55 )
Loading...
我做系统架构的一些原则

我做系统架构的一些原则

工作 20 多年了,这 20 来年看到了很多公司系统架构,也看到了很多问题,在跟这些公司进行交流和讨论的时候,包括进行实施和方案比较的时候,都有很多各种方案的比较和妥协,因为相关的经历越来越多,所以,逐渐形成了自己的逻辑和方法论。今天,想写下这篇文章,把我的这些个人的经验和想法总结下来,希望能够让更多的人可以参考和借鉴,并能够做出更好的架构来。另外,我的这些思维方式和原则都针对于现有市面上众多不合理的架构和方案,所以,也算是一种“纠正”……(注意,这篇文章所说的这些架构上的原则,一般适用于相对比较复杂的业务,如果只是一些简单和访问量不大的应用,那么你可能会得出相反的结论)

原则一:关注于真正的收益而不是技术本身

对于软件架构来说,我觉得第一重要的是架构的收益,如果不说收益,只是为了技术而技术,而没有任何意义。对于技术收益来说,我觉得下面这几个收益是非常重要的:

  • 是否可以降低技术门槛加快整个团队的开发流程。能够加快整个团队的工程流程,快速发布,是软件工程一直在解决的问题,所以,系统架构需要能够进行并行开发,并行上线和并行运维,而不会让某个团队成为瓶颈点。(注:就算拖累团队的原因是组织构架,也不妨碍我们做出并行的系统架构设计)
  • 是否可以让整个系统可以运行的更稳定。要让整个系统可以运行的更为的稳定,提升整个系统的 SLA,就需要对有计划和无计划的停机做相应的解决方案(参看《关于高可用的架构》)
  • 是否可以通过简化和自动化降低成本。最高优化的成本是人力成本,人的成本除了慢和贵,还有经常不断的 human error。如果不能降低人力成本,反而需要更多的人,那么这个架构设计一定是失败的。除此之外,是时间成本,资金成本。

如果一个系统架构不能在上面三个事上起到作用,那就没有意义了。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (212 人打了分,平均分: 4.70 )
Loading...
如何做一个有质量的技术分享

如何做一个有质量的技术分享

分享信息并不难,大多数人都能做到,就算是不善言谈性格内向的技术人员,通过博客或社交媒体,或是不正式的交流,他们都能或多或少的做到。但是如果你想要做一个有质量有高度的分享,这个就难了,所谓的有质量和有高度,我心里面的定义有两点:1)分享内容的保鲜期是很长的,2)会被大范围的传递。我们团队内每周都在做技术分享,虽然分享的主题都很有价值,但是分享的质量参差不齐,所以,想写下这篇文章 。供大家参考。

首先,我们先扪心自问一下,我们自己觉得读到的好的技术文章是什么?我不知道大家的是什么,我个人认为的好的文章是下面这样的:

  • 把复杂的问题讲解的很简单也很清楚。比如我高中时期读到这本1978年出版的《从一到无穷大》,用各种简单通俗通懂的话把各种复杂的科学知识讲的清清楚楚。还有看过的几本很好的书,有一本是《Windows程序设计》,从一个hello world的程序开始一步一步教你Windows下的原生态编程。
  • 有各种各样的推导和方案的比较,让你知其然知其所以然。有了不同方案的比较,才可能让人有全面的认识。这个方面的经典作著是《Effective C++》。
  • 原理、为什么、思路、方法论会让人一通百通。这里面最经典的恐怕就是《十万个为什么》了,在计算机方面也有几本经典书,有《Unix编程艺术》、《设计模式》、《深入理解计算机系统》等书,以及《The C10K Problem》等很多技术论文。

其实,从教科书,到专业书,再到论文,都有上面这些不错的特质。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (112 人打了分,平均分: 4.54 )
Loading...
程序员如何把控自己的职业

程序员如何把控自己的职业

这篇文章的主要内容主要是我今年3月份在腾讯做的直播,主要是想让一些技术人员对世界有一个大体的认识,并且在这个认识下能够有一个好的方法成就自己。而不是在一脸蒙圈的状态下随波逐流,而日益迷茫和焦虑。直播完后,腾讯方面把我的直播形成文字的形式发了出来,我觉得我可以再做一个精编版。所以,有了这篇文章,希望对大家有帮助。

对我来说,在我二十多年的工作经历来看,期间经历了很多技术的更新换代,整个技术模式、业务模式也是一直变来变去,我们这群老程序员成长中所经历的技术比今天的程序员玩的还更杂更多。我罗列一下我学过的,而且还被淘汰掉的技术,大家先感受一下。

- MIS应用开发:FoxPro,PowerBuilder,Delphi
- OA:Lotus Notes,VBScripts
- 微软:ODBC/ADO,COM/DCOM,MFC/ATL,J++
- 服务器:AIX,HP-UX,SCO Unix
- Web:CGI,ISAPI,SOAP
- RPC:CICS,Tuxedo
- J2EE:Websphere,Weblogic
- DB:Sybase,Informix 

我想说的是,无论过去还是今天,我们这些前浪和你们后浪所面对的技术的挑战和对技术的焦虑感是相似的,我们那个时候不但玩996,还玩封闭开发(就是一周只能回家一天)。当然,唯一好的东西,就是比起今天的程序员来说,我们那个年代没有像微信、微博、知乎,抖音这些巨大消耗你人生的东西,所以,我们的工作、生活和成长都有很效率,不会被打断、喜欢看书、Google还没有被封……当然,那时代没有StackOverlow和Github这样的东西,所以,能完成的东西或质量都一般。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (461 人打了分,平均分: 4.75 )
Loading...
MegaEase的远程工作文化

MegaEase的远程工作文化

MegaEase 是我创业的公司,主要是想把云计算(PaaS/SaaS层)的那些高可用高并发的分布式技术普及到那需要对技术自主可控的公司,这样就不需要去使用不能自主可控的闭源系统或是大公司的云平台。我于2016年开始成立MegaEase,从早期8个人,直到今天有20来个人,我们从一开始到今天都是在远程工作的公司文化。因为我很喜欢《Rework》这本书,写这本书的公司叫37signal(现名basecamp),这家公司在发《Rework》这本书的时候,整个公司只有16个人,分布在全世界8个城市,这种Geek的公司的文化很吸引我,所以,在我决定创业的时候,我就止不住地想成立这样能够远程工作的公司,于是,远程工作的团队文化就这样成为了MegaEase的基因。下面我会分享一下,我们公司的远程工作文化和其中的一些问题,最后还有一个工作协议

我们在早期的时候,8个员工来自5个城市,现在的20来个员工来自8个城市2个国家。虽然我们现在使用“共享办公室”,但是本质上,我们的整个文化是远程工作的文化。在2017-2018年度,我们公司产品商业化以来,公司早期的8个工程师在远程工作的状态下成功支持了得到的老罗的跨年演讲活动,以及其它几个客户,一方面验证了用户愿意付费购买我们的产品和服务之后,另一方面也有一些不错的收入,客单价都在百万左右。还记得当时,有几个投资人并不相信我们连个办公室都没有,而且8个人分布在5个城市,觉得我们是个骗子公司(哈哈)。在过去的一年,我们通过我们的产品和服务帮助银行电信互联网等公司进行了他们的系统架构的改造和升级,让复杂和高门槛的分布式技术和架构可以被更多的企业所掌握所应用。这说明,远程工作是没有什么问题的。实际上远程团队远程工作真的不新鲜,Github上有个Repo维护着一个支持远程工作的公司列表,还有一个跟远程工作相关的Awesome索引

当然,自从我创业以来,我身边就一直有好些不同的声音质疑远程工作。听过他们的理由后,我能够理解他们的疑虑和困惑,因为管理的确是一个很复杂的事,因为要面对的是极为复杂的人,所以,有这些疑虑也是正常的。下面是我的一些经验和分享。先说宏观管理,再说微观实践。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (173 人打了分,平均分: 4.63 )
Loading...
使用简单的逻辑方法进行独立思考

使用简单的逻辑方法进行独立思考

这是一个非常复杂的世界,这个世界上有很多各式各样的观点和思维方式,作为一个程序员的我,也会有程序员的思维方式,程序员的思维方式更接近数学的思维方式,数学的思维方式让可以很容易地理清楚这个混乱的世界,其实,并不需要太复杂的数学逻辑,只需要使用一些简单的数学方法,就可以大幅提升自己的认识能力,所以,在这里,记录一篇我自己的思维方式,一方面给大家做个参考,另一方面也供更高阶的人给我进行指正。算是“开源我的思维方式”,开放不仅仅是为了输出,更是为了看看有没有更好的方式。

我的思维方式中,使用数学逻辑的方式进行思考,通常来说,我会使用五步思考的方式:

第一步:信息数据可考证。如果一个观点或是一个见解的数据是错误的,那么就会造成后面的观点全是错的,所以,首要的是要进行数据的查证或考证。一般来说,如果一篇文章的作者足够严谨的话,他的需要给他的数据建立相关的引用或是可以考证的方法方式。如果一篇文章中出现的是,“有关专家表明”、“美国科学家证明”、“经济学家指出”,但是没有任出处,也没有点明这个专家或是科学家的名字,或是,也没有说明或引用让读者可以自己去验证的方法。那么,其引用的话或是数据是无法考证的,如果是无法考证的,那么,这篇文章的水份就非常大了。一般来说,当我读到一篇文章中的东西没有可考证的来源或是方法时,通常来说,我就不会再读了,因为这篇文章的价值已经不大了,如果我关心这篇文章中的东西,我会改为自己去查找的方式,虽然变“重”了,但是很安全。(所以,像Wikipedia这样的网站是我经常去获得信息的地方,因为信息可以被考证是其基本价值观)

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (156 人打了分,平均分: 4.62 )
Loading...
别让自己“墙”了自己

别让自己“墙”了自己

这一两周与几个朋友聊天,有年轻的90后,也有大叔级的70后,这些人在我看来都是很有能力的人,但是一些喜好过于强烈,让我不经意地回顾了我工作20年来身边的人,有发展得好的,也有发展的不好的,有些人是很可惜的,因为限制他们的不是其它人,也不是环境,而是自己,所以,很想写下这篇文章。(注:这篇文章可能会是一篇说教的文章,所以,可能会让你看着犯困,所以,我会尽量地短一些,而且尽可能多讲故事,少道理,这里的故事,全是真实发生的)

几个故事

2019年年初,我面试了一个很年轻的小伙子(93/94年出生),这个小伙子特别有灵性,也很聪明,计算机专业出身,也很喜欢技术,基础和学习能力也很好。在我这20年来认识的人中,如果他能呆在北京、上海、深圳这样的城市,我保证不出三年,他会成为他们同龄人中非常出色的技术人员,如果有个好的舞台有一个好的团队带他,他的未来会非常成功。然而,这个小伙子有两大喜好:1)只愿(或是说被迫)呆在一个毫无IT的环境的三/四线城市,2)对技术有非常大的偏好,只喜欢Go语言,非常不喜欢其它的语言,比如:Java(离开Java的世界,基本上离开了做架构的世界(相关解释见文末))。

他的这两个喜好,足以让一个未来会很优秀的人毁掉,因为,这个时代没有限制他,他的能力也没有限制他,但是他的意识完完全全地限制了他。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (479 人打了分,平均分: 4.68 )
Loading...
50年前的登月程序和程序员有多硬核

50年前的登月程序和程序员有多硬核

2019年7月20日,是有纪念意义的一天,这天不是因为广大网民帮周杰伦在新浪微博上的超话刷到第一,而是阿波罗登月的50周年的纪念日。早在几年前,在Github上放出了当年Apollo飞船使用的源代码(当然是汇编的),但完全不明白为什么这几天会有一些中国的小朋友到这个github的issue里灌水……,人类历史上这么伟大的一件事,为什么不借这个机会学习一下呢?下面是一些阿波罗登月与程序员相关的小故事,顺着这些东西,你可以把你的周末和精力用得更有价值。

首先,要说的是Apollo 11导航的源代码,这些代码的设计负责人叫Margaret Heafield Hamilton ,是一个女程序员,专业是数学和哲学,1960年得到一个MIT麻省理工大学的临时的软件开发职位,负责在PDP-1和LGP-30上运行天气预报的软件(注:在计算机历史上,PDP系统机器被称为Hack文化的重要推手,PDP-11推了Unix操作系统,而Unix操作系统则是黑客文化的重要产品。参看《Unix传奇》)。然后,她又为美国空军编写探测知敌方飞行的软件,之后,于1965年的时候,她加入了MIT仪器实验室,并成为了这个实验室的主管,这个实验实就是Apollo计划的一部分,她负责编写全新的月球登录的导航软件,以及后来该软件在其他项目中的各个版本。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (181 人打了分,平均分: 4.54 )
Loading...