Bekerja sebagai pengembang tunggal: mendapatkan kode yang terlihat


39

Saya tidak punya pilihan selain bekerja sendiri, dan tidak dapat menemukan solusi yang memadai untuk memeriksa pekerjaan saya, memeriksa kewarasan, meminta seseorang untuk melakukan brainstorming ide, mendiskusikan praktik terbaik dan sebagainya.

Saya pikir saya akan mendapat jawaban melalui artikel Jeff Atwood: Dalam Pemrograman, One Is The Loneliest Number , yang terbaik yang bisa saya temukan pada subjek, tetapi ternyata hanya mengulangi pertanyaan saya.

Saya tahu situs Stack Exchange seperti ini, dan Peninjauan Kode adalah jawaban potensial yang jelas, tetapi karena banyak yang akan menghargai, ini JAUH dari ideal:

Walaupun saya tidak dapat membuat daftar semua jebakan, seringkali, merumuskan pertanyaan dan memasukkannya ke dalam masalah yang mandiri seringkali membutuhkan begitu banyak pekerjaan sehingga pada saat Anda sudah mempersiapkannya dengan cukup, Anda telah menjawab pertanyaan Anda sendiri lebih lanjut waktu daripada yang seharusnya diambil sebaliknya. Selain itu, menyembunyikan detail untuk mengajukan pertanyaan yang jelas menghilangkan kemungkinan seseorang menemukan masalah yang tidak Anda pikirkan. Selain itu, walaupun saya tidak bisa mengikutinya, respon dari percakapan bebas tidak dapat ditandingi oleh segala bentuk diskusi internet tekstual yang dapat saya pikirkan. Terakhir tetapi tidak kalah pentingnya, saya tidak ingin memposting seluruh proyek saya untuk dunia untuk melihat sisa kekekalan, untuk alasan yang jelas.

Apakah ada jawaban selain membayar konsultan untuk memeriksa kode saya?


3
Saya memiliki masalah ini juga (dengan proyek yang menyenangkan), hanya saja saya cukup beruntung memiliki beberapa teman dekat programmer yang mau melihat-lihat kode saya.
Austin Hyde

23
Anda selalu bisa berbicara dengan diri sendiri - ini sangat baik untuk pemeriksaan kegilaan :-)
Danny Varod

4
Jika Anda mampu membelinya, ini adalah salah satu alasan mengapa baik untuk menyewa kantor / meja di taman bisnis (idealnya di mana orang-orang IT cluster). Saya memiliki banyak obrolan yang bagus dengan orang-orang IT di kantor tetangga saya ketika saya adalah seorang programmer yang bekerja di kantor.
JW01

6
Bekerja sendiri bisa lebih baik daripada bekerja dengan orang idiot.
Pekerjaan

2
Bukan benar-benar solusi, tetapi Anda dapat hang out di SO chat atau saluran IRC yang sesuai; yang mungkin meringankan beberapa beban bekerja sendiri.
Tikhon Jelvis

Jawaban:


36

Saya telah berada di posisi Anda dan saya pikir tidak ada solusi yang mudah. Membayar konsultan untuk memeriksa kode Anda bukanlah cara yang baik untuk menghabiskan uang. Jika masalah Anda adalah bahwa Anda merasa kesepian dan tidak memiliki siapa pun untuk diajak bicara tentang pemrograman maka saya tidak dapat membantu Anda di sana tetapi jika Anda benar-benar tertarik untuk meningkatkan kualitas kode Anda maka hal terbaik untuk dilakukan adalah mengaturnya samping dan kembali ke sana dalam seminggu atau lebih. Jika kodenya benar-benar buruk maka itu akan menjadi jelas karena Anda tidak akan dapat memahaminya dan Anda dapat mulai refactoring untuk masuk akal. Setelah beberapa iterasi dari proses ini, Anda akan mulai memperhatikan pola kode yang membuat kode mudah dipahami dan kualitas kode Anda akan meningkat.


Bagus ... 15
Marjan Venema

2
Secara teori ini bisa berhasil, dalam praktiknya TIDAK ADA JALAN DIA dia akan melihat kembali kode yang dia tulis 2 minggu lalu jika berhasil. Tidak juga seharusnya dia, mungkin .. Jika berhasil kembali untuk menghabiskan waktu di atasnya dengan satu-satunya alasan menjadikannya "lebih cantik" adalah buang-buang waktu, itu harus dilakukan kapan dan jika disentuh lagi.
Thomas Bonini

3
@ Krelp: Saya melihat kode masa lalu sepanjang waktu dan tidak ada cara Anda dapat menambahkan fitur dan secara umum memelihara perangkat lunak tanpa melihat kode yang ditulis sebelumnya. Tidak ada yang namanya arsitektur sempurna dan abstraksi yang bocor adalah aturan daripada pengecualian sehingga melihat kode yang ditulis sebelumnya tidak dapat dihindari. Saya tahu bahwa coders maraton diidolakan di kalangan pemrograman tetapi pengkodean maraton dengan cepat menyebabkan burnout dan membatalkan proyek sehingga di samping meningkatkan kualitas istirahat kode dan kembali juga membuat saya tetap waras.
davidk01

@david: Anda menyebutkan melihat kembali kode setelah waktu yang tetap, bahkan jika tidak perlu saat ini. Anda awalnya tidak mengatakan untuk melihat kembali kode hanya ketika Anda harus melakukannya untuk menambah fitur baru .. Jadi jika - sesuai dengan apa yang Anda katakan - pada akhirnya Anda harus melihat kembali semua kode lama, mengapa tidak melakukan jadi suatu saat itu relevan bukan setelah periode waktu yang tetap?
Thomas Bonini

3
@Krelp: Jika Anda cukup percaya diri pada kemampuan Anda, silakan saja dan hanya melihat kode yang berfungsi ketika Anda menyukainya tetapi jika Anda baru memulai dan tidak yakin seberapa baik Anda menyusun kode Anda kemudian terus mencari kembali pada apa yang Anda tulis beberapa minggu lalu dan refactoring itu adalah cara yang sangat baik untuk mempelajari struktur kode yang tepat. Saran saya adalah untuk orang yang ingin meningkatkan dan mencapai titik di mana restrukturisasi kode yang ditulis sebelumnya menjadi kurang dan kurang diperlukan karena versi awal memiliki struktur yang dapat diperluas yang tepat. Anda dipersilakan untuk mengabaikan saran saya.
davidk01

17

Apakah ada jawaban selain membayar konsultan untuk memeriksa kode saya?

Tidak.

Saran saya bergabunglah dengan grup pengembang \ pengguna lokal, dan bicarakan ide Anda dengan orang lain. Bicara tentang desain Anda. Tanyakan kepada orang lain bagaimana mereka telah mendekati masalah tertentu.

Jika mereka memverifikasi desain Anda, bahkan tanpa melihat kode Anda, itu harus cukup baik.


4
Banyak penulis profesional melakukan ini.
JeffO

10

Ada beberapa teknik pemeriksaan mandiri seperti pengembangan yang digerakkan oleh tes yang dapat membantu memberikan umpan balik. Ketika menjadi sulit untuk dilakukan, Anda tahu arsitektur Anda kemungkinan rusak.

merumuskan pertanyaan dan memasukkannya ke dalam masalah yang mandiri seringkali membutuhkan banyak pekerjaan sehingga pada saat Anda sudah mempersiapkannya dengan cukup, Anda telah menjawab pertanyaan Anda sendiri dalam waktu yang lebih lama daripada yang seharusnya diambil sebaliknya.

Masalah terpecahkan. Anda tidak perlu umpan balik eksternal pada setiap baris kode untuk meningkatkan, hanya sampel yang baik di persimpangan utama di jalan, dan hati-hati memeriksa di titik-titik di antaranya.

Anda harus melupakan gagasan bahwa Anda dapat mempertahankan tingkat kualitas yang sama dengan bekerja sendiri dalam jumlah waktu yang sama dengan seseorang yang bekerja dalam tim. Ada alasan orang bekerja dalam tim. Berita baiknya adalah Anda tidak memiliki konflik tentang keputusan desain. Berita buruknya adalah Anda tidak memiliki konflik tentang keputusan desain. Semoga waktu ekstra yang Anda habiskan untuk mempertahankan kualitas agak diimbangi dengan keuntungan bekerja sendiri.


Saya gagal melihat bagaimana TDD merupakan jawaban di sini.
Aaronaught

1
@Aronaught Saya berada di kapal yang sama dengan TS dan saya dapat meyakinkan Anda bahwa menulis tes (baik sebelum kode seperti dalam TDD atau setelah itu) adalah cara untuk memeriksa apakah kode Anda waras. Jika Anda tidak dapat mengujinya, itu buruk.
stijn

1
@stijn: Mungkin memang (agak) benar bahwa kode yang buruk lebih sulit untuk menulis tes, tetapi tidak pernah mustahil - begitulah sistem warisan ditingkatkan. Bahkan jika kami menerima pada nilai nominal klaim yang meragukan bahwa kode yang baik mengarah ke tes yang baik, klaim terbalik masih belum terbukti; tes kelulusan tidak berarti bahwa kode tersebut berkualitas baik. Bahkan, premis TDD - "merah, hijau, refactor" - pada dasarnya berarti menulis kode ceroboh yang lulus tes dan kemudian refactoring untuk meningkatkan kualitas, sehingga pada akhir hari Anda segera kembali ke tempat Anda mulai, hanya dengan tes.
Aaronaught

2
@Aaronaught: Anda benar-benar membuat poin yang valid, tetapi tetap saya mengerti bahwa tes adalah cara yang sangat baik untuk memeriksa kode kewarasan (meskipun bukan satu-satunya cara memang); pengalaman telah membuktikan saya demikian, ini sangat berguna untuk melihat di mana SRP dilanggar berat.
stijn

@ Mark: Itu bagus, tetapi semua anekdot ini bernilai bahkan kurang dari klaim iklan "Saya kehilangan 50 pound dalam 2 minggu", karena hal yang dibicarakan belum benar-benar diukur , apalagi diamati dalam kondisi terkendali. Ya, ada bukti bahwa TDD mengurangi cacat pra-rilis, dan itu bagus sekali; ulasan kode memecahkan masalah yang sama sekali berbeda dan tidak ada dasar untuk mengasumsikan bahwa TDD memecahkan masalah yang sama. Tes unit "Old-school" mungkin sebenarnya lebih baik untuk ini karena mereka menempatkan kendala testability pada kelas individu daripada kelompok mereka.
Aaronaught

6

Saya akan merekomendasikan melakukan sebanyak mungkin jejaring di konferensi dan grup pengguna lokal. Saya tahu banyak pengembang yang menembakkan kode sanitized bolak-balik melalui email atau im sepanjang waktu hanya untuk tetap tajam dan melihat-lihat algoritma bersama. Tidak, ini bukan percakapan tatap muka, dan ya itu kadang-kadang menyusahkan untuk membersihkan kode, tetapi tinjauan 20 kode pesan instan dari waktu ke waktu bisa sangat berguna, terutama ketika Anda sangat membutuhkan sepasang mata yang kedua.


4

Saya dalam situasi yang sama dan saya sangat bergantung pada Stack Overflow untuk mendapatkan umpan balik pada pertanyaan-pertanyaan degil. Saya juga menemukan berdasarkan benar-benar harus menuliskan deskripsi masalah yang jawabannya sering menjadi jelas. Dalam hal praktik terbaik, saya adalah pengembang .Net dan saya menggunakan ReSharper yang akan menawarkan saran alternatif praktik yang baik untuk kode yang saya tulis (yang kadang-kadang saya abaikan saja - ini bisa sedikit bertele-tele). Dan alat lain yang bermanfaat adalah FxCop yang akan melakukan analisis kode statis dan menyoroti setiap masalah yang tidak cocok dengan aturannya.

Kalau tidak, terserah Anda untuk membaca dan tetap mengikuti perkembangan praktik saat ini. Saya suka Morning Dew Alvin Ashcraft untuk tautan ke apa yang baru dan lebih baik di dunia .Net.


4

Saya sarankan mencoba membuat (atau menemukan) grup pengguna kecil. Jadikan kode Anda tersedia, dan buat semua orang berkomitmen untuk membuatnya berfungsi - setengah jam atau lebih setiap hari.


3

Umpan balik yang membangun dari pengalaman saya adalah bahwa selama tahun-tahun awal pengembangan Anda akan sangat penting meskipun tidak wajib bahwa pengembang yang berpengalaman meninjau kode Anda untuk meletakkan dasar. Setelah berpengalaman, Anda dapat mengikuti pendekatan yang disarankan oleh @ davidk01 yaitu Meninjau kode Anda sendiri secara berkala untuk meningkatkan kualitas kode.


2

Saya tidak tahu detail situasi Anda, tetapi di mana saya sekarang ada banyak siswa yang berpengalaman untuk lebih dari senang bekerja sebagai magang dan belajar sesuatu.

Mungkin terdengar pekerjaan ekstra bagi Anda untuk menangani mereka dan mengajari mereka ini dan itu, tetapi kami sudah ada di sana ketika kami pertama kali memulai dan saya kira ini giliran kami untuk membayar kembali.

Mereka bukan ahli dan kadang-kadang mereka mungkin menyesatkan Anda, tetapi biasanya mereka menantang segalanya dan penuh dengan ide dan bagus untuk diskusi di mana Anda harus mempertahankan setiap detail kode Anda.


2

Walaupun saya tidak dapat membuat daftar semua jebakan, seringkali, merumuskan pertanyaan dan memasukkannya ke dalam masalah yang mandiri seringkali membutuhkan begitu banyak pekerjaan sehingga pada saat Anda sudah mempersiapkannya dengan cukup, Anda telah menjawab pertanyaan Anda sendiri lebih lanjut waktu daripada yang seharusnya diambil sebaliknya.

Saya mengalami hal yang sama untuk> 75% pertanyaan yang saya posting.

Namun, itu bukan argumen untuk tidak repot-repot melakukannya. Ini adalah debugging bebek karet yang efektif. Anda menemukan jawaban untuk pertanyaan yang menurut Anda mungkin muncul sebagai jawaban atas pertanyaan Anda; yang berarti Anda memikirkan masalah dari sudut pandang orang yang berbeda; yang berarti Anda memikirkan masalah dari semua arah yang mungkin; yang merupakan cara terbaik untuk menemukan cacat.

Paling-paling, Anda telah membuktikan secara meyakinkan bahwa Anda jelas tidak dapat memikirkan jawabannya di sini. Pada "terburuk", Anda akhirnya menjawab pertanyaan Anda sendiri. Pikirkan kutipannya, karena ini tidak buruk sama sekali. Itu mungkin sedikit waktu tidak efisien, tetapi menyelesaikan masalah secara perlahan lebih baik daripada dengan cepat memutuskan untuk tidak mengatasi masalah . Anda akan lebih cepat menyelesaikan masalah pada akhirnya.

Inti masalah:

Ketika saya adalah seorang pengembang pemula, saya berurusan dengan halaman eror ASP.Net banyak kali. Saya perlu Google pesan untuk mencari tahu apa yang salah. mungkin butuh beberapa jam sebelum saya mendapatkan solusi yang tepat. Saya pada dasarnya membuat setiap kesalahan dalam buku ini dan kemudian harus berurusan dengan konsekuensi harus men-debug masalah.

Sekarang, ketika kesalahan muncul, saya sudah tahu "tersangka biasa" apa yang bisa menyebabkan masalah. Daftar mental saya "tersangka biasa" secara efektif didasarkan pada masalah yang paling banyak saya alami selama karier saya. Tanpa terlebih dahulu melakukan pekerjaan kaki yang tidak efisien dari Googling selama berjam-jam, saya tidak akan pernah membuat daftar mental ini . Tetapi sekarang karena saya memiliki daftar mental itu, saya lebih cepat dalam pemecahan masalah.


Selain itu, walaupun saya tidak bisa mengikutinya, respon dari percakapan bebas tidak dapat ditandingi oleh segala bentuk diskusi internet tekstual yang dapat saya pikirkan.

Saya agak tidak setuju di sini. Anda benar bahwa komunikasi internet kurang responsif, tetapi Anda (menurut saya) salah bahwa ini buruk bagi Anda.

Sebagai pengembang tunggal, Anda akan bergantung pada debugging bebek karet. Bahan utama untuk membuat RDD berfungsi adalah bahwa Anda mengantisipasi pertanyaan yang mungkin dimiliki bebek karet untuk Anda. Anda jelas tidak bisa mengandalkan apa yang sebenarnya dikatakan oleh bebek karet.

Ketika berhadapan dengan sistem pesan yang lambat (memposting di StackOverflow atau berkomunikasi dengan menulis surat), Anda secara inheren diberi insentif untuk memastikan bahwa Anda melakukannya dengan benar pertama kali. Karena perlu memperbaiki kesalahan akan menjadi proses yang lambat dan sulit.
Sebagai perbandingan, pertimbangkan sistem pengiriman pesan cepat (percakapan, pengiriman pesan instan), Anda dapat segera memperbaiki sesuatu. Kemampuan untuk mengoreksi sesuatu dengan cepat membuat orang kurang mendapat insentif untuk memastikan bahwa itu benar.

Empat kasus dalam poin:

  • Ketika saya membuat daftar analisis / catatan pribadi saya sendiri sebagai pengembang, saya masih menggunakan pena dan kertas. Saya perhatikan bahwa saya mengabaikan asumsi dan kepalsuan ketika saya mengetik catatan saya, karena pikiran saya berpikir bahwa "Saya dapat dengan mudah memperbaikinya nanti". Namun, harus mengoreksi sesuatu yang Anda tulis di kertas itu menjengkelkan, Anda harus mencoret hal-hal dan menulis yang tersirat dan dokumen terlihat jauh lebih buruk ketika ada tulisan di atasnya. Menulis di atas kertas membuat saya memeriksa fakta sendiri sebelum saya berkomitmen untuk menulisnya. Ini menangkap banyak kesalahpahaman awal, sebelum saya bahkan menulis kode yang akan menghasilkan bug.
  • Nenek saya adalah seorang sekretaris (usia mesin tik). Membuat kesalahan ketik pada dokumen formal berarti harus mengetik seluruh halaman lagi. Bibiku adalah seorang sekretaris (usia pengolah kata). Dia dapat mengandalkan pemeriksa ejaan otomatis, dan kesalahan dapat diperbaiki dengan mudah dan dengan sedikit usaha. Tidak mengherankan, nenek saya membuat kesalahan pengetikan dan kesalahan pengejaan yang jauh lebih sedikit dibandingkan dengan bibi saya.
  • Video game dulu dicetak pada kartrid. Memperbaiki bug setelah rilis tidak mungkin dilakukan. Anda perlu mencetak ulang semua kartrid, mendistribusikannya ke semua vendor, dan berharap vendor entah bagaimana dapat menghubungi pelanggan yang sudah membeli permainan. Itu akan menelan biaya banyak uang (dua kali lipat dari biaya produksi fisik) dan masih belum menjangkau beberapa pelanggan. Sekarang, di usia patch internet, pengembang game telah terbukti jauh lebih diinvestasikan dalam pengujian permainan mereka sehingga mereka dapat menghindari bug rilis hari, karena itu jauh lebih mudah untuk hanya mendorong perbaikan untuk setiap pelanggan secara langsung. Dampak dari membuat kesalahan diminimalkan ke titik di mana lebih baik untuk memperbaiki beberapa masalah setelah fakta, dibandingkan dengan harus menguji semua kemungkinan kesalahan yang bisa terjadi.
  • Saya dulu tinggal di apartemen lantai tiga, tidak ada lift, dan harus sering memarkir satu atau dua jalan dari gedung saya. Saya hampir tidak pernah lupa untuk mengambil sesuatu dari mobil saya. Sekarang, saya tinggal di sebuah rumah dengan mobil saya tepat di sebelah saya di jalan masuk. Saya lupa mengambil barang-barang dari mobil saya sepanjang waktu .

Gagasan yang mendasari di sini adalah bahwa sistem pertukaran yang sulit mendorong orang untuk melakukan pertukaran yang benar dan diperiksa fakta . Beratnya hukuman (= proses koreksi yang sulit) mengajarkan Anda untuk tidak membuat kesalahan.


Selain itu, menyembunyikan detail untuk mengajukan pertanyaan yang jelas menghilangkan kemungkinan seseorang menemukan masalah yang tidak Anda pikirkan.

Saat Anda membuat MCVE , Anda tidak harus membuatnya dan mempostingnya di pertanyaan. Pertama-tama Anda harus membuatnya sendiri , sehingga Anda dapat mengisolasi masalahnya. Dan kemudian, ketika Anda berpikir masalahnya tidak dapat dikurangi lagi, dan Anda masih tidak melihat penyebabnya; maka Anda memiliki pertanyaan yang valid untuk StackOverflow.

Inti masalah:

Saya selalu memiliki Visual Studio kedua yang berjalan dengan aplikasi konsol sederhana bernama Sandbox. Setiap kali saya mengalami masalah teknis, saya menyalin kode yang menyinggung ke dalam kotak pasir dan mulai bermain-main dengannya.

  • Apa yang terjadi ketika saya mengubah pengaturan ini?
  • Bisakah saya mereproduksi masalah jika saya mempersingkat kodenya?
  • Pengaturan mana yang memungkinkan / tidak mungkin mereproduksi masalah?

Dalam 90% kasus, saya menemukan penyebab masalah karena kotak pasir membantu saya melihat kode yang menyinggung tanpa terganggu oleh konteks sekitarnya (atau, misalnya, ketidakpastian tentang nilai yang datang untuk bagian kode yang berbeda.

Dalam 10% kasus lainnya, saya memiliki kode minimal untuk mereproduksi masalah, yang berfungsi sebagai contoh cuplikan sempurna untuk diposkan di StackOverflow.


Terakhir tetapi tidak kalah pentingnya, saya tidak ingin memposting seluruh proyek saya untuk dunia untuk melihat sisa kekekalan, untuk alasan yang jelas.

Ketika Anda sudah memiliki MCVE, Anda seharusnya tidak memiliki banyak informasi pribadi (atau perusahaan) di dalamnya. Jika ya, karena kodenya minimal, mudah untuk mengubah nama menjadi contoh foo / bar / baz yang lebih mendasar.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.