成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

程序員如何提一個好問題

開發 前端
提出好的問題是在編寫軟件時的一個非常重要的技能。這么多年來我對此也算略有小成。這里有一些我用著覺得很棒的指導方針!

提出好的問題是在編寫軟件時的一個非常重要的技能。這么多年來我對此也算略有小成。這里有一些我用著覺得很棒的指導方針!

開始

我實際上是那種總是會問出愚蠢問題或“不好”問題的大信徒。我一直在問人們一些愚蠢并且完全可以通過谷歌搜索或搜索代碼庫解決的問題。大多數時候我都不愿意自己去搜索解決,但有的時候我又會無論如何都自己去搞定,而且也不會認為這如同世界末日一樣可怕。

所以本文中列舉的各個策略不是關于“在提問之前你必須要做的所有事情”,而是“一些可以幫助提出更好的問題并得到我想要的答案的要點!”。

何為好問題?

我們的目標是提出易于回答的關于技術概念方面的問題。我時常碰到知識淵博并且這些知識也是我想知道的人,但他們并不總是知道如何確切地用***的方式解釋。

如果有一系列好的問題,那么就可以幫助解答的人將他們所知道的內容有效地解釋給我聽,并指導他們告訴我我感興趣的東西。那么我們該如何做到這一點呢?

說明你所知道的

這是我最喜歡的提問技巧之一!提問形式基本上是這樣的:

  • 說明到目前為止你對這個話題的理解
  • 問“對嗎?”

例如,我最近在和人(一個優秀的問題提問者)談論網絡!他們說“所以,我在這里的理解是有某個遞歸式dns服務器鏈……”。那是不正確的!實際上沒有遞歸式DNS服務器鏈。(當你談到遞歸式DNS服務器時,只涉及一個遞歸式服務器)因此他們說出他們當前的理解,可以方便我們澄清它實際上的工作原理。

我對rkt很感興趣,但我不明白為什么rkt在運行容器時會比Docker占用更多的磁盤空間。

雖然“為什么rkt比Docker要使用更多的磁盤空間”不怎么像是正確的問題——我差不多知道代碼是如何工作的,但我不明白為什么他們那樣寫代碼。所以我把這個問題寫到 rkt-dev 郵件列表:為什么rkt存儲容器圖像時不同于Docker?

我:

  • 寫下了我對rkt和Docker如何在磁盤上存儲容器的理解
  • 想出了幾個我認為他們可能會按照他們的方式設計的原因
  • 問“我的理解對嗎?”

我得到的答案超級超級有幫助,正是我所尋找的。我花了很長時間以一種我滿意的方式制定了這個問題,我很高興我花了時間,因為它使我更好地明白了個中奧妙。

闡明你的理解并不容易(需要時間思考你所知道的并澄清你的想法),但效果會很好,更方便你要求幫助的人針對性地提出解答。

問答案是事實的問題

我有很多問題一開始有點模糊,如“SQL中的連接查詢JOIN如何工作?”。這個問題不是很棒,因為連接查詢如何工作有很多不同的部分!那么對方怎么知道我有興趣學習的是什么?

我喜歡問那種答案是一個直截了當的事實的問題。例如,在SQL連接查詢示例中,一些事實問題的答案可以是:

  • 連接兩個大小為N和M的表的時間復雜度是多少?是O(NM)嗎?還是 O(NlogN)+ O(MlogM)?
  • MySQL在進行連接查詢之前是否始終將聯結列排序作為***步?
  • 我知道Hadoop有時會“hash連接”——這是其他數據庫引擎也使用的一個連接策略嗎?
  • 當我在一個索引列和一個未索引列之間進行連接時,我需要對非索引列進行排序嗎?

當我問像這樣超級具體的問題時,被問的人并不總是知道答案,但至少他們理解了我感興趣的問題是怎么樣的——很明顯,我并不想知道如何使用連接查詢,我就是想了解一些實現細節和算法。

真誠地說出你不明白的地方

很多時候當有人向我解釋某事時,他們會說一些我不明白的東西。例如,可能有人正在向我解釋一些關于數據庫的東西,并說“好的,我們使用MySQL的樂觀鎖,因此……”。等等,我不知道什么是“樂觀鎖”啊。所以這需要提問了! :  )

阻止某人接著說下去并提問“嘿,那是什么意思?”是一個超級重要的技能。我認為它是自信的工程師的屬性之一,并且培養起來會大有裨益。我看到很多高級工程師經常要求澄清說明他或她不明白的地方——我覺得當你對自己的技能更有信心時,這更容易。

越是這么去做,在我要求別人澄清的時候就越是感覺自然。事實上,如果有人在我解釋的時候不要求我澄清,我反而會擔心他們不是真的有在聽!

這也為問題回答者創造了在觸及他們知識領域范圍之外時可以承認的余地!很多時候,當我問某人問題時,如果問到他們不知道的東西。我問的人通常真的非常善于說“不,我不知道!”

識別你不明白的術語

當我開始當前這份工作時,我首先去了數據團隊。當我看我的新工作需要什么的時候,有這些要求!Hadoop,Scalding,Hive,Impala,HDFS,zoolander,以及等等。我可能之前聽說過Hadoop,但這些單詞是什么意思我基本上是兩眼一抹黑。其中一些是內部項目,其中一些是開源項目。所以我從要求幫助我理解每個術語的含義和它們之間的關系開始。我可能會問的一些問題是:

  • HDFS是數據庫嗎?(不,它是一個分布式文件系統)
  • Scalding使用Hadoop嗎?(是)
  • Hive使用Scalding嗎?(不)

實際上我編寫了一部關于所有術語的“字典”,因為術語實在太多,并且理解所有的術語意味著真正幫助我定位自己,以便于以后提出更好的問題。

做一些研究

在我鍵入上面的SQL問題時,我在Google搜索框中輸入了“如何實現SQL連接”。我點擊了一些鏈接,看到“哦,我知道了,有時有排序,有時有哈希連接,以前我聽說過”這些話,然后寫一些我遇到的更具體的問題。首先稍微Google一下,這可以幫助我寫出更好的問題!

也就是說,我認為人們有時對“在沒有谷歌搜索之前就不要提問題”這一原則太過苛刻——有時我在和某人一起吃午飯的時候,因為對他們的工作好奇,于是我就會問到相關的基本問題。這完全正常!

但是做研究非常有用,并且做足夠的研究以便于提出一系列超贊的問題真的很有意思。

決定去問誰

在這里我主要談論向你的同事問問題,因為大多數時候我都是向他們求助的。

詢問同事時,我會思考到的一些問題是:

  • 是提問的好時機嗎?(如果他們在忙著做一件緊迫的事情,那么可能就不是好時機)
  • 詢問他們解答問題所需要的時間是不是可以節約我盡可能多的時間?(如果我問了一個問題,將花費他們5分鐘回答,卻將節約我2個小時的時間,那就棒棒噠 : D)
  • 他們需要多少時間來回答我的問題?如果我有半小時的問題要問,那么我可能會之后再安排一段時間,如果我只有一個快速的問題,那么我很有可能現在就問了。
  • 這個人對這個問題而言是否過于太高級了?我認為這是很容易陷入的陷阱,那就是每個問題都去問最有經驗/最有知識的人,而且每個問題的主題還各不相同。但實際上更好的辦法是找一個知識稍微沒那么淵博的人——通常他們可以回答大部分的問題,擴散負荷,而且他們還可以展示他們的知識(哈哈)。

我不總能做好這些事情,但考慮這些確實于我有所幫助。

此外,我通常會更多地去問更靠近問題的人——幾乎每天我都會與之談論的人,一般說來我更很傾向于去問他們問題,因為他們更了解我的工作背景,從而給我一個有用的答案。

How to ask questions the smart way by ESR》是一個流行和相當有敵意的文檔(它的開頭陳述很爛,如‘我們稱呼這樣的人為“失敗者”’)。內容關于如何在互聯網上向陌生人提問。向互聯網上的陌生人問問題是一個超級有用的技能,可以讓你獲取真正有用的信息,但這也是一類“硬模式”的問題。因為與你對話的人對你的情況知之甚微,所以更仔細地陳述你確切想要知道什么更佳。我不喜歡ESR文檔,但它確實說明了一些有用的東西。文章的“How To Answer Questions in a Helpful Way”部分還是挺不錯的。

提出問題以顯示不明顯的內容

更高級的問題提問形式是提出問題以揭示隱藏的假設或知識。這種問題實際上有兩個目的——***,得到答案(可能這個人知道但其他人不知道的信息),但也要指出,這里有一些隱藏的信息,并且共享這些信息是有用的。

Etsy的“Debriefing Facilitation Guide”中的“The Art of Asking Questions”部分就是在討論已發生事件的背景下的一個非常好的入門介紹。以下是從該指南摘錄的幾個問題:

  • “當你懷疑這種類型的失敗發生時,你想要尋找什么?”
  • “你怎么判定這種情況是‘正常’的?”
  • 你是怎么知道數據庫崩潰的?
  • 你怎么知道那是你需要page的團隊?

這些類似的問題(看起來很基本,但實際上并不明顯)在某些權威人士提問的時候特別強大。我特別愿意看到經理/高級工程師問及這類基本但重要的問題,如“你是怎么知道數據庫崩潰的?”,因為它為水平較低的人創造了以后提問相同問題的空間。

回答問題

André Arko的“How to Contribute to Open Source”里面有部分是我非常欣賞的

既然你已閱讀了所有要點并pull請求,那么就開始查看你可以回答的問題。如果問題你以前就回答過,或者你剛剛閱讀的文檔就可以解答,那么用不了多少時間你就能發現這一點。回答你知道怎么回答的問題。

如果你正在攀登一個新項目,那么回答那些正在學習你剛學完的那些內容的人的問題,可謂是鞏固知識的好方法。每當我***次回答關于一個新主題的問題時,我總是會有一種“OMG,要是我答錯了該怎么辦啊,OMG”的感覺。但通常我都可以正確回答他們的問題,然后我就會感覺自己棒棒噠,好像自己更好地理解了主題!

問題也是巨大的貢獻

好的問題可以為社區做出巨大的貢獻!我回答了一些關于CDN的問題,并在 CDNs aren’t just for caching寫出了答案。很多人告訴我,他們真的很喜歡這篇博文,我認為我問的這些問題幫助了很多人,不僅僅惠及自己。

很多人表示自己很喜歡回答問題!我認為將好的問題當作一件你可以做的超棒的事情,并放到對話中是很重要的,而不要只是認為“問好的問題,這樣人們才只會稍微惱火,而不會非常非常惱火”。

責任編輯:張燕妮 來源: 碼農網
相關推薦

2020-02-22 21:51:43

程序員Microsoft SServerSQL

2020-10-05 21:13:37

程序員技能開發者

2009-03-18 13:12:36

程序員技術IT行業

2015-05-13 14:06:03

程序員糟糕的程序員

2014-01-06 09:33:32

程序員管理

2020-06-01 09:43:26

程序員互聯網系統

2016-07-26 13:47:49

程序員新手編程

2015-06-25 09:32:55

JavaScript程序員

2014-05-22 14:36:34

2021-07-01 07:43:41

項目程序員代碼

2009-07-02 09:42:34

JSP程序員

2010-12-27 09:24:45

JSP程序員

2012-09-29 10:49:36

程序員debug架構

2015-06-25 19:23:03

JavaScript程序員

2015-06-25 09:53:13

JavaScript程序員

2013-07-18 09:58:18

C++程序員

2019-09-19 14:28:14

程序員分布式系統

2015-06-08 10:48:39

程序員程序員自白

2011-02-14 13:05:17

PythonWeb

2015-06-16 10:31:36

程序員
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 久久99精品国产麻豆婷婷 | 亚洲毛片在线 | 毛片免费视频 | 一级毛片视频在线 | 免费观看成人鲁鲁鲁鲁鲁视频 | 亚洲一区二区三区久久久 | 国产精品久久久久久久久久久久 | 国产又色又爽又黄又免费 | 欧美中文在线 | 日韩精品1区2区3区 成人黄页在线观看 | 久久久精品国产 | 午夜精品一区二区三区在线观看 | 91精品国产综合久久婷婷香蕉 | 国产成人精品一区二区三区在线 | 91精品国产综合久久婷婷香蕉 | 午夜免费电影院 | 午夜视频免费 | 成人在线观看免费 | 欧美伊人久久久久久久久影院 | www.久久久.com | 午夜影院在线播放 | 精品一级 | 97超碰成人 | 久久aⅴ乱码一区二区三区 91综合网 | 欧美乱做爰xxxⅹ久久久 | 久久99精品久久久久久国产越南 | 成人欧美一区二区三区黑人孕妇 | 99精品视频在线观看 | 国产剧情一区二区三区 | av播播 | 亚洲国产情侣 | 九九在线视频 | 免费观看一区二区三区毛片 | 自拍偷拍亚洲一区 | 国产91视频一区二区 | 亚洲成人播放器 | 精品真实国产乱文在线 | 成人小视频在线 | 91精品国产综合久久婷婷香蕉 | 久久综合久 | 日韩精品一区在线观看 |