Перевод статьи Эрика Дитриха «How to Write Software: 5 Lessons Learned from Running Businesses».
Раньше я зарабатывал на жизнь написанием программ. Я занимался этим много лет, так что немало узнал о том, как нужно писать программное обеспечение.
Но узнал я это с точки зрения разработчика. Сегодня я хотел бы рассказать, как мое отношение к разработке изменилось за последние несколько лет.
Программы с точки зрения разработчика и с точки зрения собственника бизнеса
Моя карьера была довольно извилистой. Начинал я как разработчик, затем перешел в менеджмент, затем начал обучать разработчиков. После этого несколько лет работал консультантом. И, наконец, в настоящее время я, в основном, занимаюсь своим быстрорастущим бизнесом.
Все это я рассказываю для того, чтобы обозначить, чем я занимался между своей последней работой на полную ставку в роли разработчика и сегодняшним днем.
Сейчас я вернулся к написанию ПО. Но, конечно, не занимаюсь этим все свое рабочее время. Я создаю линию бизнес-приложений, которыми непосредственно пользуются четыре человека, а опосредованно – еще около 30. Так что я не зарабатываю этим на жизнь, но это и не игрушки, если учитывать важность для бизнеса и масштаб.
Снова посвятив некоторое время разработке, я задумался, как изменилась моя точка зрения на этот предмет. Не поймите меня неверно. Я никогда не прятал голову в песок, притворяясь, что бизнес не существует или не имеет значения. Но я никогда и не был бизнесменом. Мои деньги никогда не стояли на кону. А теперь ситуация изменилась.
Хочу также внести ясность: говоря об уроках, я не имею в виду нечто, что вы должны усвоить. Я лишь хочу показать, как изменилось мое восприятие вещей.
1. Я часто думаю: «Не может быть, чтобы этого не существовало!»
Не буду вдаваться в детали проекта, которым занимаюсь в данное время. Если любопытно, вот ссылка на github-репозиторий.
Посмотрев проект, вы можете сказать, что я мог бы использовать готовые коммерческие решения. Я этот вопрос изучал и отказался от подобной идеи, как из-за цены, так и из-за того, что мне нужна большая расширяемость, чем предлагалась в готовых решениях.
Так что я решил построить самостоятельно, вместо того чтобы покупать. Но это решение далось мне не легко.
И эта философия затрагивает более глубокие уровни. Когда я был разработчиком, я мог размять пальцы и сказать: «Вот черт, похоже, совершенной сетки для фронтенда нет, так что построю-ка я, пожалуй, собственную!» А сегодня я уже не так рвусь в бой.
Что бы это ни было – фреймворк, архитектурная конструкция, библиотека или что-то еще, – я думаю, что кто-то, должно быть, это уже сделал. Это ж чертов 2018 год, как эта вещь может еще не существовать?!
Я хочу тратить свое время на построение бизнес-логики и работу над теми специфичскими частями моего приложения, которые представляют особую ценность. Я не хочу писать 183663-й datepicker.
2. Я больше не думаю, что самоличное создание вещей закаляет характер
Этот пункт логически вытекает из предыдущего. Я не хочу строить еще один datepicker, потому что это напрасная трата времени, которое я мог бы потратить на другие вещи. Так что я лучше предпочту уже существующий.
И, следовательно, я также не думаю, что создание собственного datepicker-а каким-то образом сделает из меня лучшего разработчика.
Желание узнать, как все работает «под капотом», вполне закономерно. Если вы пишете веб-приложения, вы можете улучшить свои навыки, написав собственный веб-сервер. Так вы на самом деле поймете, как работает ваше веб-приложение. Пишете веб-серверы? Попробуйте написать собственную логику ядра или собственную операционную систему.
Это, конечно, крайность, но отражает идею. И я помню, что я вполне ее разделял. Построение вещей, ценность которых для бизнеса сомнительна, может не быть полезным в краткосрочной перспективе. Но это даст вам более широкие общие знания, которые вы сможете использовать в своей карьере.
Однако я не считаю, что создание datepicker-а будет полезным хоть в краткосрочной, хоть в долгосрочной перспективе. Станете вы после его создания немного лучшим специалистом общего профиля? Вполне возможно. Но почему бы не построить что-то, что действительно послужит вашей карьере, а не будет просто работой для практики?
Сейчас я бы предпочел улучшить свои навыки автоматизации и решения глубоких проблем в выбранной мной сфере деятельности. Ведь это повысит мою рыночную ценность как специалиста.
3. Не надо умозрительно абстрагировать
Давайте отойдем от темы развития навыков и изобретения велосипеда и поговорим, собственно, о проектировании ПО. В этом деле мои взгляды также сильно изменились.
Во времена, когда N-слойная архитектура была обязательной для корпоративных приложений Java, я был ее стойким приверженцем. Хотите создать игрушечное приложение для сортировки файлов на жестком диске? Ну, для начала вам нужен слой доступа к данным, затем слой бизнес-логики, слой приложения, слой представления и, конечно, разметка.
И интерфейсы. Всюду интерфейсы. Да, сегодня вы хотите только сортировать MP3-файлы на диске, но, возможно, завтра вам захочется, чтобы это были ссылки на реляционную базу данных или blobs. Если у вас будут интерфейсы для всех слоев, вы сможете поменять всю вашу модель, не трогая ничто лишнего! Захотите ли вы это делать? Какая разница! Вы сможете это сделать!
Как и все, я переметнулся от этого подхода к YAGNI («You aren’t gonna need it», «Вам это не понадобится») еще когда был наемным разработчиком, в конце 2000-х. Но я все еще занимался украшательством архитектуры. Вам нужны интерфейсы для юнит-тестирования. Вам нужна хоть какая-то слоистость.
Сегодня я уже не так этим озабочен. Мне нужно сделать тест-драйв моего кода, и если я могу это сделать, – прекрасно. Таким образом я не делаю никаких интерфейсов, пока у меня не будет нескольких реализаций. Я не делаю слоев, пока у меня нет настоящего use case для разных вещей, располагаемых независимо, сверху и снизу. Я не создаю абстракций, пока они не решают проблемы.
Поэтому я использую фреймворк Entity и работаю с контекстом прямо в моем контроллере, аж пока у меня не будет убедительной причины поступать иначе. У меня нет времени раздумывать над лучшими подходами к проектированию.
4. Технический долг может быть техническим кредитом
Вы знаете разницу между долгом и кредитом? Вариант «долги бывают у миллениалов, а кредиты — у толстосумов постарше» не проходит. Речь идет о причине, по которой вы занимаете деньги.
Если вы одалживаете у меня $20 на пиццу, которую затем съедаете, то у вас долг. Вы взяли эту пиццу и превратили ее в… ну, скажем, в нечто, не имеющее денежной ценности. Вы должны мне $20, а одолженные деньги вы использовали таким образом, что это никак не поможет вам в выплате долга.
Но допустим, что вы, одолжив у меня двадцатку, вместо пиццы купили акции. Вы все еще должны мне $20, но у вас на руках актив стоимостью в $20. Вы в любой момент можете отдать мне долг. Больше того, у вас на руках актив, который может принести вам прибыль. Эта прибыль может даже превысить проценты, которые вы заплатите мне сверху моей двадцатки. Это кредит.
Кредит это более стратегическая штука, чем долги.
Это истина как для сферы финансов, так и для вашей кодовой базы.
Когда я был моложе, я воспринимал технический долг исключительно как «непродуманный дизайн» и слабость команды. Я не различал технический долг и технический кредит.
А теперь различаю.
Недавно я использовал библиотеку, нетестируемый дизайн которой протекал в код, где она используется. Поэтому я ограничил ее использование изолированной областью на краю моей кодовой базы. Это сработало, но серия событий начала приводить бизнес-логику в эти непротестированные маленькие методы.
С этим пришлось смириться, поскольку в связи с неотложными работами нам нужно было относительно быстро произвести серию изменений. Я понимал, что мне нужно подумать насчет изолированного фреймворка или обертки для этой библиотеки. Я понимал, что без этого каждый коммит, который я сделаю, будет впоследствии поглощать больше времени.
Но некоторое время это пришлось потерпеть. А затем, когда в выходной у меня появилось свободное время, я выплатил этот долг.
Это был технический кредит. Благодаря этому техническому кредиту у меня и появилось какое-то свободное время. Я сэкономил больше времени, чем потратил, вернул долг в виде нужного кода и при этом не сорвал график доставки функционала.
5. Моя гордость за работу моего продукта не важна
И, наконец, последнее изменение в моем мышлении. Вы можете с этим не согласиться и привести расхожую фразу о том, что «если вы не стыдитесь своего продукта, значит, вы слишком затянули с доставкой». Но у меня другое мнение.
Я подхожу к этому вопросу с прагматической точки зрения, при которой «гордость за код» не имеет отношения к целям, которые мы преследуем в бизнесе.
Не поймите меня неверно. Я в некоторой степени горжусь, когда мне удается что-то быстро доставить или придумать, как компактно и читабельно сделать рефакторинг метода. И я, конечно, предпочту выпускать в продакшен нечто с шикарным UI.
Но это все соображения тщеславия, а не бизнеса. Для бизнеса моя гордость не имеет значения. Так что я не могу допускать такие мысли, как «если бы я был хорошим программистом, я бы применял вот этот, самый лучший подход, или защитил бы свой код от <вставить_нужное>» и т. п. Вместо этого я должен ограничивать все эти вещи рамками ценности для бизнеса и возврата инвестиций.
Возвращаясь к datepicker-у. Ведь корбит же, когда приходится запускать в продакшен нечто, где нет возможности сделать выбор даты и нужно вводить ее вручную? Конечно, коробит. Но можно ли пренебречь datepicker-ом, если люди, использующие приложение, говорят, что такая функция практически не сэкономила бы им никакого времени? Безусловно.
Я считаю, что путь от программиста к бизнесмену и обратно научил меня разграничивать многие вещи. В моих хобби-проектах я занимаюсь автоматизацией, оттачиваю свои навыки и делаю вещи, которыми горжусь. А в проектах, представляющих для меня коммерческий интерес, я пишу код, как экономист.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]