воскресенье, 11 января 2015 г.

Ссылка. Как улучшить свой стиль программирования?

http://habrahabr.ru/post/230637/

Процитирую:

"
Ролевые игры. Часть 1

Вы и ваш двойник открыли бизнес по автоматизации чего-нибудь. Конкретно вы из вас двоих — директор.

Какая у вашего двойника часовая ставка? Возьмите калькулятор и поделите число, указанное в трудовом договоре на 160. Если вы совершаете эти действия в рабочее время, то поделите результат еще на 60. Вот на столько (+20% льготной ставки в ПФР + 0.2% за травматизм + 6% УСН (половину можно зачесть из налогов ПФР) = +23.2% минимум) вы нагрели своего работодателя, развлекаясь здесь со мной. Знаете, как выглядит миллион рублей? Вспомните объем (и, особенно, качество) написанного вами за последний год — вот это и есть миллион. Стоит покупать ваш труд? Вы, уже как директор, купили бы?

Рано или поздно вы подойдете к другому себе с простым вопросом «Когда будет готово?», с рациональным предложением «Работай быстрее» (потому что ты дорого мне обходишься) и с мудрым советом «Делай проще». Вас от души забавляют объяснения двойника, почему сроки затягиваются, потому что до того как стать директором, вы сами «отмазывались» точно так же и знаете, что за этим стоит.

Теперь ваш двойник оказался в той же ситуации, как и человек из первой исповеди. Вопрос в том, признает ли себя ваше второе я частью проблемы или спишет всё на начальника и прочие внешние обстоятельства.

А теперь, внимание, большой секрет. Для, вас, как директора, он уже никакой не секрет, а очевидная мысль — вам не нужны программисты. Вам надо решить проблему. Может, стоило заказать программу в другом месте или купить готовый модуль или вообще ничего не автоматизировать, а нанять людей на низкую зарплату. На текущий момент вы уже потратили 600 тыс. и не получили никакого пригодного результата.

Большой Секрет Еще Раз: программисты никому не нужны. И программы тоже. То есть совсем. Людям интересны они сами, их проблемы и некоторые другие люди. Просто так получилось, что часть проблем можно решить написанием кода. Если бы те же проблемы решались струганием деревянных дощечек и покраской их в зеленый цвет, и это было бы дешевле — так бы и делали.

Если из всей статьи вы готовы запомнить лишь одну мысль, то запомните эту: Программирование не самоценно, а программисты — обслуживающий персонал.

Эта мысль может вас задеть — всё нормально. Чем раньше вы примете её, тем более ценным специалистом вы сможете стать. В нашей культуре считается, что лучше быть господином, нежели слугой. Но если подумать, то общество и вы находитесь в некоторых отношениях. В этих отношениях вы можете занять роль «добровольного слуги» и общество (в лице работодателя и довольных клиентов) щедро вознаградит вас за вашу заботу.

Ролевые игры. Часть 2

Зайдем с другой стороны: ваш двойник — директор, а вы — разработчик.

К вам вот-вот заглянет директор, а фабрика абстрактных автоматизаторов еще не дописана, SQL-запросы не отлажены да и вообще за полгода пришло понимание, что всё должно быть не так. 

Дилемма: никто не хочет работать тяп-ляп. Все хотят гордиться своей работой. Следовательно: (логическая ловушка) Да, я делаю медленно, зато правильно.
Если с «медленно» всё ясно, то что такое «правильно» — совсем не очевидно. На самом деле всё просто. «Правильно» — это когда за отведенный срок (±) появляется пригодная к использованию программа или сервис. Если ваше другое понятие «правильно» не приводит к появлению пригодного к использованию продукта за разумный срок, то ваше «правильно» никуда не годится. Тут нет простора для маневра. Вспомните, что программирование не самоценно.

Работа занимает всё отведенное на неё время. Если разработчику дать в три раза больше времени, он не напишет в три раза лучше. Он напишет в три раза больше кода того же качества, которое обычно выдает. Поэтому, всеми силами старайтесь получить нечто рабочее. Любой ценой. Ваша цель — работающая программа, неважно как написанная. Есть много т.н. называемых «грязных проблем» — это такие проблемы, которые непонятно как решать, пока не попробуешь решить. Пример: краш-тест машин. «Грязные» проблемы всплывут во время первого прохода и их можно будет учесть во время чистовой работы. Желательно, чужими руками.

Второй Большой Секрет: код — это всегда плохо. «Красивого» кода не бывает. Чем меньше кода, тем лучше. Любой код содержит ошибки, компромиссы и проблемы производительности."

Неожиданно актуально...

Ну и ещё:

"P.S.
Третий секрет. Начните писать в commit'ах пользовательскую ценность добавленного кода. Не «добавил два метода», а «Теперь пользователю быстрее/легче/меньше...» или «появилась функция / изменилась реакция». Вам нечего написать? Вы ничего не сделали за день."

(+)
http://18delphi.blogspot.ru/2013/04/blog-post.html
http://18delphi.blogspot.ru/2013/04/blog-post_2.html

Комментариев нет:

Отправить комментарий