Apakah pesanan perusahaan untuk beralih ke IDE tertentu merupakan tanda bahaya? [Tutup]

80

Baru-baru ini saya bergabung dengan startup yang berkembang pesat. Dalam 3 bulan terakhir tim pengembangan telah berkembang dari 4 menjadi 12. Sampai sekarang mereka sangat laissez-faire tentang apa yang digunakan pengembang untuk melakukan pekerjaan mereka. Sebenarnya salah satu hal yang awalnya saya temukan menarik tentang perusahaan adalah bahwa kebanyakan programmer menggunakan Linux, atau OS apa pun yang mereka rasa paling sesuai dengan upaya mereka.

Sekarang pesanan, tanpa diskusi, telah turun bahwa setiap orang harus beralih ke Eclipse. Editor yang baik. Saya lebih suka SublimeText2, tapi itu hanya selera pribadi saya.

Untuk lebih jelasnya: kami adalah tim JS yang menggunakan Backbone dan Eclipse tidak pandai memahami kode Backbone. Ini berarti bahwa mereka yang ada di tim yang menggunakan / good / IDE (PHP Storm), harus kembali melakukan banyak pencarian-temukan-oh-tunggu-di mana-dulu-saya-tiga-langkah-lalu hal-hal yang lalu bukan hanya ctrl + mengklik dan menggunakan back / forward - mungkin mengurangi produktivitas dengan mengatakan 15% dan kenikmatan sebesar 50% ...

Apakah ini bendera merah? Tampaknya berubah-ubah dan mengendalikan secara tidak masuk akal untuk memberi tahu pengembang (non-MS) apa IDE atau perangkat-set untuk digunakan jika mereka sudah menetap dan produktif.

— Justin Alexander
sumber

7

Apa proses pembangunan Anda? Apa yang perlu di tempat untuk karakter yang Anda ketik menjadi kode biner untuk pergi ke pelanggan.

22

Ini adalah permulaan. Jika manajemen secara sepihak membuat keputusan seperti mempengaruhi pembangunan, tanpa diskusi, itu bisa menjadi bendera merah utama terlepas dari apa itu tentang.

— joshin4colours

29

Tidak - ada banyak alasan untuk pergi ke satu IDE: perizinan, proses, kontinuitas, konsistensi ...

— Wonko the Sane

55

Sebuah perusahaan yang sedang tumbuh mencoba untuk menetapkan standar sejak awal adalah perusahaan yang cerdas dalam buku saya (tidak peduli apa pun itu)! Letakkan semua orang di halaman yang sama dan bangun keahlian dengan IDE umum. Kemudian tim menjadi lebih efisien karena semua orang dapat saling membantu, dan dapat berbagi kode lebih mudah tanpa harus khawatir tentang lebar ruang tab, pengodean dan hal-hal seperti itu.

— Yanick Girouard

23

Eclipse adalah keseluruhan lingkungan, bukan hanya editor. Mungkin IT menemukan bahwa berurusan dengan setiap kepingan salju khusus di perusahaan yang sedang berkembang menjadi tugas besar dan berat dan ingin distandarisasi. Mungkin ada alat dalam manajemen ekosistem Eclipse yang ingin segera digunakan. Mungkin 12 editor pemformatan otomatis yang berbeda membuat Anda kehilangan repositori dan menyebabkan pembangunan lebih lanjut. Mungkin alat tanpa izin "dari rumah" khawatir manajemen yang tidak ingin digugat. Mungkin Anda orang baru, apakah Anda benar-benar berharap untuk dikonsultasikan mengenai IT luas dan keputusan pengembangan? Bisa jadi sejuta alasan, semua waras.

— Patrick Hughes

92

"Sekarang perintah, tanpa diskusi , telah turun bahwa setiap orang harus beralih ke Eclipse."

Saya pikir ini adalah bendera merah asli. Tim Anda adalah pakar dalam pengembangan perangkat lunak dan yang akan dipengaruhi oleh keputusan tersebut, namun Anda tidak dapat mengatakan sepatah kata pun dalam diskusi yang menghasilkan pesanan ini?

Kedengarannya seperti manajemen berlebihan oleh bos berambut runcing. Apakah orang / tim pembuat keputusan memiliki wawasan yang relevan untuk keputusan itu?

Mengingat bahwa para pembuat keputusan cukup memenuhi syarat untuk keputusan seperti itu, tidak meminta pendapat tim pengembang setidaknya memiliki dua kekurangan:

Tim tidak merasa terlibat. Melibatkan tim harus menjadi prioritas bagi manajemen. Saya tidak ingin bekerja sebagai dev di suatu tempat di mana pendapat saya tentang masalah sentral seperti IDE tidak cukup dihargai bahkan untuk diminta. Memang, meminta pendapat seseorang dan kemudian memutuskan untuk menolaknya mungkin lebih buruk, tetapi dalam hal ini saya mengharapkan alasan yang kuat untuk keputusan itu.
Manajemen, bagaimanapun berpengalamannya, tidak bekerja 100% dengan pengembangan kode khusus ini. Dengan asumsi bahwa orang-orang yang tidak memiliki wawasan yang menarik sama sekali naif. Tentu saja mungkin agar para manajer memikirkan segala hal yang diajukan para dev, tetapi satu-satunya cara untuk mengetahuinya adalah dengan bertanya.

— Gauthier
sumber

9

Omong kosong. Hanya karena tim tidak berkonsultasi bukan berarti atasan tidak tahu apa-apa. Sangat menarik sebagai pengembang non-Java, saya tahu Eclipse adalah IDE untuk menggunakan cukup banyak, tetapi tidak pernah mendengar tentang favorit OP sampai dia mempostingnya. Ini akan menjadi kesalahan untuk memungkinkan tim untuk melakukan standarisasi pada IDE yang tidak biasa, menciptakan masalah dengan merekrut pengembang baru lainnya.

— Andy

5

Sudahkah Anda mempertimbangkan bahwa "manajemen atas" mungkin pengembang senior? Beberapa organisasi memiliki banyak lapisan?

2

Anda terlalu banyak membaca ini. Manajemen mungkin memiliki masalah lain, seperti opsi dukungan, dan mungkin mengarah ke sesuatu yang cukup populer dengan biaya dukungan yang masuk akal (saya berbicara tentang insiden dukungan berbayar). Jika itu masalahnya, mungkin tidak ada pilihan lain, jadi apa artinya bertanya kepada pengembang? Juga, sudahkah Anda mencoba bahkan untuk sejumlah kecil (10-15) pengembang untuk menyetujui sesuatu? Ada alasan mereka mengatakan membuat pengembang setuju seperti menimbun kucing.

— Andy

3

@Andy Menimbun kucing itu mudah (berbicara dengan perawan tua mana pun), mendengarkan mereka adalah masalah lain. ; o)

— JW01

3

@ JW01 Ahh, saya salah kata. Tapi bukankah itu penggembalaan? :-)

— Andy

63

Adalah masuk akal bahwa ketika Anda bekerja bersama pada proyek bersama, bahwa pada setiap workstation Anda memiliki semua alat yang tersedia untuk mengedit / membangun / men-debug perangkat lunak Anda, dan bahwa alat inti untuk melakukan sekitar 90% dari pengembangan diketahui oleh semua orang di tim. Tujuan itu lebih sulit untuk dicapai jika tim Anda berkembang dan semua orang menggunakan perangkat favorit pribadinya - semakin banyak orang, semakin banyak pendapat. Dan pekerjaan administrasi menjadi lebih mudah juga, jika Anda tidak membiarkan jumlah alat tumbuh lebih dari yang diperlukan.

Tentu saja, jika satu pengembang bersikeras untuk menggunakan editor favorit pribadinya, itu boleh saja asalkan dia dapat memastikan sumbernya tidak terlihat atau berperilaku berbeda di editor utama tim (dalam kasus Anda Eclipse), jadi jika dev B harus mengedit sumber dev A, dev B tidak boleh dipaksa untuk mempelajari editor favorit pribadi A untuk dapat mengubah sumber secara efektif. Namun waspadalah, jika keduanya harus bekerja sama dari waktu ke waktu di depan layar yang sama (atau melakukan pemrograman berpasangan), seringkali lebih mudah jika editor yang dipilih dikenal oleh keduanya.

— Doc Brown
sumber

2

Pertama-tama, jarang sekali pengembang harus membuat perubahan pada mesin orang lain. Saya setuju dengan "semakin banyak orang, semakin banyak opini", tapi itu tidak masalah kecuali orang mencoba memaksakan pendapat pada orang lain. Sebagai sumber, semua proyek harus memiliki proses pembangunan satu perintah otomatis. Selama itu berhasil, dan kode mengikuti konvensi, tidak masalah orang IDE mana yang menggunakannya. Sebagian besar IDE bersifat intuitif untuk hal-hal sederhana (masing-masing memiliki manfaatnya sendiri untuk tugas yang lebih kompleks), sehingga pemrograman pasangan bukan masalah. Jika ada pertanyaan, pengembang yang menggunakan IDE dapat menjawab.

— Matthew Flaschen

Jika Anda berdua tahu bahasanya, melihat editor yang berbeda sebenarnya bukan masalah. Beberapa sintaks disorot secara berbeda dan nama file mungkin berada di tempat yang berbeda, tetapi tidak ada masalah kecuali Anda benar-benar menggunakan pengaturan pengembang lain.

— Izkata

30

Saya bekerja di google dan di tim khusus saya satu orang menggunakan Eclipse pada orang menggunakan intellij Saya menggunakan Emacs dengan mode jahat untuk meniru Vim dan satu orang menggunakan Vim sendiri. Kami bekerja dengan baik satu sama lain dan perbedaan alat tidak ada masalah. Memang membantu bahwa kita semua menggunakan sistem build yang sama dan memiliki panduan gaya yang ditetapkan untuk membaca kode tetapi itu tidak ada hubungannya dengan pilihan editor untuk setiap individu.

— Jeremy Wall

@JeremyWall: seperti yang saya katakan, mungkin ok, jika kode sumber Anda ditampilkan sama di semua editor yang Anda gunakan dan Anda tidak melakukan banyak pemrograman pasangan.

— Doc Brown

5

@JeremyWall: Hanya karena tim pengembang Anda dapat bekerja seperti itu, tidak berarti bahwa semua tim dapat bekerja seperti itu, dan pada kenyataannya, saya akan menganggap tim pengembang Google berada di luar norma.

— James P. Wright

25

Demi pemrograman berpasangan, alangkah baiknya jika kedua pihak di depan layar memiliki keterampilan yang sama saat menggunakan keyboard. Sangat menyenangkan mengetahui bahwa, jika proyek Anda memiliki kebutuhan konfigurasi khusus dalam IDE, maka itu dikonfigurasi dengan cara yang sama untuk semua orang. Memulai pengembang baru lebih mudah bila alatnya sama untuk semua orang.

Tetapi jika Anda membandingkannya dengan hanya berusaha menjadi yang paling efektif, maka itu tidak terlalu sepadan

— Espen Schulstad
sumber

7

+1 untuk memperhatikan manfaat dari lingkungan pengembangan yang serupa ketika pemrograman pasangan

— jcmeloni

1

+1. Saya sangat setuju. Bekerja dengan banyak pengembang, masing-masing memiliki alat dan cara pengkodean pilihan mereka sendiri dapat menjadi neraka! Misalnya, Anda mungkin ingin memaksakan spasi lebih dari tab, ukuran indentasi tertentu, dan pengkodean UTF-8 untuk semua sumber Anda. Saya harus melalui ini di tim saya sebelumnya dan kami harus membuat semua orang menggunakan IDE yang sama pada akhirnya tepat untuk alasan yang disebutkan di atas. Pengembang yang serius tidak perlu menghabiskan waktu lama untuk beradaptasi dengan IDE baru, jadi saya tidak melihat ada salahnya. Ini juga memudahkan anggota baru untuk mempercepat jika semua orang menggunakan alat yang sama.

— Yanick Girouard

@Yanick: Space over tabs, indent size, encoding ... Semua jenis parameter ini harus hidup dalam standar pengkodean, yang harus dipatuhi oleh semua pengembang. Tidak masalah bagaimana mereka ingin mematuhinya, bukan? Persyaratan pemformatan harus fokus pada hasil yang benar, bukan pada bagaimana mencapainya. Jika para pengembang perlu beralih IDE untuk mendapatkan format yang benar, maka saya tidak akan menyebut mereka "pengembang serius", maaf karena berani.

— Gauthier

18

Ya, itu sedikit tanda bahaya yang manajemen anggap sebagai penilaian yang lebih baik untuk alat mana yang lebih efisien daripada Anda.

— matt b
sumber

38

Sangat tergantung pada alasan MENGAPA IDE harus sama.

3

Kami tidak yakin dari pertanyaan siapa yang mengambil keputusan atau mengapa. Istilah "tanpa diskusi" dapat berarti bahwa mereka tidak termasuk orang baru.

— mhoran_psprep

3

Saya tidak memiliki perwakilan untuk mengundurkan diri, tetapi saya tidak setuju dengan perspektif ini. Bahkan jika alat yang diputuskan oleh manajemen sebenarnya bukan yang terbaik, itu akan lebih baik daripada tidak memiliki standardisasi. Jelas para devs tidak mampu mengambil keputusan tentang mana yang "terbaik", karena dibiarkan sendiri, mereka semua memilih alat yang berbeda . Sangat bodoh untuk mengklaim alat yang berbeda bekerja lebih baik dalam konteks yang berbeda, karena sebagian besar dari mereka tidak benar-benar menjadi lancar dalam banyak hal.

— FumbleFingers

4

"Jelas para devs tidak mampu mengambil keputusan tentang mana yang" terbaik ", karena dibiarkan sendiri, mereka semua memilih alat yang berbeda." Mereka memilih alat terbaik (paling produktif) untuk diri mereka sendiri . Setiap orang memiliki pengalaman dan pola kerja yang berbeda. Mereka semua bisa benar.

— Matthew Flaschen

2

@Andy Thats 'tidak benar-benar benar, seperti ketidaksepakatan Vim vs Emacs. Dan itu terutama editor teks, bukan IDE lengkap. Butuh waktu bertahun - tahun untuk meningkatkan kecepatan di lingkungan baru.

— Izkata

14

Itu bukan bendera merah itu sendiri.

Terkadang manajemen perlu mengambil keputusan . Setiap masalah yang memerlukan standardisasi pada sesuatu cenderung masuk dalam kategori itu. Saya pernah bekerja di klien yang membiarkan standar melayang selama beberapa tahun dan mereka memiliki 20+ alat SCM yang berbeda. Apa yang dimulai sebagai pilihan independen oleh tim pengembangan yang berbeda berubah menjadi mimpi buruk logistik yang sangat menghambat berbagi keterampilan dan kolaborasi pada kode di seluruh organisasi. Bangunan terintegrasi adalah ..... eh ..... tidak terlalu terintegrasi .....

Selain itu, tidak praktis atau perlu berkonsultasi dengan semua orang untuk setiap keputusan . Sejauh mana hal ini perlu dilakukan tergantung pada budaya organisasi dan pentingnya / kompleksitas keputusan. Biasanya Anda akan mengambil salah satu dari opsi yang kurang konsultasi ini:

Buat keputusan sendiri, jika Anda memiliki pengetahuan yang cukup tentang pro / kontra dan itu bukan keputusan yang cukup penting untuk memerlukan konsultasi luas.
Konsultasikan dengan beberapa individu kunci (yang mungkin akan menjadi pengembang senior yang paling memenuhi syarat untuk mengambil keputusan).
Angkat fakta bahwa Anda membuat keputusan untuk semua orang yang mungkin terpengaruh (email, rapat balai kota, rapat tim). Katakan apa yang menurut Anda keputusan yang tepat tetapi Anda bersedia mengubahnya jika bukti baru muncul sebaliknya. Undang orang untuk tampil secara individu jika mereka memiliki beberapa pandangan penting
Undang orang untuk membentuk sub-tim untuk meninjau opsi dan merekomendasikan keputusan. Pilihan yang bagus jika itu benar-benar panggilan dekat, Anda tidak tahu jawabannya dan Anda ingin orang-orang yang terlibat ikut serta dalam keputusan tersebut.

Untuk sesuatu seperti pengembang perangkat (yang merupakan masalah yang berpotensi diperdebatkan) saya mungkin akan melakukan 2 diikuti oleh 3 atau 4. yaitu pasti akan ada beberapa individu yang saya tidak akan berbicara secara pribadi tentang masalah ini, tetapi di sisi lain sebagian besar dari orang-orang kunci akan mendapatkan kesempatan untuk berkontribusi dalam pengambilan keputusan.

Bagi saya bendera merah yang sebenarnya akan ada jika Anda merasa sangat kuat bahwa keputusan yang salah telah diambil (salah == itu merugikan perusahaan daripada hanya alat favorit Anda yang tidak akan dipilih). Bagaimana manajemen bereaksi ketika Anda mengangkat masalah ini:

Manajemen yang baik akan mendengarkan argumen Anda, terima kasih dengan tulus atas umpan balik dan mempertimbangkan kembali posisi mereka jika Anda telah meningkatkan wawasan baru . Mereka mungkin masih tidak setuju dengan Anda dan mungkin berpegang teguh pada keputusan mereka, tetapi mereka akan menghargai bahwa Anda telah mengangkatnya dengan mereka dan apakah Anda dengan sopan mengatakan mengapa mereka tetap dengan keputusan mereka. Mereka bahkan mungkin mengubah cara mereka membuat keputusan seperti itu di masa depan, dan jika Anda membuat poin yang baik dapat memasukkan Anda dalam daftar "orang pintar untuk bertanya".
Manajemen yang buruk akan menjadi defensif, mengatakan bahwa "keputusan telah dibuat" dan taktik lainnya untuk menghindari menghadapi kenyataan bahwa mereka mungkin telah membuat keputusan yang salah. Mereka mungkin melihat Anda sebagai "pembuat onar". Perusahaan menderita, seperti halnya iman Anda dalam manajemen. Ini adalah bendera merah asli! Keluarlah selagi bisa!

— mikera
sumber

6

Ada perbedaan yang cukup besar dari ide / editor dan sistem scm atau build. dan ide / editor adalah untuk penggunaan pribadi dan biasanya dirancang untuk individu. Sistem scm atau build digunakan secara global oleh semua orang. Salah satu dari hal-hal ini membutuhkan manajemen yang tersentralisasi dan yang lainnya tidak.

— Jeremy Wall

2

Jawaban saya ditargetkan pada masalah manajemen daripada keputusan khusus pada IDE per se. Namun ada juga banyak alasan bagus untuk melakukan standarisasi pada IDE (misalnya keterampilan, pelatihan, biaya lisensi, efisiensi pemrograman pasangan, integrasi dengan alat-alat lain, kualitas keseluruhan IDE, biaya dukungan, kemudahan penyebaran). Dalam beberapa konteks, keputusan yang tepat adalah standardisasi - Anda salah jika Anda berpikir ini selalu dapat diserahkan kepada pilihan individu (bahkan jika ini adalah keputusan yang tepat dalam banyak situasi)

— mikera

2

@ Jeremy: Saya pikir perspektif Anda baik-baik saja untuk satu orang atau sekelompok peretas. Saya sangat bersimpati: Saya persis sama untuk proyek pribadi saya sendiri. Tetapi pendekatan itu tidak berskala pada konteks perusahaan yang lebih besar. Memiliki preferensi untuk alat tidak apa-apa, tetapi saya berharap pengembang profesional yang baik bersedia dan mampu belajar dan mengadopsi alat apa pun yang membuat organisasi paling efektif secara keseluruhan.

— mikera

3

Perspektif saya dibagikan oleh perusahaan saya Google yang tentu saja memenuhi syarat sebagai konteks perusahaan yang lebih besar. Saya setuju bahwa pengembang profesional yang baik harus mau belajar dan mengadopsi alat untuk membuat organisasi paling efektif secara keseluruhan. Saya tidak setuju bahwa ide atau editor bisa masuk ke dalam kategori itu.

— Jeremy Wall

2

Perusahaan yang keren dan hebat, dan Anda beruntung bisa bekerja di tempat yang mampu beroperasi sebagai "kelompok peretas kecil" di proyek yang relatif independen. Sayangnya, sebagian besar perusahaan besar tidak memiliki kemewahan itu. Pikirkan bank besar yang perlu merekrut dan melatih 100 coders Java entry-level di India untuk bekerja mempertahankan aplikasi call center. Mendorong mereka semua untuk menjadi kreatif dan memilih alur kerja IDE / build sendiri tidak akan berhasil.

— mikera

12

Jika Anda menggunakan pakar atau sesuatu yang serupa, tidak masalah dengan IDE mana yang Anda gunakan. Mungkin ada kasus di mana seseorang terikat pada IDE tertentu seperti gerhana, jika ada plugin yang Anda andalkan.

Saya pikir Anda harus dapat memilih IDE Anda sendiri, IDE yang paling produktif bagi Anda. Namun, seperti yang sudah saya katakan ada beberapa kasus di mana masuk akal untuk menggunakan IDE standar.

— Jarle Hansen
sumber

misalnya. jika Anda ingin melakukan ADF, maka JDeveloper adalah pilihan alami, plugin untuk id lain mungkin tidak memiliki semua fungsionalitas.

— Rohit Banga

11

Saya telah menginstal "mandat perusahaan" IDE, tetapi masih akan melakukan sebagian besar pekerjaan saya di IDE apa pun yang saya inginkan - tidak seperti orang dapat mengetahui apa yang digunakan IDE untuk mengedit file sumber.

Di IDE vs Editor depan ... untuk hampir semua bahasa, saya sangat lebih memilih IDE (IntelliJ) karena ada begitu banyak lagi yang bisa lakukan untuk Anda daripada editor kaleng. Ada beberapa hal yang saya kembalikan ke ST2 atau Emacs, tetapi untuk pengkodean sehari-hari, meskipun saya sangat menyukai kedua ST2 / Emacs, IDE hampir selalu menang.

— Dave Newton
sumber

1

Saya membantah pernyataan Anda bahwa IDE dapat melakukan lebih dari sekadar editor. Ada editor yang jelas lebih rendah, misalnya Anda tidak akan melakukan pengembangan serius dengan nano atau gedit, tetapi saya dapat kode lebih cepat di vim daripada saya, dan saya kira kebanyakan orang lain, bisa dalam IDE. Dan meskipun saya benci untuk membela emacs, saya yakin pengguna emacs yang berpengalaman lebih cepat dalam emacs daripada IDE juga.

— Kevin

1

@Kevin Sengketa pergi - Saya pengguna lama Emacs, dan menjadi lebih baik dengan ST2, dan tidak ada perbandingan. Lebih baik, penyelesaian lebih konteks-sensitif, integrasi debugging yang lebih ketat, tidak ada terlalu banyak hal yang saya berikan anggukan kepada editor teks. Beberapa bahasa memiliki tarif yang lebih baik daripada yang lain, misalnya, saya tidak akan membuat kode Java di Emacs cukup banyak, tidak peduli apa, untuk Ruby dan Python saya sekitar setengah dan setengah, tetapi IntelliJ memenangkan saya. Untuk mengedit teks yang sebenarnya , apakah itu kode atau tidak, saya menggunakan editor.

— Dave Newton

1

Saya tahu pertanyaan dan sebagian besar tanggapan diarahkan ke dunia Java, tetapi di sini di dunia Microsoft. NET, gagasan bahwa editor bisa lebih baik daripada IDE mainstream (Visual Studio) benar-benar terbelakang. Saya tidak akan menyewa .NET dev yang bersikeras menggunakan Notepad ++ di atas Visual Studio.

— Graham

11

Setiap tim yang pernah saya kunjungi memiliki beragam IDE dan editor: Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine - ini tidak pernah menjadi masalah. Tidak pernah.

Bagi saya ini berbicara dengan kesalahpahaman di tingkat tinggi organisasi, tentang apa yang benar-benar penting. Yang penting adalah membiarkan pembuat kode yang baik melakukan apa yang perlu mereka lakukan dan menggunakan alat yang membuat mereka paling nyaman. Keseragaman IDE sangat sedikit hubungannya dengan komunikasi nyata yang terjadi tentang pertanyaan-pertanyaan penting arsitektur objek, pengujian unit, algoritma, dll.

Memiliki IDE yang sama dengan orang berikutnya hanya berarti bahwa kita berdua tahu cara menelusuri kode dengan cara pintas yang sama, dan bagaimana kompilasi / konfigurasi kita diatur. Tidak ada yang akan menjadi masalah ketika berbicara tentang masalah kode nyata.

Lihat, itu layak huni, tergantung pada faktor-faktor lain di perusahaan. Anda selalu dapat menggunakan editor pilihan Anda sendiri untuk hal-hal sehari-hari. Dan mungkin grup Anda melakukan hal-hal hebat lainnya yang menciptakan budaya hebat. Namun, mandat IDE adalah kesalahan langkah IMO yang sangat besar. Bagi saya, jika saya mewawancarai sebuah perusahaan dan mereka memberi tahu saya IDE mana yang diizinkan untuk digunakan, saya akan berterima kasih dengan sopan atas waktu mereka.

— Dave Sims
sumber

8

Di toko Ruby kami ada rekomendasi yang kuat untuk menggunakan IDE yang dinikmati sebagian besar tim (RubyMine), karena kami tahu itu berfungsi dan kami bisa saling mengajarkan cara pintas dll.

Pengembang bebas menggunakan IDE yang berbeda, tetapi kami mengharuskan mereka untuk memiliki keterampilan yang solid dalam editor itu jika mereka memilihnya. Jika kami melihat seseorang yang berjuang untuk menavigasi proyek mereka atau mengedit teks di FooEdit kustom mereka, RubyMine untuk mereka adalah.

— triskweline
sumber

4

Jika seorang programmer adalah pakar di IDE yang diberikan, maka mereka harus menggunakannya. Jika mereka bukan ahli di IDE mana pun, mungkin ada satu atau dua yang sangat umum untuk bahasa pemrograman Anda, atau dalam tim Anda, dan mungkin masuk akal bagi mereka untuk mempelajarinya.

Terpaksa melakukan standardisasi pada IDE terdengar seperti ide yang buruk.

— Matt Rogish
sumber

2

Alasan perusahaan memaksa editor atau perangkat lunak tertentu secara umum pada pengembangnya harus diperiksa. Bagian paranoid (mungkin bukan kata yang saya cari) dari saya berpikir mungkin ada semacam pelacakan produktivitas yang ditambahkan ke gerhana yang mereka minta agar dipasang oleh pengembang. Pemikiran yang jauh lebih paranoid (lagi) adalah bahwa mereka telah menghabiskan waktu menambahkan alat pembuatan produk ke IDE ini yang akan membuat segalanya lebih mudah jika semua orang menekan tombol yang sama untuk menguji dan membangun cabang kode mereka.

Pokoknya yang ingin saya katakan adalah mungkin lebih dari sekadar birokrasi, atau metode mengacaukan kepala pengembang.

— Pykler
sumber

2

Ini adalah bendera merah besar. Setiap perusahaan memiliki beberapa ide bodoh seperti itu, tetapi jika bendera merah lainnya terus berdatangan, pergilah.

— taw
sumber

Tidak setuju. Banyak perusahaan besar membuat keputusan cepat, dan jika mereka membuat kesalahan maka dengarkan umpan balik dan lakukan iterate. Mereka tidak membuang waktu untuk terjebak dalam konsultasi tanpa akhir untuk setiap keputusan.

— mikera

2

Sangat mudah untuk motivasi di balik beberapa keputusan untuk hilang - terutama dengan tim yang berkembang pesat. Motivasi untuk pindah ke Eclipse mungkin hanya fakta bahwa sebagian besar pengembang tampaknya menghabiskan banyak waktu hanya mengkonfigurasi IDE dan bahwa hanya ada keahlian terbatas dengan perusahaan Anda.

Saya hanya akan mengambil perintah untuk pindah ke Eclipse untuk berarti bahwa Anda harus memiliki pengaturan Eclipse jika diperlukan, tetapi lanjutkan pekerjaan Anda di editor favorit Anda. (Anda mungkin harus pindah ke Eclipse secara bertahap jika perusahaan Anda mulai menggunakan alat keren dalam Eclipse.)

Bendera Merah: Saya akan menunggu jika ada beberapa pesanan irasional seperti itu sebelum khawatir.

— Vineet
sumber

1

Startup umumnya mencoba untuk tetap gesit cukup lama untuk mengetahui model bisnis yang berkelanjutan. Setelah mengetahui bagian uang, manajemen bergerak untuk meningkatkan bisnis. Itu umumnya ketika semua karyawan teknologi awal mulai pergi, karena proses rekayasa diperketat.

Seperti yang Anda ketahui, Anda tidak tahu kode apa yang sebenarnya akan dilakukan sampai Anda menjalankannya. Turing membuktikan hal itu di awal-awal komputasi. Ini berarti bahwa tidak ada yang namanya ukuran produktivitas yang berarti dalam hal menulis perangkat lunak. Namun, bagi manajemen untuk melakukan tugasnya, produktivitas harus dapat dibaca. Karena Anda tidak dapat mengukur kode (dan orang-orang telah mencoba - baris kode, misalnya), mereka akan mengukur apa yang dapat mereka lihat. Pemrogram lebih terbaca daripada perangkat lunak yang mereka kembangkan. Tim manajemen tipikal berupaya mengendalikan programmer untuk membuat hal-hal ini dapat dibaca oleh mereka (alih-alih melakukan pekerjaan nyata mereka: menyingkir). Dan karena mereka mengukur hal-hal yang salah, itu tidak berfungsi dengan baik.

Karena itu, Anda masih bisa pergi jauh dengan tim yang longgar. Tim pengembangan Github memiliki sekitar 50 orang dan mereka melanggar setiap aturan dalam buku teks manajemen bisnis. Mereka tampaknya baik-baik saja. Bug diperbaiki (akhirnya). Fitur ditambahkan. Api bisa padam.

Apa yang dimaksud dengan bendera merah besar adalah jika mereka mencoba meningkatkan skala tanpa mengetahui cara menghasilkan uang. Pada titik itu, Anda harus bertanya-tanya berapa banyak opsi dan hibah yang tidak Anda investasikan benar-benar bernilai.

— Ho-Sheng Hsiao
sumber

Ini sepertinya sama sekali tidak berhubungan dengan pertanyaan. Apakah Anda bermaksud memposting di tempat lain?

— Daenyth

@Daenyth maksud saya memposting di sini. Judul asli "Satu IDE untuk mengatur semuanya?" tidak ada hubungannya dengan paragraf penjelasan. OP tampaknya bertanya apakah dipaksa menggunakan IDE menunjukkan waktu untuk menyelamatkan perusahaan.

— Ho-Sheng Hsiao

1

Tentunya ini adalah ide yang buruk. Tidak dapat dihindari bahwa tim akan menjadi kurang produktif karena mereka harus belajar menggunakan alat baru. Dan bahkan saat itu mereka tidak akan seefektif dengan alat yang sudah mereka grok .

Karena saya sudah mencoba berbagai alat sendiri, saya selalu merasa bahwa "ya ampun, editor ini mengganggu saya dengan <memasukkan beberapa bug / perbedaan dari alat yang disukai>". Jadi itu akan menjadi kelemahan moral juga.

Tapi tentu saja ada juga pro untuk membuat seluruh tim menggunakan alat yang sama. Berbagi konfigurasi, skrip, plugin, dan semua hal semacam itu. Yang tidak mungkin dilakukan dengan beragam toolset.

Di sisi lain ... bit terakhir tidak akan diperlukan jika semua orang menggunakan perangkat lunak pilihannya. ;)

— noxoc
sumber

0

Anda dapat "menggunakan" Eclipse sambil mengetik di SublimeText2.

Ini berarti memiliki Eclipse diinstal dan dikonfigurasi untuk proyek Anda dan mempercepat dengan itu sehingga Anda sama-sama nyaman menggunakannya jika, katakanlah, memasangkan pemrograman. Tidak ada yang akan (atau paling tidak seharusnya) peduli editor apa yang sebenarnya Anda gunakan untuk mengetikkan kode yang Anda komit selama mempertahankan pengaturan paralel Anda tidak memakan waktu yang tidak semestinya dan Anda tidak memotong diri dari lingkungan pengembangan standar.

— Tiberiu Ana
sumber

0

Jika Anda menggunakan Git dan percabangan Anda sedang down, Anda tidak perlu menggunakan editor satu sama lain. Anda bisa mendorong cabang dan dev lain menariknya untuk membuatnya bekerja jika dia benar-benar tidak bisa mengetahui toolset Anda. Memaksa semua orang untuk menggunakan editor yang sama terdengar seperti perintah oleh beberapa kepala bisnis yang ingin terlihat pintar tetapi tidak benar-benar mengerti cara kalian beroperasi.

— tubbo
sumber

0

Jika Anda memikirkan hal ini dari sudut pandang manajemen, alasan mereka melakukan hal ini adalah untuk kepatuhan hukum. Perusahaan bertanggung jawab untuk memastikan bahwa setiap alat yang digunakan digunakan secara legal dan juga tidak akan membebani produk yang sedang dikembangkan. (Beberapa editor gratis untuk penggunaan pribadi, tetapi tidak gratis untuk tujuan lain, dll.) Untuk mengaudit setiap alat yang mungkin ingin digunakan setiap pengembang bisa mahal. Saya telah melihat bahwa pada proyek-proyek di mana garis waktu sangat ketat, manajemen akan berhati-hati tentang alat / perpustakaan / dll mana yang digunakan untuk meminimalkan perubahan nanti dalam proyek yang diarahkan oleh orang-orang hukum.

Pada proyek keamanan yang lebih tinggi ada juga kekhawatiran di mana IDE menyimpan file sementara, dan informasi apa yang disimpan di antara sesi.

— SammyO
sumber

0

Itu semua tergantung pada alasan mereka harus merekomendasikan Eclipse. Jika pengembang mengalami kesulitan mengatur lingkungan mereka karena semua orang mengatur berbagai hal secara berbeda, mungkin ada alasan untuk merekomendasikan straightjacket. Namun, jika semua orang bahagia dan produktif menggunakan apa pun yang mereka inginkan, ada sedikit alasan untuk memaksakan perubahan pada sesuatu yang begitu terlibat dalam proses kreatif.

Eclipse jauh lebih dari sekadar editor - Anda dapat tetap menggunakan editor favorit Anda untuk mengedit kode Anda dan mengandalkan Eclipse untuk kontrol sumber, debugging, dan apa pun yang ingin digunakan oleh alur kerja yang diamanatkan oleh perusahaan.

Satu hal terakhir - proses penegakan di tingkat ini dapat menunjukkan perusahaan bermaksud untuk memperluas tim pengembangan dan ingin memiliki sedikit struktur tertentu di tempat sehingga rekan tim baru bisa menjadi produktif lebih cepat. Jika Anda menganggap Rails (atau Django) sebagai kerangka kerja "pendapat", Anda akan menyadari memiliki struktur membantu untuk memahami aplikasi baru dengan lebih mudah.

— kasar
sumber

0

Bendera merah tidak begitu banyak bahwa IDE / editor tunggal dipaksakan pada setiap pengembang, tetapi bahwa keputusan ini, dan terutama keputusan di mana IDE / editor akan digunakan tidak dibuat oleh semua pengembang, dan mungkin tidak ada mereka!?!

Tentu akan lebih baik bagi para pengembang untuk mencapai konsensus, terutama karena mereka jelas-jelas memenuhi syarat untuk keputusan (setidaknya pada editor / IDE mana). Mungkin ada alasan yang baik untuk menyesuaikan dan bahwa keputusan harus mempertimbangkan preferensi manajemen, tetapi editor / IDE mana yang seharusnya menjadi keputusan semua pengembang.

Mendapatkan 12 pengembang untuk memberikan suara akan mudah. Tentu saja ada cukup waktu untuk melakukan itu! Kesimpulannya mungkin akan menyakitkan untuk beberapa hal dan itu mungkin bahkan akhirnya menjadi Eclipse pada akhirnya, tetapi label persyaratan sebagai "bendera merah" dalam kasus itu akan jauh lebih bisa diperdebatkan.

— ghbarratt
sumber