Перед...

Перед началом очередного проекта
Перед добавлением нового функционала
Перед улучшением работающего кода

Плохой программист

Наверное, многим знакома ситуация, когда, взглянув на чей-то код, думаешь "$%#... как можно так писать?!" Тут даже рефакторить бесполезно! Выкинуть бы да переписать с нуля! А бывало ли так, что вы сами оказывались по ту сторону баррикад? Что кто-то смотрел на ваш код, и в глазах ревизора читался ужас :)?

А как вы сами относитесь к коду, написанному вами же, полгода, год, два года назад? Кажется ли применённый подход и найденное решение таким же правильным? Или как-то так?

Лично я считаю такую реакцию вполне нормальной и, даже, правильной.

Полгода (не говоря уже о том, что целый год), - это большой отрезок времени. Это целых 182 дня = 4368 часа, из которых 2912 часа человек бодрствует (при расчете, что на сон уходит 8 часов). Достаточно ли 2912 часов, чтобы узнать хоть что-нибудь новое и полезное для себя?

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

Программист на Фортране может написать программу на Фортране на любом языке программирования.
Ed Post, 1983

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

It is possible that you are a bad programmer. You'll never know until someone better sees it.
(c) Scott Hanselman

И пусть этим someone better будете вы сами :)

Шило на мыло или вопрос об эмиграции

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

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

Принципы Эмерсона

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

Размышления о пиратстве

Вместо введения

 

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

Мотивация

Да, эта статья, именно, о мотивации. Нет, это не очередные  «стопицот способов замотивироваться». И не очередное тыканье пирамидой Маслоу (хотя с неё, наверное, стоило бы начать, ведь именно потребности являются основными двигателями). Все мы знаем свои потребности – именно те недостающие детали мозаики наших поступков, объясняющие всё – и на них останавливаться не будем.  

 Есть цель, определяющаяся потребностями, есть дорога к цели, состоящая, например, из тасков в проекте или материалов к экзамену, и есть мотивация, которая и заставляет нас, двигатель, работать. Но порой двигатель глохнет. Вроде и дорога не ухабистая, вроде и ехать не далеко, а вот не едется. То ли бензин закончился, то ли бак вообще не заправляли, то ли слил кто-то весь бензин. Бывало? У всех бывало. И не раз. Ведь слабая мотивация занимает третье место в перечне причин, препятствующих росту бизнеса*. 

Размышления о качестве

Читаю Э.Голдрат "Цель. Процесс непрерывного совершенствования". Долго откладывала эту книгу в сторону, но пришло и её время. Действительно, хорошая книга. Хоть и не it-тематики, но точки соприкосновения есть. Почитать эту книгу полезно всем, не только управленцам.

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

Это далеко не новость. Но что такое качественный продукт? Первое, что приходит в голову, это программа без ошибок, т.е. тщательно оттестированный функционал, когда пользователь не переживает, что, ткнув не туда, можно завалить программу. Всю качественность функционала может затмить интерфейс, который не позволяет использовать продукт на все 100%. Т.е. интерфейс тоже должен быть качественным, продуманным, позволяя пользователю не тратить много времени на освоение. Это всё? Нет. Бек-сайд продукта - это код. И качественный код != код без багов. Качественный код - это совокупность характеристик, где одно из первых мест занимает качественная архитектура, позволяющая легко и безболезненно развивать продукт. Это тестируемость (testability) кода как подтверждение качества архитектуры.
И, конечно же, качественный продукт в состоянии выпустить только здоровая команда! (Однако обратное выражение не всегда верно) О влиянии отношений внутри команды на продукт была хорошая цитата тут

Здоровые отношения в группе разработки вносят непосредственный вклад в архитектуру системы. Нездоровые отношения и гипертрофированные самомнения порождают нездоровые продукты.

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

8 советов

Сегодня попались мне две статьи о том, как улучшить свой код. В сумме это дало 8 советов.

Рефакторинг - не панацея

Недавно мне попалась фраза

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

А так ли это? Попахивает  фанатизмом.

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

О колбасе :)

Понравился анекдот о колбасе и яйцах :)

Жена посылает мужа-программиста в магазин:
- Дорогой, купи, пожалуйста, палку колбасы, и если будут яйца, то купи десяток.
Через полчаса программист возвращается с десятью палками колбасы.
Жена:
- Что это?! Зачем ты купил столько колбасы?
Программист:
- Ну так яйца-то были...

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

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

Из-за чего получаются такие ошибки? Как они закрадываются в спецификации? Есть несколько ответов на эти вопросы: от банального не доглядели до несогласованности требований. Всем известно, что требования в процессе разработки меняются, и после каждого изменения или дополнения нужно проверять, не получилось ли так, что часть новых требований не согласуется со старыми. Так же есть такие факторы, как взаимонепонимание и "требования по умолчанию". Разработчики, которые не являются специалистами в предметной области разрабатываемого продукта, могут не знать некоторых деталей, а для заказчика (или эксперта, учавствующего в разработке спецификации) данные детали являются делом обыденным, само собой разумеющимся. "Требования по умолчанию" - это опасные требования. Их даже может и не быть в спецификации, потому что это "само собой разумеющиеся" вещи, о них просто забывают. А для разработчиков эти вещи далеко не очевидны, так же как и для обычного человека не очевидно то, что для разработчика ясно как 0 и 1.

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