Мой код никого не интересует. Я был шокирован, когда понял это, работая программистом.
Я потратил много времени на совершенствование своего кода, пока не понял, что он никому не интересен, потому что важен не сам код, а продукт. Принятие программистом этого факта приведет к увеличению производительности и ценности его работы.
Код — это инструмент
Написание кода Нет это работа программиста.И это предполагает создание приложения для решения определенных задач.
Да, код — это основной инструмент, который для этого используется, но это всё равно всего лишь инструмент. Точно так же, как работа плотника заключается не в использовании молотка или пилы, а в том, чтобы что-то сделать с помощью этих инструментов.
Однако некоторые действия могут привести к ошибочному мнению, что код — это продукт. Например, рефакторинг: что мы с его помощью улучшаем: код или продукт? Если ответ — код, ни один менеджер не даст вам времени на это занятие.
Но стоит объяснить, что это может исправить существующие ошибки или помочь внедрить новую функцию, и вдруг на это появится время.
Заявка сначала оценивается в целом.
Об этом следует помнить при написании каждой строки кода.
Если продукт непривлекательный, дальше ничего обсуждать просто нет смысла.
Даже если все инструменты используются идеально, работа будет провалена, если изделие получится некачественным.
Это не означает, что код бесполезен и не должен рассматриваться в контексте требований к продукту.
Обеспечение безопасности и отказоустойчивости требует навыков и использования правильных библиотек.
Здесь код должен выполнять свою работу, остальное не должно выделяться.
Чем быстрее рецензент проработает такой код, тем больше он будет удовлетворен.
Идея «Код — это инструмент» объясняет, почему важно знание нескольких языков и фреймворков; причина пользы знаний математики и теории сложности, но отсутствие необходимости в таких знаниях; причина, по которой среда разработки может быть одновременно прекрасной находкой и худшей ловушкой.
Все это — мера гибкости программиста, которая напрямую зависит от разнообразия его инструментов.
Сосредоточьтесь на производительности
Возьмем, к примеру, встречу с премьер-министром или заказчиком.Что ты ему скажешь? Сколько строк кода написано, сколько классов создано, как работают скрипты, как обрабатываются исключения и как структурирована база данных? К сожалению, зачастую ответ на все эти вопросы звучит так: «Да, я ему так и скажу».
Вы видели его лицо в тот момент? Ему скучно.
Ему следует быстро перейти к следующим пунктам.
Эти детали не имеют для него ни малейшего значения.
Дело не в том, что он не понимает, о чем мы говорим, ему просто все равно.
Представьте, что дизайнер начинает рассказывать вам о том, какие слои он использовал в Фотошопе, сколько у него там объектов, какие градиенты и на каких кистях он использовал и какие крутые анимационные скрипты он написал.
Вас это не интересует. Вам интересно, можете ли вы уже забрать фотографии? Вам нужно общаться на уровне состояний готовности: импорт готов, но не хватает поддержки того-то; Приложение работает на большинстве телефонов, но на этом все равно лагает; Клиентское приложение уже запущено, но функциональность пока оставляет желать лучшего.
Это то, что важно для менеджера или клиента.
Именно это приносит ему информацию, полезную в контексте планирования дальнейших действий.
Ваша библиотека ничего не стоит
Я часто вижу в Интернете вопросы, связанные с защитой исходного кода.Программист пишет код для заказчика и использует для этого свою личную библиотеку.
И вот, клиент требует исходный код всего проекта, а программист думает: он не хочет отдавать ценный код своей библиотеки.
Для начала давайте подумаем, зачем клиенту вообще может понадобиться исходный код. Возможно, чтобы гарантировать, что разработка сможет продолжиться, даже если программист внезапно исчезнет. Возможно проведение аудита безопасности или соответствия лицензии.
Сам код ему не нужен, он опять же просто играет роль инструмента для выполнения какой-то другой задачи.
И хотя личная библиотека может быть ценным активом, сама по себе она не является ценностью.
Это будет важно только для вас, так как позволяет работать быстрее.
На самом деле это может быть самая важная часть вашего бизнеса, но другой программист может отбросить ее за ненадобностью.
Но что, если библиотека действительно ценна? Если действительно есть уверенность, что оно само по себе может быть продуктом.
Потом можно будет поделиться, а то и продать, может, так и получится.
Стоит только учесть, что очень немногие подобные продукты добились какого-либо успеха.
Это упражнение вообще полезно для любого программиста.
Это заставляет вас осознать, как мало других программистов волнует ваша работа.
Да хоть взять свой проект. Чем вы руководствуетесь при выборе сторонней библиотеки: какой крутой код она содержит или какие крутые вещи она умеет? Вы вообще на его код смотрите после установки?
Да, но.
Означает ли это, что вы можете писать дерьмовый код? Нет, это не значит. Для создания качественного продукта требуется мастерство.
Несмотря на то, что код никого не интересует, он по-прежнему является основным инструментом достижения цели.
И хотя перфекционизм может быть проклятием, если мы будем использовать этот инструмент неэффективно, то не выполним задачу.
Возвращаясь к аналогии со столяром, грязный молоток забьет гвоздь так же хорошо, как и полированный, а вот ржавый может легко сломаться при ударе и даже поранить вас.
Цель программиста — улучшить продукт, а не код. Для максимальной эффективности нужно исходить из того, что должен делать продукт, и понимать, какова истинная ценность результата.
Теги: #философия программирования #разработка сайтов #программирование #идеальный код
-
#002. Пройтись По Картине Мира
19 Oct, 24 -
Мучительный Вокс
19 Oct, 24 -
Привет, Мир
19 Oct, 24 -
Использование Дженериков В Swift
19 Oct, 24
