Уголок философа: Долой перфекционизм
мая 10, 2011 | Published in Development Processes, Уголок философа | 3 Comments
Уголок философа — новая рубрика в которуюя буду помещать некоторые свои или понравившиеся чужие мысли. Статьи в этой рубрике не всегда будут соответствовать тематике блога, но я надеюсь, что они все-же будут интересны моим читателям, да и блог от них хуже не станет.
Дорога возникает под шагами идущего, а совершенствование — это бесконечный процесс движения вперед. Я сам перфекционист и люблю очень долго затягивать с чем нибудь, люблю долго что-то планировать, в своих фантазиях оттачивать это что-то до совершенства. Время идет, а это что-то остается на уровне идеи…
Недавно начал читать книгу «Человеческое, слишком человеческое» авторства Фридриха Ницше — очень познавательное чтиво, хотя написано очень тяжело из-за чего приходится по несколько раз перечитывать одно предложение. Там была выдвинута идея того, что, нет хорошего и плохого, и плохое не может породить хорошего. Мы можем лишь сравнить два примера и сказать какой из них лучше. Грубо говоря, нет ничего отрицательного — все лишь градиент положительного.
Таким образом код, который вы пишете не может быть говнокодом, он является отличным, замечательным кодом для тех условий в которых вы находитесь. Но ваш код не есть совершенным и никогда таким не станет! Вы должны осознать это и либо прекратить разработку, так как совершенства вы не достигните, либо продолжать писать код и пытаться достичь совершенства не в один присест, а итерациями, с каждой итерацией наращивая его качество и функциональность.
Итерационный подход — замечательный подход. Вы не делаете все и сразу, и выпускаете релиз через 5 лет,да еще и с кучей багов. Вы разбиваете весь процесс на кучу версий, а каждую версию на кучу более мелких итераций. Теперь, вы сфокусированы конкретно на выпуске продукта, который выйдет максимально быстро, будет содержать минимальное количество ошибок, которые можно перектыть патчем, либо в выпуске следущей версии.
Перфекционизм в коде
Иногда разработка приложения перестает быть целью и целью становится написание красивого, «правильного» кода, при этом программист забывает о том,что правильный код — это в первую очередь рабочий код. Если вы используете циклы вместо итераторов, или if-elsif-else в случае когда больше подходит конструкция case-when-default, то это без условно хуже, чем если бы вы использовали итераторы и case, однако это не так страшно, как нерабочий код. Единственное требование к коду — это его документирование: написание комментариев, и, для крупных проектов, отдельной документации по API. Можно бесконечно изучать предопределенные методы и функции, читать статьи гуру посвященные рефакторингу кода, однако ваш код никогда не станет совершенным.
Поймите, единственное требование к вашему коду — это его работоспособность и более-менее качественная документация.
Важно: Когда я говорю, что качество кода не так важно, чтобы доводить его до совершенства, я не говорю о том, что не нужно срараться делать его максимально качественным, давать вразумительные имена переменным и методам и т.д. Вы просто не должны зацикливаться на качестве.
Перфекционизм в архитектуре проекта
Очень важной составляющей процесса разработки является проэктирование архитектуры проекта. Архитектура приложения — это то, как функциональные части приложения взаимодействуют, как приложение масштабируется и расширяется.
Часто архитектуру выбирают неправильную. Нельза заранее спроэктировать совершенную архитектуру. В мажорных версиях программного обеспечения часто вносятся очень огромные изменения в саму архитектуру приложения, а расширение функционала в первых версиях можно считать вторичным. Таким образом приложение от версии к версии может переменить координальным образом и это нельзя назвать плохим проэктированием, это реалии разработки.
Вы не должны сидеть несколько недель с листком бумаги и маркером и стараться спроэктировать архитектуру приложения. Не старайтесь предусмотреть все, многое из того, что вы считаете необходимым будет, в лучшем случае, просто избыточным.
При разработке первых версий проекта следует сконцентрировать свое внимание не так на функциональности, как на архитектуре приложения. Существует много паттернов, благодаря которым вам не нужно изобретать свой велоспед, который в итоге может и не поехать. Эксплуатируйте труд других — это повысит вашу продуктивность и защитит от ошибок, которые уже были допущены.
Перфекционизм в программисте и ниша
Многие считают, что отличный программист должен в совершенстве знать несколько языков, несколько фреймворков, идеально знать математику, все алгоритмы и все патерны, написать свой собственный язык программирования, фреймворк и так далее. Я сам так раньше считал, но недавно переосмыслил свои представления.
Программсит — это профессия. Профессия — это определенные знания и навыки способствующие заработку денег. Хороший программист — это тот программист, который зарабатывает много денег. На самом деле многие программисты владеют несколькими языками программирования, но реально приносящим деньги инструментом является 1-2 из них. Отличный программист должен знать эти два языка, возможно, не идеально, но очень-очень хорошо. Если вы программируете на Ruby, то взгляните на вакансии, что требуется от Ruby — программиста: Ruby, JavaScript и все. Осваивайте эти два языка и их вамбудет достаточно, чтобы мочь назвать себя профессионалом, или чтобы люди могли назвать вас профессионалом, не сразу, но через несколько лет. Не рассеивайте свое внимание, вы должны выбрать свою нишу — свой коридор, по которому вы будете двигаться всю оставшуюся жизнь.
Самое ценное в отличном программисте — это не совершенное знание языков, а опыт решения проблем. Отличный программист при необходимости легко может перейти на другой язык программирования или фреймворк и стать гуру уже в новой нише. Когда я говорю о нишах, не стоит воспринимать это как то, что отличный веб-программист может легко стать отличным программистом систем наведения боеголовок. Здесь разница в профессиях более значительна, чем между, скажем Ruby и PHP веб-программистами, здесь действуют иные требования, здесь совершенно другие алгоритмы и технологии. Однако опытному веб-программисту все-же будет способствовать имеющийся у него опыт, да и это очень редко встречается, чтобы программист так резко менял свою нишу. Не думайте о необходимости учить другие языки и технологии на случай, если те, которые вы сейчас используете вдруг канут в небытие. Веб разработка никогда не исчезнет, а это значит, что если пропадет PHP и Zend, то вы всегда можете перейти на более кошэрный Ruby и Rails, или, не дай бог, наоборот.
Изучение других языков очень полезно, и интересно, но их изучение не должно становиться какой-то высшей целью. Принимайте это как развлечение и отдых от родного языка и начинайте их изучение либо по необходимости,либо когда уже достигли более-менее высокого уровня владениями своими основными инструментами.
Выберите себе нишу и двигайтесь в направлении того, чтобы быть лучшим программистом в этой нише, а не лучшим программистов вообще. Вы никак не сможете знать и уметь все, но почти совершенно знать и уметь что-то одно вам вполне под силу. Не распыляйтесь! Будучи отличным программистом на Ruby и Rails, вы заработаете больше денег, чем если будете посредственно знать несколько различных технологий, исключения очень редки.
мая 11, 2011 at 06:22 (#)
Ночью что ли писал? :) Описок много, прогнать бы черед спеллчекер, да все в одну кучу спихано. Т.е. соедины в одном контексте, местами в противопоставлении, вещи мало связанные.
Идея того, что идеал — недостижим, а делать надо то, что нужно, а не то, что мечтается — совсем не ограничивается рамками программирования. Хотя и в программирование об этом много было сказано, например милая сердцу моему статья .
Этот идея с равным успехом применима и к Agile, и к Waterfall. Ключевое — что программа должна работать и делать то, что от нее требуется, а не то, что придумал себе программист, иначе ее можно выкинуть на свалку таких покалеченных мечтами уродцев. :)
Но тем не менее заметка производит такое впечатление, это при отказе от перфеционизма ты скатываешься в другую крайность. «Make it work. Just work. Any way!». Ну по крайней мере такое ощущение возникает у меня :) Может это из-за того, что все идет рядом и вместе, эти идеи имхо стоило бы кристализовать в чистом виде и публиковать раздельно.
В общем, качество кода — вещь совсем не абстрактная, и стремится к оптимизации качества при данном количестве ресурсов (времени/разработчиков/денег) стоит. Заезженная идея рефакторинга на этом и строится. Что хороший, качественный — причем именно качественный, а не мудренно-академичный с 15 слоями абстракции — делает разработку дешевле. И «WTF?! в секунду» как мерил качество кода ;) Здесь же плавает точка зрения, что зачастую коментарии — зло, дезодорант, которым пытаются замаскировать и сделать безобидным какую-нибудь адовый хак.
Про архитектуру — тоже самое, архитектура в данном контексте не что иное как макро-вариант плохого кода. Есть, конечно, монстры, которые просто берут с произвольного угла и начинают писать систему, когда архитектура вырабатывается по мере необходимости, потом рефакторится, но в общем они на то и монстры. И в данном случае плохая архитектура будет примером плохого кода в целом, только более дорого для исправления. И дорого не в условным единицах, а реальных человеко-часах. Голова всегда должна быть на месте, а правильно поставленный вопрос в начале разработки может сэкономить кучу времени потом. Все же всегда лучше иметь чуть большую эластичность системы, чем минимально-необходимо. Собственно, тут возникает такой момент, что действительно хорошие архитектурные решения оказываются зачастую может и сложными по реализации, но элегантными по структуре, позволяющими с легкостью жонглировать огромными валунами абстракций. Другое дело, что они появляются не так часто, и требуют или много опыта, или много везения.
Кстати все же о блоге в целом, в такт последним абзацам. Ruby — это не только RoR. Это сверх-эффективное средство решения миллиона реальных мелких задач, включая такие радости, как написание консольных утилит, работа с произвольными бинарными форматами файлов, средство автоматизации и быстрого прототипирования всего и вся. И в данном случае сам язык является инструментом, хорошо подходящим для подобных небольших, но утилитарных задач. Так что иногда таки стоит просто взять и осилить какой-то язык(или фреймворк, по сути они тоже являются «подязыками»), который преспособлен под решение встающих перед тобой задач.
мая 11, 2011 at 06:58 (#)
Да, вы правы, писал ночью, да еще и под впечатлением от лабораторных работ, которые готовил в институт =)
На самом деле крайности в моих словах нет. Я не говорю, что от достижения совершенства следует отказываться, просто на первом месте должен стоять релиз, а не гонка за тем, чего догнать невозможно. И что следует разбивать разработку на итерации, а не пытаться за раз переплюнуть конкурета, который на рынке не новичек.
По-моему, комментарии очень важны и сильно упрощают жизнь, а без хаков иногда не обойтись, особенно на первых версиях, когда архитектура приложения не предполагала добавления чего-либо, а это что-либо вдруг понадобилось.
Изучить другой язык безусловно полезно, но это нужно делать не распыляясь, когда уже знаком со своей киркомотыгой досконало.
мая 11, 2011 at 14:17 (#)
Про комментарии есть позиция следующего рода, которую я в целом разделяю. Если в двух словах: «Никогда не комментируй ЧТО делает код. Это и так в коде написано. Комментируй ПОЧЕМУ он так делает, если это непонятно из самого кода». Сюда попадают варианты «Так сказал заказчик», «Это навороченная оптимизация методом Панцеклязевича-Пупкина», «В либе баг при вызове с очевидным набором параметров, потому делаем в два захода с прыжком через голову» и всякие прочие события.
Ну и соответственно для этого требуется навык писать код так, что бы читался легко, как художественная книжка :) Ну это должно быть знакомо, например очень ярко это в RSpec’е сделано.