avl

97 вещей, которые должен знать каждый программист.

Оригинал лежит вот тут.

Уже переведенные мной статьи.

Из 97 вошедших в книгу:

1. Будьте предусмотрительны
2. Применяйте принципы функционального программирования
3. Наблюдайте за пользователями
4. Автоматизируйте стандарт кодирования
5. Красота и простота
6. Перед началом рефакторинга
7. Осторожнее с повторным использованием!
8. Правило туриста
9. Подозреваете ошибку в компиляторе? Проверьте получше свой код!
10. Осторожно выбирайте внешние модули
11. Программируйте на языке предметной области
12. Программирование - это дизайн.
13. Разметка кода важна!
14. Делайте ревью кода.
15. Программируйте осознанно.
16. О комментариях.
17. Комментируйте лишь то, что не ясно из кода
18. Непрерывное обучение
...
34. Удовлетворяйте свои амбиции на проектах open source

Из остальных:

49. Ограничивайте изменения состояний
55. Спешка убивает

Продолжение - примерно по одной главе в день :)

Текст оригиналов выложен под лицензией Creative Commons Attribution 3. C переводами можете поступать так же :)

97 вещей, которые должен знать каждый архитектор ПО

Оригинал лежит вот тут: 97 Things Every Software Architect Should Know

К сожалению, near-time решило чего-то непонятное замутить с переименованием себя в strategy nets, в результате чего доступа к оригиналам этой серии не стало. Пока переводы приостанавливаются (вдруг оригиналы таки где-то еще появятся).

Переведено: 56 из 97.

И да, ссылки на оригиналы, конечно же, работать перестали.

( Индекс 56 переведенных заметок )

Они же на моем сайте avl2.info

Текст оригиналов выложен под лицензией Creative Commons Attribution 3. C переводами можете поступать так же :)

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

А почему оно такое, и что с этим можно сделать?

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

( Прочитать о тренинге подробнее )

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

(В оригинале - )

Мы живем в интересное время. Как только разработка ПО распространилась по всему земному шару, многим стало понятно, что в мире полно людей, способных делать их работу. И необходимо все время обучаться, чтобы представлять ценность на рынке. Иначе вы постепенно превратитесь в динозавра, «прилипшего» к своей работе, пока в один прекрасный день ваши услуги больше не будут нужны или же вашу работу переложат на более дешевый outsource.

И что же с этим делать? Некоторые работодатели достаточно щедры, чтобы оплачивать обучение сотрудников, другие могут не иметь достаточно ресурсов для этого. Вам потребуется взять ответственность за свое обучение в свои руки.

Вот список возможных для образования способов. Часть из них полностью бесплатна при наличии интернета.

• Читайте книги, журналы, блоги, твиттер и различные сайты. Если захотите «копнуть глубже», то подпишитесь на рассылку.
  
• Если захотите реально погрузиться в технологию – напишите какой-нибудь код.
  
• Старайтесь найти ментора, поскольку если вам не на кого равняться, это может сильно замедлить ваше обучение. Наиболее эффективно учиться у кого-то, кто имеет больше опыта или в чем-то лучше вас. Если не найдете ментора, все равно двигайтесь вперед сами.
  
• Не игнорируйте виртуальных менторов. Найдите в интернете авторов и программистов, на кого бы вы хотели равняться, и читайте все, что они напишут.
  
• Изучите фреймворки и библиотеки, используемые вами для работы. Если вы знаете, как оно работает, вы сможете это использовать гораздо эффективнее. Если вы имеете дело с open source, то считайте, что вам повезло – берите отладчик и шаг за шагом исследуйте, что там происходит внутри. Вы столкнетесь с кодом, написанным и проверенным очень способными людьми.
  
• Когда вы сделали что-то не так, исправляете ошибку или сталкиваетесь с проблемой, старайтесь всегда выяснить, что именно произошло. Очень вероятно, что такое уже случалось, и кто-то уже опубликовал решение. Надо только погуглить.
  
• Лучший способ чему-нибудь научиться – это научить кого-нибудь еще. Когда вас будет слушать много людей, а потом задавать вам вопросы, у вас будет отличная мотивация это выучить очень хорошо.
  
• Присоединитесь к сообществу (или откройте свое), где изучается язык, технология или предмет, интересный для вас.
  
• Участвуйте в конференциях. Если нет возможности посещать их вживую, то многие из них выкладывают часть материалов онлайн. Долгая дорога на работу? Слушайте подкасты!
  
• Запускали когда-нибудь статический анализатор кода? Или хотя бы обращали внимание на warning-и в вашем IDE? Разберитесь, что они означают и почему появляются.
  
• Изучайте по новому языку программирования в год. Или хотя бы по новой технологии или инструменту. Это даст вам новые идеи, полезные в вашей текущей работе.
  
• Не обязательно изучать лишь технологии. Углубитесь в предметную область, с которой вы работаете, чтобы лучше понимать требования и находить решения проблем. Изучение того, как повысить свою производительность – еще одна очень полезная вещь, которую не стоит игнорировать.
  
  Было бы замечательно, если бы люди имели такую возможность, как у Нео в «Матрице» - загружать необходимые знания непосредственно в мозг. Но увы, для этого потребуется время. Не стоит, конечно, тратить на обучение все свое свободное время, но стоит делать это регулярно. Немного времени раз в неделю – сильно лучше, чем вообще ничего. Оставьте себе и другую жизнь, кроме работы.
  
  Технологии меняются быстро. Не останьтесь позади!
  
  Автор оригинала -
  
  Перевод мой, при использовании ссылка на мой живой журнал обязательна!

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

А подтолкнуло к принятию решения таки взять и сделать то, что давно хотелось, а не просто абстрактно хотеть, книга Стива Павлины "Personal development for smart people". Серия переводов заметок о программировании - тоже кстати после нее стартовала. Так что советую, кому интересно развитие, но при этом что-то мешает.

(В оригинале - A Comment on Comments)

На самых первых курсах программирования в колледже преподаватель однажды выдал по два бланка «Программа на Basic», написал на доске «Напишите программу, подсчитывающую среднее значение 10 игр в боулинг» и вышел из класса. Было ли это сложно? Я уже не помню деталей, но скорее всего, там был цикл и не более 15 строчек кода. Бланки (да-да, нам приходилось сначала писать программы на бумажных бланках перед тем как вводить их в компьютеры) позволяли написать до 70 строк кода. Мне было непонятно, зачем был нужен второй. Поскольку с аккуратностью у меня были проблемы, я переписал программу на второй бланк максимально аккуратно, надеясь получить дополнительные баллы.

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

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

Комментарии – это такой же необходимый элемент в программировании, как например условия или циклы. Многие современные языки программирования даже имеют инструмент, позволяющий из специально отформатированных комментариев сгенерировать API документацию. Это очень неплохо, но все же недостаточно. Внутри самого кода должны быть комментарии, объясняющие, что этот код делает. Программирование в стиле «То, что было сложно написать, должно быть не менее сложно прочесть» навредит всем – вашему заказчику, вашему работодателю, коллегам в команде и вам самому в ближайшем будущем.

С другой стороны, не стоит заходить слишком далеко, комментируя все подряд. Комментарии должны прояснять ваш код, а не загромождать его. Лишь немного «сбрызните» код комментариями, объясняющими сложные места. «Заголовочные» комментарии должны предоставлять любому программисту достаточно информации о том, как использовать ваш код, вообще в него не заглядывая. А «внутренние» комментарии должны помочь следующему за вами разработчику сопровождать и изменять ваш код.

На одной своей работе я был несогласен с архитектурным решением, принятым наверху. Испытывая раздражение, часто присущее молодым программистам, я вставил кусок письма с указанием использовать требуемое решение непосредственно в «шапку» файла. Оказалось, что менеджеры просматривали изменения перед каждым коммитом. Так я познакомился со значением термина «действие, ограничивающее карьерный рост».

Автор оригинала - Cal Evans

Перевод мой, при использовании ссылка на мой живой журнал обязательна!

(В оригинале - Coding with Reason

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

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

Секции должны подбираться так, чтобы в конце каждой из них «состояние программы» (значение всех «живых» на данный момент объектов) удовлетворяло легко формулируемому критерию, а функциональность этой секции бы легко описывалась одной задачей. Такие состояния конечных точек обобщают концепции вроде пред- и пост-условий для функций и инвариант (тела) для циклов и классов. Старайтесь, чтобы секции были как можно более независимыми друг от друга.

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

• Избегайте операторов goto, поскольку они делают удаленные друг от друга секции сильно связанными.
  
• Избегайте изменяемых глобальных переменных, поскольку они делают секции, их использующие, зависимыми.
  
• Каждая переменная должна иметь минимально возможную область видимости. Например, локальный объект может создаваться непосредственно перед его использованием.
  
• Делайте объекты неизменяемыми там, где только это возможно.
  
• Делайте код легко читаемым используя пробелы, как по горизонтали, так и по вертикали. Например, выравнивайте зависимые структуры и разделяйте секции пустыми строками.
  
• Делайте код самодокументируемым, выбирая «говорящие» имена, при этом не слишком длинные.
  
• Если вам нужна вложенная секция, сделайте ее функцией.
  
• Делайте функции короткими и сфокусированными на единственной задаче. Старое ограничение на 24 строки все еще актуально. Хотя разрешение экрана сильно выросло, способность человека воспринимать информацию осталась той же.
  
• Функции должны иметь ограниченное число параметров (скажем, максимум четыре). Заметьте, это не накладывает ограничение на объем данных, которые можно передать. Просто сгруппируйте данные в объект и передавайте его, заодно обеспечив когерентность и связность этих данных.
  
• Каждый модуль должен иметь минимально возможный интерфейс. Меньше коммуникаций – меньше потребуется аргументов для доказательства правильности. К примеру, “getter”, возвращающий внутренние данные объекта – потенциальный источник проблем. Вместо запрашивания у объекта данных, чтобы потом что-то с ней сделать, пусть эту работу со своей информацией делает сам объект. Другими словами, инкапсуляция – лучшее средство для «сужения» интерфейса.
  
• Для защиты инвариантности объектов “setter”-методы не должны поощряться, поскольку они легко позволяют нарушить инвариантность.
  

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

Автор оригинала - Yechiel Kimchi

Перевод мой, при использовании ссылка на мой живой журнал обязательна!

(В оригинале - Code Reviews)

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

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

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

Будьте мягкими во время просмотра. Обеспечьте, чтобы замечания были конструктивными, не едкими. Представьте различные роли просмотра, чтобы избежать влияния иерархической структуры команды на процесс ревью кода. Примеры ролей – просмотр документации, просмотр системы исключений, просмотр функциональности. Такой подход позволяет распределить груз ревью кода по всем членам команды.

Выделите отдельный «день просмотра кода» в неделю. Тратьте пару часов на обсуждения просмотра. Обеспечьте равномерную ротацию ролей просматривающих. Меняйте роли на каждом обсуждении ревью. Вовлекайте в просмотр новичков. У них может не быть достаточно опыта, но при этом у них будет «свежий взгляд», что тоже имеет свою ценность. Вовлекайте в процесс экспертов. Они смогут быстрее и точнее найти проблемные места. Процесс просмотра будет идти быстрее, если в команде будет установленный стиль кодирования, проверяемый автоматически. Тогда обсуждение стиля не будет выноситься на обсуждения.

Самый главный залог успеха – сделать процесс просмотра привлекательным. Если процесс создает проблемы или вызывает негатив, то будет сложно кого-либо мотивировать его проводить. Сделайте его неформальным. Сделайте основной целью просмотра распределение знаний между членами команды. Вместо сарказма старайтесь быть позитивными.

Автор оригинала - Mattias Karlsson

Перевод мой, при использовании ссылка на мой живой журнал обязательна!

(В оригинале - Code Layout Matters)

Когда-то очень давно я работал над системой, написанной на Cobol, в которой программисты не могли менять идентацию, если только у них не было причин для реального изменения кода. Такое ограничение было введено потому, что когда-то кто-то чего-то сломал, неправильно изменив идентацию и тем самым внеся строку в одну из специальных колонок вначале. Это правило работало даже в случае неправильной идентации, что иногда случалось. И в результате при чтении кода приходилось быть внимательным, потому что идентации нельзя было доверять.

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

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

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

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

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

Автор оригинала - Steve Freeman

Перевод мой, при использовании ссылка на мой живой журнал обязательна!

(В оригинале - Code Is Design)

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

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

Возможность прогнозировать сроки практически исчезнет. Стоимость строительства гораздо проще расчитать, чем стоимость дизайна. Мы примерно знаем, сколько стоит один кирпич, и сколько кирпичей нам понадобится. Если же предсказуемая часть задачи будет стремиться к нулю, на первый план выйдет непредсказуемая – дизайн. Результаты будут получаться быстрее, но за практически непредсказуемое время.

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

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

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

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

Автор оригинала - Ryan Brush

Перевод мой, при использовании ссылка на мой живой журнал обязательна!

(В оригинале - Code in the Language of the Domain)

Представьте себе два исходных кода. В первом вы видите что-то подобное:

if (portfolioIdsByTraderId.get(trader.getId()).containsKey(portfolio.getId())) {...}

Вы чешете затылок, пытаясь догадаться, что может делать этот код. Выглядит как взятие ID из объекта trader и использование его для получения другого ID, после чего – поиск еще одного ID из объекта portfolio… Почесывание затылка почему-то не помогает. Вы ищете определение portfolioIdsByTraderId и находите следующее:

Map< int, Map< int, int>> portfolioIdsByTraderId;

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

А в другом исходном коде вы находите вот такую строчку:

if (trader.canView(portfolio)) {...}

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

А теперь скажите, с каким кодом вы бы предпочли работать?

Когда-то давно были только простые структуры данных: биты, байты и символы (на самом деле те же байты, но нам больше нравилось считать их буквами, цифрами и знаками). С числами было уже чуть сложнее – наша десятичная система не очень хорошо «ложилась» на двоичную, и поэтому было несколько различных типов с плавающей запятой. Потом появились массивы и строки (на самом деле такие же массивы). Потом – стеки, очереди, хеши, связанные списки и другие замечательные структуры, не существующие в реальном мире. И «программируя», мы тратили значительную часть ресурсов на то, чтобы поставить в соответствие объекты из реального мира и эти достаточно ограниченные структуры данных. Настоящие же гуру могли даже запомнить то, как именно они это сделали.

Потом появились типы, определенные пользователем! Это серьезно изменило правила игры. Если в вашей области есть сущности «трейдер» и «портфолио», то вы можете смоделировать их при помощи типов данных с именами Trader и Portfolio. Но еще более важно то, что вы можете моделировать отношения между ними, тоже используя термины из предметной области.

Если вы программируете, не используя термины предметной области, то тем самым вы создаете тайное знание о том, что например вот этот int означает идентификатор трейдера, а вот этот – идентификатор портфолио. (И лучше их не перепутать!). А если вы представляете какую-либо концепцию («Некоторые трейдеры не могут просматривать отдельные портфолио») при помощи алгоритма, подобного поиску соответствия в таблице идентификаторов, то вы не даете тем, кому придется с этим разбираться, вообще никакой подсказки.

Программист, пришедший за вами, не будет иметь того тайного знания, которое имели вы. Так зачем делать его тайным? Использовать ключ для поиска другого ключа, используемого для проверки наличия соответствия – не самый распространенный прием. Каким образом кто-то должен догадаться о том, какое именно правило из предметной области тут скрыто?

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

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

Автор оригинала - Dan North

Перевод мой, при использовании ссылка на мой живой журнал обязательна!

(В оригинале - Choose Your Tools with Care)

Современные приложения редко пишутся с нуля. Они собираются из уже существующих «кирпичиков» - компонент, библиотек и фреймворков. Делается это из-за следующих причин:

• 
  Приложения все сильнее растут в размерах, сложности и функциональности, а времени на разработку выделяется все меньше. Такой подход позволяет снизить время разработки и сконцентрироваться на написании бизнес-ориентированной части кода, а не на написание инфраструктурной части.
  
• 
  Распространенные компоненты скорее всего содержат меньше ошибок, чем разработанные самостоятельно с нуля.
  
• 
  В интернете есть много качественных программ с открытым кодом, доступных бесплатно, что также снижает расходы на разработку и повышает шансы найти разработчиков с требуемыми знаниями.
  
• 
  Разработка и сопровождение ПО – достаточно ресурсозатратное дело, поэтому может быть дешевле купить готовое решение.
  

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

• 
  Различные инструменты могут иметь различные требования к контексту использования – инфраструктуре, модели управления, модели данных, протоколам коммуникации, что может привести к несоответствию между разными инструментами. Такое несоответствие приводит к различным хакам и обходным путям, что вносит излишнее усложнение в код.
  
• 
  Разные компоненты могут иметь различный жизненный цикл, и обновление одного из них может оказаться крайне сложной задачей из-за того, что новая функциональность или даже исправление ошибки может оказаться несовместимым с остальными компонентами. И чем больше компонент используется, тем сложнее.
  
• 
  Некоторые инструменты требуют значительных объемов конфигурации, часто в виде XML файлов, и эти файлы конфигурации могут выйти из под контроля очень быстро. В результате приложение будет выглядеть написанным на XML с небольшим количеством вставок кода на другом языке. Сложность конфигурирования может сделать приложение сложным для сопровождения и модификации.
  
• 
  При сильной зависимости от решений какого-либо производителя проблемы могут начаться в ситуации, когда производитель что-нибудь изменит: возможность поддержки, производительность, цену или что-нибудь еще.
  
• 
  Если вы решите использовать бесплатное ПО, может оказаться, что оно совсем не бесплатное. Возможно, придется оплачивать коммерческую поддержку или коммерческую лицензию. Например, может оказаться неприемлемым использование ПО под бесплатной лицензией GNU, потому что результат нужно будет распространять под такой же лицензией GNU, с открытым исходным кодом.
  

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

Автор оригинала - Giovanni Asproni

Перевод мой, при использовании ссылка на мой живой журнал обязательна!

Афиша детского спектакля:



Да, если что, то словенское "sraka" - это всего лишь русское "сорока" :)

Взято у todash_tahken

(В оригинале - Check Your Code First before Looking to Blame Others

Все разработчики часто склонны не верить, что ошибка в их коде, обвиняя вместо этого, например, компилятор.

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

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

Если инструмент широко распространен и используется множеством людей в различных ситуациях, то причин сомневаться в его качестве очень мало. Конечно, если инструмент еще в стадии раннего релиза, используется лишь несколькими людьми в мире, имеет версию 0.1 или же относится к редко скачиваемому open source, то основания для подозрений могут быть гораздо более весомыми. То же самое справедливо и для альфа-версий известных коммерческих продуктов.

Взяв за основу то, что ошибки в компиляторах – очень большая редкость, вы сможете гораздо эффективнее тратить свое время на поиски ошибок у себя вместо попыток доказать, что виноват компилятор. Применяйте все обычные практики отладки: изолируйте проблему, отслеживайте вызовы, окружайте ее тестами, проверяйте соглашение о вызовах, общие библиотеки и версии, расскажите о проблеме кому-нибудь еще, проверьте переполнение и повреждение стека, запустите код на разных машинах и с разными конфигурациями сборки (debug и release).

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

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

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

Так что перед тем, как обвинить компилятор, вспомните правило Шерлока Холмса: «После того, как вы исключили невозможное, то все, что осталось, независимо от того, насколько невероятным оно выглядит, является истиной», и отдавайте предпочтение именно ему, а не правилу Дирка Джентли «Посл того, как вы исключили невероятное, все, что осталось, независимо от того, насколько невозможным оно выглядит, является истиной».

Автор оригинала - Allan Kelly

Перевод мой, при использовании ссылка на мой живой журнал обязательна!

Спустя много лет от начала моей программистской карьеры довелось погрузиться и в главное средство разработки микрософтовской платформы - visual studio. Достался в наследство проект, сопровождать и менять который теперь надо мне.

Понимаю, что описанная ниже ошибка - результат "хорошо" написанного проекта, но тем не менее user-friendly интерфейс от микрософта эта ошибка демонстрирует как нельзя лучше.

Итак, есть продукт, написанный на visual studio c++ 2005, в нем есть файл с ресурсами. При внесении изменений в этот файл и попытке сохранить его выдается сообщение "Cannot load external resource file". Вот так, дословно. Какой именно файл оно не может загрузить и чего это вдруг при нажатии на кнопку Save оно хочет чего-то грузить, я должен догадаться сам.

Но это еще не все. Несмотря на высокоинформативное окно, сохранение в этот раз все же происходит. А вот если еще раз поменять этот файл, то теперь при попытке его сохранить выдается уже ошибка "Cannot save file. (skipped).rc". О причине того, какого хера оно не может его сохранить, я опять же, должен догадываться.

А до тех пор, пока не догадался, приходится после каждого изменения файла с ресурсами закрывать visual studio и открывать его заново.

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

Вот такая вот дружелюбная платформа. Не Freescale Codewarrior конечно, но вполне в микрософтовском стиле :)

И да, порадовал еще способ, которым visual studio предлагает мне смотреть в дебаге массивы и области памяти. Спобоб этот единственный - в столбик по одному элементу. Неужели пишущим под винду никогда не надо видеть область памяти в старом добром hex режиме, по 16 байт в строке, разделенных пробелами, и адресом в начале строки?

Второй раз за зиму в Словению пришла зима :)

Обнаружил сегодня ссылку на свои переводы, что не могло не порадовать :)

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

И несмотря на это, все равно очень много общего :) Так что рекомендую!

(В оригинале - The Boy Scout Rule

У настоящих туристов есть правило: «Всегда оставляй место стоянки чище, чем оно было до вас». Если стоянка загажена, вы ее очищаете независимо от того, кто ее загадил до вас. Тем самым вы обеспечиваете приятное окружение следующей группе туристов. В оригинале это правило, сформулированное основоположником движения скаутов Робертом Стивенсоном Смитом Баден-Пауэлом, звучало так: «Старайтесь оставить этот мир чуть лучше, чем он был до вашего прихода»

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

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

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

Откровенно говоря, это должно стать правилом приличия, как мытье рук после туалета или выбрасывание мусора в урну, а не куда попало. Написание «мусорного» кода должно быть столь же неприемлемым, чем-то таким, чего никто не делает.

Но есть еще одно «но». Кроме заботы о своем собственном коде, нужно еще заботиться и коде всей команды. Команда должна помогать друг другу, в том числе и убирать мусор друг за другом. Следование правилу настоящего туриста выгодно всем!

Автор оригинала - Uncle Bob

Перевод мой, при использовании ссылка на мой живой журнал обязательна!

(В оригинале - Beware the Share)

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

Как же это было возможно? Ведь везде говорили, что повторное использование – одна из основных вещей профессиональной разработки! Все статьи, которые я читал, все книги, все профессионалы, обучавшие меня – все говорили именно так! Где же была ошибка?

Оказалось, я пропустил одну критическую вещь.

Контекст.

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

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

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

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

Будьте осторожны с повторным использованием. Сначала проанализируйте контекст, и только потом реализуйте.

Автор оригинала - Udi Dahan

Перевод мой, при использовании ссылка на мой живой журнал обязательна!

(В оригинале - Before You Refactor)

В какой-то момент каждому программисту приходится делать рефакторинг уже написанного кода. Но перед тем, как начинать рефакторинг, подумайте над нижеприведенными пунктами – это сохранит вам много времени и избавит от множества проблем.

• 
  Лучше всего реструктуризацию начать с подробной ревизии существующего кода и тестовых сценариев для этого кода. Это поможет вам выявить сильные и слабые стороны существующего решения, чтобы потом оставить удачные моменты и избежать проблемных мест. Все мы часто думаем, что сможем написать лучше, чем уже написано... до тех пор пока не получаем в итоге что-то, гораздо худшее, чем предыдущая реализация, потому что мы ничему не научились на опыте и ошибках существующей системы.
  
• 
  Избегайте намерения переписать все. Лучше стараться повторно использовать как можно больше уже написанного кода. Неважно, каким бы ужасным он не был, он уже оттестирован, просмотрен и прочее. Выбросить старый код, особенно если система уже «в поле», означает выбросить месяцы или даже годы, потраченные на оттестированный и прошедший проверку «в поле» код, имеющий при этом какие-то исправления, о которых вы не знаете. Без информации об этих «подводных камнях» может получиться так, что ваш переписанный код будет содержать те же «мистические» ошибки, которые уже были исправлены в старом коде. Это приведет к серьезным потерям времени, усилий и знаний, собираемых долгое время до этого.
  
• 
  Несколько последовательных изменений лучше, чем одно большое. Небольшие изменения позволяют легче отслеживать воздействие на систему, например, при помощи тестов. Ничего приятного в том, чтобы после исправления обнаружить сотню провалившихся тестов. Это может вызвать раздражение и как следствие, принятие не самого лучшего решения. Тогда как пара-тройка провалившихся тестов легко укажет на источник проблемы.
  
• 
  После каждой итерации важно убедиться, что все существующие тесты все еще проходят. Добавьте новые тесты, если существующие недостаточно покрывают изменяемый вами кода. Не выбрасывайте старые тесты без основательного анализа. На первый взгляд тесты могут казаться незначительными и неважными для вас, но может оказаться полезным копнуть глубже, чтобы понять, зачем же они были добавлены.
  
• 
  Личные предпочтения и эго не должны быть ведущим фактором. Если что-то работает, зачем это исправлять? То, что стиль или структура не соответствует вашим персональным предпочтениям, недостаточно для начала реструктуризации. Мысль о том, что вы можете написать лучше, чем ваш предшественник, тоже не является достаточной причиной.
  
• 
  Новая технология также недостаточна для рефакторинга. Одна из худших причин переписать код – это то, что существующий код находится «в стороне» от сегодняшних «прикольных» технологий, и мы уверены, что новый язык или фреймворк могут сделать то же самое гораздо более элегантно. Если только анализ не покажет, что новый язык или платформа действительно не приведут к значительному улучшению функциональности, сопровождаемости или производительности, обеспечив при этом финансовый выигрыш, то лучше рефакторинг не начинать.
  
• 
  Помните, что люди ошибаются. Реструктуризация не гарантирует, что новый код получится лучше (или хотя бы таким же), чем предыдущая версия. Я участвовал в нескольких неудачных попытках реструктуризации. Это не было приятно, но это было по-человечески.
  

Автор оригинала - Rajith Attapattu

Перевод мой, при использовании ссылка на мой живой журнал обязательна!