Секрет швидкого програмування: не замислюйтесь



Програмувати швидко — це легко! Так вважає інженер-програміст компанії Google, який всі публікації в своєму блозі підписує лаконічним «Макс». Макс також працює головним архітектором, ком'юніті-менеджером і реліз-менеджером в Bugzilla Project. Ми в Alconost вразили і перевели його поради про те, чи як навчитися програмувати з космічною швидкістю.

Якщо обговорювати з розробниками складність коду, вони часто говорять, що хочуть писати простий код, але із-за тиску дедлайнів і більш глибинних причин у них не вистачає часу або знань для того, щоб виконати завдання і оптимізувати рішення до максимальної простоти.

Вони, звичайно, мають рацію в тому, що в умовах стислих термінів розробники, як правило, будуть писати складний код. Втім, дедлайни не повинні призводити до складності. Замість фрази «Цей дедлайн завадив мені написати простий код» можна вимовити рівноцінну: «Я недостатньо швидко програмують, щоб писати просто». Тобто чим швидше ви як програміст — тим менше впливу на якість вашого коду мають дедлайни.

Тепер давайте розберемося, як, власне, стати швидше? Може, це вроджене магічне вміння? Треба бути «розумнішими» інших, щоб бути швидким?

Ні, це взагалі не магія і не вроджений дар. Насправді існує лише одне просте правило, рахуючись з яким, з часом ви вирішите проблему:

Читати далі →

Один з простих способів поліпшити свої навички програмування — читати чужий код

Примітка: спочатку ця стаття була написана для сайту Fuel Your Coding back у травні 2010 року. На жаль, цей сайт зараз не працює, тому я публікую статтю тут, щоб зберегти її для нащадків. Я збирався оновити її, враховуючи останні віяння, але вирішив залишити так, як вона була написана. Ті частини, що застаріли, можуть здатися трохи смішними, але да ладно. Отримуйте задоволення…

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

Якщо ви бажаєте різко підняти ваше вміння програмувати, необхідно… читати код, написаний іншими програмістами.

Ви можете вірити, можете не вірити. Ваше право. Але якщо ви готові ризикнути, то, впевнений, ви будете винагороджені за витрачений час.

У цій статті я хотів би допомогти вам у виборі того, що саме читати, і дати практичні поради щодо такого читання. Якщо ви вже читаєте інші програми, то, може бути, ви знайдете тут що-небудь, що дозволить отримати більше від ваших зусиль. Якщо ж ви не читаєте коди інших розробників, то ви просто зобов'язані зайнятися цим.

Читати далі →

Йдемо на рекорд: п'ята перевірка Chromium


Здавалося б, Chromium був розглянутий нами неодноразово. Уважний читач здасться логічним питанням: «Навіщо потрібна ще одна перевірка? Хіба було недостатньо?». Безперечно, код Chromium відрізняється чистотою, ніж ми переконувалися кожен раз при перевірці, проте помилки неминуче продовжують виявлятися. Повторні перевірки добре демонструють, що чим частіше буде застосовуватися статичний аналіз, тим краще. Добре, якщо проект перевіряється кожен день. Ще краще, якщо аналізатор використовується програмістами безпосередньо при роботі (автоматичний аналіз зміненого коду).

Читати далі →

Мистецтво написання простих і коротких функцій

Софт постійно ускладнюється. Стабільність і простота розширення програми безпосередньо залежать від якості коду.
На жаль, майже кожен розробник, і я в тому числі, у своїй роботі стикається з кодом поганої якості. І це — болото. У такого коду є токсичні ознаки:
  • Опції занадто довгі, і на них занадто багато завдань
  • Часто функцій є побічні ефекти, які складно визначити, а іноді навіть складно налагоджувати
  • Незрозумілі імена у функцій і змінних
  • Крихкий код: невелика модифікація несподівано ламає інші компоненти програми
  • Погане покриття коду тестами або взагалі його відсутність
Всім знайомі висловлювання «я не розумію, як працює цей код», «маревний код», «цей код складно змінити» та інші.
Одного разу мій колега звільнився, бо намагався впоратися з REST API на Ruby, який було важко підтримувати. Він отримав цей проект від попередньої команди розробників.
Виправлення поточних помилок створювало нові, додавання нових функцій породжувало нову серію помилок, і так далі (крихкий код). Клієнт не хотів перебудовувати додаток, робити йому зручну структуру, і розробник прийняв правильне рішення — звільнитися.

Такі ситуації трапляються часто, і це сумно. Але що робити?
Читати далі →

Залишимо пил з глобуса: перевіряємо проект NASA World Wind

PVS-Studio and NASA World WindІноді корисно озирнутися і подивитися, як міг допомогти аналізатор в старих проектах, і яких помилок можна своєчасно уникнути, якщо використовувати аналізатор регулярно. Цього разу вибір припав на проект NASA World Wind, який до 2007 року розроблявся на мові C#.

NASA World Wind — це інтерактивний глобус, який дозволяє побачити будь-яке місце на Землі. Для роботи проект використовує базу публічних знімків з супутника Landsat і проект моделювання рельєфу Shuttle Radar Topography Mission. Перші версії проекту створювалися на мові С#. Пізніше проект продовжив свій розвиток на мові Java. Остання випущена на C# версія — 1.4. Хоча C# версія вже багато років як покинута, це не завадить нам перевірити проект і оцінити якість коду, розробником якого є NASA Ames Research Center.

Навіщо ми перевірили старий проект? Нам давно пропонували перевірити щось з проектів NASA і ось ми випадково натрапили на цей проект. Так, ця перевірка не принесе ніякої користі проекту. Але такої мети в цей раз ми і не ставили. Ми просто хотіли, щоб у черговий раз продемонструвати користь, яку може приносити статичний аналізатор коду PVS-Studio при розробці, в тому числі і компанії NASA.


Читати далі →

Статичний аналіз коду

John Carmack
Примітка від перекладача. Спочатку ця стаття була опублікована на сайті AltDevBlogADay. Але сайт, на жаль, припинив своє існування. Більше року ця стаття залишалася недоступною читачам. Ми звернулися до Джону Кармаку, і він сказав, що не проти, щоб ми розмістили цю статтю на нашому сайті. Що ми із задоволенням і зробили. З оригіналом статті можна ознайомитися, скориставшись Wayback Machine — Internet Archive: Static Code Analysis.

Оскільки всі статті на нашому сайті представлені російською та англійською мовою, то ми виконали переклад статті Static Code Analysis на російську мову. А заодно вирішили опублікувати її на Хабре. Тут вже публікувався переказ цієї статті. Але впевнений, багатьом буде цікаво прочитати саме переклад.


Найголовнішим своїм досягненням в якості програміста за останні роки я вважаю знайомство з методикою статичного аналізу коду та її активне застосування. Справа навіть не стільки в сотнях серйозних помилок, не допущених в код завдяки їй, скільки в зміні, викликаної цим досвідом в моєму программистском світогляді щодо питань надійності та якості програмного забезпечення.

Читати далі →

Забезпечення якості коду в масштабних проектах



Коли восени 2012 року я прийшов у Airbnb, то тут м'яко кажучи, був деякий розбрід і хитання. Деякий час тому компанія почала рости і розвиватися величезними темпами. В першу чергу це виражалося в обсягах трафіку і транзакцій. Щоб справлятися з усім цим, дуже швидко і збільшили штат розробників. За рік до мого приходу в групі було 16 чоловік, зі мною було близько 40, а зараз вже понад 130. І однієї з головних проблем, викликаної усіма цими процесами, стало збереження якості коду в стрімко зростаючому і усложняющемся проекті.

Читати далі →

10 найпоширеніших помилок, які роблять новачки в Java

Доброго дня, мене звуть Олександр Акбашев, я Lead QA Engineer в проекті Skyforge. А також за сумісництвом асистент tully Технопарку на курсі «Поглиблене програмування на Java. Наш курс йде у другому семестрі Технопарку, і ми отримуємо студентів, які закінчили курси по C++ і Python. Тому я давно хотів підготувати матеріал, присвячений найпоширенішим помилок новачків в Java. На жаль, написати таку статтю я так і не зібрався. На щастя, таку статтю написав наш співвітчизник — Михайло Селіванов, правда, англійською. Нижче представлений переклад цієї статті з невеликими коментарями. По всіх зауважень, пов'язаних з перекладом, прошу писати в особисті повідомлення.



Спочатку мова Java створювався для інтерактивного телебачення, проте з часом став використовуватися скрізь, де тільки можна. Його розробники керувалися принципами об'єктно-орієнтованого програмування, відмовившись від зайвої складності, властивої тим же С і С++. Платформонезалежність віртуальної машини Java сформувала свого часу новий підхід до програмування. Додайте до цього плавну криву навчання і гасло «Напиши одного разу, запускай скрізь», що майже завжди відповідає істині. Але все-таки помилки досі зустрічаються, і тут я хотів би розібрати найбільш поширені з них.

Читати далі →

Якість коду Open Source вперше превзошло якість коду пропрієтарних проектів на C / C + +

  Вчора організація The Linux Foundation оголосила про запуск проекту Core Infrastructure Initiative (CII) для фінансової підтримки бідуючих Open Source проектів на кшталт OpenSSL, який в останні роки жив на пожертви $ 2000 на рік.
 
В офіційному прес-релізі The Linux Foundation підкреслює, що необхідність фінансової підтримки зовсім не пов'язана з низькою якістю коду OSS, зовсім навпаки. Вільне ПЗ перевершує пропріетарний софт за якістю коду і по безпеці. На підтвердження цього The Linux Foundation послалася на останнє дослідження Coverity Open Scan , результати якого опубліковані 15 квітня, через тиждень після публікації інформації про баге Heartbleed.
 
Зрозуміло, що момент для публікації обраний виключно невдалий. Всі тільки й обговорювали, як такий баг потрапив у відкритий код і як запобігти такому в майбутньому. Відповіді досі немає. Можливо, мільйони доларів від CII допоможуть вирішити проблему.
 
У цій ситуації важливо розуміти, що якість коду СПО дійсно об'єктивно перевершує якість коду пропрієтарного софта. Умовно кажучи, якби код OpenSSL не було відкрито, ми могли взагалі ніколи не дізнатися про цю уразливість.
 
Читати далі →