Разработчики очень хорошо умеют абстрагироваться:

  1. Они генерируют базовые или универсальные классы для наследования или повторного использования;
  2. Они пишут универсальные или перегруженные функции, вызываемые с аргументами, вместо автономных;
  3. Они пытаются повторно использовать код в нескольких технологиях, даже если этого трудно добиться из-за присущих им различий в платформах (например, Xamarin).

Хотя такие навыки важны в мире программирования, также очень важно, чтобы ими не злоупотребляли в коммерческом мире.

С годами я понял, что очень часто лучше просто не абстрагироваться, чем делать это. (Я знаю, что это может вызвать большую дискуссию, которая никогда не закончится или, по крайней мере, заставит некоторых моих читателей генерировать сложные комментарии, такие как… !@#$%^&*). Вот почему:

  1. Много раз мы абстрагируемся от вещей, предполагая, что клиенты будут запрашивать аналогичные новые функции в будущем, и что в этом случае нам будет легче их разрабатывать; но мы тратим много времени на первоначальную настройку, при этом нет уверенности, что в конечном итоге это принесет какую-либо пользу — клиенты непредсказуемы — и часто оказывается, что если бы мы не обобщали вещи, мы могли бы поставить — по крайней мере, первую версию продукта — раньше (иногда раньше, чем наши конкуренты!) Конечно, если потом нам действительно понадобится рефакторинг, мы могли бы попросить заказчика доплатить за него, когда бы он или она ни потребовали аналогичная функция, объясняя ему или ей о более легкой ремонтопригодности, когда не допускается дублирование кода (деньги, которые было бы трудно запросить изначально).
  2. В других случаях также задействована концепция личных ценностей, например, возникающая из-за чувства делать что-то так, как мы думаем, что это лучше: нам нравится абстрагироваться от вещей так сильно, что мы хотите сделать это независимо от его коммерческой выгоды.
  3. Хотя с технической точки зрения я заметил, что дублирование кода или отсутствие совместного использования кода для разных технологий действительно связано с некоторыми проблемами и более сложным управлением, но с этим можно жить: вам просто нужна дополнительная осторожность. и некоторые хорошие инструменты во время обслуживания. Более того, много раз заказчик(и) будут запрашивать небольшие изменения, применимые только к одному или нескольким «дублированным» случаям, и если бы мы сделали это со слишком большой абстракцией, потребовалось бы передать так много цепочек аргументов по внутренние маршруты кода для получения предполагаемого поведения, которое мы бы сказали нашему клиенту, что это невозможно сделать — просто сохранить код читабельным (а он или она наверняка не поверит и не поймет нас!)
  4. Наконец, обратите внимание, что иногда вы просто не можете делиться кодом, например, если вы разрабатываете приложения или компоненты мультиплатформенным + нативным способом, например. если вы разрабатываете для Windows, используя C#/C++ и UWP/WPF, для Android, используя Java/Kotlin, для iOS, используя Swift/Objective C, и для Интернета, используя TypeScript/JavaScript и такую ​​​​инфраструктуру, как Angular (и, возможно, позже также для голографических компьютеров используя Unity 3D и его подмножество C#): современные языки программирования разделяют — в своей основе — более или менее одни и те же концепции, но они требуют разного синтаксиса, и максимум, что вы можете повторно использовать, — это логический дизайн приложения и несколько общих взглядов. и поддерживаемые типы ввода (по крайней мере, для пользовательского интерфейса вы можете легко себе представить, что поддержка как 2D, так и 3D, или жестов мыши, касания и воздуха вместе будет очень, очень «дорогой».) для некоторых целей, таких как решение использовать C# и Xamarin, чтобы ваше приложение с единой кодовой базой с легкостью работало на устройствах UWP, Android и iOS (хотя это само по себе может привести к другим проблемам, когда возникнут крайние случаи), вы, вероятно, все равно будете нужен другой язык программирования f или Интернет, а позже, возможно, что-то совершенно другое для правильной поддержки 3D-голограмм.

В заключение: не делайте все возможное и меньше беспокойтесь: это мой совет сегодня, и я бы дал его и себе, если бы мог вернуться в прошлое на десять или два десятилетия!

Однако это не означает, что вы никогда не должны абстрагироваться или реорганизовывать свой код. Наоборот, это означает, что вы должны делать это правильно: анализировать возможности любой возможной абстракции, прежде чем применять ее на практике!

Первоначально опубликовано на WordPress 10 августа 2017 г.