Đội của tôi nên bắt đầu từ đâu khi trở thành hiện đại [đóng cửa]


106

Tôi là một nhà phát triển tương đối mới, mới từ trường đại học. Khi còn học đại học và trong quá trình tìm việc sau đó, tôi nhận ra rằng có rất nhiều phương pháp phát triển phần mềm "hiện đại" mà giáo dục của tôi còn thiếu: kiểm thử đơn vị, ghi nhật ký, chuẩn hóa cơ sở dữ liệu, phát triển nhanh (so với khái niệm nhanh nhẹn chung), kiểu mã hóa hướng dẫn, tái cấu trúc, đánh giá mã, không có phương pháp tài liệu chuẩn hóa (hoặc thậm chí yêu cầu), v.v.

Nhìn chung, tôi không thấy đây là một vấn đề. Tôi mong đợi công việc đầu tiên của tôi sẽ nắm lấy tất cả những ý tưởng này và dạy chúng cho tôi trong công việc. Sau đó, tôi nhận được công việc đầu tiên của tôi (full chồng phát triển web) tại một tập đoàn lớn và tôi nhận ra rằng chúng tôi không có những điều này. Trong thực tế, tôi, người ít kinh nghiệm nhất trong nhóm, là người đi đầu trong nỗ lực đưa đội của tôi tăng tốc với các kỹ thuật lập trình "hiện đại" - vì tôi lo lắng rằng không làm như vậy là tự sát chuyên nghiệp.

Đầu tiên tôi bắt đầu với phần mềm ghi nhật ký (log4J), nhưng sau đó tôi nhanh chóng chuyển sang viết phần mềm theo phong cách của riêng mình, sau đó từ bỏ nó cho phần định kiểu của Google - và sau đó tôi nhận ra rằng việc phát triển web Java của chúng tôi đã sử dụng bộ điều khiển viết tay, vì vậy tôi đã thúc đẩy chúng tôi chấp nhận Spring - nhưng sau đó tôi nhận ra chúng tôi cũng không có bài kiểm tra đơn vị nào, nhưng tôi đã học Spring ... và như bạn có thể thấy, nó trở nên quá tải nhanh chóng, đặc biệt là khi kết hợp với công việc phát triển bình thường. Hơn nữa, thật khó để tôi trở thành "chuyên gia" đủ trong các phương pháp này để dạy cho bất kỳ ai khác trong chúng mà không dành quá nhiều thời gian cho một người trong số họ, chứ đừng nói đến tất cả.

Trong tất cả các kỹ thuật mà tôi thấy là "mong đợi" trong thế giới phát triển phần mềm ngày nay, làm cách nào để tích hợp chúng vào một đội như một người chơi mới mà không áp đảo cả tôi và đội?

Làm thế nào tôi có thể ảnh hưởng đến nhóm của mình để trở nên nhanh nhẹn hơn? có liên quan, nhưng tôi không phải là nhà phát triển Agile như người hỏi ở đây và tôi đang xem xét một bộ phương pháp rộng hơn nhiều so với Agile.


92
"Hiện đại"? Loại bỏ từ thông dụng "nhanh nhẹn" khỏi danh sách của bạn và tôi chỉ có thể thấy những thứ có tuổi đời> 20 năm.
Doc Brown

10
Có lẽ "hiện đại" theo nghĩa là việc áp dụng rộng rãi chúng là hiện đại, không phải là gen của ý tưởng? Tôi không phải là một chuyên gia về này thuộc một trong hai, đây chỉ là ấn tượng của tôi.
WannabeCoder

41
Tôi đảm bảo, bạn, kiểm tra đơn vị, ghi nhật ký, chuẩn hóa cơ sở dữ liệu, hướng dẫn kiểu mã hóa, kiểm tra mã (= đánh giá) đều cũ hơn 30 năm. Thuật ngữ "tái cấu trúc" ít nhất 15 năm tuổi (Fowler đã viết cuốn sách của mình vào năm 2000). Và không có tài liệu chính thức hoặc yêu cầu bằng văn bản không phải là "một kỹ thuật hiện đại", IMHO thậm chí không phải là một "kỹ thuật".
Doc Brown

69
@DocBrown thừa nhận điều đó, bạn vừa gửi Marty ngược thời gian để tạo tất cả những điều này trước khi đưa ra nhận xét của bạn.
null

17
Tôi lo lắng hơn rằng trường đại học của anh ấy không dạy những điều đó từ trước - tôi đã ra khỏi trường hơn 15 năm và hầu hết những điều đó được đề cập khá sớm. (Tất nhiên trừ buzzwords, tất nhiên).
Allen Gould

Câu trả lời:


165

Nghe có vẻ như bạn đang đặt xe ngựa trước ngựa.

Vấn đề chính mà nhóm của bạn đang gặp phải là gì và công nghệ nào sẽ giúp khắc phục nó?

Ví dụ: nếu có nhiều lỗi, đặc biệt là lỗi loại hồi quy, thì kiểm thử đơn vị có thể là điểm khởi đầu. Nếu nhóm của bạn thiếu thời gian, có lẽ một khung có thể giúp ích (trung hạn đến dài hạn). Nếu mọi người gặp khó khăn khi đọc mã của nhau, kiểu dáng có thể hữu ích.

Hãy nhớ rằng mục đích của doanh nghiệp bạn làm việc là để kiếm tiền chứ không phải để tạo mã.


35
Khá nhiều. Một phần từ quan điểm thực dụng là phải bắt đầu từ đâu đó và một phần từ điểm có uy tín rằng nếu bạn có thể khắc phục vấn đề cho nhóm, họ có thể sẵn sàng lắng nghe các đề xuất khác. Cũng nên nhớ rằng công ty này đã kiếm được tiền trước khi bạn đến với các phương thức hiện có của nó, vì vậy những gì bạn đặt ra phải tăng khả năng kiếm tiền của công ty.
Jaydee

6
Chấp nhận điều này, nhưng tôi sẽ đánh giá cao việc theo dõi để giải quyết các rủi ro của việc này một cách chuyên nghiệp (ví dụ: "sơ yếu lý lịch của tôi sẽ có nhiều thứ hơn, nhưng công việc cũ của tôi không chấp nhận thay đổi rất tốt.")
WannabeCoder

4
@WannabeCoder - Bạn phải bắt đầu sử dụng nó trước khi bạn thành thạo. Bạn vẫn có thể đưa mã vào sản xuất. Đôi khi mã hóa giống như là một bác sĩ y khoa. Tất cả chúng ta vẫn đang luyện tập.
JeffO

5
Câu trả lời chính xác. Bạn chỉ nên thực hiện những điều này để giải quyết vấn đề, không sản xuất vấn đề.
Kik

5
@WannabeCoder Điều quan trọng là phải nhận ra rằng không có phương pháp nào trong số những phương pháp này được tạo ra trong chân không. Chúng đang trở nên phổ biến rộng rãi vì chúng giúp giải quyết vấn đề . Nếu bạn cố gắng thực hiện chúng và chúng không giúp giải quyết các vấn đề mà nhóm của bạn đang gặp phải, thì bạn đã không làm được gì và có thể hoàn toàn hiểu sai và lạm dụng các thực tiễn. Trọng tâm của bạn là một nhà phát triển nên tập trung vào giải quyết các vấn đề trong mọi hành động bạn thực hiện. Tìm kiếm những chiến thắng nhỏ trong đó đưa các thực hành này vào vị trí chỉ một chút nữa sẽ cải thiện tình hình. Điều này giúp xây dựng một trường hợp để mở rộng chúng.
jpmc26

77

Java? Hiện đại?! Bạn đã thất bại ở rào cản đầu tiên. Nếu bạn muốn thực sự hiện đại và tránh "tự sát chuyên nghiệp" thì bạn phải viết mã Rust. Tất nhiên, tuần tới, tất cả sẽ thay đổi và bạn sẽ phải học một cái gì đó mới hơn để theo kịp!

Hoặc, bạn có thể chấp nhận rằng không có số lượng công nghệ từ thông dụng hoặc phương pháp hoặc khuôn khổ hoặc bất kỳ du jour nào khác sẽ thay đổi thực tế rằng bạn muốn xây dựng các sản phẩm chất lượng hoạt động. Sẽ không có vấn đề gì nếu bạn không sử dụng nhanh nếu bạn sản xuất đúng sản lượng. Tất nhiên, nếu bạn không phải, thì bạn có thể muốn thay đổi mọi thứ nhưng rất có thể không có thực hành cụ thể nào sẽ khắc phục được vấn đề. Chúng sẽ vẫn là những vấn đề của con người có thể được khắc phục theo bất kỳ cách nào khác nhau.

Đối với tự tử chuyên nghiệp, nếu bạn biết bạn đang làm gì và linh hoạt thì bạn không cần bất kỳ điều gì bạn đã đề cập. Mọi người sẽ tiếp tục nghĩ ra những cách mới để thực hiện công việc cũ và bạn sẽ luôn bắt kịp. Hoặc bạn có thể chỉ cần sử dụng bất kỳ kỹ thuật nào mà công ty hiện tại của bạn sử dụng bất kể. Khi bạn thay đổi công ty, bạn chỉ cần học và sử dụng các kỹ thuật họ sử dụng.

Quá nhiều trẻ em bị treo trên tất cả các công cụ mới mà chúng có thể sử dụng, quên rằng những công cụ này là vô dụng trong tay của một người mới. Trước tiên hãy tìm hiểu thực tiễn, khi bạn là nhà phát triển có kinh nghiệm, bạn có thể bắt đầu "sửa chữa" các thực tiễn phát triển bằng "những điều mới mẻ thú vị", nhưng sau đó bạn sẽ hy vọng rằng chúng không quan trọng như bạn nghĩ hiện tại và Chỉ được sử dụng khi chúng thực sự cần thiết.


4
Câu trả lời rất hay (+1), đặc biệt là đoạn cuối. Một cuốn sách rất hiện đại (hiện đại theo nghĩa mà tôi thấy nó rất phù hợp ngày nay) Tôi đang đọc gần đây là SICP.
Giorgio

1
+1 để đề cập đến việc những từ thông dụng và ngôn ngữ phổ biến này thay đổi nhanh như thế nào. Một nhà phát triển tốt đưa ra mã tốt hơn hẳn các phương pháp. Làm những gì hoạt động và làm việc tốt!
WeRelic

2
Mặc dù bạn đúng rằng những thứ này cần được sử dụng đúng cách, tôi không đồng ý với quan điểm rằng "chúng gần như không quan trọng như bạn nghĩ hiện tại." Được rồi, chắc chắn, điều đó có thể đúng với một số thực tiễn (tôi hơi nghi ngờ về thử nghiệm đơn vị.), Nhưng những thứ khác là vô cùng có giá trị. Tôi đã có cơ hội bắt đầu thực hiện nhiều CI và tự động hóa và sử dụng tốt việc kiểm soát nguồn từ sớm, và bây giờ làm việc trong một dự án không có mặt, tôi thấy tất cả các vấn đề chúng tôi muốn giải quyết trong hành động: sai lầm, mâu thuẫn , không ai biết mã ở đâu, công trình. Những thực hành đó làm cho một sự khác biệt rất lớn .
jpmc26

6
Không ai nói "không giải quyết vấn đề", vấn đề là khi các giải pháp được đưa ra nhằm tìm kiếm các vấn đề cần giải quyết. Chúng không quan trọng như nhiều người nghĩ, những người sùng bái hàng hóa nghĩ rằng các công cụ là phần quan trọng, nơi chúng thực sự chỉ là công cụ. Đó là học viên quan trọng, và bất kỳ công cụ nào làm việc ở đúng nơi là những công cụ để lựa chọn. Quan điểm của tôi là không bao giờ chọn một công cụ đơn giản vì nó nằm trong hộp công cụ.
gbjbaanb

2
Một kẻ ngốc với một công cụ vẫn là một kẻ ngốc.
Pete Becker

40

Nhiều công ty bị mắc kẹt như thế này; bạn thậm chí có thể ngạc nhiên khi thấy rằng một số đồng nghiệp phát triển của bạn tự học và trở thành nhà phát triển không có nền tảng chính thức nào. Những nhà phát triển này thường giỏi hơn trong công việc của họ, vì họ sẽ là những người được thúc đẩy để học các kỹ năng mới và thành công thay vì chỉ đơn giản là thực hiện công việc. Thật không may, điều này cũng có nghĩa là, trong khi họ xuất sắc trong lập trình, họ có thể không nhận thức được lợi ích của những thực tiễn này. Thực tế là đây là những thực tiễn tốt nhất , không phải thực tiễn phổ biến . Sử dụng tốt nhất chúng, nhưng chúng không phải là tất cả các yêu cầu để thành công, chúng chỉ đơn giản là công cụ để giúp thành công dễ dàng hơn.

Bạn hoàn toàn đúng, sẽ rất áp đảo khi cố gắng thực hiện tất cả mọi thứ cùng một lúc. Bạn có thể sẽ tự thiêu (và có thể nhóm của bạn) đang cố gắng làm điều đó, điều này sẽ làm mất đi những nỗ lực trong tương lai để áp dụng các phương pháp / công nghệ mới. Điều tốt nhất để làm trong tình huống như thế này là chọn mộtđiều (đăng nhập có lẽ là một khởi đầu tốt, vì có lẽ bạn đã có một con đường khó khăn phía trước để tìm lỗi mà không cần đăng nhập, và chắc chắn có lỗi) và nói chuyện với nhóm về nó. Bạn không phải tự tay thực hiện điều này; bạn sẽ thảo luận tốt hơn về những ưu và nhược điểm với nhóm (và ông chủ của bạn, người tuyệt đối PHẢI ở trên tàu với thứ gì đó như thế này) và đưa ra kế hoạch thực hiện nó. Sẽ không đau đớn nhất có thể (hãy nhớ rằng, bạn đang nói với mọi người rằng bây giờ họ phải viết thêm mã ngoài những gì họ đã làm).

Và hãy để tôi nói lại, hãy chắc chắn rằng sếp của bạn mua hàng . Điều này là rất quan trọng; bạn có thể sẽ thấy rằng tốc độ sửa lỗi / phát hành chậm lại khi bạn thực hiện những điều mới. Vấn đề là bạn đang trả tiền trước để tiết kiệm chi phí; họ PHẢI hiểu điều này và đứng về phía bạn. Nếu bạn không đưa họ lên máy bay, bạn sẽ chiến đấu một trận thua tốt nhất, và tệ nhất là họ có thể coi bạn là chủ động phá hoại đội (hỏi tôi làm sao tôi biết).

Một khi bạn mang những vật phẩm này đến bàn, thảo luận với nhóm, lên kế hoạch thực hiện chúng và làm theo, thứ hai, thứ ba, thứ tám, v.v. sẽ dễ dàng hơn. Không chỉ vậy, có một tiềm năng để nhóm và sếp của bạn có được sự tôn trọng dành cho bạn khi các đề xuất của bạn được thực hiện và được công nhận là tăng thêm giá trị. Tuyệt quá! Chỉ cần đảm bảo rằng bạn luôn linh hoạt: bạn đang chống lại quán tính ở đây và thay đổi không dễ dàng. chuẩn bị từ từ làm nhỏthay đổi và đảm bảo rằng bạn có thể theo dõi tiến trình và giá trị kiếm được. Nếu bạn thực hiện đăng nhập vào một quy trình mới và nó giúp bạn tiết kiệm hàng giờ để tìm ra lỗi trong ba tuần, hãy giải quyết vấn đề lớn! Hãy chắc chắn rằng mọi người đều biết rằng công ty chỉ tiết kiệm được $ XXX bằng cách làm điều đúng đắn trước thời hạn. Mặt khác, nếu bạn bị đẩy lùi hoặc có thời hạn chặt chẽ, đừng thử ép buộc vấn đề. Hãy để thay đổi mới trượt trong thời điểm này và quay lại. Bạn sẽ không bao giờ chiến thắng bằng cách cố gắng buộc nhóm làm điều gì đó mà họ không muốn làm và bạn có thể chắc chắn rằng điều đầu tiên họ sẽ đề xuất là công việc 'thêm' mới (như viết nhật ký hoặc theo dõi một phong cách thay vì chỉ "làm cho nó hoạt động").


6
Tôi nghi ngờ bạn có ý nghĩa nhiều với nó, nhưng tôi không hài lòng với những người như tôi mà không có giáo dục compsci đại học. Kinh nghiệm của tôi (khá không may) là giáo dục đại học có ít mối tương quan với chất lượng của nhà phát triển. Và cho đến nay trong sự nghiệp của mình, tôi là một trong những người ủng hộ và thực hiện các thực tiễn tốt nhất. Lời khuyên của bạn là tuyệt vời mặc dù.
djeikyb

5
Thật ra tôi có ý đó theo một cách khác: OP sẽ ngạc nhiên bởi có bao nhiêu nhà phát triển giỏi ở ngoài đó mà không có giáo dục chính thức. Nhiều vị trí công nghệ đã mở ra trong 20/30 năm qua được lấp đầy bởi những người sẵn sàng học thay vì trẻ em có bằng cấp. Và những phát hiện của tôi phản ánh của bạn: kinh nghiệm luôn tốt hơn giáo dục. Đó là lý do tại sao OP cần phải đi chậm ... thúc đẩy một nhóm áp dụng các thực hành mới quá nhanh sẽ khiến họ phẫn nộ và anh ta sẽ không có kinh nghiệm để làm dịu những thái độ đó. Cũng quan trọng để nhận ra là một số đội sẽ không bao giờ sử dụng các công cụ này; đó là khi bạn có một công việc mới.
DrewJordan

1
"Nhiều công ty bị mắc kẹt như thế này, bạn thậm chí có thể ngạc nhiên khi thấy rằng một số đồng nghiệp 'nhà phát triển' của bạn tự học và trở thành nhà phát triển không có nền tảng chính thức nào." Đây thường là những nhà phát triển có giá trị nhất do chuyên môn về miền của họ.
PMF

Phải, tôi hoàn toàn đồng ý. Phần thưởng cho đoạn đầu tiên để nó nghe có vẻ ít hơn. Tôi chỉ muốn chắc chắn rằng OP biết rằng một phần tốt của lực lượng lao động ngoài kia không thực sự có một nền tảng chính thức. Lựa chọn từ ngữ kém về phía tôi.
DrewJordan

18

Tôi hy vọng bạn đã không trình bày các vấn đề cho đồng nghiệp của bạn như bạn đã làm với chúng tôi trong bài viết của bạn. ĐÓ sẽ là tự sát chuyên nghiệp.

Vấn đề đầu tiên là bạn đang cố gắng dạy các công nghệ và phương pháp mà thậm chí bạn không có kinh nghiệm với một nhóm lập trình viên, có thể hơi lỗi thời, nhưng hãy hoàn thành công việc. Khả năng của phản ứng đó là vô tận, và có thể sẽ mang lại nhiều niềm vui cho đồng nghiệp của bạn. Thật thú vị và đáng ngưỡng mộ khi bạn muốn cải thiện bản thân và bộ phận của mình, nhưng tránh sử dụng các thuật ngữ như "mũi nhọn". Trân trọng, đừng sử dụng từ đó.

Là một vấn đề phụ ở trên, kiểm tra xem bạn đang làm một số công việc . Tôi đã làm việc như một lập trình viên đơn độc, tự học trong nhiều thời gian và tôi biết làm thế nào dễ dàng để dành công việc thực tế để khám phá các khuôn khổ, công nghệ đầy hứa hẹn và tương tự. Đảm bảo rằng hiệu suất của bạn nằm trong các tham số dự kiến ​​(không, không ai quan tâm rằng bạn dành 20 giờ để nghiên cứu Spring nếu báo cáo mà họ yêu cầu bạn không được thực hiện).

Từ tất cả những điều trên, tránh làm giáo viên (trừ khi nó liên quan đến một lĩnh vực / công nghệ mà thực sự bạn có đủ kinh nghiệm). Một bài thuyết trình trung lập hơn sẽ chỉ ra những lợi thế của việc thử nghiệm tự động và cho phép quản lý chọn người mà họ muốn nghiên cứu những ưu và nhược điểm của những thực tiễn đó.

Bây giờ, để trình bày những "thực tiễn tốt nhất" đó, có hai cách giải thích chúng cho nhóm của bạn:

  • Bởi vì tôi nói rằng họ là những thực tiễn tốt nhất, và thế là đủ.
  • Bởi vì chúng hữu ích và giúp giải quyết vấn đề.

Sử dụng đối số đầu tiên, trừ khi bạn là ông chủ hoặc một thành viên rất cao trong nhóm, không chắc họ sẽ dành cho bạn bất kỳ sự chú ý nào. Và "Tôi đã đọc một cuốn sách từ Knuth nói như vậy" hoặc "những người của SE nói rằng" sẽ không gây ra bất kỳ ấn tượng nào, ("những người đó không làm việc ở đây vì vậy họ không thực sự biết điều gì tốt cho cửa hàng CNTT này "). Họ có phương pháp, thói quen, quy trình và những việc "nhiều hay ít", vậy tại sao phải nỗ lực và rủi ro khi thay đổi?

Đối với cách tiếp cận thứ hai để làm việc, phải có nhận thức rằng một vấn đề tồn tại . Vì thế:

  • Đừng đi ngày đêm để thử nghiệm tự động. Đợi cho đến khi một bản cập nhật phá vỡ một số tính năng và nhóm phải làm việc thêm giờ để sửa nó, sau đó đề xuất xây dựng một hệ thống kiểm tra tự động.
  • đừng hỏi đánh giá mã. Đợi cho đến khi Joe được nghỉ phép dài hạn và cần phải thay đổi mô-đun đó mà chỉ Joe biết, và chỉ cho sếp của bạn biết mất bao nhiêu thời gian chỉ để cố gắng hiểu mã của Joe.

Tất nhiên, thay đổi sẽ chậm và tiến bộ (hơn nữa trong một tập đoàn lớn). Nếu bạn có thể giới thiệu đánh giá mã và kiểm tra tự động trong năm năm, bạn nên tự chúc mừng mình vì đã hoàn thành tốt công việc. Nhưng, trừ khi có một bản viết lại hoàn toàn do các nguyên nhân bên ngoài, hãy quên mọi ảo tưởng rằng họ sẽ chuyển IS cốt lõi sang, nói, Spring ( Joel giải thích theo cách đó tốt hơn tôi từng có, ngay cả trước khi bạn sinh 1 ); trong thời gian đó, nhiều nhất bạn có thể đưa Spring vào danh sách các nền tảng được hỗ trợ để viết các hệ thống không quan trọng.

Chào mừng đến với thế giới của doanh nghiệp CNTT, cậu bé! :-p

1 : Ok, có lẽ tôi đang hăng hái một chút, nhưng không quá nhiều.


1
Chủ yếu là không đồng ý. Cách duy nhất để có được một số thay đổi trong một nhóm là nếu ai đó sẵn sàng thực hiện nghiên cứu và kéo phần còn lại đi cùng. Tất nhiên bạn nên duy trì năng suất làm việc, nhưng nếu mọi người đều cúi thấp đầu thì cuối cùng bạn "hơi lỗi thời, nhưng bạn đã hoàn thành công việc". Và hoàn toàn bị đốt cháy từ sự nhàm chán.
nháy mắt

@winkbrace Tôi không khẳng định rằng bạn không nên cố gắng cải thiện (thực tế tôi nói ngược lại). Nhưng thúc đẩy những thay đổi đó mà không có sự hỗ trợ quản lý và không có sự ủy quyền của một số thâm niên có thể khá khó khăn và gây ra một số trở ngại; Thêm vào đó, OP không phải là một chuyên gia và có thể gặp rắc rối với việc triển khai thực tế. Sẽ thật tuyệt nếu OP có thể tình nguyện tham gia nhóm nghiên cứu / tạo mẫu để giới thiệu đúng các thay đổi; nhưng cấm rằng anh ta nên cẩn thận trong việc lựa chọn phương pháp đúng để thúc đẩy những người đó và kiên nhẫn.
SJuan76

@winkbrace cho bit nhàm chán, nó phụ thuộc vào tính cách của bạn và những gì bạn đang tìm kiếm trong một công việc. Sẽ là hợp lý khi cố gắng hạ cánh ở một vị trí công việc thỏa mãn bạn, thay vì đi bất cứ đâu và cố gắng thay đổi tổ chức theo sở thích của bạn. Và thông thường các tập đoàn lớn (trừ các bộ phận R & D) không phải là nơi dành cho những người thích thử nghiệm công nghệ mới mỗi vài tháng.
SJuan76

Có một chút sai lầm khi nói "hãy chắc chắn rằng bạn đang thực sự làm việc". Chắc chắn bạn nên làm việc nhưng bạn cũng cần suy nghĩ lâu dài và mỗi ngày bạn nên cải thiện. Tôi đã mất 5 tháng để khiến người quản lý của chúng tôi mua vào thực tế rằng các bài kiểm tra đơn vị giúp ích ngay cả khi chúng tôi đang cố gắng viết mã "nhanh". Nhưng tôi cần phải mất 10 phút ở đây và cứ sau vài ngày để điều đó xảy ra.
Rudolf Olah

@omouse Tôi chỉ chỉ là một rủi ro đôi khi đã đánh vào chính mình, khi làm nghiên cứu. Chắc chắn tôi không thấy nguy cơ đó trong tình huống mà bạn mô tả, nhưng hình thức mà OP mô tả nghiên cứu của anh ấy ("đầu tiên tôi bắt đầu với ... sau đó tôi nhanh chóng di chuyển ...") khiến tôi thêm sự thận trọng. Lưu ý rằng tôi không cho rằng OP không thực hiện đúng công việc được giao của mình (đó là điều mà đơn giản là tôi không biết, và đó là ông chủ của anh ấy), tôi chỉ cảnh báo anh ấy để đảm bảo rằng anh ấy không bị mang đi .
SJuan76

12

Bạn nên bắt đầu với cuốn sách Làm việc hiệu quả với Bộ luật kế thừa của Michael Feathers. Từ phần giới thiệu của cuốn sách, "Đó là về một hệ thống rối, mờ, phức tạp và dần dần, từng mảnh, từng bước, biến nó thành một hệ thống đơn giản, có cấu trúc tốt, được thiết kế tốt." Anh ta chủ yếu bắt đầu với thử nghiệm tự động, để bạn có thể tái cấu trúc một cách an toàn (bạn sẽ biết nếu bạn phá vỡ bất cứ điều gì) và anh ta bao gồm rất nhiều chiến lược để đưa mã khó vào thử nghiệm tự động. Điều này hữu ích cho mọi dự án vẫn đang được phát triển. Khi bạn đã có một số thứ tự cơ bản tại chỗ, bạn có thể thấy những công nghệ hiện đại khác mà dự án của bạn thực sự có thể hưởng lợi từ - nhưng đừng cho rằng bạn cần tất cả chúng.

Nếu bạn muốn học một khuôn khổ mới (hoặc một cái gì đó) vì lý do nghề nghiệp hơn là vì dự án hiện tại của bạn thực sự cần nó, thì bạn nên sử dụng nó trong một số dự án cá nhân (vào thời gian riêng của bạn).


Tôi đồng ý với các chủ đề trong Làm việc hiệu quả với Mã di sản nhưng nó không gọn lắm. Hãy xem nó như một tài liệu tham khảo và lướt qua các chương hơn là mong đợi để đọc nó như một cuốn tiểu thuyết.
Lukas

10

Kiểm soát nguồn.

Bạn đã không đề cập đến nó, hy vọng bởi vì nó đã được đặt ra, nhưng, trong trường hợp không, hãy bắt đầu từ đó.

Kiểm soát nguồn có tiếng nổ lớn nhất, ngoại trừ trong các trường hợp hiếm hoi bệnh lý cần một thứ khác.

Và bạn có thể bắt đầu một mình nếu ban đầu không có ai mua.


1
Bang-for-buck lớn nhất giống như một vài ASSERT ở đúng nơi.
Peter Mortensen

@PeterMortensen Đúng, nhưng chỉ khi bạn biết đúng nơi là gì.
Emilio M Bumachar

Bạn đánh bại tôi vào nó. Bất kể OP đưa đội của mình đi theo hướng nào, việc đến đó với Git sẽ dễ dàng và hiệu quả hơn nhiều so với không có.
dotancohen

6

Trả lời trực tiếp

Các câu trả lời khác làm cho 'điểm meta' tốt về việc áp dụng các thực tiễn tốt hơn, nhưng, chỉ để cung cấp cho bạn một số hướng dẫn có liên quan trực tiếp, đây là một thứ tự sơ bộ về các thực tiễn tốt nhất mà tôi đề xuất nhóm của bạn (hoặc bất kỳ nhóm nào) áp dụng (trước tiên):

  1. Kiểm soát nguồn
  2. Theo dõi vấn đề (quản lý dự án và nhiệm vụ)
  3. Xây dựng tự động 1
  4. Triển khai tự động

1 Một thực tiễn rất liên quan là tự động hóa, hoặc ít nhất là tài liệu , thiết lập môi trường xây dựng và phát triển của từng ứng dụng hoặc dự án phần mềm bạn đang phát triển hoặc bảo trì. Nó ít hữu ích hơn bởi vì bạn (hy vọng) làm việc này không thường xuyên hoặc hiếm khi.

Mọi thứ khác

Bạn đề cập đến một số thực tiễn tốt khác - "kiểm tra đơn vị, ghi nhật ký, chuẩn hóa cơ sở dữ liệu, ... tái cấu trúc, ... tài liệu" - nhưng đây là tất cả các thực tiễn có thể và nên được áp dụng dần dần và tăng dần. Không ai trong số họ cần phải được thông qua tất cả cùng một lúc và có thể bạn sẽ áp dụng tốt hơn cho họ ở tất cả bằng cách áp dụng chúng một cách cẩn thận và chánh niệm.

Bốn thực hành tôi liệt kê ở trên cũng sẽ giúp việc áp dụng và thử nghiệm các thực tiễn mới dễ dàng nhất có thể. Ví dụ: kiểm tra đơn vị có thể được tích hợp vào các bản dựng tự động của bạn và tài liệu có thể được xuất bản như một phần của các triển khai tự động của bạn.

Một số thực tiễn khác mà bạn đề cập - "phát triển nhanh, ... hướng dẫn phong cách mã hóa, ... đánh giá mã, ... phương pháp tài liệu được tiêu chuẩn hóa" và các khung (ví dụ: Spring) - thực sự là tùy chọn hoặc có giá trị đáng ngờ. Và điều đó đúng với rất nhiều (hầu hết?) Các thực tiễn có thể bạn sẽ khám phá hoặc gặp phải.

Phát triển Agile rõ ràng không vượt trội so với bất kỳ phương pháp nào khác được sử dụng. Và rất nhiều người (bao gồm cả bản thân tôi) đã có những trải nghiệm khủng khiếp với nó. Nhưng nhiều người thực sự thích nó (hoặc thích nó) quá. Thử nó!

Hướng dẫn về phong cách mã hóa có thể hữu ích, đặc biệt đối với các dự án lớn hoặc trong các nhóm lớn, nhưng cũng rất nhiều công việc để thực thi các hướng dẫn đó và đó có thể không phải là cách sử dụng tốt nhất thời gian của bất kỳ ai đang làm như vậy.

Đánh giá mã cũng có thể rất hữu ích - bạn đã yêu cầu đồng nghiệp xem lại mã của mình chưa? Hãy nhớ rằng bạn không cần một quy trình chính thức để áp dụng các thực hành tốt!

Tài liệu rất hay - bạn có cái nào không? Nếu như thế, sẽ tốt cho bạn! Bạn có đang đối mặt với nhiều công việc làm thêm có thể được ngăn chặn bằng cách có (nhiều hơn) tài liệu "chuẩn hóa" không? Nếu bạn là như vậy, thì đó có lẽ là điều đáng làm. Tuy nhiên, giả sử nếu phần mềm của bạn đang được sử dụng bởi một nhóm nhỏ người, bạn có thể không cần bất kỳ tài liệu nào . (Hoặc bạn có thể kết hợp trực tiếp tài liệu vào phần mềm của mình. Đó luôn là sở thích của tôi.)

Khung là ... một con dao hai lưỡi (rất sắc). Một giải pháp được gói gọn và duy trì tốt cho tính năng không cốt lõi của phần mềm của bạn là tuyệt vời ... cho đến khi không. Tôi không chắc chắn chính xác "bộ điều khiển viết tay" là gì nhưng không có lời giải thích rõ ràng về lý do tại sao chúng kém hơn mã sử dụng Spring. Bạn đã xem xét việc đóng gói logic chung trong tất cả các bộ điều khiển này vào khung trong nhà của riêng bạn chưa? Chấp nhận Spring và viết lại tất cả mã hiện tại của bạn, có thể là một dự án tái cấu trúc to lớn (hoặc, nhiều khả năng, viết lại) và đó có thể không phải là thay đổi tốt nhất bạn có thể thực hiện đối với mã của mình . Tất nhiên bạn không nên viết tất cả các phần mềm bạn sử dụng - khung (và thư viện) là tuyệt vời!Nhưng có lẽ bạn không phải sử dụng Spring (hoặc một giải pháp thay thế) để viết các ứng dụng web tuyệt vời (hoặc tốt).


Tôi sẽ đặt thử nghiệm hồi quy tự động ngay trên đó với xây dựng và triển khai tự động. Nó cũng có lợi thế là nó là thứ bạn có thể làm việc tăng dần.
sdenham

Kiểm thử đơn vị nên là đầu tiên, bắt đầu với thủ công luôn luôn chạy cục bộ (hoặc trên mỗi lần thanh toán / đăng ký) và sau đó đưa phần còn lại của nhóm để mua vào kiểm tra hồi quy tự động. Có những nhà phát triển thực sự sợ chạy thử nghiệm liên tục vì một số lý do.
Rudolf Olah

5

Nhìn xung quanh đội mà bạn là một phần của. Bạn có thể thấy bất kỳ bằng chứng nào cho thấy việc phát triển theo hướng kiểm tra hoặc chuẩn hóa cơ sở dữ liệu sẽ cải thiện chất lượng phần mềm bạn đang viết hoặc làm cho mọi người làm việc hiệu quả hơn không?

Bạn đã thử nói chuyện với một trong những giám sát viên phát triển về nó, hay người đứng đầu phát triển chưa? Một cuộc trò chuyện thực sự không chính thức sẽ là một khởi đầu tốt. Điều gì khiến bạn nghĩ rằng những người ở trên bạn không có cùng ý tưởng nhưng không thể / sẽ không thực hiện chúng vì doanh nghiệp sẽ không cho phép điều đó?

Tôi thấy rằng dẫn đầu bằng ví dụ là một cách tốt để đi. Mọi người sẽ giảm sức đề kháng rất nhiều nếu người khác đã hoàn thành công việc và có thể chỉ cho họ cách tái tạo nó. Giới thiệu TDD vào một dự án bạn đang thực hiện. Yêu cầu thuyết trình cho các thành viên còn lại trong nhóm, hoặc thậm chí một vài người khác và cho họ thấy những gì bạn đã làm. Những gì @DrewJordan nói về việc mua lại từ ông chủ là quan trọng hơn bạn có thể nhận ra.


5

Tìm một lỗ hổng. Sửa một lỗ hổng. Hiển thị các sửa chữa.

Trước tiên hãy chuẩn hóa *. Và thực tế, tôi khuyên bạn nên dùng nó trước, vì thiếu bình thường hóa có thể dẫn đến dữ liệu lỗi thực tế không tồn tại nếu không, trong khi phần còn lại là trường hợp thực hành tốt nhất có thể giúp đỡ nhưng khó nói hơn "Lỗi A là do không tuân theo chính sách X ". Nếu bạn có một cơ sở dữ liệu không được chuẩn hóa, thì bạn có một nơi mà dữ liệu có thể không nhất quán.

Thật may là bạn sẽ có thể tìm thấy một trường hợp thực tế của dữ liệu không nhất quán. Bây giờ bạn đã tìm thấy hai điều:

  1. Một lỗi trong dữ liệu của bạn.

  2. Một lỗi trong schemata cơ sở dữ liệu của bạn.

Bạn thực sự đã biết về lỗi thứ hai trước tiên, nhưng lỗi thứ nhất dễ gặp hơn và cũng là thứ gây ra vấn đề thực sự, không phải là thứ mà về mặt lý thuyết có thể.

Thật không may, một trong những lý do thực sự để chống lại việc bình thường hóa cơ sở dữ liệu không chuẩn hóa là câu hỏi phải làm gì với dữ liệu lỗi như vậy không phải lúc nào cũng dễ dàng, nhưng bạn sẽ tìm thấy một lỗi thực sự.

(Hãy lưu ý rằng có những lý do tại sao đôi khi người ta có thể không chuẩn hóa một số dữ liệu về mục đích. Đừng nhầm lẫn việc phá vỡ quy tắc về sự thiếu hiểu biết về quy tắc; nếu bạn bình thường hóa một bảng được cố tình không chuẩn hóa cho tốc độ tra cứu, bạn đã thắng Mặc dù ở đây, mặc dù ở đây, việc không chuẩn hóa bị ảnh hưởng là điều cần được thực hiện theo thủ tục, vì vậy nếu bảng không chuẩn hóa không được tạo tự động dựa trên nội dung của các bảng được chuẩn hóa thì vẫn có tiến trình để thực hiện).

Đối với phần còn lại, hãy giới thiệu họ khi họ giúp đỡ trong thời gian ngắn, để sau này xây dựng chúng trong dài hạn. Ví dụ, nếu bạn được cung cấp một đoạn mã nhỏ để xây dựng, hãy viết một bài kiểm tra đơn vị cho nó. Tốt hơn hết, nếu bạn được cung cấp một lỗi để sửa, hãy viết một bài kiểm tra đơn vị không thành công do lỗi và sau đó khi bạn sửa lỗi, hãy đề cập đến thực tế là nó đã vượt qua khi bạn tắt các lỗi (hoặc gửi email nói rằng nó đã được sửa , hay bất cứ cái gì).

* Ngẫu nhiên, không hiện đại lắm. Lý do nó được gọi là bình thường và không bình thường hay cái gì khác, đó là vào thời điểm đó nó là một trò đùa tại chỗ để dính -ization vào cuối điều cần làm cho niềm vui của tên của Richard Nixon Việt Nam hóa chính sách.


4

Tôi sẽ đi ngược lại ngũ cốc và nói: tìm một công việc mới sau khi dành chút thời gian này để xây dựng sơ yếu lý lịch của bạn một chút. Mục tiêu trong một năm hoặc lâu hơn. Mặc dù nhiều thứ là "buzzwords", các vấn đề như thiếu kiểm thử đơn vị hoàn toàn không thể chấp nhận được đối với một nhà phát triển và có thể là nếu các lập trình viên làm việc không có mong muốn kiểm tra, bạn sẽ không bao giờ mua hàng và thậm chí có thể gây nguy hiểm cho vị trí của bạn tại công ty bằng cách khiến mọi người nghĩ về bạn như một kẻ đáng ghét. Bạn cần ở một nơi mà bạn có thể nhận được tư vấn, không cố gắng đẩy văn hóa theo hướng năng lực cơ bản.


3
Đó chính xác là những gì tôi đã làm. Chỉ có một lần (trong số ~ 5 lần thử ở nhiều nơi) khi tôi giới thiệu thành công một số "thực hành tốt" mới hoặc thực hiện một thay đổi đáng kể trong thực tiễn hiện có, và đó là khi nhóm mới và chúng tôi bắt đầu hầu hết các dự án từ đầu . Tất cả các lần thực hành tốt khác đều được giới thiệu từ đầu (nhóm trưởng) hoặc chỉ thất bại vì không có ai tham gia. Tôi tin rằng tất cả đều có khả năng buộc quyết định của bạn bằng cách trở thành một nhà lãnh đạo / sếp.
scriptin


1

Đã có rất nhiều đề xuất để cải thiện mô hình lập trình . Các từ thông dụng nhất hiện nay dường như là lập trình nhanh và hướng đối tượng. Hoặc là họ? Cả hai đã mờ nhạt đáng kể so với những gì họ chỉ năm năm trước đây.

Bạn có thể khá tự tin rằng bất cứ phương pháp nào được đưa ra đều cố gắng hoàn thành cùng một kết quả cuối cùng: giúp các kỹ sư sản xuất một cách kinh tế một sản phẩm cuối cùng đủ tốt.

Có một mô hình mà đã gây nhiều tranh được giới thiệu trong năm 1960: có cấu trúc lập trình : chỉ sử dụng "trình độ cao" xây dựng như while, for, repeat, if/ then/ else, switch/ casebáo cáo thay vì sử dụng rất nhiều gototuyên bố đó đã được chấp nhận theo mặc định. Vẫn còn nhiều tranh luận về việc liệu gotocó sử dụng hợp pháp nào không.

Tôi chấp nhận rằng giảm thiểu sử dụng gotolà một điều tốt, nhưng giống như tất cả những điều tốt đẹp, có thể đi quá xa.

Bạn đề cập đến agilephương pháp như một cái gì đó tích cực. Tôi đã ở trong một nhóm phát triển trong khoảng sáu tháng, cố tình tuân theo một chế độ nhanh nhẹn theo quy định. Tôi thấy nó giống như các phương pháp quản lý dự án đã giác ngộ từ nhiều thập kỷ trước, ngoại trừ mọi thứ được đổi tên. Có lẽ bằng cách bó lại và bán lại các ý tưởng để truyền đạt cho ai đó kiếm sống và các công ty có thể cảm thấy tốt khi "nhìn thấy" quần áo mới của hoàng đế .

Bài học quý giá nhất của Agile, được biết đến từ lâu, đó là sự linh hoạt để tìm ra con đường tốt hơn cho sản phẩm hoàn chỉnh là một điều tốt và khả năng tìm ra con đường đó có thể đến từ bất cứ ai, không chỉ là quản lý cấp trên.


Từ một bài viết của thủ lĩnh chống goto Edsger Dijkstra:

Nghệ thuật lập trình là nghệ thuật tổ chức sự phức tạp, làm chủ vô số và tránh sự hỗn loạn khốn của nó một cách hiệu quả nhất có thể.

TiếtDijkstra, in: Dahl, Dijkstra & Hoare 1972, pg. 6. (xem trang 6 tại đây .)

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.