後端開發時碰到的一些情況和一些思考

2021-10-08 19:45:38 字數 674 閱讀 6381

後台返回給前端的提示語需要和客戶溝通。

有個介面不呼叫了,需要在舊的呼叫的地方返回提示語句說明一下不呼叫了。

我在這個地方改了,覺得簡單,沒想過會不會涉及其他的地方,也沒測過,直接給測試人員測,出現問題了。 問題詳細不便描述,但解決的方法捋清了邏輯如下:

舊的邏輯:

判斷某個物件是否存在

不存在,呼叫介面。存在,連線本地資料庫查詢。

錯誤邏輯:

判斷某個物件是否存在

不存在,返回提示資訊。存在,連線本地資料庫查詢。

新的邏輯應該為:

判斷某個物件是否存在

不存在,不呼叫介面,返回提示資訊1。存在,判斷該物件的某欄位是否為調介面的型別,是則返回提示資訊2,否則連線本地資料庫查詢。

這個介面不是不呼叫,而是改為,根據新增的某個字段判斷是否呼叫已經公升級成新版本新介面位址的介面。在某些情況下調不通新街口,後來確定那些調不通的情況下不調了,返回些提示資訊就行了。

根據新字段呼叫公升級後介面版本二是我寫的。後來實際情況,在某些情況下調不通,確定了那些調不通的情況下不調了,返回些提示資訊,是大家一起拍板定的,我卻沒考慮到,公升級後介面版本二的根據欄位的呼叫對不呼叫了的情況的影響,而且自己沒測過,返工了。

下次多思考,多測。盡量沒有下次。

flask前後端分離碰到的一些坑

首先 flask多對多關係 多對多關係,中間表使用table,定義乙個用於關係的輔助表,不對中間表直接操作,網上基本上都說強烈建議 不 使用模型,採用乙個實際的表。我也就這樣用了,course class relation db.table course class relation db.colu...

銀行IT的一些情況

一.銀行it是什麼?銀行it首先是銀行,其次是it。這個理解因人而異 銀行是經營風險的企業,對所有銀行iter來說,第一位的就是把控風險,在這個主旨之上展開工作,明白這個就能明白為什麼銀行it不是個技術愛好者的好去處,這裡先求穩,再求新,熱愛技術的人,想施展開很難。二.銀行it做什麼?銀行it這個定...

WEB開發時的一些思考

這星期在整理工程的文件。發現一些問題。1 dao層應該進行具體的操作還是抽象程度高的操作?抽象程度越高,復用的可能性就越大。但是效率上確實眼睜睜看著它提高不了。2 dao層的操作應該事先準備完整的 增刪改查 還是等用到的時候再針對性的增加?由於當初在開始建立工程時,時間緊迫而且需求不清晰,所以dao...