Олексій Пєніє Developer, Java
выделил с чем согласен
Я знаю примерно 5% наполнения тех фреймворков и особенностей языка, с которыми работаю прямо сейчас или работал совсем недавно. Те, с которыми давно — 1% достаточно объективная оценка.
Такова селяви. Если ты работаешь над сколь-либо серьёзными вещами, то функционал обеспечивается не языком или фреймворком, а бизнес-логикой самого продукта. Вот его я знаю на 90% и более.
Такова моя роль. Я стараюсь делать бизнес-логику как можно более простой и понятной. И всё, что требует понимания каких-то редких вещей, я просто 1 раз понимаю, снабжаю комментами, и забываю что там было. Мне достаточно знать имя класса, где происходят трудно изучаемые вещи. А с точки зрения бизнес-логики, операция идёт уже с классами, и львиная доля кода состоит из примитивнейших конструкций. Например, каждая третья операция это какое-нибудь «если». Собственно говоря, это и есть хороший код, когда логика видна, а подковёрная работа спрятана и описана чётко в своём уголочке.
ЛИБО, если код короткий, делается строго обратное: выбрасываются лишние сущности, а кусочки кода тупо копипастятся. С целью сделать его читабельным и снизить требования к памяти при чтении. Но опять же, если это требует общения с редко встречаемыми конструкциями, я стараюсь обернуть это во внутренний класс, или же в анонимку, стараясь дать сущности имя через создание (или использование общепринятого) интерфейса.
Так что никаких must have. Работать надо не головой, а компьютером. Если что-то за тебя может делать компьютер — даже думать забудь это зубрить. Просто помни как назвал или где положил. И не скупись на комментарии. Потому что если забудешь как назвал — тебе поможет полнотекстовый поиск, хорошие комменты содержат все ключевые слова, по которым ты можешь захотеть поискать.
По той же причине в недописанном коде комментов куда больше, чем в готовом. Они лучше тестов обеспечивают целостность. Потому как в написании тестов легко ошибиться, когда код ещё не готов. А вот в описании идеи, что ХОТЕЛОСЬ сделать, ошибёшься ты сильно вряд ли (в силу избыточности естественных языков, дающей устойчивость к ошибкам). Когда же код написан, комменты лучше перенести в тесты. Ибо когда тест какой-то завалится, всегда полезно знать, как на самом деле должен работать код, и соответственно что надо править — сам код, тестовый набор данных, или же тесты.
А по поводу работы с людьми — это хард скиллы, а не софт. Как раз софт это то что приходится постоянно апгрейдить, а вот если с людьми какие-то нестыковки, тут уж никакие знания не помогут. Потому что это фактор, влияющий на скорость выполнения работы в 10…100 раз и выше. По той же причине джунов не хотят брать. Не потому что знают мало. А потому что синдром Даннинга-Крюгера одного тормозит всю работу всем.