Có một mô hình lập trình nào thúc đẩy việc tạo ra sự phụ thuộc cực kỳ rõ ràng đối với các lập trình viên khác không?


26

Tôi làm việc trong Kho dữ liệu cung cấp nhiều hệ thống thông qua nhiều luồng và lớp với các phụ thuộc giống như mê cung liên kết các tạo phẩm khác nhau. Gần như mỗi ngày tôi gặp phải những tình huống như thế này: Tôi chạy một cái gì đó, nó không hoạt động, tôi trải qua vô số mã nhưng nhiều giờ sau tôi nhận ra mình đã khái niệm được bản đồ quy trình của một phần nhỏ những gì tôi biết bây giờ sau đó trong ngày là bắt buộc, vì vậy tôi hỏi ai đó và họ nói với tôi rằng luồng khác này phải được chạy trước và nếu tôi kiểm tra ở đây (chỉ ra một phần dường như tùy ý của một đống lớn các phụ thuộc được mã hóa khác), thì tôi sẽ có Xem cái này đi. Thật là bực bội vô cùng.

Nếu tôi có thể đề xuất với nhóm rằng có lẽ đó là một ý tưởng tốt nếu chúng tôi làm nhiều hơn để làm cho sự phụ thuộc giữa các đối tượng rõ ràng và rõ ràng hơn, thay vì nhúng chúng sâu vào các mức mã đệ quy hoặc thậm chí trong dữ liệu phải có mặt do nó được tạo ra bởi một luồng khác, có lẽ bằng cách tham khảo một mô hình phần mềm nổi tiếng, đã thử và đã thử nghiệm - sau đó tôi có thể làm cho công việc của mình và mọi người khác đơn giản hơn rất nhiều.

Thật khó để giải thích những lợi ích của việc này với nhóm của tôi. Họ có xu hướng chỉ chấp nhận mọi thứ theo cách của họ và không 'nghĩ lớn' khi thấy lợi ích của việc có thể khái niệm hóa toàn bộ hệ thống theo một cách mới - họ thực sự không thấy rằng nếu bạn có thể mô hình hóa một hệ thống khổng lồ sau đó, nó sẽ giúp bạn ít gặp phải sự thiếu hiệu quả của bộ nhớ, ngăn chặn các ràng buộc duy nhất và các khóa trùng lặp, dữ liệu vô nghĩa vì việc thiết kế nó phù hợp với tầm nhìn ban đầu và sau đó bạn sẽ không gặp phải những vấn đề này bây giờ chúng ta đang trải qua, điều mà tôi biết là khác thường từ những công việc trước đây, nhưng dường như họ nghĩ là không thể tránh khỏi.

Vì vậy, có ai biết về một mô hình phần mềm nhấn mạnh sự phụ thuộc và cũng thúc đẩy một mô hình khái niệm chung của một hệ thống nhằm đảm bảo sự tuân thủ lâu dài với một lý tưởng không? Hiện tại chúng ta có khá nhiều mớ hỗn độn và giải pháp mỗi lần chạy nước rút dường như là "chỉ cần thêm vào điều này ở đây và ở đây" và tôi là người duy nhất lo ngại rằng mọi thứ thực sự bắt đầu sụp đổ.


2
Bạn có thể làm rõ loại "phụ thuộc giống như mê cung liên kết các cổ vật khác nhau" này là gì không? Có phải họ xây dựng các phụ thuộc, có thể được giải quyết bằng một công cụ xây dựng như Maven không? Chúng có phụ thuộc đầu vào không, trong đó một trong những đồ tạo tác này phụ thuộc vào một số đầu vào không rõ ràng hoặc không rõ ràng? Có phải chúng phụ thuộc chính giữa các bảng cơ sở dữ liệu?
Thất

Hệ thống này là PLSQL, Unix bash, OWB, v.v. nên có đủ loại phụ thuộc. Đôi khi dữ liệu được yêu cầu ở một định dạng nhất định, ở một nơi nhất định, tại một thời điểm nhất định, bởi một mô-đun nhất định, nhưng nó không rõ ràng từ mã và chỉ có thể được phân biệt theo hai cách: bằng cách đi qua một núi mã, có lẽ mất nhiều ngày, để tìm ra rằng một số dữ liệu có dấu chấm phẩy trong một phần của hệ thống mà bạn thậm chí không biết là đã được tham chiếu vì nó được chôn trong 10 lớp mã được gọi đệ quy, hoặc bằng cách hỏi ai đó, tất cả Thời gian, mọi lúc. Nó không thúc đẩy sự độc lập.
Christs_Chin

4
Nghĩa đen là tất cả trong số họ
Miles Rout

3
Tiếp tuyến nhỏ: Vì Haskell lười biếng, bạn thực sự không chỉ định thứ tự các hoạt động khi bạn viết mã. Bạn chỉ xác định phụ thuộc. Hàm C phụ thuộc vào kết quả của hàm A và B. Vì vậy, A và B phải được chạy trước C, nhưng nó có thể hoạt động tốt như nhau nếu A được chạy trước hoặc nếu B được chạy trước. Tôi chỉ nghĩ rằng đó là thú vị.
GlenPeterson

1
Có một cuốn sách được gọi là Mẫu thiết kế (cuốn sách hút, nhưng hầu hết những gì nó nói là tốt, ngoại trừ một chút về singleton). Nó có một số phần về quản lý phụ thuộc.
ctrl-alt-delor

Câu trả lời:


19

Khám phá

Sự vắng mặt của nó làm khổ nhiều tổ chức. Công cụ mà Fred xây dựng lại ở đâu? Trong kho Git, chắc chắn. Ở đâu?

Mẫu phần mềm xuất hiện trong tâm trí là Model-View-ViewModel. Đối với người không quen biết, mô hình này là một bí ẩn hoàn toàn. Tôi giải thích với vợ tôi là "năm vật dụng nổi trên bàn nói chuyện với nhau thông qua một thế lực bí ẩn nào đó". Hiểu mô hình, và bạn hiểu phần mềm.

Nhiều hệ thống phần mềm không thể ghi lại kiến ​​trúc của chúng vì chúng cho rằng nó tự giải thích hoặc xuất hiện tự nhiên từ mã. Nó không phải, và nó không. Trừ khi bạn đang sử dụng một kiến ​​trúc được xác định rõ, những người mới sẽ bị lạc. Nếu nó không được ghi lại (hoặc nổi tiếng), những người mới sẽ bị lạc. Và các cựu chiến binh cũng sẽ bị lạc, một khi họ đã rời xa mã trong vài tháng.

Trách nhiệm của nhóm là đưa ra một kiến ​​trúc tổ chức hợp lý và ghi lại nó. Điều này bao gồm những thứ như

  • Tổ chức thư mục
  • Tài liệu tham khảo dự án
  • Tài liệu lớp học (nó là gì, nó làm gì, tại sao nó tồn tại, nó được sử dụng như thế nào)
  • Dự án, mô-đun, lắp ráp, bất cứ tài liệu nào.

Trách nhiệm của nhóm là làm cho mọi thứ có tổ chức và có thể khám phá để nhóm không liên tục phát minh lại bánh xe.

Nhân tiện, quan niệm rằng "mã nên tự ghi lại tài liệu" chỉ đúng một phần. Mặc dù đúng là mã của bạn phải đủ rõ ràng để bạn không phải giải thích mọi dòng mã bằng một nhận xét, các mối quan hệ giữa các tạo phẩm như các lớp, dự án, tập hợp, giao diện và tương tự là không rõ ràng, và vẫn cần phải được ghi nhận.


3
Chắc chắn, nhưng những người dựa quá nhiều vào các mẫu thiết kế là một phần của vấn đề. Họ là những người viết mã mà không có bất kỳ tài liệu nào, cho rằng mọi người khác sẽ hiểu cái quái gì họ đã làm chỉ bằng cách nhìn vào mã. Ngoài ra, các mẫu thiết kế phần mềm không phải là kiến ​​trúc (đối với hầu hết các phần).
Robert Harvey

1
Công cụ mà Fred xây dựng lại ở đâu? Trong kho Git, chắc chắn. Ở đâu? - Chính xác! Mẫu MVC quá đặc trưng cho phát triển front-end (tôi nghĩ) và các mẫu chỉ hữu ích nếu mọi người trong nhóm biết chúng, vì vậy điều này chỉ chuyển vấn đề từ phụ thuộc không rõ ràng, đối với họ rõ ràng NẾU mọi người đều biết cách tìm họ Nhưng vấn đề giả định trước đây không phải là trường hợp. Vì vậy, tôi hy vọng có một cái gì đó thúc đẩy một cách thực sự rõ ràng để giải thích các phụ thuộc mà không yêu cầu một số khung khái niệm đã học khác để bạn sử dụng.
Christs_Chin

7
Nó được gọi là "tài liệu." Ngoài ra, bạn cần một khuôn khổ phụ thuộc hợp lý mà mọi người đều hỗ trợ. Thật không may, không có mẫu soạn sẵn mà bạn có thể thả vào dự án của mình; cấu trúc tổ chức của phần mềm là thứ mà nhóm của bạn tự tạo ra, với sự hỗ trợ của kiến ​​trúc hợp lý.
Robert Harvey

5
@RobertHarvey: Nghe khá gần đây: "Chúng tôi viết mã không cần tài liệu". Sai rồi. Bạn đang viết mã mà không có tài liệu.
gnasher729

3
Một số thứ tốt ở đây. NB có một sự khác biệt giữa viết mã không yêu cầu bình luận và viết tài liệu hỗ trợ.
Robbie Dee

10

Cách tốt nhất để tiếp cận các loại vấn đề này là tăng dần. Đừng nản lòng và đề xuất những thay đổi lớn về kiến ​​trúc. Những người sẽ không bao giờ được phê duyệt, và mã sẽ không bao giờ cải thiện. Điều đó giả định rằng bạn thậm chí có thể xác định các thay đổi kiến ​​trúc rộng, chính xác để thực hiện, điều này khó có thể xảy ra.

Có gì có khả năng là bạn có thể xác định một sự thay đổi nhỏ mà có thể đã giúp bạn những vấn đề cụ thể mà bạn chỉ giải quyết. Có lẽ đảo ngược một số phụ thuộc, thêm một số tài liệu, tạo ra một giao diện, viết một kịch bản mà cảnh báo về một sự phụ thuộc mất tích, vv Vì vậy, đề nghị rằng sự thay đổi nhỏ hơn để thay thế. Thậm chí tốt hơn, tùy thuộc vào văn hóa công ty của bạn, họ có thể chịu đựng hoặc thậm chí mong đợi bạn thực hiện những cải tiến như thế như một phần của nhiệm vụ ban đầu của bạn.

Khi bạn thực hiện những thay đổi nhỏ hơn này là một phần thường xuyên trong công việc của bạn và bằng ví dụ của bạn khuyến khích những người khác cũng làm như vậy, họ thực sự cộng lại theo thời gian. Hiệu quả hơn nhiều so với than vãn về những thay đổi lớn hơn mà bạn không được phép thực hiện.


2
Tôi đồng ý với ý tưởng thay đổi gia tăng. Vấn đề là, nếu không có một số nguyên tắc tổ chức đã có, bạn có thể sẽ tạo ra nhiều hỗn loạn hơn. Xem xét hiệu quả của việc di chuyển chỉ một dự án, lớp hoặc tạo tác khác (trong đó các mô-đun khác phụ thuộc) vào một vị trí hợp lý hơn.
Robert Harvey

1
Công cụ tuyệt vời. Những chuyến đi của tôi thường được thực hiện ít khó khăn hơn bởi một vài linh hồn siêng năng có nous để thêm một công cụ / vật dụng ở đây và ở đó để tạo ra trật tự từ sự hỗn loạn. Mặc dù tôi không phải là một fan hâm mộ của các tài liệu và các tài liệu, một bảng cheat được viết tốt hoặc danh sách các dấu gạch chéo của các tính năng / tính năng có thể giúp ích rất nhiều.
Robbie Dee

+1 để đề xuất các thay đổi nhỏ có khả năng được phê duyệt. Tôi đã trải nghiệm điều đó và nó giúp tôi trở thành một người có ảnh hưởng nhiều hơn, và sau đó các đề xuất của tôi có tác động nhiều hơn.
RawBean

2

Kiến trúc.

Không có nguyên tắc hay thực tiễn duy nhất, cụ thể, phổ quát nào giải quyết được các vấn đề về khả năng khám phá và bảo trì áp dụng cho tất cả các khía cạnh của tất cả các phần mềm. Nhưng, thuật ngữ rộng cho những thứ tạo ra một dự án lành mạnhkiến trúc.

Kiến trúc của bạn là toàn bộ các quyết định xung quanh từng điểm của sự nhầm lẫn tiềm năng (hoặc lịch sử) - bao gồm cả việc chỉ định cách các quyết định kiến ​​trúc được đưa ra và ghi lại. Mọi thứ liên quan đến quá trình phát triển, cấu trúc thư mục, chất lượng mã, các mẫu thiết kế, v.v. đều là những thứ có thể đi vào kiến trúc của bạn, nhưng không phải một trong số chúng kiến trúc.

Lý tưởng nhất, những quy tắc đó được thống nhất bởi một điểm kỳ dị của tâm trí.

Một nhóm nhỏ chắc chắn có thể tạo ra kiến ​​trúc hợp tác. Nhưng, với nhiều ý kiến ​​khác nhau, điều này có thể nhanh chóng dẫn đến một kiến trúc phân liệt rất không phục vụ để duy trì sự tỉnh táo của bạn. Cách đơn giản nhất để đảm bảo rằng kiến ​​trúc của bạn, và nhiều TLA và các mẫu trong đó, tất cả đều phục vụ cho sự thành công của nhóm với một tâm trí kỳ dị là tạo ra một tâm trí duy nhất chịu trách nhiệm cho họ.

Bây giờ, điều đó không nhất thiết đòi hỏi một "kiến trúc sư" cho triều đại giáo hoàng . Và, trong khi một số đội có thể muốn một người có kinh nghiệm chỉ đưa ra những quyết định đó, thì điểm chính là ai đó cần sở hữu kiến ​​trúc, đặc biệt là khi nhóm phát triển. Ai đó giữ ngón tay của họ trên nhịp đập của nhóm, thảo luận về kiến ​​trúc vừa phải, quyết định tài liệu và theo dõi các quyết định và công việc sắp tới để tuân thủ kiến ​​trúc và đặc điểm của nó.

Tôi không phải là một fan hâm mộ lớn của bất kỳ ai đưa ra tất cả các quyết định; nhưng, xác định một "kiến trúc sư" hoặc "chủ sở hữu sản phẩm kỹ thuật", người chịu trách nhiệm kiểm duyệt các cuộc thảo luận kiến ​​trúc và ghi lại các quyết định chống lại một tội ác lớn hơn: Sự khuếch tán trách nhiệm dẫn đến không có kiến trúc rõ ràng.


Bạn hoàn toàn chính xác trong việc xác định sự khuếch tán trách nhiệm là chịu trách nhiệm cho không có kiến ​​trúc rõ ràng. Các quyết định bây giờ chỉ mới được đưa ra gần đây để khắc phục vấn đề này. Tôi luôn nghĩ rằng một giải pháp tốt cho việc này sẽ là tạo ra toàn bộ hệ thống phân tán thông qua một hệ thống phần mềm khác hoạt động như một bộ khai thác, nơi bạn quyết định những gì đi vào hệ thống, nhưng nó quyết định nơi, theo cách mà kiến ​​trúc sư lập trình. Bạn sẽ có một cái nhìn vào nhiều hệ thống và công nghệ khác nhau và sẽ điều hướng chúng thông qua một số sơ đồ kiến ​​trúc hệ thống ...
Christs_Chin

Tôi nghĩ rằng quan điểm của bạn trong câu trả lời này là cách duy nhất để chống lại / ngăn chặn loại điều mà OP đang nói đến. Nó thậm chí còn áp dụng để kế thừa một mớ hỗn độn như OP có.
GWR

1

Chào mừng bạn đến với Kỹ thuật phần mềm (theo cả hai nghĩa);) Đây là một câu hỏi hay, nhưng thực sự không có câu trả lời dễ dàng, vì tôi chắc chắn bạn biết. Đó thực sự là một trường hợp phát triển thành các thực tiễn tốt hơn theo thời gian, đào tạo mọi người trở nên khéo léo hơn (theo định nghĩa, hầu hết mọi người trong ngành đều có năng lực tầm thường) ...

Công nghệ phần mềm như một ngành học phải chịu đựng nó trước tiên và thiết kế tâm lý khi chúng ta đi, một phần của sự nhanh chóng và một phần không cần thiết. Nó chỉ là bản chất của con thú. Và tất nhiên, các bản hack được xây dựng dựa trên các bản hack theo thời gian, vì các lập trình viên đã nói ở trên đưa ra các giải pháp chức năng một cách nhanh chóng để giải quyết nhu cầu ngắn hạn thường bằng chi phí giới thiệu nợ kỹ thuật.

Mô hình bạn cần sử dụng về cơ bản là có được những người tốt hơn, đào tạo những người bạn có tốt và nhấn mạnh tầm quan trọng của việc dành thời gian cho việc lập kế hoạch và kiến ​​trúc. Người ta không thể dễ dàng là "Agile" khi làm việc với một hệ thống nguyên khối. Nó có thể có kế hoạch đáng kể để đưa vào những thay đổi nhỏ. Có được một quy trình tài liệu cấp cao tuyệt vời tại chỗ cũng sẽ giúp những người chủ chốt nắm bắt được mã nhanh hơn.

Các ý tưởng bạn có thể tập trung vào sẽ (theo thời gian, dần dần) cô lập và tái cấu trúc các phần chính của hệ thống theo cách làm cho chúng trở nên mô đun và tách rời hơn, có thể đọc được, có thể duy trì. Bí quyết là làm việc này là yêu cầu kinh doanh hiện có, để giảm nợ kỹ thuật có thể được thực hiện đồng thời với việc mang lại giá trị kinh doanh rõ ràng. Vì vậy, giải pháp là một phần cải thiện thực hành và kỹ năng và một phần cố gắng hướng tới tư duy kiến ​​trúc dài hạn, như tôi có thể nói với bạn là đã có.

Lưu ý rằng tôi đã trả lời câu hỏi này từ góc độ phương pháp phát triển phần mềm thay vì quan điểm về kỹ thuật mã hóa bởi vì thực sự đây là một vấn đề lớn hơn nhiều so với các chi tiết về mã hóa hoặc thậm chí là phong cách kiến ​​trúc. Đó thực sự là một câu hỏi về cách bạn lên kế hoạch thay đổi.


6
Tôi nghe thấy những gì bạn nói, nhưng câu trả lời của bạn cuối cùng không thỏa mãn, và thẳng thắn một chút xúc phạm. Đó là một vấn đề lớn hơn là chỉ thuê những người giỏi hơn; ngay cả trong cửa hàng nhỏ mà tôi làm việc, chúng tôi cũng phải vật lộn với điều này và tôi nghĩ đó không chỉ là vấn đề của mọi người; Tôi nghĩ rằng nó có một số điểm đau kỹ thuật cụ thể.
Robert Harvey

1
Tôi đồng ý có các khía cạnh kỹ thuật, nhưng tôi nghĩ đó là những khía cạnh tương đối nhỏ so với việc nhấn mạnh vào một phương pháp mạnh mẽ hơn để thay đổi kế hoạch. Tôi không thấy điều này giống như về các mẫu thiết kế nhiều như một sự thay đổi văn hóa theo hướng lập kế hoạch và phân tích nhiều hơn, lập kế hoạch và phân tích sớm hơn và lập kế hoạch và phân tích tốt hơn .
Brad Thomas

Được rồi, tôi sẽ đăng câu trả lời của riêng tôi để so sánh. Tôi không nghĩ nó có liên quan đến các mẫu phần mềm.
Robert Harvey

Brad, cảm ơn vì câu trả lời. Phản hồi của bạn được đánh giá cao vì tôi biết tôi không đơn độc khi nhận thức được vấn đề này. Có vẻ như điều này trong đội của tôi. Tôi cũng đồng ý với Robert Harvey, rằng vấn đề này rất phổ biến và tôi không muốn từ bỏ niềm tin rằng có một giải pháp, trong một loại phần mềm mới hoặc một cách làm việc mới.
Christs_Chin

2
Chính xác là kinh nghiệm của tôi: bạn phải khiến các thành viên trong nhóm hiểu những gì họ đang làm. Tôi thấy mọi người trộn MVVM và MVC, những người khác sử dụng các điều khiển WPF theo cách bình thường với Windows Forms (hay đúng hơn là: VB6), mọi người lập trình trong C # mà không hiểu cơ bản về hướng đối tượng ... Dạy cho họ. Dạy chúng một lần nữa. Nản lòng. Dạy chúng một lần nữa, ... Thường nghĩ đến việc từ bỏ. Và dạy họ một lần nữa ...
Bernhard Hiller

1

Tôi thích ý tưởng về các quy ước của @ RobertHarvey và nghĩ rằng chúng có ích. Tôi cũng thích ý tưởng của @ KarlBielefeldt là "tài liệu khi bạn đi" và biết rằng đó là điều cần thiết bởi vì đó là cách duy nhất để giữ tài liệu hiện tại. Nhưng tôi nghĩ rằng ý tưởng bao quát là việc ghi lại cách tìm tất cả các đoạn mã của bạn, xây dựng và triển khai chúng là rất quan trọng!

Gần đây tôi đã gửi email cho một dự án nguồn mở quan trọng có một số cấu hình XML tạo mã hoàn toàn không có giấy tờ. Tôi đã hỏi người bảo trì, "Quá trình tạo mã XML này được ghi lại ở đâu? Thiết lập cơ sở dữ liệu thử nghiệm được ghi lại ở đâu?" và anh ta nói, "Không phải." Về cơ bản, đây là một dự án đóng góp duy nhất và bây giờ tôi biết tại sao.

Hãy nhìn xem, nếu bạn là người đó và bạn đang đọc cái này, tôi thực sự đánh giá cao những gì bạn đang làm. Tôi thực tế tôn thờ thành quả lao động của bạn! Nhưng nếu bạn dành một giờ để ghi lại cách thức các công cụ thực sự sáng tạo của bạn được kết hợp với nhau, tôi có thể dành một vài ngày để mã hóa các tính năng mới có thể giúp bạn. Khi phải đối mặt với bức tường gạch "thiếu tài liệu không phải là vấn đề", tôi thậm chí sẽ không thử.

Trong một doanh nghiệp, việc thiếu tài liệu là một sự lãng phí rất lớn thời gian và năng lượng. Các dự án như thế thường được đưa ra cho các chuyên gia tư vấn có chi phí cao hơn, chỉ để họ có thể tìm ra những thứ cơ bản như, "tất cả các mảnh và chúng khớp với nhau như thế nào".

Cuối cùng

Điều cần thiết không phải là quá nhiều công nghệ hay phương pháp, mà là sự thay đổi văn hóa; một niềm tin được chia sẻ rằng ghi lại cách mọi thứ được xây dựng và tại sao lại quan trọng. Nó phải là một phần của đánh giá mã, một yêu cầu để chuyển sang sản xuất, gắn liền với tăng. Khi mọi người tin điều đó và hành động theo nó, mọi thứ sẽ thay đổi. Mặt khác, nó sẽ giống như đóng góp nguồn mở thất bại của tôi.


2
Tôi nghi ngờ rằng một phần của vấn đề văn hóa nằm ở niềm tin của Agile rằng "nếu nó không phải là một phần của Câu chuyện người dùng (nghĩa là nó không đóng góp trực tiếp vào giá trị của các bên liên quan), thì điều đó không quan trọng." Chuyện nhảm. Cuộc trò chuyện liên quan ở đây: Trong nhanh, các nhiệm vụ cơ sở hạ tầng cơ bản khi bắt đầu một dự án được lên kế hoạch và phân bổ như thế nào?
Robert Harvey

@RobertHarvey Có. Mọi người trong đội của tôi đều vô cùng sáng dạ và rất dễ hòa đồng. Các bậc thầy scrum và người quản lý dự án có ý định và định hướng tốt, và các thực tiễn là Agile nhất trong đó tôi đã làm việc. Nhưng tài liệu còn thiếu, có lẽ vì chính lý do bạn đề xuất. Ngoài ra, khi tài liệu được tạo ra, một lớp ngẫu nhiên nữa về hiệu quả giao tiếp được đưa ra trong khả năng của người đó để xác định các khái niệm thích hợp và cũng để giải thích chúng, không đề cập đến thái độ của họ đối với việc phải thực hiện một nhiệm vụ như vậy. Thông thường, đó chỉ là "Hỏi ai đó"
Christs_Chin

@GlenPeterson Vâng, tôi đồng ý rằng điều này sẽ hữu ích. Nhưng nó nên được chỉ định không chỉ là nó nên được xây dựng, mà còn cả cách thức và những gì đủ điều kiện là tài liệu. Ví dụ như một ví dụ gần đây ở đây, một người nào đó bao gồm một danh sách các số mới mà hệ thống của chúng tôi sẽ xác định. Đó là nó. Không có đề cập đến việc làm thế nào những con số này vào hệ thống, ở đâu, tại sao, bởi ai, tần suất hoặc bất cứ điều gì hữu ích, chỉ có họ làm. Không có gì tôi đã tự hỏi những con số hệ thống của chúng tôi sẽ xác định là có liên quan. Nhưng tôi thường tự hỏi, họ vào đâu, đi đâu và làm gì trên đường đi. Nó vẫn còn là một bí ẩn.
Christs_Chin

1
@Christs_Chin Rất nhiều giao tiếp dựa trên ngữ cảnh. Không có bối cảnh đó, hầu hết các thông tin liên lạc gần như vô nghĩa. Tôi cảm nhận được nỗi đau của bạn. Nhưng tôi nghĩ thật khó để viết (tiếng Anh) để người khác có thể hiểu bạn. Đôi khi các thông số kỹ thuật ban đầu cho một hệ thống có bối cảnh bạn cần hiểu nó ngay cả khi chúng đã lỗi thời khủng khiếp, bối cảnh thường giúp ích.
GlenPeterson

1

Để trả lời câu hỏi như được đặt ra (thay vì cho bạn lời khuyên cho tình huống cụ thể của bạn):

Mô hình lập trình được gọi là lập trình hàm thuần túy đòi hỏi mọi thứ ảnh hưởng đến đầu ra của hàm phải được chỉ định trong các tham số đầu vào. Không có phụ thuộc ẩn hoặc biến toàn cục hoặc các lực bí ẩn khác hoạt động vô hình trên cơ sở mã. Không có "bạn phải làm điều này đầu tiên" khớp nối tạm thời.


0

Mỗi kho dữ liệu là khác nhau nhưng có rất nhiều thứ bạn có thể làm để làm cho mọi thứ dễ dàng hơn cho chính mình.

Để bắt đầu, tất cả các hàng trong cơ sở dữ liệu đã có một DATE_ADDEDDATA_UPDATED cột vì vậy chúng tôi có thể nhìn thấy khi nó được bổ sung vào cơ sở dữ liệu và khi nó đã thay đổi. Chúng tôi cũng đã có một cột SOURCE_CODE để chúng tôi có thể theo dõi từng bit dữ liệu được nhập vào hệ thống.

Tiếp theo, chúng tôi đã có các công cụ phổ biến chạy trên tất cả các kho dữ liệu của chúng tôi, chẳng hạn như sắp xếp, khớp bảng, máy thái và dicers, v.v.

Mã Bespoke được giữ ở mức tối thiểu và thậm chí sau đó, nó phải xác nhận các kiểu mã hóa và báo cáo khác nhau.

Tôi sẽ giả định rằng bạn đã quen thuộc với bộ ETL . Có rất nhiều chức năng bạn có được miễn phí những ngày này không có mặt khi tôi tham gia trò chơi khoảng một thập kỷ trước.

Bạn cũng có thể muốn xem xét các bảng dữ liệu để trình bày một phiên bản vệ sinh, thân thiện hơn của kho dữ liệu của bạn. Tất nhiên không phải là viên đạn bạc nhưng có thể giúp giải quyết một số vấn đề nhất định thay vì phải xây dựng lại / sửa kho dữ liệu của bạn.


cảm ơn vì phản hồi Có, chúng tôi sử dụng tất cả các trường này, nhưng chúng chỉ thực sự hỗ trợ việc xác định một hàng duy nhất, không phụ thuộc giữa các luồng, lớp và hệ thống. Bạn nói đúng về các bộ ETL - chúng tôi đang trong quá trình nâng cấp lên một công cụ ETL nổi tiếng từ một công cụ không còn hỗ trợ nhưng thay vào đó, cuối cùng lại chuyển về PLQuery. Mã hóa tốt, nhưng để duy trì và hiểu hệ thống tổng thể từ cấp mã, điều đó hoàn toàn khủng khiếp.
Christs_Chin

1
Lý tưởng là bạn có thể theo dõi dữ liệu từ đầu đến cuối thông qua các bảng phân tầng hoặc các tệp phẳng nhưng nếu bạn không có điều đó, bạn sẽ để lại mã đi bộ.
Robbie Dee

0

Tôi không biết nó có liên quan đến trường hợp của bạn đến mức nào, có một số chiến lược để làm cho sự phụ thuộc rõ ràng hơn và bảo trì mã chung-

  • Tránh các biến toàn cục, sử dụng tham số thay thế. Điều này cũng áp dụng cho các cuộc gọi ngôn ngữ chéo.
  • Tránh thay đổi / biến đổi giá trị của các biến, càng nhiều càng tốt. Tạo một biến mới và sử dụng, khi bạn cần thay đổi giá trị, nếu có thể.
  • Làm cho mã mô-đun. Nếu không thể mô tả phần nào (không phải như thế nào) thực sự đang làm trong một câu đơn giản, hãy chia nó thành các mô-đun thỏa mãn điều kiện.
  • Đặt tên cho các phần mã của bạn đúng cách. Khi bạn thực sự có thể mô tả những gì một phần mã đang làm theo các thuật ngữ đơn giản, các thuật ngữ đó trở thành tên của phần đó. Do đó, mã trở thành tài liệu tự thông qua tên của các mô-đun / lớp / hàm / thủ tục / phương thức, v.v.
  • Kiểm tra mã của bạn. Kiểm tra xem các thực thể trong mã của bạn biện minh cho tên của chúng, đã thảo luận ở điểm trước.
  • Đăng nhập các sự kiện trong mã. Ít nhất duy trì hai cấp độ của nhật ký. Đầu tiên luôn được bật (ngay cả trong sản xuất) và chỉ ghi nhật ký các sự kiện quan trọng. Và sử dụng cái khác để đăng nhập cơ bản mọi thứ, nhưng có thể được bật hoặc tắt.
  • Tìm và sử dụng các công cụ phù hợp để duyệt, duy trì và phát triển cơ sở mã của bạn. Ngay cả một tùy chọn "Tìm kiếm mọi thứ" đơn giản của Visual Studio Code cũng giúp cuộc sống của tôi dễ dàng hơn rất nhiều đối với một số trường hợp nhất định.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.