Привет! Сегодня я хочу поделиться советами по написанию совершенного понятного кода, взятые из книги Питера Гудлифа «Ремесло программиста // Практика написания хорошего кода».

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

Предисловие

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

Тут другое дело. PHP не просто неудобен в использовании, плохо мне подходит, субоптимален или не соответствует моим религиозным убеждениям. Я могу рассказать вам много хороших вещей о языках, которых я стараюсь избегать, и много плохих вещей о языках, которые мне нравятся. Вперёд, спрашивайте! Получаются интересные обсуждения.

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

PHP — препятствие, отрава моего ремесла. Я схожу с ума от того, насколько он сломан и насколько воспеваем каждым уполномоченным любителем нежелающим научиться чему-либо ещё. У него ничтожно мало оправдывающих положительных качеств и я бы хотел забыть, что он вообще существует.

Это перевод первой части цикла из четырех статей о разработке и производстве физических продуктов. Автор, источник: Ben Einstein.

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

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

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

Эту статью я хочу посвятить временами нелегкой, но увлекательной профессии ИТ-аналитика. На Хабре не так много материалов по данной дисциплине. К примеру, по управлению проектами – на порядок больше. Но выложенные недавно две статьи (раз и два), похоже, вызвали интерес, посему я тоже хотел бы внести свой скромный вклад. Сам работаю более 8 лет в роли аналитика, так что постараюсь не потратить Ваше время зря.
Не стану пересказывать теорию (ее можно почерпнуть в замечательной книге Вигерса или в BABOK). Мне бы хотелось сосредоточиться на практической стороне вопроса – описать выжимку из «боевого» опыта, как своего, так и некоторых других людей, с которыми мне посчастливилось работать.

Обсуждая с различными людьми — в большинстве своём опытными разработчиками — классический труд «Приёмы объектно-ориентированного проектирования. Паттерны проектирования» Гаммы, Хелма и др., я с изумлением встретил полное непонимание одного из базовых подходов ООП — различия классов и интерфейсов.

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

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

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

В недавнем проекте с Qt пришлось разбираться с классом QThread. В результате вышел на «правильную» технологию работы c QThread, которую буду использовать в других проектах.

Данный пост представляет собой выдержку «золотых правил» из примечательной книги Питера Гудлифа «Ремесло программиста».

Кто-то освежит память, кто-то сверится как с чек-листом, а кто-то заинтересуется и прочтет книгу. Т.к. пост получился достаточно объемным, можно добавить его в закладки и периодически к нему возвращаться.

Содержание

• 1. Введение
  
  • 1.1. Правки
• 2. Несколько причин, почему SQLite не использует Git
  
  • 2.1. Git затрудняет поиск потомков после коммита
  • 2.2. Ментальная модель Git излишне сложна
  • 2.3. Git не отслеживает исторические названия ветвей
  • 2.4. Git требует дополнительной административной поддержки
  • 2.5. Git неудобен в использовании
• 3. Руководство пользователя Git по доступу к исходному коду SQLite
  
  • 3.1. Зеркала на GitHub
  • 3.2. Доступ через веб
  • 3.3. Доступ через Fossil
• 4. Дополнительно

1. Введение

SQLite не использует Git. Вместо этого у нас работает система управления версиями Fossil, специально разработанная и написанная для поддержки SQLite.

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

Для шифрования в SQLite были найдены следующие возможные решения:

• SEE — официальная реализация.
• wxSQLite — c++ wxWidgets обертка для шифрования SQLite.
• SQLCipher — использует в реализации openSSL.
• SQLiteCrypt — модифицированная реализация API.
• botansqlite3 — шифрующий кодек для SQLite3 использующий библиотеку botan.
• SQLiteCrypto — java API для Android, использует AES-256 и SHA-256.
• QtCipherSqlitePlugin — SQL плагин для Qt с поддержкой шифрования.

Из рассмотренных решений SEE, SQLiteCrypt and SQLiteCrypto требуют приобретения лицензии. SQLCipher доступен в версии Community Edition, но требует libcrypto.

Наиболее интересным решением из представленного списка, на мой взгляд, является QtCipherSqlitePlugin.
Плагин шифрует «на лету» и полностью интегрирован в API Qt.

Добрый день.

Ниже пойдет речь о том, как использовать SQLite в Qt. Автор постарался как можно подробнее рассматривать программирование баз данных в Qt.

Об этих двух замечательных продуктах можно прочитать следуя приведенным выше ссылкам, а мы будем конкретно рассматривать программирование БД в Qt, в частности, на примере SQLite. Скажу только, что SQLite несколько отличается от «обычных» баз данных, таких как MySQL тем, что «не обладает» клиент-серверной архитектурой. То есть движок БД не является отдельно работающим процессом, с которым взаимодействует программа. SQLite представляет собой библиотеку, с которой компонуется ваша программа и, таким образом, движок становится составной частью программы. То есть представьте вы решили сохранять все данные, с которыми «сталкивается» ваша программа в обычный файл. В один прекрасный день вы решаете сохранять данные в файле, но организовав это с «реляционной» точки зрения. После этого вы поняли, что новая структура файла должна «распознаваться особым образом». С этого, как минимум, следует, что вам нужно предоставить некоторый API, обеспечивающий связь между этим файлом данных с приложением. В общем, следуя логической постановке приведенного сценария у вас рождается система БД, не требующая сервера БД и собственно, клиента. Получается достаточно быстрая по сравнению с «клиент-серверной» БД система, и сама программа упрощается.

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

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

На самом деле, мало кто действительно понимает, как работают реляционные БД. А многие разработчики очень не любят, когда они чего-то не понимают. Если реляционные БД используют порядка 40 лет, значит тому есть причина. РБД — штука очень интересная, поскольку в ее основе лежат полезные и широко используемые понятия. Если вы хотели бы разобраться в том, как работают РБД, то эта статья для вас.

Вступление

Добрый день, уважаемые читатели! Совсем недавно я завершил разработку одного своего приложения на Qt, и мне захотелось создать профессиональную программу установки, чтобы всё было «как у взрослых». Как оказалось, сделать это непросто, учитывая, что на официальном сайте инструментария информации по развёртыванию почти нет. В данной статье рассмотрены некоторые этапы подготовки программ на Qt версии 5.2 или выше для распространения на компьютеры других пользователей. Итак, вот план руководства:

1. Подготовка проекта Qt к развёртыванию
2. Компоновка дистрибутива программы
3. Подписание кода и создание установщика

Не будем терять времени и приступим к работе.

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

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

Теперь давайте посмотрим, как поступит в этом случае типичный джуниор. Есть задача – её надо решить. Их так учили в университетах. Многие из них ещё находятся под влиянием маргинального лозунга «пиши код, б##дь!». Итак, он наливает себе растворимого кофе, надевает наушники с чем-нибудь пожёстче и погромче и уходит в поток на пару-тройку часов.

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

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

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

Первая часть, представленная ниже, посвящена классам, объектам и интерфейсам.
Вторая часть иллюстрирует инкапсуляцию, полиморфизм и наследование

Вступление

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

Не знаю, на каком языке программирования вы пишете, но уверен, что используете Гит при разработке. Инструментов для сопровождения разработки становится всё больше, но даже самый маленький тестовый проект, я неизменно начинаю с команды git init. А в течение рабочего дня набираю в среднем ещё 80 команд, обращаясь к этой системе контроля версий.

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

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

Кому будет полезна эта статья?

Вы уже освоили джентльменский набор Гита и готовы двигаться дальше? Существует 2 пути:

1. Освоить сокращённые команды – алиасы. Они почти всегда составлены мнемонически и легко запоминаются. Забыть оригиналы команд проблематично, я легко их набираю, когда это требуется. Плюс не сбиваюсь с мысли, проверяя что-то в Гите в процессе написания кода.
2. Узнать о дополнительных флагах к командам, а также их объединении между собой. Я понимаю, что кто-то ненавидит сокращения. Для вас тоже есть интересный материал в статье – как повысить полезность и удобство вывода команд, а также как решать не самые тривиальные, но часто встречающиеся на практике задачи.

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

Добро пожаловать под кат!

Часть 1. Линейные структуры

Массив

Когда вам нужен один объект, вы создаёте один объект. Когда нужно несколько объектов, тогда есть несколько вариантов на выбор. Я видел, как многие новички в коде пишут что-то типа такого:

// Таблица рекордов
int score1 = 0;
int score2 = 0;
int score3 = 0;
int score4 = 0;
int score5 = 0;

Это даёт нам значение пяти рекордов. Этот способ неплохо работает, пока вам не потребуется пятьдесят или сто объектов. Вместо создания отдельных объектов можно использовать массив.

// Таблица рекордов
const int NUM_HIGH_SCORES = 5;
int highScore[NUM_HIGH_SCORES] = {0};

Будет создан буфер из 5 элементов, вот такой:



Заметьте, что индекс массива начинается с нуля. Если в массиве пять элементов, то они будут иметь индексы от нуля до четырёх.

Перевод статьи Random numbers широко известного в узких кругах Джона Скита. Остановился на этой статье, так как в своё время сам столкнулся с описываемой в ней проблемой.

---

Просматривая темы по .NET и C# на сайте StackOverflow, можно увидеть бесчисленное множество вопросов с упоминанием слова «random», в которых, по сути, поднимается один и тот же извечный и «неубиваемый» вопрос: почему генератор случайных чисел System.Random «не работает» и как это «исправить». Данная статья посвящена рассмотрению данной проблемы и способов её решения.