自動化平臺開發的幾點總結

最近花了些時間在琢磨自動化平臺開發的事情，所以每天都會抽出幾個小時來寫一寫，大方向的開發任務算是逐步有了眉目。如果客觀來說，這部分的工作算是完成了20%左右。前期花在基礎架構上的功夫比較多。

為了方便平臺化的開發，我主要考慮了一下幾點：

1. 動態選單，不同許可權，不同業務的人看到的選單是不一樣的

2. 對於許可權的粒度把握，增刪改查的業務許可權盡管宣告瞭不同的選單許可權，但是許可權的粒度還是需要考慮的。

3. 對於操作日誌的記錄，做了什麼操作，哪些操作這些資訊還是需要格外重視的。

4. 基礎功能實現可配置化，比如選單，許可權，這些都是基礎的資料，完全實現配置化的工作，會讓整個平臺的可操作性提高不少。

從最開始的時候，我是本著從簡的思路，能用一個表搞定，絕對不適用兩個表。設計的時候，允許部分的資料冗餘，確切的說，我不喜歡過度設計，因為耦合度太低，最終還是要花大力氣整合起來。

模型設計中的列舉值

在前期的準備過程中，最開始寫頁面的時候，對於列舉值都是在MTV的M層來定義，我在models.py檔案裡面做了很多的配置，但是發現按照這種擴充套件的方式，後期處理就很尷尬了。因為ORM層面的對映是體現不出這種列舉值的差異的。而且資料從後端到前端，還得逐個轉換一般，比如這種方式，在實際的前端頁面中，還需要二次過濾，看起來實現了配置化，但是效率確實不高。

class Cmdb_server(models.Model):

db_types_choices = (

('mysql', u'MySQL'),

('redis', u'Redis'),

('greenplum', u'GreenPlum'),

)

db_role_choices =(

('master', u'Master'),

('slave', u'Slave'),

)

server_status_choices = (

('1','online'),

('0','fault'),

('2','offline'),

)

server_os_hostname = models.CharField(max_length=50,verbose_name='主機名')

所以越是擴充套件和改變程式碼，發現這個地方越來越是一個坑，所以在後面果斷使用了資料字典的配置方式來統一管控。

動態二級選單

我希望實現的一個比較規範的功能就是動態選單，即不同許可權的使用者看到的選單項是不同的。前後改了好幾版，總算是把整個流程調通了。

設計到細節的時候，發現很容易有使用的歧義或者不明確的地方。

二級選單的設計真是一把辛酸淚，最開始感覺這個很簡單，一個for迴圈能夠搞定，但是落實到程式碼層面，琢磨了很多想法，發現自己最開始的切入點就不太對，迴圈輸出HTML標籤，結束標籤的迴圈就是一個技巧了。

寫了很多版本，至少有6個版本，有的選單不夠穩定，有的顯示出來亂七八糟的。拿著程式碼反反覆覆看了多遍，趕緊還是有點抓耳撓腮的感覺，於是乎直接把關鍵程式碼列印出來，在那兒盤算了一會，總算是得出了滿意的答案。

改造一個統一的模板

開發這個平臺的時候，如果為了降低開發的難度，提高資源的可重複效率，是用統一的模板，然後在這個基礎上修修改改即可。但是實際上自己看了很多原型之後，發現目前的實現和現在的存在著較大的差異。所以這樣一個件看起來不鬧心的事情，自己就花了一些精力，專門來做統籌的工作。

按照優先順序，否則易陷入死衚衕

在開發的過程中，總是會冒出一些想法來，想自己能夠實現一些比較好的功能，但是實際上，這個過程總是事與願違。一個看起來簡單的功能，想追求完美，但是實際這樣下來，效率不高，效果反而會差一些。還是需要按照優先順序來做，而不要總是被打斷。