Semua yang lama suatu hari menjadi baru kembali. Ada saatnya ketika bahkan programmer berpengalaman menginjak menyapu yang sama. Tidak mungkin untuk membuat daftar semua "aturan tidak tertulis" dari disiplin apa pun, sebagian karena banyak dari mereka bahkan bukan aturan . Ini sering merupakan cara untuk mengulangi kebenaran yang abstrak dan abadi.

Marie Kondo membuat karier dengan menerapkan prinsip universal efisiensi, kebersihan, dan keindahan pada tugas rumah tangga untuk mengurus rumah tangga. Ternyata banyak orang hanya membutuhkan penerjemah antara kebijaksanaan abadi dan kehidupan sehari-hari mereka untuk benar-benar “memahami” makna dari apa yang terjadi di sekitar (lihat juga “Zen dan seni perawatan sepeda motor” ). Kami sangat berharap bahwa Anda menikmati upaya kami untuk melakukan hal yang sama untuk pemrograman.

1. Tidak ada Deposit Jumat

Bahkan jika Anda memiliki sistem penyebaran yang berkelanjutan. Jumat adalah hari yang paling tidak tepat untuk memulai master, karena alasan yang jelas: hanya ada setengah hari tersisa untuk memperbaiki kemungkinan tiang tembok. Biasanya, setelah pembaruan, lonjakan tiket dukungan teknis diamati, terutama setelah rilis fungsi baru dan, mau tidak mau, kesalahan baru. Orang-orang pada hari Jumat mengantuk, kurang perhatian, cenderung menunda semuanya sampai nanti ... Anda tahu bagaimana itu terjadi.

Tidak ada yang kebal dari pasukan dunia lain yang selalu memilih hari Jumat untuk bug! Karena itu, perhatikan praktik terbaik, dan jika Anda tidak yakin, perhatikan pemimpin industri. Misalnya, Apple seharusnya membuat rilis pada hari Selasa , menyisakan cukup waktu di kedua sisi peristiwa kritis seperti Penyebaran: Senin untuk menguji dan menangkap bug terbaru, dan dari Rabu hingga Jumat untuk membuat perubahan mendesak. Dan dengan pendapatan Apple, Anda menyadari bahwa model penyebaran mereka dicuci dengan darah dan keringat.

2. Backup reguler

Sulit untuk melebih-lebihkan pentingnya cadangan reguler. Seluruh industri kami dibangun di atas sistem cadangan progresif abstrak. Tentu saja saya berbicara tentang Git, tetapi itu tidak cukup. Basis data Anda, kunci kriptografis, file konfigurasi, gambar VM, gambar / video ... bahkan paket yang diimpor harus disimpan dengan aman di tempat mereka akan selalu tersedia jika terjadi keadaan darurat. Jika Anda tidak memiliki sistem otomatis, maka biarkan setidaknya beberapa karyawan secara teratur mengarsipkan folder kerja dan menyalinnya ke drive eksternal. Ya, hanya pasangan - redundansi tidak berlebihan.

Mungkin Anda tidak akan pernah membutuhkan 9 dari 10 cadangan. Tetapi suatu hari, seperti saya hari ini, Anda akan ingin kembali ke masa lalu dan mencari tahu kapan kita membuat kesalahan yang tidak mencolok tetapi benar-benar mematikan ini yang belum pernah disadari siapa pun?! Maka Anda akan senang bahwa Anda meluangkan waktu untuk membuat cadangan. Atau, Anda tahu, ketika seorang karyawan baru secara tidak sengaja menghapus 100.000 baris kode. Itu terjadi. Kami tidak menyimpan dendam terhadap orang lain, tetapi belajar dari kesalahan. Buat cadangan, meskipun sulit!

3. Dapatkan spesifikasi lengkap sebelum memulai pengembangan

Saya sering menderita sindrom "mulai terlalu dini". Lebih dari sekali saya harus menulis ulang fragmen kode yang besar, karena saya tidak mengajukan cukup pertanyaan pada pertemuan pertama dengan pelanggan, di mana ia menguraikan kontur tugas. Otak kita sangat kecil, dan itu membenci keakuratan, terutama ketika keakuratannya kompleks dan mahal (baca: perlu bagi klien). Dia menemukan kesamaan di mana dia bahkan tidak dekat. Ini terutama benar dalam desain program - dalam aplikasi yang cukup kompleks, sepuluh tombol serupa melakukan selusin tugas yang sama sekali berbeda. Sebelum Anda mulai coding, Anda harus menangkap seluk-beluk ini jika Anda ingin mendapatkan yang terbaik dari waktu dan waktu klien Anda. Jangan seperti aku atau otakku. Gambar semuanya di atas kertas, pastikan semuanya jelas, dan jika perlu, Anda dapat menggambar ulang sistem dari awal (dengan mempertimbangkan waktu persiapan yang cukup - kita semua manusia).

Tidak seorang pun akan mencapai kesempurnaan dalam proses ini. Saya masih terlalu mengandalkan dugaan. Tetapi sejak saya menyadari masalahnya, asumsi yang tidak berdasar menjadi kurang. Itu harus dianggap seperti komputer: tegas dan tanpa berpikir dalam logikanya. Dalam konsep desain sistem, pelajari situasi perbatasan, jadilah "penguji tester" - dan Anda mungkin akan menemukan desain yang segera menghilangkan seluruh kelas kesalahan yang diizinkan dalam desain yang kurang bijaksana.

4. Jika Anda melihat omong kosong yang tidak penting, katakan demikian

Cobalah untuk menghentikan atau mencegah diskusi yang tidak produktif sebelum mereka lepas kendali. Waktu kantor kita hampir sama berharganya dengan 3-8 jam yang kita habiskan tanpa sadar setiap malam - yaitu, ini sangat penting! Dari sudut pandang bisnis, semakin banyak orang di sana, semakin efektif pertemuan itu, karena upah per jam dikalikan oleh 20-500 pengembang dalam satu ruang / ruang konferensi / dll. Ini adalah uang gila, terutama di California yang cerah dengan gajinya. Waktu adalah uang! Dan kami sedang mengerjakan uang ini dengan menciptakan trik intelektual di sekitar monster dengan tentakel yang tersembunyi di balik setiap basis kode dan hanya menunggu untuk menghancurkan harapan yang tidak bersalah dengan bug dan crash yang kejam.

Tetapi kita tidak selalu berkeliaran melalui katakomb kode yang terlupakan dengan obor yang bergetar dan dahi yang berkeringat. Terkadang kita duduk di pertemuan atau mendiskusikan sesuatu yang tegang di luar pertemuan formal. Slack terkenal dengan peningkatan kohesi tim, tetapi berapa biayanya (selain biaya bulanan)? Dalam pengalaman saya, Slack secara dramatis meningkatkan "waktu yang tidak berarti" dari otak Anda - waktu yang dibutuhkan untuk menyaring aliran peringatan suara (sering tidak pantas) yang konstan ketika Anda mencoba melakukan apa yang perusahaan bayar untuk Anda; yaitu, mengembangkan dan memperbaiki kode yang berguna. Dan orang dengan mudah jatuh ke dalam perselisihan yang tidak perlu.

Tidak apa-apa untuk meminta untuk mengakhiri diskusi jika terlalu banyak waktu. Saat ini, anak-anak suka mengatakan bahwa "yang nyata melihat masa kini": orang yang benar-benar melakukan pekerjaan nyata, membantu pelanggan, pengguna, dan dunia - mereka akan berterima kasih karena meminta Anda untuk mengakhiri diskusi tentang apakah kulkas baru harus berwarna hitam atau berlapis krom. "Ya, kamu melempar koin, apa bedanya ... kita punya masalah yang lebih serius." Dan banyak dari orang-orang yang memperhatikan Anda akan berasal dari kepemimpinan.

Terima kasih telah bergabung dengan saya dalam perjalanan ini. Semoga Anda melihat kebijaksanaan yang sama dengan mereka yang pertama kali menulis kiat ini di hadapan kami. Dan tolong, jika dalam pengalaman Anda, Anda telah mempelajari beberapa aturan tak terucapkan lainnya, tulislah dan beri tahu kami!