Как мы все знаем, технологии быстро меняются. Сегодня мы можем быть хороши, но завтра будет другой день. Здесь мы собираемся обсудить, почему мы являемся хорошим программистом, а также некоторые способы, в которых мы можем улучшить себя.
Вы можете адаптироваться и изучать новые технологии
Всякий раз, когда появляется что-то новое, новый язык, новая библиотека или любая новая технология, вы готовы адаптироваться и изучать это. Вы можете быстро подобрать его и применить к своей реальной работе.
Но уверены ли вы, что используете его правильно? Можно ли что-то сделать с тем, что вы уже знали?
Иногда мы применяем новые знания в своей работе, не до конца понимая их цель. Да, хорошо браться за руки, пачкать руки, потому что это самый эффективный способ чему-то научиться, но мы должны быть осторожны, применяя его для решения наших реальных проблем. Почему? Потому что в большинстве случаев это делает вещи излишне сложными, а иногда (что мы обязательно должны предотвратить) добавляет больше проблем, чем решений.
Не поймите меня неправильно, использование новых знаний допустимо, но мы должны полностью понимать, почему мы это делаем и какие фактические проблемы оно решает. Насколько это возможно, все должно быть осмысленным и практичным. Помните, что мы строим, чтобы упростить, а не усложнить нашу жизнь.
Вы умеете ставить и доводить дела до конца
Вы можете доставить рабочий продукт в срок. Вы можете сравнить себя с другими, которым трудно доставлять продукты (не говоря уже о правильной работе) вовремя.
Но пробовали ли вы сравнивать себя с другими, которые могут сделать то же самое? Какую разницу вы видите?
Помните, что вы можете предоставить работающий продукт вовремя, не слишком задумываясь о качестве кода и архитектуре. Иногда вы можете доставить его намного быстрее, поскольку ваша единственная цель — заставить его работать. Но каковы последствия этого? Вам и другим становится трудно его поддерживать. Когда нужно сделать новую функцию или исправить ошибку, это может занять больше времени, чем у тех, кто создает ее с чистым кодом и правильной архитектурой.
Да, работа над продуктом при сохранении чистого кода может занять некоторое время, но в долгосрочной перспективе вы сможете последовательно оценивать свои задачи. Долгосрочная согласованность важнее краткосрочной интенсивности.
Вы можете правильно спроектировать и внедрить принципы кодирования
Любой проект, который вы берете, или любые проблемы, поставленные перед вами, вы можете правильно спроектировать для своей кодовой базы. Вы можете правильно применять лучшие практики и принципы проектирования.
Что может пойти не так, когда вы можете это сделать?
У меня есть проект, в котором я правильно практиковал и реализовывал чистую архитектуру. По мере того, как проект становится больше, бизнес-поток усложняется. Есть также поступающие новые сотрудники, которым требуется наставничество и передача знаний. Несмотря на то, что я применил чистый подход к нашей кодовой базе, все еще есть проблемы с реализацией новых функций и обучением новых сотрудников. Но почему? Разве чистый код не должен решить эту проблему? Да и нет. Проблема в том, что я не выровнял наш поток кода с бизнес-потоком, это означает, что я неправильно перевел бизнес в код (отображение классов/потоков кода). Эту проблему можно решить с помощью Domain Driven Design (DDD). Это подход к разработке того, как мы должны создавать наш код, где мы переводим фактические имена сущностей и процессы из домена/бизнеса в наши классы и методы. Есть много статей, объясняющих DDD.
Некоторые позитивные мысли
Не существует стандартного универсального способа определить, являетесь ли вы хорошим программистом. Да, есть количественные показатели (упражнения по кодированию, работающий продукт, технические оценки и т. д.), но они имеют определенный охват, в котором некоторые из нас могут быть за, а некоторые нет, и они могут иметь бесконечное количество возможных изменений/обновлений.
Опять же, мы все знаем, как трудно идти в ногу с быстрыми изменениями в технологиях. Будет определенный момент, когда мы будем перегружены этой информацией и знаниями. Всегда найдется программист лучше нас, и это не должно нас обескураживать. Вместо этого давайте использовать его как источник вдохновения и руководство, чтобы стать лучше. Мы должны признать, что мы не знаем всего, и когда это происходит, это означает, что у нас есть мудрость.
