Category: Переводы

Естественный Пользовательский Интерфейс

Перевод Андрея Юркова ответа на вопрос «What are the basic principles of NUI (Natural User Interface) design?»
Это был его первый технический перевод, он немного хромает, но понять суть можно.

Каковы основные принципы дизайна NUI?

Дизайн для пальцев, а не для курсоров

Сенсорные иконки должны быть гораздо больше, чем для ПК: 8-10мм для иконок, 10-14мм в области соприкосновения с пальцами.

Помните о физиологии и кинезиологии

Не заставляйте пользователей делать лишние или повторяющиеся действия.

Не для рук гориллы

Люди не должны делать много задач с поднятыми, перед их телом, руками в течение длительного периода времени. Извините, сугубо личное мнение.
Гориллы с айпадом

Расположение элементов на экране

Ладонь, соединенная с пальцами, может закрывать экран, в то время как вы пытаетесь сделать жест. Избегайте помещать важные элементы, например, ярлыки ниже элементов контроля, их может быть не видно из за рук пользователя. Поместите пункты меню в нижней части экрана, чтобы избежать этот феномен.

Знайте технологии

Тип сенсорного экрана, датчика или камеры определяет тип жестов, которыми вы можете пользоваться.
Чем больше сложных жестов, тем меньше людей, которые смогут (или захотят) выполнять их.
Запуск действия легкой нажатием, а не давлением.

Приветливость

Используйте простой жест, чтобы дать возможность пользователям начать использовать систему.

Избегайте случайных нажатий

Различные повседневные движения со стороны пользователей могут случайно запустить систему. Избегайте их.

Жесты и командные кнопки

Обеспечьте простой (кнопки, ползунки, пункты меню и т.д.) способ доступа к функциональности, но и обеспечить передовые функции, например, возможность распознавать жесты, как ярлыки.

Необходимость разнообразия

Существует широкий спектр способов выполнения жеста. Рассчитывайте на это.
Сосчитайте сложность жестов со сложностью и частотностью задания
Простые, часто используемые задачи должны соответствовать столь же простым жестам, для из вызова.

Как перевести слово «Говнокод»?

Говнокод это очень сильное и ёмкое понятие. В нём вся суть нашего отношения к коду.
Есть даже хороший сайт Govnokod.ru  на котором коллекционируют листинги пахучего кода. В англоязычном сегменте есть аналог TheDailyWTF.com.

Проблема в том что в английском языке такого понятия похоже нет. А выделить отдельное понятие в своё слово это так же как дать название болезни: обязательный шаг к излечению от неё.

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

Вообщем я считаю что нужно вводить международное понятие и активно его популяризировать.

Вариантов немного:

  • Полностью русское слово Govno Code. Произносить не очень сложно, как пишется так читается. Проблема в том что не всем иностранным коллегам будет ясно что такое Govno.
  • Если перевести говно на английский с примерным сохранением этимологии то получится Shit Code. Но Shit имеет оттенок сожаления, это скорее аналог русского «Вот блин!»
  • Научный вариант Copro Code. Тут есть тонкий намёк на Копрофилию.

Больше вариантов мне пока не известно.

Голосуем!

Ну и в качестве бонуса
Копроэкономика

[Перевод] Пол Грэм: Парадокс Питона (The Python Paradox)

Автор: Пол Грэм, August 2004
Python + Java
В недавней беседе я сказал то, что расстроило большое количество людей: «Вы можете найти более сообразительных программистов для работы над проектом на Python’е, чем для работы над Java проектом».

Я не имел в виду, что программисты на Java тупые. Я имел в виду, что программисты на Python’е сообразительнее. Ведь это огромная работа выучить новый язык программирования. Люди учат Python не потому, что он даст им возможность получить работу. Эти люди учат новый язык, потому что они искренне любят программировать и не удовлетворены теми языками, которые уже знают.

Это делает их как раз теми, кого компании по разработке ПО следует хотеть нанять. Именно поэтому, из-за отсутствия лучшего названия, я назову это «парадоксом Python’а»: если компания хочет написать своё ПО на относительно эзотерическом языке, то она наймет лучших программистов, потому что она привлечёт только тех, кто позаботился выучить его. Для программистов парадокс можно перефразировать так: язык, который нужно выучить, чтобы получить хорошую работу, это тот язык, который люди учат не только чтобы получить работу.

Не много компаний достаточно мудры, чтобы осознать это. Но и здесь происходить выбор: это как раз те компании, в которых программисты захотят работать. Например, Google. Когда они нанимают java программистов, они также хотят увидеть опыт программирования на Python.

Мой друг, который знает большинство распространенных языков, использует Python для большинства своих проектов. Он говорит, что основная причина, это то как выглядит исходный код. Это может показаться несерьезной причиной выбора языка. Но это намного вачнее, чем кажется: когда ты пишешь программу, ты тратишь больше времени на чтение, чем на написание кода. Ты добавляешь куски исходного кода также, как скульптор добавляет куски глины. Язык, который делает исходный код уродливым, сводит с ума придирчивого программиста, как глина с комьями скульптора.

При упоминании уродливого кода, люди конечно подумают о Perl. Но внешнее уродство Perl не из этого разряда. Настоящее уродство не грубо выглядящий синтаксис, а неизбежность построения программ на не правильных концепциях. Perl может выглядеть как нелепый персонаж мультфильма, но в некоторых случаях он концептуально превосходит Python.

До сих пор, не смотря ни на что, оба языка являются «движущимися мишенями». Тем не менее их объединяет с Ruby (и Icon, и J, и Lisp, и Smalltalk) тот факт, что они создавались и использовались людьми, которые действительно интересуются программированием. И тот велик, кто делает это хорошо.

Оригинал (англ.) The Python Paradox
Статья хоть старая но до сих пор актуальная. Перевод не мой, я просто делаю репост чтобы не потерялся текст.
И кстати да, не дайте себе запудрить мозги, Ява лучше 😉
joseph-ducreux-meme-disregard-python-acquire-java-080b2b

[Перевод] Способы сравнения объектов дат в Java

Аннотация от переводчика

Статья вкратце затрагивает трудности работы с датами в Яве на простом примере сравнения дат. Рассчитана для начинающих программистов которые уже более менее знакомых с работой с датами в Java.

Итак, давайте обрисуем проблему — сравнение объектов Date в Java известный источник ошибок.
Это появляется в стандартном коде, но также бывает и в тестирующем коде, где нам регулярно нужно создавать объекты Date которые отмечают определенный момент времени на который потом будем ссылаться в сравнении.

Старый добрый устаревший и не рекомендуемый путь

В тестирующем коде я не переживал что использую устаревшие (deprecated) методы. Поэтому я использовал старый конструктор Date чтобы инициализировать даты, после чего я сравнивал их с другим объектами дат через метод сравнения equals():

Date date = new Date(112, 5, 3);
Date userCreatedDate = user.getCreatedDate();
if (userCreatedDate.equals(date)) { // Если даты равны…
  // делаем что нибудь…
}

Преимущества: это лаконично. Недостатки: это весьма не очевидно и вам нужны хорошие знания Java API чтобы знать что первый параметр это год минус 1900 и второй это индекс месяца который начинается с ноля для Января. И это сюрприз когда вы узнаёте что последний параметр это просто… просто день месяца.

Канонический способ

Начиная с Java 1.1 в Java API был добавлен класс Calendar чтобы разделить момент во времени (т.е. дату) от её представления в специфическом справочнике (календарь). Следующий фрагмент кода (snippet) это способ получения такого же результата как выше.

Calendar calendar = Calendar.getInstance();
calendar.set(YEAR, 2012);
calendar.set(MONTH, JUNE);
calendar.set(DAY_OF_MONTH, 3);

Это не только более многословно, тут также есть ошибка: часы, минут и остальное не равно нолю (берётся от момента непосредственного создания календаря), поэтому сравнение через equals() будет возвращать false. Вот правильный код:

Calendar calendar = Calendar.getInstance();
calendar.set(YEAR, 2012);
calendar.set(MONTH, JUNE);
calendar.set(DAY_OF_MONTH, 3);
calendar.set(HOUR_OF_DAY, 0);
calendar.set(MINUTE, 0);
calendar.set(SECOND, 0);
calendar.set(MILLISECOND, 0);

По меньшей мере это ухудшает краткость 😉

Apache Commons Lang

Apache Commons изначально предоставляет различные утилитные библиотеки которые облегчают разработку в Java. Одна из таких библиотек Apache Commons Lang которая предоставляет функционал который заслуживает быть частью Java API. В нашем случае класс DateUtils позволит нам сократить код сохранив при этом его читаемость:

Calendar calendar = Calendar.getInstance();
calendar.set(YEAR, 2012);
calendar.set(MONTH, JUNE);
calendar.set(DAY_OF_MONTH, 3);
calendar = DateUtils.truncate(calendar, DAY_OF_MONTH); 

Даже лучше, DateUtils позволяет нам работать непосредственно с объектами Date в таком альтернативном виде:

Date date = new Date();
date = DateUtils.setYears(date, 2012);
date = DateUtils.setMonths(date, JUNE);
date = DateUtils.setDays(date, 3);
date = DateUtils.truncate(date, DAY_OF_MONTH);

Обратите внимание что он оставляет параметры нетронутыми, достигая неизменяемости (immutability) по принципа функционального программирования.
Преимущества: мы используем стандартное Java API.
Недостатки: да никаких. И ещё, не будет ли полностью своеобразный DSL казаться чем-то более подходящим?

Joda Time

Последний вариант это использование библиотеки Joda Time, которая нацелена стать заменой для Date и Calendar. Она также породила JSR-310 — новый и улучшенный API для манипуляции с датой и временем, который должен стать частью Java 8 (он был изначально запланирован для Java 7). Joda Time стоит посвятить отдельную статью (или даже мини-руководство). Для наших текущих нужд следующий фрагмент кода может выгодно заменить наш изначальный:

DateMidnight dm = new DateMidnight(2012, 6, 3);

Если сравнивать с первым примером, такой код кажется чище и лаконичней. И ещё, параметры самоописывающие, нет реальной нужды регулярно проверять JavaDocs чтобы узнать как инициализируется год. Кроме того, семантика имён классов ясна. И наконец, метод toDate() даёт нам мост к стандартному Java API.

Заключение

Вывод делайте сами. Лично я обычно использую Apache Commons Lang, но в последнее время склоняюсь к Joda Time. Архив с примерами кода доступен для скачивания тут в виде Maven проекта под Eclipse.

Автор: Nicolas Fränkel
Оригинал Ways of comparing Date Objects in Java.

[Перевод] Как писать сопроводительное письмо

Перевод статьи How to Write a Cover Letter.

Примечание переводчика: Сопроводительное письмо (англ. Cover Letter) — это письмо которым вы сопровождаете ваше резюме работодателю когда хотите устроится на конкретную позицию. В нём вы пишите, мол «я тут нашёл вашу вакансию на таком то сайте, я кое что умею из описанного в ней, я долго ждал такой возможности, возьмите меня пожалуйста на работу, в приложении к письму моё резюме и связаться со мной можно по этому телефону».
Например вот таким было моё сопроводительное письмо год назад когда я пытался поменять специализацию. А вот ещё один пример сопроводительного письма фрилансера.

Эту статью крупнейшая фриланс биржа oDesk рекомендует новичкам. Она будет полезна главным образом программистам и всякого рода фрилансерам работающим на западного заказчика.

Как писать сопроводительное письмо

Сопроводительное письмо это ваш первый, возможно единственный, шанс заинтересовать потенциального клиента или нанимателя. Но всё таки не позвольте этому запугать вас. Сопроводительное письмо фактически даёт вам шанс блеснуть. Оно даёт нанимателю заметить вас и потенциально заинтересоваться вами. Ваш опыт, ваша личность и ваш энтузиазм все вместе играют роль чтобы помочь вам устроится на работу. Не оставляйте их в стороне когда будете составлять ваше сопроводительное письмо.

Так как же его писать?

В общем, будьте честными, искренними, и профессиональными. Но детали могут стать более сложными. Следуйте этим простым правилам чтобы создать неотразимое сопроводительное письмо которому нанимателю будет сложно отказать!

Начните с приятного и профессионально приветствия.

Этот человек будет принимать решение нанимая вас — поэтому ваше начало знакомства должно убедить его думать о вас как о том с кем бы он хотел работать. «Уважаемый Евгений Николаевич», «Здравствуйте, Евгений,» будет уместным. А вот «Привет Женя,» «Как житуха, Жека?» или любая несерьёзность должна быть заменена на что нибудь более формальное. Не знаете имени человека который занимается наймом? «Уважаемый менеджер по персоналу», (“Dear Hiring Manager,”) это отличный способ задать профессиональный тон с самого начала.

Переходите к делу.

Ваше сопроводительное письмо это не место где нужно писать новеллу о себе. Дайте нанимателю понять почему вы пишете ему, какие навыки у вас есть которые делают вас подходящим человеком на эту позицию, и где они могут найти больше информации о вашем опыте работы:

Меня заинтересовала ваша позиция ведущего блогера который вы недавно опубликовали. Я была профессиональным писателем на протяжении девяти лет, и я хорошо знакома с WordPress’ом и Typepad’ом. На протяжении трёх лет, как главный редактор BeingInterested, я управляла командой писателей которые публиковали по пять записей в блог за неделю. Вы можете познакомится с некоторыми моими работами в поём портфолио по адресу www.odesk.com/users/…

Подчеркните главное.

Большинство объявлений о работе дадут вам очень понятные подсказки про набор навыков которыми должен обладать желаемый кандидат.
Если у вас есть эти навыки, вы должны их упомянуть — повторяя требования нанимателя на позицию и как вы их покроете даст понять, что вы тот самый человек на эту работу:

Вы упомянули что ищете кого нибудь с опытом писательского мастерства и журналистики. Я изучала эти предметы в колледже, где я получала специализацию Английского языка. Я начала мою карьеру как ассистент редактора в местной газете, где я училась практическому подходу к журналистским расследованиям.

Следуйте указаниям.

Много потенциальных нанимателей будут просить кандидатов заполнить специфические запросы в их сопроводительных письмах. Это сделано чтобы помочь им быстро отсеивать их через программу, и отбрасывать тех кто просто воспользовался копированием и вставкой когда отправляли резюме. Если вам задан специфический вопрос или должны вставить ключевое слово в ваш ответ, убедитесь что вы сделали это! И как дополнительный бонус, указание той информации которую они запросили это отличный способ дать им понять и проще принять решение о найме:

По вашему запросу, здесь предоставлены ссылки на три статьи которые я написала про местное мероприятие, садоводство или технологию…

Закрывайте продажу.

Убедитесь что вы дали им понять вашу способность занять позицию и пригласили их связаться с вами для обсуждения в будущем. Это вежливый способ «попросить работу» и закрепить ваш энтузиазм для работы с этим нанимателем:

Я могу выделять 15 часов в неделю вашей компании, и мои часы в день можно обсудить. Я очень заинтересована помочь вам сделать ваш блог успешным. Пожалуйста, чувствуйте себя свободно и обращайтесь ко напрямую чтобы обсудить детали этой работы.

Перечитайте, отредактируйте и продумайте.

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

Сопроводительные письма являются первым впечатлением для работодателя или клиента, поэтому убедитесь что вы приложили необходимые усилия. Найти больше советов по мастерству удачного сопроводительного письма вы можете найти в предыдущей статье Написание «убийственного» сопроводительного письма (ориг. Writing a Killer Cover Letter), содержащее короткий список способов добиться чтобы ваше письмо стало по настоящему «убийственным».

О авторе:

Эрика Бентон (Erica Benton) возглавляет команду блога в oDesk, и видела достаточно сопроводительных писем чтобы определить «убийственное» (“killer”) когда она его встретит. Эрика получила опыт как владелец небольшого бизнеса и фрилансера вплоть до того как она стала менджером по маркетинговым связям в oDesk.

[Перевод] Может ли программирование стать следующей массовой профессией?

Может ли программирование стать следующей массовой профессией так же как сельское хозяйство в 17-ом столетии, фабричная работа во время промышленной революции, строительство во время Великой Депрессии, и мануфактура после Второй мировой войны.
Даже лучше! Потому что программирование является творческим процессом, который может быть с или без традиционного (устаревшего?) офиса, и может создавать огромную личную и экономическую ценность.

Большинство молодых людей начинает работать в направлениях, у которых нет будущего.
И большинство не получает высшее образование — только одна треть получает какую нибудь учёную степень.
В прошлом, студенты, которые не получали высшее образование, изучили профессионально-технические навыки, но это сломалось когда мы перешли в информационную экономику.
Сегодня, студенты без высшего образования вообще идут в сферу обслуживания или торговлю, где работа, если они её таки получат, не предлагает большого карьерного роста.

Есть новая возможность, появившаяся для молодых людей чтобы получить продуктивную, предприимчивую, удовлетворяющую работу: они могут научиться программировать. Программирование это не то, чему трудно научится — любая аутсорсинговая компания берет людей без знаний и делает их Ява программистами за 3 месяца (Конечно, огромное значение имеет тут имеет талант и мастерство).
Программировать не дорого — с интернетом, облачными хостингами и открытым ПО.
До определенного момента программисты самообучаемы, и могут продолжить совершенствовать свои умения.

Есть даже великолепные сервисы: на подобии Treehouse и Codecademy, бесчисленые бесплатные онлайн курсы, Google Code University, приветливый Stack Overflow, персональные курсы вроде Dev Bootcamp, летние кружки для детей, и великолепные организации вроде CodeNow. Я уверен что перечислил далеко не все.

Ещё не так много ВУЗов обучающих программированию. Большинство их учит этому лишь как часть учебного курса.
Хотя конечно они так и должны делать — программирование это грамота, а не (только) специализированный навык. И даже дети могут начать программировать рано. Много студентов которые могут быть потрясающими в программировании, креативными, но при этом не развиваться в институтской (школьной) среде.

Существует огромный спрос на программистов, даже несмотря на общий уровень безработицы, так-что обучение программированию быстро вознаграждается.
Онлайн фриланс бирижи наподобии oDesk и Elance нанимают начинающих программистов по рейтам $15-20 за час и более.
Обучению программированию это один из лучших путей к предпринимательству. Программирование также доставляет студентам удовольствие творчества и мастерства.
Программирование однажды станет базовым профессиональным навыком — наподобие отправки электронной почты или «профессиональное владение Word-ом».
Молодые люди также готовы это изучать: программирование сейчас бренд. Парень который пишет под iPhone или Android, сегодня заполучает девчонку (ну или мальчика).

Есть даже возможность делать больше чем просто научится программировать — а стать элитным программистом, и для этого не обязательно идти в ВУЗ.
Мы сейчас на ранней стадии обучения программированию как профессии. Большинство академических курсов направлены на обучение студентов теории а не практике.
(В США только программа обучения колледжей из Лиги Плюща требует одного курса где студенты непосредственно пишут код.)
Представьте если студенты которые даже не смогли поступить в ВУЗ могут стать элитными программистами.

Для нас в США главной идеей развития является создание нового поколения учёных.
И это так и отражено в том как мы называем предмет программирования — компьютерная «наука» (computer science).
Мы можем сделать что-то другое (или в дополнение), обучая студентов быть ремесленниками, а не учёными: создать следующее поколение тех кто может хакать, творить, зарабатывать сразу, и возможно стать предпринимателями.
Обучение этому может сделать высшее образование более ценным, потому что это будет давать непосредственный результат.

Меня беспокоит эта идея уже несколько лет. Я считаю что это может стать тем путём, который поможет починить большинство того что сейчас не работает: наши способы обучения студентов, улучшить будущую экономику, сделать мир творческим и приносящим удовольствие.
Я уверен что здесь много тех кто работает над этим — если вы один из них, обратитесь ко мне и давайте найдём способ сделать общее дело.
И если вы считаете меня сумасшедшим, скажите почему.

© Roy Bahat


Не поленитесь, и почитайте ещё несколько очень важных моих статей для начинающих программистов, студентов и джуниоров.
Также не забудьте вступить в группу IT Juniors куда я пытаюсь собирать ссылки на другие полезные статьи для вас и анонсы курсов и интернатуры в компаниях.

[Перевод] Принципы хорошего программирования

Не самый лучший дизайн
Спустя многие годы я обнаружил что следующие относительно немногие фундаментальные принципы помогли мне стать более эффективным программистом.

Принципы хорошего программирования тесно связаны с принципами хорошего дизайна и техники. Следующие принципы программирования помогли мне с годами стать хорошим программистом, и я верю что помогут любому разработчику стать более эффективными и производить код, который проще в сопровождать и имеет меньше дефектов.

DRY (Don’t repeat yourself) Не делайте одну и ту же работу дважды

Наверное, самый фундаментальный принцип в программировании это избегать повторения. Многие программные конструкции существуют исключительно для этой цели (т.е. циклы, функции, классы и другие). Как только вы начнете повторять себя (например, длинное выражение, серия похожих выражений, похожие сущности) создавайте новые абстракции.

Принцип абстракции (Abstraction Principle)

Относящийся к DRY принцип абстракции: «Каждый значительный кусок функциональности в программе должны быть реализован в одном месте исходного кода».

KISS (Keep it simple, stupid!) Не усложняй, тупица


Упрощение (и избежание сложности) всегда должно быть ключевой целью. Простой код занимает меньше времени чтобы его написать, имеет меньше ошибок, и его легче изменить.

YAGNI (You aren’t going to need it) Вам это не понадобится

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

Делай сразу простейшую вещь, которая скорее всего заработает (Do the simplest thing that could possibly work)

Когда программируете сразу задайте себе вопрос: «Что является простейшей вещью, которая могла бы вот сразу заработать?». Это помогает удерживать нас на пути к простоте дизайна.

Не заставляйте меня напрягаться и думать (Don’t make me think)


Это на самом деле это название книги Стива Круга о веб-юзабилити и также имеет отношение к программированию. Дело в том, что код должен легко читаться и восприниматься с минимумом усилий. Если код вызывает затруднения чтобы его понять, то вероятно его стоит упростить.

Принцип Открытости/закрытости (Open/Closed Principle)

Программные Сущности (классы, модули, функции) должны быть открыты для расширения и закрыты для изменений. Другими словами, не следует писать классы, которые люди могут изменять, создавайте классы, которые люди могут расширять. Это означает, что новое поведение должно добавляться только добавлением новых сущностей, а не изменением старых.

Пишите код для сопровождающего (Write Code for the Maintainer)


Практически любой код, который стоит писать, предстоит поддерживать в будущем вам или кому-то другому. Будущем вы, когда вернётесь к коду обнаружите что большая его часть совершенно вам незнакома, так что старайтесь писать как будто для другого.

Программируй так, как если бы человек, который будет поддерживать твой код, будет брутальным психопатом и будет знать, где ты живёшь. © Martin Golding

Принцип наименьшего удивления (Principle of least astonishment) POLA


Принцип наименьшего удивления, как правило, используется в отношении пользовательского интерфейса, но тот же принцип применим и к написанию кода. Код должен удивлять читателя как можно меньше. Это означает, что нужно следовать соглашениям форматирования, код должен делать то что написано в комментариях и названии и потенциальных и побочных сюрпризов следует избегать, насколько это возможно.

Принцип единственной ответственности (Single Responsibility Principle)

Компонент кода (т.е. класс или функция) должен выполнять единственную хорошо определённую задачу.

Слабая связанность (Minimize Coupling)

Любая часть кода (код блока, функции, класса и т.д.) должна минимизировать зависимости от других частей кода. Это достигается за счет как можно меньшего использования общих переменных. Слабая связанность часто является признаком хорошо структурированной компьютерной системы и хорошей архитектуры, а в сочетании с высоким сцеплением, поддерживает главные цели высокой читаемости и удобства сопровождения.

Максимальное сцепление (Maximize Cohesion)

Код который имеет похожую функциональность должен находится в том же компоненте.

Скрытие деталей реализации (Hide Implementation Details)

Скрытие деталей реализации позволяет изменять реализацию код компонента с минимальными затрагиваением любых других модулей которые используют этот компонент.

Закон Деметры (Law of Demeter)

Компоненты кода должны взаимодействовать только с их непосредственными отношениями (например, классы от которых они унаследованы, объекты которые они содержат, объекты переданные с помощью аргументов и т.д.)

Избегайте преждевременной оптимизации (Avoid Premature Optimization)

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

Мы должны забыть про небольшие улучшения эффективности, скажем на протяжении 97% времени: преждевременная оптимизация — это корень всех бед. © Дональд Кнут

От переводчика:

Преждевременная оптимизация хуже преждевременной эякуляции. © namezys

Учтите, что зачастую оптимизацию ухудшает понятность системы. И перед оптимизацией я бы настоятельно рекомендовал выполнить рефакторинг.

Оптимизируйте только те части системы, которые действительно нуждаются в этом. Как правило это обработка больших массивов данных.

Определяйте такие фрагменты с помощью профайлеров — анализаторов производительности. Оценив с их помощью скорость работы на реальных данных вы можете обнаружить что самые казалось бы тяжёлые фрагменты системы могут особо не оказать негативного влияния на производительность системы, поскольку они выполняются пару раз всего за работу. В тоже время иногда неожиданно прозрачные фрагменты могут оказаться самыми затормаживающими работу.

Также профайлеры позволяют выполнить анализ покрытия кода (Code Coverage) — процесс выявления неиспользуемых участков кода при помощи, например, многократного запуска программы.

Повторное использование это хорошо (Code Reuse is Good)

Не очень содержательный, но тоже хороший принцип как и все другие. Переиспользование кода улучшает читаемость кода и уменьшает время разработки.

Разделение ответственности (Separation of Concerns, SoC)

Различные области функциональности должны управляться различными и минимально перекрывающимися модулями кода.

Обними изменения (Embrace Change)


Это заголовок книги Кента Бека, в которой рассматривается принципы экстремального программирования (XP) и методологии гибкой разработки (Agile) в целом. Многие другие принципы основаны на концепции, что вы должны ожидать и приветствовать изменения. На самом деле очень старые принципы разработки, вроде минимизации связанности, непосредственно предназначаются для более лёгкого изменения кода. Даже если вы не приверженец экстремального программирования этот подход к написанию кода не теряет смысла.

От переводчика: и ещё один очень важный принцип не упомянутый автором

В объектно-ориентированом дизайне обязателен SOLID: аббревиатура из первых букв названий приниципов, часть которых уже описана в этой статье:

Single responsibility principle Принцип единой разделения ответственности
Open/closed principle Принцип открытости/закрытости
Liskov Substitution Principle Принцип подстановки Лисков
Interface segregation principle Принцип изоляции интерфейса
Dependency Inversion Principle Принцип инверсии зависимостей

© Christopher Diggins

UPD
Посмотрите ещё на отличные мотиваторы с этими приницпами для программистов.