Jakiej najlepszej lekcji nauczyłeś się w swojej karierze? [Zamknięte]

Myślę, że moim jest „nie ma czegoś takiego jak pięciominutowa praca” - że programiści są zbyt optymistyczni co do rozwoju i że powinniśmy naprawdę przemyśleć implikacje, zanim obiecamy szybkie rozwiązanie problemu, a następnie zanurzymy się w kodzie

Zawsze jest lepszy sposób na napisanie kodu.

Bez względu na to, jak świetnie znajdziesz kod, który napiszesz, zdziwisz się, jak źle jest, jeśli przejrzysz go za kilka lat. Tylko dlatego, że kilka lat wcześniej nie byłeś świadomy niektórych wzorców, które znasz dzisiaj, lub niektórych funkcji językowych, których nauczyłeś się w międzyczasie itp.

1. Pomyśl, zanim zaczniesz kodować.

2. Nie ma nic bardziej trwałego niż tymczasowe rozwiązania :)

3. Jeśli rozwiązanie problemu jest bardzo trudne, najprawdopodobniej sam problem jest od samego początku źle postawiony.

Twoje oprogramowanie będzie działało znacznie dłużej niż myślisz w momencie jego pisania.

Karierę rozpocząłem w latach 80-tych. Zacząłem od oprogramowania, które powstało w latach 70. i wciąż było używane w latach 90. (może dłużej, nie wiem na pewno o jego losie). Niektóre z moich własnych kodów open source są w połowie drugiej dekady.

Dobra współpraca z innymi jest bardzo ważna.

„Pokaż mi swoje„ Idź do faceta ”, a pokażę ci twój problem”

Slapdash Hero Coders - ci, którzy po prostu wypakowują kod, nie zważając na konwencję, czytelność czy cokolwiek, nad kim pracują inni - mogą wyrządzić więcej szkody niż pożytku.

Nie mówię, że ludzie, którzy potrafią pisać tony kodu dobrej jakości, są złymi rzeczami. Po prostu rzadkie.

To byłaby lekcja pokory.

Nauka nowych języków jest częścią pracy

Nauczyłem się o czterech językach programowania w szkole w latach 80., ale użyłem jednego z nich w pracy. Miałem cztery prace, w których nawet nie znałem języka, w którym zostałem zatrudniony.

Ogólnie nauczyłem się i posługiwałem zawodowo być może tuzinem języków w swojej karierze, w tym FORTRAN, c, c ++, c #, java, perl, Tcl, ruby, groovy, awk, python, sh, batch, DCL, javascript i kilka małych DSL. Robiąc małą matematykę, wydaje mi się, że średnio co kilka lat przeceniam nowy język, choć nakładają się na siebie.

Jeśli coś było stałą w mojej karierze, to zmiana.

Oprogramowanie nigdy nie jest kompletne.

Zawsze są pewne zmiany wymagań, ulepszenia, poprawki błędów, które musisz przygotować. Dlatego bądź elastyczny i zaakceptuj fakt, że "software is never complete"zawsze można wprowadzić ulepszenia.

Ucz się codziennie. Znajomość dnia dzisiejszego jutro jest przestarzała.

Jak na ironię, ta odpowiedź również jutro powinna być nieaktualna. Ale tak naprawdę, przestudiuj dokładnie jedną lub dwie rzeczy i uzyskaj certyfikat, jeśli to możliwe, bądź ich bogiem (może językami programowania lub administracją systemu / sieci / bazy danych) i zawsze miej oko na inne drobne rzeczy, takie jak inne języki bez znaczenia dla ty.

Mam na myśli, na przykład, być świetnym profesjonalistą w dziedzinie administracji Java i Oracle DB, ale studiuj trochę Python, PHP, C ++, HTML5, Javascript, choć nie na poziomie certyfikacji. Przestudiuj każdą istniejącą strukturę internetową lub językową. Studiuj lub próbuj mieć (podstawowe) doświadczenie z każdą istniejącą bazą danych, taką jak SQL Server, MySQL, Cassandra, HBase, PostgreSQL i cały świat bez SQL, taki jak MongoDB i CouchDB. Postaraj się mieć trochę doświadczenia w administrowaniu i wirtualizacji systemu Linux.

To największa lekcja, jaką wyciągnąłem z mojego 16-letniego doświadczenia. Przez prawie 10 lat byłem programistą w jednym języku, używając Pascala w tamtych czasach i Visual Basic 6 na początku tysiąclecia, a od 9 lat jestem programistą PHP. Ale od tego czasu dowiaduję się, że programiści muszą wiedzieć przynajmniej trochę wszystkiego.

„Jeśli twoja matematyka jest błędna, toast”.

Nauczyłem się tego po raz pierwszy kilka lat temu. Nauczyłem się tego jeszcze dwa tygodnie temu.

Powiedziałbym, że najlepsza lekcja, jakiej się nauczyłem

„Zawsze powinieneś wybierać najlepsze możliwe podejście, a nie swoje ”.

Dowiedziałem się, że najlepszą zasadą projektowania jest KISS (Prostota, głupku!) .

Dowiedziałem się, że utrzymanie prostego i czystego kodu powinno być głównym celem, a każdy członek zespołu powinien zrozumieć, co masz kod. The KISS principlestwierdza, że ​​większość systemów działa najlepiej, jeśli są one proste, a nie złożone, dlatego prostota powinna być głównym celem w projektowaniu i należy unikać niepotrzebnej złożoności.

Jeśli nie jest zepsuty, nie naprawiaj go!

Próba rozszerzenia i ulepszenia rzeczy, które już działają, może sprawić ci duży ból głowy

Nie ma próby

Powiedzmy, że masz zadanie lub kilka zadań, których wykonanie szacuje się na 4 dni. Następnie szef lub kierownik projektu pyta, czy możesz spróbować zrobić to w ciągu dwóch dni z ważnego powodu. Chcąc być dobrym, elastycznym pracownikiem, możesz mieć ochotę powiedzieć: jasne, możesz spróbować. Najprawdopodobniej wyniknie to z tego, że albo spóźnisz się na termin, albo zrobisz na wpół osłupiały hack, aby to zrobić. I to nie wina twojego szefa, że ​​cię o to poprosił, to jego praca. To twoja wina, że ​​nie powiedziałeś „nie”, co jest twoją pracą.

Z czasem nie można się targować. Możesz targować się z lunetą. Bądź profesjonalny i nie sprzedawaj się krótko.

„To się nigdy nie wydarzy” w rzeczywistości oznacza „To się nie stanie aż do pierwszego dnia produkcji”

Dobrze jest pisać na najwyższym poziomie, najnowocześniejszy, czysty kod.

Nawet jeśli poproszę cię o szybkie obejście problemu, które zrujnuje bazę kodu, raczej zrobię to dobrze.

• Pisanie kodu jest łatwe. Czytanie kodu jest trudne. Nawet jeśli kod jest twój. Jeśli to możliwe, wybierz podejście czytelne.

• Nie jesteś mądrzejszy od innych. Nigdy nie myśl, że twoje podejście jest najlepsze tylko dlatego, że jest twoje.

• Zwróć uwagę na CO, co zostało powiedziane, a nie przez KTO, co zostało powiedziane. Mogą pojawić się genialne pomysły na najbardziej nieoczekiwane źródła.

• Nie bądź leniwy. Nie spiesz się, aby napisać ładny kod. I tak będziesz musiał to naprawić wyższym kosztem.

Nie używaj fantazyjnych funkcji OOP tylko dlatego, że możesz! - YAGNI (nie będziesz go potrzebować)

Use fancy OOP featuresponieważ mają konkretne, dające się udowodnić korzyści dla problemu, który próbujesz rozwiązać . Śmiejesz się, ale cały czas to widzę. Większość programistów nigdy nie spotkała obiektu, którego nie lubił. Myślę, że powinno być na odwrót: te techniki są winne, dopóki nie zostaną udowodnione niewinność przed sądem KISS .