"Привет, мир!" Я не собираюсь начинать с плохой шутки или :) Так что это я! Сегодня ты будешь моим психологом, я расскажу тебе некоторые свои беды. Давайте начнем!

Называть кого-то хорошим программистом или плохим программистом мне всегда кажется высокомерным. С самого начала своей карьеры я всегда работал в agile-командах. Но какие-то атрибуты, какие-то привычки или какие-то особенности могут выделить вас или поставить на задний план, или вы можете свести их с ума и сломать их психологию. Ладно.. ладно, иногда это может быть весело, нам нужно веселье, ладно… ладно… я могу это принять :) Я не собираюсь торчать ради развлечения и менять ситуацию. Я должен быть последовательным прямо сейчас :) Были люди, которых я спрашивал, как этот человек делает программное обеспечение, и я хотел бы передать вам черты, которые я вижу в этих людях.

  1. Чтение и понимание кода

Нет, я не преувеличиваю! Некоторым программистам тяжело читать код или 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. Будьте активны

Не все в команде берут на себя ответственность. Если информация распределяется непропорционально, одни будут работать больше, а другие меньше, и часто другие команды склонны перерабатывать. Это всегда нарушает баланс внутри коллектива, а когда уходит сотрудник, который берет на себя ответственность, это ослабляет силу коллектива. В команде, где все активны, баланс сил распределяется поровну и команда развивается вместе.

Береги себя:)