Wewnętrzne a środowisko programistyczne [zamknięte]

W branży istnieje rozróżnienie między środowiskiem „opracowywania wewnętrznego”, w którym twórcy oprogramowania piszą kod, który będzie używany przez samą firmę, a odpowiednim środowiskiem „opracowywania oprogramowania”, w którym oprogramowanie jest budowane w celu sprzedaży / dystrybucji Publicznie.

Między innymi jedną oczywistą różnicą między nimi jest to, że firma zorientowana na rozwój oprogramowania będzie zazwyczaj przestrzegać pewnego rodzaju cyklu życia oprogramowania, takiego jak pisanie specyfikacji, testowanie, budowanie itp., Podczas gdy sklep zorientowany na firmę zazwyczaj będzie robić rzeczy w bardziej swobodny sposób, ponieważ sami są użytkownikami końcowymi i zawsze mogą naprawić coś, co nie zostało zrobione dobrze.

Jako student (podobnie jak większość innych studentów) spodziewałem się, że skończę pracować w środowisku programistycznym, ale ostatecznie dostałem swoją pierwszą pozycję w firmie, która działa w bardziej wewnętrzny sposób.

Czasami zastanawiam się, czy brakuje mi pełnego doświadczenia w tworzeniu oprogramowania. Czy istnieje podstawa tego uczucia? Czy powinienem starać się dołączyć do odpowiedniego środowiska programistycznego?

Z mojego doświadczenia wynika, że ​​rozróżniasz między „produkcją wewnętrzną” a „produktem do dystrybucji” jest fałszywy.

Są firmy, które poważnie podchodzą do procesu tworzenia oprogramowania, a takie nie. Niezależnie od tego, czy są „w domu”, „na zamówienie”, czy „folią termokurczliwą”, zwykle nie wchodzą w to tak często (chociaż jeśli są dostawcami „folii termokurczliwych”, jeśli nie mają procesu, prawdopodobnie nie będą prowadzić działalności długo).

Powinieneś szukać miejsca, które ma standardy rozwoju, których szukasz - podczas rozmowy kwalifikacyjnej musisz zadać te pytania, aby upewnić się, że miejsce podoba Ci się pod tym względem (a także inne).

Możesz przeczytać ten artykuł

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

Joela Spolsky'ego, który dokładnie zajmuje się twoim pytaniem.

Jestem w pozycji, w której musiałem pracować zarówno przez ostatnie lata - sprzedawany średniej wielkości produkt programowy, jak i oprogramowanie wewnętrzne. Z tego doświadczenia mogę powiedzieć, że istnieją różnice między tymi dwiema platformami, ale sytuacja nie jest taka zła, jak opisał to Joel.

Na przykład większość naszego wewnętrznego oprogramowania musi działać tylko w bardzo ograniczonym środowisku. Wiele narzędzi po prostu współpracuje z określoną wersją arkusza kalkulacyjnego lub bazy danych, z określonym środowiskiem sieciowym, z ograniczoną liczbą użytkowników, nie wymaga rutynowej instalacji itp. To sprawia, że ​​wiele rzeczy jest łatwiejszych i szybszych do opracowania w porównaniu z nowymi funkcjami wprowadzonymi do nasz produkt wysyłkowy. Z drugiej strony nie oznacza to, że mój kod dla programów „wewnętrznych” ma niższą jakość lub jest napisany w bardziej „swobodny sposób”.

Dawno temu czytałem książkę o zwinnym zarządzaniu projektami (chciałbym pamiętać tytuł), w której autor wyróżniał systemy na podstawie ich poziomów tolerancji na wady systemu. Tolerancja dla defektów może wahać się od bardzo wysokiej - na przykład narzędzia używanego przez innych programistów (gdzie błędy są jedynie niedogodnością), do bardzo niskiego - na przykład systemu, który obsługuje podtrzymywanie życia astronautów (gdzie błąd może zagrażać życiu).

Autor stwierdził, że metodologię rozwoju (i formalność) należy dostosować do tolerancji na awarie (lub krytyczności) systemu. Myślę, że to rozróżnienie jest najważniejsze, w przeciwieństwie do rozróżnienia między programowaniem wewnętrznym a oprogramowaniem do ogólnej dystrybucji.

Wyobraź sobie szpital, w którym wewnętrzni programiści budują systemy dokumentacji medycznej, które mogą mieć wpływ na jakość opieki medycznej. W takim przypadku sklep wewnętrzny byłby prawdopodobnie bardziej rygorystyczny niż doradztwo na stronie internetowej, które buduje produkty internetowe do użytku przez ogół społeczeństwa.

Pracowałem dla software house'ów, agencji marketingowych, operatorów telefonii komórkowej i banków. Powiem jedno, to kultura i przemysł firmy, który decyduje o poziomie stosowanych procesów. Najbardziej rygorystycznym, powolnym, restrykcyjnym i przetestowanym środowiskiem, jakie kiedykolwiek spotkałem, było wewnętrzne opracowanie banku. Najbardziej zwyczajna była agencja marketingowa.

Polecam uczyć się na podstawie tego doświadczenia i wykorzystać je do podjęcia decyzji o przyszłym kierunku przyszłej pracy. Branża tworzenia oprogramowania nie jest nauką, jej sztuką / nauką stąd różnice i różnice między firmami. Ważniejsze jest, abyś nauczył się dobrze postępować z kodem. Chociaż przydatne jest zanotowanie w pamięci błędów lub braku procesów, więc kiedy menedżer może wdrożyć lepsze procesy.