Làm thế nào chúng ta có thể làm cho thực tiễn phát triển phần mềm tốt nhất thú vị hơn với mọi người mà không có nền tảng phần mềm?


8

Nơi tôi làm việc có một vài nhà phát triển phần mềm có kinh nghiệm với nền tảng phần mềm, nhưng phần lớn các nhà phát triển là nhà vật lý hoặc nhà hóa học có kiến ​​thức về miền tuyệt vời nhưng kinh nghiệm hạn chế khi phát triển phần mềm chất lượng cao, có thể bảo trì. Để giải quyết điều này, chúng tôi đã bắt đầu điều hành các cuộc hội thảo và hội thảo thường xuyên.

Những chủ đề nào bạn nghĩ chúng ta nên thảo luận để giúp làm cho những người này phát triển phần mềm hiệu quả hơn?

Đặc biệt, chúng tôi đang đấu tranh để có được sự nhiệt tình cho các cuộc đàm phán này vì nhiều nhà phát triển không xem phần mềm là một chủ đề thú vị. Làm thế nào chúng ta có thể làm cho những điều này thú vị hơn với mọi người mà không có nền tảng phần mềm?

Cảm ơn


hãy để tôi nói lại rằng - Làm thế nào tôi có thể nói với các tài xế xe tải tham gia cuộc đua F1? (Có phải như thế này không)
Ayush G Lòng

Để giải thích tình hình của chúng tôi tốt hơn, chúng tôi đều là thành viên của một bộ phận phần mềm trong một tổ chức lớn. Lịch sử của công ty là khoa học trong quá khứ quan trọng hơn phần mềm, đó là lý do tại sao chúng ta có rất nhiều nhà phát triển phần mềm có nền tảng khoa học mạnh mẽ. Nhưng công ty đã thay đổi, hiện tại chúng tôi là công ty lớn hơn nhiều (từ ~ 40 nhà phát triển phần mềm đến ~ 250 trên 5 quốc gia) và hầu hết các thách thức chúng tôi có là phần mềm không dựa trên khoa học.
Andy Lowry

Câu trả lời:


4

Tôi nghĩ nó sẽ khó khăn, vì vậy hãy chuẩn bị cho một cuộc đấu tranh - nhưng không phải là không thể. Vào cuối ngày lập trình (đặc biệt là mã hóa không phải là cao bồi-hack'n) sẽ không cực kỳ thú vị với mọi người. Điều này đặc biệt đúng đối với những người đã làm việc trong một lĩnh vực đầy thách thức về trí tuệ và bổ ích theo đúng nghĩa của nó.

Trước hết hãy làm cho các cuộc nói chuyện và hội thảo trở nên thú vị - thực phẩm miễn phí (đảm bảo đó là thức ăn ngon!) Và các món ăn tương tự là một nơi tốt để bắt đầu. Cố gắng tạo ra một chút hài hước và, ít nhất là ban đầu, giữ cho chúng khá ngắn gọn và không chính thức như bạn có thể.

Thứ hai đảm bảo các cuộc đàm phán và hội thảo có liên quan. Cố gắng đừng làm cho chúng quá trừu tượng (ngay cả khi các khái niệm được đề cập là trừu tượng) và nếu bạn có thể có thể, hãy đảm bảo rằng chúng có thể thử những gì được đề cập. Thậm chí kiểm tra tốt hơn những gì họ đã thực hiện giữa các phiên và cung cấp phản hồi tích cực. Nếu chúng không liên quan và chúng không áp dụng những gì bạn đã thảo luận thì chúng sẽ (chính xác) xem chúng như một sự lãng phí thời gian.

Cuối cùng hãy thử giới thiệu một số tiêu chuẩn mã hóa cơ bản, tốt nhất là những tiêu chuẩn không quá xâm phạm vào cách chúng hoạt động. Nếu bạn đang ở trong thế giới .net, Resharper là một thứ tốt để bắt đầu vì nó sẽ cảnh báo về những thứ như quy ước đặt tên. Bạn có thể tiến xa hơn với StyleCop (có thể được tích hợp vào Resharper) - nhưng trước tiên hãy đảm bảo bạn tùy chỉnh quy tắc. Nếu bạn không ở .net thì tôi chắc chắn các công cụ tương tự sẽ tồn tại ở nơi khác. Nó không nhiều, nhưng đó là một sự khởi đầu.

Đừng mong đợi kết quả tức thì (ngoại trừ có thể là bất kỳ tiêu chuẩn mã hóa được thi hành tự động nào) - Tôi đã nghe 6, 9 và 12 tháng được băng bó trong thời gian để giới thiệu các thực tiễn tốt nhất.

Cho đến nay tôi chỉ lướt qua nó, nhưng dường như có một chút lời khuyên tốt, phù hợp, dành cho bạn trong cuốn sách sắp tới Lái xe Thay đổi Kỹ thuật .


Lời khuyên tuyệt vời, cảm ơn. Tôi vừa đọc xong bản beta mới nhất của Driving Technical Change, rất hữu ích và tôi khuyên bạn nên đọc nó.
Andy Lowry

5

Nếu các nhà hóa học và vật lý học này không chủ yếu là các nhà phát triển chuyên nghiệp và không có ý định trở thành như vậy, tôi sẽ đề nghị suy nghĩ khác về vấn đề này.

Các nhà phát triển "thực" nên cung cấp các môi trường dễ dàng để họ phát triển thành. Bạn nên cung cấp tư vấn và bạn nên cung cấp đánh giá ngang hàng về mã của họ với các khuyến khích mạnh mẽ để làm cho mã đủ tốt để vượt qua ngay từ đầu.

Nói cách khác, đừng coi họ là bằng nhau, nhưng hãy cung cấp tất cả những gì bạn có thể để họ vượt trội về những gì họ thực sự làm đó là thế mạnh của họ.


2

Tôi làm việc với các kỹ sư mạng rất thông minh, những người không phải là nhà phát triển và không muốn trở thành. Tôi có thể hiểu điều đó bởi vì tôi không muốn trở thành một kỹ sư mạng.

Những gì chúng tôi thấy rằng hoạt động tốt là cho kỹ sư và tôi làm lập trình nhóm. Chúng tôi đang ở các trang web riêng biệt, vì vậy chúng tôi nhận được trên điện thoại, mở một phiên chia sẻ màn hình thường bằng screenlệnh và phá mã.

Chúng tôi đã làm điều đó nhiều lần và cảm thấy nó hoạt động rất tốt. Tôi hiểu cách họ làm việc của họ tốt hơn và kỹ sư đang học cách chúng tôi viết mã có thể duy trì và kiểm tra.


1

Họ có vai trò gì trong công ty? Nếu bạn cần nhà phát triển, thì hãy để họ ra đi nếu họ không phải là nhà phát triển giỏi và không quan tâm đến việc trở thành nhà phát triển giỏi. Nếu họ được coi là nhà vật lý và nhà hóa học, bạn có thể điều hành các hội thảo, nhưng đừng hy vọng họ sẽ duy trì mức độ quan tâm cao. Nếu họ được coi là cả hai, hãy nâng cao kỳ vọng và đảm bảo rằng bạn trả đủ tiền để chứng minh họ đảm nhận vai trò của nhà phát triển phần mềm trong khi duy trì kiến ​​thức và kỹ năng tên miền phức tạp.

Trừ khi một phần vai trò được xác định của ai đó là trở thành nhà phát triển, họ có thể sẽ không bao giờ quan tâm đến việc phát triển phần mềm chất lượng cao. Chỉ vì ai đó đang tạo tập lệnh nhanh và hack không nhất thiết có nghĩa là họ thực sự muốn trở thành nhà phát triển phần mềm, nó chỉ là phương tiện để kết thúc, giống như một kế toán tìm ra các công thức Excel phức tạp. Nếu bạn cần phần mềm chất lượng cao, có thể bảo trì, thì các nhà phát triển phần mềm nên tạo ra nó.


1

cho họ thấy những lợi ích cho họ . nếu không, tại sao họ phải quan tâm?

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.