Archive for the ‘Код и программистское’ Category

Но ведь если оно не работает — оно не будут работать.

Четверг, Февраль 19th, 2009

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

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

Однако со временем, я заметил, что собственно говоря любую вещь, которые хоть насколько то сложнее средней  он начинает обсуждать с фразы «А что, если оно в __каких-то__ случаях не работает?». Резонный ответный вопрос -«В каких например?». В ответ им выдается, дай бог, один какой-нибудь жутко редкий необычный случай, который сложно даже проверить.

Собственно говоря нервирует

— Критика методов, не конструктивная. То есть, чаще всего не предлагается лучший метод

— В случае когда метод лучший предлагается, то он чаще всего гораздо дольше по времени исполнения, при этом очень мало уменьшает вероятность проблем

И самое главное, что меня убивает — это аргумент «Но ведь если там есть ошибка — оно не будет работать.» Ну, ясен пень, работать оно не будет. Поэтому ошибка и называется ошибкой.

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

Cкруммное

Четверг, Октябрь 23rd, 2008

Тут я последнее время, немножко с Scrumm’ом поработал.

Что мне понравилось, очень логичная и правильная система Backlog’а и Sprint’ов. Логично, записываем все задачи, выставляем им приоритеты, набираем задач на месяц с наибольшим приоритетом и делаем.

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

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

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

Ацпект.

Четверг, Сентябрь 25th, 2008

Сижу вот я на завалинке, читаю книжку про аспектное программирование. Блин, умные же люди бывают. И придумается им такое.

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

Так вот, возвращаясь к умным людям. Они, что же придумали. Что можно описать в отдельном файле что-нибудь типа — в начале всех функций класса A, и функций x,y класса B — делать проверочку прав и только если она прошла то вызывать саму функцию. Выходит, что и овцы целы (классы продолжают делать, что им положены) и волки сыты (авторизацию проводим).

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

Тем не менее, думаю, что это действительно следующий шаг за ООП. Хотя он конечно, призван не заменить, а дополнить его.

Интересно вообще, какого граница декомпозиции и компактности языков программирования? Думаю вопрос на самом деле не корректный, но тем не менее…

Просто, по большему счету фактически все развитие языков идет по следующему циклу

а. Решаем задачу

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

в. Изобретаем новые методы, решаем этими методами проблему из б)

г. Увеличиваем размер задач.  Переходим на пункт а)

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

Вот такая, вот сборка мыслей по поводу аспектного программирования.

Так что, очень рекомендую почитать что-то по этому поводу. Прекрасно прочищает мозги.

Кстати, у меня есть стандартный вопрос на собеседование — «Чем вам НЕ нравиться язык X (вставить нужное)?».Похоже, добавлю в свой список вопрос — «Чем вам НЕ нравиться ООП»? Вот будет забавно поглядеть, как люди буду дергаться и нервничать.

Категоризация программистов.

Среда, Сентябрь 17th, 2008

Не программист — тот кто вообще не может решить проблему (написанием кода).

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

Средний программист — это тот, кто уже может решить проблему. Но, со временем, его решение обрастает соплями и ведет к большей проблеме (но уже на длительном промежутке времени).

Хороший программист — тот кто решает проблему и заодно предвидит/предотвращает будущие возможные проблемы.

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