Скобочки для if в одну строчку

(DRAFT)

Здесь расскажу про такое заблуждение как обрамление фигурными скобочками оператор if с одним простым действием.

if(condition)
{
        return 0;
}

вместо

if(condition)
        return 0;

Мифическая причина идущая от Стива Макконнела (Code Complete). К ней все обращаются, когда начинают мне её называть. Такое ощущение, что это единственная книга, которую горячие стороники скобочек читали :) Кстати, советую тогда заглянуть на http://agileconsulting.ru/wiki/Books - тут множество книг о качестве кода.
1. Защита от дурака, что кто-то в будущем добавит строчку и сделает баг в программе.

А теперь демистификация скобок. Итак, почему скобки это пережиток:
1. Отступы явно указывают на логический блок из одной строки.
2. Отступы проставляются автоматически средой разработки.
3. Тесты не дадут написать код неправильно. У вас нету тестов? Тогда улучшать качество кода начали не от туда :)
4. Скобки кушают 2 линии
5. Мы бизнес-разработчики, и должны свести к минимум все инженерные ухищрения. Ведь в любом языке фраза: "если наступит утро, то я проснусь" не содержит скобок.

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

Если вы используете современную IDE и TDD и утверждаете, что скобки полезны по названой мифической причине - просьба дайте конкретный пример. Иначе рассуждаем о коне в ваккууме.

Вебкасты про Agile

http://www.autumnofagile.net/
http://www.summerofnhibernate.com/

«Agile по-крупному!» — ВИДЕО

Во вторник, 21 апреля, прошла аннонсированная ранее встреча сообщества AgileRussia.ru, озаглавленная «Agile по-крупному!». Изначально тема заявлялась, как разбор сложностей Agile в крупных командах и проектах, обсуждение тонкостей масштабирования, ведь все, что выходит за максимальный размер стандартной Agile-команды в 9 человек, уже требует специальных подходов.

«Waterfall2Agile — Agile для Большой Waterfall компании: нужен? как и что внедрять?» — это пришли ребята из широкоизвестной компании «C», они детально описали свой цикл разработки и структуру проектного управления своего Большого Продукта (достаточно заметить, что цикл тестирования релиза занимал у них 18 месяцев), пояснили возникающие проблемы, и запросили у сообщества предложений по улучшению процесса — включая как Agile-практики, так и технические/инструментальные решения.





«AgilePostmortem» — это была посмертная ретроспектива распределенного Agile-проекта, интересного высокотехнологичного стартапа, к сожалению, «не дожившего до весны».



Оригинал: http://team.custis.ru/2009/04/agile-agilerussiaru.html

Строки-ресурсы или магические строки (draft)

В продолжение предыдущего поста возникли логичные вопросы. А что делать с
String.Format(StringResourse.TotalString, total)? Кстати, вам легко понять это? А я ещё не начал перечислять минусы :)

Итак, начну с переносом строк в ресурсы. Начнём сначала. Какой смысл был у строки? Если смысл кокатация строчек. То первичный вопрос - накой козе баян? Зачем делать форматирование строке "Всего: " + total + " штук"? А потом повышаем косвенность, закидывая строку "Всего: {0} штук" в ресурсы?

В отличии от string, StringBuilder, String.Format назначение ресурсов в предоставление вариационности. Вариационности в способе отображения, а для строк это либо другой язык, либо другая система отображения значений (пример: дата, дроби и т.п.). Вы часто имеете дело с мультикультурными приложениями? :) Да и там чуток по другому делают. Причем не на стадии программирования, а это свойство относится к всем процессу разработки. Другой нюанс - некоторое множество сообщений, которое на каждом углу программы используется. Некое постоянное магическое множество. Типа "Всего: {0} руб.". Тут ещё можно подумать. Но вредно. Для этого есть специальные классы. Которые должны сразу выплёвывать такие строчки и мы не должны волноваться как это получилось.

Другой сногсшибательный аргумент - если у вас есть технический редактор, и ему удобно работать с одним списком сообщений. Представляю я работу этого редактора. Вместо того, чтобы заранее написать текст, который он ожидает. Или с программистом договориться во время непосредственного написания кода. Он будет открывать файл ресурсов и не соображая, что за туча сообщений, править. Полностью оторвав от контекста применения. Кто нибудь так делает? Ух ты! Ну и как часто так делаете? Чаще чем пишете код? :)

А теперь какие бонусы мы получаем от такой системы (не для варианта мультикультурной платформы, а для нашей простой разработки)
Бонус 1. Попробуйте посчитать количество ваших действий, чтобы внести изменение в вашу строчку. Ужас на крыльях ночи. И это только ради того, чтобы внести маленькое исправление в строчку. Боюсь если вы уделяете столько внимания строчкам, то время на полезный код у вас не остаётся вообще :) Мне намного легче править то, что я вижу непосредственно.
Бонус 2. Даже если не менять. Чтобы читатель мог понял, что тут написано и что ожидается, вам прийдётся скакать как минимум по двум файлам. Кстати, поиск таких вещей и мест их потребления - это другая тема. А разговор идёт не об одной сущности, а просто об одной строчке кода. Да к тому же ещё среди кучи строчек вам нужно ещё вашу. Упасть не встать.
Бонус 3. Я молчу, насколько это эффективно программируется по сравнению с простой строчкой кода :)
Бонус 4. Нарушение ценностей и принципов Implementation Patterns и Simple Design.
Бонус 5. Программирование ради неопределенного будущего. Какой то технический

Задайте себе вопрос - что вы чаще меняете: кучу сообщений без привязки к месту использования или конкретное сообщение в конкретном коде. И из этого делайте вывод. Если вы днями программируете текст в ресурсном файле. То ресурс это ваше все. А если вы пишите код программы и добавляете в него сообщения - то вывод очевиден. Что данные (а строка это данные) должны быть в непосредственной близости от места потребления.

Следующий вопрос - Magic String. Звучит очень странно. Но давайте вернёмся к аналогии. У нас есть Magic Number. Пример: 12. Конечно, любой скажет, что нужно напрячься, причем очень сильно, чтобы найти СМЫСЛ этого. Поэтому СМЫСЛ мы заключаем в название переменной int interest = 12. Ещё раз подчеркиваю, чтобы не искать смысл числу 12 по крупицам в коде окружающем это значение мы вводим переменную, в название которой перенесли смысл числа. В нашем примере 12 означает interest (процент). Теперь взглянем на наши Magic String:

string errorMessage = "Произошла ошибка. Повторите операцию";

Вот скажите, а чего вам не понятно в исходном сообщение? Смысл? Там же по-русски написано :) Я понимаю, что фраза "@#$#@$^%$" может запутать и нужно ввести поясняющую переменную. Но в примере то чего сложного?

Теперь пошли нюансы Magic String:
Бонус 1. Переменная, у которой область видимости максимум круглые скобочки в качестве параметра вызова в MessageBox, почему то становиться видна всей нашей функции. Как будто без этого мало строчек кода.
Бонус 2. При чтение кода нам нужно прыгать сначала к тексту применения, а потом к определению. Хотите скачи - идите на ипподром.
Бонус 3. Некоторые умельцы ещё и форматирование туда запихивают. Мозг выносится напрочь, когда обнаруживается код типа:
string totalString = "Всего: {0} штук";
....
String.Format(totalString , total);

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

String vs StringBuilder

Сегодня в microsoft study-group обсуждали стринг. Собственно эта тема всех интервью - что нужно использовать для "оптимального" хранения строчек? И все хором говорят - используем StringBuilder. А на вопрос, что использовать для кокатации строк - String.Format. И все напрочь забывают, что мы программируем не для оптимизации, а для того, чтобы поддерживать код и развивать. То есть делать код понятным даже первокласснику, что не скажешь про "профессионально" оптимизированные без надобности куски творчества.

Так вот про вопросы интервью. Я с ними полностью не согласен. Люди! Не то чтобы на пороге 21 век, он уже дома! Преждевременная оптимизация - зло и порождает ДОРОГОСТОЯЩИЙ код! Качественный код приравнивается к самодокументируемому коду. Оптимизация здесь не рассматривается - она здесь не обсуждается. Так как мы бизнес-разработчики, а не любители оптимизнуть что под руку попадёт. Бизнес-разработчик пишет код, где каждая строчка отражает НАМЕРЕНИЕ, а не хитро-вычитанные фичи платформы :)

Начну развеивать заблуждение с конкатацией через String.Format. Цель функции String.Format форматирование строки, а не конкатация. То есть привращать 1 в 001,00 например. С точки зрения качественного программирования запись с целью конкатации String.Format("Total: {0} dollars", total); выглядит настолько неэкономично, что ужас. Конечно микроскопом можно гвозди забивать :) У некоторых это даже получается. Во-первых, чтобы понять это, нужно чтение слева-направа заменить на скачкообразное чтение с актвацией ячейки памяти в моём мозгу. Во-вторых, добавление новых переменных вызывает дополнительное напряжение - теряем время, за которое нам платят деньги. В-третьих, чтобы добавить новую переменную - мне нужно делать 2 (!!!!) изменения.

Исходя из этих соображений. А мои соображения основываются на принципах Implementation Patterns & Refactoring и трёх простых ценностях (коммуникация, простота и гибкость). В данном случае используем самую первую и самую важную ценность - коммуникация. Напомню: Коммуникация (communication) - разрабатываемый код должен явно отражать намерение создателя. Этот принцип подчёркивается и в рефакторинге. Так вот начиная читать строку String.Format - я чётко фиксирую себя на мысле "форматируем"!, а когда плюсиками - то конкатируем. Просто и разумно.

Ужасная конкатация через форматирование: String.Format("Total: {0} dollars", total);
Поэтому намного лучше и приятней: "Total: " + total + " dollars";
Хотя, перед PHP код снимаю шляпу: echo "Total: $total dollars";

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

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

Итак с точки зрения качественного кода (а это код, которых легко читать):
StringBuilder - вещь хорошая, но его стоит применять, когда мы подходим к объекту как механизму с накапливанием значения, а результат будет снят как сливки намного дальше от кода наполнения. То есть в одном месте явно накапливаем (сложный код... преимущественно бывает в циклах), а в другом вы забираете результат (особенно часто встречается со словом return ;).
String.Format - для форматирования кода, но не конкатации. Причем в отличие от String.Builder результат забирается в месте форматирования.
+ (любимый плюсик для строк) - приятный и дешевый способ конкатации

PS. "Экономично", "дорогостоящий" и "дешевый" читать с точки зрения разработки и поддержки. Меньше тратим время, чтобы "врубиться", значить дешевле. Время - деньги.
PS2. А оптимизация делается на заключительной стадии. Ключевое слово: профайлер.

Что такое Agile?

Часто задается вопрос, что такое Agile или XP. В чём ключевое отличие от других подходов. Ответ очень простой. Agile - это культура разработки, включает гармонично подобранные ценности, принципы и практики. Мета-методология, которая определяется входящими в неё методологиями. Эти вещи уже проверены по отдельности различными командами. Но в совокупности они порождают нечто большее. Синергию. Другие подходы ориентируются преимущественно на практики, иногда на принципы. Про ценности же забывают напрочь. То есть на то, что человека отличает от болтика.

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

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

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

Да... а для работы с ценностями можно использовать практику - Team Value Sync-up Practice, о которой я писал ранее.

Кстати, в тему цитата Кент Бека (link):

There is 3 legs on the stool: practices, values and principles and I think people who are successful applying XP are paying attention to all 3. This gets back a little bit to some of my disenchantment with the direction of agile development in general, people are now asking the question: "How am I going to do agile development?" and agile development isn't a thing you do, it's an attitude, it's a set of personal values about responding to the real world, being open to the information that is there and being willing to do something about it.

That is agility. Yes, there is a lot of practices that come out of that but to me that is where it starts, it's this attitude. If somebody understood a bunch of practices and tried to do them, you could do agile development without being agile and it's a disaster because you're acting out of harmony with what you really believe when you do that.

И в заключение: весь мир делится на два лагеря - 1) те кто работает в новом стиле и 2) те кто работает постаринке. Честно говоря я рад, что вторых больше. Потому что именно вторые оплачивают мою работу :)

Эмоциональный интеллект

Уже сложно найти сайт и специалиста в области менеджмента, которые не говорят о важностях эмоционального интеллекта применительно к проектной деятельности. Я спрашиваю их - а делать то чего? Разводят руками или начинают говорить о красивых абстракциях и грандиозных результатах. Но я опять не понимаю. Тогда говорят, это сложный вопрос, а тебе стоит найди правильного человека для своей команды, он чувствует это всё. А другие советуют почитать Кови или книгу о сабже, после этого ты и поймешь.

Мне кажется можно организовать все проще. Основная идея - потенциал команды складывается из ментальных и эмоциональных усилий команды. IQ + EQ. Если с IQ понятно, то вот как прокачивать EQ?

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

Исходные материалы для развития эмоционального интеллекта:



Делаем простой уголок, который потом будем ставить себе на стол. C одного листа А4 вырезается 5-6 полосок, таким образом получаем 5-6 уголоков с листа.



И в итоге получаем тренажёр для эмоционального интеллекта:



Вот и инструмент готов.

Как это работает? Перед тем как что-то делать, вы садитесь и чувство-думаете:
Я ЧУВСТВУЮ ________, ПОТОМУ ЧТО __________

Чувства: РАДОСТЬ, ГРУСТЬ, СТРАХ, РАЗДРАЖЕНИЕ. Других недопустимо. Важно объяснить себе, почему я это чувствую. Важно называть минимум 2 чувства. В "ПОТОМУ ЧТО" немного напрягшись нахожу причину своего чувства. Понимая причину, я повышаю осведомленность. Ибо только зрелые личности испытывают чувства и осознают причины их побудившие. Таким образом мы повышаем осведомленность как на уровне EQ, так и IQ. А дальше либо миримся с причинами, то есть забиваем на свою осведомленность, либо решаем возникшую проблему :)

Теперь о правилах. Они простые, как всё эффективное и работающее:

1. Перед каждой активностью говорить себе "Я чувствую..."
2. Минимум 2 чувства
3. Ставить уголки на стол, чтобы другие видели
4. Если кто-то интересуется "почему" - отвечать честно.
5. Запрещено врать и убирать под давлением.

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

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

Жду ваших отзывов о внедрение :)

Об этих и других практиках развития эмоционального интеллекта слушайте в подкасте Agile Study Group: ссылка сообщества Study Group.

PS. Практика называется "Вход" (Check-in). То есть я ментально и эмоционально вхожу в работу.

PS2. Alexander Lipatov: У меня в аське частенько раньше спрашивали что-то вроде Как дела? Как настроение? :) Я теперь отвечаю: я чувствую радость, что на улице хорошая погода и чувствую раздражение, потому, что на работе много мелких дел, которые никак не хотят заканчиваться