Penulis materi, terjemahan yang kami terbitkan hari ini, mengatakan bahwa sebagian besar programmer bekerja dalam tim. Namun, pada titik tertentu dalam karier, pengembang mungkin perlu bekerja sendiri. Ruang lingkup utama pendekatan untuk organisasi yang bekerja pada produk perangkat lunak dirancang khusus untuk digunakan dalam tim. Pendekatan ini diekspresikan dalam aturan yang diadopsi oleh organisasi. Aturan seperti itu memudahkan pekerjaan, membantu programmer untuk melakukan pekerjaan mereka dengan cepat dan efisien. Hal serupa akan sangat berguna bagi para programmer yang bekerja sendiri.
Bagaimana dengan orang yang bekerja sendiri? Apa yang menjadi fokus, berusaha untuk membangun alur kerja yang jelas dan efisien? Prinsip dan aturan apa yang harus diikuti? Kami menyarankan untuk mencari jawaban atas pertanyaan-pertanyaan ini bersama-sama.
Tentang satu-satunya programmer
Di sini, berbicara tentang "programer tunggal," maksud saya semua yang bekerja di lingkungan tidak resmi dan tidak terstruktur. Ini bisa berupa programmer tunggal atau sekelompok kecil orang yang terlibat, katakanlah, di waktu luang mereka, dengan beberapa jenis proyek. Berikut ini beberapa contohnya:
- Pengembangan proyek open source, seperti paket atau semacam perpustakaan.
- Proyek pribadi seseorang, yang dapat berupa komersial atau gratis.
- Lepas.
Semua contoh ini disatukan oleh fakta bahwa pekerjaan programmer yang terlibat dalam sesuatu yang serupa biasanya tidak diatur oleh seperangkat aturan tertentu, seperti yang biasanya ada di perusahaan.
Mengapa seorang programmer harus peduli dengan aturan?
Aturan, dalam menerapkannya pada pekerjaan pemrogram independen pada proyek tertentu, penting karena beberapa alasan. Pertimbangkan mereka.
▍ Aturan pribadi dan kemungkinan kerja tim
Seorang programmer yang pekerjaan independennya terorganisasi dengan baik dapat bergabung dengan tim tertentu. Dalam hal ini, kemungkinannya bagus bahwa ia akan menjadi anggota yang berharga dari tim semacam itu. Yaitu, kita berbicara tentang hal berikut:
- Jika dia bergabung dengan tim yang mengikuti aturan yang sama dengannya, maka dia tidak perlu membuang waktu untuk mencoba mempelajari masalah organisasi. Dia, secara harfiah sejak hari pertama, akan siap untuk pekerjaan produktif.
- Jika ia menjadi bagian dari sebuah tim, aturan yang diadopsi berbeda dari apa yang biasa ia gunakan, tidak akan butuh banyak waktu baginya untuk mempelajari aturan baru ini. Bagaimanapun, ia, yang terbiasa mengatur pekerjaannya secara rasional, dibimbing oleh ide-ide umum tertentu, yang, tentu saja, mirip dengan yang mendasari aturan tim. Akibatnya, ia dapat dengan cepat mencapai tingkat produktivitas kerja yang tinggi.
- Jika dia masuk ke tim di mana tidak ada aturan sama sekali, maka, tergantung, tentu saja, pada tim, dia dapat menawarkan visinya tentang pengorganisasian pekerjaan para programmer, yang mungkin dapat meningkatkan kerja tim seperti itu. Jika anggota tim yang kurang terorganisir menolak untuk mengubah sesuatu, maka ini adalah kesempatan untuk berpikir untuk meninggalkan tim semacam itu.
Akibatnya, seorang programmer mandiri yang secara rasional mengatur pekerjaannya, bagaimanapun, adalah pemenangnya.
▍ Aturan dan tingkat profesional seorang programmer
Pengembangan perangkat lunak bukan hanya proses penulisan kode. Ada banyak detail yang bertanggung jawab untuk mengubah ide menjadi proyek jadi, dan kemudian mempertahankannya dalam kondisi kerja. Pengenalan teknik pengembangan perangkat lunak yang canggih ke dalam alur kerja pribadi akan membantu seorang programmer tunggal dengan percaya diri mengikuti tujuan proyek yang sedang dibuat dan untuk menghindari situasi di mana segala sesuatu tampak sangat membingungkan sehingga tidak jelas ke mana harus pindah.
Jika Anda, seperti saya, suka memprogram, Anda akan selalu tergoda untuk memulai proyek baru dan segera, tanpa melihat ke belakang, bergegas ke jurang penulisan kode. Tetapi pengalaman mengatakan kepada saya bahwa, jika saya memiliki rencana kerja tingkat tinggi tertentu, ini, tanpa merusak fleksibilitas yang berbeda dalam pengembangan individu, membantu menghindari banyak masalah dari skala yang berbeda.
Bicara tentang praktik terbaik untuk pengembangan perangkat lunak.
Ikuti aturan yang menjelaskan alur kerja Anda.
"Alur Kerja" adalah urutan langkah yang harus Anda lalui dalam proses mengubah ide menjadi produk jadi. Berikut adalah beberapa pertanyaan yang harus dijawab oleh aturan yang mengatur proses bekerja pada produk perangkat lunak:
- Ketika diputuskan untuk melakukan perubahan pada produk - bagaimana urutan implementasinya?
- Bagaimana transfer versi baru produk ke pengguna?
- Bagaimana perubahan produk dilacak?
- Bagaimana pemantauan pesan kesalahan dan masalah yang dihadapi oleh pengguna diatur?
- Bagaimana proses perencanaan fitur produk baru?
Mengapa mengatur semua ini, mengendarainya ke dalam semacam kerangka kerja, jika tampaknya pekerjaan pada proyek akan berjalan lebih cepat tanpa alur kerja tertentu? Bukankah lebih mudah untuk membayangkan seluruh "alur kerja" dalam formulir ini: "cukup tulis kode dan kirimkan ke cabang utama"? Faktanya, seiring dengan meningkatnya kompleksitas proyek, ternyata keberadaan aturan yang jelas menyederhanakan definisi tentang apa yang perlu dilakukan dalam pekerjaan pada proyek ini, dan, karenanya, tanpa pemikiran lebih lanjut, memungkinkan Anda untuk fokus pada hal-hal ini. Saat bekerja dalam tim, alur kerja berubah menjadi sesuatu seperti sabuk konveyor yang meningkatkan efisiensi setiap anggota tim.
Sekarang mari kita bicara tentang bagaimana mengatur proses bekerja pada produk perangkat lunak.
▍Gunakan pelacak tugas
Di sini Anda akan menemukan mekanisme platform tempat Anda menempatkan kode yang berguna - GitHub, Gitlab, BitBucket dan lainnya. Tugas membantu melacak pesan kesalahan, permintaan untuk menambahkan fungsionalitas baru ke produk, dan mengatur informasi tentang perubahan proyek penting. Perlu dicatat bahwa ketika Anda memasukkan judul dan deskripsi tugas, itu memaksa Anda untuk merumuskan pikiran dengan jelas dan dengan jelas menggambarkan masalah dan cara-cara yang mungkin untuk menyelesaikannya. Gagasan menggunakan tugas dapat dikembangkan dengan memperkenalkan alat manajemen tugas seperti Trello atau GitHub Projects ke dalam alur kerja Anda.
Tantangan▍Gunakan permintaan tarik
Banyak pengembang lebih suka mengirim perubahan, menggunakan permintaan push, langsung ke cabang utama dari proyek mereka, yang disebut master. Namun, pendekatan untuk membuat perubahan pada kode proyek menggunakan permintaan tarik memiliki beberapa keuntungan penting. Pertama, permintaan tersebut memfasilitasi analisis perubahan terkait pengenalan fitur baru atau perbaikan bug ke dalam proyek, dan bagaimana mereka, setelah bergabung dengan basis kode utama, akan memengaruhinya. Selain itu, jika permintaan tarik dikaitkan dengan tugas-tugas dari pelacak tugas, penggunaannya memudahkan untuk memahami bagaimana proyek berkembang, menghilangkan kebutuhan untuk mencari tahu saat membaca kode.
Tarik detail permintaan▍ Lakukan tinjauan kode khusus
Rekomendasi untuk meninjau kode asli mungkin terdengar aneh, tetapi meskipun demikian, pengembang harus menganalisis kode mereka sendiri seolah-olah orang lain yang menulisnya. Beberapa programmer menyarankan untuk membuat permintaan tarik, mengganggu untuk sementara waktu, dan kemudian memeriksanya sebelum memasukkannya ke dalam kode. Melakukan pemeriksaan kode yang dilakukan di luar lingkungan yang biasa bagi programmer dalam bentuk IDE-nya memungkinkan Anda untuk melihat kode dengan lebih segar. Ini membantu menemukan kesalahan dan mendeteksi sesuatu yang dalam kondisi normal dapat diabaikan dalam kode. Ulasan Kode, di samping itu, memaksa pengembang untuk bertanya pada dirinya sendiri berbagai pertanyaan: "Mengapa peluang ini diterapkan dengan cara ini? Apa yang bisa dilakukan salah di sini? Apakah ada cara yang lebih efisien untuk menyelesaikan masalah ini? "
▍ Simpan riwayat yang berarti dari proyek di repositori
Cobalah membuat komitmen seolah-olah Anda bekerja dalam tim. Yaitu - hindari komit yang terlalu besar, cobalah untuk memastikan bahwa pesan komit menggambarkan dengan jelas dan jelas artinya. Sama seperti dalam kasus review kode, menulis pesan komit berkualitas tinggi memaksa pengembang untuk berpikir hati-hati tentang tindakan mereka, bertanya pada diri sendiri pertanyaan-pertanyaan seperti berikut: “Apa yang saya coba capai dengan komit ini? Bagaimana saya mencoba mencapai ini? "
Mungkin ada situasi di mana Anda dapat membiarkan diri menyimpang dari aturan. Misalnya, Anda dapat memutuskan bahwa, agar tidak memperlambat pekerjaan karena hal-hal sepele, Anda, ketika melakukan perubahan kecil pada kode (seperti memperbaiki kesalahan ketik), Anda dapat, tanpa gerakan yang tidak perlu, mengirim permintaan push langsung ke cabang master.
Terlepas dari aturan yang mendasari alur kerja Anda, yang paling penting adalah bahwa semua yang Anda lakukan dilakukan dengan sengaja, dan bukan karena kebetulan. Proyek yang sukses tidak muncul dengan sendirinya: mereka diciptakan dengan cinta dan perhatian. Tindakan yang dilakukan dengan sengaja melibatkan periode analisis situasi tertentu, analisis kasus yang rumit dan refleksi tentang bagaimana, misalnya, dengan bantuan alat mana yang dapat Anda tangani.
Membangun Komponen dan Modul yang Dapat Digunakan Kembali
Menerapkan prinsip
KERING ,
PADAT dan
PERTAMA . Bangun program dari komponen atom yang kecil, terbungkus, dan cocok untuk digunakan kembali. Tetap perbarui komponen-komponen ini, rakit menjadi koleksi menggunakan platform yang sesuai seperti
Bit . Semua ini akan membantu Anda meningkatkan kecepatan dan kualitas pekerjaan.
Tulis dokumentasi
Dokumentasi ... Bagi banyak orang, ini adalah titik yang menyakitkan. Banyak orang tahu bahwa proyek perangkat lunak memerlukan dokumentasi. Mereka yang menulis dokumentasi yang baik sudah jauh lebih sedikit, dan bahkan lebih sedikit yang suka melakukan ini. Setelah tahap penulisan kode menarik berikutnya selesai, kebutuhan untuk mendokumentasikannya seringkali menjadi tugas yang hanya ingin Anda lupakan. Bagaimana, dalam bentuk teks biasa, untuk mengekspresikan semua seluk-beluk kode program?
Dan, omong-omong, pantas untuk mengajukan pertanyaan tentang mengapa semua ini diperlukan. Faktanya adalah orang cenderung membuat kesalahan. Kita bisa melupakan sesuatu. Kami mengalami hari-hari yang buruk. Atau, mengerjakan proyek tertentu, kita bisa melanjutkan mengerjakan sesuatu yang lain. Dokumentasi memungkinkan Anda untuk menangkap pengetahuan tentang kode, yang, jika tidak, akan diikat ke orang tertentu. Mendokumentasikan kode juga membantu pengembang melihat kode dalam istilah yang lebih umum daripada yang tersedia saat menulisnya, dan lebih memahami tujuan proyek.
Gagasan berikut akan membantu Anda menulis dokumentasi yang baik.
- Pahami bahwa dokumentasi Anda bukan sesuatu seperti buku. Dokumentasi tidak boleh merupakan contoh seni sastra tinggi. Tidak ada yang akan mengevaluasi dia dalam hal kemampuan artistiknya. Jangan mencoba menjelaskan semuanya di dalamnya. Berusaha keras untuk menjadi jelas dan mudah dimengerti. Terkadang hanya beberapa kalimat yang cukup untuk menggambarkan sesuatu.
- Menulis dokumentasi sebelum menulis kode. Dokumentasikan antarmuka modul Anda, jelaskan urutan pekerjaan mereka dari sudut pandang pengamat eksternal. Dokumentasi semacam itu akan memainkan peran spesifikasi produk dan akan membantu Anda dalam proses pengembangan.
- Menulis dokumentasi setelah menulis kode. Di sini, sekali lagi, perlu mematuhi posisi "pengamat luar". Apa yang penting dalam fragmen kode yang dijelaskan? Apa yang perlu Anda ketahui tentang menggunakannya (atau berkontribusi pada pengembangannya?). Spesifikasi yang ditentukan oleh dokumentasi yang dibuat sebelum menulis kode selama pengembangan dapat berubah. Oleh karena itu, penting untuk memeriksa dokumentasi tersebut untuk kepatuhan dengan keadaan sebenarnya setelah pekerjaan selesai.
- Dokumentasi penulisan dalam proses penulisan kode. Pendekatan dokumentasi ini terutama berlaku untuk sesuatu seperti komentar yang ditambahkan ke kode selama pengembangan. Ada banyak materi tentang topik ini, jadi saya tidak akan membahas detailnya di sini.
- Dokumentasi dan "modul". Semua prinsip di atas berlaku untuk modul. Di sini konsep "modul" digunakan dalam arti yang cukup luas. Ini bisa berupa fungsi, kelas, peluang baru, perubahan perilaku program, pada kenyataannya, modul program tertentu, atau seluruh proyek. Jika mendokumentasikan "modul" seperti itu sepertinya terlalu banyak tantangan, cobalah memecahnya menjadi bagian-bagian yang lebih kecil. Atau, jika Anda lebih mudah berpikir dalam kategori yang lebih umum, pertimbangkan untuk menulis dokumentasi untuk blok proyek yang lebih besar.
Berkomunikasi dengan pelanggan dan mereka yang terlibat dalam pengembangan produk bersama Anda
Di sini, apa yang kita sebut "komunikasi" berlaku terutama untuk situasi ketika sebuah proyek dikembangkan oleh tim kecil atau dibuat sesuai pesanan.
Mengapa ini dibutuhkan? Faktanya adalah bahwa transparansi pekerjaan mengarah pada peningkatan tanggung jawab para pemainnya. Ketika Anda tahu bahwa Anda harus memberi tahu seseorang (anggota tim atau perwakilan pelanggan) sesuatu, ada baiknya Anda lebih berhati-hati dengan apa yang Anda lakukan. Itulah sebabnya banyak perusahaan berlatih mengadakan pertemuan singkat di mana karyawan melaporkan pekerjaan mereka.
Selain itu, sering anggota tim dihadapkan dengan masalah yang sulit baginya, yang dapat dengan mudah diselesaikan hanya dengan mendiskusikannya dengan klien atau dengan anggota tim lainnya. Saya sudah kehilangan hitungan, mengingat kasus-kasus ketika saya benar-benar menjatuhkan tangan, mencoba memahami mengapa apa yang saya tulis tidak berhasil. Dan alasannya adalah anggota tim yang lain membuat perubahan pada proyek yang mengganggu kode saya. Untuk memahami ini, cukup membawa masalahnya ke diskusi publik.
Berikut adalah beberapa pedoman untuk berkomunikasi dengan klien dan dengan anggota tim programmer.
- Jika Anda menemukan masalah yang tidak terduga - beri tahu anggota tim atau perwakilan klien tentang hal itu.
- Beri tahu klien secara teratur tentang kemajuan proyek. Pada saat yang sama, cobalah agar informasi ini tidak hanya terkait dengan masalah teknis.
- Beri tahu tim perubahan rencana.
- Cobalah untuk mengatur lingkungan komunikasi yang nyaman, yang, misalnya, memungkinkan setiap anggota tim untuk dengan cepat mengetahui apa yang sedang dilakukan orang lain. Anda dapat melakukan ini dengan menggunakan berbagai alat, katakanlah - itu bisa berupa WhatsApp, email, Slack, atau apa pun yang sesuai dengan situasi Anda.
Secara umum, dapat dicatat bahwa Anda harus mencoba memastikan bahwa interaksi antara semua pihak yang berkepentingan diatur dengan mudah dan sederhana, sehingga, dengan kata lain, "putaran umpan balik" bekerja tanpa penundaan. Ini membantu mengatur lingkungan kerja yang sehat dan produktif.
Atur sistem pemantauan
Pemantauan di bidang pengembangan perangkat lunak adalah masalah yang sangat penting. Komputer rentan terhadap gangguan. Selama penyebaran proyek, kesalahan terjadi. Kelalaian pengembang mengarah pada fakta bahwa program yang tampaknya telah melewati semua kemungkinan pemeriksaan dan berhasil dioperasikan, terkecuali. Itu sebabnya pengembang perlu menjaga sistem pemantauan program. Ini akan memfasilitasi penyelesaian masalah yang mungkin timbul pada berbagai tahap siklus hidup produk. Data pemantauan program adalah salah satu bagian dari "umpan balik" yang disebutkan di atas. Pemantauan memberi programmer koneksi dengan kenyataan, dengan lingkungan di mana programnya bekerja.
Berikut adalah beberapa saran untuk memantau perilaku program:
- Simpan log dan hasil analisis kode otomatis. Jangan ragu menggunakan console.log () di mana Anda membutuhkannya. Lebih baik menyimpan terlalu banyak informasi daripada terlalu sedikit. Namun, cobalah untuk menemukan "jalan tengah" sehingga log dari program Anda tidak berisi rincian yang tidak perlu tentang pekerjaan mereka. Ini akan membuatnya lebih mudah untuk menemukan informasi penting dalam log.
- Cari tahu ke mana log aplikasi Anda pergi, dan konfigurasikan mekanisme yang membuatnya nyaman untuk bekerja dengannya. Peran "mekanisme" yang disebutkan di atas bisa apa saja - mulai dari masuk ke server menggunakan SSH dan melihat peristiwa terbaru yang dicatat dalam log, hingga sesuatu seperti menggunakan tumpukan ELK. Yang paling penting adalah mengetahui di mana log aplikasi dihasilkan oleh console.log () atau cara lain.
- Jangan abaikan pengecualian. , , , , «» , «» catch, . . , - API , ( — ), 404. , , . , , , , . , API .
- . , , , . , , . , . , .
. console.log(), . , Sentry, Bugsnag Elastic APM. — , , .
, ,
, , .
, « », , , . , . - , , - , . , , , , , , .
, , , . , , , , , . , , , ( A/B- ). «» — , , .
. , . — , « — — ».
. , , . , UTC-. , .
, UTC. , , , 5:30 pm, 5:30 pm UTC. , . , . ? , . .
, , , — , . , , , . «5 » «2 ». , , , .
. , . , , , , , . , , .
Ringkasan
, , — , . ( ), , , . , , ( , ), , . , , . , , , , .
Pembaca yang budiman! , «-»?
