С тех пор, как люди вышли из своих пещер, мы как единое целое расширяли наши возможности, создавая инструменты. Подобно ребенку на подставке или ходулях, мы расширяем нашу досягаемость с каждым добавляемым инструментом и каждым процессом, который мы автоматизируем.
Программирование - относительно молодая область знаний, которая (слишком) быстро растет. Чрезвычайный спрос на программистов заставляет даже неопытных программистов находить хорошо оплачиваемую работу с множеством возможностей. Золотой век, если хотите.
Проблема, которая начинает расти при избытке рабочих мест и нехватке опытных сотрудников, - это непонимание. Когда вы пытаетесь делать ее правильно или пытаетесь найти правильное решение, в первую очередь важно тщательно понять свою работу. А когда ваша работа заключается в решении проблем и автоматизации задач, потенциальный риск небольшой ошибки может быть большим.
Количество времени и усилий, вложенных в обучение и постоянный рост сотрудников, - вот что ограничивает компании. Особенно европейские.
Почему важно качество
Создание программного обеспечения похоже на строительство дома. Каждая часть программного обеспечения построена на основе набора материалов. Основа и используемые материалы - это язык программирования и библиотеки. Хороший фундамент имеет решающее значение при строительстве дома, как и в случае с программным обеспечением. Подобно зданиям, программное обеспечение имеет архитектуру, без которой ваш дом с большей вероятностью рухнет, если вы попытаетесь изменить структуру.
Если ваше программное обеспечение рухнет, это может быть не буквальный или единичный момент выхода из строя, в отличие от здания. Это также может нанести вред вашему авторитету и / или репутации. Следует учитывать финансовый риск между потенциальным крахом или новой особенностью. Это постоянная битва между вашим бюджетом и качеством. Тот, который продолжается во всем мире в каждой отрасли.
Хороший пример, который я довольно часто перерабатываю, - это стоимость доли миллисекунды. Если у вас есть строка кода, выполнение которой занимает примерно 0,01 миллисекунды, влияние кажется невероятно небольшим. Если вы запустите эту строку кода 100 раз при отправке сообщения чата, воздействие составит 10 миллисекунд, что все еще невероятно мало.
Если ваш чат обслуживает пару тысяч пользователей одновременно, это означает, что этот единственный процесс может обрабатывать только 100 сообщений чата в секунду, не считая всей остальной работы, которую необходимо выполнить. Если предположить, что остальная рабочая нагрузка составляет еще 1 миллисекунду, получается 90 сообщений чата в секунду.
Предположим, мы расширяем функциональность чата и заставляем одну строку кода занимать всего 0,005 миллисекунды, что в 2 раза быстрее. Воздействие теперь снижено до 5 миллисекунд на сообщение чата, увеличивая количество сообщений чата в секунду до 166. Таким образом, изменив одну строку кода, мы сэкономили 50% оборудования и увеличили скорость отклика нашего приложения как минимум на 50. %, огромная победа.
Многие разработчики не обнаружили или не поняли причину оптимизации и будут действовать соответственно. Это не их вина как личности, но может вызвать большие проблемы. Разработка программного обеспечения полна таких небольших сценариев, которые будут появляться или исчезать время от времени. Чаще всего это начинает происходить, когда компания растет.
