想成为优秀的程序员这些码德不能缺.pdf

想成为优秀的程序员这些码德不能缺 至少要把一个变量弄成这样：到处被设置，但是几乎没有哪里用到它。不幸的是，现代编译器通 常会阻止你做相反的事：到处读，没处写。不过你在C 或 C++ 里还是可以这样做的。 我把这些看成是作为一个程序员的基本素质，多数是编码之外的事情： 代码每天备份；（预防意外导致的任何损失） 上传代码时写清楚log信息；（为维护这个模块的人着想，有可能是你自己） 提供接口时不要把问题抛给使用接口的人，升级或者变更接口时不要删掉原来的接口；（为使用 你接口的同事着想） 变量命名要见名知意；（起码不能误导别人） 在工程中新建一个doc文件夹将项目相关的文档放在该目录下，方便后面维护的人员理解项目和 代码；（为维护这个模块的人着想，有可能是你自己） 签署bug或者转办bug时写明分析结果和转办原因；（让测试员知道你的改动是否对其它功能有 没有影响，让改这个bug 的人知道你的分析结果和转给他的原因） 向身边的同事或者在网上提问时，先要有自己的分析和思考；（不要浪费他人的时间） 不私自接受功能变更，不私自增删功能；（做一个执行者，决策会有该做决策的人去做）。 离职或者换岗的时候做好工作交接；（善始善终） 回答者：邬wlf，一切问题的根源都是交流障碍 作为一个在码工界干过15年的人来说，最有码德的事情我认为应该是绝不加班。 可能对于刚干这行不久的码工来说，绝不加班就是逃避工作的代名词。但是作为过来的老人很明 确的告诉你，想做到这点还能安心的拿钱公司还不能对你哔哔啥是没那么容易的。 一般来说，要加班赶工的项目，问题其实都出在最开始的阶段，要么目标不明，要么跟用户交流 不畅，要么夸大海口结果给自己惹来一堆麻烦。而开始一旦出问题，造成的错误会形成累计效应，越 到后面很可能越麻烦，甚至验收后都无法收场。 刚 开始工作的时候，项目的谈判都是由商务组的家伙去谈的，这些家伙基本没有什么节操，他 们的收成只跟项目提成有关系，所以他们在谈判的时候会答应不现实或者 很扯淡的技术要求，主动 跳进对方给出的售后服务陷阱 （比如说并没写明售后服务范围和时间范围）只为求快速签署合同。甚 至根本没明白对方说了啥就拿回来一个 离题万里的需求，反正只要工程验收后他们就能拿到提成， 所以他们并不在乎会带来多大麻烦。这样的干法就只会带来无穷无尽的加班，哪怕你代码写的再好再 利于 维护加班到猝死，都没任何意义，因为从一开始就错了。 后 来在我工作一段时间后，干掉了几个难以验收的项目。我这时候觉得不能放任那帮根本没有 软件思维的家伙去跟客户胡扯，我对boss表示开发人员应该参与商务 谈判。而且事实证明本公司商 务对客户的思维理解经常都是离题万里的，boss也早已被各种烂尾搞的头痛不已。但是出于传统 （不 让技术人员跟客户接触，以避 免技术人员挖了客户自己玩）他开始并没有采纳意见。但是有一次在 大连做项目，本地的软件公司已经做了客户一部分的工作，boss利用关系半路截胡。本地公 司当然 不愿意，然后两边开始撕比，本地公司要求我们完全包容他们的系统，而客户急着赶快完工赶奥运的 趟。这时候商务开始干瞪眼了，因为牵涉到了软件问题， 这烂事丢在了我头上。我去后跟对方客户 交流，客户要求1个月内系统上线工作，而boss对我说的是你得让客户相信这破事一个月肯定做不 完，这样我们就能成 功的赶跑本地公司。我跟本地公司的技术总监胡扯了一晚上，对方年纪有些大 了，最后被侃晕了承认1个月搞不完。然后这事就变成了本地公司出硬件，直接上咱们 的成熟软件， 一个月完成。 从 这事以后，boss才算看明白商务谈判不能缺乏技术的重要性，后来数次工程，都先让我去跟 客户谈判。在清晰的了解客户的需求，有了完整完善的前期设计和完 备清晰的验收项目合同后，基 本再也没加过班。对于这种谈判能力，其实是码工的一个很好的转型，毕竟代码民工是不能长期干的， 而这种跟人打交道的技术工作， 其实很适合码工转型。当然，你要是你很腼腆，见人就脸红那就没 招了。我参与技术谈判有几点心得：你得完全了解你所在公司的软硬件实力，明白有那些弱点和特 长， 在谈判的时候你得敏锐的分析出客户的想法有那些可能会很难搞又没有多大意义。你得引导客户往本 公司擅长的技术上去思考。你得引导客户，而不是只听客户 怎么说你就怎么做。在我朝现在做软件 应用，3分看技术7分看人，应用性的软件一般不追求技术上的顶级高端，出的问题多半在于人与人 的交流错误上。你得做一 个擅长与人交流的码工才