Внутренняя среда и среда разработки программного обеспечения [закрыто]


13

В отрасли проводится различие между средой «внутренней разработки», в которой разработчики программного обеспечения пишут код, который будет использоваться самой компанией, и надлежащей средой «разработки программного обеспечения», в которой программное обеспечение создается для продажи / распространения. публике.

Среди прочего, одно очевидное различие между ними заключается в том, что компания, ориентированная на разработку программного обеспечения, обычно придерживается своего рода жизненного цикла разработки программного обеспечения, такого как написание спецификаций, тестирование, сборка и т. Д., В то время как магазин, ориентированный на внутренний рынок, обычно будет делать вещи более непринужденно, так как они сами являются конечными пользователями и всегда могут исправить то, что было сделано неправильно.

Будучи студентом (как и большинство других студентов), я как бы ожидал, что сам окажусь в среде разработки программного обеспечения, но в итоге я получил свою первую должность в фирме, которая работает в большей степени в своей компании.

Иногда мне интересно, упускаю ли я опыт полноценной разработки программного обеспечения. Есть ли основание для этого чувства? Должен ли я стремиться присоединиться к правильной среде разработки программного обеспечения?


9
Я думаю, что вы перестали обобщать. Используемые методологии не имеют ничего общего с собственными продуктами по сравнению с коммерчески реализуемыми проектами. Я работал над поставляемым продуктом, который был разработан специально, игнорируя многие из того, что будет считаться наилучшей практикой. Я также работал над собственными проектами, которые имели подробные спецификации, наборы тестов и множество методов контроля качества.
Томас Оуэнс

На оба вопроса вы можете ответить только сами.
Лев

6
ИМХО, ваша проблема не имеет ничего общего с отсутствием In-House против софтверной компании. Похоже, вы страдаете от неструктурированной среды разработки и отсутствия сильного наставника, который помогает вам следовать передовым практикам.
maple_shaft

1
Независимо от того, разработано ли программное обеспечение для продажи или для внутреннего использования, все это называется «разработкой программного обеспечения». Коммерческий может быть лучшим термином, чем то, что вы называете «разработкой программного обеспечения».
Калеб

1
Вы объединяете два аспекта разработки программного обеспечения - специализированный и структурированный процесс разработки, и собственное развитие против разработки продукта. Степень каждого может варьироваться независимо.
Шон Макмиллан

Ответы:


13

По моему опыту, различие, которое вы проводите между «внутри дома» и «распространяемым продуктом», является ложным.

Есть компании, которые серьезно относятся к процессу разработки программного обеспечения, а те - нет. Независимо от того, находятся ли они «в доме», «на заказ» или «термоусадочная пленка», они обычно не имеют такого значения (хотя, если они являются поставщиками «термоусадочной пленки», если у них нет процесса, они, вероятно, не будут заниматься бизнесом. длинная).

Вы должны искать место, которое соответствует стандартам развития, которые вы ищете - во время собеседования вам нужно задать эти вопросы, чтобы убедиться, что это место вам по вкусу (как и другим).


Я писал что-то похожее на это, когда ты писал. +1 только за последнее предложение, хотя это все действительные пункты.
Томас Оуэнс

@ThomasOwens - Да, видел твой комментарий к вопросу после публикации моего ответа и также ожидал от тебя ответа;)
Одед

10

Вы можете прочитать эту статью

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

Джоэла Спольски, который точно занимается вашим вопросом.

Я нахожусь в положении, когда мне приходилось работать как в последние годы, так и в связи с проданным программным продуктом среднего размера и некоторым собственным программным обеспечением. Исходя из этого опыта, я могу сказать, что между этими двумя платформами есть различия, но ситуация не так плоха, как описал Джоэл.

Например, большая часть нашего собственного программного обеспечения должна работать только в очень ограниченной среде. Множество инструментов, работающих только с определенной таблицей или версией базы данных, с определенной сетевой средой, с ограниченным числом пользователей, без необходимости установки и т. Д. Это облегчает и ускоряет разработку многих вещей по сравнению с новыми функциями, введенными в наш продукт доставки. С другой стороны, это не означает, что мой код для «собственных» программ имеет более низкое качество или написан более «случайным образом».


6

Давным-давно я читал книгу об Agile Project Management (хотелось бы, чтобы я помнил название), где автор различал системы, основываясь на их уровнях допуска к системным дефектам. Допуск на дефекты может варьироваться от очень высокого - например, утилита, используемая другими разработчиками (где ошибки являются просто неудобством), до очень низкой - например, система, которая поддерживает жизнеобеспечение космонавтов (где ошибка может быть опасным для жизни).

По мнению автора, методология разработки (и формальность) должна быть ограничена отказоустойчивостью (или критичностью) системы. Я думаю, что это различие является наиболее важным, в отличие от различия между внутренней разработкой и программным обеспечением для общего распространения.

Представьте себе больницу, в которой собственные разработчики создают системы медицинской документации, которые могут повлиять на качество медицинской помощи. В этом случае внутренний магазин, скорее всего, будет более строгим, чем консалтинг по веб-сайту, который создает веб-продукты для широкой публики.


3

Я работал в софтверных компаниях, маркетинговых агентствах, мобильных телефонах и банках, скажу одно: культура и отрасль компании определяют уровень применяемых процессов. Самой строгой, медленной, строгой и проверенной средой, которую я когда-либо испытывал, была внутренняя разработка для банка. Самым случайным было маркетинговое агентство.

Я бы порекомендовал учиться на этом опыте и использовать его, чтобы определить свое будущее направление на следующую работу. Индустрия разработки программного обеспечения не наука, ее искусство / наука, следовательно, различия и различия от компании к компании. Более важно, чтобы вы научились правильно делать код. Хотя помнить о сбоях или отсутствии процессов полезно, поэтому, когда вы управляете, вы можете реализовать более эффективные процессы.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.