Что входит, должно выходить. А с точки зрения компьютерной программы вводимые данные должны возвращать ожидаемый результат. То, как написана программа, не имеет никакого значения для пользователя. Но то, что они ожидают увидеть при взаимодействии с ним, действительно есть. Как я программист, я понимаю эту точку зрения, и со временем я стал гораздо больше соглашаться с тем, что чистая кодовая база не так важна, как конечный результат.

Очевидно, что как разработчики мы тратим много времени на то, чтобы поддерживать чистоту нашей кодовой базы. Мы реализуем шаблоны проектирования, используем наши лучшие практики ООП, обсуждаем и реализуем архитектуру и т.д.

Но времена меняются, и ожидания быстрой доставки от наших клиентов становятся все более очевидными, я лично в наши дни обращаю меньше внимания на внутреннюю работу кода и стараюсь всегда уделять внимание следующему:

Разработка через тестирование. Обеспечиваем ли мы то, что мы создаем, соответствует ожидаемым требованиям? Мы должны гарантировать, что покрываем нашу систему регулярными автоматическими тестами, уделяя особое внимание различным типам тестов в зависимости от того, что мы создаем.

Расширяемость. Можно ли быстро расширить программу, чтобы она могла выполнять больше функций, чем то, что она уже делает? Иногда чрезмерное проектирование или чрезмерная архитектура систем могут стоить расширяемости. То же можно сказать и об игнорировании архитектуры или инженерии в целом. Необходим баланс в зависимости от вашего программного обеспечения. Это постоянная борьба.

Автоматическая доставка. Можем ли мы быстро внедрить изменения в нашу систему? И делаем ли мы это с возможностью отката, если что-то пойдет не так?

Измерение и обратная связь. Измеряем ли мы, насколько хорошо работает наша система? Отслеживаем ли мы, что делают наши пользователи? Аналитика важна. С его помощью мы можем принимать решения о том, как улучшить систему.

Управление ошибками. Правильно ли мы обрабатываем непредвиденные ошибки? Правильно ли мы обрабатываем ожидаемые ошибки? Возвращаются ли правильные типы ошибок и сообщения об ошибках? И можем ли мы надежно отслеживать эти проблемы (например, файлы журналов, информационные панели и т. Д.)?

Производительность. Оптимизирован ли код, который мы пишем, для повышения производительности? В противном случае нам нужно рассмотреть альтернативные пути, чтобы улучшить то, что мы написали. Нагрузочные тесты и тому подобное могут помочь выявить любые проблемы с производительностью.

Масштабируемость, отказоустойчивость и надежность. Может ли ваша система надежно масштабироваться при большой нагрузке? Также может ли ваша система быстро и надежно восстановиться, если что-то пойдет не так? Мы хотим убедиться, что наша система не выйдет из строя, и если это произойдет, то она не отключится надолго.

Это не исчерпывающий список вещей, которые нам, разработчикам, следует учитывать, но я считаю, что это самая важная из вещей, которые мы действительно рассматриваем. С некоторыми из этих проблем я столкнусь в одиночку, а с другими - вместе с моей командой. Но независимо от того, кто этим занимается, я лично знаю, что не буду чувствовать себя комфортно с состоянием программного обеспечения, если мы хотя бы не сосредоточимся на этих областях.

Заметили, что я не включил в список читаемый код или обслуживание кода? Если бы вы спросили большинство разработчиков, они бы поместили это в свою тройку самых важных вещей. Я знаю, что раньше, конечно, был. Но когда я начал думать больше как деловой человек, а не только как разработчик, я пришел к выводу, что только мы, разработчики, заботимся о поддержке кода и удобочитаемости. Это должно доставить нам удовольствие и облегчить нашу работу.

Позвольте мне пояснить. Иметь читаемый и поддерживаемый код, безусловно, идеально. Я не собираюсь в этом сомневаться. Фактически, я действительно рекомендую потратить время во время итерации спринта на рефакторинг некоторой части вашего кода, чтобы уменьшить сложность там, где это необходимо. Даже если на это потрачено всего полдня. Но тратить время на попытки постоянно улучшать качество кода во время разработки снижает пропускную способность. Пока мы решаем перечисленные выше проблемы, для меня этого достаточно.

Теперь убедитесь, что если вы видите что-то не совсем правильное и это легко изменить, продолжайте. В противном случае отпустите это сейчас, отметьте это как что-то, что может быть реорганизовано позже, и двигайтесь дальше. Давайте продолжим эти функции. Решив все наши основные проблемы, мы всегда можем вернуться позже и провести рефакторинг.

Еще одна вещь, которую я хочу сказать о сопровождении кода, касается политкорректности, и это может беспокоить некоторых читателей, но меня это не волнует. Я считаю, что соблюдение правил руководства по стилю контрпродуктивно. Споры о том, следует ли людям использовать пробелы или табуляции, или если вы ставите подчеркивание перед частной переменной и т. Д., - это полная чушь. Мы больше не пишем в текстовых редакторах. Мы все по большей части используем IDE, и в них встроен intellisense. В наши дни мы можем довольно быстро увидеть, что является частным или публичным, что статическим, а что не статическим, что такое класс, а не класс и т.д. Это не значит, что мы берем код на принтере и читаем его на бумаге. Поэтому, пока вы понимаете, чего пытается достичь код, оставьте это в покое. Отбрось это проклятое эго. Перестаньте ожидать, что все будут работать так, как вы. Каждый кодирует по-своему и всегда будет кодировать. Простое «вы подумали об этом» - это нормально, но навязывать свои концепции и практики другим не нужно. Некоторое время назад мне пришлось смириться с этим, и другим пора тоже. Если это сработало, они сделали свое дело, независимо от того, нравится вам, как они это сделали.

Имея это в виду, некоторые из вас могут сказать мне, что я также не должен заботиться о проверках кода. Это неправда, просто я думаю о них иначе. Для меня рецензирование кода должно быть связано с тем, что рецензент оценивает вероятность того, что конкретный запрос на вытягивание может не достичь поставленной цели на основе того, что написано. Или что это может негативно повлиять на другие функции приложения. Если есть сомнения по поводу того, как код должен работать при определенных обстоятельствах (возможно, обработка ошибок неправильная, нули не были проверены и т. Д.), У нас есть возможность обсудить это с человеком, который его создал, выслушать их, и, если вы все еще видите проблема с ним, вы можете довести это до их сведения. Если вы лично не уверены в том, как что-то должно работать, то также можно провести групповое обсуждение, чтобы решить, что следует делать. Проверки кода также дают нам время оценить, будут ли соблюдены упомянутые выше пункты после этого изменения.

Для меня обзор кода не значит указывать на глупые вещи, такие как правильное именование переменных и т. Д. (Если только имя переменной не сбивает читателя с толку, зачем это нужно). Руководство по стилю Нацисты раздражают, и по большей части, когда дело доходит до этой темы, у всех другое мнение, поэтому давайте не будем беспокоиться о таких вещах.

Суть в том, что я согласен с тем, что идеально, если у нас есть легко поддерживаемый код, иногда лучше просто оставить код в покое и продолжить работу. В конце концов, общая цель - предоставить программное обеспечение как можно быстрее и больше сосредоточиться на поддержании его работоспособности, а не на том, как оно было создано. И я считаю, что сосредоточение внимания на проблемах, о которых я упомянул выше, намного важнее общей структуры нашего кода.