1.“我不知道是該洗掉還是重撰寫,”
回歸歷史源代碼會誘使程式員重新產生更多的障礙集群,邏輯性差的冗余句法令人無法理解!然而,如果它沒有中斷,請不要去修復,這是我經常掙扎的問題,相信也困擾了不少其他軟體開發員,

2.“我應該在開始架構時檢查Github版本控制系統,”
絕大多數開發員都應該知道Github版本控制系統及每天公布的開源專案,涉足所有計算機語言的程式員,利用網路分解研究現有專案,進行維基論壇討論或發表個人的代碼報告,這些為很多專案的插件和模板提供了很多很好的資源,
3."為什么這個腳本需要如此多的庫"
尤其是變得越來越重量級例如 java和Objective-C,庫檔案的數量日益增加,非常明顯的是當建立一個框架時就需要許多的基礎庫,甚至一些JavaScript的插件都需要大量額外的檔案,有的時候雜七雜八的東西很招人煩 -但至少它能運行,
4“在互聯網上移動一定會有解決方法”
遇到困難問題我的第一反應是在互聯網上查找,許多的程式員會把他們遇到的問題發布到論壇上,問題最終得到解決并保存下來,
谷歌極好的挑選出你問題相 關的關 鍵字并且為你指出了正確的導向,這些都為討論提供了有益的線索,不幸的是,有的時候對于一個特定的問題還沒有過多的資訊,

5.“有這個功能的插件么?“
為什么要重造輪子?插件是擴展任何程式或網站用戶界面的一個很好的資源,另外他們可以為開發者使用的一些定制的獨特的選項,如果不存在已有插件的話,為什么不自己創建一個呢?
6.“網站專案,我害怕Internet Explorer,”
使用Internet Explorer渲染網頁時遇到的坑我就不提了,從5.5版本到IE9-IE10瀏覽器支持方面的爭議一直不斷,Web開發人員可能害怕網頁除錯,使用IE6渲染更是噩夢,謝天謝地,那些日子已經慢慢成為了過去,
7.“邏輯陳述句——它本身就不是很有邏輯,”
現在有的邏輯陳述句有if/else回圈、for回圈、while回圈、do回圈……這個串列相當長,當查看一些舊示例代碼時我盡力想弄明白我當時的使它運行的邏輯是什么,NOT操作的跳轉數及比較符讓人頭暈,以后我會經常回過頭來更新自己好的邏輯實踐,

8.“我花30分鐘寫一個函式,卻要花2小時讓它作業,”
這不是十年前的故事嗎?你沿著以前的套路輕松構建,突然函式輸出了一個致命的error,因此你不得不回過頭去清除代碼塊來試圖找到故障的代碼行,當你筋疲力盡最終找到了罪魁禍首后就像得到救贖一樣,
9.“讀了幾個博客后我才意識到我之前的理解一直是錯誤的,”
我喜歡按自己的編程思想直奔主題,當事情沒有按計劃進行時這樣做會導致麻煩,很多次我開始了一個專案后就陷入困境,然后便到博客或相關文章中尋求幫助,之后我發現整個方法實際上是錯誤的,重新開始會更容易!開始時多一點研究在長遠看來是在節省時間,
10.“編程社區上的好心人會幫助你,”
我已經數不清有多少次通過編程社區解決困難的問題了,勇敢邁出第一步的話社區里有很多聰明的熱心人愿意幫你,所有的在線論壇被定義為是軟體開發者及前端/后端web工程師最全面的支持網,
如果你也想成為程式員,想要快速掌握編程,趕緊關注小編加入學習企鵝圈子吧!
里面有資深專業軟體開發工程師,在線解答你的所有疑惑~編程語言入門“so easy”
資料包含:編程入門、游戲編程、課程設計等,
免費學習書籍:
免費學習資料:
11. “忘記關閉結束括號帶來的麻煩”
你采取的所有步驟都是除錯,向前兩步,退回一步,或者向前更多,你會感徑訓很多時間盯著代碼,只為查找一些語法錯誤或者是變數的作用域,最終卻只找到一個失蹤的括號,這是一種奇怪的感覺,所有的時間都花費在了一個小小的語法錯誤上,在同一時間會感覺自己即是一個天才又是一個傻子,

12. “停下來,喝一杯咖啡”
有時候你需要的是起身離開顯示幕,在鍵盤上作業幾個小時后,這有助于打破慣例,大多數的健康指南建議休息30-60分鐘,但這一切都取決于你的需要,如果讓你從編程程序中中斷會使你苦惱,那最好還是不要中斷,
13."是不是有人正在擺弄我的代碼"
這聽起來像是妄想和偏執,但有時你只是猜想誰在你正忙著睡覺的時候挖了這個坑,遍覽過去幾周或者幾個月的專案能夠給你留下一種病態的感覺,
有時候你 將會發 現你這從來都不記得是自己留下的坑——盡管上個星期你都搗騰過這個專案!我發了瘋似得把它寫下來,但是你從來不知道...
14.“我不知道這意味著什么,“
你能遇到的最糟糕的情況就是看一看代碼,完全不知道所以然,這可能來自于你自己的專案,也可能是其他什么人的專案,但都是同樣的問題,現在你不得不去決定是否值得花更多的時間尋找替代方案,或者剖析代碼以了解其作業原理,
15.“我在想花錢找人幫我修復這個問題得花費多少?”
鋪天蓋地的招聘額外開發者的想法是很誘人的,但很顯然其可行性不及財務上的可行性,再加上如果不是你自己把手弄臟的,那你怎么從所有這些錯誤中學到教訓?當你在許多次失敗以后,最終理解了一個編程的概念時將會很有成就感,但這種思想并不總是能在我的腦海閃過,
16. “這個 API 怎么能沒有檔案呢?!”
使用一個具有糟糕檔案的插件或者框架時,最令人沮喪的事情是你不得不自己深入閱讀源代碼,我推崇的專案是,那些開發人員花時間特別設計出一個有用文 檔頁的 專案,所有的引數與選項都被予以解釋,可能甚至會在一些案例代碼片段中使用出現,但是遺憾的是事實并不總是如此,最簡單的辦法就是遠離檔案貧乏的作業,以 免你自己陷入不幸,
17. “我當然希望我留下了那個資料庫的一份拷貝…”
在撰寫代碼并進行除錯的時候,我總是想不起備份,然而,資料備份提供了一個墊腳石,使我們可以回到我們實施了某種更改之前的時刻,對一個生產環境的 服務器 這個特別有用,在那個環境中變化總是在瞬間完成的,
記住保留網站檔案和資料庫的本地拷貝,以備不時之需!這或許是很煩人的任務,但這也沒有比重新創建一個 被破壞的SQL資料庫更煩人,
18. “能讓這個正常作業的最快的解決方案是什么?”
在東跌西撞的尋找了幾小時的自定義解決方法后,很明顯你需要一個新的方案了,程式員們都是希望功能正常運轉之后,再去考慮介面設計的優雅問題,
要確定最快最準確的解決方案,并應用它使之盡快的開始作業,然后,就可以放松心情去追求程式的美感了,
19.“放棄這個,從頭開始,”
有時在嘗試了長時間解決方案后,你需要把你的作業檔案轉移到歸檔目錄(或洗掉),然后從頭開始,考慮到前一小時辛苦這確實是個艱難的決定,但當我謹記前車之鑒重新開始時這往往是專案走向完成所應該看到的,
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/250074.html
標籤:其他
