 |
|
|
|
Вперед, к цели! Четыре правила эффективности
Вперед, к цели! Об эффективном программировании написано множество статей и книг, однако в этой статье не будет рецептов – только общие принципы и примеры их использования С чем сталкивается программист, особенно начинающий, когда приходит утром на работу? Обычно с необходимостью решить сразу несколько задач, и эти задачи могут быть новыми и старыми, простыми и сложными, срочными и глобальными. С какой из них начать? Как именно реализовать? С чего начать реализовывать? Проводить ли рефакторинг кода и модульное тестирование? Эти вопросы обычно решаются без особого обдумывания, на интуиции, однако уже здесь есть огромные возможности для увеличения эффективности. Выбор цели Итак, давайте подумаем, как нам сделать выбор. Для этого надо определиться с тем, чего мы хотим добиться, потому что эффективность без цели – это как свадьба без брачной ночи: вроде бы и весело было, а чего-то важного не хватает. Цель каждый ставит себе сам. Она может быть простой, например, «быть хорошим работником», «добиться повышения зарплаты» и т.д., главное, чтобы цель была, потому что в противном случае результат будет хаотическим. Кроме того, надо понимать, что для достижения цели затрачиваются некоторые ресурсы, обычно человеко-часы, которые можно пересчитать на деньги. Давайте для ясности рассмотрим пару примеров, как же все это использовать на практике. Вариант №1. Быть работником, выгодным для компании Допустим, речь идет о наемном работнике, и его цель – следовать цели компании. А цель компании в 99% случаев – заработать как можно больше денег. При таком раскладе проблема выбора программиста «с чего начать» становится проще: с энтузиазмом делаем выгодные для компании проекты, а невыгодные откладываем в долгий ящик, если это возможно. На первый взгляд может показаться, что нет никакой разницы, что делать: сначала задачу А или задачу Б, ведь все равно придется делать и то, и другое. Однако при внимательном рассмотрении выясняется, что это не так. Допустим, утрирую, задача А принесет очень много денег, и компания сможет нанять еще пару программистов. Тогда задача Б будет решена с легкостью, потому что будет избыток ресурсов. И наоборот, если вы сначала провозитесь над задачей Б, ваш отдел вообще могут ликвидировать, потому что вы что-то делаете, но денег как не было, так и нет. Разумеется, часто начальство не снисходит до объяснения важности того или иного проекта, в таком случае вам придется это как-то выяснять, спрашивать. Если вы, конечно, действительно хотите стать эффективным программистом. Что касается ресурсов – они не бесконечны, поэтому их надо экономить, освобождать от ерунды и вкладывать в важные дела. Например, компания запускает новый проект, скажем, стартап, а ведь доподлинно известно, что большинство таких попыток проваливаются. А если не проваливаются, то настолько отходят от первоначальной реализации, что хочется спросить, куда же подевался код, который мы писали вначале? Что отсюда следует? Возможно, не стоит на начальном этапе развития проекта сильно мудрить, покрывать код подробнейшими тестами, чрезмерно рефакторить и т.д., ведь это как бы черновик, попытка наудачу. Иногда лучше сделать три попытки, выбрать ту, которая реально пошла, и ее развивать, чем с теми же ресурсами запустить только один супер-мега-качественный проект, использующий все модные теории разработки, и при этом прогореть. Если рассматривать случай, когда компания занимается только одной задачей, даже здесь можно получить реальный выигрыш, если начинать с главного. Например, сначала делаем так, чтобы хоть что-то работало, показываем менеджеру/клиенту, и если он передумал, то переделываем, если же нет – обвешиваем «мулечками» (красивый дизайн, вспомогательные меню, кнопки, тестирование и т.д.). Если же сразу делать с «мулечками», работать над быстродействием программы и только потом показывать, то это напрасная трата времени. Вариант №2. Работа без стрессов Эта цель в какой-то степени является противоположной предыдущей, ведь здесь надо убрать главный источник стрессов – менеджера. Нет менеджера – нет проблем. Чтобы начальство не капало на мозги, нужно делать то, что говорят, все успевать, как можно меньше спорить, заранее предусматривать оправдания. Из выгодной задачи А и менее выгодной задачи Б выбирать ту, у которой срок предполагаемого завершения стоит раньше (чтобы потом не влетело за срыв сроков), даже если в вашей трекинговой системе у нее ниже приоритет. Если нет ни приоритета, ни даты, то следует делать ту задачу, которая начальнику больше нравится. Программист, следующий этой цели – этакий дауншифтер на поле боя. Приказы выполнены, результат – не моего ума дело. Эффективность в рамках его цели отличная. Вариант №3. Чтобы коллеги уважали и считали умным Цели фирмы игнорируются полностью. Затраченные ресурсы не имеют значения. Сроки проваливаются. Код – абсолютно гибкий, предусмотрено все, включая проблему 2038 и нашествие инопланетян. На каждую строчку кода – юнит-тест, UML-диаграмма, документация, независимо от стадии проекта. Бесконечный рефакторинг, порождающий постоянное изменение юнит-тестов, UML-диаграмм, документации. Используется все модные новинки, до которых можно дотянуться. Чтобы сложить 2 и 2, используется пять паттернов проектирования и два фреймворка. Половина рабочего времени используется для повышения квалификации, что на деле является оттачиванием аргументов своих парадигм на форумах, чтобы потом блеснуть интеллектом перед коллегами или в резюме. Я, конечно, снова утрирую, и должен заметить, что в определенном контексте такое поведение может совпадать с целями фирмы. Если это давно работающий, раскрученный, прибыльный проект, где, например, цена сбоя системы очень велика, то каждый писк должен быть тщательно протестирован и задокументирован. Осторожно, техника программирования! В общем, вы поняли, эффективному программисту без цели никуда. Но есть еще один важный аспект эффективности, приносящий огромный вред или огромную пользу, в зависимости от использования – это техники программирования. Существует огромное количество всевозможных теорий, техник и методологий, призванных помочь разработчику: Getting Real, экстремальное программирование, TDD, RUP и так далее. Все они имеют массу полезных идей и свойств, однако зачастую разработчики совершенно не принимают во внимание, что ВСЕГДА существует контекст применимости. Если вы пишете всего лишь веселую гостевую книгу для домашней странички друга, наверное, нет смысла использовать TDD. Следует остерегаться, когда авторитетный гуру программирования пишет в книге, что всегда надо делать так-то и так-то. Вранье. Он не сможет этого доказать. Верно и обратное: если кто-то говорит, что TDD – напрасная трата времени, он неправ, просто скорее всего конкретно в его работе это неприменимо. К примеру, всем известно, что гвозди не стоит забивать микроскопом, есть такой стереотип мышления. Однако вполне можно придумать ситуацию, где это будет приемлемо: возможно, в каком-нибудь Богом забытом месте нет ни одного молотка, зато ненужных микроскопов целый вагон. Опять же утрирую. Итак, я бы посоветовал использовать все эти теории только как очень ценный источник идей, из которых придется лепить свою собственную технику, подходящую к конкретной ситуации. В противном случае можно зарыть кучу времени/денег в песок. Легкая голова Другими словами, чтобы быть по-настоящему эффективным, надо все время думать, причем не только над архитектурой приложения, но и над тем, что именно вы делаете, как и ради чего, то есть понимать общую картину. А чтобы голове легче думалось, желательно обеспечить для этого все условия. Во-первых, надо высыпаться. Сонный программист может достаточно хорошо выполнять механическую рутинную работу, но когда необходимо придумать нестандартное решение или срочно исправить какую-то проблему, начинается торможение. Общая картина происходящего становится расплывчатой. Очень важно проветривать помещение и поддерживать подходящую температуру воздуха. Непостижимо, но почему-то этот фактор частенько упускается работодателями, а ведь производительность труда в душном офисе может быть в несколько раз ниже. И дальше: неудобное кресло, плохой монитор, депрессия, болезнь, сниженный тонус, нехватка витаминов, отсутствие интересного отдыха – все это наши враги. Примеры из жизни Допустим, приходит к вам кто-то из менеджеров и говорит, мол, сделай, пожалуйста, в такой-то форме кнопку «Восстановить значения по умолчанию», это займет пять минут. Мол, тикета нет, приоритет не определен, но там сущий пустяк. Вы чувствуете, что это действительно не займет много времени, но... Не пять минут, конечно. Может быть, час, потому что Вася там что-то кривовато запрограммировал. То есть надо отложить срочные и приоритетные проекты на час. Плюс надо отдавать работу на тестирование, тестировщики будут все время дергать, задавая свои странноватые вопросы. Потом выкладывать на сервер, где клиент сможет это посмотреть. Потом выкладывать на продакшн-сервер. И все эти операции проходят через тестирование. И вообще, выяснится, что кнопка не там, не такая и, может быть, вообще не нужна. Кроме того, таких мелких просьб появляется множество, и если все их сложить, получится немаленькая задача. Задача, отнимающая кучу времени и имеющая неясную важность. В общем, если кто-то подходит к вам с такой просьбой, возможно, стоит попросить сделать тикет, в котором указан приоритет, и если окажется, что эта задача не важна, отложить ее в долгий-предолгий ящик. Вот еще пример. Вы пришли на работу с тяжелой головой: вчера была свадьба друга, удалось добраться до дома только в два часа ночи. А тут еще и в офисе душно. И вот вы смотрите на свои задания и понимаете, что ничего не понимаете. Мозг выключен. Что же делать? А поступать надо, как обычно: решать проблемы, начиная с самой главной. Если главная проблема – вчерашний алкоголь, значит, надо выпить много воды, восстанавливая солевой баланс, в Интернете полно рецептов, как улучшить самочувствие. Если главная проблема – недосып, то придется выпить какое-то количество чашек кофе. Душный офис – проветрить помещение. Самое плохое, что вы можете сделать, это сидеть и жаловаться, не пытаясь исправить ситуацию. Если уж совсем ничего не помогает, все плохо, тогда можно попробовать отложить на потом сложные задачи, сосредоточившись на задачах средней сложности. *** Итак, чтобы быть эффективным, надо:
И вперед, вперед к цели! |
АНТОН ОКОЛЕЛОВ, занимается разработкой UI для исследовательских порталов глобальных компаний. Хочет научиться всегда выбирать только те решения, которые максимально быстро приближают к цели| Комментарии |
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
