Môi trường trong nhà so với phát triển phần mềm [đóng]


13

Trong ngành, có một sự khác biệt giữa môi trường 'phát triển nội bộ' nơi các nhà phát triển phần mềm đang viết mã sẽ được sử dụng bởi chính công ty và môi trường 'phát triển phần mềm' thích hợp nơi phần mềm được xây dựng để bán / phân phối cho công chúng

Trong số những người khác, một điểm khác biệt rõ ràng giữa hai công ty là một công ty định hướng phát triển phần mềm thường sẽ tuân thủ một số loại vòng đời phát triển phần mềm như viết đặc tả, thử nghiệm, xây dựng, v.v. trong khi cửa hàng định hướng trong nhà thường sẽ làm mọi thứ theo cách giản dị hơn vì chính họ là người dùng cuối và luôn có thể sửa những thứ không được thực hiện đúng.

Là một sinh viên (giống như hầu hết các sinh viên khác), tôi mong muốn bản thân sẽ làm việc trong môi trường phát triển phần mềm, nhưng cuối cùng tôi đã có được vị trí đầu tiên tại một công ty hoạt động theo kiểu thời trang nội bộ.

Đôi khi, tôi tự hỏi liệu tôi có đang bỏ lỡ trải nghiệm phát triển phần mềm đầy đủ không. Có một cơ sở cho cảm giác này? Tôi có nên tìm cách tham gia một môi trường phát triển phần mềm thích hợp?


9
Tôi nghĩ rằng bạn đang quá khái quát. Các phương pháp được sử dụng không liên quan gì đến các sản phẩm nội địa so với các dự án được bán thương mại. Tôi đã làm việc trên một sản phẩm được vận chuyển được phát triển rất đặc biệt, bỏ qua nhiều điều sẽ được coi là thực tiễn tốt nhất. Tôi cũng đã làm việc với các dự án nội bộ có thông số kỹ thuật chi tiết, bộ thử nghiệm và rất nhiều thực hành kiểm soát chất lượng.
Thomas Owens

Cả hai câu hỏi bạn đặt ra chỉ có thể được trả lời bởi chính bạn.
leo

6
IMHO, vấn đề của bạn không liên quan gì đến việc bỏ lỡ In-House so với công ty phần mềm. Bạn có vẻ như bạn đang chịu đựng trong một môi trường phát triển không có cấu trúc và không có một người cố vấn mạnh mẽ giúp bạn tuân theo các thực tiễn tốt nhất.
maple_shaft

1
Cho dù phần mềm được phát triển để bán hay sử dụng nội bộ, tất cả đều được gọi là "phát triển phần mềm". Thương mại có thể là một thuật ngữ tốt hơn so với những gì bạn gọi là 'phát triển phần mềm'.
Caleb

1
Bạn đang kết hợp hai khía cạnh của phát triển phần mềm - quy trình phát triển có cấu trúc và quảng cáo có cấu trúc và phát triển nội bộ so với phát triển sản phẩm. Mức độ của mỗi có thể khác nhau độc lập.
Sean McMillan

Câu trả lời:


13

Theo kinh nghiệm của tôi, sự khác biệt mà bạn đang thực hiện giữa "trong nhà" và "sản phẩm phân phối" là sai.

Có những công ty coi trọng quy trình phát triển phần mềm của họ và những công ty thì không. Cho dù họ là "trong nhà" hay "bespoke" hay "co lại" có xu hướng không tham gia vào đó nhiều (mặc dù nếu họ là nhà cung cấp "thu nhỏ", nếu họ không có quy trình thì có lẽ họ sẽ không kinh doanh Dài).

Bạn nên tìm một nơi có tiêu chuẩn phát triển mà bạn đang tìm kiếm - khi phỏng vấn bạn cần hỏi những câu hỏi này để đảm bảo nơi đó theo ý thích của bạn về mặt này (cũng như khác).


Tôi đã viết một cái gì đó tương tự như thế này khi bạn đăng. +1 chỉ cho câu cuối cùng, mặc dù đó là tất cả các điểm hợp lệ.
Thomas Owens

@ThomasOwens - Vâng, đã thấy bình luận của bạn cho câu hỏi sau khi đăng câu trả lời của tôi và đang mong đợi câu trả lời từ bạn;)
Oded 19/12/11

10

Bạn có thể đọc bài viết này

http://www.joelonsoftware.com/items 2007/12 / 04.html

của Joel Spolsky, đó chính xác là câu hỏi của bạn.

Tôi đang ở một vị trí mà tôi phải làm việc trong cả hai năm qua - một sản phẩm phần mềm cỡ trung bình được bán và một số phần mềm nội bộ. Từ trải nghiệm đó, tôi có thể nói với bạn rằng có sự khác biệt giữa hai nền tảng đó, nhưng tình hình không tệ như Joel đã mô tả.

Ví dụ, hầu hết các phần mềm nội bộ của chúng tôi chỉ phải chạy trong một môi trường rất hạn chế. Rất nhiều công cụ chỉ hoạt động với một phiên bản cơ sở dữ liệu hoặc bảng tính nhất định, với môi trường mạng cụ thể, với số lượng người dùng bị hạn chế, không cần cài đặt thường xuyên, v.v. Điều đó giúp phát triển nhanh hơn và dễ dàng hơn so với các tính năng mới được đưa vào sản phẩm vận chuyển của chúng tôi. Mặt khác, điều đó không có nghĩa là mã của tôi cho các chương trình "nội bộ" có chất lượng thấp hơn hoặc được viết theo cách "thông thường" hơn.


6

Cách đây rất lâu, tôi đã đọc một cuốn sách về Quản lý dự án Agile (tôi ước tôi có thể nhớ được tiêu đề), trong đó tác giả phân biệt các hệ thống dựa trên mức độ chịu đựng của chúng đối với các lỗi hệ thống. Dung sai cho các khiếm khuyết có thể dao động từ rất cao - ví dụ, một tiện ích được sử dụng bởi các nhà phát triển khác (trong đó các lỗi chỉ là sự bất tiện), đến rất thấp - ví dụ, một hệ thống đang chạy hỗ trợ sự sống cho các phi hành gia (trong đó một lỗi có thể bị đe dọa tính mạng).

Quan điểm của tác giả là phương pháp phát triển (và hình thức) cần phải nằm trong phạm vi dung sai thất bại (hoặc mức độ quan trọng) của hệ thống. Tôi nghĩ rằng sự khác biệt này là quan trọng nhất, trái ngược với việc phân biệt giữa phát triển nội bộ so với phần mềm để phân phối chung.

Hãy tưởng tượng một bệnh viện có các nhà phát triển nội bộ xây dựng các hệ thống hồ sơ y tế có thể ảnh hưởng đến chất lượng chăm sóc y tế. Trong trường hợp này, cửa hàng trong nhà có thể sẽ nghiêm ngặt hơn so với tư vấn trang web, người đang xây dựng các sản phẩm web được sử dụng bởi công chúng.


3

Tôi đã từng làm việc cho các nhà phần mềm, các cơ quan tiếp thị, các công ty viễn thông và điện thoại di động, một điều tôi sẽ nói, đó là văn hóa và ngành công nghiệp của công ty, quy định mức độ của các quy trình được áp dụng. Môi trường khắt khe, chậm chạp, hạn chế và thử nghiệm nhất mà tôi từng trải qua là phát triển nội bộ cho một ngân hàng. Bình thường nhất là một cơ quan tiếp thị.

Tôi khuyên bạn nên học hỏi từ kinh nghiệm này và sử dụng nó để quyết định hướng đi trong tương lai cho công việc tiếp theo của bạn. Ngành công nghiệp phát triển phần mềm không phải là một khoa học, nghệ thuật / khoa học của nó do đó có sự khác biệt và khác biệt giữa các công ty. Điều quan trọng hơn là bạn học cách làm những điều đúng về mã của mình. Mặc dù việc ghi chú tinh thần về những thất bại hoặc thiếu các quy trình là hữu ích, vì vậy khi người quản lý của bạn, bạn có thể thực hiện một quy trình tốt hơ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.