Làm thế nào để viết mã hiệu quả mặc dù thời hạn nặng

Tôi đang làm việc trong một môi trường trong đó chúng tôi có nhiều dự án với thời hạn nghiêm ngặt về việc giao hàng. Chúng tôi thậm chí nói chuyện trực tiếp với khách hàng để hoàn thành công việc và nhanh chóng là điều bắt buộc.

Vấn đề của tôi là tôi luôn viết mã cho giải pháp đầu tiên xuất hiện trong đầu, tất nhiên lúc đó tôi nghĩ là tốt nhất. Nó luôn luôn kết thúc xấu xí và sau đó tôi nhận ra rằng có nhiều cách tốt hơn để làm điều đó nhưng không đủ khả năng để thay đổi do hạn chế về thời gian.

Có bất kỳ mẹo nào để tôi có thể làm cho mã của mình hiệu quả mà vẫn cung cấp đúng hạn không?

Nếu mã cần được duy trì, giải thích rằng cần thêm thời gian để làm cho mã dễ bảo trì hơn, điều này sẽ giúp họ tiết kiệm tiền cho phần phụ trợ. Nói cách khác, làm cho mã duy trì là một yêu cầu.

Nếu họ không quan tâm đến điều đó, tôi không nghĩ bạn cần phải làm gì khác, ngoài việc trở nên tốt hơn mọi lúc và làm tốt nhất có thể để kết hợp các thực hành tốt nhất bất cứ khi nào có thể.

Được rồi, điều này nghe có vẻ hơi điên rồ nhưng tôi thề là nó hoạt động. Nó không chỉ dành cho lập trình, nó là một công thức để tăng khả năng sáng tạo, tập trung và trí nhớ:

• Ăn tốt
• Suy nghĩ
• Ngủ nhiều (7-9 giờ tùy theo người)
• Nap bất cứ khi nào não của bạn mờ
• Đi ngủ với một vấn đề chưa được giải quyết. Đừng kết thúc một ngày của bạn với mọi thứ hoàn tất. Để lại một nhiệm vụ khó khăn đang chờ xử lý - tiềm thức của bạn có hiệu quả rõ rệt.
• Mặc quần áo thoải mái
• Tập thể dục
• Dành thời gian để thực hiện các bài tập tinh thần - sudoku (không được lập trình), trò chơi ô chữ, bài tập toán, câu đố không gian, v.v.
• Tự mình thực hiện các thử nghiệm khách quan để xem hành vi nào của bạn ảnh hưởng đến hiệu suất (bạn sẽ cần một cách đáng tin cậy để kiểm tra hiệu suất để hoạt động này).
• Chú ý đến sức khỏe tinh thần của bạn
• Quần lót cotton
• Chú ý đến sức khỏe tình dục của bạn
• Dành thời gian cho gia đình và bạn bè của bạn
• Trở nên thành thạo một thứ gì đó bên ngoài nghề nghiệp của bạn (âm nhạc, nấu ăn, thể thao, v.v.) và giao tiếp với những người khác làm điều tương tự
• Đối với một số người, thú cưng là phải

Trước khi bạn biết điều đó, bạn sẽ thấy một sự cải thiện rõ rệt về năng suất và chất lượng giải pháp lập trình của bạn (không đề cập đến các cải tiến trong các lĩnh vực khác).

Nguồn:

1. Bộ não kỳ diệu của bạn: Tối đa hóa trí não, tăng cường trí nhớ, nâng cao tâm trạng, cải thiện chỉ số IQ và sự sáng tạo, ngăn ngừa và đảo ngược sự lão hóa tinh thần
2. Bản thân định lượng
3. Seth Roberts - trong Khoa học Mỹ

Nó phản trực giác, nhưng có lẽ bạn cần phải chậm lại. Khi bạn thực hiện giải pháp đầu tiên xuất hiện trong đầu, bạn sẽ tạo ra rất nhiều công việc phụ cho bản thân. "Xuống đường", ý tôi là sớm nhất là vào chiều hôm đó. Các vấn đề bạn tạo ra cho chính mình không mất nhiều tháng để phát triển. Hãy xem xét lựa chọn của bạn. Gõ ít và suy ngẫm nhiều hơn. Ngay cả trong một dự án ngắn, bạn sẽ thấy rằng ít mã hóa hơn có thể thực sự tăng tốc cho bạn.

Nếu khách hàng của bạn tập hợp trong các ngành cụ thể, hãy cố gắng xây dựng các dự án có các thành phần có thể sử dụng lại. Không viết mã nhanh hơn viết nó.

Từ quan điểm của khách hàng của bạn, điều này có mùi hơi giống như " Nhanh, tốt và rẻ, chọn hai ". Chắc chắn, tất cả chúng ta đều muốn những gì chúng ta mong muốn ngay lập tức, nhưng khách hàng của bạn cần xem xét nếu điều này là tốt nhất trong dài hạn. Cố gắng nói rõ sự đánh đổi và giúp họ đưa ra quyết định tốt.

Tìm kiếm công việc khác.

Bạn sẽ thấy rằng sau khoảng 6 mos. đến một năm mà bạn sẽ không có niềm tự hào về công việc mà bạn đã làm. Hơn nữa, bạn sẽ không mất thời gian để tìm hiểu về các kỹ thuật, công nghệ hoặc khung mới - vì vậy sau một năm, bạn sẽ không thể theo kịp các công nghệ mới. Bạn sẽ là một lập trình viên tồi tệ hơn so với thị trường sau một năm so với lúc ban đầu.

Nếu quá nhiều thời gian trôi qua (giả sử vài năm trở lên), bạn sẽ có một thời gian rất khó khăn để được thuê ở bất cứ đâu ngoại trừ những loại công việc có nhịp độ nhanh này, nơi mã chất lượng không được đánh giá cao, chỉ tốc độ.

Điều đó nói rằng, như một trải nghiệm học tập "thế giới thực", có một điều gì đó để nói về môi trường có nhịp độ nhanh, nhưng tôi sẽ nói rằng khoảng 6 mos. Là đủ. Ngoài ra, bạn nên tìm cách kết nối với một vài nhà tuyển dụng và tìm kiếm nơi nào đó tốt hơn. Bạn sẽ hạnh phúc hơn nhiều, trung thực.

Từ khách hàng của bạn xem hiệu quả mã có thể không quan trọng, và có thể khá tốn kém. Ngày nay, thời gian làm mã cần tiết kiệm thời gian CPU để chứng minh thời gian của bạn là một giờ. Đối với hầu hết các chương trình hiệu quả là không quan trọng. Ngay cả đối với những người ở đó, hầu hết các mã không cần phải hiệu quả. Với sự lựa chọn, sở thích của tôi sẽ là một giải pháp dễ duy trì hơn là một mã hiệu quả hơn, khó bảo trì hơn.

Dành thời gian để lập kế hoạch mã hóa trước khi bạn bắt đầu có thể cho bạn thời gian để đánh giá các giải pháp và xem xét các phương pháp thay thế. Điều này sẽ giúp bạn tiết kiệm thời gian trong mã hóa và thử nghiệm. Tôi đã thấy rằng mã thường đơn giản hơn là hiệu quả hơn.

Bố trí mã sạch bằng cách sử dụng càng nhiều dòng càng cần thiết. Mã phức tạp có thể gây nhầm lẫn cho trình tối ưu hóa và có thể dẫn đến mã chậm hơn. Trình biên dịch hiện đại rất tốt trong việc tối ưu hóa mã, tin tưởng nó để thực hiện công việc của nó.

Chấp nhận rằng đủ tốt là đủ tốt. Khi bạn đưa ra những cách tiếp cận hiệu quả hơn, hãy ghi lại cho chính mình. Nếu bạn có thời gian, hãy so sánh một vài thiết kế hiệu quả hơn của bạn với những thiết kế bạn đã thực hiện. Hãy thử chúng trong nhỏ (chỉ mã bị ảnh hưởng) cũng như lớn (chương trình sử dụng chúng). Điều này sẽ cho bạn cảm giác khi một cách tiếp cận hiệu quả hơn là phù hợp.

Nhiều người coi tối ưu hóa sớm là một cách tiếp cận xấu. Nó có thể tốn kém để thực hiện. Thật không may, nhiều tối ưu hóa sớm thực sự không hiệu quả như mã mà họ đã tối ưu hóa. Để tối ưu hóa đúng mã, bạn cần ghi lại mã trước và sau khi thay đổi để xem bạn có thực sự cải thiện hiệu quả hay không.

Nghiên cứu các kỹ thuật giúp bạn viết mã sạch hơn với độ khớp thấp và độ gắn kết cao. Trong nhiều trường hợp, giảm độ phức tạp làm tăng hiệu quả. Các kỹ thuật giúp bạn giảm thiểu các lỗi bạn phải sửa trong quá trình phát triển sẽ giúp bạn cung cấp nhanh hơn. Điều này có thể giải phóng thời gian để bạn thử nghiệm các phương pháp thay thế.

Robert bao gồm các khía cạnh quan trọng nhất.

Tôi đã làm việc trong những môi trường như vậy, trong đó mã không (không thể) sống được hơn sáu tháng. Có một vài quy tắc ngón tay cái mà tôi có thể nghĩ ra:

1. Sử dụng các thư viện nguồn mở, giải pháp của bên thứ ba, v.v.,. Việc học có liên quan được đền đáp bằng cách ít bảo trì và gỡ lỗi. Tuy nhiên, nếu bạn bị mắc kẹt với một thư viện lỗi, bạn sẽ phải chịu số phận.
2. Đảm bảo nghiêm ngặt thiết kế của bạn có thể mở rộng. Một yêu cầu bắt buộc: hầu hết các công việc đều là cải tiến, không xây dựng các tính năng mới.
3. Xây dựng kế hoạch kiểm tra nghiêm ngặt. Nhận QA hoặc tự động hóa các bài kiểm tra để đảm bảo kiểm tra hồi quy.
4. Sử dụng các công cụ thông minh - IDE, tiện ích tạo mã, v.v.,.
5. Giữ mọi thứ càng cấu hình càng tốt. (Lật mặt là tăng nỗ lực thử nghiệm)
6. Cải thiện tốc độ gõ của bạn :-)

Trong giai đoạn thiết kế, nói chuyện với đồng nghiệp .

Thảo luận về thiết kế của bạn và cách bạn muốn thực hiện nó, và để chúng xem xét kỹ lưỡng các quyết định của bạn. Nếu và khi tất cả các bạn đồng ý về những gì thông minh, bạn có một thiết kế hợp lý hơn nhiều.

Thực hành. Thực hành viết mã tốt cho đến khi nó trở thành bản chất thứ hai. Sau đó thực hành tại mã hóa nhanh hơn. Sau đó thực hành mã hóa tốt hơn. Và khi bạn hoàn thành ... thực hành thêm một số.

Vấn đề của tôi là tôi luôn viết mã cho giải pháp đầu tiên xuất hiện trong đầu, tất nhiên lúc đó tôi nghĩ là tốt nhất.

Không, đó không phải là vấn đề của bạn. Đó là một đức tính tốt. Đó là làm điều đơn giản nhất có thể làm việc. Nhưng nó chỉ hoạt động khi kết hợp với tái cấu trúc. Đó là một quá trình liên tục: thực hiện điều đơn giản tiếp theo có thể có thể hoạt động, lặp đi lặp lại, để hệ thống của bạn luôn thể hiện sự hiểu biết hiện tại của bạn về không gian giải pháp.

Vấn đề của bạn là bạn có quản lý không hiểu chi phí vòng đời thực của các hệ thống phần mềm. 90% chi phí đó là bảo trì, không phải thực hiện ban đầu. Kiểm tra và tái cấu trúc là những công cụ tốt nhất của chúng tôi để giảm tổng chi phí vòng đời của một hệ thống phần mềm. Nếu người quản lý của bạn sẽ không cho phép bạn làm những việc này, họ sẽ vô trách nhiệm và cần được đào tạo lại. Hoặc bạn cần tìm một công việc mới.

Cuối cùng: như tôi đã nói trước đây *, bạn cần học cách nói không .

* Làm thế nào để mã trên một lịch trình rất chặt chẽ?

Nếu họ cố định phạm vi và thời gian, tất cả những gì bạn có thể làm để thực hiện thời hạn là giảm chất lượng.

Nếu có thể làm giảm chất lượng bên ngoài, hiển thị cho các bên liên quan, đừng thỏa hiệp với chất lượng bên trong, những thứ gây tổn hại đến khả năng sinh sống của bạn trong cơ sở mã.

Tôi thực sự không nghĩ rằng cải thiện bản thân sẽ giúp bạn một chút trong tình huống này. Nếu có bất cứ điều gì sau đó, xin lỗi để nói, thường là sự quyết đoán.

Hãy cố gắng để có được một chân trong cửa khi công việc được ước tính. Làm thế nào sếp của bạn có thể ước tính thời gian bạn muốn làm gì?

Mang lại sự lựa chọn cho sếp và / hoặc khách hàng của bạn. Thông thường, chính các nhà phát triển đã chọn giảm chất lượng mà không truyền đạt bất cứ điều gì. Các dự án / công việc muộn là rất phổ biến và thường là 'được quản lý'. Hành động đúng giờ, cảnh báo mọi người nếu bạn thấy thời hạn bị bỏ lỡ sắp tới.

Họ không thể cắt phạm vi hoặc di chuyển thời hạn nếu bạn không nói gì với họ.

Nếu bạn sẽ thỏa hiệp về chất lượng dưới mọi hình thức, hãy cố gắng để nó là quyết định của họ. Cung cấp cho họ công cụ để trọng lượng với nhau.

Một số thứ chỉ BẠN có thể quyết định. Nếu bạn chỉ cần có nó để làm việc. Nhưng nó rất không thể nhầm lẫn. Có lẽ bạn không chắc chắn nếu nó hoạt động trong mọi trường hợp. Đừng nói với bất cứ ai bạn đã làm xong. Làm lại nó. Rất thường đó là một quyết định chỉ bạn có thể đưa ra. Hoặc bởi vì vấn đề rất tốn thời gian để phát biểu hoặc bạn có một người quản lý phi kỹ thuật.

Đôi khi, đó là một phần trong đạo đức công việc của bạn, bạn chỉ cần khâu bệnh nhân lên mà không rửa tay vì 'không có thời gian'?

Trên hết, hãy nhớ rằng: không có sau này.

Tôi là một nhà phát triển .Net làm việc trên các ứng dụng web.

Những điều tôi đã bắt đầu làm là -

Nếu đó là mã C #, tôi cố gắng viết mã đó trong LinqPad trước (nếu có thể).

Nếu đó là mã Javascript, trước tiên tôi viết mã đó và kiểm tra nó trong jsfiddle / jsbin (nếu có thể).

Tôi thấy rằng điều này giúp với chất lượng mã nhưng không làm tôi chậm lại (và trong một số trường hợp, tôi thấy nó nhanh hơn).