Làm thế nào để trở thành một lập trình viên nhanh hơn

Đánh giá công việc cuối cùng của tôi chỉ bao gồm một điểm yếu: tính kịp thời. Tôi đã nhận thức được một số điều tôi có thể làm để cải thiện điều này nhưng những gì tôi đang tìm kiếm còn nhiều hơn nữa.

Có ai có lời khuyên hoặc lời khuyên về những gì họ làm để tăng tốc độ đầu ra mà không làm giảm chất lượng của nó không?

Làm thế nào để bạn ước tính thời gian và bám sát chúng? Bạn làm gì để hoàn thành công việc nhiều hơn trong khoảng thời gian ngắn hơn?

Bất kỳ thông tin phản hồi được đánh giá rất cao, cảm ơn,

Tắt máy tính. Lấy một cây bút chì và một số giấy. Phác thảo thiết kế của bạn. Xem lại nó với các đồng nghiệp của bạn. Sau đó viết mã.

Một vài ý tưởng...

• Tránh mạ vàng - chỉ làm những gì được yêu cầu của bạn (về yêu cầu)
• Hiểu các yêu cầu kinh doanh và làm điều đó ngay lần đầu tiên
• Hiểu thấu đáo môi trường và công cụ của bạn
• Trở thành một người đánh máy tuyệt vời, sử dụng phím tắt thay vì chuột
• Thực hiện một cách tiếp cận lặp đi lặp lại và xây dựng trong kiểm tra độ tỉnh táo để đảm bảo bạn đang đi đúng hướng
• Đừng phát minh lại bánh xe, xem xét sử dụng lại công việc trong quá khứ và công việc của người khác
• Loại bỏ phiền nhiễu, đừng tiếp tục kiểm tra email, nhìn ra ngoài, nói chuyện với đồng nghiệp, v.v.
• Đừng làm việc quá sức - nhận ra khi nào bạn cần nghỉ ngơi

Mong muốn trở thành một lập trình viên "nhanh hơn" của chính bạn là điều đáng khen ngợi. Tuy nhiên, không giao hàng đúng hạn không có nghĩa là bạn chậm, điều đó có nghĩa là dự án được lên kế hoạch kém. Trở thành một lập trình viên "nhanh hơn" sẽ không giúp ích gì; nó chỉ có nghĩa là bạn sẽ vượt quá thời hạn nhanh hơn.

Bạn (và nhóm của bạn) đang mắc một trong những lỗi sau (hoặc tất cả các lỗi đó):

• đánh giá thấp công việc cần phải làm;
• thiếu một yêu cầu lớn hoặc phần kiến ​​trúc trong quá trình lập kế hoạch;
• ước tính công việc khó hiểu với ước tính lịch và không hạch toán cho những thứ như cuộc họp / điện thoại / chi phí khác;

Có nhiều cách bạn có thể giải quyết bất kỳ trong ba cách trên. Nhưng trước khi bạn có thể cải thiện bất kỳ vấn đề nào trong số họ, bạn cần biết lý do tại sao mọi thứ đang diễn ra như vậy. Thực hiện một postmortem trên hai hoặc ba dự án cuối cùng so với thời gian thực tế và tìm ra thời gian thêm đã đi.

Tôi sẽ lặp lại một lần nữa - việc chậm viết mã sẽ không gây ra thời hạn , nếu bạn đã lên kế hoạch đúng để giải thích cho thực tế đó.

Thực sự, thực sự học trình soạn thảo của bạn. Nếu bạn sử dụng IDE, hãy đảm bảo bạn đang sử dụng tất cả các tính năng mà nó cung cấp. Nhận một bảng cheat để tìm hiểu các phím tắt cho trình soạn thảo bạn chọn. Nếu bạn đang sử dụng trình bao, hãy thiết lập các phím tắt cho các thư mục thường được sử dụng

"Có ai có lời khuyên hoặc lời khuyên về những gì họ làm để tăng tốc độ đầu ra mà không làm giảm chất lượng của nó không?"

Nhiều, nhiều người phấn đấu cho chất lượng "tối thượng" với chi phí của một cái gì đó (a) đơn giản, (b) đáng tin cậy và (c) chính xác.

Cách quan trọng nhất để tăng tốc độ phát triển của bạn là đơn giản hóa những gì bạn đang làm để nó hoàn toàn đơn giản nhất có thể.

Hầu hết mọi người có vấn đề với việc giao hàng đúng hạn đều cung cấp cách thức, cách quá nhiều. Và những lý do được đưa ra thường là ngớ ngẩn. Họ thường chỉ nhận thức được yêu cầu, không phải yêu cầu thực tế.

Tôi đã nghe rất nhiều người nói với tôi những gì khách hàng "mong đợi". Đây là một chính sách tồi.

Xây dựng điều đơn giản nhất có thể. Nếu khách hàng yêu cầu nhiều hơn, xây dựng nhiều hơn. Nhưng xây dựng điều đơn giản nhất có thể đầu tiên.

Tránh đánh bóng mã của bạn để hoàn thiện, chỉ làm cho nó hoạt động. Đó là những gì doanh nghiệp mong đợi.

Nhưng thông thường, tăng tốc độ ngụ ý hy sinh chất lượng.

Tái sử dụng - Tôi cố gắng tìm ra bất kỳ bit thông minh nào từ các dự án trước đó, vì vậy tôi có thể sử dụng lại chúng trong các dự án trong tương lai. Luôn luôn đáng để tự hỏi "tôi có thể sử dụng nó một lần nữa vào một ngày nào đó không?"

Giữ cho nó đơn giản.

Nếu bạn sử dụng TDD, bạn nên theo " đỏ, xanh lục, tái cấu trúc ":

1. Viết một bài kiểm tra thất bại ( màu đỏ ). (Thường cho chức năng mà mã của bạn chưa có.)
2. Cam kết tội phạm mã hóa khủng khiếp để vượt qua các bài kiểm tra của bạn ( màu xanh lá cây ). Mã cứng nếu cần thiết.
3. Refactor , có thể phá vỡ các thử nghiệm trong một thời gian ngắn, nhưng tổng thể cải thiện thiết kế.

Tải xuống tất cả tài liệu ngôn ngữ / thư viện của bạn cục bộ về máy tính của bạn, sau đó rút cáp mạng / tắt Wi-Fi .

Không cố tỏ ra buồn cười ở đây. Điều này thực sự giúp tôi!

Lưu ý khi bạn đã đọc Stack Overflow quá lâu. Cái cớ "Biên dịch" chỉ hoạt động quá lâu. :)

Tránh chuyển đổi nhiệm vụ quá thường xuyên. Sự mất tập trung và chuyển đổi nhiệm vụ có thể giết chết một ngày, ngay cả khi bạn sử dụng các công cụ như Mylyn để quản lý các nhiệm vụ của mình.

Chỉ ra mức độ chi tiết (ví dụ: 30 phút) và chỉ làm việc trên những thứ liên quan đến nhiệm vụ trong tay. Bất cứ điều gì khác (báo cáo lỗi mới, email về các vấn đề khác, các vấn đề thủ tục không liên quan) đều bị trì hoãn ít nhất cho đến khi "điểm kiểm tra tiếp theo". Đảm bảo tắt thông báo email để bạn không bị hút vào.

Nó đặc biệt hiệu quả nếu bạn có một người bạn trong nhóm của mình, người sẽ cho bạn biết nếu mọi thứ thực sự tan chảy và đòi hỏi sự chú ý của bạn ngay lập tức.

Làm đúng, cách tốt nhất, lần đầu tiên. Nếu điều đó có nghĩa là bạn phải dừng lại và suy nghĩ về nó một lúc trước khi bạn bắt đầu, thì hãy làm điều đó. Hoạt động 90% thời gian.

Học cách chạm vào càng nhanh càng tốt .

Tôi sẽ làm nó vào ngày mai .

Bắt mọi thứ cũng rất hữu ích.

Dù sao tôi cũng có một khoảng chú ý ngắn, vì vậy những cuốn sách này giúp tôi giữ được thân hình của mình ... tôi đã làm gì nữa?

Luyện tập và chăm chỉ.

Bạn cần bỏ thời gian và công sức vào. Khi bạn trở nên thoải mái và tự tin hơn với bất kỳ công cụ nào bạn sử dụng, tốc độ và sự sáng tạo nên tuân theo.

Nếu bạn muốn cải thiện bất kỳ kỹ năng cụ thể nào, nó cũng có thể giúp thiết kế các bài tập cho phép bạn làm việc cụ thể về điều đó. Nếu sự chậm chạp của bạn đang trong giai đoạn thiết kế, hãy cố gắng tìm các vấn đề thiết kế để làm việc trực tuyến. Làm lại bài tập tương tự sẽ cho phép bạn hoàn thành nó nhanh hơn và tốc độ luyện tập. Cá nhân tôi thích các bài tập thuật toán của TopCoder để thực hành tốc độ lập trình tuyệt đối. Họ cũng có những thách thức về thiết kế, nhưng tôi chưa thử.

Tìm hiểu về Khu vực, tìm hiểu cách hòa mình vào đó và tìm hiểu cách nhận biết khi bạn không tham gia.

Khi tôi "ở trong khu vực", tôi cực kỳ năng suất và mã chỉ chảy ra khỏi tôi, thường thì tôi có thể nhận được 2 hoặc 3 ngày mã hóa được thực hiện trong 1 ngày. Nhưng tôi thấy rằng thường rất khó để đến nơi đó, tôi thấy mình chần chừ, bị phân tâm bởi những thứ khác (ví dụ như Stack Overflow).

Trích dẫn từ what-trick-do-you-use-to-get-mình-in-the-area

Biết IDE và khung của bạn tốt. Phải chuyển sang Google cho mọi thứ nhỏ nhặt cần có thời gian.

Emacs

Trước khi bạn bắt đầu phát triển:

• Đăng xuất khỏi hộp thư của bạn
• Tắt mọi ứng dụng khách IM
• Lịch sự yêu cầu đồng nghiệp cho bạn thời gian để tập trung
• Tất nhiên, ngừng lướt Internet

Mỗi khi bạn bị gián đoạn, bạn sẽ chậm lại vì phải mất thời gian để suy nghĩ lại. Tôi đã nghe những con số cho mỗi lần gián đoạn, tâm trí con người phải mất 5-10 phút để thiết lập lại quá trình suy nghĩ trước khi bị gián đoạn. Với nhiều thời gian cho mỗi lần gián đoạn, sẽ không mất nhiều thời gian để lãng phí cả ngày.

Mọi người trong công ty chúng tôi đã thực sự ngăn chặn thời gian trong lịch của họ và sau đó chuyển đến một phòng hội nghị trống trong vài giờ mỗi ngày.

Tìm hiểu IDE phát triển của bạn trong và ngoài. Tìm hiểu các phím tắt. Học cách sử dụng chuột ít hơn. Tôi thấy rằng điều này tiết kiệm nhiều thời gian cho tôi.

Bạn chậm hơn so với đồng nghiệp của bạn, hay ước tính của bạn quá mức?

Để sản xuất phần mềm nhanh hơn, tôi đã tìm thấy điều tốt nhất cần làm là tìm hiểu API thời gian chạy của bạn tốt nhất có thể. Đừng gõ logic danh sách khi tiện ích mở rộng LINQ sẽ làm; đừng xây dựng một nhóm người nghe sự kiện khi ràng buộc sẽ hoạt động, v.v.

Theo như ước tính, điều đó đi kèm với kinh nghiệm. Bạn có thể sử dụng phần mềm dự toán ngoài kia để giúp bạn tìm ra các ước tính tốt hơn.

Cá nhân, tôi đã tìm thấy với các nhà phát triển cấp cơ sở, lấy bất cứ ước tính ban đầu nào của họ và nhân nó lên 2, sau đó nhân đôi nó. Điều này sẽ chiếm tất cả các hoạt động học tập, hội họp, lãng phí thời gian, v.v ... Các nhà phát triển cấp cao hơn có xu hướng làm việc với hệ số 2 so với ước tính của họ.

Thông thường, câu hỏi không phải là nếu ước tính của bạn sai. Đó là tài khoản ước tính của bạn cho tất cả những điều đúng? Bạn đang đưa ra ước tính và thời gian của bạn về nỗ lực mã hóa hoặc về thời gian lịch? Hãy suy nghĩ về tất cả thời gian trong ngày của bạn và bao nhiêu trong số đó là thực tế, mã hóa hiệu quả so với các cuộc họp, học tập, gỡ lỗi, v.v.

Hai điều có thể được ngụ ý, nhưng tôi chưa thấy trong số các câu trả lời ở đây giúp tăng năng suất là:

• Sử dụng một số loại kịch bản xây dựng và triển khai. Biên dịch, triển khai, khởi động lại máy chủ ứng dụng và không cần thời gian hay sự tập trung, đó chỉ là một kiểu bấm chuột.

• Có một số loại kiểm soát phiên bản. Phải viết mã mà không thể quay lại thay đổi cũng giống như cố gắng đi trên trứng

Một vài ý tưởng nảy ra trong đầu:

1. Lấy ý kiến ​​khác về ước tính của bạn - Có nhà phát triển nào khác mà bạn có thể hỏi điều gì đó như "Này, bạn có nghĩ rằng bạn có thể thực hiện loại tính năng này trong khung thời gian này không?" Ý tưởng là đầu vào của người khác có thể giúp chính xác trong một số trường hợp vì ai đó có thể lưu ý một loạt điều bạn đã bỏ lỡ khi đưa ra ước tính.

2. Rèn luyện kỹ năng ước tính của bạn - Bắt đầu theo dõi xem bạn đang ước tính như thế nào và tại sao bạn lại nghỉ: Các mục công việc khác gây ra thời hạn không được đáp ứng? Bạn luôn đánh giá thấp sự phức tạp của một cái gì đó? Bạn có đưa ra toàn bộ dòng thời gian khi nó không thực tế, ví dụ những gì được hỏi đủ mơ hồ rằng chỉ cần lấy một nguyên mẫu sẽ mất vài tuần và sau đó cần phải đánh giá lại những gì khác sẽ được thực hiện? Làm điều này có thể giúp ích nhiều nhất trong việc xây dựng kỹ năng đó để nếu bạn nói điều gì đó sẽ mất x giờ, bạn có thể tự tin vào điều đó bởi vì bạn đã làm đi làm lại nhiều lần. Một cách khác để nói điều này chỉ đơn thuần là thực hành, thực hành, thực hành.

Cấp cho bạn có thể đã xem xét những điều này, nhưng tôi chỉ nghĩ rằng nó đáng để nói điều này cho những người khác có thể không xem xét những ý tưởng này.

1. Biết công nghệ từ trong ra ngoài.
2. Dừng lại! Hãy suy nghĩ! Đi!
3. Kiến trúc sư cho bất cứ điều gì có thể phát sinh, nhưng chỉ thực hiện những gì thực sự được yêu cầu.
4. KISS - Giữ cho nó đơn giản ngu ngốc
5. Nếu nó đang trở nên quá phức tạp, có lẽ, nó không được suy nghĩ tốt. (Quay trở lại 2 và 4)
6. Đừng mắc kẹt trong 5. Nó thường trả tiền để bắt đầu lại từ đầu (Quay lại 2 và 4)
7. Quay trở lại 1.

Tôi nghĩ từ khóa của họ ở đây là "tính kịp thời". Họ không nói bạn quá chậm, đúng hơn là bạn không kịp.

Trong quản lý dự án, điều quan trọng là người quản lý có thể ước tính khi nào các mục công việc của bạn sẽ được hoàn thành với độ chính xác. Tôi nghi ngờ rằng lý do chính khiến những nỗ lực của bạn không được coi là kịp thời là bạn thường xuyên có những món đồ không được giao đúng tiến độ và được giao muộn hơn nhiều so với lịch trình.

Để cải thiện tính kịp thời của bạn, bạn có thể muốn dành nhiều thời gian hơn để hiểu bạn sẽ mất bao lâu để hoàn thành một mục công việc cụ thể dựa trên kỹ năng, kinh nghiệm và tên miền của bạn. Điều này sẽ cho phép bạn đưa ra ước tính tốt hơn cho người quản lý dự án của bạn. Chìa khóa ở đây là "tốt hơn" ... bạn có thể giao hàng đúng giờ thường xuyên hơn bằng cách đệm mọi thứ với yếu tố mờ nhạt, nhưng điều bạn thực sự muốn phấn đấu là ước tính chính xác hơn.

Tôi sẽ thảo luận điều này với người quản lý của bạn để xem đây có thực sự là vấn đề không. Mặt khác, bạn có thể kết thúc chương trình nhanh gấp đôi, những điều hứa hẹn trong một nửa thời gian bạn đã sử dụng và vẫn bị chỉ trích vì tính kịp thời của bạn vì ước tính của bạn vẫn có cùng hệ số lỗi.

Nhận ổn định, ổn định.

Xây dựng một cái gì đó thực hiện một chút chức năng và đảm bảo rằng nó hoạt động, từ đầu đến cuối. Sau đó, giữ cho nó hoạt động khi bạn thêm các bit mới của chức năng. Vâng, đây là một phần thực hành TDD, nhưng nó có ý nghĩa ngay cả khi bạn không làm TDD.

Lý do là mỗi lần tôi đã nhìn thấy một người nào đó với 2 tuần mã mà chưa bao giờ ổn định, nó luôn luôn mất thêm khoảng 2 tuần để có được nó ổn định.

Nếu bạn ở lại ổn định, bạn loại bỏ sự không chắc chắn rằng, và cũng có thể cung cấp cho mình một cách để phạm vi xuống gần thời hạn nếu cần thiết.

Đối số rõ ràng là việc làm này sẽ mất nhiều thời gian hơn là chỉ viết một lần, vì bạn sẽ làm thêm việc ổn định mã không phải là cuối cùng. Tôi không mua cái này trong một giây. Khi bạn có mã hoạt động , bạn thay đổi 5 dòng và một cái gì đó bị phá vỡ, bạn biết chính xác nơi nghỉ phải xảy ra.

Nếu bạn có 10.000 dòng mã không bao giờ hoạt động và bạn phải tìm cách ngắt, bạn có rất nhiều mã để tìm kiếm.

Những thay đổi nhỏ, gia tăng trên một hệ thống luôn ổn định FTW. Đi chậm để đi nhanh.

Đối với tôi, có được năng suất tốt là có một ý tưởng rõ ràng về những gì bạn đang cố gắng đạt được, và làm thế nào bạn sẽ đạt được điều đó.

Gần như tất cả các câu trả lời đã được nói đến cái chết ở nhiều nơi ở đây và những nơi khác. Hoặc, ít nhất tôi đã nghe thấy nó đến chết. Tìm hiểu IDE của bạn, học cách gõ nhanh hơn, sử dụng các khung công tác, sử dụng tạo mã, v.v., vâng, tất nhiên những điều này sẽ giúp ích và tôi nghi ngờ có rất nhiều lập trình viên là bậc thầy của tất cả. Nhưng là loại lập trình viên hỏi những câu hỏi và trang web thường gặp như Stack Overflow bạn đã biết những điều này rồi . Bạn chỉ muốn ở đây họ lặp đi lặp lại hay bạn chỉ muốn trút giận một chút?

Nhưng nếu chúng ta có thể đến trạng thái đó thì sao? Tôi có nghĩa là chủ tất cả những đề nghị? Điều gì sẽ xảy ra sau đó? Tốt. Tôi đoán rằng dòng thời gian sẽ còn giảm hơn nữa. Và một lần nữa, chúng tôi sẽ trở lại nhận thức về chất lượng. Ý tôi là, nghề của chúng tôi chắc chắn đã tiến bộ và ngày càng có năng suất cao hơn trong nhiều thập kỷ. Nhưng chất lượng đã tăng lên trong thời gian này (trừ những năm đầu tiên của khóa học)?

Câu trả lời của tôi rất đơn giản: phần mềm chất lượng cần có thời gian ! Bạn chỉ có thể đổi cái này lấy cái kia (chất lượng / tốc độ). Nhưng vâng, tất cả chúng ta đều biết rằng tuy nhiên chúng ta không trung thực về mức độ mà sự đánh đổi thường kết thúc ở tốc độ cuối của thang đo. Và chúng tôi thậm chí còn nói dối lớn hơn sớm trong các dự án!

Tôi nói rằng bạn không có lỗi ở đây. Vấn đề là nhận thức của mọi người về việc phần mềm chất lượng phải mất bao lâu. Chúng tôi tự đánh lừa mình khi tin rằng chúng tôi có khả năng tạo ra phần mềm chất lượng với các loại dòng thời gian mà người quản lý của chúng tôi hoặc thậm chí chúng tôi dự đoán. Chúng tôi không tạo ra phần mềm chất lượng . Chúng tôi viết phần mềm hoạt động nhưng đôi khi có chất lượng nhấp nháy ở một số góc nhất định của ứng dụng.

vậy chúng ta có thể làm gì? Chúng tôi không thể thuyết phục các ông chủ của mình rằng chúng tôi cần tăng gấp đôi hoặc gấp ba khoản đầu tư vào mỗi dự án của mình. Tôi nói dẫn bằng ví dụ. Tạo một phần mềm thực sự tuyệt vời như một dự án phụ. Đặt thời gian của riêng bạn vào đó và không thỏa hiệp. Tất cả trong khi chú ý đến cách bạn tiến bộ. Lưu ý về các nhiệm vụ rõ ràng không liên quan mà bạn đã phải đặt một lượng thời gian không mong muốn vào và xem liệu bạn có thể biện minh được không. Tương phản điều này với tất cả các dự án khác mà bạn đã làm việc. Hãy trung thực một cách tàn nhẫnvới bản thân và tất cả các khía cạnh của phân tích này. Những điều bổ sung bạn đã làm với phần mềm chất lượng của bạn có thể bị bỏ qua trong các dự án "thực tế" tại nơi làm việc không? Nhưng có thể nỗ lực của bạn đã thất bại. Nguyên nhân gì vậy? Bạn đã chán và chỉ cần vội vàng để hoàn thành các tính năng cốt lõi? Tôi vẫn chưa làm điều gì đó như thế này, đó là lý do tại sao tôi kết thúc suy nghĩ này với một số nghi ngờ - nhưng tôi dự định sẽ thực hiện nó. Tôi sẽ giữ cho bạn được đăng :).

Cuối cùng, tôi nghĩ rằng hầu hết (nếu không phải tất cả) các đánh giá hiệu suất đều bị xoắn và thao túng lạ thường. Bạn không thể điều tiết chất lượng và tốc độ ở mức 100%. Sếp của bạn nên chấm điểm bạn theo một tiêu chuẩn do tổ chức đặt ra. Tiêu chuẩn của tổ chức về sự đánh đổi giữa chất lượng và tốc độ. Hãy tưởng tượng rằng OrangeSoft Inc. mong đợi chất lượng 33% và tốc độ 66%. Vì vậy, nếu bạn đang viết mã có thể có một phần ba đơn vị kiểm tra thì nên thực hiện với tốc độ và giảm thời gian giao hàng, bạn nên đạt điểm gần 100% trong bài đánh giá của mình! (Đây là những tương tự khá thô nhưng bạn có được điểm). Nhưng thay vào đó, những gì xảy ra là Bob viết mã cực kỳ nhanh nhưng lại nổi tiếng là lỗi. Vì vậy, trong bài đánh giá hiệu suất của mình, anh ấy sẽ đạt điểm 3/5 cho chất lượng và 5/5 cho tốc độ. Mặt khác, Carol viết mã chậm hơn nhiều nhưng tạo ra ít lỗi hơn đáng kể. Cô đạt điểm 5/5 cho chất lượng nhưng 3/5 cho tốc độ. Dù bằng cách nào thì Bob và Carol cũng được thả neo. Có thể cho bất kỳ nhân viên để có được một số điểm hoàn hảo? Điều này có công bằng không?

Kỹ thuật mà tôi sử dụng là tạo mẫu tiến hóa

Bạn có thể google để biết thêm thông tin - nhưng nếu nhu cầu là sản xuất một cái gì đó nhanh chóng, đó là cách duy nhất để đi. Thêm vào đó, nó có lợi ích là khi người dùng nói rằng anh ta thích nó, bạn đã hoàn thành (... và có thể bắt đầu làm tài liệu).