Là một công ty đặt hàng để chuyển sang một IDE nhất định là một lá cờ đỏ? [đóng cửa]

Gần đây tôi đã tham gia một khởi nghiệp đang phát triển nhanh chóng. Trong 3 tháng qua, nhóm phát triển đã tăng từ 4 lên 12. Cho đến bây giờ họ rất tự hào về những gì các nhà phát triển đã sử dụng để làm công việc của họ. Trên thực tế, một trong những điều ban đầu tôi thấy hấp dẫn về công ty là hầu hết các lập trình viên đều sử dụng Linux, hoặc bất kỳ hệ điều hành nào họ cảm thấy phù hợp nhất với nỗ lực của họ.

Bây giờ các đơn đặt hàng, không cần thảo luận, đã đi xuống rằng mọi người sẽ chuyển sang Eclipse. Một biên tập viên tốt. Tôi thích SublimeText2, nhưng đó chỉ là sở thích cá nhân của tôi.

Nói rõ hơn: chúng tôi là một nhóm JS sử dụng Backbone và Eclipse không giỏi trong việc hiểu mã Backbone. Điều này có nghĩa là những người trong nhóm sử dụng / tốt / IDE (PHP Storm), phải quay lại để thực hiện nhiều việc tìm kiếm-tìm-oh-chờ-ở-đâu-tôi-ba-bước-trước thay vì chỉ ctrl + nhấp và sử dụng lùi / tiến - có thể giảm năng suất bằng cách nói 15% và hưởng 50% ...

Đây có phải là một lá cờ đỏ? Có vẻ như việc kiểm soát một cách bất hợp lý và không hợp lý để nói với các nhà phát triển (không phải MS) những IDE hoặc bộ công cụ nào sẽ sử dụng nếu chúng đã ổn định và hoạt động hiệu quả.

"Bây giờ các đơn đặt hàng, không cần thảo luận , đã đi xuống rằng mọi người sẽ chuyển sang Eclipse."

Tôi nghĩ rằng đây là cờ đỏ thực sự. Nhóm của bạn là chuyên gia về phát triển phần mềm và là người chịu ảnh hưởng của quyết định, nhưng bạn vẫn chưa thể nói một từ nào trong cuộc thảo luận dẫn đến thứ tự này?

Nghe có vẻ như quản lý quá mức bởi các ông chủ tóc nhọn. Người / nhóm ra quyết định có cái nhìn sâu sắc có liên quan cho quyết định đó không?

Cho rằng những người ra quyết định đủ điều kiện cho một quyết định như vậy, không hỏi ý kiến ​​của nhóm nhà phát triển có ít nhất hai khuyết điểm:

• Nhóm không cảm thấy tham gia. Liên quan đến nhóm nên được ưu tiên cho quản lý. Tôi không muốn làm việc như một nhà phát triển ở đâu đó mà ý kiến ​​của tôi về các vấn đề trung tâm như IDE không đủ giá trị để thậm chí được yêu cầu. Cho rằng việc hỏi ý kiến ​​của ai đó và sau đó quyết định chống lại nó có thể tồi tệ hơn, nhưng trong trường hợp đó tôi mong đợi một lý do vững chắc cho quyết định đó.

• Quản lý, tuy nhiên có kinh nghiệm, không hoạt động 100% với việc phát triển mã cụ thể này. Giả sử rằng những người không có cái nhìn sâu sắc thú vị nào sẽ là ngây thơ. Tất nhiên có thể là do các nhà quản lý đã nghĩ về mọi thứ mà các nhà phát triển nghĩ ra, nhưng cách duy nhất để biết là hỏi.

Điều hợp lý là khi bạn làm việc cùng nhau trong một dự án chung, trên mỗi máy trạm, bạn có tất cả các công cụ có sẵn để chỉnh sửa / xây dựng / gỡ lỗi phần mềm của mình và mọi công cụ cốt lõi để thực hiện khoảng 90% sự phát triển được mọi người biết đến đội. Mục tiêu đó khó đạt được hơn nếu nhóm của bạn đang phát triển và mọi người sử dụng bộ công cụ yêu thích cá nhân của anh ấy - càng nhiều người, càng có nhiều ý kiến. Và công việc hành chính cũng trở nên dễ dàng hơn, nếu bạn không để số lượng công cụ phát triển hơn mức cần thiết.

Tất nhiên, nếu một nhà phát triển khăng khăng sử dụng trình soạn thảo yêu thích cá nhân của mình, điều đó có thể ổn miễn là anh ta có thể đảm bảo nguồn không trông hoặc hành xử khác trong trình soạn thảo chính của nhóm (trong trường hợp của bạn là Eclipse), vì vậy nếu dev B phải chỉnh sửa nguồn của dev A, dev B không nên buộc phải học trình soạn thảo yêu thích cá nhân của A để có thể thay đổi nguồn một cách hiệu quả. Nhưng hãy cẩn thận, nếu cả hai thỉnh thoảng phải làm việc cùng nhau trước cùng một màn hình (hoặc thực hiện một số chương trình cặp), mọi thứ thường dễ dàng hơn nếu cả hai trình soạn thảo được chọn đều được biết đến.

Đối với mục đích lập trình cặp, thật tuyệt nếu cả hai bên trước màn hình có các kỹ năng giống nhau khi sử dụng bàn phím. Thật tuyệt khi biết rằng, nếu dự án của bạn có nhu cầu cấu hình đặc biệt trong IDE, thì nó được cấu hình theo cách tương tự cho mọi người. Bắt đầu một nhà phát triển mới dễ dàng hơn khi mọi công cụ đều giống nhau.

Nhưng nếu bạn so sánh rằng chỉ cố gắng để có hiệu quả nhất, thì nó không thực sự xứng đáng

Vâng, đó là một chút cờ đỏ mà ban quản lý tự coi mình là người đánh giá tốt hơn về công cụ nào bạn sẽ làm việc hiệu quả hơn bạn.

Bản thân nó không phải là một lá cờ đỏ.

Đôi khi quản lý cần phải đưa ra quyết định . Bất kỳ vấn đề nào yêu cầu tiêu chuẩn hóa về một cái gì đó có xu hướng rơi vào thể loại đó. Tôi đã từng làm việc tại một khách hàng đã cho phép các tiêu chuẩn trôi dạt trong một vài năm và họ có hơn 20 công cụ SCM khác nhau. Những gì bắt đầu như sự lựa chọn độc lập của các nhóm phát triển khác nhau đã biến thành một cơn ác mộng hậu cần gây cản trở nghiêm trọng việc chia sẻ các kỹ năng và cộng tác trên mã trong toàn tổ chức. Bản dựng tích hợp đã ..... er ..... không tích hợp lắm .....

Hơn nữa, nó không thực tế hoặc cần thiết để tham khảo ý kiến ​​của mọi người cho mọi quyết định . Mức độ mà điều này cần phải được thực hiện phụ thuộc vào văn hóa của tổ chức và tầm quan trọng / phức tạp của quyết định. Thông thường, bạn sẽ có một trong những lựa chọn ít tham khảo ý kiến ​​sau:

1. Tự đưa ra quyết định, nếu bạn có đủ kiến ​​thức về ưu / nhược điểm và đó không phải là một quyết định đủ quan trọng để yêu cầu tư vấn rộng.
2. Tham khảo ý kiến ​​với một vài cá nhân quan trọng (có lẽ sẽ là nhà phát triển cao cấp đủ điều kiện nhất để đưa ra quyết định).
3. Nêu lên thực tế rằng bạn đang đưa ra quyết định cho tất cả những người có thể bị ảnh hưởng (email, cuộc họp tòa thị chính, cuộc họp nhóm). Nói những gì bạn nghĩ rằng quyết định đúng là nhưng bạn sẵn sàng thay đổi điều này nếu bằng chứng mới xuất hiện ngược lại. Mời mọi người tiến lên phía trước nếu họ có một số quan điểm quan trọng
4. Mời mọi người thành lập một nhóm nhỏ để xem xét các lựa chọn và đề xuất quyết định. Tùy chọn tốt nếu đó thực sự là một cuộc gọi thân thiết, bạn không biết câu trả lời và bạn muốn những người liên quan được mua vào quyết định.

Đối với một cái gì đó như công cụ dành cho nhà phát triển (là một vấn đề có thể gây tranh cãi) tôi có thể làm 2 theo sau là 3 hoặc 4. tức là chắc chắn sẽ có một số cá nhân tôi sẽ không nói chuyện riêng với mình về vấn đề này, nhưng mặt khác trong số những người chủ chốt sẽ có cơ hội đóng góp vào việc ra quyết định.

Đối với tôi, cờ đỏ thực sự sẽ xuất hiện nếu bạn cảm thấy mạnh mẽ rằng quyết định sai đã được đưa ra (sai == nó gây hại cho công ty thay vì chỉ là công cụ yêu thích của bạn sẽ không được chọn). Quản lý phản ứng thế nào khi bạn nêu ra vấn đề này:

• Quản lý tốt sẽ lắng nghe lập luận của bạn, cảm ơn bạn chân thành về phản hồi và xem xét lại vị trí của họ trong trường hợp bạn đã đưa ra những hiểu biết mới . Họ có thể vẫn không đồng ý với bạn và có thể tuân theo quyết định của họ, nhưng họ sẽ đánh giá cao rằng bạn đã nêu ra điều đó với họ và bạn có lịch sự khi nói lý do tại sao họ lại kiên định với quyết định của họ. Họ thậm chí có thể thay đổi cách họ đưa ra quyết định như vậy trong tương lai và nếu bạn đưa ra những điểm tốt có thể đưa bạn vào danh sách "những người thông minh để hỏi" của họ.
• Quản lý tồi sẽ nhận được sự phòng thủ, nói rằng "quyết định được đưa ra" và các chiến thuật khác như vậy để tránh phải đối mặt với thực tế là họ có thể đã đưa ra một quyết định sai lầm. Họ có thể xem bạn là một "kẻ gây rối". Công ty chịu đựng, cũng như niềm tin của bạn vào quản lý. Đây là một lá cờ đỏ thực sự! Ra ngoai trong khi bạn co thể!

Nếu bạn đang sử dụng maven hoặc một cái gì đó tương tự, bạn không nên sử dụng IDE nào. Có thể có trường hợp một người bị ràng buộc với một IDE cụ thể như nhật thực, nếu có các plugin mà bạn dựa vào.

Tôi nghĩ bạn nên có thể chọn IDE của riêng bạn, IDE mà bạn làm việc hiệu quả nhất. Tuy nhiên, như tôi đã nói, có những trường hợp sử dụng IDE chuẩn.

Tôi đã cài đặt IDE "bắt buộc của công ty", nhưng vẫn sẽ thực hiện hầu hết công việc của tôi trong bất kỳ IDE nào tôi muốn - không giống như bất kỳ ai có thể nói IDE được sử dụng để chỉnh sửa tệp nguồn.

Trên mặt trận IDE so với biên tập viên ... đối với hầu hết tất cả các ngôn ngữ, tôi cực kỳ thích một IDE (IntelliJ) vì có rất nhiều thứ có thể làm cho bạn hơn là một trình soạn thảo có thể. Có một số điều tôi hoàn nguyên về ST2 hoặc Emacs, nhưng đối với mã hóa hàng ngày, mặc dù tôi thích cả ST2 / Emacs đến mức nào, IDE hầu như luôn thắng.

Mỗi nhóm tôi từng tham gia đều có nhiều IDE và biên tập viên: Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine - đó chưa bao giờ là vấn đề. Không bao giờ.

Đối với tôi điều này nói lên một sự hiểu lầm ở cấp cao của tổ chức, như những gì thực sự quan trọng. Điều quan trọng là để cho các lập trình viên giỏi làm những gì họ cần làm và sử dụng các công cụ giúp họ thoải mái nhất. Tính đồng nhất của IDE có rất ít liên quan đến giao tiếp thực sự diễn ra về các câu hỏi thiết yếu về kiến ​​trúc đối tượng, kiểm tra đơn vị, thuật toán, v.v.

Có cùng IDE với anh chàng tiếp theo chỉ có nghĩa là cả hai chúng tôi đều biết cách duyệt mã với các phím tắt giống nhau và cách biên dịch / cấu hình của chúng tôi được thiết lập. Không ai trong số đó sẽ quan trọng khi nói về các vấn đề mã thực sự.

Hãy nhìn xem, nó có thể sống được, tùy thuộc vào các yếu tố khác tại công ty. Bạn luôn có thể sử dụng trình soạn thảo ưa thích của riêng bạn cho công việc hàng ngày. Và có thể nhóm của bạn đang làm những điều tuyệt vời khác tạo ra văn hóa tuyệt vời. Nhưng các IDE bắt buộc là một sai lầm rất lớn IMO. Đối với tôi, nếu tôi đang phỏng vấn với một công ty và họ thông báo cho tôi biết IDE nào tôi được phép sử dụng, tôi sẽ cảm ơn họ một cách lịch sự vì đã dành thời gian cho họ.

Trong cửa hàng Ruby của chúng tôi, có một khuyến nghị mạnh mẽ là sử dụng IDE mà hầu hết nhóm yêu thích (RubyMine), bởi vì chúng tôi biết nó thực hiện công việc và chúng tôi có thể dạy cho nhau các phím tắt, v.v.

Các nhà phát triển có thể tự do sử dụng một IDE khác, nhưng chúng tôi yêu cầu họ phải có kỹ năng vững chắc trong trình soạn thảo đó nếu họ chọn như vậy. Nếu chúng ta thấy ai đó đang vật lộn để điều hướng dự án của họ hoặc chỉnh sửa văn bản trong FooEdit tùy chỉnh của họ, thì đó là RubyMine cho họ.

Nếu một lập trình viên là một chuyên gia tại một IDE nhất định, thì họ nên sử dụng nó. Nếu họ không phải là chuyên gia tại bất kỳ IDE nào, có lẽ một hoặc hai điều rất phổ biến đối với ngôn ngữ lập trình của bạn hoặc trong nhóm của bạn và có lẽ họ nên học nó.

Bị buộc phải chuẩn hóa một IDE nghe có vẻ là một ý tưởng tồi tệ.

Những lý do để một công ty buộc một biên tập viên hoặc phần mềm cụ thể nói chung về các nhà phát triển của họ nên được kiểm tra. Sự hoang tưởng (có thể không phải là từ tôi đang tìm kiếm) trong tôi nghĩ rằng có thể có một số loại theo dõi năng suất được thêm vào nhật thực mà họ đang yêu cầu các nhà phát triển cài đặt. Một suy nghĩ ít hoang tưởng hơn (một lần nữa) sẽ là họ đã dành thời gian để thêm các công cụ xây dựng sản phẩm vào IDE này sẽ giúp mọi việc dễ dàng hơn nhiều nếu mọi người nhấn cùng một nút để kiểm tra và xây dựng nhánh mã của họ.

Dù sao, những gì tôi đang cố gắng nói có lẽ không chỉ đơn thuần là quan liêu, hay một phương pháp gây rối với những người đứng đầu các nhà phát triển.

Đây là một lá cờ đỏ khổng lồ. Mỗi công ty đều có một vài ý tưởng ngu ngốc như vậy, nhưng nếu những lá cờ đỏ khác cứ đến, hãy rời đi.

Rất dễ để động lực đằng sau một số quyết định bị lạc - đặc biệt là với đội ngũ đang phát triển nhanh chóng. Động lực để chuyển sang Eclipse có thể chỉ là thực tế là hầu hết các nhà phát triển dường như đang lãng phí rất nhiều thời gian chỉ để cấu hình IDE và rằng chỉ có chuyên môn hạn chế với công ty của bạn.

Tôi sẽ chỉ cần chuyển sang Eclipse để có nghĩa là bạn nên thiết lập Eclipse trong trường hợp cần thiết, nhưng tiếp tục công việc của bạn trong trình soạn thảo yêu thích của bạn. (Bạn có thể phải chuyển sang Eclipse dần dần nếu công ty của bạn bắt đầu triển khai các công cụ tuyệt vời trong Eclipse.)

Cờ đỏ: Tôi sẽ đợi nếu có thêm một vài mệnh lệnh phi lý như vậy trước khi lo lắng.

Một startup nói chung đang cố gắng duy trì sự nhanh nhẹn đủ lâu để tìm ra một mô hình kinh doanh bền vững. Một khi nó chỉ ra phần tiền, ban lãnh đạo sẽ tiến hành mở rộng quy mô kinh doanh. Đó là nói chung khi tất cả các nhân viên công nghệ đầu tiên bắt đầu rời đi, khi các quy trình kỹ thuật được thắt chặt.

Như bạn biết, bạn không biết mã nào sẽ thực sự làm cho đến khi bạn chạy nó. Turing đã chứng minh rằng trong những ngày đầu của máy tính. Điều này có nghĩa là không có bất kỳ thước đo ý nghĩa nào về năng suất khi viết phần mềm. Tuy nhiên, để quản lý thực hiện công việc của mình, năng suất phải rõ ràng. Vì bạn không thể đo mã (và mọi người đã thử - ví dụ như dòng mã), họ sẽ đo những gì họ có thể thấy. Các lập trình viên dễ đọc hơn phần mềm họ phát triển. Nhóm quản lý điển hình cố gắng kiểm soát các lập trình viên để làm cho những điều này trở nên rõ ràng đối với họ (thay vì thực hiện công việc thực sự của họ: tránh đường). Và bởi vì họ đo lường những điều sai, nó không hoạt động tốt.

Có nói rằng, bạn vẫn có thể đi một chặng đường dài với một đội ngũ lỏng lẻo. Đội ngũ phát triển của Github có khoảng 50 người và họ phá vỡ mọi quy tắc trong sách giáo khoa quản lý kinh doanh. Họ dường như đang làm tốt. Lỗi được cố định (cuối cùng). Các tính năng được thêm vào. Hỏa hoạn được đưa ra ngoài.

Lá cờ đỏ lớn là gì nếu họ đang cố gắng mở rộng mọi thứ mà không tìm ra cách kiếm tiền. Tại thời điểm đó, bạn phải tự hỏi bao nhiêu lựa chọn và khoản tài trợ không đầu tư của bạn thực sự có giá trị.

Chắc chắn đây là một ý tưởng tồi. Không thể tránh khỏi việc nhóm sẽ trở nên kém năng suất hơn vì họ phải học cách sử dụng các công cụ mới. Và thậm chí sau đó họ sẽ không được hiệu quả như với các công cụ mà họ đã grok .

Vì bản thân tôi đã thử nhiều công cụ khác nhau nên tôi luôn cảm thấy "trời ạ, trình chỉnh sửa này làm tôi khó chịu với <chèn một số lỗi / khác biệt từ công cụ ưa thích>". Vì vậy, nó cũng sẽ là một nhược điểm đạo đức.

Nhưng tất nhiên cũng có những ưu điểm để có cả một nhóm sử dụng các công cụ tương tự. Chia sẻ cấu hình, tập lệnh, plugin và tất cả những thứ đó. Điều này sẽ không thể xảy ra với sự đa dạng của các bộ công cụ.

Mặt khác, bit cuối cùng sẽ không cần thiết nếu mọi người sử dụng phần mềm ưa thích của mình. ;)

Bạn có thể "sử dụng" Eclipse trong khi vẫn gõ SublimeText2.

Điều này có nghĩa là đã cài đặt và cấu hình Eclipse cho các dự án của bạn và tăng tốc với nó để bạn có thể thoải mái sử dụng nó nếu, giả sử, lập trình cặp. Không ai sẽ (hoặc ít nhất nên) quan tâm đến trình soạn thảo nào bạn thực sự đã sử dụng để nhập một đoạn mã bạn đã cam kết miễn là duy trì thiết lập song song của bạn không chiếm một khoảng thời gian quá hạn và bạn không tự cắt đứt khỏi môi trường phát triển chuẩn.

Nếu bạn đang sử dụng Git và việc phân nhánh của bạn không hoạt động, bạn không cần phải sử dụng trình chỉnh sửa của nhau. Bạn chỉ có thể đẩy một nhánh và có một nhà phát triển khác kéo nó để nó hoạt động nếu anh ta thực sự không thể tìm ra bộ công cụ của bạn. Việc buộc tất cả mọi người sử dụng cùng một trình soạn thảo nghe có vẻ như một đơn đặt hàng của một số người đứng đầu doanh nghiệp muốn trông thông minh nhưng không thực sự hiểu cách các bạn vận hành.

Nếu bạn nghĩ về điều này từ quan điểm quản lý, lý do họ có thể làm điều này là để tuân thủ pháp luật. Công ty có trách nhiệm đảm bảo rằng mọi công cụ được sử dụng đang được sử dụng hợp pháp và cũng sẽ không mã hóa sản phẩm đang được phát triển. (Một số trình soạn thảo miễn phí cho sử dụng cá nhân, nhưng không miễn phí cho bất kỳ mục đích nào khác, v.v.) Để kiểm tra mọi công cụ mà mọi nhà phát triển có thể muốn sử dụng có thể tốn kém. Tôi đã thấy rằng trong các dự án có dòng thời gian eo hẹp, ban quản lý sẽ thận trọng về việc sử dụng công cụ / thư viện / vv nào để giảm thiểu những thay đổi sau này trong dự án được hướng dẫn bởi những người hợp pháp.

Trong các dự án bảo mật cao hơn, cũng có mối quan tâm về nơi các IDE lưu trữ các tệp tạm thời và thông tin nào được lưu trữ giữa các phiên.

Tất cả phụ thuộc vào lý do họ phải đề xuất Eclipse. Nếu các nhà phát triển gặp khó khăn trong việc thiết lập môi trường của họ bởi vì mọi người tổ chức mọi thứ khác nhau, có thể có một lý do để đề xuất một áo liền quần. Tuy nhiên, nếu mọi người đều vui vẻ và làm việc hiệu quả bằng bất cứ điều gì họ muốn, thì có rất ít lý do để áp đặt một sự thay đổi đối với một cái gì đó liên quan sâu sắc đến quá trình sáng tạo.

Eclipse không chỉ là một trình soạn thảo - bạn có thể tiếp tục sử dụng trình soạn thảo yêu thích của mình để chỉnh sửa mã của mình và dựa vào Eclipse để kiểm soát nguồn, gỡ lỗi và bất cứ điều gì khác mà quy trình công việc được ủy quyền của công ty muốn sử dụng.

Một điều cuối cùng - quá trình thực thi ở cấp độ này có thể cho thấy công ty dự định mở rộng nhóm phát triển và muốn có một chút cấu trúc nhất định để các đồng đội mới có thể làm việc nhanh hơn. Nếu bạn nghĩ Rails (hoặc Django) là một khung "có ý kiến", bạn sẽ nhận ra rằng cấu trúc giúp hiểu các ứng dụng mới dễ dàng hơn.

Cờ đỏ không nhiều đến mức một IDE / trình soạn thảo bị ép buộc đối với mọi nhà phát triển, nhưng quyết định này, và đặc biệt là quyết định sử dụng IDE / trình soạn thảo nào không được đưa ra bởi tất cả các nhà phát triển và có lẽ không ai trong số các nhà phát triển họ!?

Chắc chắn sẽ là tốt nhất cho các nhà phát triển để đạt được sự đồng thuận, đặc biệt bởi vì họ rõ ràng là đủ điều kiện tốt nhất cho quyết định (ít nhất là về trình soạn thảo / IDE). Có thể có lý do chính đáng để tuân thủ và quyết định đó nên cân nhắc ưu tiên của quản lý, nhưng trình soạn thảo / IDE nào phải là quyết định của tất cả các nhà phát triển.

Bắt 12 nhà phát triển bỏ một số phiếu sẽ dễ dàng. Chắc chắn có đủ thời gian để làm điều đó! Kết luận có thể đã gây đau đớn cho một số trường hợp và cuối cùng nó thậm chí có thể trở thành Eclipse, nhưng việc dán nhãn yêu cầu là "cờ đỏ" trong trường hợp đó sẽ gây tranh cãi hơn nhiều.