it-swarm-vi.com

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 nhiều việc 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,

142
Nick Gotch

Tắt máy tính. Lấy một cây bút chì và một ít 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ã.

190
gatorfax

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 - hãy nhận ra khi nào bạn cần nghỉ ngơi
149
Mayo

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 hoàn thành;
  • thiế 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;
  • khó hiể ước tính công việc 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ỳ 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 về hai hoặc ba dự án cuối cùng so với thời gian thực tế được thực hiện và tìm ra thời gian thêm đã đi đâu.

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

132
Franci Penov

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 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 Shell được thiết lập các phím tắt cho các thư mục thường được sử dụng

89
slashnick

"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 sao cho nó hoàn toàn đơn giản nhất có thể.

Hầu hết những 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.

38
S.Lott

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.

32
user8685

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?"

29
Phil Jenkins

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

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

  1. Viết một bài kiểm tra thất bại (đỏ). (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ế.
24
bryanbcook

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!

22
mcjabberz

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. :)

20
Matthew Jones

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ú ý ngay lập tức của bạn.

20
Uri

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.

14
ck01
14
AJ Johnson

Tôi làm vào ngày mai .

Bắt mọi thứ đã hoàn thành cũng vô cùng 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?

12
Matthew Jones

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 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ử.

12
DisplacedAussie

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

11
Dustin Getz

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

10
Mike Hall
9
ZeroCool

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 IM client
  • 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 rất 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.

8
dhable

Tìm hiểu sự phát triển của bạn IDE vào và ra. 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 giúp tôi tiết kiệm nhiều thời gian.

7
D3vtr0n

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?

7
pjc50

Để 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.

7
James Schek

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 mất thời gian hay 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

7
Buhb

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 có luôn đánh giá thấp mức độ 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 là đủ mơ hồ rằng chỉ đơn giản là đưa một nguyên mẫu lên 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.

7
JB King
  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 bị 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.
7
Rui Craveiro

Tôi nghĩ rằng 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.

7
Larry Watanabe

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 thấy ai đó có 2 tuần mã chưa bao giờ ổn định, luôn phải mất thêm 2 tuần nữa để get nó ổn định.

Nếu bạn ở lại ổn định, bạn sẽ loại bỏ sự không chắc chắn đó, đồng thời cung cấp cho mình một cách để giảm phạm vi 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 mà sự phá vỡ phải xảy ra.

Nếu bạn có 10.000 dòng mã chưa bao giờ hoạt động và bạn phải tìm một dấu 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.

7
kyoryu

Đố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 đó.

7
mdma

Khá nhiều 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 (không bao gồm 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 thang. 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 mọi người có phần mềm chất lượng nên 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 ý 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. Be trung thực một cách thô bạo với chính bạ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ể tăng tốc chất lượng và tố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 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?

6
Thiru

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).

5
slashmais

Nút thắt thời gian của bạn là gì? Tôi thấy rằng suy nghĩ là nút cổ chai thông thường của tôi, vì vậy cải thiện tốc độ gõ của tôi (đã tốt) sẽ chẳng làm được gì. Mặt khác, nếu việc gõ không nhanh và tự nhiên đối với bạn, nó cũng có thể làm bạn chậm lại.

Bạn đang cố gắng để làm nhiều hơn được yêu cầu? Thông thường, một doanh nghiệp sẽ muốn có nhiều công việc tốt từ bạn hơn là công việc ít hơn nhưng được đánh bóng hơn và thêm các tính năng sẽ không được sử dụng sẽ lãng phí thời gian và tiền bạc mà không có lợi nhuận kinh doanh.

Bạn đang quá vội vàng? Dưới áp lực thời gian, mọi người thường xuyên tiết kiệm thiết kế và lên kế hoạch trước, hy vọng rằng dù sao nó cũng sẽ hoạt động được. Nó thường không.

Bạn đang xử lý thời gian đúng cách? Phát triển đòi hỏi khối lượng thời gian suy nghĩ không bị gián đoạn, hoặc bạn sẽ không hiệu quả, và do đó chậm.

5
David Thornley

Đọc cuốn sách tuyệt vời của Neal Ford Lập trình viên năng suất .

Nó chứa rất nhiều lời khuyên hữu ích.


Biên tập:

Và, như đã đề cập ở nơi khác, hãy đọc tài liệu cho các công cụ của bạn. Tôi luôn học hỏi những điều mới cho Vim bằng cách đọc các wiki của Vim. Tương tự, chỉ cần đọc qua trang man cho bash hoặc zsh luôn đưa ra các thủ thuật mới để sử dụng.

4
Rob Wells

Tôi đã đọc một cái gì đó từ lâu về việc tối ưu hóa thực sự mắc kẹt với tôi. Tôi không nhớ nguồn hoặc từ chính xác, nhưng ý chính của nó là, "Cách duy nhất để làm cho chương trình chạy nhanh hơn là làm cho nó ít hơn. Mọi kế hoạch khác chỉ là như vậy." Con người cũng vậy. Quân đội cũng có một câu nói: "Sự vội vàng làm lãng phí". Làm những việc tương tự chúng ta làm bây giờ, nhưng nhanh hơn, sẽ chỉ tạo ra vấn đề. Có nhiều kế hoạch khác nhau để trở nên hiệu quả hơn ngoài kia, và tôi không nói rằng chúng không hiệu quả, nhưng chúng sẽ không phù hợp với nhu cầu của bạn. Tốt hơn hết là bạn nên nhìn vào những gì bạn làm và tìm ra những việc bạn làm không hiệu quả và loại bỏ chúng. Bất kỳ kế hoạch nào khác chỉ là một phiên bản giảm nước.

4
Imagist

Đây là những gì làm việc cho tôi:

  1. Chia công việc của bạn thành các nhiệm vụ nhỏ được (1) xác định trong phạm vi (2) ngắn - ví dụ: 2 giờ.
  2. Bắt đầu ngày mới bằng cách viết chúng ra giấy, theo thứ tự. Vẽ một số dòng thông qua - những thứ bạn muốn hoàn thành trước bữa trưa, những thứ bạn sẽ hoàn thành vào cuối ngày, v.v.
  3. Làm việc danh sách của bạn, vượt qua các mục khi bạn đi.
  4. Những thứ trong hộp thời gian - nếu thứ gì đó bắt đầu kéo, hãy tự giới hạn thời gian nghiên cứu trước khi bạn yêu cầu trợ giúp hoặc giải quyết theo cách đơn giản hơn.
  5. Nếu có thể, hãy cấu trúc công việc của bạn để bạn công khai cam kết với các khung thời gian này - nhập ước tính trong theo dõi lỗi, v.v.
  6. Nếu bạn bắt mình giết thời gian nghiên cứu, đọc, v.v., thì hãy đảo ngược thứ tự - ví dụ, cho phép bạn tự thưởng 10 phút nếu bạn hoàn thành thành công nhiệm vụ 1 giờ theo lịch trình.

Tôi đã thấy một số ý kiến ​​rằng bạn nên dành ít thời gian hơn cho Stack Overflow. Nếu bạn đang sử dụng đúng, Stack Overflow sẽ giúp bạn hiệu quả hơn chứ không phải ít hơn. Tránh xa các cuộc thảo luận và tập trung vào việc sử dụng nó để hoàn thành công việc.

3
Jon Galloway

Đừng lặp lại chính mình

Tái sử dụng tài sản dự án cũ.

Hãy dành một ngày để học IDE của bạn. Nếu nó không cung cấp các công cụ như snipets, mã tự động hoàn thành ... hãy xem xét nhận một công cụ mới.

Đặt phím tắt cho mọi thứ ở những vị trí quan trọng để bạn có thể truy cập mọi thứ nhanh hơn.

Nhận một màn hình thứ hai nếu đó không phải là trường hợp.

Đừng kiểm tra email của bạn quá thường xuyên.

Hãy thử tập trung vào chỉ một nhiệm vụ tại một thời điểm. Nếu điều này là không thể, hãy theo dõi chặt chẽ những gì bạn đang làm và không bị lạc giữa 15 nhiệm vụ không liên quan.

Sử dụng giấy. Khi tôi làm việc, tôi luôn có một phiên bản in các nhiệm vụ mà tôi có thể ghi chú, bỏ qua, v.v. Đó là cách nhanh hơn so với việc đi trên một màn hình khác để đọc một cái gì đó hoặc viết một cái gì đó. Vào cuối ngày, tôi dành 10 phút để sao chép mọi thứ vào hệ thống. Tôi nhận ra nó tiết kiệm cho tôi một số thời gian mỗi ngày.

3
marcgg
  1. Phát triển bản thân ngày càng nhiều hơn với tư cách là một lập trình viên, mỗi ngày ... Tìm hiểu các mẫu thiết kế!
  2. Sử dụng TDD, nhưng theo một cách thích hợp, các lỗi bạn có thể có trong mã của mình là điều tốn nhiều thời gian nhất.
  3. Sử dụng ReSharper :)
3
Denis Biondic

Vì nhiều câu trả lời khác nói về việc thực hiện thiết kế, tôi sẽ chỉ tập trung vào khía cạnh cơ học thuần túy của mã hóa nhanh hơn. Hầu hết những điều này có lẽ là hiển nhiên, nhưng dù sao tôi cũng sẽ nói điều đó vì tôi nhận thấy rằng nhiều đồng nghiệp của tôi không làm một số điều này.

Ánh xạ lại IDE phím tắt bàn phím để bạn có thể thực hiện hầu hết chúng bằng tay trái. Điều này giải phóng bàn tay chuột của bạn để phác thảo/tái cấu trúc mã nhanh và nguy hiểm.

Tìm hiểu cách điều hướng con trỏ của bạn và chọn văn bản bằng cách sử dụng kết hợp CtrlShift, phím mũi tên, Home và End.

Dưới đây là thiết lập C++ của tôi (Visual Studio với Visual Assistant X). Tôi có một bàn phím tiếng Na Uy, vì vậy hãy đồng ý với tôi:

Alt-Z: Thay đổi giữa .h và .cpp

Ctrl-Shift- <: Ngữ cảnh nhạy cảm nhảy qua các tham chiếu. (<đối với tôi là chìa khóa bên trái của Z, các bạn tiếng Anh không có một trong số đó. Hãy ánh xạ nó tới Ctrl-Shift-Z.)

Alt- | : Phương thức thực hiện. Bằng cách viết tiêu đề đầu tiên và chỉ cần nhấn Alt- | tất cả thời gian bạn có thể làm cho toàn bộ lớp phác thảo trong vài giây. (| Đối với tôi là chìa khóa bên dưới thoát.) Điều này đặc biệt đúng nếu bạn đặt các tệp cpp và tiêu đề cạnh nhau trong trình soạn thảo văn bản để tiêu đề không Sẽ không bị che khuất mỗi khi bạn thực hiện hành động.

Alt-R: Đổi tên biểu tượng dưới dấu mũ của tôi.

Alt-D: Thêm một mẫu tài liệu cho chức năng được chọn.

Điều này, ngoài việc hoàn thành mã nhanh như chớp, có thể tái cấu trúc tay trái.

3
Nailer

Đoạn mã, kinh nghiệm và không bao giờ ngừng nhiệt tình. Luôn đọc nội dung: blog lập trình viên, sách, văn học, mã xấu của người khác. Bạn sẽ nhận được nhanh hơn nếu bạn có một cái nhìn rộng hơn về công cụ. Nếu bạn có thể tưởng tượng tất cả các loại quy trình nền phức tạp có liên quan và bạn thực sự biết toàn bộ sự phức tạp của hệ thống đích.

Cẩm nang lập trình viên thực dụng là một điều tuyệt vời: đó là về các thực tiễn tốt nhất và những cạm bẫy lớn của nhiều khía cạnh khác nhau trong phát triển phần mềm. Vịt cao su và những thứ nghe có vẻ ngang nhiên và ngu ngốc. Tuy nhiên, bản chất của hầu hết các vấn đề lập trình là chúng ta có xu hướng suy nghĩ quá phức tạp. Tôi là một fan hâm mộ lớn của các giải pháp đơn giản và dễ dàng: không có thủ thuật hay, không hack siêu thanh lịch: chỉ sử dụng các giải pháp đơn giản nhất.

Nếu nhóm của bạn tốt, bạn có thể cố gắng hợp tác làm việc: Bespin và một số khung công tác khác hiện nay cho phép chỉnh sửa một tệp cùng nhau. Thật tuyệt vời nếu bạn thực sự thích nó và thấy đồng nghiệp của mình làm điều kỳ diệu;).

3
wishi

Hãy thử kiểm tra email của bạn với khoảng thời gian dài hơn và ngừng sử dụng các công cụ xã hội trực tuyến như Twitter, facebook, v.v.

Sử dụng này hình nền .

Cố gắng làm việc với tầm nhìn phía trước mở. Tôi thường sử dụng phòng hội thảo khi nó miễn phí, nó giúp tôi tập trung!

Cố gắng làm việc với các lập trình viên khác xung quanh bạn.

3
Adnan Memon

Bí quyết không phải là viết mã nhanh hơn, mà là viết mã làm việc nhanh hơn.

Bạn phát hiện ra lỗi càng sớm thì càng ít nỗ lực để sửa nó - đây là điều cơ bản ảnh hưởng đến hiệu suất lập trình viên.

Đây không phải là về tốc độ bạn nhập, hoặc trình biên dịch của bạn nhanh như thế nào, mà là về tốc độ bạn có thể xác định lỗi và sửa chúng khi bạn đi.

Do đó, tôi khuyên bạn nên lập trình cặp như một cách để nhanh hơn - nó thực sự tránh được lỗi. Điều đó và phát triển dựa trên thử nghiệm. Có hai cặp mắt khiến bọ khó vượt qua hơn gấp đôi (tôi nghĩ dù sao đi nữa).

Lời khuyên khác sẽ là

  • Cố gắng giảm thời gian quay vòng kiểm tra mã của bạn xuống mức tối thiểu - điều này rõ ràng phụ thuộc vào nền tảng của bạn một công cụ. Nếu bạn đang làm việc trên một hệ thống nhúng ngớ ngẩn với các công cụ khập khiễng, thời gian quay vòng có thể khá quan trọng (ví dụ: nếu bạn cần xây dựng lại hình ảnh hệ thống và cài đặt lại netboot thiết bị), VM hoặc trình giả lập có thể trợ giúp tại đây.
  • Nếu không ghép đôi lập trình, thỉnh thoảng yêu cầu người khác xem xét mã không chính thức, nhưng chỉ tại các ngắt hợp lý trong luồng (và hy vọng của họ). Làm điều này ngoài quy trình xem xét mã chính thức của bạn mà bạn chắc chắn có.
  • Giữ cho nó đơn giản - đừng quá kỹ sư. Bạn sẽ không cần nó.
3
MarkR

Viết các công cụ năng suất của riêng bạn. Họ có thể mất thời gian ban đầu để viết, nhưng tiền trả có thể lớn theo thời gian.

Một số công cụ mà tôi đã viết mà tôi sử dụng mọi lúc:

  • Một định dạng SQL.
  • Trình tạo SQL tự động: chỉ cần chọn các bảng.
  • Một nhiệm vụ đơn giản trước, vì vậy tôi có thể thấy tất cả các nhiệm vụ của mình trong một lần.
  • Một lời nhắc nhở nhiệm vụ mà cằn nhằn tôi định kỳ.
  • Một ứng dụng lấy văn bản được phân tách và cho phép bạn coi nó như bảng tính và thích văn bản.
  • Một trình định dạng trang PHP/Javascript/HTML. Một ơn trời khi làm việc với mã của người khác.

Tôi đã viết rất nhiều công cụ nhỏ khác trong thời gian đã bị thất sủng, nhưng nó vẫn đáng để nỗ lực.

3
Jonathan Swift
  1. Tôi thực sự thích nghe nhạc trong khi tôi lập trình bởi vì tôi cảm thấy như nó làm tôi thư giãn và tôi có thể tập trung.

  2. Một chiếc ghế thoải mái. Tôi không bao giờ sử dụng phòng máy tính của trường tôi để lập trình bởi vì ghế văn phòng rất khó chịu.

  3. Ăn thứ gì đó trước vì không có gì giết chết động lực của tôi như cơn đói dai dẳng.

3
Matt Phillips

Thực hành. Điều đó, và có được các công cụ năng suất cho phép bạn đi nhanh hơn.

Ví dụ: (bạn không đề cập đến nền tảng mà bạn làm việc), trong môi trường .NET, có Resharper.

2
Randolph West

Đàm phán lại các ước tính và thời gian. Hãy chắc chắn bạn là người nói rằng một cái gì đó sẽ mất bao lâu và không chịu thua bất kỳ đề xuất "tốt nào, chúng tôi cần thực hiện sớm hơn" hoặc "làm thế nào về một mục tiêu kéo dài".

Đọc bài viết của Joel Spolsky về các ước tính, trong đó chủ yếu ủng hộ việc chia phần công việc thành các phần nhỏ và ước tính từng phần. Nếu bất kỳ trong số chúng được tính theo ngày, hãy chia nhỏ chúng ra cho đến khi bạn có mọi thứ ước tính theo giờ.

2
harriyott

Bạn và sếp/người đánh giá của bạn cần xác định thời gian bạn thực sự phải lập trình. Loại bỏ các cuộc họp, email, tài liệu, thử nghiệm, các cuộc can thiệp khác kể từ thời điểm bạn dự kiến ​​sẽ làm việc và xem những gì còn lại.

Cố gắng theo dõi thời gian của bạn để có được điểm chuẩn về thời gian thực hiện một số nhiệm vụ. Sẽ có những khoảng thời gian làm việc hiệu quả (đối với tôi vào đầu ngày hoặc bất kỳ khoảng thời gian nào tôi có được tại nơi làm việc mà không có sự can thiệp) và thời gian không hiệu quả. Tìm một trung bình.

Bạn có thể xác định rằng một nhiệm vụ nhất định mất 8 giờ để lập trình, nhưng tôi nghi ngờ bạn sẽ hoàn thành công việc đó trong một ngày.

Tôi cũng sẽ cố gắng so sánh bản thân với người khác. Văn hóa doanh nghiệp có thể được đưa vào rất nhiều giờ.

2
JeffO

Chà, tôi nghĩ tôi không chậm, nhưng công việc tôi được giao có xu hướng lấp đầy thời gian có sẵn.

Bất kể, đôi khi tôi nghe thấy "Gee, bạn đã làm điều đó nhanh chóng", nhưng nó không phải là một lập trình viên nhanh, mà là từ mã hóa ít hơn.

Tôi nghĩ cách chính để viết mã ít hơn là suy nghĩ như DSL. Nếu bạn không thể lấy mã được tạo bởi bộ xử lý trước, thì hãy viết trình tạo mã. Nó không phải là lạ mắt. Mục tiêu là, nếu bạn được cung cấp một yêu cầu độc lập, để giảm thiểu số lượng nguồn khác biệt cần thiết để thực hiện yêu cầu đó. Lý tưởng nhất, con số đó là 1. Nếu bạn có thể giảm xuống trung bình khoảng 3-6, điều đó khá tốt. (Không chỉ là bạn viết ít hơn. Con số này càng nhỏ, số lượng lỗi bạn đặt vào càng nhỏ và thực sự tiết kiệm thời gian.)

Để làm điều này, tôi khuyên bạn nên thực hiện điều chỉnh hiệu suất , bởi vì sau đó bạn sẽ tìm ra cách thực hành mã hóa nào dẫn đến sự chậm lại lớn nhất và chúng cũng dẫn đến mã bị cồng kềnh. Cụ thể, cấu trúc dữ liệu quá mức và lập trình kiểu sự kiện/thông báo. Những thứ đó một mình đóng góp ồ ạt vào khối lượng mã.

Nhiều khối lượng mã ngày nay là do giao diện người dùng, đặc biệt là nếu nó linh hoạt linh hoạt. Tôi tình cờ tìm ra cách để thực hiện phần đó, được gọi là Hộp thoại động , có đường cong học tập khó khăn nhưng thu nhỏ mã UI khoảng một bậc độ lớn.

Bạn sẽ phải tìm cách riêng cho mình về điều này, tôi sợ, nhưng may mắn nhất.

2
Mike Dunlavey

Giữ cuộc sống cá nhân của bạn theo thứ tự. Ngủ nhiều, ăn uống lành mạnh và uống vitamin - đặc biệt nếu bạn bị thiếu chất sắt. Tránh xa "đồ uống" - nếu bạn hiểu ý tôi. Và hãy nhớ, "Cả Rượu và Phụ nữ đều có thể khiến một người đàn ông khôn ngoan lạc lối."

Ngoài ra, tạo các mẫu mã của bạn và một "trình tạo mã" hoạt động bằng các mẫu biểu thức thông thường. NẾU bạn thấy mình sao chép và dán, sau đó tìm kiếm và thay thế các lớp tương tự, tự động hóa quy trình này. Tôi đã làm điều này cho các dự án PHP, trong đó tôi có thể tạo một ứng dụng CRUD, hoàn thành với tất cả các thành phần MVC cơ bản, dựa trên các bảng dữ liệu của tôi - tất cả các mô hình dữ liệu đều giống nhau ngoại trừ các bảng dữ liệu mà chúng đại diện, vì vậy đây là các thiết lập trong các mẫu và được sử dụng để tạo mã ban đầu của tôi. Tiết kiệm hàng giờ gõ.

Cuối cùng, nói với tất cả những người liên quan đến dự án rằng mã sẽ mất thời gian gấp 1/4 đến 1/2 lần so với BẠN nghĩ. Đàm phán thêm phòng thở cho chính mình, sớm. "Muộn" là một thuật ngữ tương đối. Khi các thay đổi xảy ra trong dự án, giữa dòng, hãy cho mọi người biết trước rằng 8 giờ làm việc đã được thêm vào. Một hệ thống theo dõi, chẳng hạn như một hệ thống được cung cấp trong "FogBugz" có thể hữu ích cho chính bạn và các nhà quản lý để dự đoán sẽ mất bao lâu để hoàn thành công việc, dựa trên kinh nghiệm trước đó. Tôi cố gắng thực hiện chiến thuật, "Vẫn chưa muộn - tôi đã sử dụng lượng thời gian thích hợp để hoàn thành chức năng này - nó chỉ mất nhiều thời gian hơn chúng tôi mong đợi."

Một lập trình viên khác có thể nói: "Chà, tôi có thể đã làm nó nhanh hơn ..." Có lẽ, có lẽ không, đó không phải là một điểm đáng để tranh luận hay đánh bại chính bạn - luôn luôn có một anh chàng "thông minh" nào đó cố gắng nhấn nút đó. Anh ấy sẽ làm bạn chậm lại nếu bạn nghĩ về nó! Nó luôn luôn là một tình huống xấu khi ông chủ của bạn, mặc dù. Vào thời điểm đó, tôi sẽ cân nhắc tìm kiếm một công việc khác, bởi vì loại sếp đó là một JERK kiêu ngạo, trong cuốn sách của tôi.

2
JasonMichael

Q: 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?

Trả lời: Mỗi ngày đến văn phòng và viết tất cả những gì bạn muốn hoàn thành vào đó (ghi chú dán) ghi chú Outlook. Bắt đầu làm việc theo thứ tự của các mặt hàng. Hãy tin tôi vào cuối ngày bạn sẽ cảm thấy bạn đã làm những gì bạn đã lên kế hoạch và đó là một cảm giác tuyệt vời.

2
Cshah

Chương trình cặp - điều này có tất cả các loại lợi ích:

  • buộc bạn phải nói rõ/làm rõ suy nghĩ của bạn
  • cung cấp cho bạn cái nhìn sâu sắc về cách người khác làm việc, nhiều ý tưởng mà bạn có thể áp dụng/thử
  • tìm hiểu công nghệ mới trực tiếp từ người khác biết chúng
  • nhận được lời khuyên năng suất nhỏ từ những người khác. Bạn luôn thấy ai đó sử dụng lệnh menu mà bạn chưa hiểu trước đây hoặc một số lệnh Unix hữu ích.
2
ndp

Viết ít mã hơn.

Banish Not-Invented-Here và tận dụng tốt các thư viện/khung/bộ công cụ hiện có để cung cấp chức năng chung (và thường không xác định) để bạn chỉ cần viết những gì mới. Đối với những phần bạn cần phải tự viết, hãy xây dựng chúng với mục đích sử dụng lại để bạn sẽ không phải viết lại chúng cho dự án tiếp theo.

Ngay cả khi bạn không tăng số dòng mã làm việc bạn sản xuất mỗi ngày, bạn vẫn có thể hoàn thành nhiều việc hơn trong thời gian ngắn hơn bằng cách làm cho mỗi dòng làm được nhiều hơn.

2
Dave Sherohman

Điều rõ ràng duy nhất tôi thấy rằng các công trình là không bị phân tâm. Mà, trong một số môi trường, là không thể. Nhưng việc có thể tập trung vào nhiệm vụ cụ thể và CHỈ vào nhiệm vụ đó có thể sẽ vượt xa mọi thứ khác. Những chuyển đổi bối cảnh là thời gian thực sự lớn chìm.

2
Joe

tung hứng trong khi nghỉ ngơi

Juggling

2
Cornelius

Uống Yerba Mate thay vì Cà phê

Yerba Mate

2
Cornelius

Đó luôn là cùng một quyết định duy nhất, phát triển nhanh so với chất lượng, dễ đọc, mở rộng. Kéo và thả các điều khiển và các tệp phía sau mã vô hạn (nhanh và bẩn) hoặc mô đun, mô hình và thực tiễn (đầu tư dài hạn)?

Theo ý kiến ​​trung thực của tôi, mọi người đều phải đầu tư vào cách viết mã dài hạn. Thời gian trôi qua, sự phát triển nhanh chóng cũng sẽ có chất lượng tuyệt vời.

Tuy nhiên, trong trường hợp tôi không hiểu câu hỏi của bạn và bạn đang tìm kiếm câu trả lời về các khía cạnh thực tế của phát triển nhanh, như công cụ, trình tạo mã và các công cụ khác, ý kiến ​​của tôi là bắt đầu sử dụng Resharper và tìm hiểu càng nhiều càng tốt về = IDE :)

1
Aggelos Biboudis

SỬ DỤNG TRÁI CÂY !! Đừng làm phiền bản thân với mã hóa!

1
Koosha

Trước hết, bạn không nên thiết kế một hệ thống dựa trên một vài cuộc họp với người dùng cuối. Trong thực tế, bạn không nên tham gia vào giai đoạn yêu cầu của một dự án, đó là để các nhà phân tích kinh doanh và người dùng cuối giải quyết.

Giai đoạn thứ hai nên là yêu cầu kỹ thuật của bạn, đây là lúc bạn sẽ bắt đầu làm việc với các nhà phân tích kinh doanh để đưa ra giải pháp cho đặc tả được yêu cầu.

Bây giờ là phần quan trọng. Hãy chắc chắn rằng bạn hiểu cả yêu cầu của người dùng cuối và yêu cầu chức năng, sẽ không có việc bạn bắt đầu một cái gì đó chỉ để thấy nó không đáp ứng mong đợi của người dùng. Hãy lên tiếng nếu bạn không hiểu điều gì đó.

Bây giờ, thời gian để nhấn trình soạn thảo. Nhưng cách tiếp cận của tôi là không bao giờ viết mã thực, luôn viết một chồng bình luận tuyệt đối trước, thực hiện bằng mã giả nếu điều đó dễ với bạn, bất kể điều gì không quan trọng, miễn là nó rõ ràng và dễ đọc/dễ hiểu.

Khi bạn đã thực hiện xong nhận xét của mình, bạn có thể bắt đầu a) viết các trường hợp thử nghiệm của mình b) viết việc thực hiện.

Tùy thuộc vào môi trường của bạn, bạn sẽ bắt đầu tốt nhất với (a) nhưng đáng buồn nhất là bắt đầu với (b) và sau đó thử buộc các bài kiểm tra để đáp ứng việc thực hiện. Nói một cách thẳng thắn, nếu bạn là một phần của một công ty lớn, sẽ có một bộ phận viết các trường hợp thử nghiệm cho bạn trước khi bạn bắt đầu làm bất cứ điều gì.

1
Brett Ryan

Mọi người đều nói 'kiểm tra email' nhưng hãy xem xét thời gian bạn viết email kỹ thuật cao. Tôi có thể dễ dàng dành một giờ để viết một email. Để khắc phục, tôi có thể 1) không viết nhiều hoặc 2) tắt các công cụ kỹ thuật (và nội dung yêu cầu tôi đọc mã để trả lời) cho đến khi thật cần thiết.

1
Shin

Khi thực sự viết mã, CodeRush giúp khá nhiều đặc biệt là khi bạn đã thành thạo các phím tắt của nó. Thêm vào đó là miễn phí: D

1
GaiusSensei

Tôi dành một ít thời gian mỗi tuần chỉ để tìm kiếm những cách sáng tạo mới để làm những việc có thể liên quan trực tiếp đến những gì tôi đang làm. Thường thì tôi sẽ tìm các thủ thuật hoặc công cụ mới mà tôi chưa bao giờ biết về việc tăng tốc quy trình làm việc của mình.

1
fscmj

Làm quen với IDE của bạn.

Nếu IDE của bạn là Visual Studio, thì tôi rất khuyến khích sách của Sara Ford .

1
Jim G.
  • tìm hiểu các mẫu thiết kế. Chúng giúp bạn hiểu vấn đề, giúp bạn trở thành một lập trình viên giỏi hơn -> sẽ cho phép bạn lập trình nhanh hơn rất nhiều vì bạn đã có giải pháp cho một số vấn đề được chuẩn bị trong đầu
  • trích xuất các phần lặp đi lặp lại trong chương trình của bạn. Nếu có một số logic lặp lại trong một số chương trình bạn viết, hãy xem xét khái quát hóa chúng và trích xuất chúng vào một thư viện lớp nào đó mà sau đó bạn có thể sử dụng lại trên các ứng dụng mới mà bạn viết. Chuẩn hóa điều: đầu tư một chút thời gian để tìm hiểu làm thế nào các nhiệm vụ lặp đi lặp lại được thực hiện tốt nhất. Tài liệu các bước để đạt được. Lần tới bạn sẽ biết chính xác cách giải quyết/áp dụng chúng.
  • Nguyên tắc KISS
  • Tạo mã sẽ hữu ích (một khi có sẵn một công cụ hữu ích). Máy phát điện bắt đầu trở nên phổ biến, gần đây.

Lưu ý : Chỉ làm cho mọi thứ hoạt động tồi tệ hơn !! Như một số đề cập chỉ để hack trong mọi thứ cho đến khi chúng hoạt động sẽ làm cho bạn nhanh hơn chỉ trong lúc này. Lỗi sẽ xuất hiện tuy nhiên bằng cách nào đó cũng tính cả về tốc độ bạn lập trình. Nếu tôi phải viết một số chức năng và tôi đầu tư vào việc viết nó tốt, có một thiết kế tốt, có thể được kiểm tra tốt (với các bài kiểm tra Đơn vị) và nói rằng tôi sẽ cần nửa ngày. Nhưng giả sử rằng đó là và tính năng của bạn hoạt động và bạn không phải chạm vào nó một lần nữa. Một lập trình viên khác, chỉ tập trung vào việc đạt được mục tiêu nhanh chóng của mình, sẽ biến (có thể) thành một thiết kế tồi, do thiếu thử nghiệm mà anh ta sẽ không xem xét (nhận thức được) ranh giới, các trường hợp đặc biệt. Anh ấy sẽ cần 2 giờ (giả sử). Lỗi sẽ đến, anh ta sẽ lại phải chạm vào mã, sửa nó, có thể kéo dài nó (hàng giờ sẽ được đầu tư lại). Mã sẽ khó duy trì, v.v ... tiếp tục: cuối cùng anh ta sẽ dành nhiều thời gian quặng và sự thất vọng sẽ cao hơn.

1
Juri

Sử dụng một bố trí bàn phím được tối ưu hóa công thái học . Một số thậm chí còn nhắm đến các lập trình viên, thông qua các ký tự đặc biệt rất dễ tiếp cận.

1
knittl

Làm ở nhà. Khi tôi có một thời hạn khó khăn và tôi cần tập trung hoàn toàn vào một vấn đề, tôi nói với sếp rằng tôi đang làm việc tại nhà. Điều này cho phép tôi thiết lập môi trường của mình một cách tối ưu, giảm sự gián đoạn và cho phép tôi tập trung như một tia laser vào vấn đề.

1
Pedro Estrada

Bạn sẽ nhanh hơn với kinh nghiệm và ghi nhớ API nhiều hơn nữa.

Những ngày tôi tìm kiếm trên web các đoạn mã ngắn hơn rất nhiều bây giờ tôi đã học cách viết mã tốt hơn.

Ồ, bạn cũng có thể muốn thử sử dụng các khái niệm lập trình chức năng và lamda để cắt giảm mã của mình :)

1
Vince

Vui mừng về những gì bạn đang làm là một cách tuyệt vời để tăng hiệu quả. Hãy chắc chắn rằng nó rất vui!

1
Jakob

Tôi nghĩ rằng phác thảo ý tưởng của bạn trên giấy, hãy nhớ những thứ đó, là một cách tuyệt vời để đưa ra một số ý tưởng. Là những lập trình viên, cho dù là người chuyên nghiệp hay người có sở thích, chúng tôi dành rất nhiều thời gian để nhìn chằm chằm vào màn hình, rằng có một lối thoát khác để đưa ý tưởng của bạn là tốt. Tôi thấy rằng việc gãi mọi thứ ra, vẽ các đường vội vàng liên kết các ý tưởng, khoanh tròn, gạch chân, v.v ... tất cả đều nhấn mạnh vào một ý tưởng và thực sự có thể giúp bạn sắp xếp một ý tưởng nhanh hơn nhiều so với cố gắng cấu trúc nó ngay lập tức một số hình thức hỗ trợ máy tính.

Một điều khác giúp là tạo mẫu các bộ phận nhỏ. Đã nghe một podcast âm thanh TED đêm qua nơi diễn giả đang thảo luận về việc xây dựng các cấu trúc nhỏ từ que spaghetti và Marshmallow, rõ ràng đây là một nghiên cứu được sử dụng khá rộng rãi để kiểm tra khả năng xây dựng xã hội của các nhóm nhỏ ... dù sao, các nhóm luôn làm tốt hơn, bên cạnh các kiến ​​trúc sư hiểu về gia cố và xây dựng công trình là trẻ em vì họ đã sử dụng một luồng phản hồi liên tục để có được kết quả. Tôi nghĩ rằng bạn cũng có thể đưa ý tưởng này vào một ý tưởng lập trình trong đó bạn thấy rằng làm những việc nhỏ nhặt và đạt được kết quả không chỉ hiệu quả hơn mà còn thú vị và hữu ích hơn nhiều so với việc xây dựng một công trình khổng lồ và sau đó dành nhiều ngày để gỡ lỗi .... chắc chắn một số ý tưởng "vui vẻ" của tôi trong quá khứ.

1
dscher

Khi tôi ở văn phòng và tôi cần duy trì sự tập trung của mình, tôi đóng ứng dụng khách email của mình. Không có gì phá hủy hiệu quả đối với tôi nhanh hơn sự cám dỗ liên tục để "xem nhanh" bất cứ thông điệp nào vừa đến. Tôi cũng đã từng chơi đùa với Kỹ thuật Pomodoro để quản lý sự gián đoạn và duy trì sự tập trung.

1
Tim Trout

Sử dụng trình tạo mã bất cứ khi nào có thể. Đôi khi, ngay cả Microsoft Excel (hoặc OpenOffice Calc) hóa ra lại là một công cụ tạo mã mạnh mẽ.

0
Canavar

Nói một cách đơn giản, Bảng trắng -> chia thành các yêu cầu có thể kiểm tra thành các nhiệm vụ (Tôi đã sử dụng Team Foundation để theo dõi từng nhiệm vụ và mất bao lâu.)

Sử dụng thử nghiệm để đảm bảo rằng bạn đang nhận được những gì được yêu cầu, không hơn không kém. (Đừng lo lắng về hiệu suất chưa.)

Đi từ yêu cầu đến yêu cầu và kiểm tra sau khi từng được thực hiện. Sau khi hoàn thành mỗi nhiệm vụ, bạn nên có ước tính chính xác về thời gian còn lại.

Khi tất cả các yêu cầu được thực hiện trở lại và "đánh bóng" nó.

Thực hiện công việc chân trước tiên buộc người ta phải giải quyết tất cả các yêu cầu giúp tiết kiệm thời gian bằng cách thực hiện ngay lần đầu tiên.

Nếu được thực hiện đúng cách, điều này sẽ cho phép dành nhiều thời gian hơn cho Stack Overflow :)

Chúc may mắn

0
Brad8118

Có một loạt các ý tưởng tuyệt vời ở đây. Để giúp tôi vào 'vùng', tôi sử dụng bộ hẹn giờ được đặt trong khoảng thời gian 27 phút. Tôi tìm thấy một khi tôi ở chế độ làm việc, thật dễ dàng để làm việc tốt hơn tiếng chuông và làm việc với dòng chảy là không đau. Đến đó là khó khăn.

0
Daver

Một điều mà tôi nhận thấy ảnh hưởng đến tốc độ của tôi nhiều nhất là động lực và vui chơi. Điều này có vẻ mờ, nhưng khi tôi có động lực và làm điều gì đó mà tôi thấy vui, tôi có thể cực kỳ hiệu quả. Mặt khác, khi tôi không thực sự cảm thấy mình phải đẩy từng dòng mã ra khỏi mình.

Tìm điểm ngọt ngào của bạn, điều gì thực sự thúc đẩy bạn và loại nhiệm vụ nào bạn thực sự thích làm? Và bạn có thể ảnh hưởng đến kế hoạch của bạn để bạn có thể làm điều này? Đối với tôi đó là khi tôi có thể giải quyết các vấn đề và các vấn đề thiết kế, và khi tôi cảm thấy rằng tôi có một phần của dự án.

Vài tháng trước chúng tôi đã có một dự án nhỏ mà nhóm nhỏ của chúng tôi được giao thực hiện và đó là một thời hạn thực sự quan trọng và rất phi thực tế đối với nó. Tuy nhiên, tất cả chúng tôi đều rất có động lực và rất vui khi làm điều đó và hoàn thành kịp thời gian, với một khách hàng hạnh phúc. Lý do cho động lực của tôi là chúng tôi đã tham gia vào dự án và phải đưa ra ý tưởng sáng tạo cho nó. Tôi cũng phải làm những phần mà tôi thực sự thích.

Tuy nhiên, gần đây tôi đã tham gia vào một dự án mà về cơ bản tôi là một con khỉ mã, chỉ làm những công việc phiền toái và bực bội, hoặc chỉ cần sửa chữa nhanh chóng theo cách nhanh nhất có thể mà tôi biết sẽ quay lại và cắn mạnh vào tôi một tương lai gần, và nó đã bị chậm một cách đau đớn.

Vậy điểm ngọt ngào của bạn là gì?

0
Runeborg
  1. Biết những gì bạn muốn làm và có hứng thú với nó
  2. Dành một vài giờ nghiên cứu mã về cách làm điều đó
  3. Sao chép và dán mã để đạt được kết quả cuối cùng
  4. Làm việc trên một gui cơ bản để hoàn thành công việc, ĐỪNG KIẾM THỜI GIAN ĐỂ KIẾM TIỀN XEM
  5. Kiểm tra và gỡ lỗi
  6. Làm việc trên một gui đẹp
0
Matt S.

"Tính kịp thời" không giống với "nhanh". Nếu đó là vấn đề thì đánh giá của bạn chỉ nên nói "chậm". Vì vậy, trước khi bạn đi theo con đường bạn đề xuất, hãy chắc chắn rằng bạn biết những gì được mong đợi ở bạn.

Nó có thể có nghĩa là bất cứ điều gì; nó thậm chí có thể có nghĩa là bạn không vào văn phòng cho đến 20 phút sau khi đồng nghiệp của bạn hoặc bạn quản lý thời gian kém. Điều đó có thể không liên quan gì đến 'tốc độ lập trình' của bạn.

Tôi có lẽ dành phần lớn thời gian để thiết kế và lập kế hoạch; lập kế hoạch nhiệm vụ dễ dàng hơn từ một phân tích và thiết kế tốt, và sau đó bạn sẽ đưa ra các ước tính tốt hơn sẽ được tin tưởng. Hơn nữa, từ một thiết kế tốt, mã hóa trở nên đơn giản hơn rất nhiều và quy trình được định hướng nhiều hơn. Nó cũng làm cho nó có thể phân chia một nhiệm vụ và phân phối nó giữa các nhà phát triển khác.

0
Clifford

Tôi thực tế đã tăng gấp ba tốc độ mã hóa C của mình với VIM .

0
Liran Orevi

CodeRush! Hiểu rồi! Yêu nó!

0
Bobby Ortiz

Chọn trình soạn thảo nhanh, trình biên dịch nhanh và viết phần mềm với thời gian thực hiện nhanh. Bằng cách này, bạn có thể mắc lỗi nhiều gấp mười lần so với lập trình viên bình thường và vẫn trở nên tốt hơn những người khác. Đó có lẽ là một trong những lý do ứng dụng google rất phổ biến. Phát triển web chứa đầy những lỗi khó chịu và việc viết thêm phần mềm trên nền tảng lỗi là điều khó khăn. Nhưng thời gian phản hồi giữa chỉnh sửa mã và thấy kết quả nhanh đến mức vẫn dễ dàng khiến cho đống rác đó hoạt động hơn là mở rộng các chương trình c ++. :)

0
AareP

Dành nhiều thời gian hơn để đặt mọi thứ cùng nhau trong tâm trí của bạn hơn trước IDE. Khi bạn có một kế hoạch, bạn đã có hầu hết các công việc đã hoàn thành. Thực hiện chỉ là 20% khác. Nếu bạn gặp khó khăn trong khi viết mã do các vấn đề cụ thể về nền tảng, hãy bám sát kế hoạch và tiếp tục thực hiện và kiểm tra phần còn lại. Cuối cùng, giải quyết tất cả các điểm bạn đã bỏ lại, giải quyết từng điểm một - có thể một số điểm sẽ liên quan và giải quyết một số điểm có thể đủ để tìm ra phần còn lại. Tôi thường sử dụng cách giải quyết cho các vấn đề như vậy, thêm nhận xét "// ĐỔI THAY ĐỔI" tại các vị trí cụ thể trong mã và viết lại những vấn đề có ảnh hưởng lớn nhất đến chất lượng và hiệu suất, nếu tôi không có thời gian để giải quyết tất cả của họ theo thời hạn.

0
luvieere

Xây dựng thư viện mã của riêng bạn

Mỗi khi bạn mã hóa một tính năng mới, hãy cố gắng giữ cho nó chung chung nhất có thể, nhưng không quá chung chung. Trong ngắn hạn, điều này sẽ chậm hơn một chút, nhưng về lâu dài khi mã của bạn trở nên lớn hơn, mỗi dự án mới sẽ được hoàn thành nhanh hơn vì rất nhiều ứng dụng kinh doanh có nhu cầu tương tự (không phải lúc nào) nhưng đủ gần mã có thể được sử dụng lại.

0
Darknight

Nhanh hơn không có nghĩa là tốt hơn. Nếu bạn quản lý để trở thành một lập trình viên nhanh hơn và tốt hơn. Tất cả đi xuống để cân bằng. Bao lâu bạn có thể làm điều đó? Suy nghĩ, kiên nhẫn và lập kế hoạch luôn được đền đáp. Đôi khi "nhanh" trong thế giới phát triển có thể mang lại kết quả tồi tệ nhất.

0
Ryuken

Giải cấu trúc. Phá vỡ bất cứ điều gì bạn đang xây dựng thành các tính năng nhỏ hơn mà bạn có thể thực hiện theo từng giai đoạn. Sau đó, bất cứ khi nào bạn có bất kỳ phần nhỏ nào được thực hiện và bạn đã kiểm tra để xác nhận rằng nó không phá vỡ bất cứ thứ gì, hãy triển khai nó và hiển thị cho Powers That Be.

Sử dụng các bước lặp nhỏ thường sẽ giúp bạn hoàn thành dự án lớn nhanh hơn và tốt hơn, bởi vì bạn nhận được phản hồi khi bạn đi và bạn sẽ không cần phải quay lại và làm lại nhiều như vậy. Nhưng ngay cả khi điều đó không xảy ra, bạn đang thể hiện sự tiến bộ không ngừng, điều này mang lại lợi ích tâm lý vững chắc và khôi phục sự tự tin của người quản lý hoặc khách hàng của bạn.

Phát triển dựa trên thử nghiệm cũng giúp rất nhiều với phương pháp này. Thoạt đầu, nó có vẻ giống như các bài kiểm tra viết trước tiên làm mọi thứ chậm lại - nhưng nó sẽ khắc phục được lỗi mà bạn sẽ tránh được, và tùy thuộc vào cách bạn viết chúng, bản thân các bài kiểm tra có thể được cung cấp cho Powers That Be và xác nhận hành vi của ứng dụng ngay cả trước khi bạn viết tất cả.

0
SFEley

Nếu bạn đang lập trình bằng C thì việc học hack bit là điều bắt buộc để trở thành một lập trình viên nhanh hơn. Cũng đọc thực hành mã hóa bởi những người xếp hạng hàng đầu tại Topcoder.com. Mã của họ rất nhỏ và hiệu quả.

0
avd

Trở thành một người nhanh hơn lập trình viên bằng cách làm chậm khi bạn đang thiết kế và mã hóa.

  • Hãy suy nghĩ về những gì bạn đang làm.
  • Hãy xem xét ý nghĩa của thiết kế của bạn.
  • Làm cho đúng ngay lần đầu tiên (kiểm tra mã của riêng bạn một cách mạnh mẽ).

Nó có thể cảm thấy chậm hơn, nhưng thông lượng của bạn sẽ nhanh hơn những kẻ lừa đảo mã quay vòng trong 4 giờ, và sau đó cần 6 vòng QA trước mã thông qua.

0
mmc

Re: Làm thế nào để ước tính và bám vào nó:

Khi ước tính, hãy nhớ định luật của Hofstadter cũng như câu châm ngôn này: "Mọi thứ mất nhiều thời gian hơn nó". Hãy đoán một cách hợp lý về việc một cái gì đó sẽ mất bao lâu, sau đó tăng gấp đôi hoặc gấp ba trước khi nó ra khỏi miệng. Sẽ có những phức tạp, thất bại, phiền nhiễu, những điều bạn quên, v.v ... Tốt hơn là nên hứa hẹn và cung cấp quá mức so với ngược lại.

Dựa vào ước tính, cố gắng hết sức để hoàn thành công việc của bạn một cách hiệu quả. Khi vấn đề xuất hiện, giao tiếp sự chậm trễ sớm. Điều này cho mọi người thời gian để điều chỉnh kỳ vọng của họ. Nếu lời giải thích của bạn là hợp lý, bạn có thể được cung cấp thêm thời gian hoặc hỗ trợ hoặc có những phiền nhiễu (như một người hàng xóm ồn ào) bị xóa khỏi đường dẫn của bạn.

0
steamer25

Các thực tiễn sau đây nổi tiếng nhưng thường bị bỏ qua vì nhiều lý do, thường là do thời hạn chặt chẽ, vì vậy chúng đáng được đề cập ở đây (thực tế, đây là những cơ chế dành thời gian trước để tránh chi tiêu nhiều hơn thời gian sau):

  • Do phát triển theo hướng kiểm tra; nó sẽ giúp bạn chỉ viết số lượng mã thực sự cần thiết và sẽ giúp bạn tránh được việc giới thiệu các lỗi khi thêm tính năng hoặc tái cấu trúc

  • Viết bình luận, nhưng chỉ khi mã đủ phức tạp để đảm bảo mã

  • Refactorđơn giản hóa mã của bạn thường xuyên

  • Sử dụng phần mềm kiểm soát nguồn tốt (như Git hoặc Mercurial) -nếu chủ nhân của bạn sử dụng cái gì khác, hãy sử dụng cục bộ của riêng bạn-

  • Cam kết mã thay đổi thường xuyên: đối với mọi tính năng hoặc tái cấu trúc, hãy thực hiện một cam kết, vì việc hoàn nguyên sẽ ít tốn kém hơn cho bạn nếu có gì đó không ổn

  • Đừng sợ chi nhánh; Git đặc biệt có cơ chế phân nhánh rất nhanh và "an toàn" (ví dụ, so với Subversion)

0
Nick Toumpelis

Cá nhân tôi nghĩ rằng tất cả về khả năng tái sử dụng mã. Trừ khi bạn thực hiện mọi thứ hoàn toàn tùy chỉnh mỗi lần, bạn nên có một thư viện các chức năng sử dụng phổ biến mà bạn có thể chuyển sang. Tôi có một utils.php trong đó tôi có toàn bộ "cơ sở" các chức năng mà tôi đã sử dụng cho các dự án trước đó. Tiết kiệm một TON thời gian khi tôi phải làm một cái gì đó tương tự.

Chúc may mắn và đừng nản lòng. Tôi nghĩ rằng tất cả chúng ta đều cảm thấy chậm chạp hoặc "ngu ngốc". Tôi biết tôi có!

0
Code Monkey

Sử dụng các công cụ phân tích tĩnh.

Chúng giúp bạn tìm thấy nhiều lỗi hơn trong thời gian biên dịch nếu không bạn sẽ phải theo dõi trong thời gian chạy.

Đặc biệt là khi xây dựng các ứng dụng đa luồng, chúng là một trợ giúp THỰC SỰ.

0
Oliver Weiler

Đây là tất cả những gợi ý tốt. Tôi sẽ thêm kỹ thuật năng suất của riêng mình để biết cách hoàn thành công việc không chỉ với mã tối thiểu mà còn với mã dự phòng tối thiểu.

Nói chung điều này có nghĩa là cấu trúc dữ liệu càng ít càng tốt.

Để tạo mã với sự dư thừa tối thiểu đòi hỏi sự sáng tạo và sẵn sàng làm mọi thứ theo cách có thể áp đặt đường cong học tập. Đó là giá của năng suất. Đây là một ví dụ.

0
Mike Dunlavey