Kandungan
- 01. Pengekodan jangan memotongnya lagi
- Luas dan kedalaman
- 02. Peringatan besar
- 03. Apa yang dikatakan oleh internet
- Fahami medium
- 04. Perkara yang kita bina
- 05. Peranti
- Fahami timbunan
- Kerja misteri
- Alat yang berguna
- 06. Dev akan memperbaikinya ... mungkin
- Menyahpepijat
- 07. Apa yang pengguna mahukan
- Pasaran yang kompetitif
- 08. Melukis dan menulis
- 09. Selamat mencuba
- 10. Tetap tajam
- Suka ini? Baca ini!
Pembangun perlu lebih daripada pekerja kasar yang menghasilkan kod. Kami menjangkakan lebih banyak kehidupan digital kami dan orang-orang inilah yang membangunnya, jadi apa yang perlu diketahui oleh para dev terbaik? Inilah perkara yang saya lihat hilang daripada terlalu banyak pembangun. Ini tidak menyeluruh tetapi kualiti inilah yang menjadikan pengkod yang masuk akal menjadi pembangun yang luar biasa.
Tetapi itu bukan satu perkara, dan terutama sekali tidak mampu menguraikan XML atau mengoptimumkan kod, Ini adalah koleksi kemahiran yang mengejutkan yang tidak diajar dalam buku-buku mengenai menulis kod. Mereka sedikit tambahan.
Mengapa melampau seperti ini? Kerana pembangunan penting tetapi pemaju terlalu sering diserahkan ke dunia yang berbeza, tidak selalu dibuatnya. Ini tidak pernah berjaya. Pembangunan - apa sahaja yang teknikal - sentiasa berkembang apabila mereka yang mempunyai pengetahuan lebih memahami daripada hanya kod.
01. Pengekodan jangan memotongnya lagi
Kita berada di dunia di mana pengekodan menjadi kurang hebat. Semua orang membina laman web, ada di antaranya kod tetapi anda tidak perlu. Bukan hanya orang yang pandai membuat laman web, aplikasi dan ciri.
Sejak web datang dan orang dapat mengajar diri mereka sendiri ada pengembang yang mengajar sendiri. Tetapi graduan juga terancam. Saya mendapat CV dengan orang yang mempunyai ijazah sains komputer, kursus AI, pelbagai media dan pengekodan di bawah tali mereka tetapi masih ada yang hilang. Kadang-kadang banyak yang hilang.
Saya bukan orang pertama yang mengatakan ini. 'Pengekodan jangan memotongnya lagi' adalah tajuk bab 3 dari Pengaturcara Bersemangat, yang bersama dengan buku seperti Pemikiran dan Pembelajaran Pragmatik mendesak pengaturcara untuk memperbaiki diri melebihi kod; untuk menjadi anggota pasukan yang bertanggungjawab dan sepenuhnya manusia.
Luas dan kedalaman
Pembangun perlu lebih baik dalam dua cara: luas dan mendalam. Mereka perlu memahami luasnya interaksi manusia dalam pasukan mereka dan dengan perkara-perkara yang mereka bina. Mereka perlu memahami kedalaman sistem yang mereka gunakan, hingga ke O / S.
Dan bukan hanya pembangun yang seharusnya membaca perkara ini. Sekiranya anda bekerja dengan pemikir, saya rasa anda harus mengharapkan lebih banyak daripada mereka. Buat mereka membuat sketsa apa yang mereka bicarakan. Mintalah mereka untuk menerangkan dengan gambar, objek, dan (ia berfungsi) memotong orang dengan tepat bagaimana sistem itu bagi manusia yang menggunakannya.
02. Peringatan besar
Saya akan bercakap negatif mengenai pembangun, tetapi saya rasa saya dibenarkan kerana saya seorang. Juga kerana sekurang-kurangnya satu perkara yang saya bicarakan di sini adalah benar bagi banyak pembangun yang saya temui. Walaupun karya mereka hebat dan mereka tahu kod mereka, masa-masa adalah kompetitif. Anda mesti mempunyai kelebihan, dan ini:
- lebih berteknologi
dan
- menjadi banyak lebih banyak manusia
03. Apa yang dikatakan oleh internet
Googling untuk 'kemahiran pengembangan web penting' memunculkan apa yang anda harapkan. Pengetahuan rangka kerja, penyemak imbas x, CSS dan JS. Mereka menyenaraikan kerangka kerja yang harus anda ketahui, platform yang mesti anda buat dan tren baru yang harus anda perhatikan.
Ini adalah media kami. Mereka adalah barang yang kami bina tetapi bukan yang berjaya dalam projek. Pembangun dapat memahami setiap perincian sistem, memberitahu anda setiap ciri API dan teknologi CSS baru tetapi masih menghasilkan sesuatu yang tidak dapat digunakan.
Fahami medium
Pembangun, seperti semua orang, perlu memahami mediumnya - tetapi mereka juga harus memahami penonton, sama ada pengguna, pasukan atau pembangun lain. Mereka perlu memahami bagaimana media mereka sesuai dengan dunia (dengan kata lain, persekitaran pengeluaran) dan kesannya (bagaimana orang menggunakannya).
Saya melihat ini digambarkan sebagai orang yang "luas dan dalam". Luas, kerana anda perlu memahami dunia sebagai manusia yang bekerja dengan manusia lain. Jauh kerana anda memerlukan pengetahuan teknikal yang menyeluruh di bawah tahap bahagian projek anda. Pembangun ini memberikan dorongan besar kepada projek anda dan mengubah rentak projek, tanpa itu anda akan mendapati kakitangan bukan teknikal tersekat dengan terperinci yang melimpah dari pasukan teknologi.
04. Perkara yang kita bina
Saya baru-baru ini menulis senarai semua yang kami gunakan untuk membina laman web, mengurus hosting dan menyelesaikan sesuatu agar orang yang bergabung dapat menipu teknologi untuk dipelajari dalam beberapa minggu pertama mereka. Kami menganggap bahawa orang mengetahui perkara-perkara ini, jadi untuk memberi permulaan baru kepada rekrut baru, kami akan menyenaraikan semua yang kami gunakan setiap hari.
Saya menjangkakan setengah lusin teknologi tetapi berakhir dengan lebih banyak lagi. Senarai ini - 'apa yang kami gunakan' - merangkumi CMS, bahasa pengaturcaraan dan teknologi penyemak imbas biasa, tetapi juga sekumpulan alat yang tidak diingati oleh pasukan. Itu semua memori otot. Menaip 'git', 'phing', 'thor' pada baris arahan, kami tidak menyangka bahawa seseorang mungkin tidak.
Membina alat; CI; git untuk kawalan versi dianggap biasa, tetapi melihat semula CV ini hampir tidak muncul. Yang bergaya akan muncul (dan adakah sinis saya fikir agensi tertentu menambahkannya?!) Tetapi selalunya tanpa pengalaman konkrit.
Alat ini penting untuk mempercepat pembangunan projek, jadi pastikan anda mempunyai set alat yang jauh lebih kaya daripada bahasa anda, CMS dan beberapa kerangka kerja. Anda memerlukan penerapan, pengujian, CI, kawalan versi yang kuat (dalam pasukan - bukan dengan anda sendiri), dan anda perlu memahami konsep teras ini daripada hanya beberapa tutorial.
05. Peranti
Alat dan trik tambahan ini sesuai dengan apa yang disebut orang sebagai 'devops'. Devops terbang di hadapan dua silo tradisional: pengeluaran, yang membuat sesuatu berjalan, dan pengembangan, yang membuat barang baru (dan sering menghentikan sesuatu berjalan). Silo menghasilkan dua kem dengan rasa simpati antara satu sama lain.
Pembangun tanpa pengetahuan pengeluaran lebih kerap menghasilkan kod yang tidak sesuai untuk pengeluaran, dengan menggunakan konfigurasi atau ciri yang belum ada di timbunan pengeluaran. Kerana mereka tidak mengetahui masalah lingkungan produksi, mereka membuat kod untuk melengkapkan fitur dan bukan menyebarkannya ke produksi.
Perincian kecil ini dapat menimbulkan kelewatan yang menyakitkan, yang diperburuk oleh trend menghantar pengurusan pelayan ke luar negara.
Fahami timbunan
Devops adalah bidang yang sangat besar, merangkumi penggunaan berterusan dan banyak automasi. Ini adalah ringkasan menyeluruh, tetapi perkara penting yang perlu difahami oleh pembangun ialah timbunan yang mereka jalankan. Tidak cukup untuk menyerahkan ini kepada pentadbir pelayan, anda harus memahami implikasi platform pada kod anda.
Sekiranya anda mengusahakan Rails, baca kod Rails dan ketahui bagaimana Ruby dilaksanakan oleh Apache. Sekiranya anda bekerja di Java, ketahui mengenai pilihan konfigurasi. Sekiranya Perl anda gunakan, fahami cara memasang modul Perl dan konfigurasikannya.
Kerja misteri
Senarai 'apa yang kami gunakan' mengandungi banyak perkara ini, dan pembangun yang baik memanfaatkannya untuk memahami bagaimana semua kerja misteri ini dilakukan. Dan setelah mereka mendapatkannya, penyebaran berjalan lebih cepat, kerja dikerahkan dengan lebih lancar dan semua orang akan lebih gembira.
Penyebaran berterusan dan amalan yang berkaitan dengan devops menjadi sangat standard sehingga mana-mana pemaju atau syarikat yang tidak mempraktikkan ini menetapkan diri mereka untuk diatasi. Orang lain akan mula melakukannya dan kemudian mereka akan lebih pantas daripada anda.
Alat yang berguna
Googling untuk 'devops' memberi anda idea tentang alat yang digunakan oleh lelaki ini. Ini bukan mengenai PHP dan MySQL, atau Rails. Ini mengenai perisian penghantaran dan menyimpan projek yang berisiko tanpa risiko. Mereka berkonsentrasi pada penggunaan, automasi dan menjaga saluran pipa dari pemaju ke lingkungan produksi berjalan secepat mungkin.
Anda akan dapati bahawa gaya pembangunan ini memberi anda pembangun yang bekerja lebih baik antara satu sama lain dan dengan jabatan dan syarikat lain. Sekiranya mereka bekerja dengan API dari pihak ketiga, mereka akan memahami masalah yang mungkin timbul di pihak lain. Semasa bekerja dengan pentadbir pelayan, mereka akan memahami apa yang mereka perlukan dan mengetahui bagaimana laman web perisian mereka di pelayan pengeluaran. Kebalikannya boleh menyakitkan ...
06. Dev akan memperbaikinya ... mungkin
Pencarian untuk 'kemahiran pemaju web penting' membawa jawapan yang bagus dari Michael Greer (The Onion's CTO) di Quora:
- Kemalasan: enggan melakukan apa-apa dua kali: menulis skrip atau algo untuknya.
- Pengecut: Berfikir untuk menguji, risau akan beban dan kesan kod
- Recklessness: Mencuba barang baru secara berterusan, melancarkan idea pada hari yang sama
Pengecut adalah cara yang baik untuk menyusun 'perhatian terhadap perincian'. Penyahpepijatan dan pengujian adalah 99 peratus dari kehidupan pengembang yang tidak disebutkan oleh seseorang ketika mereka mencecah W3Schools atau memulakan kursus pengkomputeran 101.
Keupayaan untuk memperbaiki aplikasi memerlukan kemahiran menyelesaikan masalah yang sangat baik, tetapi bukan hanya menyahpepijat kod. Kadang-kadang jalan keluar bagi pengguna yang tidak dapat memuat turun invois mereka adalah membuat halaman dapat dicetak, dan bukannya menghabiskan satu hari menghasilkan PDF. Kadang kala pautan dapat menggantikan pengembangan selama seminggu, tetapi penyelesaian yang elegan itu tidak akan berlaku jika para pemikir menyelesaikan masalah semata-mata dengan menulis banyak baris kod.
Ujian adalah titik penglihatan yang luar biasa bagi banyak pengguna, walaupun terdapat banyak alat di luar sana. Gunakan ujian unit, selenium, ujian beban dan alat profil seperti xhprof. Analisis dari perkara seperti Relik Baru untuk memastikan jejak aplikasi anda tetap kecil. Dan pertimbangkan ini semua bahagian tugas dev: ini adalah kod anda, pastikan anda tahu ia berfungsi seperti yang diharapkan dan bukannya berharap ia berlaku.
Menyahpepijat
Menyahpepijat juga menjadi masalah. Bukan cara menggunakan penyahpepijat, tetapi bagaimana cara men-debug masalah - jadi saya akan menambah senarai Michael Greer:
- Tidak sabar: secara agresif mengabaikan maklumat yang tidak relevan untuk mencari dan menyelesaikan masalah sebenar
Ini adalah tonggak semua teknik debugging. Mengabaikan yang tidak relevan dan mencari makna dalam yang relevan. Malangnya, banyak yang cenderung secara tidak sengaja memalu yang tidak relevan selama berjam-jam atau hari, menyelesaikan masalah dengan mencuba perkara yang sama 10 kali.
Terdapat banyak buku (sayangnya, bukan buku yang saya sampaikan kepada penerbit yang tidak akan saya namakan) mengenai penyahpepijatan dan setiap pembangun harus membaca semuanya. Seorang dev yang hebat dapat menyelesaikan masalah pada sistem tanpa melihat sebaris kod.
07. Apa yang pengguna mahukan
Fahami apa yang cuba dilakukan oleh orang sekeliling anda. Nikmati kodnya - cintai seni mengikat fail CSS dengan sempurna, atau mengoptimumkan aplikasi rel - tetapi ingat bahawa semuanya adalah untuk tujuan tertentu.
Pembangun perlu memahami perniagaan, operasi dan proses perniagaan kerana barang mereka membantu menjalankannya. Dev dengan pengetahuan ini dapat membina perisian dan aplikasi yang membantu pengguna, tetapi mereka sering kelihatan tidak produktif. Ini mungkin kerana pengetikan cepat mereka yang terang atau pengetahuan tentang timbunan yang luar biasa, tetapi kemungkinan besar disebabkan oleh pengetahuan mereka tentang kehendak pengguna.
Pasaran yang kompetitif
Kembali ke titik asal saya, perkembangan itu semakin mudah dan pasaran untuk pemaju hebat lebih kompetitif mana-mana pemaju yang dapat memahami keperluan perniagaan dan membawa sesuatu yang sangat baik untuk memenuhi mereka akan mempunyai kelebihan. Memahami pasaran, pelanggan dan mengapa mereka berpisah dengan wang semuanya membantu.
Fahami data dan bagaimana ia akan berubah dari masa ke masa. Dalam fikiran pemaju, mereka harus menyusun teknologi baru dengan cabaran yang anda hadapi sekarang atau lihat akan datang. Dengan cara ini, apabila anda mencadangkan idea baru yang menarik kepada MD atau kepada pelanggan, ia akan berdasarkan kepada apa yang sebenarnya pelanggan mahukan dan anda akan mendapat anggaran / masa untuk itu. (Sebaliknya, perkara terburuk untuk disaksikan adalah pembangun menjajakan teknologi kegemaran baru mereka sebagai penyelesaian untuk semua penyakit kita.)
Pembangun mempunyai banyak kawalan - adakah mereka perlu mengetahui maksud setiap bidang dalam pangkalan data untuk pengguna akhir? Sekiranya kita mengubah data, apa yang akan dilihat oleh pengguna? Adakah cara yang lebih baik untuk menolong pengguna? Terlalu kerap pandangan pentadbir DB adalah dunia adalah gambaran buruk dari pangkalan data mereka dan bukannya pangkalan data mereka menjadi perwakilan yang tidak baik dari dunia nyata. Dunia ini huru-hara dan sangat mengejutkan. Tangani, pentadbir DB.
08. Melukis dan menulis
Melukis adalah cara paling langsung untuk menyampaikan apa yang akan menjadi seperti itu. Pembangun mesti dapat menarik idea mereka di papan putih, kertas dan tikar bir.
Pembangun mesti dapat membuat prototaip di atas kertas, mencetak tangkapan skrin dan mencoretkannya hanya untuk menyampaikan maksud mereka. Jangan mempercayai pembangun yang mengangguk, mengatakan bahawa mereka memahami dan membuka editor mereka.
Gagal dengan murah: pengekodan terbaik bermula dengan melukis sebagai prototaip pantas. Gagal lebih kerap dan pastikan semua pengguna di sekitar anda melakukan perkara yang sama kerana anda lebih cenderung berjaya seperti itu.
09. Selamat mencuba
Dan bagaimana jika anda perlu menghabiskan 10 jam untuk menyelesaikan masalah dengan memindahkan pautan? Nikmati - walaupun hanya cabaran untuk menyelesaikan kerja.
Sikap paling teruk dari pemaju (atau sesiapa sahaja) adalah sikap tidak peduli terhadap apa yang cuba dicapai oleh pasukan. Sayangnya ini perkara biasa, kerana pembangun melihat diri mereka berada di luar pencapaian pasukan. (Pengaturcara Bersemangat mengemukakan soalan, "berapa banyak lagi keseronokan yang dapat anda lakukan?" - cubalah.)
Dan bersiaplah untuk menunjukkan karya anda kerana kebalikannya adalah: jangan berkembang setelah mencuba beberapa tutorial mengenai Ruby hingga 'Experience of Ruby'!
Pembangunan web dan aplikasi masih merupakan profesi muda, tetapi kumpulan kemahiran yang sangat diperlukan oleh para pengembang. Setiap orang harus mengharapkan lebih banyak pembangun kerana lebih cepat kita semua keluar dari ruang belakang yang tidak menyenangkan dan terlibat dengan proses kreatif semakin baik hasilnya.
10. Tetap tajam
Untuk mencapai ini ke pusingan 10 yang bagus, saya akan menambahkan satu perkara terakhir. Tetap tajam. Cari persaingan. Jenis terburuk adalah satu-satunya.
"Sentiasa jadilah lelaki terburuk dalam setiap kumpulan yang anda sertai."
Yang paling teruk - yang sangat buruk - pengaturcara, pengkod, pereka mempelajari barang mereka dan bergantung pada kejayaan mereka. Tanpa alat pacu jantung, terlalu mudah untuk melambatkan dan tanpa melihat persaingan, menjadi kebiasaan untuk melihat diri anda melebihi purata.
Jadi, jadilah yang terburuk dengan mencari yang lebih baik. Sertailah projek di luar tempat kerja, sumbangkan dan cari maklum balas dan kritikan kerana semakin banyak kritikan yang anda perolehi, semakin sedikit orang yang akan memberi anda pada masa akan datang. Apabila anda meneka apa yang mereka mahukan lebih baik daripada yang ada, maka anda adalah pembangun ninja yang semua orang mahukan.
Dan Frost adalah pengarah teknikal syarikat web perkhidmatan penuh 3EV, rakan kongsi AWS rasmi. Dia telah bekerja di CMS dan pengembangan aplikasi web selama tujuh tahun.
Suka ini? Baca ini!
- Cara membina aplikasi
- Fon web percuma terbaik untuk pereka
- Ketahui apa yang seterusnya untuk Augmented Reality
