報警系統中的思維轉變

2022-09-20 05:39:10 字數 1451 閱讀 9201

在我的開發中,將報警系統分解為了以下幾個部分: 1、規則配置部分   2、指標獲取部分   3、指標判斷部分   4、結果處理部分

可以看出雖然這是乙個報警系統,但在我劃分的部分中卻未有提及報警二字,這中間是有乙個我思維轉變的過程的。

在最開始設計報警系統時,我總有乙個先入為主的觀念。認為某某指標值若落入報警範圍就該產生報警行為,沒落入就捨棄了。在隨後的開發中,我發現這種觀念有兩個不便之處。

1) 某某值:實際就是對單一的指標值進行判斷,但現實的情況大多是分析一定範圍的指標值才會產生是乙個合理的報警行為。

2) 落入報警範圍與沒落入報警範圍:這樣不利於乙個靈活的報警機制,而且實際上只處理了部分資料,沒有處理未落入報警範圍的資料,不利於將來系統的擴充套件。

所以為了解決這種情況,

1) 維護乙個佇列:佇列記錄了一定範圍內的所有指標值,合力判斷報警狀態。

2) 對數軸劃分區間:利用不同的閾值對數軸劃分區間,任何指標值過來了,不管它是否該被報警,先判斷它屬於哪個區間,然後打上這個區間的狀態,這樣利用佇列,逐漸積累指標狀態,根據不同的報警策略產生不同的報警狀態,進而產生報警行為。將來想選取任意範圍的資料報警,找到對應區間的報警狀態就好。

可以看到,我在處理指標資料時,第一種思維是:報警目的 --> 分析資料;

第二種思維是:分析資料 --> 報警目的。

就我現在看來,在開發報警系統時,第二種思維是更好的,即:弱化本來目的,忠於資料本身。

2013.12.18 更新

1)面對乙個類時,想到的是:輸入、環境配置、輸出。不要把環境配置當成輸出。

2)類和公共函式記得寫說明;注意各種東西的命名

3)一定要明白什麼東西是屬於什麼應該知道的的。比如,monitorstate應該是屬於程式應該知道的,而不是過多的在資料庫中反應,因為是程式在執行這個monitor,只要它自己最清楚,如果反應在資料庫中,無論如何都是經過了程式這一道手才到資料庫的。monitortime,ismailed應該屬於monitorconfig應該知道的,與sdalert無關,sdalert只記錄具體的配置引數,monitorconfig記錄monito的狀態。如果這裡想不清楚,很容易就把monitortime,ismailed放到sdalert裡面去。

4)要多考慮異常處理,至少要寫個日誌什麼的吧?

2014.2.1 更新

1)要注意變數命名風格,c#的

public

屬性一般用

pascal

命名規則,即每個單詞的首字母大寫,加下劃線的通常是

private

屬性。2)使用父類進行變數申明,引用子類的例項是多型性的表現

3)將各種屬性合成字串,再將字串還原成各種屬性,然後再使用,這是個很怪異的過程。在物件導向的程式設計方法中,直接設計物件和屬性即可。

4)命名問題和注釋問題。各個類都應該有詳細注釋說明這個類的用處,在整體架構中所處的位置等等。

交易思維的轉變

交易的思維要轉變 之前之所以虧損,是因為思維是扭曲倒置的,僅僅只著眼於所謂的術。放縮量 假陰線 一線天等等等等。術本身沒有問題,問題在於忽略了道,也就是市場規律 勢 大週期 小週期 大週期 勢 的轉變。大部分時間醉心於分時的上下波動,內心跟隨波動無處安放,而忽略了交易最核心的本質。交易最核心的便是買...

思維習慣的轉變

這幾天在寫乙份設計文件。本來作為乙個簡單的初步設計文件的草稿,應該考慮的是我們需要做的是什麼,大致上的功能怎樣劃分,有哪些非功能性的需求等。但是,在考慮這些問題的時候,總是不自覺的就想到了 這個功能我們應該採用什麼技術來實現,該怎樣實現,有哪些問題或者技術需要進一步的研究或者學習。這讓我想起了在以前...

SQL到NOSQL的思維轉變

nosql系統一般都會宣傳乙個特性,那就是效能好,然後為什麼呢?關係型資料庫發展了這麼多年,各種優化工作已經做得很深了,nosql系統一般都是吸收關係型資料庫的技術,然後,到底是什麼因素束縛了關係型資料庫的效能呢?我們從系統設計的角度看這個問題。1,索引支援。關係型資料庫創立之初沒有想到今天的網際網...