Geliştiricilerin farklı şekilde ne yapmasını istersiniz? [kapalı]

Bir geliştirici olarak zamanımın çoğunu kod, UI, veri yapıları vb. Hakkında düşünerek harcıyorum, ancak (cesurca itiraf ediyorum) uygulamamın sysadmins ve DBA'lar üzerindeki etkilerini düşünmeye meyilli değilim. uygulama.

İlk olarak, özür dilerim. İkincisi, siz ve uğraştığınız diğer geliştiricilerin farklı yapmasını ne istiyorsunuz? Hangi şeyler hayatı sizin için kolaylaştıracak, daha az soruna neden olacak, işbirliğini teşvik edecek ve kazaları, performans sorunlarını ve yapılandırma kabuslarını azaltacaktır?

1. 0 günden itibaren güvenliği düşünün ve geliştirin.
2. Her şey için sürüm kontrolünü kullanın: kaynak kodu, dokümantasyon, konfigürasyon vb.
3. Belgeler, belgeler, belgeler.
4. Platformda yerel paketleme kullanarak temiz kurulum ve sökme
5. Yapılandırma verilerini kitaplıklardan ve yürütülebilir dosyalardan ayırın
6. Test ve geçiş için farklı sürümleri paralel olarak çalıştırma desteği
7. Sağlam, yapılandırılabilir günlük kaydı
8. Hafif, doğru, güvenli izleme
9. Uygulama kontrol belirleme ve yedekleme
10. Uygulamanız sorunlara nasıl tepki veriyor: bellek yetersiz, dosya sistemi dolu, ağ bağlantısı kapalı, eksik / bozuk yapılandırma dosyaları, zaman kayması?
11. Her zaman ayrı geliştirme, test etme ve üretim ortamlarına sahip olun. Tüm ücretsiz VM yazılımı ile hiçbir bahane yok!

Uygulamanızın muhtemelen yukarı veya aşağıdan daha fazla durum olduğunu unutmayın. Bir durum diyagramı çizin. Çoğu uygulamada aşağıdaki gibi durumlar vardır:

• aşağı
• ilk olarak başlatılması
• kurtarma
• yukarı-ama-kabul etmiyor-iş
• bekleme
• checkpointing
• işleme
• bitirmek
• kapatmak
• aşağı

Sistem her durumda çökerse ne olacağını düşünün. Bir sysadmin durum geçişlerini nasıl izleyecek ve kontrol edecektir?

"Kullanıcı" yı SA'dan ayırın.

Bir "kullanıcı", yazılımınızı nasıl kullanacağınızı bilmelidir. Kullanıcılar, yazılımınızı nasıl kuracağınızla ilgilenmez.

SA yazılımınızı nasıl kullanacağınızı önemsemez, ancak yazılımı nasıl yükleyeceğinizle ilgili bazı önemli ayrıntıları bilmesi gerekir.

Her biriyle ilgili bilgiler de dahil olmak üzere, bu rollerin her biri için ayrı ayrı belgeler yazın.

İsteklerimden biri de istisnalara ve hata kodlarına uygun mesajların eklenmesi. Ne JimmyNotAtHomeException: it's late!anlama geldiğini uygulamayı geliştirmemiş birine tamamen opak .

Ancak böyle bir mesaj Unable to find jimmy - initial manual call_mother procedureçok faydalıdır.

İletişim, iletişim, iletişim. Bir sysadmin ve dev arasındaki her problem hemen hemen her zaman iletişim eksikliğine kadar takip edilebilir. Bir projeden önce sistem yöneticileri (veya bunların bir temsilcisi) ve dev'ler bir araya geldiler ve güzel bir çerçeve tartışması yaptılarsa, SOOOOOOOOOO, birçok sorundan kaçınılabilirdi. Size kaç şeyin yol açtığını söyleyemem, çünkü geliştirici bir kutudaki herkesi prod'daki alevler içinde izlemek için geliştiriyorsunuz çünkü uygulama daha sonra Uygulama sunucusu + DB sunucusu + arabirim sunucusuna vs. ayrılıyor. Bu konuyu gündeme getirdiğin için teşekkür ederim.

Projenin başlarında bizi meşgul et. İşlevsel aşamada, gerçek gerçek erken gibi.

Bir başkası her PC'ye manuel olarak kurmak zorunda olduğunu söyledi, ancak aynısı config ve config değişiklikleri için de geçerli. Connect dizileri istemci tarafı gibi bir şey depolamayı seçerseniz ve bunları düzenli aralıklarla güncellemeniz gerekirse, muhtemelen sizi öldürmek isteriz .

Aynı nedenden dolayı merkezi olarak yönetilebilecek ve yapılandırılabilecek teknolojiyi seçin. Kullandığımız merkezi yönetim araçlarıyla iyi bir şekilde bütünleştiğinden emin olun.

Daima en düşük ortak payda kullanarak test edin. Bu, Yönetici olmayan, en ilkel işletim sistemlerinde, ortak kullanımda uygulama paketi ve tarayıcı plaformu anlamına gelir. Mümkün olan en son dakikada üzerimize düşen tüm kullanıcılarımız için gerekli bir tarayıcı güncellemesi yapmaktan hoşlanmıyoruz.

İşler ters gittiğinde bizi suçlamaya atlama. Eski işimde her zaman bir uygulama bozulduğunda, geliştiriciler anında bize parmağını gösterirdi. "Yeni bir yama yüklediniz, tarayıcıları yükseltmeyeceksiniz, güvenliğiniz çok sıkı" ya da her neyse. Bu yıkıcı bir atmosfer oluşturur. Gerçekten aynı taraftayız ve düzeltmek için sizinle birlikte çalışmak istiyoruz, ancak bu tür durumlarda yapamayız.

Elitist olma.

"Dostum benim zaman kaybetmeyin sadece bir köle gibi çalıştırılan kimse sitem;. Ben yazılım yazmak ve sen sadece bunu hizmet dediklerimi Dolayısıyla, sadece küçük endişeleri ile sus ve yapmak, tamam.?"

Bir geliştirici aslında bu kelimeleri bana bir keresinde söyledi (1). E-postada. CC, büyük bir dağıtım grubuna. Sonuç açıktı: Bir geliştirici olarak, tüm yazılım dünyasının efendisi ve ustasıydı; ve ben sadece bir günlük işçi olarak, değerli zamanını boşa harcayamayacağı kadar önemsiz işlerle uğraşmak için işe alındım. Tabii ki bu neredeyse en kötü durumdan bir örnek, ama biliyorsunuz, bu yorumdan önce ve sonra birkaç geliştiriciden güçlü ve zayıf yankılar duydum (2).

Benden daha çok para kazanabilirsiniz (ama bunu varsaymayın!). Ancak, kullanıcılarımızın güvendiği sistemleri kurmak, işletmek ve sürdürmek için bir ekip gerekir. Nihayetinde hepimiz onlara hizmet ediyoruz.

İşinin ve yeteneklerinin benimkinden farklı olduğunu anladım. Yeteneklerine saygı duyuyorum. Umarım sorularınızı cevaplayacaksınız, basit ve size aptal gibi. Bu nezaketten neşeyle döneceğim!

Çılgınca bir güç yolculuğuna çıkmıyorum, pek çok kötü (ya da sadece umursamaz) devlerin söylediği ve düşündüğü ve çeşitli forumlarda yayınladığı gibi. Ancak endişelerim sizinkinden farklı, sorularım ve önerilerim egomun hizmetinde değil. Aslında benim işim, uygulamalarınızı en iyi çalışma koşullarında, kullanılabilir ve tüm kullanıcılara duyarlı bir şekilde tutarak sizi daha iyi görünmek. Bunu yapmak için, ağın geri kalan kısmını ve sistemlerini de en iyi durumda tutmam gerekiyor.

Geçmişte aptal, güçsüz ve / veya sadece düz tembel yöneticilere rastladığınızı tamamen biliyorum. Tek olmamaya ve birine benzememeye çalışıyorum. Bu olasılığa yer bırakıp onu gördüğünüzde onaylarsanız, diğer gerizekalılar hala sysadminlerinin ne kadar aşağılık biri olduğunu söylerken ihtiyacınız olanı alacağınızdan eminim.

(1) Programının (yazılım gereksinimlerini yazmak ve yönetmek için bir araç) yüklemek ve çalıştırmak için etki alanı yöneticisi ayrıcalıklarına ihtiyaç duyduğunu vurguladı. Bu büyük bir güvenlik riskiydi.

(2) Gerektiğinde öğretebilecek ve gerektiğinde öğrenebilecek birçok harika geliştiriciyle çalıştım.

Sistem yöneticilerinin yapacak bir işi olduğuna saygı duyun ve işlerini yapmalarına izin verin. Birçok şirket yetersiz sistem yöneticilerine sahiptir ve bu çoğu zaman gerçekçi değildir. Ancak, kibirli geliştiricilerin, sistem yöneticilerinin yeterliliklerini kanıtlamasından sonra bile sistem gruplarının tavsiyelerini görmezden geldiklerini gördüm.

Yeni bir sistemin tasarımını sysadmins ile tartışın. Genellikle değerli görüşler vardır. Geliştiriciler genellikle sysadmins ile görüşmelere bakar ve “erken optimizasyon” olarak başlangıç ​​gereksinimlerini verir. Aslında bir geliştirme grubunun başının, yazma yoğunluğu veya yoğun okuma yükü olup olmadığını tarif etse de, sistem yöneticileri ve DBA'lı yeni veritabanı sunucuları için gereklilikleri tartışması zamanının boşa gittiğini söylediğini gördüm. ne kadar depolamaya ihtiyaç duyulur.

Sysadmins ile performans sorunlarını tartışın. Dürüst olmak gerekirse, yalnızca sistem yöneticileri sistemlerdeki performans ölçütlerini doğru şekilde yorumlayabilir. Geliştiricilerin Linux'un her zaman hafızaya sızdığına karar verdiklerini gördüm, çünkü "ücretsiz" olarak bildirilen boş hafıza her zaman azalır, 10. zamandan sonra bile "boş" çıktısının açıklandığını açıklar.

Sysadmins ile tartışmadan sonuç çıkarmayın. Geliştiricilerin "veritabanları her zaman diske bağlı" (iostat'ın var olduğunu bile bilmiyorlardı), "RAID 5 işlemsel iş yükleri için daha hızlı olduğunu" (taşınan bir veritabanı sisteminin hatırlanmasına dayanarak) gibi teorilere takıldığını gördüm. bir donanım platformundan diğerine - yoğun okuma yoğun bir iş yüküydü, RAID5 çözümü daha fazla denetleyiciye yayılmış daha hızlı ve daha hızlı sürücülere sahipti, ancak bu ayrıntıları unuttular ve sadece sonucu hatırladılar.)

Sistem problemine, sistem yöneticileri ile tartışmadan bir çözüm tasarlamayın. Geliştiricilerin bir çözüm tasarlayacakları ve küçük uygulama yardımları isteyecekleri bir patolojik ortamda çalıştım. Unix grubunun üyeleri, kendimin yanı sıra, Unix grubunun başı ve patronu da, genel bir altyapı işlevi görmeye çalışan iş arkadaşlarına değil, geliştiricilere "müşteriler" olarak bakmak istedi. Müşteri her zaman haklı olmak, ne yaptıklarını veya nedenini sorgulamamak anlamına geliyordu. Doğru bir çözüme karar verebilmek için, tarif edilen sorunun tanımlanmasında ısrar edecek tek kişi bendim. Bunun gibi patolojik ortamlar yaratacak şekilde davranmayın. Net bir fayda sağlamaz - bunun yerine, sistem yöneticileri savunmada etkili olacak ve herkes acı çekecek.

Artık okulda değilsin. Bunlar gerçek dünya sistemleridir ve ideal şekilde davranmazlar. Örneğin, her şeyin sıfır gecikme süresi yoktur. Bir sysadmin sizi kümeleme çözümlerinin sadece politik amaçlar için uyardığı ve sistemin ilave karmaşıklığının genel güvenilirliği azalttığı konusunda uyardığında, ciddiye alın. Gerçek dünya arıza modları için tasarım yapmanız gerekir; örneğin, TCP üzerinden konuştuğunuz sunucuyu kaybettiğinizde, bağlantı muhtemelen sizin için sıfırlanmayacaktır. Sysadmins gerçek dünyadaki başarısızlık modlarını anlar.

Sysadmin'inizin size söylediklerini dinleyin ya da sysadmins'inizin yetersiz olduğu ve işten çıkarılmaları gerektiğinden yönetimi şikayet edin. Sysadmin'ini görmezden gelmek anlamsız.

Uygulamanızı nasıl dağıtacağınızı düşünün. Bunu sistem yöneticilerinizle tartışmanın bir anlam ifade ettiğini anlayın. Yalnızca tek bir yapılandırma dosyasına göre farklılık gösteren aynı 100 sunucunuz varsa, bu yapılandırma dosyalarının ana kopyalarını merkezi bir konumda saklamayı düşünebilirsiniz. Uygulamanızın tekrar dağıtılması kolaysa, herkesin ne kadar iyi olduğunu anlayın. Bir sistemde bir sorun varsa, bir dakikanın altında bir yedek parçaya yerleştirmeyi veya kırık olanı tamir ederken yaşları beklemeyi mi tercih edersiniz? Uygulamanızı yeniden dağıtabilirseniz, işletim sistemi daha kolay ve güvenli bir şekilde yükseltilebilir. Gelecekte bununla ilgilenebilirsin.

İşletim sistemi nedeniyle olabileceğini düşündüğünüz bir sorununuz varsa, kontrol etmek için hemen sysadmin'i çağırmanız mantıklıdır. Ancak bir sorgulama soruşturması hiçbir şey açığa çıkarmazsa, sorunu açıklamakla görevlidir.

"Yavaşça cevap verme" ile "hiç cevap vermeme" arasında bir fark olduğunu anlayın.

Geliştirdiğiniz işletim sistemi (en) için bunları değiştirmenin öngörülebilir yöntemleriyle öngörülebilir bir şekilde yapılandırma ve düzenleme. Bu her şey demektir. Örneğin: OpenLDAP'ın loglevel yapmanın tuhaf bir yolu vardır; bazı IMAP sunucularında yapılandırma dosyaları bile yoktur, ancak içinde derlenmiş seçeneklerin olması gerekir; Bazı paketler eşyalarının belirli bir dizin yolunda olmasını ister; bu da kaçınılmaz olarak belirli bir işletim sisteminin kurallarını bozacaktır. Bunların hepsi benim olağan konfigürasyonlarımdaki siğiller gibi göze çarpıyor.

Bu genel bir kuraldır, ancak özel olduğunuzu varsaymayın ve bu nedenle, yazılımınızın gerektirdiği kadar iyi bir neden olmadıkça, yazılım paketlerinin platformunuzda genel olarak nasıl çalıştığına dair genel kuralları çiğnemekle kutsandı. “Bunun böyle olması gerektiğini şiddetle hissediyorum” herkesin normal düzenini bozacak kadar iyi değil; Yazılımınızın gerçekleştirmeye çalıştığı işleve bağlı bir sebep olmalıdır.

Uygulamaya dahil olan sunucular arası iletişim olduğunda, lütfen tasarım aşamasında en az bir sysadmin ekleyin. Ayrıca, diğer hizmetlere olan bağımlılıkları da açıkça belgeleyin: SQL, SMTP, HTTP, vb ... Bize ne yaptığınızı tahmin etmeyin, bir şey beklediğiniz gibi çalışmadığında size yardımcı olamayız.

Lütfen yazılımınızı otomatik olarak düzinelerce veya yüzlerce sistemde dağıtmanızı mümkün kılar. Bir organizasyon bir yazılım paketine ihtiyaç duyuyorsa, sysadmins'in kesinlikle her kutuya manuel olarak kurmak için vakti yoktur. Bir dosyanın lisans bilgisi olması gerekiyorsa, nasıl sağlanacağını belgelemek çok yararlı olacaktır.

Adobe, tarihsel olarak üzerinde çalışılması gereken gerçek bir acı olan bazı kuruculara sahipti ; lütfen bundan daha yükseğe nişan al!

İlk günden itibaren ölçeklendirme düşünün. Sysadmins bir performans problemine para / donanım atarak harikalar yaratabilir ancak bazen bunların hiçbiri yardımcı olmaz - özellikle kilitleme hakkında düşünün - bazen kendinizi kilitleme sorunundan alamazsınız. Yine de sorduğunuz için teşekkürler :)

Oh ve mümkün olduğunda 64-bit olmaya çalışın ve çok parçacıklı :)

İşlemler için tasarım.

Burada her şeyin ötesinde ...

• Simüle edilmiş bir üretim ortamı (canlı sunucu ile aynı konfigürasyona sahip bir geliştirme sunucusu veya VM) isteyin ve ardından bırakma işlemini test etmek için kullanın. Ardından bize değişiklik listesi ve uygulanması gereken sıra dahil olmak üzere bu sürüm sürecini sağlayın (örn. 1. Bakım moduna girin, 2. SQL güncellemesini uygulayın, 3. X sürümüne güncelleme kaynağını, 4. bakım modundan çıkın, 5. dua et)
• Veri bütünlüğünü korumak için kullanıcıları atabilecek bir bakım moduna sahip olduğunuzdan emin olun. Kullanıcıların oturum açtığı ve işlemlerin gerçekleştirildiği birkaç sunucu arasında büyük bir sistem güncellemesi yapmamızı istemiyorsunuz ... bu çoğu durumda başarısızlık için bir reçetedir.
• Biraz standardize edilmiş bir geliştirme modeli kullanın. Örneğin, iş yerindeki tüm yeni uygulamalarımız (web grubu) Zend Framework'ü kullanıyor.
• Değişikliklerin kapsamı hakkında bir fikir edinmek için arayabileceğimiz bir hata listesi de dahil olmak üzere bize okuyabileceğimiz değişmezler sağlayın. Bazen potansiyel sorunları farklı bir bakış açımız olduğu için belirleyebiliriz.

Gerçekçi olmamakla birlikte, geliştiricilerin dünyaya salıverilmeden önce prodüksiyon sysadmin veya dba rolünde çalışmaya zorlanmaları yararlı olacaktır.

Ele aldığım pek çok özel uygulama, yönetilen bir ortamda kurulum hakkında hiçbir fikre sahip değil veya veritabanı tasarımının zulmünü yerine getiriyor.

1) Hataları ayrıntılarıyla kaydeden bir günlük dosyası. veya ELMAH gibi iyi bir hata takip sistemi.

2) Kurulum, uygulama ve SA kılavuzu için ayrıntılı belgeler.

3) Ayrıca yukarıda belirtilen diğer şaşırtıcı SA'lardan gelenler. :)

Şu an tek düşünebildiğim bu.

Kitap bırakın! Üretimde neyin yanlış gidebileceği ile ilgili güzel korku hikayeleri var. Okumak, akılda operasyon ile tasarım için ilham / fikir sağlayabilir. (Hem geliştirme hem de operasyonlar tarafında çalışan Michael Nygard tarafından yazılmıştır.)

• Özellikleri olmadan gelişmeyin
• Belge (veya belge yapanların bunu doğru şekilde yapmalarını sağlayın)
• Müşteriyi desteklemekten korkmayın (daha yüksek seviyeli destek olarak)

Tecrübelerime göre, en fazla fark yaratacak olan şey, geliştiricilerin 1. günden itibaren konuşlandırmayı düşünmeleri durumunda olur. Üretim / müşteri ortamında yeni bir özellik ortaya çıkarmaya başlar başlamaz, bunun bu alana nasıl yayılacağını düşünmeye başlayın. çevre ve nasıl çalışacağı.

Geliştirme sürecine girdikten sonra çok geç değildir, ancak bakış açılarını bu kadar uzağa kaydırmaları biraz zaman alabilir; onunla yüzleşmek zorunda kalana kadar kod tabanını ne kadar soyut gördüklerini anlamıyorlar. Onların aklında, bu sadece bir "bileşen". Özel ilgi alanı, yazılımın önceki (veya daha eski!) Versiyonunu çalıştırarak önceden var olan bir ortama nasıl dağıtılacağıdır . Dağıtım tartışmaları, mimarinin yeni özelliği barındıracak şekilde ayarlanması üzerinde önemli bir etkiye sahip olabilir.

Henüz görmediğim ve sevmediğim bir şey Yapılandırılabilir. Herhangi bir yapılandırma dosyası kullanan bir uygulamanız varsa, her şeyi yapılandırılabilir hale getirin.
Benim şirketimde, veritabanını dışa aktaracak basit bir uygulama yazdım. Ertesi hafta küçük bir parçanın kapatılmasını sağlamak için yeniden yazıyordum. O zamandan beri her hafta parçaları yeniden yazmak ve sadece küçük bir özelliği değiştirmek için yeniden yapmak zorunda kaldım. Sadece bir xml config dosyası ekledim ve şimdi yeniden dağıtmak çok daha kolay.
Config dosyalarını seviyorum.

Geliştiricilerin KG görevlerinden daha iyi ayrılmalarını diliyorum. Bir geliştirici üzerinde çalıştığı bir proje için bazı birim test senaryoları oluşturabildiğinde bunun güzel olduğunu düşünüyorum, ancak bu testlerin KG'ye devredilmesi güzel olurdu. Aslında, geliştiriciler QA mühendislerine küçük bir yardımda bulundukları için güzel çünkü sonuçta DEV'ye fayda sağlıyor.

Desteklenebildiğinden emin olun: burada belirtilen diğer her şeye ek olarak, SO - https://stackoverflow.com/questions/205374/what-are-the-core-elements-to-include-in-support- dokümantasyon /