程序員的營銷探討

時間 2019-12-06

原文原文鏈接

引子

文章開篇就從經典的和尚賣梳子提及吧。連接參考:https://m.imooc.com/article/259628
銷售員甲看到和尚曬太陽撓頭皮時，靈機一動賣出一把。
銷售員乙建議拜佛上香要心誠，蓬頭垢面是對佛的不敬，應在每座廟佛像的香案前放把梳子供善男信女梳理鬢髮。主持採起了他的建議，買了十把。
銷售員採起梳子上刻"積善梳"，做爲贈品回饋虔誠的香客，賣出1000把。
故事簡介到此爲止。
這三個銷售員都屬於挖掘需求。有的屬於挖掘客戶本身的需求，有的屬於挖掘客戶的客戶需求。java

程序員如何挖掘需求

若是從程序員的個體來說，他須要的東西千千萬萬，很差細說。咱們先將範圍細化到工做層面。
工做第一步須要積累專業知識，第二須要同事間的交流，第三就是可以快速的解決問題。
這個範圍仍是過於泛化，很差定義。我首先界定幾個課題來說。git

代碼規範

編碼規範

代碼規範是每一個程序員都應瞭解的技能。
最近公司創建了代碼規範審查的環節，利用下班後的一個小時，抽先後端各一人，項目小組內的成員坐一塊兒公開評論代碼，可謂一篇腥風血雨，各類不規範啊......
之前沒有代碼審查時，我以爲很沒有必要。
我在期間提問過代碼規不規範和業務bug沒有必然的關係，但獲得了一個有意思的回答:代碼寫的規範就以爲人靠譜，若是代碼都亂七八糟，就會以爲人不靠譜。原話忘了，大體是這意思。
帶着初時的困惑，執行了幾回以後也確實收穫良多。我的在注視，方法整合剝離等層面作了很多優化，但也有不少問題也要注意。程序員

第一總體業務流程介紹問題。

代碼要配套業務流程講清楚纔有意義。這兩次個人開篇流程講的應該算不好，由於領導聽了後還要補充一下。這固然是本身的問題，若是真的表達很差，能夠藉助白板草圖來說。
我這裏反思下如何解決這個問題。應該是提早半小時作下準備，理清思路。不要一上臺沒有頭緒的亂講，讓人聽的茫然無措。或者提早和一個不瞭解業務的同事略講下，時間控制在一分鐘內，若是講不清就須要繼續提煉。
古人說一舉成名，若是開篇都講的不夠清晰，如何驚人？要記住並非你的聽衆都
瞭解你作的事。
你的一次失誤就是信任值減一，一次成功就是信任值加一。github

第二就是複製老代碼問題。

有些類似基礎代碼有時候爲了方便會複製過來使用，但這些在代碼評審時一塊兒提交的，若是本次提交評審的代碼有之前說過而還未改，就會着重再提了……拿過來用的就是你本身的，沒什麼老代碼。能優化就優化吧，實在不能的那也沒辦法。但能簡單優化卻不優化而又被吐槽的滋味酸爽！後端

第三就是命名空間排序，代碼換行問題，變量命名。

Vs2017有對using刪除和排序的支持，也有將using System排列到第一位的設置。命名空間排列整齊，看着也舒服。
在適當的業務邏輯處，注意換行。這和寫博客同樣。一大段混在一塊兒，誰也看不懂。把處理同一個邏輯的放一塊，能提取新方法的就提取，提取不了的就換一行。
變量命名通常是小駝峯寫法。數組

第四基礎用法

要善於利用.net平臺提供的特性，如Ling裏面將數組轉list，將list轉字符串string.join，
類型轉換try parse 等。還有關於如何處理異常的探討。
利用好這些經常使用的方法，能夠減小代碼量，看着更整潔。更整潔的代碼，人人看着都舒服，改起來也舒服。框架

上面列了四點我總結的信息，代碼評審中還有更多的總結，單個說來都知道，合起來一看都有觸雷。ide

程序員和程序員公開溝通分享的機會並非那麼多，每週週五分享會和代碼評審機制創建了一個你們共同窗習的渠道。雖然上面列的都是很普通的，但依然有不少人包括我在踩雷。程序員和程序員之間的分享也是一種營銷，經過不一樣的寫法，不一樣的講法會引來不一樣的評價。這是一項基本功。如何去應對不一樣的情形，是一項挑戰。我指的不只僅是代碼，還有溝通，還有遇到疑問時的即時回答。學習

講完評審溝通，就要提一下最大的營銷了。你寫的代碼上線了，若是沒有問題，也許一直默默無聞，也許獲得了衆多誇獎。但若是上線後bug一堆，負面事故不斷，那你就危險了。優化

上面講了程序員工做層面的自身營銷，下面來說講非工做層面的營銷。
我就以自身來舉例。