Как улучшить свой стиль программирования?
Я — разработчик. От своих работодателей я постоянно слышу, что работаю медленно и часто всё усложняю без веской причины. И что мне пора бы что-то с этим сделать. Во избежание.
Весь мой опыт программирования складывается из университетских работ и пары лет пребывания в различных компаниях. Критикующие меня люди неоднократно говорили мне, что в целом я разбираюсь в теме, так что я далеко не клинический случай, как можно было подумать. Однако, очевидно, я выработал совсем не те программистские привычки (как минимум, на взгляд работодателя) и мне нужно срочно изменить их. Везде, где бы я ни работал, мои решения, использующие иерархии мелких классов с делегированием поведения, признавались плохими. Говорят, будто так и надо писать, но это не так. Потому что всё это «как надо» может стоить мне работы.
Я начал читать книги. В них я видел все то же самое, от чего пытался убежать. Например: для одной разовой работы я воспользовался похожим кодом из другого проекта, для чего привел его к общему интерфейсу. Мой коллега, разбирая ошибку, наткнулся на этот код и спросил меня зачем я сделал всё так сложно для одноразовой-то работы. Но для меня это не одноразовая работа! Оба проекта очень похожи и тот же самый абстрактный код можно было бы использовать еще в нескольких.
Замечу, что люди, которые меня критиковали, всегда были значительно опытнее меня. Поэтому здесь два варианта: либо что-то не так со всеми опытными разработчиками, либо что-то не так со мной.
Человек, оставив это сообщение на одном из популярных англоязычных ресурсов, попросил о помощи. Признание проблемы — половина решения. Человек искренне не понимает, чего от него хотят и всей душой желает исправиться.
Решения мирового сообщества разделились на четыре группы:
1.«Забить», т.к. опытные программисты — просто дураки. И если они долго проработали, это еще не значит, что они опытны (много голосов).
2. Спросить у критиков, как бы они структурировали код (столько же голосов).
3. Напроситься программировать в пару / сходить на курсы (немного голосов).
4. «Ну так пиши проще!» — нет никакой гарантии, что требования к новым проектам хорошо лягут на заботливо разработанный интерфейс (1 голос).
Все эти советы не выходят из области, в которой сформулирован вопрос, и потому не могут решить главную проблему — «Так что мне сделать, чтобы улучшить свой стиль программирования?» Пункт 4 подбирается ближе всех, но всё же далек. Проблема глубже.
Что делать?
Ролевые игры. Часть 1
Вы и ваш двойник открыли бизнес по автоматизации чего-нибудь. Конкретно вы из вас двоих — директор.
Какая у вашего двойника часовая ставка? Возьмите калькулятор и поделите число, указанное в трудовом договоре на 160. Если вы совершаете эти действия в рабочее время, то поделите результат еще на 60. Вот на столько (+20% льготной ставки в ПФР + 0.2% за травматизм + 6% УСН (половину можно зачесть из налогов ПФР) = +23.2% минимум) вы нагрели своего работодателя, развлекаясь здесь со мной. Знаете, как выглядит миллион рублей? Вспомните объем (и, особенно, качество) написанного вами за последний год — вот это и есть миллион. Стоит покупать ваш труд? Вы, уже как директор, купили бы?
Рано или поздно вы подойдете к другому себе с простым вопросом «Когда будет готово?», с рациональным предложением «Работай быстрее» (потому что ты дорого мне обходишься) и с мудрым советом «Делай проще». Вас от души забавляют объяснения двойника, почему сроки затягиваются, потому что до того как стать директором, вы сами «отмазывались» точно так же и знаете, что за этим стоит.
Теперь ваш двойник оказался в той же ситуации, как и человек из первой исповеди. Вопрос в том, признает ли себя ваше второе я частью проблемы или спишет всё на начальника и прочие внешние обстоятельства.
А теперь, внимание, большой секрет. Для, вас, как директора, он уже никакой не секрет, а очевидная мысль — вам не нужны программисты. Вам надо решить проблему. Может, стоило заказать программу в другом месте или купить готовый модуль или вообще ничего не автоматизировать, а нанять людей на низкую зарплату. На текущий момент вы уже потратили 600 тыс. и не получили никакого пригодного результата.
Большой Секрет Еще Раз: программисты никому не нужны. И программы тоже. То есть совсем. Людям интересны они сами, их проблемы и некоторые другие люди. Просто так получилось, что часть проблем можно решить написанием кода. Если бы те же проблемы решались струганием деревянных дощечек и покраской их в зеленый цвет, и это было бы дешевле — так бы и делали.
Если из всей статьи вы готовы запомнить лишь одну мысль, то запомните эту: Программирование не самоценно, а программисты — обслуживающий персонал.
Эта мысль может вас задеть — всё нормально. Чем раньше вы примете её, тем более ценным специалистом вы сможете стать. В нашей культуре считается, что лучше быть господином, нежели слугой. Но если подумать, то общество и вы находитесь в некоторых отношениях. В этих отношениях вы можете занять роль «добровольного слуги» и общество (в лице работодателя и довольных клиентов) щедро вознаградит вас за вашу заботу.
Ролевые игры. Часть 2
Зайдем с другой стороны: ваш двойник — директор, а вы — разработчик.
К вам вот-вот заглянет директор, а фабрика абстрактных автоматизаторов еще не дописана, SQL-запросы не отлажены да и вообще за полгода пришло понимание, что всё должно быть не так.
Дилемма: никто не хочет работать тяп-ляп. Все хотят гордиться своей работой. Следовательно: (логическая ловушка) Да, я делаю медленно, зато правильно.
Если с «медленно» всё ясно, то что такое «правильно» — совсем не очевидно. На самом деле всё просто. «Правильно» — это когда за отведенный срок (±) появляется пригодная к использованию программа или сервис. Если ваше другое понятие «правильно» не приводит к появлению пригодного к использованию продукта за разумный срок, то ваше «правильно» никуда не годится. Тут нет простора для маневра. Вспомните, что программирование не самоценно.
Работа занимает всё отведенное на неё время. Если разработчику дать в три раза больше времени, он не напишет в три раза лучше. Он напишет в три раза больше кода того же качества, которое обычно выдает. Поэтому, всеми силами старайтесь получить нечто рабочее. Любой ценой. Ваша цель — работающая программа, неважно как написанная. Есть много т.н. называемых «грязных проблем» — это такие проблемы, которые непонятно как решать, пока не попробуешь решить. Пример: краш-тест машин. «Грязные» проблемы всплывут во время первого прохода и их можно будет учесть во время чистовой работы. Желательно, чужими руками.
Второй Большой Секрет: код — это всегда плохо. «Красивого» кода не бывает. Чем меньше кода, тем лучше. Любой код содержит ошибки, компромиссы и проблемы производительности.
- Меньше классов, меньше функций, меньше кнопок, меньше связей и вообще — меньше.
- Не пишите обобщенную функцию, если её функционал не встретился минимум три раза в разных местах.
- Не пишите функции и методы класса до того, как у них появится пользователь. Т.е. сперва где-то появился вызов метода и только потом появился сам метод.
- Вам не нужно три уровня наследования с шаблонным классом посередине.
- Стандартный модуль вполне способен решить вашу задачу — почитайте еще раз документацию.
- SQL — не единственное в мире хранилище. Очень много всего можно запросто хранить прямо в файлах в JSON.
- Не думайте о системе «на вырост». Другие требования — другая система. Не пытаться строить в деревне небоскреб — это и есть архитектура
- Этот алгоритм O(n^2) можно не оптимизировать до O(n logn), потому что в данном месте n никогда не больше 5, поскольку означает число задействованных пальцев на руке.
- Вместо написания генератора таблицы её можно один раз сверстать в HTML — она незначительно меняется раз в полгода.
- SVN — отличная система контроля версий. Особенно, когда вместе с вами её используют непрограммисты, работающие с вами над одним проектом.
- Вам действительно нужно попиксельное освещение для визуализации мат.модели или стандартного GL_SMOOTH хватит? И, кстати, мы будем показывать её на выставке на 7-летнем ноутбуке со встроенной графикой.
- Правда думаете, что цикл на итераторах работает быстрее, чем на индексах, особенно если сравнить первый и второй со временем доступа к диску?
- Похожие классы в двух проектах — не повод связать один с другим. Считайте это случайным совпадением. Если вы сделаете общий класс, то отныне, при любом изменении, вам придется думать о двух проектах одновременно. Стоит ли это того? Вряд ли.
- Доска с маркером + телефон с камерой отлично заменяют UML-диаграммы и большую часть программ прототипирования интерфейсов
Программист, принимающий во внимание коммерческие следствия своих решений, ценится на вес золота. Стив Макконел.
Исповедь 2
Всем привет. Я — руководитель группы разработки. От своих разработчиков я постоянно слышу, что они не успевают. Я понимаю, что мои разработчики могли бы работать быстрее (и даже заметно быстрее), если бы не усложняли всё без веской причины и почаще заглядывали бы в документацию. И мне пора бы что-то с этим сделать. Во избежание.
Весь мой опыт программирования складывается из школьных «проб пера», олимпиад, университетских работ, дополнительного образования, преподавательской деятельности, домашних проектов и 8 лет успешной работы в мелких, средних и крупных компаниях. В целом, я разбираюсь в теме. Очевидно, я выработал «те» программистcкие привычки (как минимум, на взгляд работодателя) и считаю нужным поделиться ими. Везде, где бы я ни работал, мои решения никогда не страдали манией «переиспользования». Говорят, будто так писать не хорошо, но это не так. Потому что всё это «как надо» может стоить работы не только мне.
Я читал книги и продолжаю читать. В книгах есть всё. Я пишу код почти каждый день (включая выходные: мне нравится писать код) и почти каждый день читаю документацию. У меня всё получилось далеко не сразу. Но я точно знаю, что терпение — самый короткий путь. Я никуда не спешу, потому что быстро — это медленно, но каждый день. Я отвязан от языка, парадигм, технологий и всего остального технофетиша. Мне просто нравится делать полезные программы для людей. Решать проблемы.
Замечу, что люди на похожих позициях (и самые продуктивные разработчики), придерживаются схожих мыслей. Поэтому здесь два варианта: либо что-то не так со всеми опытными разработчиками, либо что-то не так с…
P.S.
Третий секрет. Начните писать в commit’ах пользовательскую ценность добавленного кода. Не «добавил два метода», а «Теперь пользователю быстрее/легче/меньше. » или «появилась функция / изменилась реакция». Вам нечего написать? Вы ничего не сделали за день.