Хорошо, я шучу насчет № 5.
Вы, наверное, поверите, но знаете, как это бывает в наше кликбейтное время — если у вас нет списка вещей, из которых хотя бы одно вас поразит/напугает/отвратит, то никто не будет читать то, что вы выкладываете. вниз.
Имея это в виду, вот 10 вещей, которые я узнал о своей работе за эти годы, которые (в основном) удивительно не связаны с техникой и которые, я действительно чувствую, сделали меня намного лучшим разработчиком программного обеспечения.
1/ Не пытайтесь изучать языки или фреймворки, потому что они крутые «новички» в этом районе.
Вы паникуете, потому что пока не умеете писать на Go? У вас был экзистенциальный кризис, потому что вы слышите о том, что React — это «все», но не понимаете разницы между хуком и классовым компонентом? Расслабляться. Так легко увязнуть в стрессе «следующей большой вещи», что вы можете тратить энергию, пытаясь оставаться впереди воображаемой линии «технической компетенции», которая никогда не перестанет двигаться. Я знаю, что сошел с ума, пытаясь выучить каждый новый язык или фреймворк, которые рекламировались как следующая большая вещь. Это утомительно и не особенно полезно. Изучайте материал, потому что он вам интересен или нужен для работы. Не беспокойтесь о том, что делают все остальные. Не слушайте того парня в офисе, который ругает вас за то, что вы C#-разработчик, и, по его словам, если вы не пишете Node.js, то вы, по сути, ходячий мертвец.
Ты знаешь кто ты есть.
2/ Модульные тесты НЕ являются пустой тратой времени.
Я избегал их годами. Почему юнит-тест? Я просто хочу войти туда и построить. Но модульные тесты строятся, и строятся на правильном фундаменте. Как только ваш модульный тест запущен, вы прошли 90% пути к функциональности, просто продолжайте! С дополнительным преимуществом тестируемости и — давайте будем честными — обычно лучшего кода. TDD (Test Driven Development) позволяет сделать ваш код лучше. Я оглядываюсь на себя в прошлом, думаю обо всех проектах, которые он сделал без модульных тестов, и плачу. Я не говорю, что модульные тесты — это серебряная пуля, но чаще всего они являются невероятно эффективным способом создания хорошего программного обеспечения с нуля.
3/ Примите свое невежество.
Не скрывай того, чего не знаешь! Будьте откровенны в этом. Сокрытие недостатка знаний — беспроигрышный сценарий. В начале своей карьеры я пытался избежать того, что я считал «позором» непонимания технической концепции программного обеспечения, просто притворяясь. Я имею в виду, что это стратегия — конечно. Но не очень хороший. Я научился чувствовать себя комфортно, говоря: «Понятия не имею». «Понятия не имею» — мощная фраза, потому что она дает идеальную отправную точку для обучения. После «Понятия не имею» следует «Помогите мне понять?» и вы привлечете наставников и учителей. Люди, которые хотят вам помочь. Встаньте на их плечи и в таком быстро меняющемся мире, как разработка программного обеспечения, почувствуйте себя комфортно, никогда не зная почти всего. Который прекрасно сочетается с….
4/ У каждого разработчика вокруг вас есть синдром самозванца.
Серьезно. Это правда. Я знаю, тебе кажется, что ты не «крутой» разработчик. Что парень или девушка, сидящие рядом с вами, на дрожжах впереди. Что они узнают, что вы искали ответы на Stack Overflow, и вас выставят из офиса голым, а Скрам-менеджер будет ходить позади вас и скандировать: «Позор! Позор!»… Но стоп. Расслабляться. У каждого разработчика есть синдром самозванца. На самом деле это очень распространено, и если вы создадите доверие со своими коллегами-разработчиками, чтобы вести «такой» разговор, вы поймете, что все думают, что все остальные — это Нео, и все технически думают о себе гораздо меньше, чем они, вероятно, должны были бы. .
5/ Проекты и документация. Пожалуйста. Пожалуйста пожалуйста пожалуйста.
Я почти могу обещать вам, что если вы сначала перестанете торопиться с написанием кода, а вместо этого сначала нарисуете несколько эскизов и диаграмм и получите некоторую ясность в отношении того, чего вы пытаетесь достичь, ваше окончательное решение будет тем лучше. Рисование дизайна создает концепцию, обозначает поток, подчеркивает возможности и недостатки так, как код сам по себе не может.
Именно по этой причине архитекторы сначала рисуют схемы домов, а не просто бросают кирпичи на землю и смотрят, что получится. Хорошая диаграмма помогает не только вам, но и тем, с кем вы хотите общаться. Поделиться представлением вашего решения становится действительно легко, но прятаться в прямоугольниках и линиях — это столько глубины, сколько вы хотите добавить.
Помимо диаграмм, документация — хотя может показаться, что много печатать — бесценно для вас, для людей, поддерживающих вашу работу, и для организации в целом, если и когда вы решите переехать на Ямайку, чтобы создать пляжный магазин по продаже кожаных сандалий и кокосового масла холодного отжима. Я знаю аргумент о самодокументированности кода, но нет. Просто нет. Документация — это больше, чем просто описание кода. Это может быть поддержка, диагностика, внедрение, бизнес-логика, функциональные флаги и многое другое. Сделай это. Выделите время и сделайте это.
6. Команды ИТ-безопасности/SecOps не станут препятствием, если вы сами их не создадите.
В первый раз, когда мне пришлось работать с пен-тестером, чтобы протестировать приложение, которое я собирался создать, я, кажется, был… как бы это сказать, оскорбленным? Может быть? Немного. Я как бы подумал про себя: «Что это? Они мне не доверяют? Они не думают, что я умею писать безопасное приложение?». На самом деле все это было немного глупо, но я обнаружил, что моя первоначальная сдержанность не редкость в мире ИТ. Разработчикам нравится свобода использовать любые инструменты, которые им нужны, и строить так, как они считают нужным. Они могут видеть, что команды SecOps вторгаются в это пространство со своими блокировками сайтов, правилами брандмауэра и тестами на проникновение ваших API.
Но это просто ерунда. Это разрозненный способ мышления, и я рад, что рано избавился от него. Дело в том, что вы — в своей роли разработчика — и специалист по безопасности, и менеджер изменений, и тестер, вы все являетесь частью более широкой команды с одной общей целью. Делайте лучшие «вещи». Что бы это ни было. Дело в том, что «лучший» — это не только хороший разработчик программного обеспечения. Вам нужно, чтобы он был безопасным, надежным, пригодным для использования. Это не может быть просто упражнение в чистом коде, если вы действительно хотите сделать лучший продукт, это командная работа — и в наши дни, возможно, больше, чем когда-либо в истории технологий, безопасность является огромной частью головоломки. Так что примите свою команду безопасности. Не рассматривайте их как препятствие, сотрудничайте с ними! Всегда есть способ найти баланс между безопасностью, надежностью и инновациями. Это просто включает в себя выделение времени и приложение усилий. Научитесь ценить безопасное приложение как часть вашей ответственности, а не как нечто, чем должна «управлять» группа SecOps. Изучите свой OWASP. Будь офигенным! (Надежно).
7/ Простой код — хороший код. В целом.
Были времена, когда я сталкивался с такими понятиями, как абстракция, интерфейсы, дженерики и так далее, чтобы немного сойти с ума. Интерфейсы, абстрагирующие интерфейсы, абстрагирующие интерфейсы с делегатами над дженериками, и, Боже мой, остановите это! Хорошо понимать некоторые сложности разработки программного обеспечения, но хорошо сопротивляться желанию перепроектировать решение просто потому, что вы можете.
Есть время и место для сложности, но часто лучше работать с чем-то простым. Простые методы, простой код. Чисто, читабельно. Потяните за причудливые рычаги, когда вам нужно, но я хотел бы вернуться назад и уберечь себя от сложных решений, потому что я только что изучил кое-что новое в программировании. Частью усвоения этого урока для меня было признание того, что я создавал что-то со структурой почти корпоративного уровня, но это просто не собиралось использовать таким образом, который оправдывал бы это. (Например, тратить дни на создание интерфейсов для доступа к данным, чтобы было легче «заменять» технологии баз данных в будущем, когда на самом деле вероятность того, что это когда-либо произойдет, равна нулю…)
8/ Не бойтесь начать заново. С нуля.
Это так просто, но после 22 лет работы в ИТ я до сих пор укрепляю себя в этом. Каждый разработчик в какой-то момент оказывается в затруднительном положении из-за неудачного выбора дизайна. Вы построили что-то быстро, лениво, и это нормально. За исключением того, что вам нужно добавить к этому шаткому виджету еще несколько шатких виджетов. Затем вы сбалансируете уровень интеграции поверх этого.
Перенесемся на несколько недель вперед, и вы создадите самый красивый дом из шатких карточек-виджетов, который когда-либо существовал. Почему? Потому что ты решил, что легче броситься вперед, чем считать осмотрительность лучшей частью доблести и отступления. Но это отступление было — по крайней мере, для меня — ключевым уроком. Иногда вам нужно признать, что вы создаете что-то в корне неправильное, и что даже если вы можете заставить это работать, в долгосрочной перспективе вам будет гораздо лучше разорвать код и начать заново.
Как я уже говорил, я пересматривал этот урок даже недавно. Я работал над приложением .NET Razor pages, и из-за нескольких неудачных/поспешных решений во внешнем интерфейсе в начале я получил действительно шаткую кучу кода JavaScript и Razor. Всего 400+ строк. Был момент, когда я просто сидел и говорил: «Хватит. Это нонсенс".
Так что я сорвал все это и начал снова. Результат? 90 строк кода, которые намного эффективнее и могут быть расширены просто и легко. Не воспринимайте снос как поражение. Речь идет о способности распознавать, когда вы просто строите на плохом фундаменте. С кем не бывает. Не наказывайте себя в будущем, игнорируя знаки.
9/ Уважайте шаблоны проектирования!
Теперь, когда я говорю об уважении, это не означает поклонение. Вам не нужно обязательно внедрять в свой код каждый шаблон проектирования, который вы изучаете, потому что для всего этого есть время и место, но важно знать, что они из себя представляют и почему они полезны. Я потратил слишком много лет на то, чтобы как бы «раскрутить» основной дизайн своих приложений, и это проявилось. Сделав шаг назад от написания кода и потратив больше времени на изучение шаблонов проектирования, таких как Unit of Work, Factory, Facade и т. д., я получил гораздо больше признательности не только за конкретные приложения дизайна в моих проектах, но и в целом. признательность за «мысль», стоящую за хорошим дизайном программного обеспечения. Это не просто — или, по крайней мере, не должно быть — просто разбивать код. Здесь есть настоящая инженерия.
Вы можете не использовать эти шаблоны каждый день, но вы, вероятно, обнаружите, что решаете проблемы в своем коде, используя части этих шаблонов, например, легко увидеть множество мест, где вы могли бы реализовать ядро шаблона Factory для создания подобных объектов. в вашем коде. Речь также идет о создании своего рода общего повествования между вашей работой и разработчиками, которым, возможно, придется сотрудничать с вами.
Это одна из причин существования шаблонов и стандартов. Это не значит, что мы все будем дронами и будем создавать одни и те же структуры программного обеспечения изо дня в день, но эти стандарты создают простую для понимания основу для кодовых баз, над которыми мы делимся работой, так что продолжение того, на чем кто-то остановился, не будет проблемой. случай, когда вам нужно начать совершенно новый разговор, а скорее это похоже на то, как если бы вы взяли нить, которую вы никогда не прекращали полностью.
10/Создавайте возможности. Не ждите, пока они появятся.
Это легко связать не только с разработкой программного обеспечения, но поскольку моя профессиональная жизнь была связана с технологиями в течение 22 лет, я подхожу к этому через призму.
Это для меня в прошлом, который потратил годы, гадая, когда же кто-нибудь даст ему работу мечты, которую он хотел.
Иногда, несмотря на все интересные навыки программирования, которые вы изучаете, все исследования, которые вы провели для создания крутых веб-приложений, или написания потрясающих интеграций, или структурирования связных схем баз данных, может быть трудно получить возможность применить эти вещи на практике. работать на своей работе. Может быть, вы просто исправляете незначительные дефекты, небольшие фрагменты кода здесь или там, или, может быть, вы даже не работаете инженером, вы просто знаете, что хотите быть им.
Последнее, ну, это был я в первые годы моей технической карьеры. Я работал в ИТ-поддержке, поэтому ближе всего к архитектуре, дизайну или проектированию я подходил к запуску готовых сценариев SQL, предоставленных нам другими командами, для решения незначительных проблем с данными.
Но я изучал (в то время) VBScript, .NET и ASP. У меня были некоторые навыки, и я отчаянно хотел использовать их для решения бизнес-задач. Поэтому вместо того, чтобы ждать возможности, я начал создавать вещи. Все, что я мог придумать. Пока я использовал свои навыки, я строил его. VBScript здесь или там, чтобы что-то автоматизировать. Переписанные сценарии SQL, предоставленные нам для улучшения диагностики или вывода. Я даже начал писать сопутствующее приложение для программного обеспечения, которое мы использовали для приема телефонных звонков и управления проблемными заявками.
Каждый из этих проектов создавался самостоятельно, имел небольшой масштаб и не собирался менять мир. Но что они сделали, так это привлекли внимание. Ходили слухи, и после создания бесчисленного количества приложений и виджетов разной полезности меня повысили до должности технического аналитика/программиста.
Всегда ли так будет получаться? Нет. Но я думаю, что это хороший способ максимально использовать свои возможности. Не ждите похлопывания по плечу. Начать строительство. Начните создавать. Благодаря тому, что поставщики общедоступных облачных сервисов предоставляют вам практически безграничные вычислительные ресурсы, хранилища и архитектурные решения, настало фантастическое время для того, чтобы быть кем-то, у кого есть стремление строить и желание создавать технологии. Поэтому начните думать о том, что вы можете сделать — даже если это в свободное время — чтобы использовать навыки и страсть, которые вы развиваете, для разработки программного обеспечения.
Какие уроки, которые вы извлекли из разработки программного обеспечения, повлияли на вашу карьеру? Вы рано их выучили? Поздно? Вы выучили некоторые из тех же, что и я? Дай мне знать в комментариях!
