Làm thế nào tôi có thể ghi lại công việc trước đây của người khác? [đóng cửa]

Chúng ta đang ở trong một tình huống tồi tệ khi có rất ít tài liệu về việc tùy chỉnh các nhân viên trước đây của chúng ta được thực hiện cho một hệ thống quan trọng trong kinh doanh. Rất nhiều thay đổi đã được thực hiện đối với Báo cáo Pha lê, các thực thể cơ sở dữ liệu và các tệp cấu hình / lập trình độc quyền cho phần mềm ERP của chúng tôi.

Các tài liệu hiện tại thường đọc một cái gì đó như thế này:

Chương trình này được chạy trước khi lập hóa đơn. Lỗi đã biết: không có.

Chạy chương trình này sau khi cài đặt phần mềm X.

Đã thay đổi các trường sau trong báo cáo này: (không có giải thích về cách thức hoặc lý do)

Cửa hàng CNTT của chúng tôi rất nhỏ và trong trường hợp phần mềm ERP, hầu hết các công việc đều tập trung vào một người (đó là tôi bây giờ) vì vậy không ai khác ở đây biết tất cả những gì chúng tôi đã làm. Bộ phận kế toán và CNTT biết các bit và phần (đôi khi khá hữu ích) nhưng điều đó là không đủ.

Một vấn đề khác là bộ phận Kế toán của chúng tôi dường như nghĩ rằng chúng tôi có tài liệu tốt. Đúng là chúng tôi đã lưu giữ rất nhiều hồ sơ về những gì đã sai , nhưng rất ít giải thích những gì (nếu có) được thực hiện để khắc phục những vấn đề này. Chúng tôi có hàng trăm bài báo giải thích các lỗi, nhưng các tài liệu giải thích các thay đổi (như được hiển thị ở trên) gần như vô dụng.

Làm cách nào tôi có thể ghi lại những thay đổi trong quá khứ khi tôi không biết tất cả những gì đã được thực hiện? Tôi có thể bắt đầu với việc ghi lại những gì chúng tôi đã thay đổi: Tệp, bảng cơ sở dữ liệu mà chúng tôi cần phải có để hệ thống hoạt động. Tôi cũng có thể ghi lại những gì chúng ta làm ; khi báo cáo được chạy, tại sao mọi người được yêu cầu sử dụng báo cáo / chương trình X. Nhưng khi một trong những thứ tùy chỉnh này có vấn đề, tôi luôn quay lại hình vuông.

Làm thế nào tôi có thể chủ động ghi lại những thứ này cho bản thân và những người khác?

Tôi nghĩ rằng đây là một bài tập vô ích. Nếu nó hoạt động, nó hoạt động, nếu nó không hoạt động, bạn phải sửa nó.

Cách tốt nhất để ghi lại những thứ cũ là khi bạn làm việc với nó, ghi lại những gì bạn đang làm và giải thích logic kinh doanh (mà tôi cho rằng không được ghi lại). Đây sẽ là một trợ giúp lớn cho bất kỳ nhà phát triển mới.

Nói về việc ghi lại mã / những thứ cũ, ai đó đã phải sở hữu nó. Hãy cho rằng đây là người quản lý hiện tại của bạn. Anh ấy / cô ấy có thể không có kiến ​​thức kỹ thuật đầy đủ về nó nhưng sẽ biết những thay đổi đã được thực hiện. Trong trường hợp đó, nó không phải là công việc của bạn. Có thể người quản lý có thể viết một cái gì đó về nó những thay đổi đã được thực hiện. Điều đó sẽ hữu ích để giữ như lịch sử. Nếu vấn đề như vậy phát sinh bạn có thể đào sâu vào những lĩnh vực đó, điều đó có thể rất hữu ích cho bạn. Nhưng đi sâu vào mã và ghi lại các thay đổi là IMO khá vô dụng và có lẽ là không thể.

Từ bỏ nỗ lực của bạn để tài liệu thay đổi .

Thay vào đó, hãy bắt đầu ghi lại những gì hiện đang hoạt động, và làm thế nào . Giữ tài liệu đó cập nhật và hiện tại khi bạn thực hiện thay đổi trong tương lai.

Bạn có kiểm soát nguồn?

Bạn có thể tìm ra những gì đã thay đổi từ đó?

Nếu vậy, thì bạn có thể ánh xạ điều đó đến các thay đổi kinh doanh, cho dù các tính năng mới hoặc sửa lỗi.

Có thể phục hồi hộp thư nhà phát triển cũ? (không chắc điều này có khả thi với những lo ngại về quyền riêng tư hay không). Có thể có rất nhiều thông tin để có được bằng cách truy tìm thông qua đó.

Điều đầu tiên đầu tiên. Bạn đang lưu trữ tài liệu của bạn ở đâu? Nếu bạn chưa có, hãy thiết lập một wiki. Tôi thích dokuwiki bản thân mình, và thậm chí còn có một vm dựng sẵn , nếu bạn đang rất nghiêng.

Điều này cung cấp một số tính năng quan trọng:

• Tài liệu có thể được truy cập ở bất cứ đâu trên lan công ty (cài đặt trên máy tính mới ...)
• Tất cả tài liệu ở một nơi
• Tất cả các tài liệu có thể tìm kiếm
• Bạn có thể cộng tác (đồng nghiệp mới, người dùng phần mềm)

Bây giờ, nếu tài liệu của bạn ở dạng giấy thì tôi chúc bạn những điều tốt đẹp nhất. Nếu bạn có tài liệu từ, hãy xây dựng một tập lệnh nhập .

Cuối cùng, chỉ cần sử dụng các công cụ . Bất cứ khi nào bạn cần cài đặt một cái gì đó, hãy đặt ghi chú trong wiki. Nếu bạn gặp trường hợp cạnh, hãy đặt nó vào wiki. Đây là nơi hợp tác có thể tỏa sáng, vì bạn khiến người khác làm việc cho bạn.

Chuyển sang tài liệu cụ thể hơn, nếu bạn cần làm việc với nguồn cho các dự án khác nhau, hãy đảm bảo bạn có một môi trường phát triển phù hợp được thiết lập ! Đối với một danh sách kiểm tra những thứ bạn nên có:

• Kiểm soát phiên bản ( git , mercurial , hóa thạch )
• Theo dõi lỗi ( trac , bọ ngựa , redmine , hóa thạch )
• Xây dựng hệ thống ( autotools , scons , buildbot )
• Kiểm soát dự án ( nhật thực , cấu trúc thư mục được chỉ định, plugin biên tập )
• Tài liệu nguồn (README, TODO, INSTALL, Nguồn ý kiến)

Cuối cùng, vì tài liệu có thể nhàm chán, hãy biến nó thành một trò chơi. Tự cho mình "điểm" cho từng mục trong danh sách kiểm tra của bạn, định kỳ kiểm tra "điểm" của bạn. Đó là một cách tốt để xem những gì bạn đã hoàn thành, và tốt như thế nào. Nó cũng vạch ra nơi bạn cần đi tiếp theo.

Hãy xem đây là cơ hội để tìm hiểu nhiều điều về cách thiết lập môi trường phát triển phù hợp và đừng ngại thử mọi thứ và tiếp tục. Tìm một cái gì đó bạn thích và di chuyển môi trường qua để mọi thứ tốt hơn . Tiếp cận điều này như một dự án mà bạn đang tìm cách xây dựng giải pháp tốt nhất.

Biên tập:

Theo nhận xét của giàn khoan dưới đây, một điều hữu ích khác là tạo sơ đồ của mã nguồn. Freecode có công cụ , và bài viết này liệt kê một số ngôn ngữ phổ biến.

Điều tốt nhất bạn có thể làm là ghi lại tất cả những gì bạn biết và yêu cầu xung quanh công ty ghi lại bất cứ điều gì mà người khác biết. Tôi đề nghị tập trung tài liệu trong wiki hoặc một cái gì đó tương tự để mọi người đều có quyền truy cập vào tài liệu cập nhật nhất.

Bạn không thể ghi lại những điều bạn không biết, vì vậy hoặc bạn cố gắng tìm hiểu và khám phá lý do tại sao một cái gì đó được thực hiện hoặc bạn chỉ để nó không có giấy tờ. Đây là lý do tại sao công ty cần phải chăm sóc nhiều hơn để ghi chép lại những thứ trong khi những người biết vẫn còn làm việc ở đó.

Nếu bạn đang cố gắng ghi lại bất kỳ mã nào mà bạn không hiểu, tôi khuyên bạn nên viết các bài kiểm tra đơn vị để kiểm tra chức năng. Bằng cách này, bạn sẽ hiểu rõ hơn về những gì mã làm và bản thân các bài kiểm tra có thể phục vụ như tài liệu.

Chúc may mắn!

Khi tôi cố gắng ghi lại điều gì đó mà người khác không còn với dự án hoặc công ty đã làm, tôi luôn bắt đầu thái độ: Đây là hộp đen cho mọi người kể cả tôi cho đến khi tôi cần thay đổi điều gì đó hoặc giải thích cho người khác.

Lý do mà dự án này nằm trong hình dạng tài liệu mà bạn đã tìm thấy nó là bởi vì tài liệu của bất kỳ công việc nào có phần thứ yếu để khiến nó chạy. Vì vậy, hãy ghi lại những gì bạn thay đổi và nếu bạn đã tìm ra trường cụ thể trong cơ sở dữ liệu và khối mã cụ thể nào, nếu không có lợi cho ai khác ngoài lợi ích của bạn.

Bạn có thể viết các bài kiểm tra thăm dò tự động. Những điều này có một số lợi thế:

• Bạn học cách hệ thống hoạt động khi bạn viết chúng

• Chúng phục vụ như tài liệu thực thi cho sau này

• Nếu bạn chạy chúng một cách thường xuyên hoặc thậm chí liên tục, chúng sẽ cung cấp một mạng bảo mật tốt để phát hiện khi thay đổi phá vỡ một cái gì đó hoặc khi chúng cần được cập nhật

Tôi không biết liệu có khả thi để viết loại bài kiểm tra đó trong môi trường cụ thể của bạn hay không.