到 2015 2015年 7 月

30 卷數 7

新貴-為什麼很難談一談有關科技

Ryder Donahue |到 2015 2015年 7 月

軟體發展最難的部分可能談論它。每一天,開發商必須闡明深刻的技術細節和廣泛的邏輯概念,經常只有路過的瞭解他們正在談論的人。

我看到人民鬥爭與這所有的時間,我不認為這是因為他們是可憐的傳播者,或有壞的想法。這是因為談論某些抽象的因為代碼是非常困難的事。如果通信是在軟體工程中,很少發生,但事實上恰恰相反,這不是這樣的問題。有效的溝通是每個成功的、 基於團隊的軟體發展工作的核心。

即使你是一個自由職業者的程式師,試圖瞭解和提供客戶想要什麼可以艱苦的工作。對許多開發人員,每個團隊成員在哪裡工作的難題,必須組合在一起的不同部分的大型專案,所面臨的挑戰獲取甚至更嚴厲。

向別人展示一些代碼或甚至偽代碼,可以是一個偉大的方式來獲得你的觀點,但有時代碼不可用,或它是太大,無法立即掌握別人在交談中。因此,我們經常將歸類為揮手和崇高的描述。

另一個缺陷是當開發人員認為他們談論到的人都熟悉的術語和縮寫詞他們融入到他們的解釋,或其他有 helper 函數所引用的必備知識。如果另一方已搖搖欲墜掌握了這些概念,它會慢下來 — — 如果不是完全停止 — — 西遊記 》 的理解。只要一個人聽到陌生的首字母縮略詞,很多下面是對話方塊的輸給了他們他們苦苦掙扎的上下文。

更廣泛地說,一個成功的對話方塊程式設計需要雙方各持相似的藍圖,在他們心中的談話開始時。這份藍圖可以是的代碼你正在編寫或甚至整個專案的體系結構的上下文中。雖然這位通常出於需要解釋的它並不總是很好解釋 — — UML 圖通常太不方便,常常只是沒有時間來審查所有詳細的物件和資料結構。結果:團隊往往不能滿足要求開車知情的決定,但我們都繼續這麼做。

溝通是一個嚴峻的挑戰,我個人奮鬥。但它是一個弱點,如果承認,可以工作。作為開發人員,我們必須提醒自己,別人可能不會跟隨我們思路密切像我們認為的那樣。在另一面,我們必須願意讓別人知道當我們還在掙扎著理解一個概念在談話前的會移到下一個主題。

鑒於所有這些困難,我發現它是一種像 Windows 的產品甚至工作在所有的軟體工程的勝利給成千上萬的工程師,他們多年來對它工作。

也許在談論科技都將十分困難,或也許隨著軟體發展的比較年輕的學科的成熟,我們會看到更有效的溝通方法開發。也許解決辦法在於技術本身,具有更好的工具進行協作和更多的關注和進化程式設計語言。如果未來的程式設計語言設計更清晰和直觀的語法,並不冗長的行李從原始語言結轉,我們可能會看到代碼,我們可以更快地讀取和其意義更容易吸收。也許解決方案的一部分在於更新、 更好地程式設計范式,將允許更好的類比驅動的解釋比甚至物件導向程式設計現在可以提供。

有一點是明確的誰創建和採用這些解決方案將獲得很大的優勢在那些繼續在今天描述軟體工程的首字母縮寫詞和手揮舞著沙塵暴中徘徊。


Ryder Donahue 是在微軟的軟體發展工程師。最初從夏威夷群島,他現在居住在位於華盛頓州雷德蒙德市與他的未婚妻和他們的貓,大理石。