#極客觀點 聚焦於技術方向、程式設計師職業發展、個人成長等主題，致力於發起有價值的討論，輸出有價值的觀點。
在本欄目中，我們將為大家推薦在 #極客觀點 版塊被熱烈討論的話題，甄選出有趣的觀點為你呈現。期待我們一起成長和進步呀 ??
今日關鍵詞：#低程式碼 # Docker # 成長
話題發起人：程式設計師海軍
每個人都有迷茫的階段，你是怎麼突破走出來的？
有趣的觀點：
有計劃，有目的的學習
確定自己當前所屬的階段
學習處於當前階段的一些方法論，指導思想
理論結合實際給自己梳理文件
example
主要工作為開發階段
儘可能瞭解當前專案對應技術棧
保持瞭解技術動態，
瞭解新技術出現原因，解決的核心問題
學習程式碼架構的各種方法論，學習一些優秀專案的設計
帶來團隊階段
學習技術管理的協議方法論
提升技術判斷能力
瞭解業界態勢，技術形式
瞭解當前產品的商業邏輯
能對自己做的事情自上而下的思考，思考公司為什麼需要你的團隊
——社群使用者：百五
有趣的觀點：
遇到問題 - 解決問題的時候，問題越大，成長越快。
——社群使用者：ShirleyYD
話題發起人：莉香
有趣的觀點：
低程式碼的概念最近 3 年很火，很大大小廠都在發力。但它到底是好是壞，業界至今沒有一致的結論。
這也正常，這就像“哪種程式語言最好？”這種問題一樣，永遠不可只有一個答案，因為脫離場景討論技術，是不科學的。
低程式碼平臺有個大眾化的定義：無需編碼（ 0 程式碼）或透過少量程式碼就可以快速生成應用程式的開發平臺。
對於不懂程式碼（或只懂少許程式碼）的人，低程式碼的開發效率極高，因為他們可以用 2 個小時就可以做出一個表單、一個 OA 請假系統...
總的來講，它的開發效率到底怎麼樣，是和使用場景強繫結的。如果低程式碼這種通用功能能夠滿足你，那麼他的效率就是滿級，但倘若你有更多的耿興華開發，那麼它可能就不適合了。
——社群使用者：YourBatman
有趣的觀點：
其實就對於開發來說其實很多指標都是無法直接量化的，因為都和實際業務需求相掛鉤。
就我所接觸的低程式碼平臺/框架，確實對於簡單的一些管理後臺可以說是原本需要 3 人的開發小組，現在只需要2個開發就可以搞定。
資料大屏甚至是 1 個實習生搭配一個後端就可以完成，而且實習生越熟練開發效率也就越高。具體參考宜搭或者帆軟。
而低程式碼的侷限性就在這裡，如果命中了他的業務場景那麼就會很快捷便利的就可以使專案落地。
但只要有一部分超出了當初設計的業務場景那麼就還是需要去人工維護業務程式碼。
從高定製性的複雜業務平臺開發角度來說，有35%的場景通用、高重複的場景可以依靠低程式碼來完成，其餘的功能還是和原來一樣開發流程開發。能加快一定的開發進度，但十分有限。
原本計劃 10 個月左右的開發計劃，大概累計可以加快 2~3 個月的樣子。
——社群使用者：陟上晴明
話題發起人：taskctl
如題，有一篇相關論文提到了 docker 。我隨便看了看感覺這東西缺點很多，儘管安裝後使用可以省掉很多安裝第三方庫的時間，但是docker自己的執行存在很大問題，而且後期修改，各種埠對映、虛擬機器和容器的定義，也實在難為我這種不是科班出身的人
想問一下各位對docker有什麼理解，是我理解的不對嗎？還是有些優點我沒發現？
有趣的觀點：
後期修改，各種埠對映、虛擬機器和容器的定義？
後期修改：非常方便，改一下 Dockerfile，重新打一下映象就好
各種埠對映：同理，非常方便（或者說是世界上最方便的），只要改一下 docker-compose 就好
虛擬機器和容器的定義：Docker 和虛擬機器沒有任何關係。糾結定義也是毫無意義的
用 Docker 記住一件事情，映象是可變的，容器是不可變的，永遠不要想著修改已經存在的容器。
例如： 少加了一個埠對映，改改容器，加一個。這是錯誤的，容器是不可變的，要加埠，就重新跑一個容器
——社群使用者：ponponon
有趣的觀點：
使用場景很多。目前我正在用它計劃滿足單位內部各種編譯環境衝突，看中了他的隔離性（很多軟體的依賴互相沖突），如果用虛擬機器又太笨重，用容器剛好。目前是就安全性（檔案隔離,許可權隔離,困擾我）
——社群使用者：自然
他們的觀點和討論是否也能帶給你啟發呢？你又有什麼有趣的觀點，希望與大家分享？
快掃描二維碼加入我們，一起交流成長吧，等你哦 ???歡迎在評論區留下你的觀點呀~
