Şirket İçi ve Yazılım Geliştirme Ortamı [kapalı]

Endüstride, yazılım geliştiricilerin şirketin kendisi tarafından kullanılacak kod yazdığı 'şirket içi geliştirme' ortamı ile yazılımın satılmak / dağıtılmak üzere oluşturulduğu uygun bir 'yazılım geliştirme' ortamı arasında bir ayrım vardır. halka.

Diğerleri arasında, ikisi arasındaki bariz bir fark, yazılım geliştirme odaklı bir şirketin tipik olarak spesifikasyon yazma, test etme, inşa etme gibi bir tür yazılım geliştirme yaşam döngüsüne bağlı kalacağı, oysa şirket içi odaklı mağazanın genellikle kendileri son kullanıcı oldukları ve her zaman doğru yapılmayan bir şeyi düzeltebildiği için işleri daha rahat bir şekilde yapın.

Bir öğrenci olarak (diğer öğrencilerin çoğu gibi) kendimi bir yazılım geliştirme ortamında çalışmaya başlamamı bekledim, ancak daha çok şirket içi tarzda çalışan bir firmada ilk pozisyonumu elde ettim.

Bazen, tam teşekküllü yazılım geliştirme deneyimini kaçırıp kaçırmadığımı merak ediyorum. Bu his için bir temel var mı? Uygun bir yazılım geliştirme ortamına katılmalı mıyım?

Benim tecrübelerime göre, "kurum içi" ve "dağıtılabilir ürün" arasında yaptığınız ayrım yanlıştır.

Yazılım geliştirme süreçlerini ciddiye alan ve almayan şirketler var. İster "şirket içinde", ister "ısmarlama" ya da "shrink wrap" olsun, o kadar fazla gelmeme eğilimindedir (eğer "shrink wrap" sağlayıcıları olsalar da, süreçleri yoksa, muhtemelen iş için olmayacaklardır. uzun).

Aradığınız geliştirme standartlarına sahip bir yer aramalısınız - görüşme yaparken, yerin bu açıdan (ve diğerlerinin) beğeninize uygun olduğundan emin olmak için bu soruları sormanız gerekir.

Bu makaleyi okuyabilirsiniz

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

sorunuzu tam olarak ele alan Joel Spolsky.

Hem son yıllarda çalışmak zorunda olduğum bir pozisyondayım - satılan orta büyüklükte bir yazılım ürünü ve bazı şirket içi yazılımlar. Bu deneyimden, size bu iki platform arasında farklılıklar olduğunu söyleyebilirim, ancak durum Joel'in tanımladığı kadar kötü değil.

Örneğin, şirket içi yazılımlarımızın çoğu yalnızca çok sınırlı bir ortamda çalışmak zorundadır. Belirli bir e-tablo veya veritabanı sürümüyle, belirli bir ağ ortamıyla, sınırlı sayıda kullanıcıyla, kurulum rutinine gerek duyulmadan vb.Çalışan birçok araç, tanıtılan yeni özelliklere kıyasla çok daha kolay ve hızlı bir şekilde geliştirilmesini sağlar. nakliye ürünümüz. Öte yandan, bu "kurum içi" programlar için kodumun daha düşük kalitede olduğu veya daha "sıradan bir şekilde" yazıldığı anlamına gelmez.

Uzun zaman önce, yazarın sistemleri sistem hatalarına karşı tolerans düzeylerine göre ayırt ettiği Agile Project Management (başlığı hatırlayabilseydim) adlı bir kitap okudum. Hata toleransı çok yüksek olabilir - örneğin, diğer geliştiriciler tarafından kullanılan bir yardımcı program (hataların sadece bir rahatsızlık olduğu yerlerde), çok düşük - örneğin, astronotlar için yaşam desteğini çalıştıran bir sistem (bir hatanın hayatı tehdit edici olabilir).

Yazarın amacı, geliştirme metodolojisinin (ve formalitesinin) sistemin başarısızlık toleransına (veya kritikliğine) sahip olması gerektiğiydi. Bence bu ayrım, kurum içi geliştirme ile genel dağıtım yazılımı arasında ayrım yapmak yerine en önemlisidir.

Kurum içi geliştiricilerin tıbbi bakım kalitesini etkileyebilecek tıbbi kayıt sistemleri oluşturduklarını düşünün. Bu durumda, şirket içi dükkan, genel halk tarafından kullanılacak web ürünleri inşa eden bir web sitesi danışmanlığından daha sıkı olacaktır.

Yazılım evleri, pazarlama ajansları, cep telefonu telekomları ve bankalar için çalıştım, söyleyeceğim tek şey, şirketin uyguladığı süreçlerin seviyesini belirleyen kültür ve sanayi. Şimdiye kadar yaşadığım en titiz, yavaş, kısıtlayıcı ve test edilmiş ortam, bir banka için şirket içi gelişimdi. En sıradan olanı bir pazarlama ajansı idi.

Bu deneyimden öğrenmenizi ve bir sonraki işiniz için gelecekteki yönünüze karar vermek için kullanmanızı tavsiye ederim. Yazılım geliştirme endüstrisi bir bilim değil, sanatı / bilimi dolayısıyla şirketten şirkete farklılık ve farklılıklar. Kodunuzla ilgili doğru şeyleri yapmayı öğrenmeniz daha önemlidir. Her ne kadar başarısızlıkların veya süreç eksikliğinin zihinsel bir notunu almak faydalı olsa da, yöneticiniz daha iyi bir süreç uygulayabilirsiniz.