Ссати менше щороку? [зачинено]

Ссання рідше щороку - Джефф Етвуд

Я натрапив на цю проникливу статтю. Цитую прямо з поста

Я часто думав, що всмоктування менше щороку - це те, як поліпшуються скромні програмісти. Ви повинні бути незадоволені кодом, який ви написали рік тому. Якщо ви цього не зробите, це означає, що або A) ви нічого не дізналися за рік, B) код не вдається покращити, або C) ви ніколи не переглядаєте старий код. Все це - поцілунок смерті для розробників програмного забезпечення.

1. Як часто це трапляється чи не трапляється з вами?
2. Як довго ви побачите фактичне поліпшення кодування? місяць, рік?
3. Ви коли-небудь переглядаєте свій старий код?
4. Як часто ваш старий код нападає на вас? або як часто вам доводиться мати справу зі своїм технічним боргом.

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

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

• Це трапляється?
• Якщо так, скільки років після кодування на певній мові можна очікувати, що це станеться?

Пов'язані:

Колись озирнувся на якийсь свій старий код і гримасив від болю?

Момент " Зоряних воєн" в коді "Люк! Я твій код!" "Ні! Неможливо! Не може бути!"

  > Sucking Less Every Year ?

Ні , але смоктання різні Щороку :-)

Після моїх перших оглядів багато років тому я страждав від зниклих конвенцій про називання.

Тоді я постраждав, що моє кодування було (непотрібно) реалізовано максимально загальним, але це зробило код нечітким для розуміння та підтримки.

Тоді я спробував розробити тест-драйв, InversionOfControl, що дотиків чистих дженериків, де та багато іншого.

висновок

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

Цікаво, що всі програмісти "рок-зірки", з якими я коли-небудь працював, були надзвичайно скромними, прагнули вчитися та готові визнати, що вони не знають усе. Чорт забирай, багато насправді відверто самознижуються, принаймні у легкі моменти.

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

Наступні пункти - це не поради, а особистий журнал:

• використовуючи меншу кількість глобальних змінних
• не використовуйте абревіатуру для змінних чи імен функцій
• написати [деякі] коди тестування
• не судіть код як повільний (або швидкий) без порівняльної оцінки
• Дізнайтеся, як завантажити тест на додаток
• не виправляйте це, якщо він не зламався
• використовувати інструмент управління вихідним кодом (git / hg)
• рефакторинг - це круто, не варто недооцінювати вартість тестування, яке він приносить
• безпеку важко, тому остерігайтеся цього якомога раніше
• виправити деякі помилки з відкритим кодом проекту
• блог щось нове
• зручність використання може бути не запитом, але це важливо

Я не навчився все протягом року, все вимагає часу ...

Часто люди думають, що хороший код несподівано трапляється, але для більшості з нас просто смертних хороший код зростає в нашій кодовій базі. Я маю на увазі, що дуже важко написати ідеальний фрагмент програмного забезпечення з самого початку, оскільки вимоги постійно змінюються, і ми не є досконалими програмістами, не так вже й дурні рішення приймаються постійно від менеджерів і програмістів. Тоді я бачу, що кожна вимога змінює гарну можливість перетворити частину старого коду на кращий код (і за нього заплатити!) Та погасити трохи технічної заборгованості. Як кажуть: "залишайте сховище коду трохи краще щоразу, коли ви вводите код". Тоді ваша система перетвориться на більш наближену до ідеальної систему.

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

Крім того, якщо ви прочитаєте книгу "Чистий код", тоді ви збільшите свій власний код "коефіцієнт висмоктування" в кілька разів. : D

Я фактично маю для цього обидві сторони монети.

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

З іншого боку, ви помічаєте особливо елегантне рішення проблеми, і не можете не випустити самовдоволеної усмішки, наскільки ви розумні були тоді.

А потім ви прокручуєте вниз пару рядків і з жахом гримасуєтесь від того, що використовували GOTO в C.

Хм ... Я часто досить приємно здивований тим, наскільки добре багато мого старшого коду.

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

1. Як часто це трапляється чи не трапляється з вами?

2. Як довго ви побачите фактичне поліпшення кодування? місяць, рік?

3. Ви коли-небудь переглядаєте свій старий код?

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

1. Кожен раз, коли я дізнаюся щось нове, сподіваюся, це буденність.

2. Якщо мені вдасться реалізувати те, що я навчився, то це негайно з моменту його реалізації.

3. Так, корисні можуть бути лише для (1) нових функцій, (2) виправлення помилок, (3) ностальгії, (4) дивіться, як я щось вирішив.

4. Пов’язаний з 1., коли я вчуся робити щось краще, я усвідомлюю, що деякі старі проекти "могли" зробити краще. Я залишаю їх бути. Просто переконайтеся, що наступний проект зроблений кращим чином. Я не хвилююся, якщо це не справжня помилка.

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

"в моєму випадку тривалість життя - один рік. Це означає, що я можу змінити код, який я написав півроку тому, але якщо код був написаний два роки тому, він має великі шанси бути кинутим, а потім переписати повністю, оскільки це просто занадто сильно смокче ».

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

Щоб відповісти на ваше друге запитання про тривалість життя, це дуже різниться. Викинутий фрагмент коду має тривалість життя нульових секунд : він смокче відразу після того, як ви його написали, але це не має значення. Деякі фрагменти коду я написав були терпимими після двох років , але необхідні деякі косметичні зміни: трохи рефакторінга, забезпечення дотримання правил StyleCop і т.д. У середньому, в моєму випадку точного, тривалість життя коливається від восьми місяців до одного року для C # і від двох півроку до PHP.

Чи варто переглянути свій старий код? Так, звичайно, як і кожен розробник, якщо ви не дбаєте про DRY і винаходити власне колесо знову і знову. Також ви можете дуже часто переглядати та вдосконалювати код, якщо у вас є спільна база даних коду, яку ви використовуєте в багатьох проектах . Ще один момент полягає в тому, що якщо ви працюєте над величезними проектами, на деякі можуть знадобитися роки , тож вам доведеться переглянути старий код.

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

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

Навіть якщо у вас є двадцятирічний досвід роботи в комп'ютерах / програмуванні, справи змінюються занадто швидко, тому завжди є нові речі, які слід вивчити, і нові методи вдосконалення коду. Наприклад, код C #, написаний тоді, коли не було .NET Framework 3.0, дуже ймовірно, можна зробити більш читабельним і кращим з новими речами, які ми маємо сьогодні (включаючи Linq, контракти з кодом тощо), і це, навіть якщо старий код був написаний найрозумнішим розробником.

Це трапляється досить регулярно, коли я дивлюся на код і цікавлюсь: "Що я думав, коли це писав?"

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

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

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

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

1.Як часто це трапляється чи не трапляється з вами?

Як часто я незадоволений своїм старим кодом? Майже завжди. Є рідкісні винятки, де у мене є код, яким я дуже пишаюся ... але знову ж таки, вони рідкісні. Мені сказали, що код, який я написав пару років тому, був гарним ... Я притупився і подумав, що "ти, бідна бідна людина, що бачив гірше, ніж сміття, яке я написав".

2.Скільки задовго до того, як побачите фактичне поліпшення кодування? місяць, рік?

Це, як правило, поетапно ... Я дійсно вживаюсь у стиль чи методологію (наприклад, візьмімо вільні інтерфейси ... тому що це був останній стиль, для якого у мене був величезний мокрий), і розфасовувати все, що я пишу на місяць-чотири . Тоді воно починає виглядати краще.

3. Ви коли-небудь переглядали свій старий код?

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

4.Як часто ваш старий код вас напав? або як часто вам доводиться мати справу зі своїм технічним боргом.

Будучи тим, що попередні роботодавці мають більшу частину мого старого коду, і я білим стираю більшість свого особистого коду ... не дуже часто.