Какие навыки разработки вы приобрели после 7-10 ++ лет опыта в разработке ОО?

Question

Некоторые навыки разработки, такие как операции рефакторинга, чувствуют, что они имеют почти неограниченные важно для обучения - только дурак скажет, что закончил это.

Другие навыки связаны с конкретными инструментами, и, будучи хорошими разработчиками, мы изучаем новые инструменты большую часть времени.

Но некоторые навыки связаны с тем, как вы думаете о коде и о том, как вы подходите к кодированию, иногда о том, как может быть конкретная функция инструмента. применяется. Вращение парного программирования и тесное сотрудничество с другими людьми, кажется, лучший способ приобрести эти навыки, хотя, конечно, не единственный метод. (И иногда вы узнаете вещи, которые ДОЛЖНЫ выучить 5 лет назад, это не те вопросы, о которых я спрашиваю)

Итак, я хочу связать программу со всеми StackOverflow:

Каковы ваши поздние навыки кодирования?

Редактировать: Я полагаю, я не думаю о вещах, которые вы бы узнали в рамках учебной программы, если бы вы пришли прямо из школы сегодня.

Answer 1

Только когда я понял, что мне нужно человеческие навыки , чтобы дополнить свои технические навыки, я действительно начал развивать свою карьеру.

Удивительно, как часто это упускают из виду программисты или считают неважными по сравнению с «навыками разработки».

Answer 2

Это может показаться глупым и очевидным, но ... Я думаю, что мне потребовалось много лет, чтобы разобраться в этом, насколько я понимаю:

• Знание, когда писать комментарии там, где они действительно необходимы.
• Знание, когда НЕ нужно писать комментарии, потому что код теперь достаточно самодокументирован.

Answer 3

Это умение быть лучшим разработчиком в команде, а не просто умение создавать приложение, которое (более или менее) соответствует спецификации и компилируется, и пользователь / тестер не должен слишком много кричать.

1. когда защищенно писать расширяемый код, потому что вы знаете, что это сэкономит ваше время в конце.
   • когда явно не указывать пункт (1).
   • как работать в команде
   • как читать и реагировать на спецификацию, которая не является удивительно точной или четко написанной
   • когда (и как) разрешить кому-то еще проект в стиле фанк, потому что вы слишком заняты с drudge

В основном речь идет о том, чтобы быть лучшим вьючным животным, бывают времена и места для альфа-самца, но слишком часто программисты не могут воспринимать критику, и мы не всегда можем играть с проектами, как с нашими игрушками. ,

Если вы не можете этого сделать, то Гай Кавасаки и Джоэл Спольски написали много хороших статей о создании собственной компании.

Answer 4

Я научился не привязываться лично к коду, который я пишу. Я больше не чувствую личной атаки / нарушения, когда люди меняют мой код или критикуют мой код.

Answer 5

Хм, написание тестируемого кода благодаря внедрению зависимостей. Как удалось нам удается раньше ...

Для меня это, зная, что тестировать.

Некоторое время я был фанатом, который говорил, что все должно быть проверено, методы получения / установки DTO и т. Д. Это нецелесообразно и не нужно. Вы должны проверить (до смерти) сложные и критические вещи, потому что именно там находятся ваши сложные и критические недостатки. Слегка протестируйте остальное.

Answer 6

Прагматизм и навыки людей.

Быть прагматичным в ситуации. Да, это может быть идеальным, но действительно ли это необходимо. Что-то может быть самой крутой функцией в мире, но действительно ли она будет приносить больше дохода. Задавая эти вопросы и будучи реалистичным, вы сможете отфильтровать много соломы из пшеницы.

Я все еще изучаю навыки людей. Речь идет не только о знании всех ответов, но и о возможности передать их Руководству и Клиентам таким образом, чтобы они поняли и приняли их. Быть аутистом с ОКР и биполярным иногда немного сложно.

Answer 7

Некоторые навыки, которых не было, когда я начал кодировать:

• Юнит-тестирование,
• Рефакторинг
• Некоторые другие проворные парадигмы.

Вы должны перестать учиться, только если перестанете дышать.

Answer 8

Макетирование и макетирование.

Я думаю о тех временах, когда в прошлом я впервые погрузился в разработку функции «на месте» - гораздо лучше изолировать проблему в приложении-песочнице.

Насмешка - опять же, следуя принципам изоляции (Divide & Conquer), это абсолютно необходимо для любого дизайна, который я придумываю сегодня.

Answer 9

Смирение от того, что вы видите столько кода, какого-то хорошего, какого-то плохого, а потом - просто странного, что вы узнаете, что вы хотите иметь, где работаете, а что нет. Например, некоторым нравится программирование в стиле «Ковбой», в то время как другие полностью методичны и ничего не сделают, поскольку они являются частью плана, который был составлен, проверен и одобрен 3-мя руководителями высшего звена, чтобы получить благословение сделать что-то, что может занять пару недель.

Совершенствование организации кода и выяснение того, где можно сделать рефакторинг, чтобы сделать что-то более общее, чтобы у него было больше применений, или когда пытаться заблокировать что-то, чтобы это было сделано, в отличие от косметических изменений, выполняемых снова и снова, как это делает клиент. Не знаю, чего они хотят, но им не нужны 101 прототип, который они видели.

Answer 10

Программные архитектуры, Программирование в целом. Я понял, что программное обеспечение >> код, и вопрос языков программирования в лучшем случае является третичным.