Cách mã hóa nhanh hơn (không cần chất lượng hy sinh) [đã đóng]

Tôi đã là một lập trình viên chuyên nghiệp trong một vài năm. Các ý kiến ​​về mã của tôi thường giống nhau: viết mã tuyệt vời, được kiểm tra tốt, nhưng có thể nhanh hơn .

Vậy làm thế nào để tôi trở thành một lập trình viên nhanh hơn, mà không làm giảm chất lượng? Vì mục đích của câu hỏi này, tôi sẽ giới hạn phạm vi ở C #, vì đó chủ yếu là những gì tôi viết mã (cho vui) - hoặc Java, tương tự đủ theo nhiều cách quan trọng.

Những việc tôi đang làm:

• Viết giải pháp tối thiểu sẽ hoàn thành công việc
• Viết một loạt các bài kiểm tra tự động (ngăn ngừa hồi quy)
• Viết (và sử dụng) các thư viện có thể tái sử dụng cho tất cả các loại
• Sử dụng các công nghệ nổi tiếng nơi chúng hoạt động tốt (ví dụ: Hibernate)
• Sử dụng các mẫu thiết kế nơi chúng phù hợp với vị trí (ví dụ: Singleton)

Đây là tất cả tuyệt vời, nhưng tôi không cảm thấy như tốc độ của tôi đang tăng lên theo thời gian. Tôi làm cẩn thận, bởi vì nếu tôi có thể làm điều gì đó để tăng năng suất của tôi (thậm chí 10%), đó là nhanh hơn so với đối thủ cạnh tranh của tôi là 10%. (Không phải tôi có bất kỳ.)

Bên cạnh đó, tôi đã liên tục nhận được sự ủng hộ này từ các nhà quản lý của mình - cho dù đó là phát triển Flash quy mô nhỏ hay phát triển Java / C ++ cho doanh nghiệp.

Chỉnh sửa: Dường như có rất nhiều câu hỏi về những gì tôi muốn nói nhanh, và làm thế nào tôi biết tôi chậm. Hãy để tôi làm rõ với một số chi tiết.

Tôi đã làm việc trong các nhóm vừa và nhỏ (5-50 người) trong các công ty khác nhau qua các dự án khác nhau và các công nghệ khác nhau (Flash, ASP.NET, Java, C ++). Quan sát của những người quản lý của tôi (mà họ nói trực tiếp với tôi) là tôi "chậm".

Một phần của điều này là do một số lượng đáng kể các đồng nghiệp của tôi đã hy sinh chất lượng cho tốc độ; họ đã viết mã bị lỗi, khó đọc, khó bảo trì và khó viết các bài kiểm tra tự động. Mã của tôi nói chung là tài liệu tốt, có thể đọc và kiểm tra được.

Tại Oracle, tôi sẽ liên tục giải quyết các lỗi chậm hơn các thành viên khác trong nhóm. Tôi biết điều này, bởi vì tôi sẽ nhận được ý kiến ​​cho hiệu ứng đó; điều này có nghĩa là các nhà phát triển khác (có, nhiều kinh nghiệm và có kinh nghiệm hơn) có thể thực hiện công việc của tôi trong thời gian ngắn hơn so với tôi, với chất lượng gần như tương đương (khả năng đọc, khả năng bảo trì và khả năng kiểm tra).

Tại sao? Tôi đang thiếu gì? Làm thế nào tôi có thể trở nên tốt hơn ở đây?

Mục tiêu cuối cùng của tôi rất đơn giản: nếu tôi có thể tạo ra sản phẩm X trong 40 giờ hôm nay và tôi có thể cải thiện bản thân bằng cách nào đó để tôi có thể tạo ra cùng một sản phẩm vào 20, 30 hoặc thậm chí 38 giờ vào ngày mai, đó là điều tôi muốn biết - Làm thế nào để tôi đến đó? Tôi có thể sử dụng quy trình nào để liên tục cải thiện? Tôi đã nghĩ rằng đó là về việc sử dụng lại mã, nhưng dường như điều đó là không đủ.

Tôi thích cách tiếp cận của Jeff Atwood về vấn đề này có thể tìm thấy ở đây http: //www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

Về cơ bản trong bài viết, ông tham khảo một đoạn trong cuốn sách Nghệ thuật & nỗi sợ hãi của David Bayles và Ted Dessert. Đoạn văn đi:

Giáo viên gốm sứ tuyên bố vào ngày khai giảng rằng ông đang chia lớp thành hai nhóm. Tất cả những người ở phía bên trái của studio, theo ông, sẽ được phân loại chỉ dựa trên số lượng tác phẩm họ sản xuất, tất cả những người ở bên phải chỉ dựa vào chất lượng của nó. Thủ tục của anh ta rất đơn giản: vào ngày cuối cùng của lớp, anh ta sẽ mang vảy trong phòng tắm của mình và cân nhắc công việc của nhóm "số lượng": năm mươi pound chậu được xếp hạng "A", bốn mươi pound một "B", v.v. Tuy nhiên, những người được xếp loại "chất lượng" chỉ cần sản xuất một nồi - mặc dù là một nồi hoàn hảo - để có được "A". Vâng, đã đến thời điểm chấm điểm và một sự thật tò mò đã xuất hiện: các tác phẩm có chất lượng cao nhất đều được sản xuất bởi nhóm được xếp loại về số lượng. Có vẻ như trong khi "số lượng"

Về cơ bản, làm cho bàn tay của bạn bẩn nhanh hơn và thường xuyên cải thiện kỹ năng của bạn tốt hơn, dành thời gian nghiên cứu và lý thuyết về cách "hoàn hảo" để làm điều đó. Lời khuyên của tôi, hãy tiếp tục luyện tập, theo kịp công nghệ và học thiết kế.

Một khả năng mà dường như không ai khác đã đề cập là bạn đang làm tốt và người quản lý của bạn không giỏi lắm. Làm thế nào họ đo năng suất? Họ có thể cho bạn ví dụ cụ thể hay đó chỉ là một nhận thức chung? Họ đã tính đến lượng thời gian dành cho việc sửa chữa công việc của người khác so với của bạn chưa?

Tôi đã thấy nhiều người nhận được tín dụng để hoàn thành công việc, trong khi những người còn lại trong nhóm của họ sửa chữa mớ hỗn độn mà họ đã bỏ lại.

Hầu hết những gì mọi người nghĩ là quan trọng không quan trọng. Tốc độ gõ không quan trọng. Máy hoặc công cụ nhanh hơn không quan trọng. Chúng tôi không phải là người đánh máy hoặc vận hành máy. Chúng tôi là những người lao động. Chúng tôi là những người ra quyết định .

Có gì là quan trọng là sử dụng phản hồi liên tục cải tiến quy trình ra quyết định của bạn. Cách duy nhất để làm điều này, như có được bất kỳ kỹ năng nào khác, là thông qua kinh nghiệm, thực hành có mục đích và phản hồi liên tục.

• Làm việc trên các dự án phụ.
• Làm việc trên các dự án nguồn mở.
• Làm việc với các nhà phát triển tốt hơn bạn. Chương trình cặp!
• Tiếp xúc với các công cụ và kỹ thuật mới. Giữ những gì làm việc.
• Làm các bài tập lập trình được thiết kế để đào tạo bộ máy ra quyết định của bạn *.
• Theo dõi sự cải thiện của bạn dựa trên các số liệu khách quan như tỷ lệ lỗi và vận tốc và các số liệu chủ quan như chất lượng mã và thể lực.

Cuối cùng: hãy nhớ rằng tốc độ mà không có chất lượng là vô ích, và ngược lại. Để tối đa hóa tiện ích của bạn, hãy tìm sự cân bằng giữa những căng thẳng này.

* http://codekata.pragprog.com/

Thực sự có khả năng là bạn đang được yêu cầu hy sinh một số chất lượng, để có tốc độ cao hơn.

Trong một số môi trường phát triển ¹ , đơn giản là không đáng để thêm thời gian để tạo ra thứ gì đó bóng bẩy, khi "chỉ đủ tốt" sẽ làm.

^{1 - Tôi đang nghĩ về "công cụ nội bộ" nói riêng, nhưng có lẽ có những người khác.}

Có vẻ như bạn đang làm tất cả những điều tốt đẹp - rằng trong trung hạn sẽ làm cho bạn nhanh hơn, vì vậy không rõ ràng nếu bạn thực sự chậm. Chỉ có bạn thực sự biết điều đó. (nhưng đó là một khả năng rất thực tế - PeopleWare tuyên bố sự chênh lệch sản phẩm lên tới 10 lần giữa các nhà phát triển cho cùng một nhiệm vụ).

Vì vậy, tôi có một số gợi ý cho bạn:

1. Thời gian là một điều tương đối, vì vậy có lẽ vấn đề không phải là tốc độ thực tế của bạn mà là nhận thức về thời gian bạn đang đưa ra. Bạn có thể ngụ ý sẽ mất một tuần, nhưng cuối cùng lại mất hai tuần, trong đó những người khác có thể mất 3 tuần ... nhưng bạn chỉ trông chậm 1 tuần.

2. Vì bạn nhận được phản hồi này thường xuyên, có lẽ đã đến lúc nói chuyện với người quản lý và đồng nghiệp của bạn để xem những gì họ nói - phải có nhiều điều để học hỏi từ họ.

3. Thực hiện một số lập trình cặp với nhà phát triển "chất lượng nhanh" để xem bạn có thể phát hiện ra sự khác biệt không.

Hiệu quả, những gì nó sôi lên là kinh nghiệm . Để nhanh hơn với những gì bạn làm giống như lái xe hơi, ban đầu bạn sợ vì những người khác là những người lái xe nhanh (hoặc say rượu) và bạn muốn về nhà an toàn (về mặt phần mềm, bạn muốn đảm bảo mã của mình hoạt động như được phát triển và nó hoạt động tốt).

Trong nhiều năm / tháng, một khi bạn cảm thấy thích thú với việc lái xe và đường cao tốc, bạn sẽ học được một vài mẹo nhỏ trên đường khiến cho việc lái xe của bạn trở nên thú vị. Đó là những gì chúng ta gọi là kinh nghiệm. Những "mánh khóe" (mà tôi gọi là đặc điểm) là những gì giúp ích.

Trong trường hợp của tôi, tôi đã học được cách sử dụng thực tế của các mẫu thiết kế bằng cách mã hóa (thậm chí @ home) và học cách sử dụng một số. Do đó, khi tôi gặp phải một vấn đề đòi hỏi một mẫu thiết kế, tôi sử dụng kinh nghiệm trong quá khứ để xem cái nào hoạt động và tại sao nó lại hoạt động / không hoạt động cho tình huống của tôi.

Tóm tắt:

• Kinh nghiệm tạo ra những đặc điểm giúp tăng sự tự tin và phần mềm tốt hơn.

PS: Kinh nghiệm cũng đến từ việc học hỏi từ những người khác. Ví dụ: Trợ giúp từ SO, Lập trình cặp, Đánh giá ngang hàng, v.v. Bạn không thể có kinh nghiệm nếu bạn không thể nhìn lại và học hỏi từ những sai lầm (hoặc nếu ai đó không bao giờ thử thách nỗ lực của bạn).

Câu hỏi là nếu bạn ít tốn kém hơn khi nhìn vào tổng chi phí dài hạn.

Nói cách khác, các bản sửa lỗi được chế tạo cẩn thận của bạn có chất lượng cao như vậy (bao gồm các trường hợp kiểm tra và tài liệu) có vượt quá chi phí phải duy trì các bản sửa lỗi được thực hiện bởi các đồng nghiệp nhanh hơn của bạn không?

Nếu có, thì bạn cần phải làm cho cấp trên của bạn nhận thức được thực tế này. Có thể khó tranh luận nếu họ không đo lường và có dữ liệu cần thiết để xác nhận đánh giá của bạn.

Nếu không, thì bạn phải xem xét tại sao lại như vậy:

• Bạn có quá thiếu kinh nghiệm?
• Bạn có dành nhiều thời gian để làm những việc không được yêu cầu mà bạn tin là nên có không?
• Bạn có khó khăn trong việc xác định khi sửa xong?
• Rốt cuộc mã của bạn có chất lượng thấp hơn bạn nghĩ không?
• Bạn có nên tiếp cận phát triển mã theo một cách khác bởi vì bạn mất quá nhiều thời gian để tăng tốc theo cách bạn làm bây giờ?
• Bạn có dành quá nhiều thời gian cho những thứ như trang web này?

Hãy suy nghĩ và chỉnh sửa câu hỏi của bạn với những phát hiện của bạn.

Tất cả những người thắc mắc đã làm về việc bạn có thực sự chậm hay không là điều ngớ ngẩn. Trở thành một lập trình viên nhanh hơn mà không phải hy sinh chất lượng luôn là một mục tiêu tốt cho dù bạn đã chậm hay nhanh. Đây là mục tiêu số 1 của tôi với tư cách là một lập trình viên và tôi sẽ không bao giờ được thực hiện. Tôi luôn cố gắng để nhanh hơn mà không làm giảm chất lượng, tôi bị ám ảnh bởi nó. Đây là những gì đã làm việc cho tôi cho đến nay theo thứ tự hữu ích, cùng với một số ý tưởng thử nghiệm ở cuối:

1) Không bao giờ ngừng học hỏi: Tìm hiểu mọi thứ bạn có thể về lập trình và sử dụng máy tính nói chung. Tìm những lĩnh vực bạn yếu và tìm hiểu chúng. Ngay cả khi nó dường như hoàn toàn không liên quan đến công việc của bạn và C #, tôi đảm bảo rằng nếu bạn đang tìm kiếm nó, bạn sẽ thường tìm cách áp dụng nó vào những gì bạn làm. Học hỏi cũng là về kinh nghiệm, vì vậy đừng chỉ đọc những thứ mà hãy thử và mở rộng các kỹ năng của bạn. Nếu bạn đã quen sử dụng Windows, hãy thử Unix hoặc ngược lại. Nếu bạn thường muốn sử dụng các công cụ dòng lệnh và trình soạn thảo văn bản của IDE hoặc ngược lại. Nếu bạn nghe nói về một công cụ hoặc công nghệ mà bạn chưa từng nghe đến trước đây hoặc không biết nhiều về nó, đừng từ bỏ cám dỗ để tiếp tục. Tìm kiếm! Đừng sợ nghĩ xa hơn và tìm hiểu các công nghệ mới thử nghiệm mà người khác nói là không thực tế;

2) Chia nhỏ các dự án: Cố gắng chia nhỏ các dự án của bạn thành các dự án nhỏ. Cố gắng làm một bản phát hành mới mỗi ngày hoặc nhiều nhất một lần trong vài ngày. Hãy tự hỏi mình "Lượng chức năng tối thiểu tôi có thể phát hành là bao nhiêu và vẫn phát hành thứ gì đó hữu ích cho người dùng." Đây là một kỹ năng bạn sẽ học bằng cách thực hiện nó. Bạn có thể cần thuyết phục người quản lý của mình cho phép bạn làm điều này, nhưng họ thường sẽ hài lòng với kết quả khá nhanh. Bằng cách này, bạn sẽ bắt đầu nhận thấy rằng những thứ mà bạn nghĩ là thiết yếu cho tính năng của bạn thực sự là các tính năng bổ sung có thể được phát triển sau này. Điều này cho phép bạn và người quản lý của bạn chỉ ưu tiên các tính năng quan trọng nhất thay vì tất cả các tính năng liên quan đến tính năng bạn đang làm việc. Điều này cho phép bạn suy nghĩ nhanh hơn bằng cách giữ cho tâm trí của bạn rõ ràng và tập trung. Bạn sẽ lần lượt lập trình hợp pháp nhanh hơn. Người quản lý của bạn hoặc ít nhất là người quản lý của người quản lý của bạn cũng có khả năng nhận thấy rằng bạn hiện đang lập trình thậm chí nhanh hơn bạn thực sự bởi vì bạn đang nhận được nhiều bản phát hành hơn. Một lợi ích to lớn khác của việc này là bạn sẽ tốt hơn nhiều khi ước tính thời gian phát hành sẽ hoàn thành trong bao lâu và người quản lý của bạn sẽ yêu bạn vì điều này. Vì bạn đã thực hiện nhiều thử nghiệm tự động, nên bạn sẽ không gặp vấn đề gì khi thực hiện các bản phát hành thường xuyên ổn định. Bạn có thể cần tăng cường hệ thống xây dựng tự động của bạn mặc dù. Tôi đặc biệt khuyên bạn nên đọc cuốn sách Giao hàng liên tục trong sê-ri Martin Fowler. Nó khó đọc và bởi vì nó cực kỳ lặp đi lặp lại, nhưng vẫn rất hữu ích. Các nhà quản lý cũng có khả năng nhận thấy rằng bạn hiện đang lập trình thậm chí nhanh hơn bạn thực sự bởi vì bạn đang nhận được nhiều bản phát hành hơn. Một lợi ích to lớn khác của việc này là bạn sẽ tốt hơn nhiều khi ước tính thời gian phát hành sẽ hoàn thành trong bao lâu và người quản lý của bạn sẽ yêu bạn vì điều này. Vì bạn đã thực hiện nhiều thử nghiệm tự động, bạn sẽ không gặp vấn đề gì khi thực hiện các bản phát hành thường xuyên ổn định. Bạn có thể cần tăng cường hệ thống xây dựng tự động của bạn mặc dù. Tôi đặc biệt khuyên bạn nên đọc cuốn sách Giao hàng liên tục trong sê-ri Martin Fowler. Nó khó đọc và bởi vì nó cực kỳ lặp đi lặp lại, nhưng vẫn rất hữu ích. Các nhà quản lý cũng có khả năng nhận thấy rằng bạn hiện đang lập trình thậm chí nhanh hơn bạn thực sự bởi vì bạn đang nhận được nhiều bản phát hành hơn. Một lợi ích to lớn khác của việc này là bạn sẽ tốt hơn nhiều khi ước tính thời gian phát hành sẽ hoàn thành trong bao lâu và người quản lý của bạn sẽ yêu bạn vì điều này. Vì bạn đã thực hiện nhiều thử nghiệm tự động, nên bạn sẽ không gặp vấn đề gì khi thực hiện các bản phát hành thường xuyên ổn định. Bạn có thể cần tăng cường hệ thống xây dựng tự động của bạn mặc dù. Tôi đặc biệt khuyên bạn nên đọc cuốn sách Giao hàng liên tục trong sê-ri Martin Fowler. Nó khó đọc và bởi vì nó cực kỳ lặp đi lặp lại, nhưng vẫn rất hữu ích. và người quản lý của bạn sẽ yêu bạn vì điều này. Vì bạn đã thực hiện nhiều thử nghiệm tự động, nên bạn sẽ không gặp vấn đề gì khi thực hiện các bản phát hành thường xuyên ổn định. Bạn có thể cần tăng cường hệ thống xây dựng tự động của bạn mặc dù. Tôi đặc biệt khuyên bạn nên đọc cuốn sách Giao hàng liên tục trong sê-ri Martin Fowler. Nó khó đọc và bởi vì nó cực kỳ lặp đi lặp lại, nhưng vẫn rất hữu ích. và người quản lý của bạn sẽ yêu bạn vì điều này. Vì bạn đã thực hiện nhiều thử nghiệm tự động, nên bạn sẽ không gặp vấn đề gì khi thực hiện các bản phát hành thường xuyên ổn định. Bạn có thể cần tăng cường hệ thống xây dựng tự động của bạn mặc dù. Tôi đặc biệt khuyên bạn nên đọc cuốn sách Giao hàng liên tục trong sê-ri Martin Fowler. Nó khó đọc và bởi vì nó cực kỳ lặp đi lặp lại, nhưng vẫn rất hữu ích.

3) Sử dụng kỹ thuật pomodoro và điều chỉnh / thay đổi những gì không phù hợp với bạn. Nếu bạn kết hợp điều này với số 2 trong danh sách này, bạn sẽ được tăng năng suất rất lớn.

4) Học Vim. Ngay cả khi bạn kết thúc việc sử dụng các lệnh này trong Visual Studio thông qua ViEmu hoặc từ bên trong Eclipse thông qua một plugin hoặc từ bên trong Emacs, bạn sẽ đạt được năng suất. Cách tốt nhất để học Vim là bắt đầu sử dụng nó và buộc bản thân không bao giờ (vô hiệu hóa / quay lại các công cụ cũ của bạn) cho đến khi bạn thành thạo nó. Lúc đầu thật đau đớn, nhưng bạn sẽ không bao giờ muốn lùi lại, và thậm chí co rúm người lại khi bạn phải làm việc mà không có nó. Một số người sẽ nói điều này sẽ không làm tăng tốc độ của bạn lên nhiều. Nhưng nhanh hơn là nhanh hơn, đặc biệt là khi đọc và sửa đổi mã là CHÚNG TÔI LÀM GÌ và tôi đã thấy mình tiết kiệm rất nhiều thời gian với việc này.

5) Điều cuối cùng này không nhất thiết được khuyến nghị vì tôi không chắc đó là một ý tưởng hay và nó thực sự có thể làm giảm năng suất của bạn, nhưng dù sao tôi cũng sẽ thông qua nó. Bạn có thể thử làm nhiều bài kiểm tra chấp nhận và ít bài kiểm tra đơn vị hơn, hoặc có lẽ ít nhất là đảm bảo bạn thực hiện một số bài kiểm tra chấp nhận. Tôi đã thành công với SpecFlow, nhưng tôi nghi ngờ có một cái gì đó tốt hơn ngoài kia. Ngay cả việc viết các thông số kỹ thuật cũng có thể khá kỹ thuật, vì vậy bạn có thể chỉ cần người quản lý / khách hàng của bạn viết một phiên bản nháp trước mà bạn thay đổi đáng kể, hoặc bạn có thể tự viết toàn bộ nội dung và chỉ cần họ đọc và OK. Điều này sẽ giúp bạn với số 2 từ danh sách này. Ngoài ra các bài kiểm tra chấp nhận có thể thực tế hơn và yêu cầu ít mã hơn các bài kiểm tra đơn vị. Điều này không có nghĩa là họ thay thế chúng, các công cụ khác nhau cho những thứ khác nhau.

6) Điều này thậm chí còn nhiều thử nghiệm và gây tranh cãi. Tôi đã không thực sự làm điều này bản thân mình vì vậy tôi không thể chính xác đề nghị nó. Tìm hiểu và sử dụng Hệ thống lập trình Meta từ JetBrains. Sử dụng nó để tạo các công cụ mà người quản lý / khách hàng của bạn sử dụng để tự tạo phần mềm mong muốn. Bạn thậm chí có thể dừng thực hiện các bài kiểm tra đơn vị và chấp nhận nếu bạn có thể sử dụng công cụ này để tạo các công cụ mà người quản lý / khách hàng của bạn sử dụng để chỉ định hành vi theo cách rất đơn giản và không phức tạp. Ý tưởng là không thoát khỏi lập trình viên. Các lập trình viên vẫn cần thêm các tính năng mới cho các công cụ này được sử dụng bởi khách hàng / người quản lý bất cứ khi nào họ (mọi người, không phải công cụ) không thể dễ dàng tạo ra một số chức năng mong muốn. Tôi tin rằng MPS hoặc các công cụ khác tương tự như vậy là tương lai.

Sử dụng bộ não của bạn nhiều hơn và làm ít thử nghiệm. Thành thật mà nói, thử nghiệm có vị trí của nó, nhưng nó đắt tiền.

Ngoài ra, hãy đọc Nghệ thuật lập trình Unix (trực tuyến miễn phí, cuốn sách đáng giá)

Cuối cùng, bạn có thể không ở đúng nơi. Chốt tròn trong công việc vuông, vv

Cuối cùng, nó giống như trường học: "Đầu ra những gì giáo viên muốn" trở thành "đầu ra những gì quản lý yêu cầu và trả tiền".

Nếu bạn thực hiện một dự án lớn, đã hoàn thành và nhận được số dòng mã "cuối cùng" mỗi giờ, bạn sẽ thấy rằng các lập trình viên mã chậm hơn nhiều so với bạn có thể tưởng tượng.

Chúng tôi đang nói chuyện chỉ một vài dòng mã mỗi ngày. Phần còn lại của thời gian bạn dành cho gỡ lỗi, viết lại và làm công cụ lập trình chung.

Bạn có thể đã nghe câu nói cũ - nếu bạn gặp lỗi trong khi gõ, nó sẽ giúp bạn tiết kiệm thời gian gấp 10 lần nếu bạn bắt được nó trong thời gian xây dựng, tốt hơn gấp 10 lần so với bắt lỗi trong QA, tốt hơn gấp 10 lần hơn là bắt nó sau khi phát hành ..

Vậy làm thế nào để bạn tăng tốc nó lên? Tôi sẽ không tập trung vào bất kỳ hình thức tốc độ gõ nào - giảm lỗi và cải thiện các "tương tác" khác trong mã của bạn sẽ là một sự đầu tư tốt hơn nhiều cho thời gian của bạn.

Có thể đọc, mã rõ ràng là rất quan trọng. Bạn viết mã của bạn một lần, nhưng nó sẽ được đọc hàng chục lần. Viết để dễ đọc sẽ giúp bạn tiết kiệm rất nhiều rắc rối (điều này cũng sẽ tiết kiệm rất nhiều thời gian). Nếu bạn CỨ hãy quay lại và đọc mã của bạn và phải suy nghĩ về nó dù chỉ một giây thì bạn đã làm sai.

Lập trình cặp có thể giảm thời gian QA và, nếu bạn xem xét một lập trình viên chỉ tạo ra một vài dòng mỗi ngày, nếu hai người có thể viết mã với tốc độ như một nhưng với ít lỗi hơn thì bạn sẽ đi trước.

Mã hóa phòng thủ (ví dụ, kiểm tra tham số) có thể làm giảm các vấn đề ... Nếu bạn có một nhà phân tích / kiến ​​trúc sư thực sự giỏi trong nhóm của mình thì bạn có thể tiết kiệm thời gian với một thiết kế khởi đầu tốt.

Nếu không, hãy tiếp tục cải thiện kỹ năng thiết kế của bạn. Khi bạn có được kinh nghiệm, bạn sẽ thấy mình có thể nhận ra các mô hình không hoạt động và tránh chúng nhiều hơn, bạn sẽ có thể xác định thời gian chìm sớm hơn, v.v.

Bạn đã xem xét việc kiểm toán chi tiết bản thân khi bạn làm việc chưa? Theo dõi bằng bút và giấy về cách bạn đang dành thời gian hoặc sử dụng một cái gì đó như Thời gian giải cứu để theo dõi chính mình.

Một khi bạn nhận thức rõ hơn về chính xác CÁCH bạn dành thời gian, bạn có thể có được ý tưởng tốt hơn về những gì cần cải thiện và tập trung nỗ lực của bạn ở đó.

Lý tưởng nhất là bạn có thể thách thức một số đồng nghiệp của mình cũng làm điều này, so sánh kết quả của bạn và lấy ý tưởng từ nhau. Bạn có thể có một số điểm mạnh mà họ có thể được hưởng lợi từ quá.

Có thể bạn phát hiện ra rằng bạn đang dành quá nhiều thời gian cho một phần của quy trình có thể được tự động hóa hoặc chỉ là bạn có nhiều phiền nhiễu trong một phần nhất định trong ngày và một phần khác trong ngày là yên tĩnh, sau đó bạn có thể lập kế hoạch cho các nhiệm vụ của mình đó, v.v.

Hoặc có thể bạn phát hiện ra rằng thử nghiệm mất nhiều thời gian hơn bạn nghĩ và bạn phải suy nghĩ lại về nhận thức của mình rằng nó đang làm cho bạn nhanh hơn.

Nếu không có gì khác, nó cung cấp cho bạn một số điểm chuẩn bạn có thể làm việc chống lại.

Từ danh sách của bạn, bạn đang làm tốt.

Nếu đồng nghiệp của bạn đang tạo mã với số CRAP cao hơn, họ sẽ đi nhanh hơn. CRAP là một số liệu có tên hài hước kết hợp độ phức tạp chu kỳ và phạm vi kiểm tra.

Đừng viết mã nhiều CRAP hơn bạn phải làm. ;)

Thay đổi duy nhất của tôi để đề xuất cho bạn là sử dụng các thư viện, đừng viết chúng trừ khi:

1. Công ty của bạn bán thư viện
2. Bạn đã tái cấu trúc mã định kỳ vào thư viện

Bạn đang đọc và làm và điều đó thật tuyệt. Nhưng bạn có thể bị mắc kẹt khi nghĩ về mã nguồn hoặc mã OO, Bạn đã tiếp xúc với lập trình chức năng (nói Haskell?) Và Prolog?

Để cải thiện kỹ thuật lập trình OO của bạn, bạn đã chơi với Smalltalk / Squeak chưa?

Và cuối cùng là lý thuyết. Bạn có ít nhất một sự hiểu biết thô sơ về lý thuyết đồ thị? (Một số chương trình hoạt động với cây, DAG hoặc chỉ là biểu đồ đơn giản tại một số điểm. Mạng là biểu đồ)

Tôi sẽ trích dẫn chú Bob :

Cách duy nhất để đi nhanh là đi tốt.

Mỗi khi bạn cảm thấy bị cám dỗ để đánh đổi chất lượng lấy tốc độ, bạn sẽ chậm lại. Mỗi lần.

- "Tầm thường trung thành", Robert C. Martin

Theo như tôi biết thì đó là:

1. tốt
2. Nhanh
3. rẻ

Là người quản lý, bạn có thể chọn bất kỳ 2.

Đừng lo lắng về những bình luận bạn đã nhận được về tốc độ. Là một lập trình viên đồng nghiệp, tôi thà duy trì mã được suy nghĩ kỹ và viết tốt hơn là một cái gì đó được vỗ vào nhau.

Những điều chính tôi có thể nghĩ là như sau

• Tăng tốc độ gõ của bạn.
• Sử dụng các công cụ cung cấp tăng năng suất. Ví dụ ReSharper.
• Máy hoặc công cụ nhanh hơn. Giống như nhiều RAM hoặc ổ đĩa trạng thái rắn.

Tôi chắc chắn có một số điều bạn có thể làm trong lĩnh vực kỹ năng mã hóa, nhưng có vẻ như bạn là tất cả những thứ đó. Những điều tôi liệt kê ở trên thường bị các nhà phát triển bỏ qua.

Bạn có thể tham gia một khóa học tốc độ. Tôi không biết nếu gõ nhanh hơn có vấn đề hay không nhưng "mã hóa quá chậm" có thể là do tốc độ gõ chậm.

Còn máy tạo mã thì sao? Đôi khi mã được lặp đi lặp lại. Tái cấu trúc có thể loại bỏ một số trong số đó, nhưng thậm chí sau đó bạn có thể có các cuộc gọi lặp đi lặp lại đến cùng chức năng tái cấu trúc. Tùy thuộc vào dữ liệu và mã bạn làm việc với, các trình tạo mã (được viết bằng Excel, Perl, Java, bất cứ điều gì ...) có thể tiết kiệm rất nhiều thời gian. Và sử dụng các công cụ tạo mã để phát triển UI thường là không có trí tuệ.

Và cuối cùng, có thể các số liệu là sai. Bạn có từng nghĩ rằng bạn đang mã hóa ở tốc độ nhanh có thể đưa ra mọi thứ khác và các mốc thời gian quá ngắn, khiến bạn có vẻ là một lập trình viên chậm?

Dựa trên các chỉnh sửa trong câu hỏi của bạn, có vẻ như bạn có thể theo lộ trình của một số đồng nghiệp của mình và cùng nhau tìm ra giải pháp nhanh nhất sẽ hoạt động - và tài liệu và QA bị nguyền rủa!

Hoặc ... có thêm kinh nghiệm và thực hành trong một khu vực cụ thể để bạn biết cơ sở mã và API tốt đến mức bạn có thể mã hóa các giải pháp trong giấc ngủ của mình. Điều này có thể được thực hiện nhưng đòi hỏi nhiều thời gian hơn. Nếu các nhà phát triển khác nhanh hơn bạn được biết là cao cấp hơn và có nhiều kinh nghiệm hơn thì chỉ có một việc cần làm - bạn phải trở nên cao cấp và có kinh nghiệm hơn!

Tôi phản đối quan điểm "hy sinh chất lượng vì tốc độ" của OP.

Các lập trình viên chuyên nghiệp (lập trình viên) cần thỏa mãn 3 đối tượng:
1) Mã phải chạy như dự định
2) Giao hàng phải đúng lúc
3) Có chất lượng tốt, tài liệu, v.v.
4) Khác v.v.

Tôi nghĩ, OP bị chê là chậm vì có lẽ OP đã không làm kịp.

Đây là một cái bẫy 22 rất khó để có được xung quanh. Mặc dù bạn vẫn có thể thiếu kinh nghiệm và một số lượng kiến ​​thức ở nhiều khía cạnh đã nhanh hơn hầu hết, nhưng điều khó hiểu là khó đo lường hơn .

Cá nhân tốt nhất bạn có thể làm vào thời điểm này là để đo lường chính mình. Cung cấp cho bản thân thông tin phản hồi về cách bạn làm việc, có lẽ những thay đổi đơn giản trong thói quen làm việc của bạn có thể giúp bạn làm việc hiệu quả hơn.

Tôi thấy thư đã ăn đi nhiều hơn tôi nghĩ đơn giản chỉ vì sự gián đoạn. Bây giờ tôi chỉ trả lời thư hai lần một ngày và đạt được gần 1 giờ năng suất một số ngày. Hãy thử các phương pháp như pomodoro , tôi đã sử dụng nó như một biện pháp có nghĩa. Trong khoảng thời gian đều đặn (15 phút) tôi sẽ ghi lại những gì tôi đang làm vào thời điểm đó. Điều này cho phép tôi thấy ngày của tôi được cấu trúc như thế nào và tôi có thể làm gì để tối đa hóa hiệu quả.

Lợi thế của Squeak về mã hóa nhanh vượt xa chỉ là "mài giũa kỹ năng OOP của một người". Có một lý do tại sao GUI hiện đại, cũng như IDE, được phát minh trên Smalltalk, chưa kể JUNIT là một cổng của SUNIT sang Java, thuật ngữ "OOP" được phát minh để mô tả Smalltalk, v.v., v.v.

Người ta phải luôn luôn sử dụng ngôn ngữ và môi trường phù hợp nhất cho bất kỳ điều gì mà người ta hy vọng đạt được, nhưng đối với nguyên mẫu chung, ít nhất, tôi sẽ phù hợp với bất cứ điều gì, ngoại trừ HyperCard, và thậm chí điều đó sẽ yêu cầu điểm chuẩn để xem đó là gì thực sự nhanh hơn khi có các tiện ích giống như hypercard được tích hợp trong Squeak.