程序员的营销探讨

Posted 2021-01-18 fancunwei

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了程序员的营销探讨相关的知识，希望对你有一定的参考价值。

引子

文章开篇就从经典的和尚卖梳子说起吧。链接参考:https://m.imooc.com/article/259628
销售员甲看到和尚晒太阳挠头皮时，灵机一动卖出一把。
销售员乙建议拜佛上香要心诚，蓬头垢面是对佛的不敬，应在每座庙佛像的香案前放把梳子供善男信女梳理鬓发。主持采取了他的建议，买了十把。
销售员采取梳子上刻"积善梳"，作为赠品回馈虔诚的香客，卖出1000把。
故事简介到此为止。
这三个销售员都属于挖掘需求。有的属于挖掘客户自己的需求，有的属于挖掘客户的客户需求。

程序员如何挖掘需求

如果从程序员的个体来讲，他需要的东西千千万万，不好细说。我们先将范围细化到工作层面。
工作第一步需要积累专业知识，第二需要同事间的交流，第三就是能够快速的解决问题。
这个范围还是过于泛化，不好定义。我首先界定几个课题来讲。

代码规范

编码规范

代码规范是每个程序员都应了解的技能。
最近公司建立了代码规范审查的环节，利用下班后的一个小时，抽前后端各一人，项目小组内的成员坐一起公开评论代码，可谓一篇腥风血雨，各种不规范啊......
以前没有代码审查时，我觉得很没有必要。
我在期间提问过代码规不规范和业务bug没有必然的关系，但得到了一个有意思的回答:代码写的规范就觉得人靠谱，如果代码都乱七八糟，就会觉得人不靠谱。原话忘了，大致是这意思。
带着初时的困惑，执行了几次之后也确实收获良多。个人在注视，方法整合剥离等层面做了不少优化，但也有很多问题也要注意。

第一整体业务流程介绍问题。

代码要配套业务流程讲清楚才有意义。这两次我的开篇流程讲的应该算很差，因为领导听了后还要补充一下。这当然是自己的问题，如果真的表达不好，可以借助白板草图来讲。
我这里反思下如何解决这个问题。应该是提前半小时做下准备，理清思路。不要一上台没有头绪的乱讲，让人听的茫然无措。或者提前和一个不了解业务的同事略讲下，时间控制在一分钟内，如果讲不清就需要继续提炼。
古人说一鸣惊人，如果开篇都讲的不够清晰，如何惊人？要记住并不是你的听众都
了解你做的事。
你的一次失误就是信任值减一，一次成功就是信任值加一。

第二就是复制老代码问题。

有些相似基础代码有时候为了方便会复制过来使用，但这些在代码评审时一起提交的，如果本次提交评审的代码有以前说过而还未改，就会着重再提了……拿过来用的就是你自己的，没什么老代码。能优化就优化吧，实在不能的那也没办法。但能简单优化却不优化而又被吐槽的滋味酸爽！

第三就是命名空间排序，代码换行问题，变量命名。

Vs2017有对using删除和排序的支持，也有将using System排列到第一位的设置。命名空间排列整齐，看着也舒服。
在适当的业务逻辑处，注意换行。这和写博客一样。一大段混在一起，谁也看不懂。把处理同一个逻辑的放一块，能提取新方法的就提取，提取不了的就换一行。
变量命名一般是小驼峰写法。

第四基础用法

要善于利用.net平台提供的特性，如Ling里面将数组转list，将list转字符串string.join，
类型转换try parse 等。还有关于如何处理异常的探讨。
利用好这些常用的方法，可以减少代码量，看着更整洁。更整洁的代码，人人看着都舒服，改起来也舒服。

上面列了四点我总结的信息，代码评审中还有更多的总结，单个说来都知道，合起来一看都有触雷。

程序员和程序员公开沟通分享的机会并不是那么多，每周周五分享会和代码评审机制建立了一个大家共同学习的渠道。虽然上面列的都是很普通的，但依然有很多人包括我在踩雷。程序员和程序员之间的分享也是一种营销，通过不同的写法，不同的讲法会引来不同的评价。这是一项基本功。如何去应对不同的情形，是一项挑战。我指的不仅仅是代码，还有沟通，还有遇到疑问时的即时回答。

讲完评审沟通，就要提一下最大的营销了。你写的代码上线了，如果没有问题，也许一直默默无闻，也许得到了众多夸奖。但如果上线后bug一堆，负面事故不断，那你就危险了。

上面讲了程序员工作层面的自身营销，下面来讲讲非工作层面的营销。
我就以自身来举例。