Apa yang Anda harapkan akan dilakukan pengembang secara berbeda? [Tutup]

Sebagai seorang pengembang, saya menghabiskan sebagian besar waktu saya untuk memikirkan kode, UI, struktur data, dan sebagainya, tetapi (saya dengan berani mengakui) saya tidak cenderung mempertimbangkan implikasi aplikasi saya untuk sysadmin dan DBA sampai waktunya untuk menyebarkan aplikasi.

Pertama, saya minta maaf. Kedua, apa yang Anda inginkan agar saya, dan pengembang lain yang Anda tangani, akan lakukan secara berbeda? Hal-hal apa yang akan membuat hidup Anda lebih mudah, menyebabkan lebih sedikit masalah, mendorong kerja sama, dan mengurangi crash, masalah kinerja, dan mimpi buruk konfigurasi?

1. Pikirkan dan bangunlah keamanan sejak hari 0.
2. Gunakan kontrol versi untuk semuanya: kode sumber, dokumentasi, konfigurasi, dll.
3. Dokumentasi, dokumentasi, dokumentasi.
4. Bersihkan instalasi dan de-instalasi, menggunakan kemasan asli platform
5. Pisahkan data konfigurasi dari perpustakaan dan yang dapat dieksekusi
6. Dukungan untuk menjalankan berbagai versi secara paralel untuk pengujian dan migrasi
7. Logging yang kuat dan dapat dikonfigurasi
8. Pemantauan yang ringan, akurat, dan aman
9. Aplikasi pemeriksaan dan pencadangan
10. Bagaimana aplikasi Anda bereaksi terhadap masalah: kehabisan memori, sistem file penuh, jaringan mati, file konfigurasi hilang / rusak, waktu miring?
11. Selalu memiliki lingkungan pengembangan, pengujian, dan produksi yang terpisah. Dengan semua perangkat lunak VM gratis, tidak ada alasan!

Ingatlah bahwa aplikasi Anda mungkin memiliki lebih banyak status daripada naik atau turun. Gambarlah diagram keadaan. Sebagian besar aplikasi memiliki status seperti:

• turun
• inisialisasi
• pemulihan
• up-but-not-accept-work
• menunggu
• pos pemeriksaan
• pengolahan
• menyelesaikan
• mematikan
• turun

Pikirkan apa yang terjadi jika sistem macet selama setiap negara. Bagaimana sysadmin memonitor dan mengontrol transisi status?

Bedakan "pengguna" dari SA.

"Pengguna" perlu tahu cara menggunakan perangkat lunak Anda. Pengguna tidak peduli tentang hal-hal seperti cara menginstal perangkat lunak Anda.

SA tidak peduli bagaimana menggunakan perangkat lunak Anda, tetapi perlu mengetahui beberapa detail penting tentang cara menginstal perangkat lunak.

Tulis dokumentasi secara terpisah untuk masing-masing peran tersebut, termasuk informasi yang relevan untuk masing-masing peran tersebut.

Salah satu keinginan saya adalah penyertaan pesan yang tepat dalam pengecualian dan kode kesalahan. Ini benar-benar buram bagi seseorang yang belum mengembangkan aplikasi apa JimmyNotAtHomeException: it's late!artinya.

Namun pesan seperti Unable to find jimmy - initial manual call_mother procedureini sangat membantu.

Komunikasi, komunikasi, komunikasi. Setiap masalah antara sysadmin dan dev hampir selalu dapat dilacak kembali ke kurangnya komunikasi. Jika sebelum proyek sysadmin (atau perwakilannya) dan para dev berkumpul dan melakukan diskusi kerangka kerja yang bagus, SOOOOOOOOOO banyak masalah yang bisa dihindari. Saya tidak bisa memberi tahu Anda berapa banyak hal yang menjadi busuk karena Anda mengembangkan semua orang di satu kotak dalam pengembangan hanya untuk menontonnya terbakar dalam api karena aplikasi kemudian dipisahkan ke server aplikasi + server DB + server antarmuka, dll. Kudos untuk mengangkat topik ini.

Libatkan kami di awal proyek. Seperti nyata nyata awal, pada tahap spesifikasi fungsional.

Orang lain disebutkan harus menginstal secara manual pada setiap PC, tetapi hal yang sama berlaku untuk perubahan konfigurasi dan konfigurasi. Jika Anda memilih untuk menyimpan sesuatu seperti menghubungkan string sisi klien, dan perlu memperbaruinya secara teratur, kami mungkin ingin membunuh Anda .

Pilih teknologi yang dapat dikelola dan dikonfigurasikan dengan benar, untuk alasan yang sama. Pastikan itu terintegrasi dengan baik dengan alat manajemen pusat apa pun yang kami gunakan.

Selalu uji menggunakan penyebut umum terendah. Itu berarti sebagai non-Admin, pada OS yang paling primitif, suite aplikasi dan plaform browser yang umum digunakan. Kami tidak suka memiliki upgrade browser yang diperlukan untuk semua pengguna kami mendarat pada kami pada menit terakhir yang mungkin.

Jangan langsung menyalahkan kami ketika ada masalah. Dalam pekerjaan lama saya setiap kali aplikasi rusak, pengembang akan langsung menunjuk kami. "Anda memasang tambalan baru, Anda tidak akan memutakhirkan browser, keamanan Anda terlalu ketat" atau apa pun. Ini menghasilkan suasana yang merusak. Kami berada di sisi yang sama, sungguh, dan kami ingin bekerja sama dengan Anda untuk memperbaikinya, tetapi kami tidak bisa dalam keadaan seperti itu.

Jangan menjadi elitis.

"Jangan buang waktuku, sobat. Kamu hanya sysadmin anjing; aku menulis perangkat lunak dan kamu hanya melayaninya. Jadi diam saja dengan kekhawatiran kecilmu dan lakukan apa yang aku katakan, oke?"

Seorang pengembang benar-benar mengatakan kata-kata itu kepada saya sekali (1). Dalam email CC'd ke grup distribusi besar. Implikasinya jelas: sebagai seorang pengembang, ia adalah penguasa dan penguasa seluruh semesta perangkat lunak; dan saya hanyalah pekerja harian yang disewa untuk menangani tugas-tugas yang terlalu sepele baginya untuk menghabiskan waktu yang berharga. Tentu saja ini adalah contoh kasus yang hampir terburuk, tetapi Anda tahu, saya telah mendengar gema yang kuat dan lemah dari komentar dari sejumlah pengembang baik sebelum dan sejak (2).

Anda mungkin menghasilkan lebih banyak uang daripada saya (tetapi jangan berasumsi!). Tetapi dibutuhkan tim untuk membangun, mengoperasikan, dan memelihara sistem yang diandalkan pengguna kami. Akhirnya kita semua melayani mereka.

Saya mendapatkan bahwa pekerjaan dan keterampilan Anda berbeda dari milik saya. Saya menghargai kemampuan Anda. Saya harap Anda akan menjawab pertanyaan saya bahkan ketika mereka tampak dasar dan bodoh bagi Anda. Saya akan dengan senang hati mengembalikan kesopanan ini!

Saya tidak sedang dalam perjalanan gila, seperti yang dikatakan dan dipikirkan dan dipikirkan oleh banyak dev yang buruk (atau tidak peduli) dan diposting di berbagai forum. Tetapi kekhawatiran saya berbeda dari Anda, dan pertanyaan serta saran saya tidak melayani ego saya. Memang tugas saya adalah membuat Anda terlihat lebih baik, dengan menjaga aplikasi Anda tetap dalam kondisi prima, tersedia dan responsif terhadap semua pengguna. Untuk melakukannya, saya harus menjaga sisa jaringan dan sistem juga berjalan dalam kondisi prima.

Saya sepenuhnya sadar bahwa Anda telah mengalami admin yang bodoh, gila kekuasaan, dan / atau sekadar malas di masa lalu. Saya berusaha untuk tidak menjadi seperti itu. Jika Anda meninggalkan ruang untuk kemungkinan ini, dan mengakuinya ketika Anda melihatnya, saya cukup yakin Anda akan mendapatkan apa yang Anda butuhkan sementara orang-orang brengsek lainnya masih marah tentang betapa brengseknya sysadmin mereka.

(1) Dia juga bersikeras bahwa programnya (alat untuk menulis dan mengelola persyaratan perangkat lunak) memerlukan hak admin domain untuk menginstal dan menjalankannya. Itu adalah risiko keamanan utama .

(2) Saya juga telah bekerja dengan banyak pengembang luar biasa yang dapat mengajar saat diperlukan, dan belajar bila perlu.

Hormati bahwa sysadmin memiliki pekerjaan yang harus dilakukan, dan biarkan mereka melakukan pekerjaan mereka. Banyak perusahaan memiliki sysadmin yang tidak kompeten dan ini seringkali tidak realistis. Tetapi saya telah melihat pengembang sombong mengabaikan saran kelompok sistem bahkan setelah sysadmin telah membuktikan kompetensi mereka.

Diskusikan desain sistem baru dengan sysadmin. Seringkali ada wawasan yang berharga. Pengembang sering melihat diskusi dengan sysadmin dan memberikan persyaratan awal sebagai "optimasi prematur". Saya benar-benar melihat kepala kelompok pengembangan mengatakan bahwa itu membuang-buang waktu untuk mendiskusikan persyaratan untuk server database baru dengan sysadmin dan DBA, bahkan sampai pada tingkat yang menggambarkan apakah itu adalah beban menulis-intensif atau baca-intensif, atau berapa banyak penyimpanan yang dibutuhkan.

Diskusikan masalah kinerja dengan sysadmin. Jujur hanya sysadmin yang mampu menafsirkan metrik kinerja dengan benar pada sistem. Saya telah melihat pengembang memutuskan bahwa Linux selalu membocorkan memori karena memori bebas yang dilaporkan oleh "bebas" selalu menurun, bahkan setelah 10 kali keluaran "bebas" dijelaskan.

Jangan menarik kesimpulan tanpa mendiskusikannya dengan sysadmin. Saya telah melihat pengembang terjebak pada teori-teori seperti "database selalu diskbound" (mereka tidak tahu bahwa iostat bahkan ada), "RAID 5 lebih cepat untuk beban kerja transaksional" (berdasarkan ingatan satu sistem database yang dipindahkan dari satu platform perangkat keras ke platform yang lain - ini adalah beban kerja baca-intensif, solusi RAID5 memiliki lebih banyak dan lebih cepat drive yang tersebar di lebih banyak pengendali. Tetapi mereka lupa detail ini dan hanya ingat kesimpulannya.)

Jangan merancang solusi untuk masalah sistem tanpa mendiskusikannya dengan sysadmin. Saya bekerja di satu lingkungan patologis di mana pengembang akan merancang solusi dan datang meminta bantuan implementasi kecil. Anggota kelompok Unix selain saya, kepala kelompok Unix, dan bosnya, ingin memperlakukan pengembang sebagai "pelanggan", bukan sebagai rekan kerja yang mencoba membuat fungsi infrastruktur secara keseluruhan. Pelanggan yang selalu benar berarti tidak mempertanyakan apa yang mereka lakukan atau mengapa. Saya adalah satu-satunya yang akan bersikeras agar masalah dijelaskan sehingga solusi yang tepat dapat ditentukan. Jangan bertindak dengan cara yang menciptakan lingkungan patologis seperti ini. Itu tidak menghasilkan keuntungan bersih - sebaliknya, manajer sistem akan bertindak defensif dan semua orang akan menderita.

Anda tidak di sekolah lagi. Ini adalah sistem dunia nyata dan mereka tidak bertindak secara ideal. Misalnya, tidak semua latensi nol. Ketika sysadmin memperingatkan Anda bahwa solusi pengelompokan hanya untuk tujuan politik, dan kompleksitas sistem yang ditambahkan menurunkan keandalan keseluruhan, menganggapnya serius. Anda harus merancang mode kegagalan dunia nyata, misalnya ketika Anda kehilangan server yang Anda ajak bicara melalui TCP, koneksi mungkin tidak akan diatur ulang untuk Anda. Sysadmin memahami mode kegagalan dunia nyata.

Baik dengarkan apa yang dikatakan sysadmin Anda, atau mengeluh kepada manajemen bahwa sysadmin Anda tidak kompeten dan perlu dipecat. Mengabaikan sysadmin Anda tidak masuk akal.

Pertimbangkan bagaimana Anda akan menggunakan aplikasi Anda. Sadarilah bahwa mendiskusikan ini dengan sysadmin Anda masuk akal. Jika Anda memiliki 100 server yang identik, hanya berbeda berdasarkan satu file konfigurasi, Anda mungkin ingin mempertimbangkan untuk menyimpan salinan master dari file konfigurasi ini di lokasi pusat. Sadarilah betapa jauh lebih baik semua orang jika aplikasi Anda mudah digunakan kembali. Jika ada masalah dengan suatu sistem, apakah Anda lebih suka menggunakan kembali di bawah satu menit untuk cadangan, atau menunggu lama sementara yang rusak diperbaiki? Jika Anda dapat menggunakan kembali aplikasi Anda, OS dapat ditingkatkan dengan lebih mudah dan aman. Anda mungkin peduli tentang ini di masa depan.

Jika Anda memiliki masalah yang Anda pikir disebabkan oleh OS, masuk akal untuk segera menghubungi sysadmin untuk memeriksanya. Tetapi setelah penyelidikan sepintas tidak mengungkapkan apa-apa, Anda memiliki kewajiban untuk menjelaskan masalahnya.

Pahami bahwa ada perbedaan antara "merespons dengan lambat" dan "tidak merespons sama sekali".

Konfigurasikan dan tata letak hal-hal dengan cara yang dapat diprediksi dengan cara yang dapat diprediksi untuk mengubahnya untuk OS (id) yang Anda kembangkan. Ini berarti segalanya. Sebagai contoh: OpenLDAP memiliki cara aneh melakukan loglevels; server IMAP tertentu bahkan tidak memiliki file konfigurasi tetapi harus memiliki opsi yang dikompilasi; beberapa paket ingin barang-barang mereka berada di satu jalur direktori tertentu, yang mau tidak mau akan melanggar konvensi sistem operasi tertentu. Semua ini menonjol sebagai kutil pada konfigurasi saya yang biasa.

Ini adalah aturan umum, tetapi jangan menganggap Anda istimewa, dan karena itu diberkati untuk melanggar konvensi umum tentang bagaimana paket perangkat lunak umumnya bekerja pada platform Anda, kecuali ada alasan kuat yang melekat pada perangkat lunak Anda yang membutuhkannya. "Saya sangat merasa ini seharusnya begitu" tidak cukup baik untuk merusak pengaturan semua orang yang biasa; itu harus menjadi alasan yang terhubung ke fungsi yang coba dilakukan oleh perangkat lunak Anda.

Ketika ada komunikasi antar-server yang terlibat dengan aplikasi, harap sertakan setidaknya satu sysadmin dalam fase desain. Juga, jelaskan dokumentasi ketergantungan pada layanan lain: SQL, SMTP, HTTP, dll ... Jangan membuat kami menebak apa yang Anda lakukan atau kami tidak dapat membantu Anda ketika ada sesuatu yang tidak berfungsi seperti yang Anda harapkan.

Harap memungkinkan untuk menyebarkan perangkat lunak Anda pada lusinan atau ratusan sistem secara otomatis. Jika suatu organisasi membutuhkan paket perangkat lunak, sysadmin hampir pasti tidak punya waktu untuk menginstalnya secara manual di setiap kotak. Jika sebuah file perlu memiliki informasi lisensi, mendokumentasikan cara menyediakannya akan sangat bermanfaat.

Adobe secara historis memiliki beberapa installer yang sangat menyulitkan untuk dikerjakan ; tolong bidik lebih tinggi dari itu!

Pikirkan tentang penskalaan sejak hari pertama. Sysadmin dapat melakukan keajaiban dengan melemparkan uang / perangkat keras pada masalah kinerja tetapi kadang-kadang tidak ada jumlah ini akan membantu - khususnya berpikir tentang penguncian - kadang-kadang Anda tidak dapat membeli diri sendiri dari masalah penguncian. Terima kasih sudah bertanya :)

Oh dan cobalah untuk menjadi 64-bit jika memungkinkan, dan multi-threaded juga :)

Desain untuk operasi.

Melampaui segala sesuatu yang lain di sini ...

• Mintalah lingkungan produksi yang disimulasikan (server pengembangan atau VM dengan konfigurasi yang sama dengan server langsung) dan kemudian gunakan untuk menguji proses rilis. Kemudian berikan kami proses rilis ini, termasuk daftar perubahan dan urutan penerapannya (yaitu 1. Masuk ke mode pemeliharaan, 2. terapkan pembaruan SQL, 3. perbarui sumber ke versi X, 4. tinggalkan mode pemeliharaan, 5. berdoa)
• Pastikan Anda memiliki mode pemeliharaan yang dapat mengeluarkan pengguna untuk mempertahankan integritas data. Anda tidak ingin kami menjalankan pembaruan sistem besar di beberapa server dengan pengguna yang masuk dan melakukan transaksi ... itu adalah resep untuk kegagalan dalam kebanyakan kasus.
• Gunakan model pengembangan yang agak terstandarisasi. Misalnya, semua aplikasi baru kami di tempat kerja (grup web) menggunakan Zend Framework.
• Berikan kami changelog yang dapat kami baca, termasuk daftar bug yang diperbaiki yang dapat kami cari untuk mendapatkan gambaran tentang ruang lingkup perubahan. Terkadang kita dapat mengidentifikasi masalah potensial hanya karena kita memiliki sudut pandang yang berbeda.

Meskipun tidak realistis, akan sangat membantu jika pengembang dipaksa untuk bekerja dalam peran sysadmin atau dba sebelum dilepas ke dunia.

Begitu banyak aplikasi khusus yang saya tangani tidak memiliki petunjuk tentang instalasi di lingkungan yang dikelola, atau melakukan kekejaman desain database.

1) File log yang mencatat kesalahan secara detail. atau sistem pelacakan kesalahan yang baik seperti ELMAH.

2) Dokumentasi terperinci untuk instalasi, implementasi, dan panduan SA.

3) Ditambah barang-barang yang disebutkan di atas dari SA menakjubkan lainnya. :)

Hanya itu yang bisa saya pikirkan saat ini.

Buku ini Rilis! memiliki pilihan cerita-cerita horor yang bagus tentang apa yang bisa salah dalam produksi. Membaca itu dapat memberikan inspirasi / ide untuk merancang dengan operasi dalam pikiran. (Ini ditulis oleh Michael Nygard, yang telah bekerja di kedua sisi pengembangan dan operasi.)

• Jangan berkembang tanpa spesifikasi
• Dokumentasikan (atau pastikan bahwa mereka yang mendokumentasikan melakukannya dengan akurat)
• Jangan takut untuk mendukung pelanggan (sebagai tingkat dukungan yang lebih tinggi)

Dalam pengalaman saya, hal yang akan membuat perbedaan paling besar adalah jika pengembang akan memikirkan penyebaran dari hari pertama. Begitu Anda mulai memahami fitur baru di lingkungan produksi / pelanggan, mulailah berpikir tentang bagaimana ia akan digunakan untuk itu. lingkungan, dan cara kerjanya.

Begitu mereka masuk ke proses pengembangan, ini belum terlambat, tetapi perlu beberapa saat sebelum mereka dapat mengubah perspektif mereka sejauh itu; mereka tidak menyadari betapa abstraknya mereka melihat basis kode sampai dipaksa untuk menghadapinya. Dalam pikiran mereka, itu hanya "komponen". Yang menarik adalah bagaimana itu akan digunakan ke lingkungan yang sudah ada sebelumnya , menjalankan versi perangkat lunak sebelumnya (atau yang lebih tua!). Diskusi penyebaran dapat memiliki dampak signifikan pada bagaimana arsitektur disesuaikan untuk mengakomodasi fitur baru.

Sesuatu yang saya sukai yang belum saya lihat adalah Configurable. Jika Anda memiliki aplikasi yang menggunakan segala jenis file konfigurasi, buat semuanya dapat dikonfigurasi.
Di perusahaan saya, saya menulis aplikasi sederhana yang akan mengekspor sepotong database. Minggu berikutnya saya menulis ulang untuk membiarkan sebagian kecil dimatikan. Setiap minggu sejak itu saya harus menulis ulang bagian dan membangunnya kembali hanya untuk mengubah fitur kecil. Saya baru saja menambahkan file konfigurasi xml, dan sekarang cara ini lebih mudah untuk digunakan kembali.
Saya suka file konfigurasi.

Saya berharap bahwa pengembang akan memiliki pemisahan yang lebih baik dari tugas-tugas QA. Saya pikir itu bagus ketika pengembang dapat membuat beberapa unit test case untuk proyek yang sedang dikerjakannya tetapi akan lebih baik jika tes tersebut diteruskan ke QA. Bahkan, itu bagus ketika pengembang memberikan sedikit bantuan kepada insinyur QA karena pada akhirnya menguntungkan DEV.

Pastikan itu dapat didukung: selain semua hal lain yang disebutkan di sini, lihat posting ini di SO - https://stackoverflow.com/questions/205374/what-are-the-core-elements-to-include-in-support- dokumentasi/