Золотое правило программной инженерии
TL:DR
Золотое правило: Независимо от того, какой вопрос, ответ почти всегда может начинаться с «Это зависит…»
Программное обеспечение не так точно, как вы могли бы подумать. Мы пишем программы для других людей, а не для компьютеров. Написание программного обеспечения для разных людей приводит к разным ответам на одни и те же вопросы. Нам нужно сделать шаг назад и рассмотреть контекст, в котором задается вопрос, прежде чем принять решение и выбрать решение.
Золотое правило программной инженерии
Уже упоминалось в TL: DR, но его нужно повторить: Независимо от того, какой вопрос, ответ почти всегда может начинаться с «Это зависит…»
- Как следует реализовать эту функцию? Это зависит…
- Как следует тестировать эту функциональность? Это зависит…
- Какой язык / фреймворк следует использовать для этого фрагмента кода? Это зависит…
- Какая архитектура лучше всего подойдет для этого приложения? Это зависит…
- Как быстро будет работать этот фрагмент кода? Это зависит…
Это великолепно неточно
Это может вызвать у некоторых людей некоторый дискомфорт, если ваша точка зрения относится к программному обеспечению, являющемуся очень точной областью.
Золотое правило гласит, что нет ничего определенного. У каждого вопроса есть варианты, плюсы и минусы, разные результаты, которые следует учитывать.
Это может быть странно, поскольку, как известно, компьютеры делают в точности то, что вы им приказываете.
Так почему же ответ на любой вопрос в программном обеспечении такой нечеткий?
Программное обеспечение - это больше о людях, чем о компьютерах
Мы пишем программы для других людей, а не для компьютеров.
Если бы писать для компьютеров было единственной заботой, мы могли бы остановиться на сборке.
Мы этого не сделали.
Мы хотели быть более продуктивными как отдельные писатели, писать для себя в будущем. Мы хотели упростить совместную работу над одним и тем же кодом. Мы разработали всевозможные способы передачи идей и шаблонов друг другу.
Когда мы пишем код, основным читателем является другой человек.
Читатель может быть первоначальным автором этого фрагмента кода 2 года спустя, в 23:00 дождливого вторника, чашка кофе медленно превращается из прохладной в холодную, когда они проклинают автора себе под нос за то, что он написал что-то настолько непонятное.
Читатель может быть увлеченным, впечатлительным, новым инженером. Только что попал в большой офис из стекла и стали, ел бесплатное шоколадное печенье, не понимая, что лучше, а что нет, просто пытаясь получить что-то, что наконец-то работает.
Читатель может быть опытным старшим, сидящим в очень удобном кресле, в наушниках с шумоподавлением, просматривающим исходный авторский код, выбирая методы и шаблоны, которые мы намеренно оставили для расширения, например, след из панировочных сухарей, подарок товарищу. человек из прошлого.
Код запускается на компьютерах, но часто после того, как он был скомпилирован во что-то, что компьютер действительно может прочитать. В большинстве случаев код, который мы пишем, предназначен для чтения другими людьми.
Поскольку программное обеспечение написано для людей, ответ на любой вопрос может начинаться со слов «Это зависит…». Люди разнообразны, и, как следствие, разнообразно программное обеспечение. Есть много разных способов делать что-то, некоторые лучше или хуже в зависимости от ситуации.
Контекст - это все
Контекст, в котором написано программное обеспечение, имеет огромное значение для того, как это программное обеспечение должно быть написано. Одно и то же приложение может быть написано разными способами в зависимости от контекста.
Контекст - это другие люди, которые будут читать код, который мы пишем.
Это проект одного человека? Стартап, ориентированный на технологии? Корпоративный гигант? Каждая из этих ситуаций дает разные ответы на один и тот же вопрос.
Проект одного человека, вероятно, будет меньше заботиться о строгих стандартах кодирования и документации, он написан одним человеком, у него есть весь контекст.
Технологически ориентированный стартап, вероятно, сосредоточится на технологиях, которые позволяют им выполнять итерации и экспериментировать как можно быстрее, это не имеет большого значения, если это не самый масштабируемый код, если они не могут выполнить итерацию, они умрут. задолго до того, как необходимость масштабирования станет проблемой.
У корпоративного гиганта уже было принято множество решений по технологиям, и теперь нужно постоянно поддерживать все в движении. Представить новую блестящую структуру не получится, потому что она требует обучения всей компании.
Сложность здесь в том, что контекст меняется, решения, принятые в рамках проекта одного человека, становятся проблемами в стартапе. Углы, которые были сокращены при запуске, никогда не приклеиваются к корпоративному гиганту.
Ответ на какой-то вопрос в контексте проекта одного человека, вероятно, будет отличаться от ответа на тот же вопрос в контексте корпоративного гиганта.
Все это зависит.
Решай сам
В некотором смысле было бы здорово, если бы на все вопросы по программному обеспечению был дан определенный набор ответов. Это устранит необходимость в принятии решений, что, вероятно, сократит количество недоразумений. Если все пишут одни и те же вещи одинаково, легче предугадать, как это будет выглядеть.
Другими словами, это значительно усложнило бы жизнь, не все проблемы одинаковы, решение, которое сработало в одном месте, может не сработать в другом. Если бы мы были в каком-то полностью однородном мире, большая часть возможностей приспособить конкретный инструмент к конкретной ситуации была бы потеряна.
Мы не можем просто оставить ответ на вопрос «Это зависит от обстоятельств» и уйти, чувствуя себя самодовольным. Мы должны сопровождать это заявление сбалансированным взглядом, в котором излагаются возможности. Затем примите какое-то решение относительно того, какая возможность наиболее подходит для нашего контекста.
Могут быть ответы, которые в большинстве случаев являются правильными, и выбор этого ответа не должен быть по умолчанию, но, вероятно, это будет тот, к которому мы придем после некоторого размышления.
Возьмем, к примеру, выбор фреймворка для проекта. Легко следовать за толпой, присоединяться к групповому мышлению, использовать то, что считается наиболее популярным фреймворком для вашего типа проекта.
Скажем, выберем что-то вроде использования React для внешнего интерфейса.
Я не говорю, что вам не следует выбирать React для внешнего интерфейса. Я говорю, что вам следует выбирать React только в том случае, если вы рассмотрели сбалансированный взгляд на возможности и попали в React. Здесь могут быть рассмотрены следующие типы вещей:
- Я знаю React?
- У меня есть время изучить React?
- Есть ли другие люди в этом проекте?
- Знают ли они или хотят изучить React?
- Каковы сроки реализации этого проекта?
- Является ли React подходящим решением проблемы, которую пытается решить этот интерфейсный проект?
- Какие есть альтернативы?
- Что я предпочитаю?
Ответ на вопрос «Какой фреймворк мне использовать для своего внешнего проекта?» можно и нужно начинать со слов «Это зависит…». Он не должен начинаться и заканчиваться на «React», потому что он воспринимается как стандартная вещь для написания проектов внешнего интерфейса.
Я должен отметить, что мне нравится писать React, я считаю, что это полезный инструмент, но его следует использовать там, где это уместно.
Метод взвешивания вариантов с учетом контекста и принятия решения применим не только к выбору фреймворков, он применим практически ко всему в программном обеспечении. Вопросы вроде:
- Стоит ли писать микросервисы?
- Какой фреймворк мы должны использовать?
- Какой язык мы должны использовать?
- Как мы представим эту концепцию в коде?
- Какие стандарты кодирования мы должны принять (если есть)?
- Где должен жить этот кусок кода?
- Как мы проверяем эту функциональность?
- Какую базу данных мы должны использовать?
- Что мы должны использовать: NoSQL или SQL?
- Что нам следует использовать: хореографию или оркестровку?
- Как разместить наш код?
И многое другое…
Каждый из ответов на эти вопросы должен начинаться с «Это зависит…» и заканчиваться с учетом контекста и людей, на которых будет влиять ответ, а затем - решение.
Можно использовать популярный ответ по умолчанию.
Это не единственный ответ.
Резюме
Золотое правило: Независимо от того, какой вопрос, ответ почти всегда может начинаться с «Это зависит…»
Происходит из нескольких функций программного обеспечения:
- Мы пишем программное обеспечение для других людей, а не для компьютеров
- Контекст, в котором написано программное обеспечение, имеет огромное значение для ответа на вопрос.
- Нам нужно принять взвешенный взгляд, рассмотреть возможности, а затем принять решение о том, какой ответ на вопрос является наиболее подходящим, вместо того, чтобы отвечать тем, что является ответом по умолчанию.
Об авторе
Привет, меня зовут Дугал, я технический руководитель, который много лет изучал разработку программного обеспечения у нескольких очень талантливых людей. Когда я начал наставлять инженеров, я обнаружил, что есть много знаний, которые я считал само собой разумеющимся, и которые, я думаю, должны быть переданы. Эти истории - мой способ заплатить вперед.
