Là việc tạo ra phần mềm hoàn toàn mới nói chung là một phần chính của hầu hết các công việc lập trình? [đóng cửa]

Tôi đã làm việc trong lĩnh vực phát triển phần mềm hơn 10 năm nay và tôi nhận ra rằng tôi hiếm khi tạo ra bất cứ thứ gì "mới". Tôi nhận ra rằng "mới" là một thuật ngữ mơ hồ, nhưng tôi sẽ định nghĩa nó là bất cứ thứ gì từ một dự án quy mô lớn mới rõ ràng đến một tính năng lớn mới trong một dự án hiện có (nói điều gì đó đòi hỏi một số suy nghĩ về thiết kế của nó, và điều đó có thể mất 2 tuần trở lên để hoàn thành). Có thể một hướng dẫn sơ bộ là một cái gì đó mới nếu nó yêu cầu một thông số kỹ thuật bằng văn bản. Tôi nghĩ rằng hầu hết các lập trình viên đều biết những gì tôi đang nói - bạn đang ở trong khu vực, viết rất nhiều mã với tốc độ nhanh.

Dù sao, nghĩ lại những gì tôi đã làm, tôi ước tính rằng ít hơn 10% thời gian của tôi dành cho công việc "mới". Có những thứ như "điều chỉnh hệ thống hiện có này để hoạt động trong môi trường mới này", điều này chắc chắn đòi hỏi rất nhiều kế hoạch, nhưng mã hóa thực tế và "công cụ mới" tạo ra những thay đổi nhỏ ở nhiều nơi trong toàn bộ mã. Tương tự như vậy đối với các yêu cầu tính năng nhỏ - nếu tôi biết phải làm gì, chúng thường có thể được hoàn thành trong vòng một giờ và nếu tôi không, thì đó chỉ là việc đọc nhiều mã và tìm hiểu phải làm gì (điều đó làm tôi thất vọng vì tôi học tốt hơn nhiều bằng cách làm, không phải bằng cách đọc).

Nói chung tôi cảm thấy như tôi không thực sự tạo ra bất cứ điều gì hầu hết thời gian. Tôi giả định rằng đây là trường hợp xảy ra ở hầu hết các nơi - một sản phẩm mới sẽ xuất hiện khá nhanh và tại thời điểm đó, mọi người sẽ rất phấn khích và đập mã với tốc độ nhanh, nhưng sau đó, khi nó chuyển sang chế độ bảo trì, trong đó một vài thay đổi tiếp theo sẽ được coi là "mới & sáng tạo".

Tôi có lầm không? Tôi có mô tả chính xác hầu hết các công việc lập trình, hay hầu hết các lập trình viên cảm thấy như họ thường tạo ra những thứ mới?

Rất nhiều công việc phần mềm là bảo trì. Tất nhiên, không có người quản lý tuyển dụng nào sẽ nói với bạn điều này, nhưng chắc chắn là như vậy.

Vâng, nhận thức của bạn là chính xác. Đó là một sự thật tuyệt đối rằng thời gian, tiền bạc và công sức dành cho việc duy trì các hệ thống nhiều hơn là tạo ra các hệ thống mới. Vì vậy, rõ ràng, sự phân bổ thời gian của hầu hết các lập trình viên sẽ phản ánh điều đó.

Một phần lý do cho điều này là rất nhiều người, khi họ làm "mới & sáng tạo", họ làm điều đó rất tệ, do đó việc duy trì hệ thống là khó khăn (điều này đặc biệt có thể xảy ra nếu họ chưa bao giờ tự bảo trì - không ai liên tục làm việc trong các dự án sân xanh nhỏ có thể thực sự tuyên bố là có thẩm quyền).

Một lý do khác (có thể lớn hơn) là hầu hết các hệ thống được thiết kế để liên tục hữu ích, không chỉ cho một sự kiện một lần. Vì vậy, họ tiếp tục được sử dụng lâu hơn nhiều so với việc phát triển chúng. Nhưng trong thời gian đó, các yêu cầu thay đổi (và được thêm vào) do những thay đổi về luật pháp, trên thị trường, trong nghiên cứu, ở người dùng, bất cứ điều gì. Và điều đó có nghĩa là công việc bảo trì.

Các hệ thống di sản là những người thành công. Họ đã sống sót qua quá trình phát triển ban đầu, nơi 50% dự án thất bại (ngay cả sau khi thành công đã được xác định lại!). Họ sống sót trong một môi trường kinh doanh thay đổi. Có lẽ họ đã sống sót sau khoảng mười đề xuất của các lập trình viên trẻ ngây thơ để viết lại toàn bộ nội dung bằng Java hoặc bất cứ điều gì hợp thời trang vào thời điểm đó. Họ đã đủ may mắn rằng bất cứ bộ phận, công ty hoặc cơ quan nào mà phần mềm đang phục vụ đều sống sót sau nhiều lần cắt giảm ngân sách, sắp xếp lại, sáp nhập, v.v.

Có lẽ ít hơn 5% phần mềm được viết sẽ vẫn chạy mười năm sau.

Vì vậy, thay vì than vãn về điều này, hãy coi đó là một đặc ân khi làm việc trong một câu chuyện thành công của Darwin và là cơ hội để tìm hiểu những gì hoạt động trong thế giới thực và tại sao.

Thuật ngữ thường được sử dụng cho các dự án mới không phụ thuộc vào phát triển cũ là dự án greenfield . Thỉnh thoảng bạn có thể thấy thuật ngữ trong danh sách công việc - biết rằng bạn phải bắt đầu lại từ đầu thay vì kế thừa nỗ lực thất bại của người khác có thể khiến công việc trở nên hấp dẫn hơn.

Các dự án phần mềm thành công thường dành nhiều thời gian để duy trì hơn so với việc chúng được xây dựng như các dự án mới, vì vậy không có gì đáng ngạc nhiên khi bạn không phải làm nhiều thứ hoàn toàn "mới".

Ngoài ra, tạo ra một cái gì đó hoàn toàn mới là rất nhiều công việc. Ngay cả trong dự án greenfield, bạn có thể sẽ chọn một số công cụ để giúp bạn: nền tảng, trình biên dịch, khung, thư viện, v.v ... Ngay khi bạn đưa ra những lựa chọn đó, bạn đã áp đặt một số ràng buộc nhất định cho dự án của mình. Điều đó không có nghĩa là bạn không làm việc mới nữa, chỉ có điều "mới" là một thuật ngữ tương đối ở đây. Đây không phải là một bước tiến lớn để thấy việc thêm một tính năng hoặc mô-đun vào một dự án hiện tại là "mới" mặc dù bạn sẽ không gọi đó là một dự án trường xanh.

Nó phụ thuộc vào những gì công việc bạn tìm kiếm.

Tôi chỉ có một lần làm việc cho một công ty sản phẩm phần mềm thuần túy nơi tôi làm việc trên ứng dụng mạ vàng duy nhất của họ trong một nhóm khởi nghiệp nhỏ.

Mặt khác, tôi đã làm việc cho các công ty công nghệ cần phần mềm để hỗ trợ R & D nội bộ hoặc các sản phẩm bên ngoài của họ.

Ưu điểm là tôi có thể xây dựng các sản phẩm hoàn thiện bắt đầu và xây dựng khá nhiều thứ tôi muốn. Đôi khi, bạn cũng có thể thử các công nghệ mới hơn so với việc bạn bị mắc kẹt khi thêm các tính năng vào một ứng dụng hàng đầu thị trường hiện có.

Nhược điểm là bạn là một phần của chi phí, không phải là một phần của sản phẩm. Vì vậy, tôi đã có các dự án đóng hộp vì 'chúng tôi không làm phần mềm "/" phần mềm không phải là kinh doanh cốt lõi "= thật đáng kinh ngạc khi các công ty nghĩ rằng họ có thể bán một công cụ máy K $ 100 mà không có phần mềm để vận hành nó!

Thay vì xem mã kế thừa khi liên tục dọn dẹp mớ hỗn độn của người khác, hãy xem nó như một cơ hội để thực hiện nhiều dự án mới.

Hãy nghĩ về nó, mỗi tính năng mới được thêm vào một hệ thống là một dự án nhỏ trong chính nó. Bạn vẫn cần áp dụng toàn bộ SDLC để đảm bảo bạn đã hoàn thành công việc đúng cách. Chắc chắn, bạn có thể được cung cấp một đặc điểm kỹ thuật cho tính năng này, nhưng thông thường chi tiết tốt đã bị bỏ lại, do đó, tùy thuộc vào bạn để phân tích vấn đề như được hiển thị, thiết kế phương pháp tốt nhất để áp dụng thay đổi, kiểm tra, mã hóa nó, và sau đó phát hành lại cho hệ thống kiểm soát phiên bản của bạn và hoàn toàn có thể duy trì nó trong tương lai.

Đó là kinh nghiệm của tôi khi bạn không thường xuyên làm việc trong một lĩnh vực hoàn toàn xanh và thường khi bạn đủ may mắn để làm điều đó, bạn sẽ được thấy dự án thông qua một phần tốt của bảo trì và thậm chí có thể cho thời gian tồn tại của sản phẩm hoặc trong toàn bộ thời gian bạn ở với một chủ nhân nhất định. Điều này là do trải nghiệm thân mật của bạn với một sản phẩm có nghĩa là bạn trở thành một kho lưu trữ kiến ​​thức và nó có thể được coi là tốn kém để chuyển bạn sang những thứ khác. Khi bạn bắt đầu sử dụng một sản phẩm hiện có, đó là do nhà tuyển dụng gần đây đã mất tài nguyên hoặc cần thêm tài nguyên cho dự án và họ cần phải đảm bảo rằng nó không gây tổn thất quá lớn cho khoản đầu tư mà họ đã làm trong phần mềm của mình. . Đó là thực tế của việc trở thành một kỹ sư phần mềm.

Tôi đã làm việc trong ngành CNTT gần 22 năm với 15 năm qua với tư cách là Nhà phát triển phần mềm và trong toàn bộ thời gian đó tôi chỉ tạo ra khoảng 5 sản phẩm mới, trong phần lớn thời gian của tôi là duy trì các sản phẩm đó lâu dài hoặc duy trì sản phẩm của người khác sản phẩm. Mỗi người đã cho tôi những thách thức và vấn đề cần giải quyết, và từng được coi không chỉ đơn giản là một dự án lớn mà tôi chỉ đơn thuần là một phần, mà còn là một loạt các dự án siêu nhỏ để hoàn thành.

Thật đáng ngạc nhiên khi một chút nhiệt trị tinh thần hoàn toàn có thể thay đổi nhận thức và sự thích thú của bạn đối với công việc hàng ngày mà bạn làm. ;-)

Tôi nghĩ rằng nhiều công việc phát triển phần mềm liên quan đến việc cải thiện một sản phẩm hiện có hoặc điều chỉnh mã hiện có cho một khách hàng hoặc thị trường mới.

Đây không thực sự là "bảo trì". Ví dụ, VMWare vừa phát hành phiên bản 8, đây là một bản nâng cấp lớn cho sản phẩm chính của họ. Tôi nghi ngờ một vài nhà phát triển đã thực hiện công việc này đã ở đó khi dòng mã đầu tiên cho VMWare được viết. Họ đã xây dựng bản nâng cấp lớn của họ trên mã được viết bởi những người từ lâu đã chuyển sang.

Trong bản Beta tại nơi làm việc, có một câu hỏi về cách hệ thống dự án cá nhân 20% của Google hoạt động .

Tôi chắc chắn rằng Google đã tìm ra rằng các nhà phát triển tốt nhất muốn có mặt trong việc tạo ra các sản phẩm phần mềm mới và cuối cùng sẽ mệt mỏi trong việc thêm các tính năng nhỏ và điều chỉnh gui cho phiên bản tiếp theo.

Bằng cách có 20% dự án, tôi suy đoán rằng nhà phát triển Google sẽ không ngại cải thiện các dự án của Google vì họ vẫn có thể có được niềm vui khi có mặt ở đó khi bắt đầu một cái gì đó mới.

Bạn sẽ dành thời gian để tạo chức năng mới và thay đổi chức năng của mã hiện có để phù hợp với đặc điểm kỹ thuật mới.

Những người khác đang gọi bảo trì đó nhưng đó là một thuật ngữ khủng khiếp. Đó là một thiết kế lại và tái cấu trúc hoặc mã hóa lại phần mềm để làm cho nó phù hợp với một ý tưởng mới về những gì chương trình nên làm.

Tôi muốn nói rằng nó phụ thuộc vào công ty bạn làm việc.

Công việc đầu tiên của tôi là một công ty phần mềm kế toán có sản phẩm chính là hệ thống ERP, cạnh tranh ngang hàng với Great Plains hoặc Peachtree (như bạn đã chuyển lên từ QuickBooks hoặc đi ngang khi bạn cảm thấy mệt mỏi với lược đồ bị che khuất của GP hoặc bất cứ điều gì bạn nghĩ là sai với PT, sau đó bạn chuyển ra khỏi cấp hoàn toàn thành một gói như SAP). Công việc đó là bảo trì 99,99%, được định nghĩa là sửa lỗi và thêm "công cụ nhỏ", mà không thay đổi căn bản cách thức phần mềm hoạt động hoặc những gì nó có thể làm. Tôi rời công ty khi Giám đốc điều hành muốn viết lại một trang của hệ thống, điều này sẽ rất tuyệt trừ khi anh ta khăng khăng một số tính năng thiết kế chống mô hình rõ ràng, chẳng hạn như nền tảng bên trong (cho phép mức độ tùy biến cao của chương trình bằng cách cơ bản mang đến cho khách hàng một Nhà thiết kế VS đần độn,

Công việc tiếp theo của tôi sau đó là một công ty hợp đồng đã "phát triển chìa khóa trao tay"; hệ thống mà khách hàng đã chỉ định được xây dựng từ cơ sở, phần cứng và phần mềm, sau khi hoàn thành dự án, tất cả đã được chuyển cho khách hàng có thể tự duy trì hoặc giữ lại các dịch vụ của công ty với một khoản phí hàng tháng. Công việc của tôi là phát triển một trong những dự án lớn này, và vì vậy trong khi tôi làm việc ở đó, mọi thứ tôi đã làm không tồn tại trước khi tôi bắt đầu. Ngay cả khi đó, sự phát triển vốn đã lặp đi lặp lại; bạn luôn luôn thêm vào những gì bạn đã có (ngay cả khi những gì bạn có không là gì), và bạn phải tránh và khắc phục các vấn đề hồi quy (công cụ mới phá vỡ công cụ cũ). Và một khi dự án chuyển sang trạng thái "bảo hành",

Công việc hiện tại của tôi là quay lại phát triển nội bộ, cho một công ty bảo mật sử dụng giám sát video và phản hồi âm thanh để cung cấp xác minh tín hiệu báo động và các dịch vụ "bảo vệ ảo" khác. Lĩnh vực này đang phát triển nhanh chóng và vẫn đang phát triển; Thiết bị mới gia nhập thị trường mọi lúc, khách hàng mới đã đăng ký, những người muốn chúng tôi làm những điều mới, và các sản phẩm hiện tại không còn đáp ứng được sự thích nghi của UL và chính phủ. 99% công việc này là "tích hợp"; viết phần mềm mới chưa từng tồn tại trước đây, để làm cho một thiết bị hoặc phần mềm mới nhưng có sẵn hoạt động với một phần mềm hoặc thiết bị có sẵn cũ hơn, để chúng ta có thể làm những điều mới với cả hai.

Tôi muốn nói rằng nó phụ thuộc rất nhiều vào bản chất của vai trò của bạn.

Tôi là một phần của một nhóm nhỏ và như vậy, phải duy trì và hỗ trợ mọi thứ tôi tạo ra.

5 năm trước, hầu hết những gì tôi đã làm là "mới" - bây giờ tôi nói rằng việc bảo trì mã hiện tại chiếm ít nhất một nửa thời gian của tôi, với hơn 25% là các phiên bản "mới" của các hệ thống hiện có.

Nhưng nếu bạn chỉ làm việc với tư cách là nhà phát triển với một nhóm để bảo trì và hỗ trợ sau khi bạn phát hành mã thì về mặt kỹ thuật, mọi thứ sẽ là "mới". Nếu bạn có thể tìm được một công việc mà việc duy trì mã của riêng bạn không bắt buộc, hãy thực hiện nó!

1. Nó phụ thuộc vào mức độ nguy hiểm của vị trí công việc của bạn: ;-)

   Nếu bạn làm việc cho một công ty mới phát triển một sản phẩm mới có rủi ro cao rằng công ty sẽ tồn tại, bạn có thể tạo ra một số sản phẩm mới tuyệt vời.

   Nếu bạn làm việc cho một công ty cũ có vị trí ổn định trên thị trường, nhiều khả năng bạn sẽ viết mã trong chế độ bảo trì ;-).

2. Việc tạo ra phần mềm mới luôn rất hấp dẫn . Sự thật là khó để làm điều này một cách đúng đắn . Làm mã duy trì không phải là một nhiệm vụ tầm thường.

   Nếu bạn nghĩ về hàng tấn khía cạnh này, bạn phải đảm bảo viết mã tốt: ghi nhật ký thích hợp, theo dõi và thống kê thích hợp, thiết kế mô tả hiệu quả và giúp những người không quen biết tham gia vào dự án của bạn, ghi lại tài liệu, kiểm tra tự động và phát triển theo hướng kiểm tra.

Không có nhiều người đang làm đúng, vì vậy chúng tôi phải duy trì mã của họ và đánh bóng nó đến trạng thái thích hợp. ;-)

Tin tốt là nếu bạn ở trong công ty đủ lâu, bạn có thể có ảnh hưởng đến cách viết mã mới :-)

Cho dù bạn chủ yếu thực hiện bảo trì hay không ít nhất là một phần dưới sự kiểm soát của bạn. Trong trường hợp của tôi, hầu hết các công việc của tôi trong hơn 15 năm qua là sự phát triển mới. Điều này là do tôi tìm kiếm các công việc cho phép tôi phát triển mới. Tôi không phải là nhà thầu và tôi thực sự không phát triển web. Tôi hầu như luôn làm việc cho các nhà tuyển dụng nhỏ và tôi thường làm việc trong các lĩnh vực thích hợp (phát triển GUI trên máy tính để bàn, công cụ QA, công cụ dành cho nhà phát triển, thị trường dọc).

Tôi cũng đã thấy và trải nghiệm trực tiếp rằng các lập trình viên giỏi nhất trong nhóm thường (mặc dù không phải lúc nào) có được công việc tốt nhất. Vì vậy, hãy tập trung vào việc trở thành lập trình viên giỏi nhất tại công ty của bạn và bạn sẽ bắt đầu thấy sự phát triển mới theo cách của mình.

Phát triển bảo trì là một nhiệm vụ khó khăn, khó hơn về nhiều mặt so với phát triển mới. Theo kinh nghiệm của tôi, các nhà tuyển dụng muốn giữ một nhà phát triển bảo trì, đặc biệt nếu họ giỏi về nó. Tìm kiếm các nhà phát triển bảo trì tốt trong các công nghệ cũ khó hơn tìm một người có thể làm việc với công nghệ mới nhất.

Tôi đã làm việc tại một công ty được chia thành một nhóm sản phẩm, tất cả là bảo trì và một nhóm dự án, đó là tất cả sự phát triển mới. Có những nhà phát triển tuyệt vời ở cả hai phía, nhưng những người bảo trì chắc chắn là những chuyên gia kế thừa và chuyên dụng hơn.

Tôi có thể đưa ra một đề nghị rằng bạn đẩy lùi và yêu cầu một số công việc phát triển mới? Và nếu chủ nhân của bạn chỉ bảo trì thì có lẽ bạn cần phải tiếp tục?

Tôi sẽ nói rằng nó phụ thuộc vào rất nhiều yếu tố. Bạn làm việc ở đâu, bạn làm loại sản phẩm gì, nhóm của bạn được tổ chức như thế nào, v.v.

Bốn năm tôi làm việc tại công ty của mình, tôi sẽ nói rằng 70-80% thời gian của tôi là dành cho việc tạo ra một cái gì đó mới. Có lẽ 50-60% trong số đó được dành cho các dự án lớn là mã hoàn toàn mới, trong khi phần còn lại dành cho việc cải tiến chức năng hiện tại.

Một phần trong đó tôi biết là cách công ty của tôi hoạt động. Không phải ai trong nhóm phát triển của tôi cũng dành nhiều thời gian để xây dựng chức năng mới. Có một số tập trung thời gian của họ vào không có gì ngoài sửa lỗi / săn bắn. Nếu đó là một phần hoàn toàn mới của chức năng hoặc họ cần giúp đỡ, thì nó sẽ được tôi điều tra. Tuy nhiên, nói chung, nhóm thợ săn lỗi nhỏ đó là thứ cho phép nhóm nhà phát triển lớn hơn nhấn vào mà không bị gián đoạn.

Tôi đã làm việc gần ba năm với tư cách là nhà phát triển duy nhất trong một công ty sử dụng QuickBooks và Excel và không có gì khác khi tôi bắt đầu. Bây giờ chúng tôi đã có ứng dụng Windows Forms , thiết lập SharePoint , SQL Server + Báo cáo, bổ trợ Excel và bổ trợ Outlook.

Mới hôm nay , tôi thiết lập lần đầu tiên một hệ thống bán vé vì tôi mất khả năng quản lý các yêu cầu email với tốc độ khiến người dùng không phàn nàn, vì vậy tôi xem đây là một dấu hiệu cho thấy tôi đã vào chế độ bảo trì.

Các công việc trước đây của tôi giống với những gì những người khác đã đăng, nhưng tôi cho rằng tôi đã ném vào trải nghiệm không điển hình của mình chỉ vì nó cho thấy bạn không bao giờ biết công việc tiếp theo sẽ mang lại điều gì. Tôi kiệt sức, nhưng số tiền tôi học được trong công việc này là xứng đáng với công việc.

Một số tổ chức lớn hơn như Công ty tôi làm việc có chính sách ngừng hoạt động phần mềm sau một số năm, có lẽ vì ngôn ngữ phát triển mà nó được viết không còn được sử dụng (Delphi có ai không?) Hoặc nền tảng đang được thay thế (Windows XP) , hoặc yêu cầu quy định yêu cầu nó. Ví dụ, hai chương trình tầng nói chuyện trực tiếp với cơ sở dữ liệu hiện đang được ngừng hoạt động theo hướng có lợi cho ba tầng sử dụng kết nối Kerberized để bảo mật cao hơn.

Người dùng vẫn cần chức năng ban đầu đó và do đó, một phiên bản hoàn toàn mới sử dụng các kỹ thuật hiện đại được phát triển.

Mong đợi một chu kỳ thay thế 5-7 năm cho loại điều này. Ví dụ, vào năm 2020, tôi hy vọng phần mềm WPF (Client) / Java (server) tôi đang viết bây giờ sẽ là công nghệ cũ và được thay thế bằng một cái gì đó mới hơn.