"Привет, мир!" Я не собираюсь начинать с плохой шутки или :) Так что это я! Сегодня ты будешь моим психологом, я расскажу тебе некоторые свои беды. Давайте начнем!
Называть кого-то хорошим программистом или плохим программистом мне всегда кажется высокомерным. С самого начала своей карьеры я всегда работал в agile-командах. Но какие-то атрибуты, какие-то привычки или какие-то особенности могут выделить вас или поставить на задний план, или вы можете свести их с ума и сломать их психологию. Ладно.. ладно, иногда это может быть весело, нам нужно веселье, ладно… ладно… я могу это принять :) Я не собираюсь торчать ради развлечения и менять ситуацию. Я должен быть последовательным прямо сейчас :) Были люди, которых я спрашивал, как этот человек делает программное обеспечение, и я хотел бы передать вам черты, которые я вижу в этих людях.
- Чтение и понимание кода
Нет, я не преувеличиваю! Некоторым программистам тяжело читать код или sql-скрипт как книгу (я не говорю о плохо написанном бессмысленном коде). Конечно, в больших системах бизнес-информация должна быть объяснена, что она делает, где она работает или почему она работает. Такие люди обычно пытаются разобраться в деловой части с помощью кого-то. Они должны быть проинформированы.
Но если кто-то рассказывает вам каждую строку всего кода, в этом может быть проблема. Вам нужно прийти к компетенции читать код самостоятельно. Возможно, вам придется написать или прочитать больше кода, если вы так считаете.
2. Программист Ctrl + C и Ctrl + V
Если вы не умеете читать коды, есть способ кодировать :) Копировать Вставить! Некоторые программисты нашли способ писать код, копируя одни и те же методы, не затрагивая другие, с минимумом кода и тестирования. Хорошо, это может быть приемлемо, но… Вы не можете скопировать и вставить один метод ниже и изменить второй, добавив небольшое изменение. Это не пример, конечно, но я могу описать код, который я вижу аналогично;
. . . int x = Method(1,2); //Not Touched int y = MethodModified(1,2); // Added . . } private int Method(int first, int second) { int sum = 0; if(first > 0 && second > 0) { sum = first + second; } return sum; } private int MethodModified(int first, int second) { int sum = 0; if(first > 0 && second > 0 && second < 1000) { sum = first + second; } return sum; }
Вместо мультиплексирования кодов возможны простые вмешательства путем интерпретации структуры :) Мы не должны так бояться играть с кодами, даже если это заставит нас больше тестировать, мы можем в конечном итоге создать более здоровый читаемый код.
3. Объяснение
Когда мы понимаем, что в коде есть ошибка, объяснение нашим товарищам по команде не должно быть «в коде есть ошибка, к вашему сведению». Итак, я могу спросить вас: «Где? Есть лог, что там написано? Почему случилось? Что случилось? Как мы можем исправить?» Разработчик должен уметь объяснить это подробно и аналитически.
Например, «Посмотрел логи, столкнулся с этой ошибкой в этом методе, это произошло по этой причине. Мы можем решить эту проблему с помощью следующего решения».
Когда заказчик спрашивает о состоянии работы или когда она будет закончена, мы не должны говорить, что «мы не знаем». Вы можете объяснить части, которые вас заблокировали, и четко сказать, почему вы опаздываете или как долго вы будете опаздывать. Ответ всегда должен содержать ясность, если вы инженер или разработчик.
4. Емкость
Некоторые разработчики думают, что «я достаточно вырос». В этой работе нет предела. Вы должны совершенствоваться каждый день, каждый месяц, каждый год, и каждый год вам должен не нравиться код, который вы написали в прошлом году. Если вы говорите «Я достаточно вырос», ваши возможности и ограничения остаются постоянными и возвращают вас обратно, потому что в программном обеспечении есть процесс, который постоянно обновляется и развивается, а качество написанного кода может как снижать, так и повышать качество команды.
5. Будьте активны
Не все в команде берут на себя ответственность. Если информация распределяется непропорционально, одни будут работать больше, а другие меньше, и часто другие команды склонны перерабатывать. Это всегда нарушает баланс внутри коллектива, а когда уходит сотрудник, который берет на себя ответственность, это ослабляет силу коллектива. В команде, где все активны, баланс сил распределяется поровну и команда развивается вместе.
Береги себя:)