Làm thế nào để xử lý quản lý đẩy hệ thống di sản?


14

Tôi hiện đang thực tập có lương và được giao nhiệm vụ duy trì một hệ thống lỗi thời được phát triển bởi nhiều nhà phát triển (tại các thời điểm khác nhau) trong suốt 5 năm qua. Ban quản lý đồng ý "hệ thống hỗ trợ cuộc sống" và tôi nhận được nguồn cung cấp báo cáo lỗi khá thường xuyên từ người dùng cuối hiện đang sử dụng hệ thống.

Ban quản lý hiện muốn gia hạn dự án thêm một năm nữa và trong quá trình này gần gấp ba cơ sở người dùng.

Là một thực tập sinh (hoặc bất kỳ vị trí cấp nhập cảnh) làm thế nào để tôi "đẩy lùi"? Tôi đã viết một báo cáo nêu rõ mối quan tâm của mình, mặc dù trong một tài liệu kết thúc mở. Có giao thức hoặc loại tài liệu để đề xuất thay đổi? Tôi đang ở một vị trí để đưa ra đề xuất, hay tôi chỉ nên tiếp tục hỗ trợ hệ thống cũ?

  • Để làm rõ, phát triển phần mềm không phải là kinh doanh chính của công ty tôi. Như vậy không có giao thức nội bộ tồn tại. Ngoài ra, dự án hoàn toàn không có tài liệu chính thức và cũng không có tài liệu yêu cầu. Sự phát triển là rất đặc biệt.

6
Tôi thông cảm với vấn đề của bạn. Đáng buồn thay, không có cách dễ dàng xung quanh điều này và tôi chắc chắn rằng câu hỏi của bạn đã được hỏi trước đó theo nhiều cách khác nhau. Một điều tôi muốn giới thiệu là tránh viết báo cáo với những lo ngại "kết thúc mở". Các nhà quản lý (đặc biệt là những người không có kỹ thuật) ghét rằng họ có nói thẳng hay không. Nếu bạn phàn nàn về điều gì đó, bạn phải đưa ra các khuyến nghị cụ thể và thiết thực để làm cho nó tốt hơn.
Angelo

3
@James, định dạng của tài liệu, trong ngữ cảnh của bạn, hoàn toàn không liên quan. Vấn đề là bạn 1) xác định những thay đổi bạn cần thực hiện, 2) mô tả một kế hoạch cụ thể để thực hiện chúng và 3) thuyết phục những người liên quan đồng ý với kế hoạch. Trong một môi trường mà mọi thứ là "ad-hoc" cấu trúc tài liệu chính thức có nghĩa là không có gì.
Angelo

7
Trừ khi có một hệ thống thay thế đang được phát triển tích cực, tôi cho rằng hệ thống hiện tại không phải là "hỗ trợ cuộc sống". Đặc biệt là nếu công ty bao gồm nó trong kế hoạch tương lai.
TMN

7
Từ khi nào một hệ thống 5 năm tuổi "di sản"?
Marjan Venema

1
@James - Đó không phải là định nghĩa của một hệ thống cũ. Di sản được xác định bởi có sẵn một công nghệ (rõ ràng) mới hơn hoặc hiệu quả hơn, không phải là sự thất bại của quy trình nội bộ hoặc giữ chân nhân viên.
Jon Hopkins

Câu trả lời:


23

Tôi hiện đang thực tập có lương và được giao nhiệm vụ duy trì một hệ thống lỗi thời được phát triển bởi nhiều nhà phát triển (tại các thời điểm khác nhau) trong suốt 5 năm qua. Ban quản lý đồng ý "hệ thống hỗ trợ cuộc sống" và tôi nhận được nguồn cung cấp báo cáo lỗi khá thường xuyên từ người dùng cuối hiện đang sử dụng hệ thống.

Hệ thống sẽ không lỗi thời nếu mọi người vẫn đang sử dụng và nó hỗ trợ các hoạt động kinh doanh. Vì nó vẫn đang được sử dụng, doanh nghiệp không thể vứt nó đi - nó cần được hỗ trợ cho đến khi nhu cầu về hệ thống không còn tồn tại. Đó có thể là một sự thay đổi trong mục tiêu kinh doanh hoặc một hệ thống mới đã được phát triển, thử nghiệm và triển khai thành công cho người dùng cuối.

Thực sự, 5 năm không phải là dài. Tôi đã làm việc với mã 10 năm trước. Nếu nó vẫn phục vụ nhu cầu của người dùng, tại sao lại vứt nó đi? Đó là vứt đi rất nhiều tiền dành cho việc phát triển nó. Cho đến khi nó trở nên không khả thi để duy trì do chi phí ngày càng tăng hoặc các yêu cầu thay đổi mạnh mẽ, không có lý do kinh doanh nào để vứt bỏ nó.

Ban quản lý hiện muốn gia hạn dự án thêm một năm nữa và trong quá trình này gần gấp ba cơ sở người dùng.

Nếu quản lý nói rằng hệ thống này là "hỗ trợ cuộc sống", tại sao họ lại cố gắng triển khai nó hơn nữa? Điều phổ biến là các hoạt động bảo trì tiếp tục trên một hệ thống cũ cho đến khi nó được thay thế, nhưng nếu một hệ thống đang ở giai đoạn cuối, nó thường không được triển khai cho nhiều người hơn. Mở rộng bảo trì là một chuyện, nhưng việc thêm người dùng dựa vào hệ thống là một tình huống hoàn toàn khác.

Đối với tôi, có vẻ như nó không thực sự kết thúc cuộc sống, mà là trong giai đoạn bảo trì và sẽ tiếp tục ở đó cho đến khi hệ thống không còn phục vụ nhu cầu của người dùng.

Là một thực tập sinh (hoặc bất kỳ vị trí cấp nhập cảnh) làm thế nào để tôi "đẩy lùi"? Tôi đã viết một báo cáo nêu rõ mối quan tâm của mình, mặc dù trong một tài liệu kết thúc mở. Có giao thức hoặc loại tài liệu để đề xuất thay đổi? Tôi đang ở một vị trí để đưa ra đề xuất, hay tôi chỉ nên tiếp tục hỗ trợ hệ thống cũ?

Bạn cần tiếp tục hỗ trợ hệ thống cũ. Sau đó, bạn đề cập rằng phần mềm không phải là hoạt động kinh doanh chính của công ty bạn. Trong một môi trường như vậy, công việc của các nhóm phần mềm là hỗ trợ doanh nghiệp chính của công ty. Tuy nhiên, các nhóm phần mềm cũng cần ghi nhớ các mục tiêu kinh doanh.

Trong lúc này, hãy nắm bắt các đề xuất của bạn theo cách không hống hách. Chỉ ra các công nghệ hoặc kỹ thuật khác có thể được tích hợp với hệ thống hoặc được sử dụng nếu / khi một hệ thống mới được tạo và ưu / nhược điểm của chúng. Làm thế nào bạn làm điều này phụ thuộc vào công ty, nhưng xem xét một số điểm sau này, có lẽ thiết lập wiki hoặc trang web hợp tác khác sẽ hữu ích.

Trong một doanh nghiệp phi phần mềm, phần mềm là một chi phí và các nhóm phần mềm (đặc biệt là người quản lý dự án / chương trình phần mềm) nên làm việc để giảm thiểu chi phí xây dựng và bảo trì hệ thống phần mềm càng nhiều càng tốt, đồng thời hỗ trợ nhu cầu của người dùng cuối . Vứt bỏ phần mềm (theo như tôi có thể nói, từ bài đăng của bạn, dù sao đi nữa) đáp ứng nhu cầu của người dùng đi ngược lại những gì vì lợi ích tốt nhất của nhóm phần mềm.

* Để làm rõ, phát triển phần mềm không phải là hoạt động kinh doanh chính của công ty tôi. Như vậy không có giao thức nội bộ tồn tại. Ngoài ra, dự án không có tài liệu chính thức nào cả, không có tài liệu yêu cầu. Sự phát triển là rất đặc biệt.

Đối với tôi, đây là vấn đề. Không sản xuất tài liệu, không phát triển đến một đặc điểm kỹ thuật và thiếu tính nhất quán có xu hướng làm tăng chi phí phát triển phần mềm. Làm việc để khắc phục điều này sẽ là ưu tiên cao nhất của tôi và tôi sẽ làm điều đó bằng cách làm việc trên những thứ như tiêu chuẩn mã hóa, kiểm soát phiên bản, sản xuất mã tài liệu và tài liệu thiết kế, theo dõi lỗi và thông số kỹ thuật yêu cầu.


9
I've worked with code that was 10 years old before Khoảng 25 tuổi :) Vẫn đáp ứng nhu cầu của công ty và đã làm một công việc tuyệt vời với những gì nó được thiết kế để làm, mặc dù thực tế là việc chạm vào mã cũng dễ chịu như bơi ở Bắc Cực.
maple_shaft

@maple_shaft Không có gì 25 tuổi. Tôi nghĩ rằng mã lâu đời nhất tôi từng thấy là khoảng 10-15 tuổi. Nó không dễ chịu, nhưng người dùng không quan tâm đến mã sạch. Họ quan tâm đến việc sử dụng phần mềm thực hiện những gì họ cần nó để làm theo cách giúp doanh nghiệp của họ.
Thomas Owens

1
@James Không thực sự. Nếu đó là một cải tiến hoặc lỗi phần mềm yêu cầu một số thay đổi đối với hệ thống hiện có, thì đó là theo dõi trong một trình theo dõi lỗi, nơi nó được ưu tiên và được chỉ định. Nếu đó là một quá trình, phương pháp hoặc thông báo cho một dự án trong tương lai, thì sẽ được nắm bắt thông qua một dự án khả thi tạo ra giải pháp hoặc một bản ghi nhớ kỹ thuật.
Thomas Owens

1
Tôi đang làm việc trên một hệ thống 15 năm tuổi và đó là một niềm vui. Vâng, có những phần có thể làm với cải tiến, nhưng đó có thể là những phần cũ hoặc những phần được viết chỉ sáu tháng trước. Giống như với mọi người: tuổi là không đáng kể. Chính sự chăm sóc đã được thực hiện khi phát triển phần mềm và có bao nhiêu nợ kỹ thuật đã phát sinh trong quá trình phát triển đó, điều đó cho thấy bạn có thể thoát khỏi niềm vui đó bao nhiêu hoặc ít niềm vui.
Marjan Venema

1
@James SRS là kỹ thuật. Nếu bạn giao dịch trực tiếp với quản lý và phát triển phần mềm không phải là công việc chính của họ, thì bạn sẽ phải đặt nó trong điều khoản kinh doanh. Vì không có tài liệu dự án hiện có, v.v., tôi sẽ bắt đầu với một trường hợp kinh doanh hoặc kế hoạch dự án hoặc phân tích tùy chọn để tái cấu trúc trước bất kỳ SRS nào. Một điều các nhà quản lý và doanh nghiệp hiểu là chi phí. Một bản viết lại hoàn chỉnh có thể đầy khó khăn, vì vậy hãy cẩn thận.
Jason S

7

Tôi đã viết một báo cáo nêu rõ mối quan tâm của tôi

Tốt Đó là về mức độ của những gì bạn có thể làm như một thực tập viên. Để tham khảo trong tương lai khi viết các báo cáo như vậy, tôi nhấn mạnh việc trình bày các sự thật khó khăn một cách không thiên vị, chuyên nghiệp mà không có định kiến ​​về cảm xúc. Bạn không biết ai sẽ đọc báo cáo, có thể ai đó có thể hoặc không thể gây ra một số vấn đề bạn đang mô tả hoặc đã đưa ra quyết định dẫn đến những vấn đề này. Bất cứ điều gì khác ngoài sự thật lạnh lùng đều có thể được những người như vậy đối mặt, hoặc xúc phạm và sẽ khiến họ không thích bạn và có thể không coi trọng điều đó.

Ban quản lý hiện muốn gia hạn dự án thêm một năm nữa và trong quá trình này gần gấp ba cơ sở người dùng

Hãy nhớ rằng các quyết định kinh doanh như thế này được đưa ra bởi vì họ đang cố gắng thực hiện do các tài nguyên mà họ có sẵn cho họ. Tôi chắc chắn rằng quản lý có thể nhận thức được các vấn đề với phần mềm cũ và có thể nhận thức được các khiếu nại của người dùng, nhưng họ có sẵn các tài nguyên phát triển phần mềm để xử lý tái cấu trúc hoặc viết lại không?

Hầu hết thời gian họ không làm, đặc biệt nếu phần mềm không phải là bánh mì và bơ của công ty và chất lượng và sự hài lòng của người dùng với phần mềm sẽ không ảnh hưởng trực tiếp đến điểm mấu chốt. Việc đưa ra các loại quyết định này đôi khi là lý do tại sao trở thành một người quản lý tệ bởi vì bạn thường xuyên rơi vào tình huống thua cuộc bất kể bạn làm gì.

duy trì một hệ thống lỗi thời đã được phát triển bởi nhiều nhà phát triển (tại các thời điểm khác nhau) trong suốt 5 năm qua

Những sai lầm đã được thực hiện trong suốt dự án dẫn đến thời điểm này. Thiếu đầu vào hoặc yêu cầu của người dùng vững chắc, thiếu quản lý sản phẩm phù hợp và kiểm soát thay đổi để quản lý các yêu cầu và nhu cầu thay đổi và thiếu các nguồn lực kỹ thuật đầy đủ để thực hiện đã gây ra các vấn đề như hiện nay. Tôi không biết nếu lỗi thời là từ đúng. Là công nghệ cơ bản được xây dựng trên các khuôn khổ và công nghệ được hỗ trợ, hay nó không phải là công nghệ tiên tiến hay lý tưởng?

Là một thực tập sinh (hoặc bất kỳ vị trí cấp nhập cảnh) làm thế nào để tôi "đẩy lùi"?

Bạn đang ở một vị trí ít quyền lực nhất và bạn đang tạm thời ở đó. Không thành vấn đề nếu bạn đúng, tôi sẽ không mong đợi một thực tập viên sẽ "đẩy lùi" tôi. Tôi mong họ học hỏi, thảo luận các vấn đề khi họ nhìn thấy và tuân theo mệnh lệnh. Đó là về nó. Một khi một đơn đặt hàng được đưa ra, tôi hy vọng nó sẽ được thực hiện với khả năng tốt nhất của họ, bởi vì thời gian thảo luận đã kết thúc tại thời điểm đó.


Có lẽ việc sử dụng thuật ngữ "di sản" là không chính xác. Hiện tại công nghệ điều khiển hệ thống là VBA và cổ điển ASP. Cơ sở mã đã được tạo ra bởi một số thực tập luân phiên trong quá khứ. Wikipedia xác định một hệ thống cũ là một hệ thống không còn được hiểu và các tình huống như vậy xảy ra khi hệ thống không được ghi lại và / hoặc các nhà phát triển ban đầu đã rời đi. Ngoài ra, "đẩy lùi" là trong dấu ngoặc kép, bởi vì tôi có một phương châm cá nhân là "không bao giờ hài lòng với sự tầm thường", và vì thế không thể đứng lại và không nói lên những lo ngại. Tôi cảm thấy như thể tôi không hữu ích
James

@James Thật tốt khi nói lên những lo ngại nhưng hãy làm một lần, làm hoàn toàn, trình bày một sự thay thế khả thi và sau đó để nó ở đó. Nếu bạn lên tiếng về cùng một vấn đề nhiều lần thì bạn sẽ được coi là một người đánh cá, và những người hay than vãn sẽ không hữu ích. Nếu bạn không hiểu nó và không ai trong nhà thực sự hiểu nó về mặt kỹ thuật thì đó thực sự là di sản bạn đã đúng.
maple_shaft

7
James, có thể bạn không bao giờ hài lòng với sự tầm thường nhưng từ sự trao đổi này, bạn sẽ có ấn tượng rằng bạn không giỏi trong bức tranh rộng hơn về cách phần mềm hỗ trợ doanh nghiệp và mức độ ưu tiên kinh doanh khác với bạn như thế nào.
cám dỗ

2
"Wikipedia xác định một hệ thống kế thừa là một hệ thống không còn được hiểu". Chà, nếu bạn hiểu và ghi lại nó, vì vậy nó được hiểu, thì nó sẽ không còn là một hệ thống kế thừa nữa.
DJClayworth

2
"Không bao giờ hài lòng với sự tầm thường" là một phương châm tốt, nhưng nó chỉ áp dụng cho những thứ bạn có thể kiểm soát bản thân. Nếu bạn lấy một cơ sở mã hóa tầm thường và biến nó thành một cơ sở mã hóa tài liệu tốt, dễ bảo trì, đó là công việc tuyệt vời mà bạn nên tự hào.
DJClayworth

5

Bạn là thực tập sinh. Tôi nghi ngờ rất nhiều cho dù bạn thậm chí còn từ xa với các mệnh lệnh kinh doanh hàng ngày và như mọi người đã nhận thấy, một cơ sở mã 5 năm tuổi không thực sự cũ.

Các quyết định về việc thay thế các hệ thống cũ không phải lúc nào cũng được điều khiển bằng kỹ thuật; họ được thúc đẩy bằng cách thay đổi yêu cầu kinh doanh. Đầu vào cho những người có thể là những khó khăn liên quan đến việc duy trì; nhưng vào cuối ngày, bạn cần nhận ra rằng vị trí của bạn không nhất thiết có nghĩa là bạn có tất cả các kiến ​​thức cần thiết và có sẵn. Tôi sẽ đi xa hơn để nói rằng bạn thực sự có rất ít kiến ​​thức cần thiết để thực hiện cuộc gọi về những gì là di chuyển tốt nhất hiện nay.

Lời khuyên của tôi cho bạn là: hãy học hỏi kinh nghiệm và ngừng giả định rằng kiến ​​thức của bạn vượt qua những người phải điều hành công việc hàng ngày.

Công việc của bạn là giữ cho hệ thống hoạt động, không phải đề xuất một sự thay thế mới sáng bóng.

Dường như với tôi, rất nhiều lập trình viên trẻ không nhận ra rằng việc bảo trì các hệ thống cũ là một phần lớn hơn của công việc lập trình so với việc thiết kế các hệ thống mới sáng bóng /


Tôi tin rằng bạn đã đúng khi tuyên bố rằng tôi không hiểu bức tranh rộng hơn vì tôi không quen với chi phí liên quan đến phát triển phần mềm nội bộ. Nền giáo dục mà tôi đã tiếp xúc cho đến nay chủ yếu liên quan đến quy trình chính thức, hoặc ít nhất là nơi phát triển phần mềm là công việc chính
James

4

Đừng đẩy lùi. Điều duy nhất bạn nên làm là nói lên những lo lắng của mình một cách rõ ràng, súc tích. Thực tế của vấn đề là hầu hết các doanh nghiệp bạn sẽ làm việc trong tương lai sẽ có hệ thống kế thừa. Những hệ thống di sản đó cần được duy trì vì trong nhiều trường hợp quá đắt để thay thế.

Trong nhiều trường hợp, bạn thậm chí có thể có ý định tốt nhất là thay thế hệ thống hiện tại bằng hệ thống tốt hơn, tuy nhiên, bạn có thể chỉ đưa ra các lỗi mới và khác nhau ... khi bạn rời khỏi hệ thống sẽ nhanh chóng biến thành hệ thống cũ và công ty sẽ ở cùng một chỗ với nó trước đây Không có gì là lỗi thời cho đến khi không còn máy chủ mục đích của nó hoặc hoàn toàn không tương thích với các hệ thống hiện đại. Công ty của tôi có một hệ thống hơn 20 năm tuổi mà chúng tôi hiện đang chuyển đổi sang ASP.NET. Hệ thống vẫn chạy nhưng hỗ trợ cho công nghệ cũ đang cạn kiệt và khiến nó hoạt động với các trình duyệt web hiện đại ngày càng tốn thời gian hơn.

Bạn có thể làm gì:

Để lại những thứ sạch hơn

Khi bạn duy trì một cái gì đó hãy để nó sạch hơn so với khi bạn bắt đầu. sửa lỗi của bạn, nhưng cũng dọn dẹp mọi thứ để lần sau ai đó cần sửa đổi thì dễ hiểu hơn.

Tạo tài liệu

Nếu thiếu tài liệu là một vấn đề, tạo tài liệu. Khi bạn đang làm việc trên một phần cụ thể của tài liệu hệ thống.

Làm cho nó bớt đau

Như tôi đã nói, bạn có thể nói lên những lo lắng của mình nhưng tốt nhất bạn chỉ cần làm việc chăm chỉ trên hệ thống và làm cho nó tốt hơn để làm việc cho những người sau bạn. Sửa lỗi đúng cách. Tài liệu. Mã phân tán có mùi. Lam no tôt hơn. Và khi bạn làm những điều này, hãy cho cấp trên của bạn biết. Nói với họ rằng bạn đang làm X, Y và Z để cải thiện quá trình phát triển. Điều đó tạo dựng uy tín và về lâu dài sẽ giúp bạn và công ty của bạn hơn bất cứ điều gì khác.


1
Một trong những điều quan trọng nhất có thể được thực hiện như X, Y hoặc Z là viết các bài kiểm tra đơn vị. Việc kiểm tra giúp làm việc với mã kế thừa, có thể phá vỡ bất cứ lúc nào bằng mọi cách, ít căng thẳng hơn nhiều.
Kevin Vermeer

3

BẠN KHÔNG !!! Đây là một cơ hội TUYỆT VỜI!

Bạn là một thực tập để học! Dự án này là một thế giới thực như nó được.

Bạn rất may mắn khi có nó. Việc bạn không đủ tiêu chuẩn không phải là mối quan tâm của bạn. (Nếu \ khi quản lý nhận ra điều này, bạn sẽ đạt được rất nhiều)

BẠN sẽ đủ điều kiện một khi bạn hoàn thành công việc thực tập này, và đó là tin tuyệt vời.

PS: Tạo bản sao lưu một cách tôn giáo, hãy chắc chắn BẤT CỨ điều gì bạn làm có thể được khôi phục. Bắt đầu với các vấn đề là "Khắc phục dễ dàng" Nhưng điểm đau lớn cho người dùng. Thực hiện các bước bé.


Một điều khác mà thực tập là tuyệt vời là xác định xem bạn có muốn làm việc cho một công ty hay không, và (cho họ) liệu họ có muốn bạn làm việc cho họ hay không. Đây là một tình huống tốt hơn nhiều so với việc OP được thuê làm nhân viên chính thức và quan tâm đến việc giữ công việc đầu tiên hoặc rời đi nhanh chóng.
Kevin Vermeer

3

Tôi đoán, theo một nghĩa rất lý thuyết - không có thứ gọi là hệ thống Legacy . Tôi có một chiếc điện thoại rất cũ (một hệ thống cũ) và ngày nay có những chiếc điện thoại Android tốt (nền tảng hiện đại), nhưng điện thoại của tôi hoạt động và làm những gì tôi cần. Tại sao tôi phải vứt nó đi?

Tất cả các hệ thống mà bạn gọi là "di sản" ngày nay, là một ngày hiện đại. Đó chỉ là thời gian chúng ta cần. Ngoài ra, khi có công việc khá lớn, không phải là làm lại toàn bộ nội dung trong các nền tảng hiện đại, có nghĩa là nó sẽ tự động không có lỗi (hoặc không đau).

Đây là những gì tôi khuyên bạn nên làm:

  1. Trước tiên, bạn không thích "hệ thống di sản". Điều này sẽ làm cho bạn rất phản tác dụng.

  2. Bắt đầu ghi lại những gì bạn làm bây giờ và những gì bạn nghĩ. Mặc dù trong một cách từng bước. Không có thời gian nào tốt hơn để làm tài liệu hơn là nơi bạn nhận ra mình cần nó.

  3. Thay vì cố gắng đẩy lùi việc tiếp tục "hệ thống kế thừa" - hãy cố gắng xác định đường dẫn để thoát ra một cách suôn sẻ. Hãy thử để thấy rằng bạn có thể thuyết phục quản lý rằng sự phát triển mới hơn có thể được phân lập, có thể được thực hiện từng bước trong các hình thức mới hơn mà không phá vỡ khả năng tương tác với các hệ thống cũ. Dần dần (và điều này sẽ thực sự chậm) khi mọi thứ phát triển, nhu cầu giữ hệ thống di sản sẽ biến mất. Đó là cách duy nhất để nói lời tạm biệt với bất kỳ hệ thống cũ nào.

Dipan.


2

Sự thật là không ai cho thực tập sinh công việc họ muốn làm. Khi bạn là người trẻ nhất, bạn sẽ có được công việc ít thú vị nhất. Cá nhân bạn xử lý tốt điều đó nói lên nhiều điều như thế nào đối với tổ chức về việc họ có thể tin tưởng bạn làm nhiều công việc thú vị hơn không.

Vì vậy, đây là một cơ hội vô giá để cho thấy rằng bạn có thể cung cấp bằng cách thực hiện các sửa lỗi, rằng bạn có thể cấu trúc lại bằng cách tạo từng phần của mã bạn chạm vào một beter nhỏ, để bạn có thể tạo các bài kiểm tra đơn vị, bằng cách bắt đầu tạo chúng cho hệ thống này và rằng bạn có thể ghi lại bằng cách tạo tài liệu cho linh hồn tội nghiệp tiếp theo bị mắc kẹt với hệ thống này. Nó cũng cung cấp cho bạn cơ hội để cho thấy bạn có thể giao dịch với người dùng một cách hiệu quả (để biết thêm chi tiết về các lỗi được báo cáo) và đáp ứng nhu cầu của họ. Nếu dự án hiện không nằm trong kiểm soát nguồn, hãy đặt nó ở đó và nếu các lỗi không được theo dõi trong trình theo dõi lỗi, thì hãy bắt đầu một. Những kiểu hành động này sẽ cho bạn biết cách làm việc chuyên nghiệp.

Hoặc bạn có thể đi theo con đường ngược lại và chỉ chê bai về dự án tồi tệ như thế nào và nó sẽ tuyệt vời thế nào khi thay thế nó. Trong trường hợp đó, bạn gần như chắc chắn sẽ không được mời làm việc tại công ty đó sau khi thực tập.


1

Bạn có thể không có đủ thông tin để xác định xem có hiệu quả về chi phí khi đi thêm một năm nữa hay không. Sẽ rất thú vị khi hiểu công ty và lý do tại sao họ đang thêm người dùng. Có vẻ như có thể có một số tăng trưởng đang diễn ra và họ không đủ khả năng để lùi một bước về tài chính hoặc trong những hạn chế thời gian nhất định để xây dựng một ứng dụng khác. Xây dựng một ứng dụng mới hiếm khi là sự lựa chọn tốt nhất. 5 năm không phải là cũ trừ khi họ xây dựng nó trên công nghệ cũ để bắt đầu.

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.