Liệu việc xử lý mã kế thừa có giúp người ta phát triển như một lập trình viên không? [đóng cửa]


18

Tôi là một nhà phát triển Java với hơn một năm kinh nghiệm đặt tôi ở đâu đó trên một thiếu niên, nhưng chưa phải là một trong số các nhà phát triển cấp trung. Gần đây tôi đã được cung cấp một dự án dài hạn về nghiên cứu mã ứng dụng ngân hàng hiện tại trong 4 tháng và sau đó giới thiệu các thay đổi khi cần thiết. Là một lập trình viên không có kinh nghiệm, tôi đang tìm cách để phát triển và tôi tự hỏi một dự án như vậy có thể mang lại điều gì.

Bạn có xem việc đối phó với một ứng dụng lớn và có thể không được viết tốt là một thực hành tốt cho người mới bắt đầu?



1
Học hỏi từ những sai lầm của người khác là cách an toàn nhất để có được trải nghiệm ...
Michael Borgwardt

Tôi đã nghiên cứu mã người khác trong khoảng một tháng gần đây. Kinh nghiệm học tập tuyệt vời, nhưng hút thời gian lớn. Cần thử nghiệm với các loại trà an thần.
usr

Có thể có Java tốt nhưng khó tìm jr hơn. dev hơn dev của hầu hết các nền tảng ngôn ngữ ban đầu khác mà tôi sẽ tưởng tượng dựa trên kinh nghiệm, chủ yếu là một nhà phát triển web mặt trước đã trở thành người nói chung, những người đã tiếp xúc với rất nhiều mặt sau. Vấn đề tôi nghĩ, đó là ngôn ngữ Java hoàn toàn có thể sử dụng được nhưng văn hóa Java là về việc chơi hoàn toàn mọi thứ an toàn và không có lỗi nhất có thể.
Erik Reppen

Câu trả lời:


34

Khắc phục sự cố mã hiện có là một cách siêu để phát triển như một lập trình viên. Nếu mã xấu, bạn sẽ học được tác động của những lỗi họ đã gây ra và có thể tránh một số lỗi khi bạn thực hiện thiết kế. Nếu mã tốt, bạn sẽ học được điều gì đó về cách tạo ra một ứng dụng có thể bảo trì.

Bạn cũng sẽ học cách đối phó với sự phức tạp của một ứng dụng kinh doanh thực sự. Vì đây là trong lĩnh vực ngân hàng, bạn sẽ tìm hiểu về những thứ như quy định của liên bang và kiểm soát kế toán nội bộ mà bạn có thể chưa bao giờ nghĩ tới. Đây là những điều tốt để biết khi bạn được yêu cầu thiết kế một cái gì đó khác trong thế giới tài chính. Và lập trình tài chính có thể là một lĩnh vực sinh lợi để làm việc, vì vậy có được kinh nghiệm ngân hàng có thể rất tốt cho bạn.

Bạn thậm chí có thể học được rằng chỉ vì một cái gì đó đã được viết 15 năm trước, trong một ngôn ngữ mà bạn không muốn sử dụng, nó không hẳn là xấu. Rốt cuộc nó đã chạy thành công.

Nếu, như với hầu hết các ứng dụng cũ, ứng dụng không có kiểm tra đơn vị, bạn cần thực sự chắc chắn rằng một thay đổi sẽ không ảnh hưởng đến điều gì khác, bạn có thể tìm hiểu cách thêm kiểm tra đó và cách bán quản lý tại sao thêm kiểm tra đó một ý tưởng tốt


2
Thật vậy, nếu bạn sẽ có 4 tháng để nghiên cứu mã, bạn nên dành 4 tháng đó để thêm nhận xét ghi lại những gì bạn học và viết các bài kiểm tra chứng minh rằng các thành phần chính hoạt động chính xác (như một người hy vọng họ làm).
Ross Patterson

1
@RossPatterson, vì đây là ngân hàng, vâng tôi hy vọng họ thực sự làm việc chính xác ngay bây giờ. Ở bất cứ giá trị nào nếu không có bài kiểm tra, thì rủi ro thực hiện thay đổi là rất lớn trong ngân hàng và viết bài kiểm tra đơn vị để giúp bạn tìm hiểu hệ thống nên dễ bán.
HLGEM

3
Lập trình là biết cách di chuyển các mảnh. Hiểu một hệ thống là biết cách chơi trò chơi. Bạn sẽ không hối tiếc kinh nghiệm từ quan điểm xây dựng kỹ năng. Làm việc cho các công ty ăn cắp từ góa phụ và trẻ mồ côi là điều mà lương tâm của bạn có thể không tha thứ.
Meredith Nghèo

8

Tôi nghĩ rằng đó là thực hành tuyệt vời cho bất cứ ai mới bắt đầu . Học hỏi kinh nghiệm từ người khác có thể rất hiệu quả.

Thách thức thực sự không phải là tìm ra sai lầm, mà là đi vào đầu của nhà phát triển khác và cố gắng tìm ra whymã được viết theo cách đó. Đôi khi, vì họ cẩu thả, và đôi khi vì họ có lý do chính đáng. Giả sử nhà phát triển ít nhất cũng tốt như bạn nhưng có thể có nhiều kiến ​​thức về miền hơn.


2
Nó cũng giúp bạn hiểu được phương pháp mà bạn nghĩ rằng họ nên sử dụng không có sẵn khi mã được viết.
HLGEM

Sẽ thật tuyệt khi tìm thấy một số nhận xét mã hoặc tài liệu dự án trong những tình huống này. Nếu không, hack hoặc cách kỳ lạ để thực hiện một chức năng sẽ vẫn là một sai lầm. Nhà phát triển đó thậm chí có thể không ở trong công ty nữa, vì vậy không có cách nào để bạn hỏi anh ta về điều đó.
Radu Murzea

6

Đây là thực hành tốt cho bất kỳ nhà phát triển tại bất kỳ thời điểm nào trong sự nghiệp của họ. Nếu bạn có thể xem xét và phân tích phần mềm hiện có và tìm cách cải thiện phần mềm, bạn sẽ chứng minh rằng bạn là một nhà phát triển có giá trị. Bạn sẽ không chỉ học cách những người khác đã thiết kế và phát triển phần mềm, mà trên đường đi, bạn sẽ học được những điều không nên làm, đó là kiến ​​thức có giá trị.

Nếu bạn sẵn sàng cho thử thách, hãy tiếp tục dự án này và làm cho nó tốt hơn.


2

Nó hoàn toàn sẽ giúp bạn, nhưng bạn cần phải cẩn thận.

Bạn cần chắc chắn rằng bạn học được từ mã kế thừa. Làm thế nào để bạn biết cái gì là tốt và cái gì là xấu? Có thể bạn có thể nhận ra ưu và nhược điểm của các mẫu / phương thức khác nhau, nhưng nếu bạn là một nhà phát triển cơ sở mới bắt đầu, bạn có thể không thể.

Và ở lại quá lâu trong công việc đầu tiên đó, và bạn có thể không học hoặc xây dựng đủ kỹ năng và cuối cùng bị mắc kẹt ở đó.


2

Di sản có thể có nghĩa là bất cứ điều gì nhưng dựa trên nhận xét 'không được viết tốt' của bạn, tôi sẽ cho rằng Di sản có nghĩa là 'xấu' hoặc ít nhất là 'lỗi thời'. Nếu mã kế thừa là tốt, đừng giữ lại và tìm hiểu mọi dòng của nó.

Tôi không nghĩ rằng có những cảnh báo đủ rõ ràng chống lại các loại công việc và dự án chuyển hướng sự nghiệp của bạn và khiến bạn bị mắc kẹt trong các lỗ chìm vô giá trị trên chủ đề này cho đến nay.

Cảnh báo tương tự về thể thao: Bạn có nghĩ rằng một người ủng hộ dòng trong NFL học được nhiều hơn và trở nên có giá trị hơn bằng cách chơi trong đội có thành tích tệ nhất hoặc tốt nhất? Câu trả lời của tôi: Không chỉ họ có giá trị hơn khi chơi cho các đội tốt nhất, mà họ có thể chọn các kiến ​​thức và thực tiễn tốt nhất và tránh chọn các thực tiễn và thái độ kết thúc sự nghiệp.

Có rất nhiều mã chống mẫu khủng khiếp ngoài kia thực sự hoạt động cho doanh nghiệp và trả rất nhiều tiền lương cho nhà phát triển. Tôi đề xuất rằng một nhà phát triển chưa thấy đủ mã đã thực hiện theo cách 'đúng' có thể nhầm mã chống mẫu cho một giải pháp hợp pháp cho một vấn đề. Doanh nghiệp có thể nói rằng giải pháp này hoạt động, nhưng đó không phải là điều bạn muốn trong hồ sơ xin việc hoặc là điều bạn sẽ khoe khoang với các nhà phát triển khác. Điều này cũng chỉ phù hợp nếu con đường phát triển cá nhân của bạn bao gồm sự tôn trọng của các đồng nghiệp kỹ thuật và không chỉ tăng tạm thời thu nhập của bất kỳ công ty nào bạn làm việc (Nghe có vẻ tệ, nhưng cuối cùng, kỹ thuật tốt nhất hoàn toàn kiếm được nhiều tiền nhất IMO) .

Thật không may, có rất nhiều mã và rất nhiều thời gian có thể vượt qua trước khi nợ công nghệ được tiết lộ. Và khoản nợ công nghệ đó thường được ghi nhận chính xác khi quá muộn. Bất cứ ai có thể đã cố gắng ngăn chặn nợ công nghệ hoặc các mô hình chống trước đó, có thể đã bị loại bỏ vì chi phí tăng thêm hoặc thiếu hiểu biết về khả năng mở rộng. Nhiệm vụ của chúng tôi là các kỹ sư để phơi bày nợ công nghệ ngay lập tức. Các dự án không có kỹ sư giàu kinh nghiệm có nguy cơ đâm vào một bức tường gạch ở một số điểm, thực sự là tất cả các dự án ngay cả với các nhà phát triển tài năng. Hầu hết các doanh nghiệp xem "một số điểm" là có nhiều thời gian để khắc phục nó sau này. Điều này làm cho lựa chọn công việc cho các nhà phát triển sắp tới và trở thành một vấn đề rất phức tạp. Nó cũng chỉ ra các mục tiêu và tư duy hoàn toàn khác nhau giữa các nhà phát triển và doanh nghiệp và mức độ phức tạp của nó để thu hẹp khoảng cách.

Mục tiêu của các kỹ sư là 'bao gồm' công việc khoa học thực sự và xem xét thiết kế trong khi đó là mục tiêu của doanh nghiệp để 'loại trừ' chi phí và thời gian không cần thiết. Vì các kỹ sư thường không biết mức độ nỗ lực và thời gian là bao nhiêu cho đến khi thực sự kết thúc, phát triển phần mềm diễn ra giống như bất kỳ bộ phim hay nào với các nhân vật như nhanh nhẹn, scrum và kanban đóng vai trò lãnh đạo.

Một lần lấy đi có thể là tránh xa mã xấu cho đến khi bạn thấy đủ mã tốt để không bị 'hỏng'. Tôi thích câu nói rằng các nhà phát triển cao cấp tạo ra các giải pháp đơn giản cho các vấn đề phức tạp. Giống như khôn ngoan, các nhà phát triển trung cấp cơ sở tạo ra các giải pháp phức tạp cho các vấn đề đơn giản và phức tạp.

Một cách khác có thể là bạn cần làm việc với mã tốt VÀ xấu ở các điểm khác nhau để có được sự hiểu biết. Nếu bạn đã không làm điều đó thì hãy làm điều đó và sẵn sàng để học hỏi tất cả khi bạn bắt gặp một hệ thống tốt hơn. Tôi nghĩ rằng đây có lẽ là một quỹ đạo phổ biến hơn cho hầu hết các nhà phát triển.

Tôi thiên vị trong năm nay bởi vì tôi cảm thấy như mình đang leo lên một ngọn núi 'nước sốt bí mật' cực kỳ phức tạp. Mặc dù tôi sẽ tăng khả năng giải mã một số mô hình tồi tệ nhất tôi từng thấy, nhưng nó rất 'tùy chỉnh' và 'một lần' mà tôi không tin rằng cuộc đấu tranh của tôi sẽ tăng khả năng tiếp thị hoặc kỹ năng có thể sử dụng của tôi trong tương lai.

Để giữ sự tỉnh táo của mình, tôi chỉ cần chạy nhanh với tốc độ ổn định và nắm lấy mọi chướng ngại vật ngang tầm với khóa học. Vừa mới xem xét các mục tiêu hàng năm của tôi với sếp của tôi, bao gồm việc đào ra khỏi lỗ hổng di sản này, tôi nghĩ rằng đó có thể là một cuộc leo núi hy sinh. Tôi có thể sống sót qua quá trình với những đánh giá xấu và nhận thấy sự chậm chạp. Đây là một cảnh báo thực tế và báo trước cho những bạn tự hỏi nên làm công việc gì.

Disclaimer: Bài đăng này sẽ sống lâu hơn nhiều so với ý kiến ​​của tôi vì vậy hãy dùng nó với một hạt muối. Ngày mai tôi có thể yêu mã di sản! (Nghi ngờ điều đó).


1

Nó phụ thuộc rất nhiều vào cách bạn định nghĩa "di sản" trong bối cảnh này. Hãy để tôi cho bạn một ví dụ từ C và C ++. Nhiều lập trình viên C ++ gọi đó là một cách thực hành tồi để sử dụng chuỗi C trong các ứng dụng C ++, những người khác không yêu cầu sự pha trộn, trong khi những người khác, cho rằng việc sử dụng bất kỳ bit mã C nào là vô nghĩa và hoàn toàn vô nghĩa. di sản "mã. Một số người đi xa hơn và tránh sử dụng pre-C ++ X (thay thế 'X' bằng số thích hợp) thành ngữ, kiểu - đó là cú pháp, cho kiểu "di sản" của nó.

Bỏ qua các vấn đề về hiệu năng của các luồng và chuỗi C ++ và một vài đặc thù của STL, chắc chắn sẽ là một cách thực hành tuyệt vời để xem xét những gì bên trong chỉ thị tiền xử lý được yêu thích của bạn #include <string.h>. Nếu bạn làm theo các đường dẫn đến việc thực hiện và thấy mình trên một máy unix / linux tại /usr/include/string.h(và nhận được nguồn thực hiện libc, ví dụ, từ gnu.org ) và đọc strcmp.chay strlen.chay strtok.c, tôi đặt cược bạn đang gonna nghe "Thật là một thế giới đẹp "Pha vào.

Tuy nhiên, có một sự cảnh báo cho văn xuôi này - cụ thể là các lớp và phương thức không dùng nữa. Trong Java, khá nhiều công cụ kế thừa vẫn có thể truy cập được từ bên trong một môi trường gần đây, nhưng nếu tôi nhớ lại một cách chính xác, thì không phải tất cả mọi thứ. Trong lĩnh vực IB, từ kinh nghiệm của riêng tôi, tốt, không phải tất cả các phần mềm được viết bởi các lập trình viên giỏi. Rất nhiều sinh viên tốt nghiệp đã gần như không tiếp xúc với lập trình trong thế giới thực trước khi họ bắt đầu ở vị trí nhà phân tích / nhà phát triển. Nhưng đừng khái quát hóa tuyên bố này. Tôi biết rất nhiều người sử dụng Java và C # là cốt lõi của môi trường thông lượng cao, độ trễ thấp. Tôi không đồng ý với họ, nhưng tốt, đây may mắn là việc của họ. Nếu họ đã đi HFT thực sự, họ sẽ bị đẩy lùi về phía sau. Nhưng một lần nữa, dễ dàng suy ra từ câu này là giả định (và trong nhiều trường hợp thực tế) rằng mã Java có khả năng tối ưu hóa cao. Và nếu bạn có thể vượt trội trong việc tối ưu hóa, nếu được yêu cầu, không chỉ sửa cái này hay cái kia, bạn sẽ trở nên vô giá như một nhà phát triển. Đó là cách rất hài lòng bằng cách nhận ra bạn đã đóng góp bao nhiêu. Tôi sẽ đi cho 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.