Portfolio CFML yang boleh disahkan, bukan cerita

Portfolio CFML yang boleh disahkan, bukan cerita

Ramai pembangun menulis di LinkedIn: "berpengalaman 5 tahun", "mahir dalam integrasi sistem", "berjaya menyiapkan projek besar". Penyemak yang berpengalaman tidak dapat mengesahkan satu pun daripada ayat itu.

Portfolio yang berkesan tidak bercerita. Ia membolehkan orang lain menyemak. Artikel ini menyenaraikan apa yang perlu ada supaya kerja anda boleh disahkan dalam beberapa minit, bukan dipercayai secara membuta tuli.

Prinsip asas: setiap dakwaan mesti ada bukti

Sebelum menulis apa-apa dalam resume atau profil, tanya satu soalan: bolehkah orang lain mengesahkan ayat ini tanpa menghubungi saya?

Jika jawapannya tidak, ayat itu nilai rendah, atau lebih buruk, ia menimbulkan syak. Portfolio yang baik mengurangkan kerja penyemak.

Bukti 1: repo yang boleh dijalankan

Repo yang baik mempunyai README yang membolehkan orang lain menjalankannya tanpa bertanya.

Yang perlu ada:

• Arahan pemasangan yang tepat, termasuk versi enjin
• Satu arahan untuk memulakan aplikasi
• Satu arahan untuk mengesahkan ia berfungsi
• Keperluan sistem: Java, Lucee, pangkalan data, sambungan

Contoh arahan yang baik:

git clone <repo> && cd <repo>
cp .env.contoh .env
docker run -d --name app -p 8888:8888 -v "$PWD":/var/www lucee/lucee:7.1.1.17
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8888/

Arahan terakhir itu penting. Ia bukan hiasan. Ia memberitahu penyemak bahawa aplikasi benar-benar hidup, dan ia boleh disalin ke terminal.

Bukti 2: ujian yang memaparkan hasil

Ujian yang tidak memaparkan apa-apa tidak membuktikan apa-apa. Ujian yang mencetak LULUS dan GAGAL, berserta jumlah, boleh dibaca oleh sesiapa tanpa alat tambahan.

svc = new perkhidmatan.HargaService(0.06);
lulus = 0; gagal = 0;
function sah(required boolean syarat, required string nama) {
    if (arguments.syarat) { lulus++; writeOutput("LULUS " & arguments.nama & chr(10)); }
    else { gagal++; writeOutput("GAGAL " & arguments.nama & chr(10)); }
}

r1 = svc.kira(100);
sah(r1.ok && r1.jumlah == 106, "100 x 1 = 106");
r2 = svc.kira(0);
sah(!r2.ok, "harga sifar ditolak");
r3 = svc.kira(50, 200);
sah(!r3.ok, "kuantiti 200 ditolak");
r4 = svc.kira(100, 3);
sah(r4.ok && r4.jumlah == 318, "100 x 3 = 318");
writeOutput("SKOR: " & lulus & "/" & (lulus + gagal) & chr(10));

Output sebenar pada Lucee 7.1.1.17:

LULUS 100 x 1 = 106
LULUS harga sifar ditolak
LULUS kuantiti 200 ditolak
LULUS 100 x 3 = 318
SKOR: 4/4

Perhatikan bahawa dua daripada empat ujian menguji kes gagal. Penyemak yang berpengalaman akan mencari bahagian itu dahulu, kerana di situlah kebanyakan kod buatan sendiri gagal.

Simpan output itu dalam README atau dalam commit. Ia bukti yang boleh diulang.

Bukti 3: demo hidup, dengan URL yang boleh dibuka

Repo sahaja tidak membuktikan aplikasi berjalan. Satu URL awam yang stabil membuktikan lebih banyak daripada tiga perenggan penerangan.

Yang perlu disahkan pada demo:

• Halaman utama pulang 200
• Laluan utama yang anda sebut dalam README benar-benar wujud
• Tiada mesej ralat pembangun
• Ada cara untuk melihat bahawa ia bukan tangkapan skrin

Cara paling mudah untuk membuktikan ia hidup: minta penyemak menekan satu tindakan yang menghasilkan respons berbeza, seperti menukar bahasa atau menapis senarai. Tangkapan skrin tidak boleh berbuat begitu.

Bukti 4: ukuran, bukan kata sifat

"Laju" dan "optimum" tidak bermakna. Nombor bermakna.

Contoh ukuran yang boleh anda jalankan sendiri dalam CFML:

t0 = getTickCount();
for (i = 1; i <= 1000; i++) { svc.kira(100, 2); }
writeOutput("1000 panggilan: " & (getTickCount() - t0) & "ms");

Pada rig ujian Lucee 7.1.1.17, 1,000 panggilan mengambil 3 hingga 5 milisaat. Nombor itu boleh dibandingkan, dipertikaikan, dan diuji semula.

Ukuran yang berbaloi dimasukkan dalam portfolio:

• Masa respons laluan utama, median dan persentil ke-95
• Masa pertanyaan pangkalan data sebelum dan selepas indeks
• Saiz muatan selepas pengecilan
• Bilangan baris yang diuji, dan bilangan kes gagal yang diliputi

Satu angka yang tepat lebih bernilai daripada sepuluh kata sifat.

Bukti 5: sejarah commit yang boleh dibaca

Repositori dengan satu commit besar bernama "update" memberitahu penyemak bahawa anda tidak bekerja secara berperingkat, atau anda menyembunyikan sesuatu.

Commit yang baik:

• Kecil dan menerangkan sebab, bukan hanya apa
• Mengandungi ujian bersama perubahan
• Tidak mencampur pemfaktoran dengan ciri baharu
• Mesejnya boleh dibaca oleh orang yang tidak menulis kod itu

Anda tidak perlu sejarah yang sempurna. Anda hanya perlu sejarah yang jujur.

Bukti 6: nota keputusan, bukan diari

Satu fail NOTA.md dalam repo yang mencatat keputusan teknikal lebih bernilai daripada blog peribadi.

Isi yang berbaloi:

• Mengapa satu pendekatan dipilih, dan apa alternatif yang ditolak
• Had yang diketahui, dan bila ia patut dikaji semula
• Nombor yang diukur, bersama tarikh dan versi enjin

Contoh ayat yang baik: "Keyset pagination dipilih kerana OFFSET 150000 mengambil 280 ms manakala keyset 1 ms pada 200,000 baris, diukur pada MySQL 8.4.11 dan Lucee 7.1.1.17."

Penyemak boleh mengulangi ukuran itu. Ia juga menunjukkan anda tahu had penyelesaian anda sendiri, iaitu tanda kematangan yang sukar dipalsukan.

Cara mengemas kini portfolio tanpa membazir masa

Portfolio yang diselenggara setiap minggu akan bertahan. Portfolio yang dibina sekali untuk temuduga akan luput.

Tabiat kecil yang berkesan:

• Setiap kali anda menyelesaikan satu pepijat yang sukar, tambah satu perenggan dalam NOTA.md
• Setiap kali anda mengukur sesuatu, simpan nombornya bersama versi enjin
• Setiap kali anda menolak satu pendekatan, tulis sebabnya dalam satu ayat
• Setiap suku tahun, buang projek yang tidak lagi boleh dijalankan

Kerja itu mengambil masa sepuluh minit setiap kali, dan hasilnya jauh lebih baik daripada menulis semula profil setiap kali anda mencari kerja.

Apa yang tidak patut dimasukkan

• Tangkapan skrin tanpa pautan atau kod
• Nombor yang tidak boleh diulang, seperti "meningkatkan prestasi 300%" tanpa kaedah
• Senarai teknologi tanpa contoh penggunaan
• Projek yang tidak boleh dijalankan kerana pangkalan data persendirian diperlukan, tanpa data contoh
• Kredensial, kunci API, atau data pelanggan dalam repo awam

Yang terakhir itu bukan sahaja melemahkan portfolio, ia boleh menjadi insiden keselamatan.

Cara menyusun portfolio dalam satu halaman

Struktur yang berkesan:

1. Satu ayat tentang apa yang anda bina, bukan jawatan yang anda pegang
2. Tiga projek, setiap satu dengan pautan repo dan pautan demo
3. Bagi setiap projek: satu masalah, satu keputusan teknikal, satu ukuran
4. Satu pautan ke ujian yang memaparkan output
5. Cara menghubungi anda

Tiga projek sudah cukup. Sepuluh projek separuh siap melemahkan mesej.

Satu perkara yang sering terlepas pandang

Penyemak membuka portfolio anda pada telefon, bukan pada komputer yang sama dengan anda. Uji satu projek pada skrin 360 piksel sebelum menghantar pautan.

Jika navigasi terpotong atau teks perlu dizum, penyemak akan menyimpulkan bahawa anda tidak menguji kerja sendiri. Ia kesimpulan yang keras, tetapi ia yang berlaku.

Soalan lazim

Saya tiada projek untuk ditunjukkan. Apa yang boleh dibuat?

Bina satu alat kecil yang menyelesaikan masalah anda sendiri, dan uji dengan data sebenar. Alat 200 baris yang berjalan dan diuji lebih bernilai daripada aplikasi besar yang tidak boleh dijalankan.

Perlukah demo hidup menggunakan domain sendiri?

Tidak semestinya. Subdomain atau pautanhos percuma sudah cukup, asalkan ia stabil semasa penyemak melihatnya. Jika ia mati, ia memberi kesan sebaliknya.

Bagaimana jika kod lama saya tidak boleh dikongsi?

Tulis semula bahagian kecilnya sebagai projek contoh, tanpa data pelanggan. Nyatakan dengan jelas bahawa ia versi ringkas, bukan projek asal. Kejujuran itu sendiri satu isyarat positif.

Adakah ujian perlu menggunakan rangka kerja?

Tidak untuk projek kecil. Halaman ujian dengan empat assert dan output yang jelas sudah memadai. Rangka kerja berbaloi apabila bilangan ujian meningkat atau anda perlu meniru kebergantungan.

Penutup

Portfolio bukan dokumen pemasaran. Ia bukti yang disusun supaya orang lain boleh menyemaknya dengan cepat.

Empat perkara yang memberi kesan paling besar: repo yang boleh dijalankan, ujian yang mencetak hasil, demo hidup yang boleh diklik, dan satu ukuran yang tepat. Selebihnya hiasan.

Untuk kemahiran HTTP yang boleh ditunjukkan dengan cara yang sama, lihat kemahiran HTTP untuk pembangun CFML.