Ini adalah kumpulan klinis yang sinis dari apa yang saya pelajari selama 30 tahun dalam pengembangan perangkat lunak. Saya ulangi, beberapa hal sangat sinis, dan sisanya adalah hasil pengamatan panjang di berbagai tempat kerja.
Pengembangan perangkat lunak
Spesifikasi pertama, lalu kode
Jika Anda tidak tahu persis apa yang Anda coba selesaikan, maka Anda tidak tahu kode apa yang harus ditulis.
Pertama, jelaskan bagaimana aplikasi Anda bekerja sebelum Anda memulai pemrograman.
"Tanpa persyaratan atau proyek, pemrograman adalah seni menambahkan bug ke file teks kosong." - Louis SraigleyKadang-kadang bahkan "presentasi singkat" sudah cukup - tidak lebih dari dua paragraf yang menggambarkan apa yang aplikasi Anda lakukan.
Ada saat-saat ketika, karena langkah-langkah tidak tertulis, saya menghabiskan lebih banyak waktu melihat kode dan bertanya-tanya apa yang harus dilakukan selanjutnya. Ini pertanda baik bahwa ini saatnya untuk berhenti dan mendiskusikan situasi dengan rekan kerja. Atau mungkin memikirkan kembali keputusan itu.
Jelaskan langkah-langkahnya sebagai komentar
Jika Anda tidak tahu bagaimana memulainya, jelaskan aliran data tingkat atas di aplikasi Anda, cukup dalam bahasa ibu Anda. Dan kemudian mengisi kode kosong di antara komentar.
Atau bahkan lebih baik: baca setiap komentar sebagai fungsi, lalu tulis fungsi yang melakukan hal itu.
Gherkin membantu Anda mewujudkan harapan
Gherkin adalah format deskripsi tes yang prinsipnya berbunyi: "Mengingat bahwa sistem berada dalam keadaan tertentu, jika sesuatu terjadi, maka ini diharapkan." Jika Anda tidak menggunakan alat pengujian yang memahami Gherkin, itu akan memberi Anda ide bagus tentang apa yang diharapkan dari aplikasi.
Tes unit baik, tes integrasi bahkan lebih baik
Di pekerjaan saya saat ini, kami hanya menguji modul dan kelas. Sebagai contoh, kami menulis tes hanya untuk level presentasi, kemudian kami menulis tes hanya untuk level controller, dan seterusnya. Ini membantu kita untuk memahami apakah semuanya beres, tetapi tidak memungkinkan kita untuk melihat gambaran keseluruhan dari apa yang terjadi - untuk ini, tes integrasi yang memeriksa perilaku seluruh sistem jauh lebih berguna.
Tes Meningkatkan API
Kami memprogram dalam kerangka level: ada tingkat penyimpanan yang harus membuat data kami abadi; ada tingkat pemrosesan yang entah bagaimana harus mengubah data yang disimpan; ada lapisan presentasi yang berisi informasi tentang penyajian data, dll.
Seperti yang saya katakan, tes integrasi lebih baik, tetapi menguji level itu sendiri memungkinkan Anda untuk lebih memahami bagaimana API mereka terlihat. Maka Anda akan lebih memahami situasi dengan panggilan sesuatu: apakah API terlalu rumit? Apakah saya perlu menyimpan begitu banyak data di dekat saya untuk melakukan satu panggilan?
Lakukan tes yang dapat Anda jalankan dari baris perintah
Maksud saya, bukan baris perintah itu sendiri yang penting untuk objek apa pun, tetapi pengetahuan Anda tentang perintah untuk menjalankan tes, kemampuan Anda untuk mengotomatisasi eksekusi mereka, yang kemudian dapat Anda terapkan dalam alat integrasi berkelanjutan.
Bersiaplah untuk mengirim kode Anda ke keranjang
Banyak dari mereka yang mulai mengembangkan berdasarkan pengujian (TDD) kesal ketika Anda memberi tahu mereka bahwa Anda mungkin perlu menulis ulang banyak kode mereka, termasuk apa yang Anda tulis sendiri.
TDD
diciptakan untuk melempar kode: semakin banyak Anda mempelajari masalah, semakin Anda memahami bahwa apa yang Anda tulis tidak akan menyelesaikannya dalam jangka panjang.
Jangan khawatir tentang ini. Kode Anda bukan tembok: jika Anda selalu harus membuangnya, ini bukan pemborosan. Tentu saja, Anda kehilangan waktu menulis kode, tetapi sekarang Anda lebih memahami masalahnya.
Bahasa yang baik memiliki tes terintegrasi
Saya yakinkan Anda: jika perpustakaan bahasa standar memiliki kerangka kerja pengujian - meskipun minimal - maka dalam ekosistem terkait tes akan lebih baik daripada dalam bahasa yang tidak memiliki kerangka kerja seperti itu, terlepas dari manfaat kerangka pengujian eksternal untuk bahasa ini.
Memikirkan masa depan berarti membuang energi Anda
Ketika pengembang mencoba memecahkan masalah, kadang-kadang mereka mencoba menemukan cara yang akan menyelesaikan semua masalah, termasuk yang mungkin muncul di masa depan.
Saya akan memberi tahu Anda satu hal: masalah-masalah masa depan ini tidak akan pernah muncul, dan Anda harus menemani setumpuk besar kode yang tidak akan digunakan secara keseluruhan, atau Anda harus menulis ulang semuanya karena tumpukan thuy kode yang tidak digunakan.
Selesaikan masalahnya sekarang. Kemudian putuskan yang berikut ini. Lalu yang berikutnya. Setelah Anda melihat pola yang muncul berdasarkan keputusan ini, dan baru
setelah itu Anda akan menemukan "solusi universal" Anda.
Dokumentasi adalah pesan cinta masa depan untuk Anda sendiri
Kita semua tahu seperti apa pendarahan itu untuk menulis dokumentasi terkutuk tentang fungsi, kelas, dan modul. Tetapi memahami jalan pikiran Anda ketika Anda menulis fungsi ini atau itu dapat menyelamatkan pantat Anda di masa depan.
Dokumentasi fungsi adalah kontraknya
Mulai menulis dokumentasi, Anda sebenarnya membuat kontrak (mungkin dengan diri Anda sendiri): "Saya mengklaim bahwa fungsi
ini melakukan
ini , dan itulah fungsinya."
Jika nanti Anda menemukan bahwa kode Anda tidak sesuai dengan dokumentasi, maka ini akan menjadi masalah kode, bukan dokumentasi.
Jika deskripsi fungsi memiliki "dan", maka ini buruk
Suatu fungsi seharusnya hanya melakukan satu hal. Ketika Anda menulis dokumentasi untuk itu dan melihat bahwa Anda telah menambahkan "dan", itu berarti bahwa fungsi melakukan sesuatu yang lain. Bagilah menjadi dua fungsi dan singkirkan "dan".
Jangan gunakan nilai boolean sebagai parameter
Saat mengembangkan fungsi, Anda mungkin tergoda untuk menambahkan bendera. Jangan lakukan ini.
Izinkan saya menjelaskan dengan sebuah contoh: katakanlah Anda memiliki sistem
getUserMessages pesan, dan ada fungsi
getUserMessages yang mengembalikan semua pesan ke pengguna. Tetapi ada situasi di mana Anda harus mengembalikan ringkasan singkat dari setiap pesan (misalnya, paragraf pertama), atau seluruh pesan. Oleh karena itu, Anda menambahkan parameter dalam bentuk flag atau nilai Boolean yang Anda panggil
retrieveFullMessage .
Sekali lagi, jangan lakukan ini.
Karena mereka yang membaca kode Anda akan melihat
getUserMessage(userId, true) dan bertanya-tanya tentang apa semua ini?
Atau Anda dapat mengubah nama fungsi
getUserMessageSummaries dan memasukkan
getUserMessagesFull , atau yang serupa, tetapi setiap fungsi hanya akan memanggil
getUserMessage asli dengan
true atau
false - tetapi antarmuka di luar kelas / modul Anda akan jelas.
Tetapi jangan menambahkan flag atau parameter Boolean ke fungsi.
Waspadalah terhadap perubahan antarmuka
Dalam paragraf sebelumnya, saya menyebutkan penggantian nama fungsi. Jika Anda mengontrol sumber tempat fungsi digunakan, maka ini bukan masalah, itu hanya masalah pencarian dan penggantian. Tetapi jika fungsi ini disediakan oleh perpustakaan, maka Anda tidak perlu mengubah nama sesuai keinginan Anda sendiri. Ini akan merusak banyak aplikasi lain yang tidak Anda kendalikan dan membuat marah banyak orang.
Anda dapat membuat fungsi baru dan menandai fungsi saat ini sebagai yang tidak diinginkan dalam dokumen atau melalui kode. Dan setelah beberapa rilis Anda akhirnya bisa membunuhnya.
Solusi jelek: buat fungsi-fungsi baru, tandai yang saat ini tidak diinginkan dan
tambahkan sleep ke awal fungsi untuk memaksa mereka yang menggunakan fungsi lama diperbarui.
Bahasa yang baik memiliki dokumentasi bawaan
Jika bahasa menggunakan caranya sendiri mendokumentasikan fungsi, kelas, modul, dan segala sesuatu yang lain, dan bahkan ada generator dokumentasi sederhana, maka semua yang disebutkan akan didokumentasikan dengan baik (tidak hebat, tapi setidaknya bagus).
Dan bahasa yang tidak memiliki dokumentasi bawaan sering kali tidak didokumentasikan dengan baik.
Bahasa lebih dari sekedar bahasa
Anda menulis dalam bahasa pemrograman dan membuat hal-hal "bekerja". Tetapi ada jauh dari hanya kata-kata khusus di dalamnya: bahasa memiliki sistem perakitan, sistem manajemen ketergantungan, alat untuk berinteraksi alat, perpustakaan dan kerangka kerja, ada komunitas, ada cara untuk berinteraksi dengan orang-orang.
Jangan pilih bahasa untuk kemudahan penggunaan. Ingatlah bahwa Anda dapat menemukan sintaksisnya sederhana, tetapi dengan memilih bahasa ini, Anda juga memilih cara pembuat bahasa berkomunikasi dengan komunitasnya.
Terkadang lebih baik membiarkan aplikasi macet daripada tidak melakukan apa-apa.
Meskipun ini terdengar aneh, lebih baik tidak menambahkan penanganan kesalahan daripada menangkapnya diam-diam dan tidak melakukan apa pun.
Jawa memiliki pola yang sangat umum:
try { something_that_can_raise_exception() } catch (Exception ex) { System.out.println(ex); }
Tidak ada yang dilakukan dengan pengecualian di sini, hanya pesan yang ditampilkan.
Jika Anda tidak tahu cara menangani kesalahan, biarkan itu terjadi, jadi setidaknya Anda bisa mengetahui
kapan itu terjadi.
Jika Anda tahu cara memprosesnya, lakukanlah
Berbeda dengan paragraf sebelumnya: jika Anda tahu kapan pengecualian, kesalahan atau hasil muncul, dan Anda tahu cara menanganinya, maka lakukanlah. Tampilkan pesan kesalahan, coba simpan data di suatu tempat, buang data yang dimasukkan oleh pengguna untuk digunakan nanti dalam log - cukup
proseskan .
Jenis berbicara tentang data apa yang Anda miliki
Memori hanyalah urutan byte. Bytes hanyalah angka dari 0 hingga 255. Yang dimaksud angka-angka ini dijelaskan dalam sistem jenis bahasa.
Misalnya, dalam C, tipe karakter (tipe char) dengan nilai 65 mungkin akan menjadi huruf "A", dan int dengan nilai 65 akan menjadi angka 65.
Ingatlah hal ini saat bekerja dengan data Anda.
Saat menambahkan Booleans, banyak yang lupa memeriksa jumlah nilai
True . Baru-baru ini saya menemukan contoh ini JavaScript:
console.log(true+true === 2); > true console.log(true === 1); > false
Jika data Anda memiliki skema, simpan sebagai struktur
Jika datanya sederhana, misalnya, hanya dua bidang, maka Anda dapat menyimpannya dalam daftar (atau tupel jika bahasa Anda memungkinkan). Tetapi jika data memiliki skema - format tetap - maka selalu gunakan beberapa struktur atau kelas untuk menyimpannya.
Kenali dan jauhi kultus kargo
Gagasan "pemujaan kargo" adalah bahwa jika seseorang melakukannya, maka kita bisa. Paling sering, kultus kargo hanyalah "pelarian yang mudah" dari masalah: mengapa kita harus berpikir tentang cara menyimpan data pengguna dengan benar jika X telah melakukan ini?
"Jika Perusahaan Besar menyimpan data dengan cara ini, maka kita bisa."
"Jika Perusahaan Besar menggunakannya, maka itu bagus."
"Alat yang tepat untuk tugas itu" adalah cara untuk memaksakan pendapat Anda
Ungkapan "alat yang tepat untuk tugas itu" harus berarti bahwa ada alat yang benar dan salah untuk sesuatu. Misalnya, menggunakan bahasa atau kerangka kerja tertentu alih-alih bahasa atau kerangka kerja saat ini.
Tetapi setiap kali saya mendengar ungkapan ini dari seseorang, orang mendorong bahasa / kerangka kerja favorit mereka dengan cara ini, alih-alih, katakanlah, bahasa / kerangka kerja yang benar.
"Alat yang tepat" lebih jelas daripada yang Anda pikirkan
Mungkin sekarang Anda berpartisipasi dalam proyek di mana Anda ingin memproses beberapa teks. Anda mungkin ingin mengatakan, "Mari kita gunakan Perl karena semua orang tahu bahwa Perl sangat pandai memproses teks."
Apa yang Anda lupa: tim Anda berspesialisasi dalam C. Semua orang tahu C, bukan Perl.
Tentu saja, jika ini adalah proyek kecil "di lutut", maka dimungkinkan pada Perl. Dan jika proyek itu penting bagi perusahaan, lebih baik menuliskannya dalam C.
PS: Proyek heroik Anda (lebih lanjut tentang ini di bawah) mungkin gagal karena ini.
Jangan cocok dengan apa yang ada di luar proyek Anda
Terkadang, alih-alih menggunakan alat ekstensi yang sesuai, orang-orang mulai mengubah pustaka dan kerangka kerja eksternal. Misalnya, buat perubahan langsung ke WordPress atau Django.
Dengan demikian, Anda dapat dengan mudah dan sangat cepat membuat proyek tidak cocok untuk pemeliharaan. Segera setelah versi baru dirilis, Anda harus menyinkronkan perubahan dengan proyek utama, dan segera Anda akan menemukan bahwa Anda tidak dapat menerapkan perubahan lagi, dan meninggalkan versi lama alat eksternal penuh dengan lubang keamanan.
Aliran data mengalahkan pola
Ini pendapat pribadi saya. Jika Anda memahami bagaimana data harus melalui kode Anda, maka itu akan lebih baik baginya daripada jika Anda menggunakan banyak pola desain.
Pola desain digunakan untuk menggambarkan solusi, bukan untuk menemukannya.
Lagi-lagi pendapat pribadi saya. Menurut pengamatan saya, pola desain yang paling sering digunakan untuk menemukan solusi. Dan sebagai hasilnya, solusi - dan kadang-kadang masalah itu sendiri - terdistorsi agar sesuai dengan pola.
Pertama, selesaikan masalah Anda. Temukan solusi yang baik, lalu cari di antara pola untuk mengetahui apa yang disebut solusi Anda.
Saya telah melihat ini berkali-kali: kita memiliki masalah, polanya dekat dengan solusi yang benar, mari kita gunakan polanya, sekarang kita perlu menambahkan banyak semuanya ke solusi yang benar, sehingga cocok dengan polanya.
Pelajari dasar-dasar pemrograman fungsional
Anda tidak perlu mempelajari secara mendalam pertanyaan "apa itu monad" atau "apakah itu berfungsi". Tapi ingat: Anda tidak harus selalu mengubah data; buat elemen baru dengan nilai baru (anggap data tidak dapat diubah); sejauh mungkin, lakukan fungsi dan kelas yang tidak menyimpan status internal (fungsi dan kelas murni).
Upaya kognitif adalah musuh keterbacaan.
"
Disonansi kognitif " adalah ungkapan terselubung "untuk memahami hal ini, saya harus secara bersamaan mengingat dua (atau lebih) hal yang berbeda." Dan semakin tidak langsung informasi ini, semakin banyak upaya yang Anda perlu habiskan untuk menyimpannya di kepala Anda.
Misalnya, menambahkan Boolean untuk menghitung nilai
True adalah versi ringan dari disonansi kognitif. Jika Anda membaca kode dan melihat fungsi
sum() , yang, seperti yang Anda tahu, menambahkan semua angka dalam daftar, maka Anda mengharapkan untuk melihat daftar angka; dan saya bertemu orang-orang yang menggunakan
sum() untuk menghitung nilai
True dalam daftar Boolean, yang benar-benar membingungkan.
Angka ajaib tujuh plus atau minus dua
"
Angka ajaib " adalah artikel dalam psikologi yang menjelaskan jumlah elemen yang dapat disimpan secara bersamaan dalam memori jangka pendek.
Jika Anda memiliki fungsi yang memanggil fungsi yang memanggil fungsi yang memanggil fungsi yang memanggil fungsi yang memanggil fungsi, maka ini hanya neraka bagi pembaca kode Anda.
Coba pikirkan: Saya akan mendapatkan hasil dari fungsi ini, meneruskannya ke fungsi kedua, mendapatkan hasilnya, melewati yang ketiga, dll.
Selain itu, psikolog saat ini lebih sering berbicara tentang angka ajaib EMPAT, daripada tujuh.
Pikirkan dalam kategori "komposisi fungsi" (misalnya, "Saya akan memanggil fungsi ini, lalu itu, lalu ada ..."), dan bukan dalam kategori "panggilan fungsi" (misalnya, "fungsi ini akan memanggil itu, ia akan memanggil itu. .. ").
Pemotongan itu bagus, tetapi hanya dalam jangka pendek
Banyak bahasa, perpustakaan, dan kerangka kerja menawarkan metode pintasan untuk mengurangi jumlah karakter yang Anda ketikkan.
Tapi nanti itu kembali kepada Anda, dan Anda akan dipaksa untuk menghapus singkatan dan menulis semuanya secara keseluruhan.
Jadi pertama-tama cari tahu apa yang dilakukan singkatan tertentu sebelum menggunakannya.
Anda tidak perlu menulis semuanya pada awalnya, dan kemudian mengubahnya menjadi singkatan: lakukan apa yang dilakukan singkatan untuk Anda, dan setidaknya Anda akan mengerti apa yang salah, atau bagaimana mengganti sesuatu dengan versi yang tidak disusun.
Tahan godaan "mudah"
Tentu saja, IDE akan membantu Anda menyelesaikan secara otomatis banyak hal dan membuatnya mudah untuk membangun sebuah proyek, tetapi apakah Anda bahkan mengerti apa yang terjadi di sana?
Apakah Anda tahu cara kerja sistem build Anda? Jika Anda harus menjalankannya tanpa IDE, dapatkah Anda melakukannya?
Apakah Anda ingat nama fungsi tanpa penyelesaian otomatis? Apakah mungkin untuk memecahkan sesuatu atau mengganti nama sehingga lebih mudah dipahami?
Perhatikan apa yang terjadi di bawah tenda.
SELALU menggunakan zona waktu dalam tanggal
Saat bekerja dengan tanggal,
selalu tambahkan zona waktu. Anda akan
selalu mengalami masalah dengan ketidakcocokan zona waktu di komputer dan di server, dan Anda akan kehilangan banyak waktu untuk debugging, mencoba memahami mengapa antarmuka menampilkan waktu yang salah.
SELALU menggunakan UTF-8
Anda akan memiliki masalah yang sama dengan pengkodean dengan tanggal. Oleh karena itu, selalu konversikan nilai string ke UTF-8, simpan dalam database di UTF-8, dan kembali dari API Anda ke UTF-8.
Anda dapat mengonversi ke penyandian lain, tetapi UTF-8 mengalahkan perang penyandian, jadi cara termudah untuk tetap melakukannya.
Mulai bodoh
Salah satu cara untuk melepaskan diri dari IDE adalah dengan "memulai dengan cara bodoh": ambil saja kompiler, editor APAPUN dengan penyorotan kode dan - program, bangun, jalankan.
Ya itu tidak mudah. Tetapi ketika nanti Anda menggunakan semacam IDE, Anda hanya akan memikirkan tombol “Ya, itu meluncurkan itu.” Inilah yang dilakukan oleh IDE.
Log adalah untuk acara, bukan untuk antarmuka pengguna.
Untuk waktu yang lama saya menggunakan log untuk menunjukkan kepada pengguna apa yang terjadi dengan aplikasi tersebut. Anda tahu, karena lebih mudah menggunakan satu hal daripada dua.
Untuk memberi tahu pengguna tentang acara, gunakan formulir keluaran standar. Untuk pelaporan kesalahan, pesan kesalahan standar. Dan gunakan log hanya untuk menyimpan data yang dapat Anda proses dengan mudah nanti.
Log bukan antarmuka pengguna, tetapi entitas yang harus Anda parsing untuk mengambil informasi pada waktu yang tepat. Log seharusnya tidak dapat dibaca manusia.
Debuggers Berlebihan
Saya telah mendengar keluhan dari banyak editor kode bahwa tanpa debugger itu mengerikan, justru karena mereka tidak punya debugger.
Tetapi ketika kode Anda sedang beroperasi, Anda
tidak dapat menjalankan debugger favorit Anda. Sial, Anda bahkan tidak dapat menjalankan IDE favorit Anda. Tapi penjurnalan ... itu bekerja di mana-mana. Anda mungkin tidak memiliki informasi yang diinginkan pada saat musim gugur (misalnya, karena tingkat penebangan yang berbeda), tetapi Anda
dapat mengaktifkan pencatatan untuk mengetahui alasannya nanti.
Saya bungkam tentang fakta bahwa debuggers itu sendiri buruk, mereka hanya tidak memberikan bantuan yang banyak diharapkan dari mereka.
Selalu gunakan sistem versi
"Ini hanya aplikasi bodoh saya yang ingin saya pelajari sesuatu" - ini tidak membenarkan kurangnya sistem versi.
Jika Anda menggunakan sistem seperti itu sejak awal, akan lebih mudah untuk memutar kembali ketika Anda melakukan kesalahan.
Satu perubahan per komit
Saya bertemu orang-orang yang menulis pesan berikut dalam komit: "Memperbaiki masalah 1, 2 dan 3". Kecuali jika semua masalah ini saling menduplikasi - di mana dua harus sudah ditutup - harus ada tiga komit bukan satu.
Patuhi prinsip "satu perubahan per komit." Dan dengan perubahan yang saya maksud adalah perubahan dalam satu file. Jika Anda perlu mengubah tiga file, lakukan bersama file-file ini. Tanyakan kepada diri sendiri: "jika saya membatalkan perubahan ini, apa yang harus hilang?"
"Git add -p" akan membantu Anda dengan banyak perubahan
Ini hanya berlaku untuk Git. Ini memungkinkan Anda untuk menggabungkan sebagian file menggunakan parameter "-p", sehingga Anda hanya dapat memilih perubahan yang terkait satu sama lain, meninggalkan yang lain untuk komit baru.
Struktur proyek berdasarkan data atau tipe, bukan fungsionalitas
Sebagian besar proyek menggunakan struktur berikut:
. +-- IncomingModels | +-- DataTypeInterface | +-- DataType1 | +-- DataType2 | +-- DataType3 +-- Filters | +-- FilterInterface | +-- FilterValidDataType2 +-- Processors | +-- ProcessorInterface | +-- ConvertDataType1ToDto1 | +-- ConvertDataType2ToDto2 +-- OutgoingModels +-- DtoInterface +-- Dto1 +-- Dto2
Artinya, data terstruktur berdasarkan fungsionalitas (semua model input berada dalam satu direktori atau paket, semua filter berada di direktori atau paket lain, dll.).
Ini bekerja dengan baik. Tetapi ketika Anda menyusun menurut data, jauh lebih mudah untuk membagi proyek menjadi yang lebih kecil, karena pada titik tertentu Anda mungkin perlu melakukan hampir semuanya sama seperti sekarang, dengan hanya perbedaan kecil.
. +-- Base | +-- IncomingModels | | +-- DataTypeInterface | +-- Filters | | +-- FilterInterface | +-- Processors | | +-- ProcessorInterface | +-- OutgoingModels | +-- DtoInterface +-- Data1 | +-- IncomingModels | | +-- DataType1 | +-- Processors | | +-- ConvertDataType1ToDto1 | +-- OutgoingModels | +-- Dto1 ...
Sekarang Anda dapat membuat modul yang
hanya berfungsi dengan Data1, modul lain yang hanya berfungsi dengan Data2, dll. Dan kemudian Anda dapat memisahkannya menjadi modul yang terisolasi.
Dan ketika Anda perlu membuat proyek lain, juga berisi Data1 dan bekerja dengan Data3, Anda dapat menggunakan kembali sebagian besar kode dalam modul Data1.
Buat perpustakaan
Saya sering melihat bagaimana pengembang membuat repositori mega dengan proyek yang berbeda, atau mempertahankan cabang yang berbeda, tidak sehingga mereka adalah lingkungan sementara untuk kemudian bergabung dengan bagian utama, tetapi hanya untuk membagi proyek menjadi bagian-bagian yang lebih kecil (berbicara tentang pemisahan menjadi modul, bayangkan bahwa alih-alih membangun proyek baru yang menggunakan kembali tipe Data1, saya menggunakan cabang dengan fungsi utama yang sama sekali berbeda dan tipe Data3).
Mengapa tidak mengalokasikan bagian yang sering digunakan ke perpustakaan yang dapat dihubungkan di proyek yang berbeda?
Paling sering, alasannya adalah bahwa orang tidak tahu cara membuat perpustakaan, atau khawatir tentang cara "menerbitkan" perpustakaan ini ke sumber ketergantungan tanpa memberikannya (jadi bukankah lebih baik untuk memahami bagaimana alat manajemen proyek Anda mendapatkan dependensi sehingga Anda dapat membuat repositori dependensi Anda sendiri?).
Belajar memantau
Dalam kehidupan sebelumnya, saya menambahkan banyak metrik untuk memahami bagaimana sistem berperilaku: seberapa cepat datang, seberapa cepat, berapa banyak antara input dan output, berapa banyak tugas yang diproses ...
Ini benar-benar memberikan ide bagus tentang perilaku sistem. Apakah kecepatan berkurang? Untuk memahami, saya dapat memeriksa data apa yang masuk ke sistem. Apakah pengurangan kecepatan normal di beberapa titik?
Faktanya adalah bahwa tanpa pemantauan lebih lanjut, agak aneh untuk mencoba mencari tahu seberapa "sehat" sistem itu. Pemeriksaan kesehatan dengan gaya "Apakah itu menanggapi permintaan" tidak lagi cocok.
Menambahkan pemantauan dini akan membantu Anda memahami bagaimana sistem berperilaku.
Gunakan file konfigurasi
Bayangkan: Anda menulis fungsi yang harus Anda berikan nilai agar dapat mulai memproses (katakanlah, ID akun di Twitter). Tetapi kemudian Anda perlu melakukan ini dengan dua nilai, dan Anda cukup memanggil fungsi itu lagi dengan nilai yang berbeda.
Lebih baik menggunakan file konfigurasi dan menjalankan aplikasi dua kali, dengan dua konfigurasi yang berbeda.
Opsi baris perintah terlihat aneh, tetapi mereka berguna
Jika Anda mentransfer sesuatu ke file konfigurasi, Anda dapat membuat hidup Anda lebih mudah dan menambahkan kemampuan untuk memilih dan membuka file.
Hari ini, untuk setiap bahasa, ada perpustakaan yang bekerja dengan opsi untuk baris perintah. Mereka akan membantu Anda membuat utilitas yang baik dengan menyediakan antarmuka pengguna standar untuk semuanya.
Bukan hanya komposisi fungsi, tetapi komposisi aplikasi
Unix menggunakan konsep ini: "aplikasi yang melakukan satu hal dan melakukannya dengan baik."
Saya mengatakan bahwa Anda dapat menggunakan satu aplikasi dengan dua file konfigurasi. Dan jika Anda membutuhkan hasil dari kedua aplikasi? Kemudian Anda dapat menulis aplikasi yang membaca hasil yang kedua, dan menggabungkan semuanya menjadi hasil yang umum.
Bahkan ketika menggunakan komposisi aplikasi, mulailah bodoh
Komposisi aplikasi dapat berkembang menjadi layanan mikro (yang bagus), tetapi mereka membutuhkan pemahaman tentang bagaimana aplikasi "berkomunikasi" satu sama lain melalui jaringan (protokol dan sejenisnya).
Tidak perlu mulai dari ini. Aplikasi dapat menulis dan membaca dari file, jadi lebih mudah. , .
, . «, », , « , ».
, . , .
,
, , . , . . . , .
, , . Lisp, . , Python
yield , , , . , , , , .
, , . , « », « » ..
, .
,
, .
, , «»: , , , . , , . , , , .
, , . , .
, . (« ?»), .
… Google
, . , Google , . , , Google , .
C/C++ — K&R
. :)
Python — PEP8
PEP8. , .
, ?
sleep() .
? ?
, .
sleepForSecs sleepForMs , ,
sleep .
, .
«Zen of Python», .
,
, . , - . - , , , .
« , » — .: , — . , .
, Java , Rust. , Spring , ++.
, — , «» .
, .
—
, , - .
— , — .
« , »
« » « ». , , , , .
, .
,
, , , , .
.
( «»), , , . , AWS SQS ( ), , , RabbitMQ.
- , , , .
,
, . , . , .
( , ). , , , .
,
- , , . , ,
, , .
, . , , , « » « , ».
, .
«». , . , . , , . , .
: «, , , , ». , .
.
. - . «» «».
, , , . , .
, ,
. , , - , .
Jangan lakukan ini.
- ,
.
- , . , .
, . .
- ,
: - , . , .
«, , » — , .
, , . . , - . . .
, , . , , , - . , , .
,
« ».
- , , , . : « , , ».
.
, , , . .
, .
«»
«» — . , - « », - .
, , , . , , , .
.
, , «»
. - : «, , ?»
, . , , (, , ).
, —
, -, , , , ( ).
… , - , , «
!».
:
«» , , , , . , , .
, /, .
, .
- .
« » « »
: - , , , .
« » — , .
.
,
, , - , .
- .
, .
, , .
, , , .
… .
IT
.
, , 15 , 3-4 .
.
.
, , , - , , , , , , .
. , , URL, .
Trello — ,
« , », .
,
, « , », « , ».
. . , - .
, .
.
, , .
…
, . , « ». - « », , .
. .
Github «, » . , - .
.
: Python, , Java Python, .
«, »
, , , «, ».
- , , - . , .