Có phải là bình thường khi tôi không thể giữ trong đầu nhiều hơn ba lỗi được gán cho tôi, tôi cũng không thể hiểu hàng ngàn dòng mã spaghetti?


19

Tôi đang làm việc trên một cơ sở mã cũ mà ... không hoàn hảo , trong một môi trường cũng không. Đó không phải là cơ sở mã hóa tồi tệ nhất tôi từng thấy trong đời, nhưng vẫn còn nhiều vấn đề: kiểm tra đơn vị bằng không; phương thức với hàng ngàn dòng mã; hiểu sai các nguyên tắc hướng đối tượng cơ bản; v.v.

Nó đau để duy trì mã.

  1. Mỗi lần tôi phải gỡ lỗi một ngàn dòng của một phương thức được viết xấu với các biến được sử dụng lại khắp nơi, tôi hoàn toàn bị mất.
  2. Một số sửa đổi hoặc tái cấu trúc Tôi đã thực hiện các lỗi giới thiệu ở những nơi khác của ứng dụng.
  3. Không có bất kỳ tài liệu, bài kiểm tra hoặc kiến ​​trúc có thể quan sát được và kết hợp với các phương pháp được đặt tên xấu, tôi cảm thấy rằng tôi lấp đầy tất cả bộ nhớ làm việc có sẵn của mình. Không còn chỗ cho tất cả những thứ khác tôi phải nhớ để hiểu mã tôi nên sửa đổi.
  4. Gián đoạn liên tục tại nơi làm việc làm phiền tôi và làm tôi chậm lại.
  5. Tôi không thể nhớ nhiều hơn hai hoặc ba nhiệm vụ cùng một lúc mà không có hệ thống theo dõi lỗi và tôi quên tất cả chúng vào cuối tuần.

Các đồng nghiệp của tôi dường như không có vấn đề tương tự.

  1. Họ quản lý để gỡ lỗi các phương pháp viết xấu nhanh hơn tôi nhiều.
  2. Họ giới thiệu ít lỗi hơn tôi khi thay đổi codebase.
  3. Họ dường như nhớ rất rõ tất cả những gì họ cần để thay đổi mã, ngay cả khi nó yêu cầu đọc hàng ngàn dòng mã trong hai mươi tệp khác nhau.
  4. Họ dường như không bị làm phiền bởi email, điện thoại reo, mọi người nói chuyện xung quanh và những người khác hỏi họ câu hỏi.
  5. Họ không muốn sử dụng hệ thống theo dõi lỗi mà chúng tôi đã có kể từ khi chúng tôi sử dụng TFS. Họ thích chỉ cần nhớ mọi nhiệm vụ họ nên làm.

Lý do tại sao điều này xảy ra? Đây có phải là một nhà phát triển kỹ năng đặc biệt có được khi làm việc với mã viết kém trong một thời gian dài? Có phải tương đối thiếu kinh nghiệm của tôi với mã xấu góp phần vào những vấn đề / cảm xúc này? Tôi có vấn đề với bộ nhớ của tôi?


1
Là đồng nghiệp của bạn có nhiều kinh nghiệm với cơ sở mã đặc biệt này hơn bạn? Ngoài ra, Kiểm tra đơn vị / theo dõi lỗi / vv không thực sự phải là một cách tiếp cận tất cả hoặc không có gì. Chỉ cần bắt đầu thực hiện chúng trên các phần bạn chịu trách nhiệm.
Graham

1
Đây là lý do tại sao đóng gói tồn tại.
Robert Harvey

Câu trả lời:


26

Có, việc những người có cấu trúc bị ảnh hưởng bởi mã / môi trường không có cấu trúc là điều bình thường. Các đồng nghiệp của bạn có thể đang lọc tốt hơn tất cả các tạp âm. Là một người mắc chứng đau nửa đầu, tôi biết khả năng lọc ra môi trường của mình giảm đáng kể khi cơn đau nửa đầu xuất hiện. Con người khác nhau.

Điều tương tự cũng đúng với mã, các đồng nghiệp của bạn có thể đã học cách lọc "nhiễu mã" xuất phát từ nhiều mức độ trừu tượng trong một phương thức duy nhất và đã trở nên lão luyện trong việc "phân chia" mã thành các lĩnh vực chức năng lớn hơn.

Nó chỉ đơn giản là cần có thời gian để thích ứng với một cơ sở mã như cơ sở bạn mô tả. Các đồng nghiệp của bạn có thể đã có nhiều thời gian hơn để phát triển nó và có thể đã chọn ra các quy ước, mô hình và cấu trúc không nhảy ra khỏi "người mới cơ sở mã". Có thể có nhiều cấu trúc cho sự hỗn loạn hơn bạn có thể tưởng tượng. Nói chuyện với các đồng nghiệp của bạn, yêu cầu họ ghép đôi với bạn một thời gian và chọn bộ não của họ về cách họ tiếp cận giải quyết một trong những lỗi được giao cho bạn. Khi họ yêu cầu bạn mở đơn vị X, Y hoặc Z, hãy hỏi họ tại sao đơn vị đó, điều gì đang nói với họ rằng nó có thể có liên quan, v.v.

Bị mất trong một phương pháp ngàn dòng là bình thường. Tấn công nó bằng một trình soạn thảo gấp tốt và thêm nhận xét để chia các phần khác nhau thành các chức năng và / hoặc thủ tục mà không thực sự làm như vậy. In các công cụ và sử dụng một highllight lỗi thời cũng có thể giúp đỡ.

Tái cấu trúc mà không có mạng lưới an toàn của các bài kiểm tra đơn vị là tự bắn vào chân mình. Đừng. Chỉ cần không.

Không ai yêu cầu bạn giữ mọi thứ trong bộ nhớ. Nếu đồng nghiệp của bạn không muốn hoặc không cần hệ thống lỗi, chỉ cần viết tác vụ được giao cho bạn trong danh sách việc cần làm của riêng bạn và viết ghi chú khi / sau khi nói chuyện với ai đó về chi tiết nhiệm vụ của bạn.


+1 cho "Có, việc những người có cấu trúc bị ảnh hưởng bởi mã / môi trường không có cấu trúc là điều bình thường."
Md Mahbubur Rahman

2

Có 3 điểm chính mà tôi thấy:

điểm 1, 2 và 3 xuất phát từ thực tế là các đồng nghiệp của bạn đơn giản là có nhiều kinh nghiệm hơn với cơ sở mã hóa, điều đó có nghĩa là họ biết những điều kỳ quặc của nó. Điều này có nghĩa là họ sử dụng bộ nhớ dài hạn của họ cho quá trình gỡ lỗi và có thể nhớ rằng doXYZ thực sự làm UVW nhưng không bao giờ được đổi tên vì lý do lịch sử. tuy nhiên họ nên mất vài tháng để mã hóa nó sau đó họ sẽ bắt đầu cảm thấy nỗi đau của bạn.

đối với điểm 4 chống lại sự gián đoạn, đừng để việc kinh doanh không khẩn cấp đưa bạn ra khỏi khu vực , phải mất một thời gian dài để quay trở lại sau khi bị gián đoạn; đặt IM của công ty thành bận rộn, cố gắng lên lịch trong các khối dài (buổi chiều đầy đủ) chỉ cần mã hóa

cho điểm 5 giây tạo một bảng excel với các lỗi bạn hiện đang làm như danh sách việc cần làm cá nhân của bạn, (hoặc sử dụng các khả năng quản lý tác vụ trong IDE của bạn), tôi sẵn sàng đặt cược rằng một số đồng nghiệp của bạn đang làm như vậy


Cám ơn bạn đã đóng góp ý kiến. Lưu ý: đối với điểm 5, chúng tôi đã có TFS, một sản phẩm bao gồm hệ thống theo dõi lỗi. Tôi là người duy nhất sử dụng nó ngày hôm nay. Tôi không biết về mọi nhà phát triển của công ty, nhưng tôi biết chắc chắn rằng một vài người không có bất kỳ danh sách lỗi nào, ngay cả trong Excel hoặc một tài liệu văn bản đơn giản.
Arseni Mourzenko

2

Không có vẻ như vấn đề bộ nhớ với tôi. Nghe có vẻ như thói quen / xu hướng làm việc của bạn không phù hợp với những gì bạn đang gặp phải và bạn đang suy nghĩ quá nhiều về đồng nghiệp chứ không phải bản thân mình.

  1. Phương pháp hàng ngàn dòng - mọi người sẽ bị mất trên đó trừ khi họ chỉ làm việc với nó. Họ có thể nhanh hơn trong việc nhặt nó lên hoặc lấy lại. Bạn không thể thay đổi điều đó ngoại trừ thông qua kinh nghiệm và thậm chí có thể không.

  2. Tái cấu trúc giới thiệu các lỗi, tốt, đó luôn là một rủi ro. Bạn có thể thử phát triển thử nghiệm đơn vị để bao gồm những gì bạn đang thay đổi trước khi thực hiện, nhưng điều đó có thể không được quản lý cho phép (có thể là không, hoặc nó đã được thực hiện). Và kiểm tra đơn vị không phải là phép thuật họ vẫn có thể bỏ lỡ mọi thứ, bạn vẫn có thể giới thiệu các lỗi. Có thể họ không tái cấu trúc. Điều này quay trở lại (1), có lẽ họ cố gắng tập trung vào những gì cần sửa, nghĩa là họ đến điểm nhanh hơn, nhưng bỏ lỡ bức tranh lớn hơn, và sẽ mất nhiều thời gian hơn để khắc phục điều tiếp theo trong hàng ngàn dòng lộn xộn đó.

  3. Tạo những gì bạn cần để hoàn thành công việc. Nếu điều đó có nghĩa là tạo ra một biểu đồ dòng chảy hoặc một số tài liệu khác, thì hãy làm như vậy. Cho dù họ có cần hay không, và họ có sử dụng hay không sau khi bạn tạo ra nó, đều không liên quan.

  4. Gián đoạn làm mọi người chậm lại. Tập trung vào đó sẽ chỉ làm bạn chậm lại nhiều hơn. Chấp nhận nó và cố gắng quay trở lại trong rãnh càng nhanh càng tốt.

  5. Giữ hai hoặc ba lỗi trong tâm trí không phải là xấu, ba hoặc bốn sẽ tốt hơn, nhưng thay vì cố gắng cải thiện điều đó, hãy từ bỏ và viết nó ra. Mảnh giấy, bảng trắng, tfs, excel, word hoặc notepad - chỉ cần viết nó xuống. Tôi cá rằng đó là những gì đồng nghiệp của bạn đang làm. Hoặc là hoặc sửa chữa mọi thứ một cách ngẫu nhiên.

Lập trình không phải là về một bộ nhớ hoàn hảo và không phải là có thể bỏ qua những phiền nhiễu - tập trung vào đây chỉ là những phiền nhiễu mà bạn đang tạo ra.


1

CAVEAT / CẬP NHẬT: Sau khi đọc câu trả lời dưới đây, tôi cảm thấy có thể cảm thấy hơi quá khắc nghiệt. Không phải ý định của tôi, môi trường bạn mô tả là khủng khiếp và nó sẽ ảnh hưởng đến hầu hết mọi người (có lẽ ngay cả những lập trình viên giỏi hơn cũng phải chịu đựng điều đó, nhưng họ "tốt hơn" khi so sánh với những người khác trong cùng môi trường). Câu trả lời của tôi chỉ là sự phản ánh từng điểm trong câu hỏi của bạn, giả sử rằng môi trường sẽ không thay đổi (ngay cả khi nó nên).

Câu trả lời hoàn toàn có thể:

1) Điều đó phụ thuộc vào kinh nghiệm trong công nghệ, trong việc duy trì ứng dụng (nhiều hơn nếu nó được thiết kế xấu) và thậm chí trong các phần cụ thể của ứng dụng. Cũng phụ thuộc vào vấn đề tập trung của bạn (số 4)

2) Nó giống với số 1, nhưng sử dụng một số liệu khác nhau. Cùng một câu trả lời.

3) noteblock và bút. Hoặc một tài liệu word / excel. Không khó để giải quyết.

4) đó là một vấn đề cá nhân của sự tập trung. Dù vậy, không chắc chắn liệu có khả năng cải thiện nó hay không.

5) sử dụng hệ thống vé hay không không phải do người lập trình quyết định mà là người quản lý dự án. Hỏi ý kiến ​​của anh ấy / trình bày quan điểm của bạn. Nếu anh ta chống lại nó, noteblock và bút lại.


Tôi cho rằng nhiều gián đoạn là một môi trường làm việc tồi tệ. Nếu có một số tiếng ồn lớn, thì điều đó nên được giải quyết. Theo như e-mail, hãy học cách tắt chúng đi. Hãy nói, 10 phút khi bạn đi làm, sau bữa trưa và trước khi bạn rời đi để kiểm tra e-mail của bạn. Tránh kiểm tra chúng liên tục trong suốt cả ngày trừ khi bạn biết có điều gì đó quan trọng đối với bạn.
mgw854

@ mgw854 Tôi đọc lại câu trả lời của mình và tôi đồng ý rằng nó có vẻ hơi khắc nghiệt hơn tôi dự định. Tôi không có ý bất cứ lúc nào rằng các vấn đề chỉ là lỗi của OP và môi trường (cả về thể chất và tổ chức) có vẻ khủng khiếp. Ngay cả đối với những lập trình viên giỏi nhất ở đó, tôi chắc chắn những vấn đề này ảnh hưởng nặng nề đến hiệu suất. Tôi chỉ chỉ ra những cách để giảm "khoảng cách" mà OP dường như cảm thấy tồn tại với các lập trình viên khác trong cùng môi trường.
SJuan76

0

Tôi đã trải qua một tình huống như vậy trước đây và dựa trên kinh nghiệm đó tôi có thể nói rằng vấn đề của bạn không liên quan đến bộ nhớ và có điều gì đó trong tâm trí của bạn (chắc chắn không liên quan đến công việc) khiến bạn căng thẳng và khiến bạn không tập trung 100 % về nhiệm vụ trong tầm tay.

Vì vậy, bước đầu tiên là làm sạch tâm trí của bạn khỏi những thứ đó khi bạn đang ở trong bàn làm việc của bạn.

Sự căng thẳng đó cũng có thể tăng lên vì bạn cảm thấy mình bị tụt hậu về năng suất, vì vậy hãy thử nói chuyện với đồng nghiệp và hỏi họ những lời khuyên về cách tiếp cận tái cấu trúc.

Cuối cùng, đừng cảm thấy bối rối nếu bạn phải viết ra những vấn đề bạn đã giải quyết và / hoặc đang làm việc ngay bây giờ (nó không phải là một hệ thống theo dõi lỗi tinh vi) tốt hơn là bạn nên chắc chắn điều gì đó vì bạn đã đọc nó từ ghi chú của bạn hơn là nêu nó ra khỏi đỉnh đầu của bạn trong khi không chắc chắn 100% về nó

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.