[Перевод] Пятничный формат: Как писать код, который никто не сможет сопровождать
Благодаря советам экспертов в области Java вы научитесь писать код, который будет настолько сложно сопровождать, что любому, кто будет с ним работать после вас, потребуются годы, чтобы внести даже малейшие правки. Более того, если будете неизменно следовать этим правилам, вы сможете гарантировать себе пожизненное рабочее место, так как никто кроме вас не сможет разобраться в вашем коде.
Основные принципы
Чтобы нарушить все планы вашего коллеги по сопровождению кода, вы должны понимать, как он мыслит. У него есть ваша гигантская программа, но нет времени на то, чтобы прочитать весь код и уж тем более разобраться в нем. Он хочет поскорее найти ошибку и исправить ее так, чтобы потом это никак не повлияло на дальнейшую работу системы.
Вот он уже изучает ваш код под лупой. В каждый конкретный промежуток времени он может видеть лишь небольшую часть вашей программы, и вам нужно убедиться в том, что он никогда не сможет увидеть всю картину целиком. Вы должны сделать так, чтобы он ни за что не смог найти то, что ему нужно. И, что еще важнее, вы должны настолько усложнить его работу, чтобы любое его упущение приводило к катастрофе.
Особые методы
1. Лгите в комментариях. Необязательно врать на каждом шагу: достаточно того, что комментарии никак не будут связаны с кодом.
2. Заполняйте код комментариями вроде /* прибавить 1 к i */, но никогда не указывайте в коде такие общие вещи, как назначение модуля или метода.
3. Убедитесь в том, что каждый метод делает чуть больше (или чуть меньше), чем предполагается в его названии. Например, метод isValid(x) может, помимо прочего, переводить x в двоичную систему и сохранять результаты в базе данных.
4. Используйте аббревиатуры, чтобы ваш код был лаконичным. Настоящие мужчины никогда не дают определений своим аббревиатурам: они понимают их на подсознательном уровне.
5. Для создания еще большего эффекта старайтесь не пользоваться инкапсуляцией. Тем, кто вызывает тот или иной метод, необходимы все возможные подсказки, которые напомнят им, как работает этот метод.
6. Если вы, скажем, разрабатываете систему бронирования авиабилетов, сделайте так, чтобы для добавления новой авиалинии код нужно было отредактировать как минимум в 25 разных местах. И никогда не указывайте в комментариях, где именно: те, кто собрался работать с вашим кодом, не имеют права вносить в него коррективы, если до конца в нем не разобрались.
7. В целях повышения эффективности копируйте и вставляйте куски кода по несколько раз. Так выйдет быстрее, чем создавать несколько модулей для их повторного использования.
8. Никогда не пишите комментарии к переменным. Данные об использовании переменной, ее границах, допустимых значениях, скрытом и отображаемом числе знаков после запятой, единицах измерения, форме представления, правилах заполнения переменной (например, максимальное количество знаков или обязательность заполнения), о том, можно ли доверять значениям этой переменной, и т. д. следует выявлять уже в ходе работы программы.
Если ваш начальник заставляет вас делать комментарии, делайте их в теле метода, но никогда не пишите комментарии при объявлении переменных, даже временных.
9. Постарайтесь записать как можно больше данных в одну строку. В этом случае отпадает необходимость введения многих временных переменных, а также сокращается объем исходных файлов, так как остается меньше строк и лишнего пустого пространства.
Преимуществом написания длинных строк кода является еще и то, что разработчикам, которые не могут прочитать текст с 6 кеглем, приходится увеличивать шрифт, чтобы разглядеть записи в строке.
10. Кд, нпсннй бз глснх, крч [код, написанный без гласных, короче]. Когда сокращаете названия переменных или методов, дайте волю фантазии и используйте несколько вариантов одного и того же слова, иногда записывая его в полном варианте. Так вы сможете бороться с бездельниками, которые пользуются текстовым поиском, чтобы разобраться лишь в одной из функций вашей программы.
Подумайте над различными вариантами написания названий, которые могут запутать других. Например, можно одновременно использовать британский colour, американский color и специфичные варианты этого слова вроде kulerz.
В случае, когда вы записываете все имена полностью, у каждой из ваших переменных есть лишь один вариант написания. Специалист по сопровождению без труда сможет их запомнить. А раз одно слово можно сократить несколькими способами, то вы можете использовать несколько разных переменных для одной и той же цели. Более того, специалист по сопровождению ПО может и не заметить, что это несколько отдельных переменных.
11. Никогда не пользуйтесь автоматическим выравниванием кода. Попытайтесь каким-то образом повлиять на начальство, чтобы оно запретило его в вашей компании, аргументируя это тем, что автоматическое выравнивание вызывает непредвиденные изменения в системе управления версиями или потому что у каждого разработчика должен быть свой стиль выравнивания, и он должен оставаться нетронутым в любом из написанных им модулей.
Запретить автоматическое выравнивание не так уж сложно, даже несмотря на то, что оно позволяет резко сократить число нажатий по клавишам и дней, потраченных на неправильное понимание плохо выровненного кода. Вы должны настоять на том, чтобы все использовали единый стиль форматирования не только при сохранении данных в общем репозитории, но и в процессе редактирования кода. Это вызовет всеобщий гнев сотрудников, а начальство для поддержания спокойствия будет вынуждено отменить автоматическое форматирование.
После этого вы можете случайно выравнивать код так, чтобы возникала оптическая иллюзия того, что тела циклов и условий выглядят длиннее или короче, чем должны быть, или ключевое слово else соответствуют не тому ключевому слову if.
12. Никогда не вставляйте фигурные скобки { } в своих блоках if-else, если этого не требует синтаксис. Когда в вашем коде несколько выражений и блоков if-else идут подряд, причем еще и с неправильным выравниванием, то вы можете запутать даже опытного коллегу.
13. Строго следуйте указаниям, предусматривающим отсутствие оператора goto, досрочного выхода из цикла и его прерываний, особенно, когда вы можете увеличить глубину цикла if-else как минимум еще на пять уровней.
14. Используйте длинные названия переменных, отличающихся друг от друга всего лишь одним символом или регистром. Идеальная пара переменных – swimmer и swimner.
Используйте все возможные недостатки шрифтов, не позволяющих различать ilI1| или oO08, например, в случаях с parselnt и parseInt или D0Calc и DOCalc. В данной ситуации самый подходящий символ в названии переменной – это буква l, так как с первого раза ее не отличишь от константы 1.
Имена переменных также могут отличаться только регистром, например, HashTable и Hashtable.
15. Если временные рамки вас не поджимают, постарайтесь повторно использовать существующие имена несвязанных между собой переменных. Аналогично можете использовать одинаковые временные переменные для различных целей, уменьшая тем самым размер стека.
Совсем жестоко будет, если вы немного измените переменную: в начале очень длинного метода вы можете присвоить переменной одно значение, а затем где-то в середине незаметно сменить его на другое – скажем, поменять начало отсчета индексной переменной с 0 на 1. Только убедитесь, что это изменение не фиксируется в документации.
16. Пользуйтесь строчной буквой l при обозначении констант типа long. Например, 10l гораздо легче спутать с 101, чем с 10L.
17. Игнорируйте общепринятые соглашения Java об именовании классов и переменных, согласно которым, например, классы обычно пишутся с заглавной буквы, переменные – со строчной, константы – полностью заглавными, слова внутри названия класса/переменной пишутся с заглавной буквы. Даже компания Sun не следует этим соглашениям (примеры – instanceof/isInstanceOf, Hashtable/HashTable). Не беспокойтесь, компилятор даже не выдаст вам предупреждения.
Если все же ваше начальство заставляет вас следовать общепринятым соглашениям, каждый раз, когда у вас появляется выбор – стоит ли начинать с заглавной буквы или нет – пишите все прописными или пишите наугад, например, вы можете одновременно использовать inputFileName и outputfilename.
Более того, вы можете пойти на крайние меры и создать собственные безумно сложные правила именования, а потом упрекать других за то, что они этим правилам не следуют. Идеальный вариант – создать как можно больше имен переменных, слегка отличающихся друг от друга лишь регистром.
18. Никогда не используйте i как внутреннюю переменную в цикле. Можете выбрать любое название, но только не это. Вы можете специально использовать переменную i для других целей. Аналогично можно использовать n в качестве счетчика цикла.
19. Никогда не пользуйтесь локальными переменными. Как только почувствуете, что вам нужно сделать переменную локальной, объявите ее как объект или статическую переменную, чтобы щедро делится ею со всеми остальными методами класса.
Вы избавите себя от лишней работы в дальнейшем, когда в других методах нужно будет объявить те же переменные. Разработчики C++ иногда идут еще дальше и объявляют все возможные переменные глобальными.
20. Никогда не документируйте ошибки, не определяемые компилятором. Если вам кажется, что в классе прячется баг, лучше об этом умолчать. Если у вас есть идеи по поводу того, как можно перестроить или переписать код, ради всего святого, нигде о них не пишите.
Что если программист, работающий с этим кодом, увидит ваши комментарии? Что, если их увидит глава вашей компании или клиент? Вас же могут уволить.
21. Веселья ради можете подобрать как можно больше слов, обозначающих одно и то же действие, например, display, show, present. Неявно намекните, что между элементами программы якобы имеется небольшое различие, которого на самом деле нет.
И наоборот, если видите две похожие функции, имеющие принципиальное отличие, всегда используйте одно и то же слово для описания этих функций. Например, слово print обозначает одновременно и запись в файл, и печать на принтере, и вывод на экран. Не слушайте никого, кто будет требовать вас дать определения всем специфичным терминам. Это было бы непрофессионально с точки зрения принципа сокрытия информации.
22. В названиях функций старайтесь использовать больше абстрактных понятий, таких как it, everything, data, handle, stuff, do, routine, perform, и цифр, например, routineX48, PerformDataFunction, DoIt, HandleStuff и do_args_method.
23. В Java все параметры базового типа фактически доступны только для чтения, потому что они передаются по значению. Вызываемая процедура может изменить эти параметры, но не окажет никакого влияния на значения переменных в вызывающей процедуре. Все объекты, напротив, можно изменять, так как в данном случае по значению передается ссылка на эти объекты, то есть сам объект передается по ссылке. Поэтому вызываемая процедура как угодно может менять поля в вашем объекте.
Никогда не говорите о том, может ли метод изменять поля в каждом из передаваемых параметров. Названия ваших методов должны указывать на то, что сами методы могут только считывать значения этих полей, хотя на самом деле эти методы могут их изменять.
24. Никогда не указывайте в комментариях единицы измерения любого типа переменных – входных, выходных или параметров, будь то футы, метры или ящики. Это имеет большое значение не столько для точности расчетов, сколько для процесса разработки в целом.
Как следствие, не указывайте в комментариях коэффициенты пересчета каких-либо единиц измерения или методы, с помощью которых были получены итоговые значения. Простой и очень эффективный способ – записывать в комментариях неправильные единицы измерения.
Если у вас совсем нет совести, можете придумать свои единицы измерения, назвав их своим именем или именем никому не известной личности и не дав никаких пояснений. Если к вам придерутся, можете сказать, что таким способом вы отделяете целочисленные расчеты от операций над числами с плавающей точкой.
25. Инженерные расчеты можно запрограммировать двумя способами. Первый способ: перевести все входные значения в систему СИ, выполнить расчет и затем перевести выходные значения в соответствующие единицы измерения. Второй способ: проводить вычисления в различных смешанных системах измерения. Всегда выбирайте второй способ.
26. Еще одна малоизвестная хитрость. Исключения доставляют слишком много проблем. Хорошо написанный код никогда вас не подведет, так что в принципе можно обойтись и без исключений: нечего тратить на них свое время. Выделение подкласса исключений – это занятие для невежд, которые знают, что их программа не будет работать.
Вы можете значительно упростить свою программу, если оставите во всем приложении (в методе main) единственный оператор try-catch, который вызывает метод System.exit().
27. Компиляторы языка C преобразуют выражение myArray[i] в выражение *(myArray + i), которое эквивалентно выражению *(i + myArray), которое, в свою очередь, эквивалентно выражению i[myArray]. Настоящие профессионалы знают, как использовать эту особенность в своих целях. Этот способ, к сожалению, применим только в «родных» классах.
28. Если у вас имеется массив из 100 элементов, старайтесь как можно чаще присваивать переменным конкретное значение 100. Не используйте статических ненаследуемых констант вместо этого значения и не ссылайтесь на него через свойство myArray.length. Чтобы это значение было еще сложнее изменить, вы можете использовать другие конкретные числа, к примеру, 50 вместо 100/2 или 99 вместо 100-1. Можно еще больше завуалировать это значение, заменяя выражение a > 100 на a == 101 или выражение a >= 100 на a > 99.
Нужно также учитывать такие особенности, как формат страницы, которая состоит из заголовка x, основного текста y и примечаний z. Вы самостоятельно можете создать путаницу одновременно как в каждой из частей кода, так и в их комбинации или общей сумме.
Эти проверенные временем способы эффективнее всего работают, когда в программе есть два несвязанных массива, которые по счастливой случайности содержат по 100 элементов каждый. Для таких случаев есть еще более изощренные методы. Для того чтобы усыпить бдительность специалиста по сопровождению, создайте именованную константу и раз за разом совершенно случайно используйте конкретное значение 100 вместо именованной константы.
Но, помимо всего этого, самым гадким поступком в данной ситуации будет использовать время от времени другие отдельные константы, которые в данный момент времени чисто случайно будут равняться 100. Таким образом, вы фактически должны избегать использования определенной системы имен, которая бы могла связать имя массива с константой, равной его длине.
29. Избегайте любых форм табличной логики. Она только кажется безобидной, однако вскоре приводит к тому, что конечные пользователи начинают в ней разбираться, а затем и подстраивать таблицы под себя.
30. Постарайтесь максимально усложнить структуру кода. Умелые программисты могут вставить до 10 пар круглых скобок ( ) в одной строке и до 20 пар фигурных скобок { } в одном методе. Настоящие мастера умеют располагать начало и конец блока на разных страницах листинга. По возможности в циклах с условием вместо if используйте тернарные операторы [?:].
31. Поищите пособия по программированию, чьи авторы чаще пишут книги, чем программы. Можете зайти в местный книжный магазин и отобрать книги, в которых есть масса сложных диаграмм и ни одного примера написания кода. Бегло просмотрите эти книги и выберите в них чересчур умные слова. Эти слова можно использовать для того, чтобы отпугнуть самонадеянных новичков, претендующих на ваше место.
Ваш код должен производить на других впечатление. Если другие не разбираются в терминологии, которую вы используете, то они будут думать, что вы очень умный, а ваши алгоритмы слишком сложные. Не надо использовать примитивную лексику, когда объясняете, как работает ваш алгоритм.
32. Постоянно вносите изменения в свой код и вынуждайте пользователей как можно чаще обновляться: в конце концов, никто не хочет работать с устаревшей версией вашей программы. Несмотря на то, как сильно пользователям нравится работать в вашей программе, только представьте, какое удовольствие они получат после того, как вы ее «улучшили».
Никому не говорите, что именно вы изменили в новой версии, если от вас этого не требуются: зачем рассказывать о багах в старой версии, которые никто бы так и не заметил?
33. В разделе «О программе» следует указывать только название программы, имена разработчиков, а также предупреждение о нарушении авторских прав, состоящее из одних юридических терминов. В идеале он должен содержать ссылку на несколько мегабайт кода, которые выдают красивую анимацию. Но ни в коем случае не надо указывать в нем фактическое назначение программы, дополнительный номер версии, дату последнего изменения в программе, сайт, на котором можно получать обновления, или e-mail автора программы. При таком подходе все пользователи вскоре станут работать с разными версиями программы и пытаться установить сразу версию N+2 вместо версии N+1.
34. Чем больше изменений вы можете внести, тем лучше. Вы ведь не хотите, чтобы один и тот же API или пользовательский интерфейс все больше надоедал вашим пользователям. Кроме того, если вы можете внести изменения так, что ваши пользователи этого не заметят, это тоже плюс: так они не будут расслабляться, находясь в постоянном ожидании.
35. Если вам нужно написать классы, которые будет использовать другой разработчик, вставьте код для проверки переменных окружения (getenv() в C++, System.getProperty() в Java) в статические безымянные инициализаторы ваших классов, а затем передайте в таком виде все свои аргументы классам, вместо того чтобы делать то же самое в конструкторе.
Преимуществом такого подхода является то, что инициализаторы вызываются во время загрузки модулей программы, до создания экземпляров класса, то есть, как правило, они будут исполняться перед функцией main(). Другими словами, программа не сможет изменить эти параметры до того, как они окажутся в ваших классах: значения переменных окружения у пользователей должны быть такими, какими установили их вы.
36. Выбирайте для переменных названия, не связанные с соответствующими им надписями, которые появляются после запуска программы. Например, если одно из полей на экране подписано как Postal code, то соответствующей переменной вы можете дать название zip.
37. Java позволяет создавать методы, имеющие то же название, что и классы. При этом сами методы могут не являться конструкторами. Используйте эту возможность, для того чтобы всех запутать.
38. Никогда не пользуйтесь менеджерами размещения. Таким образом, когда специалист по сопровождению продукта добавит новое поле, ему придется вручную подбирать абсолютные координаты каждого элемента на экране. Если начальство заставляет вас использовать менеджеры размещения, пользуйтесь одним режимом GridBagLayout, а в качестве координат сетки выбирайте конкретные значения.
39. Забейте на интерфейс Java. Если ваше руководство станет предъявлять к вам претензии, скажите, что интерфейсы Java вынуждают вас копировать код в различные классы, которые одинаково реализуют один и тот же интерфейс, а ваше начальство знает, как тяжело будет сопровождать этот код.
Следуйте примеру разработчиков Java AWT – заполняйте свои классы богатым функционалом, который могут использовать только наследуемые классы, и выполняйте частую проверку в своих методах с помощью оператора instanceof. Получается, что любому, кто захочет несколько раз воспользоваться вашим кодом, придется расширять ваши классы. Если кто-то захочет использовать ваш код из двух разных классов, то им не повезло – они не смогут расширить оба класса одновременно.
40. Определите все свои классы, у которых нет наследников, при помощи ключевого слова final. В конце концов, свою работу на проекте вы выполнили, и никто не сможет его улучшить за счет расширения ваших классов. Более того, это может вызвать проблемы в системе безопасности. Именно поэтому класс java.lang.String объявлен как final. Если другие разработчики на вашем проекте начнут возмущаться, скажите им, что работаете над улучшением производительности программы.
41. Объявите как можно больше переменных статическими. Если в этой программе вам достаточно одного экземпляра класса, значит, и всем остальным этого будет достаточно. Если другие разработчики в вашем проекте начинают предъявлять свои претензии, также скажите им, что решаете проблему производительности.
42. Храните все неиспользуемые или устаревшие методы и переменные в коде. Если когда-то в 1976 году в них возникала необходимость, что, если она возникнет и на этот раз? Конечно, с тех пор программа сильно изменилась, но все эти изменения можно легко отменить: вы же не станете «изобретать велосипед» (любимая поговорка менеджеров). Если вы оставите в комментариях все эти методы и переменные нетронутыми и не совсем понятными, то все, кто будут сопровождать ваш код, тоже побоятся что-либо менять.
43. К методу makeSnafucated добавьте один комментарий /* make snafucated */. Нигде не указывайте, что на самом деле обозначает слово snafucated. Всем уже пора знать такие элементарные вещи.
44. Измените порядок следования параметров в методе drawRectangle(height, width) на drawRectangle(width, height), не меняя при этом названия самого метода. Затем после нескольких релизов, измените этот порядок обратно. С первого раза очень сложно догадаться, какой из вариантов используется в программе. Оставим задачу понимания работы метода коллегам.
45. Вместо того чтобы передавать параметры в один метод, создайте как можно больше отдельных методов. Например, в методе setAlignment(int alignment)переменная alignment является константой, определяющей выравнивание по левой и правой стороне и по центру. Вместо одного этого метода вы можете создать три: setLeftAlignment, setRightAlignment, и setCenterAlignment. Для еще большего эффекта можете скопировать общий код в каждый из методов, чтобы их сложнее было согласовывать между собой.
46. У метода Камасутры есть особое преимущество: он позволяет рассеять внимание как пользователей и составителей документации, так и специалистов по сопровождению ПО. Создайте множество перегруженных вариантов одного и того же метода, отличающихся друг от друга в незначительных деталях. По-моему, Оскар Уайльд однажды заметил, что в Камасутре позы 47 и 115 отличались лишь тем, что в позе 115 у женщины были скрещены пальцы. Пользователям же приходится тщательно просматривать длинный список методов, чтобы выбрать наиболее подходящий вариант.
Кроме того, благодаря этому методу увеличивается объем документации а, следовательно, и вероятность того, что она окажется устаревшей. Если ваш начальник будет спрашивать, зачем вы так поступаете, поясните, что делаете это исключительно для удобства пользователей. Для еще большего эффекта, как и в других случаях, вы можете скопировать общую часть кода в каждый из методов.
47. Объявите все методы и переменные публичными. Рано или поздно кому-то это понадобится. Если метод является публичным, от него будет тяжело избавиться: так сложнее будет вносить коррективы в работу программы. Помимо этого, такой подход позволяет скрыть реальное назначение класса. Если начальство начнет к вам придираться, скажите, что вы всего лишь следуете традиционным принципам проектирования «прозрачных» интерфейсов.
48. Перегружайте функции из библиотеки C++, используя директиву #define. В этом случае все будет выглядеть так, будто вы используете функцию, хранящуюся в библиотеке, хотя на самом деле она не имеет к ней никакого отношения.
49. В C++ вы также можете перегружать операции «+», «-», «*»», «/», чтобы выполнять действия, совершенно отличные от сложения, вычитания, умножения и деления. Если уж Страуструп догадался использовать оператор сдвига для осуществления ввода/вывода, разве вы не сможете придумать что-то похожее? Когда перегружаете операцию «+», убедитесь, что выражение i = i + 5; никак не связано с выражением i += 5;
50. При составлении документации для файла лучше подобрать случайное название вроде file, а не такие очевидные имена, как Charlie.dat или Frodo.txt. Если говорить в общем, то старайтесь в своих примерах подбирать случайные названия, максимально похожие на зарезервированные ключевые слова.
К примеру, для названия параметра или переменной отлично подойдут такие варианты, как bank, blank, class, const, constant, input, key, keyword, kind, output, parameter, parm, system, type, value, var и variable. Если в названиях вы используете зарезервированные слова, которые не принимает командный процессор или компилятор, то это еще лучше. Если у вас все получится, пользователи просто запутаются в ключевых словах и выбранных вами названиях, а вы будете здесь ни при чем, потому что хотели лишь помочь им связать назначение каждой переменной с ее именем.
51. Всегда используйте особый синтаксис команд, определяемый вашей собственной версией БНФ (формы Бэкуса-Наура). Никогда не поясняйте значение своего синтаксиса, представленного в виде набора допустимых и недопустимых команд: это будет говорить о низком уровне вашей компетенции. То же касается и использования синтаксических диаграмм.
Проследите за тем, чтобы разницу между конечными символами (теми, что можно ввести) и промежуточными символами (которые представляют собой одну из фраз синтаксиса) увидеть было не так просто. Старайтесь не создавать визуальных подсказок в виде особого шрифта, цвета или заглавных букв, которые могут помочь проверяющему определить эту разницу.
В своей БНФ используйте те же знаки препинания, что и в языке команд: те, кто пытаются разобраться в вашем коде, будут долго думать, составляют ли символы (...), [...], {...} и «...» часть вводимой вами команды или же их цель – показать, какие элементы синтаксиса вашей БНФ обязательны к использованию, какие – необязательны, а какие – просто повторяются. В конце концов, если они настолько глупы, что не могут понять суть вашей БНФ, то им просто нет смысла дальше работать с вашей программой.
52. Препроцессор макросов предлагает много возможностей для того, чтобы запутать тех, кто будет читать ваш код. Основным приемом является размещение макроса на несколько уровней вглубь кода, так что остальным приходится искать его различные компоненты в разных файлах формата *.hpp. Если вы вставите исполняемый код в макросы, а затем поместите эти макросы в каждый из файлов формата *.cpp (даже в файлы, не использующие эти макросы), то вы максимизируете число повторных компиляций, в случае если в код будут внесены изменения.
53. Объявление массивов в Java можно осуществлять разными способами. Вы можете объявлять массив по-старому, как в языках C, в виде String x[] (скобки идут после имени переменной) или по-новому в виде String[] x (скобки ставятся после типа данных). Если хотите окончательно запутать других, то можете смешать оба метода.
54. Java дает возможность запутать других во время преобразования типов переменных. Простой пример: вы, конечно, можете конвертировать тип double в String напрямую через Double.toString(d), но лучше сделать это по-другому, записав new Double(d).toString. Если хотите, можете придумать что-то более изощренное.
Однако не пользуйтесь методами преобразования, рекомендованными в Conversion Amanuensis. Чем больше временных объектов заполняет динамическую память после преобразования, тем лучше.
55. Как можно чаще пользуйтесь потоками.
P.S. Больше материалов по теме стартапов в наших блогах на Geektimes и Megamozg.
