黄弘 做于 2015/11/02 01:20git
不隐瞒的说，我是一名重度“拖延症”患者。也许从我出生开始就在本身跟本身较劲、拧巴，拒绝妥协却从不表态，由于我也不知道我在坚持什么。github
小时候爸妈以异常节俭的方式表如今我面前，他们偶尔“大方”一下要给我买点什么裤子、鞋子，我老是坚持不要。我不知道我为何不要，总之我就是不想要，因此他们就猜想究竟是没知足我什么，是颜色仍是款式，以为我很犟。安全
个人确很犟，由于我女儿也这样。因此我反而懂她了——很奇怪的反应。框架
有时候我对本身要求完美，要么满分要么鸭蛋。高中时跟语文老师对着干，只要是他的课我就不上；要么不交做业，要么写完一整本的做文。与其斗，可谓其乐无穷。工具
后来也知道本身不是那块料，就再也不写文章了，改写代码。但惋惜的是代码总有个时效，你总得依赖某个环境而存在，而环境老是在变。Java 1.4 用到如今 8，PHP 4.3 用到如今 5.3，听说 7 都出来了。其余喜欢的 Perl, Python 亦如此。我想写个长久的东西，但过不了几年再看就是垃圾，或代码样式陈旧得让人难受。设计
好比个人开源项目之一 HongsCORE 从 11 年末启动到如今都 4 年了，总共规划的 4 个系统只勉强出来这么 1 个管理系统，大量的时间在折腾框架上，并且越折腾还越来劲。项目管理
尤为是在命名和代码对齐上，耗费的时间可能就占了一半，为此没完没了的重构。命名倒不是由于用的词意思不对，而是——不能对齐，或不能呈现某种简单的规律。好比都是 6 个字母，或依次 三、四、5 个字母，或按功用某些类必须排列在一块儿且有前后顺序，巴不得想给类名都加上 0一、02 的前缀。资源
这可能就是有些人还大赞的“完美主义”吧。而我却深受其害，进度受此拖延。为了缓解本身的“症状”，我就去开发了一个“数据管理”的模块，这下建表、字段爱叫啥叫啥了，由于底下都是代号，一串无特定意义的 36 进制数字（0~Z），并且还故意设计成不可人为指定；展示上某份数据、某字段今天叫张三明天改叫李四无所谓，不再用为命名纠结了。开发
但总有其余的事萦绕在你脑海——只要你没“治疗”好你本身。好在现实老是在该让你醒醒的时候就给你浇一壶凉水，2012 年就被猛的浇了个透心凉，而后竟然就特么大彻大悟了，悟出了一剂良药：妥协。文档
由于本身嘴笨，每次讲这个话题都讲不清本身内心的意思，结果给人的感受就是：他这个老油条，又在讲买菜理论，要讨价还价了。而我在家根本不买菜也从不砍价。
过去在不一样的单位观察，总结成功的项目和失败的项目，发现一个你们都知道的没鸟用的现象：成功的项目每每有个“老家伙”在“管事”。相反新提拔起来的开发人员去作项目管理一般会出问题，要么成员不服作鸟兽散，要么常常无法定期交付，尽管你看他是那么的努力。
是“管理”经验问题？我历来不相信对开发人员有何“管理”经验，这是一群聪明透顶的人，喊口号、讲人生、画大饼、立规矩那套压根行不通，若是你相信他有用我告诉你有效期是半小时。惟一对全部人一样有用的我相信只有利益，实实在在的东西——这是帮绝顶现实的家伙。
他们要妥协什么、能够妥协什么呢？基于预期收益对目标的妥协。如今都是一条绳上的蚂蚱，你好我好他也好，其余部门都眼巴巴的看着，你们都等着了，能作出来你的代码就没白费，休假、腐败、奖金、加薪，打脸也要去申请。不谈利益瞎扯淡的那都是耍流氓。
要别人妥协什么呢？定稿、定稿、定稿，重要的事说 3 遍，意思就是：哥们，咱们要冲了，您可路指得准点，别让我端着枪跑出一里地了你又喊跑错啦，回来~回来~，我得回得来呀。
你不得不面对一个问题，什么时候本身该妥协，什么时候对方该妥协。彼此应当总有本身要去坚守的东西，要么为了维护系统的统一或稳定性，要求对方作出妥协；要么对方坚持推出与竞争对手有差别的产品，你作出妥协。不管哪方作出妥协，风险老是明确的存在，可能推迟、可能将来维护困难、可能作完了也就完了毫无特色。
每一个人都在大谈坚持，但事实上不管你是坚持仍是放弃都是错的，前进是坑、后退也是坑，只是大部分人只知道后脚跟处有个坑，殊不知道大雾弥漫的前方也是个大坑。进老是要进的，坑老是要填的，要看为了什么而舍弃了什么。
让他人妥协，是坚守本身的价值；对本身妥协，是坚守本身的利益和群体的目标。
有人以为，我就一底层写代码的，要占据主动，推进别人走，怎么可能？
做为一名智商不高情商也 Low 的笨码农告诉你，你行的。若是你情商够高可直接跳过此节，由于对您实在没神马有价值的建议。对一名搞不来人情世故，不会玩、不会来事的宅男来讲，有效的让对方作出让步的方法只有一个：让对方感觉到风险，而非藏于心里深处。
看过《三体》的朋友应该知道，第二部《黑暗森林》中 4 位“面壁者”中的 3 位相继被“破壁”，只有大宅男罗辑成功的阻止了三体的入侵，而其方法竟然是“威胁”：告诉你三体人，你要灭我，我就在你灭我以前广播坐标，我们全完蛋。
固然不是要对本身的上司、同事用如此歹毒的招数，当量要缩小些，对相关人作不到动之以情就要作到晓之以理：我能够按你说的作，但这会带来不肯定的安全性，缘由在于……同时破坏了系统的统一性，原本此类问题能够复用某某模块，如今由于增长的特殊需求，而某某模块因为过去并未考虑到这种可能没法细分……由于这些额外的需求致使部分东西必须从新开发，时间上须要延期……总之，若是您坚持这么干我们就这么干了……
你必须把你的担心说出来，你的同事、上司是个明白人的话会仔细考虑清楚的，若是他能承担那你也可安心去作，且可能因部分不肯定性争取到合理的时间，他也好作出充分的防风险准备。
透明多是三体的弱点，换个角度可能就变成优势。
我不知道为何，我从小就喜欢这 4 个字，“能够没用”，我在个人书本上处处画满这 4 个字。有用没用不重要，重要的是你在思考。
人多、时间紧，代码写很差？我有招：
独立原则：设立公共库，项目突击期不得往里面随便加东西，各自的工具各自维护，待重构期再总结重用；
特例原则：同1，不是对整个项目细节特别熟悉，对实现手段了如指掌，不要轻易作大规模封装，封装尽量是数据流经路径可拆解的（反转控制），避免遇到某个特殊问题而没法特殊处理；
就近原则：同1，相关的代码应该尽可能的靠在一块儿，或命名规范一致，如页面 A 要用到一段独立的脚本 B，不太长就放在页面内，太大放到同一目录下或指定目录下同名文件中，看到 A 就能快速的找到 B。
实际工做里并没参与多少产品设计，以旁观者的角度也提几点：
夯实基础：设计稿应当是思惟发散的，先把主干想清楚定牢固，枝叶就不容易被大风刮得东倒西歪；
各个击破：主干肯定下来后若是时间仓促必定要逐个枝条充实完善，不要一层层的完善，由于理解老是有误差，没有细节开发很难保障与设计一致；
最小文档：相似就近原则，给开发的文档要足够小和集中，若是资源多必须分散，请肯定主文档，并加好“连接”。
《失控》 个人最爱 http://book.douban.com/subject/5989373/
《三体》 近年大热 http://book.douban.com/subject/3066477/
我发现上面的标题很整齐，我很欣慰，该睡觉了