Software Quality

2021/04/03
2022/06/21 (增加連結)

簡介

軟體品質是個多面向的概念 (詳參: Software quality)，包括需求面、穩定性(reliability)、安全性 (security)、效率 (efficiency)、可維護性 (maintainability)，就CMMI的建議就是確保開發團隊依循品質管理的流程進行開發(Process Quality Assurance, PQA)，並透過Verification & Validation (VV)以及Peer Review (PR)來確保符合品質的要求。

需求面

滿足使用者的需求是最重要的品質，一般而言，管理的方式包含過程的管理及結果的管理。

過程的管理，就CMMI的建議就是必須有嚴謹的需求開發與管理的流程 (Requirement Development & Management, RDM)，確保正確的取得使用者的需求，並且當需求更動時，正確的更動相關的文件，更動也正確的落實，也就是Verification。

結果的管理通常是透過測試來達成，不過，測試有很多種類，與需求相關的測試通常稱為功能性測試。就CMMI的建議就是Validation。

穩定性(reliability)

軟體的穩定性也是可以透過過程的管理及結果的管理來達成。

過程的管理通常是透過制定程式碼的規範並進行人工的code review或自動化的code analysis工具。結果的管理則是透過測試工具進行負載測試，了解在特定負載下系統是否能穩定操作，也可以進行壓力測試，壓力測試的目的在於了解系統的最高可承載的壓力。

安全性 (security)

軟體的安全性也是可以透過過程的管理及結果的管理來達成。

安全性檢測可分為白箱檢測與黑箱檢測，白箱檢測通常是針對程式碼進行檢測，可以透過制定程式碼的安全規範並進行人工的code review或利用自動化的code analysis工具找出安全漏洞。黑箱檢測則是透過測試工具進行測試，了解在各種可能的攻擊下系統是否有效防禦。

• Code review

• 測試工具

• Code Analysis 利用動態或靜態分析工具找出安全漏洞

效率 (efficiency)

軟體的效率也是可以透過過程的管理及結果的管理來達成。

過程的管理通常是透過制定程式碼的規範並進行人工的code review或自動化的code analysis工具。結果的管理則是透過測試工具進行負載測試，了解在特定負載下系統的效率是否達到目標的回應速度。

• 測試工具

• Code Analysis 利用動態分析工具找出效率瓶頸

可維護性 (maintainability)

軟體的可維護性通常是透過制定程式碼的規範並進行人工的code review或自動化的code analysis工具。

• Code review

• Code Analysis 利用靜態分析工具找出不符合規範之程式碼

練習

• 討論一下，貴公司或團隊使用哪些方法? 使用的程度? 為什麼?

  • 貴公司或團隊進行code review嗎? code review基於任何標準或規範嗎? 進行的過程有沒有甚麼問題?

  • 貴公司或團隊進行code analysis嗎? code analysis基於任何標準或規範嗎? 進行的過程有沒有甚麼問題?

參考資料

• The Software Engineer’s Complete Guide to Code Quality **很不錯的簡介文章

  • What Is Code Quality?

  • Documentation, Code Standards, and Style Guides

  • The Importance of Code Reviews

  • Tools To Review Code Quality

  • Code Refactoring

  • Decreasing Technical Debt

    • Tools to Track and Manage Technical Debt

• Do you follow these 10 Principles for good Programmers?

  • KISS

  • DRY

  • OPEN/CLOSED

  • COMPOSITION > INHERITANCE

  • SINGLE RESPONSIBILITY

  • SEPARATION OF CONCERNS

  • YAGNI

  • AVOID PREMATURE OPTIMIZATION

  • REFACTOR, REFACTOR, REFACTOR

  • CLEAN CODE > CLEVER CODE

• How to Deliver Resilient, Secure, Efficient, and Easily Changed IT Systems in Line with CISQ Recommendations

• 8 Practices to Ensure Better Code Quality

  • Use Linter at IDE Level

  • Right Balance of Comments

  • Test Automation

  • Manual Code Review

  • Quality Gates

  • Periodic Due Diligence

  • Define Coding Standards

  • Vulnerability Scanning

• There Is No Benefit or Incentive for Developers to Create Quality Code on Software Projects

• Code Quality Automation: What’s Around the Corner?

• Do You Still Have QA Engineers on Your Team?

• PRs: Shift Left, Please (Part One) : Individuals and Interactions Matter When Reviewing Code

• PRs: Shift Left, Please (Part Two) : Realities of the PR Process

Clean Code

• The importance of Clean Code

• 無瑕的程式碼 Clean Code 心得分享 (投影片)

  • 第一章到第十二章 (跳掉第十一章)

• Clean code: 無瑕的程式碼 – 書摘心得（一）

• Clean code: 無瑕的程式碼 – 書摘心得（二）

• Summary of “Clean code”​ by Robert C. Martin

• 30 Coding Concepts I Learned After Reading “Clean Code”

• The Must-Know Clean Code Principles

• How to Write Clean Java Code

  • Structure

  • Naming

  • Solve a specific problem

  • Method parameters

  • Duplication

  • Hardcoding

  • Logs

• Clean Code: 5 Essential Takeaways

  • Programming Is a Craft

  • Keep It Short!

  • Make Code Self-Documenting

    • Tips for Writing Self-Documenting Code

      • Don’t use magic numbers

      • Use clear variable names

      • Refactor with tiny, named functions

      • Add useful test descriptions

      • Bottom line: readable over cleverable

    • The Ultimate Guide To Writing Self-Documenting Code

    • How to Write Self-Documenting Code

    • When Self-Documenting Code is Not Enough

  • Respect Abstraction

  • Clean Code Is About Principles and Hard Work

• How To Write Clean Code That Reduces Headaches. (2019)

  • What is in a Name.

  • Functions should do only one thing.

  • Comments do not make up for bad code.

  • Formatting Code is always a priority.

  • Write your “try-catch-finally” statement first.

• Excellent Code = Clean and Beautiful Code (2018)

  • “What is in a NAME”

    • Always remember, the name of any variable, function or class should answer three big questions; why it exists, what it does and what it is used.

  • “Functions should DO ONLY ONE THING.”

  • “Comments do not make up for bad code”

  • “Formatting Code is always a priority”

  • Write your “try-catch-finally” statement first

• The junior developer’s guide to writing super clean and readable code

  • Use consistent formatting & indentation

  • Use clear variable and method names

  • Use comments where necessary

  • Remember the DRY principle (Don’t Repeat Yourself)

• When DRY Doesn’t Work, Go WET

  • You need to remember: Duplication is far cheaper than the wrong abstraction.

  • After a while, you will know what your buttons will look like in the future. Then you can analyze the current codebase, find duplicated code in the button components, and move them to the good abstraction.

• Write Better Code with Coding Standards

  • Limited use of global variables

  • Follow naming conventions

  • Indentation

  • Do NOT write lengthy functions

  • Code should be well documented

  • Follow language specific conventions

• Simple tips on writing clean code

  • Later equals never

  • The Boy Scout Rule

  • Use Intention-Revealing Names

  • Avoid Disinformation

  • Make meaningful Distinctions

  • One word per concept

  • Use solution domain name

  • Use Problem domain name

  • Function should be small

  • Do one thing

  • Don’t always comment

• Write Clean Code With These 5 Simple Tips

  • KISS

  • Find the root cause of a problem

  • Meaningful names

  • You’ll need tests

  • Consistency

• Clean Code Principles for JavaScript

  • Variables

  • Functions

  • Objects and data structures

  • Classes

  • Testing

• Five behaviors of great R coders

  • Commenting

  • Formatting

  • Namespacing

  • Code efficiency

  • Clean up

• 6 Simple Habits to Adopt for Writing Cleaner, Readable Code

• Learning To Code By Writing Code Poems

• Coding With Intention

• Common Coding Mistakes You Should Avoid

  • Too Many Things Going On in One Function

  • Commented-Out Code

  • Non-Descriptive Naming of Variables

  • Magic Numbers and String

  • Messy Formatting of Code

  • Hard-Coding

• 10 Clean Coding Practices

  • Avoid poor naming

  • Follow correct naming conventions

  • Create proper method signatures

  • Keep function parameter count to a minimum

  • Declare variables at the place of use

  • Avoid using confusing magic numbers

  • Minimise extensive nested conditions

  • Don’t implement super long functions

  • Avoid code duplication

  • Make necessary comments

• 7 Unconventional Pieces of Coding Advice

• 9 Clean Code Patterns I wish I knew earlier

The Clean Code

• Martin, The Clean Code (無瑕的程式碼：敏捷軟體開發技巧守則)

  • 寫程式的規範

    • 如同童軍的規則:「離開營地前，讓營地比使用前更乾淨」

    • CLEAN CODE: CHAPTER 1

  • 那什麼是乾淨的程式碼?

    • 有意義的命名

      • Clean Code之有意義的命名

      • CLEAN CODE: CHAPTER 2 - MEANINGFUL NAMES

      • How To Create Meaningful Names In Code

        • Use Names Which Reveal Intention

        • Avoid Disinformation

        • Make Meaningful Distinctions

        • Use Names You Can Pronounce

        • Use Searchable Names

        • Member Prefixes

          • Don’t use member prefixes.

      • A Useful Framework for Naming Your Classes, Functions, and Variables **

        • prefix? + action (A) + high context (HC) + low context? (LC)

        • 5 Guideline for Variable Naming

          • Follow S-I-D

            • A name must be Short, Intuitive and Descriptive

          • Avoid Contraction

          • Avoid Context Duplication

          • Should Reflect expected result

          • Consider Singular/Plurals

          • Use meaningful and pronounceable variable names

    • 函式

      • 只做一件事

      • 避免太多參數

      • 利用例外處理代替回傳錯誤碼

      • CLEAN CODE: CHAPTER 3 - FUNCTIONS

    • 註解

      • CLEAN CODE: CHAPTER 4 - COMMENTS

      • Comments In Your Code

      • Maintain Code Hygiene With These 4 Simple Code Commenting Rules

        • Only comment things that have business logic complexity

        • Remove Dead Code

        • Remove journal comments, that’s what Git logs are for

        • Positional markers? Remove them

      • Yes, Your Code Need Comments

    • 編排

      • CLEAN CODE: CHAPTER 5 - FORMATTING

    • 物件及資料結構

      • CLEAN CODE: CHAPTER 6 - OBJECTS AND DATA STRUCTURES

    • 錯誤處理

      • Clean Code之錯誤處理

      • CLEAN CODE: CHAPTER 7 - ERROR HANDLING

    • 邊界

      • CLEAN CODE: CHAPTER 8 - BOUNDARIES

    • 單元測試

      • CLEAN CODE: CHAPTER 9 - UNIT TESTS

    • 類別

      • CLEAN CODE: CHAPTER 10 - CLASSES

    • 系統

      • Separation of concerns

        • 切割不同目的的程式碼 (如:MVC的切割)

          • 傳統的PHP程式碼，會把HTML跟PHP程式碼混在一起，這樣就很難看得懂，當然，切割程式之後，相對地就需要多一點複雜度了 (詳參:php sample)

          • 逐步提昇PHP技術能力 - 逐步改善軟體架構

            • 一個「古典」php論壇

            • 分離出頁面的邏輯

            • 使用樣板引擎

            • 建立簡單的View

            • 用DAO初步分離資料邏輯

            • 轉換到PDO

            • 單元測試

            • 寫一個簡單的Controller

            • 套用MVC架構與結語

        • Aspect-oriented programming: the separation of cross-cutting concerns

          • AOP 觀念與術語

          • Logging: Moving into next level in user log events with Spring AOP

          • Spring Security

      • CLEAN CODE: CHAPTER 11 - SYSTEMS

    • 羽化 (Emergence)

      • 簡單設計守則 (詳參: Kent Beck 的四個簡單程式設計原則)

      • CLEAN CODE: CHAPTER 12 - EMERGENCE

    • 平行化

      • CLEAN CODE: CHAPTER 13 - CONCURRENCY

    • 持續的精煉 (Successive Refinement)

      • CLEAN CODE: CHAPTER 14 - SUCCESSIVE REFINEMENT

    • JUnit 的內部結構

      • CLEAN CODE: CHAPTER 15 - JUNIT INTERVALS

    • 重構 SerialDate

      • CLEAN CODE: CHAPTER 16 - REFACTORING SERIALDATE

    • 程式碼的氣味和經驗法則 (Smells and Heuristics)

      • CLEAN CODE: CHAPTER 17 - SMELLS AND HEURISTICS

The Clean Coder

• Martin, The Clean Coder (無瑕的程式碼 番外篇：專業程式設計師的生存之道)

• [還少一本書] The Clean Coder

• The Clean Coder之三點補充

• The Clean coder: 無瑕的程式碼 番外篇 – 書摘心得

• 心得 The Clean Coder 無瑕的程式碼 番外篇：專業程式設計師的生存之道 - 1

• What Makes a Better Programmer?

  • 2003: Patterns of Enterprise Application Architecture

  • 2000: Refactoring

  • 1994: Design Patterns

  • 1975: The Mythical Man-month

  • 1971: The Psychology of Computer Programming

• 我們要如何能產出乾淨的程式呢?

  • 專業主義

    • 專業主義=擔當責任

      • 不做損害的事 (pp.46-50)

        • 不要破壞軟體功能 (不能留下bug)

        • 讓QA找不出任何問題

        • 要確信程式碼正常工作

        • 自動化QA

        • 不要破壞結構

          • 建立靈活可維護的結構

      • 職業道德 (pp.51-55)

        • 瞭解你的領域

          • Design patterns：必須能描述GoF的24個設計模式，同時對於POSA書中所介紹的許多模式都有實戰經驗

          • Design principles：SOLID原則

          • Methods：XP、Scrum、Lean、Kanban、Waterfall、Structured Analysis、Structured Design

          • Disciplines：TDD、Object-Oriented Design、Structured Programming、Continuous Integration、Pair Programming

          • Artifacts：UML、DFD、Structure Chart、Petri Net、State Transition Diagram and Table、Flow Chart、Decision Table

        • 堅持學習

        • 練習

        • 協作

        • 輔導

        • 瞭解業務領域

        • 與雇主/客戶保持一致

        • 謙遜不』

    • 竭盡所能地去追求和捍衛自身的目標 (p.60)

      • 去找到共同目標

  • 說『是』

    • 真正的承諾應該是

      • 你對自己將會做某件事做了清晰的事實陳述，而且還明確的說明了完成期限 (p.83)

  • 寫程式

    • 做好準備

      • 避免進入流態區(the flow zone)

      • 理性思考能力會下降 (p.96)

    • 阻塞

      • 好的解決方法:pair programming (p.98)

    • 除錯

      • 採用Test Driven Development (p.102)

    • 保持節奏

      • 保存好自己的精力和創造力 (p.102)

    • 進度延遲

      • 早期檢測、保持透明 (p.103)

    • 幫助 (pp.106-107)

      • 幫別人

      • 接受別人幫助

    • 輔導 (Ch.14, p.189)

  • 測試驅動開發

    • TDD三大法則 (p.111)

      • 在撰寫一個單元測試前，不可撰寫任何程式

      • 只撰寫剛好無法通過的單元測試，不能編譯也算無法通過

      • 只撰寫剛好能通過當前測試失敗的產品程式

  • 練習

    • 程式設計柔道館 (pp. 120-123)

    • 自身經驗的拓展 (pp.123-124)

  • 驗收測試

    • 避免

      • 過早精細化 (p.127)

      • 遲來的模糊性 (pp.127-129)

  • 測試策略

    • QA 也是團隊的一部份 (p.142)

      • QA 是需求規約定義者（ QA as Specifiers）

      • QA 是特性描述者 （QA as Characterizers）

    • 自動化測試金字塔 (pp.143-146)

      • 單元測試 100%

      • 元件測試 50%

      • 整合測試 20%

      • 系統測試 10%

      • 人工探索式測試 5%

  • 時間管理

    • 會議 (pp.148-151)

    • 專注力 (pp.152-154)

    • 時間拆分和番茄工作法 (p.154)

      • Pomodoro_Technique

    • 要避免的行為 (p.155)

      • 避免優先順序錯亂

    • 死胡同 (p.155)

      • 有足夠勇氣走回頭路

    • 泥潭 (pp.155-156)

      • 要有足夠勇氣走回頭路

  • 預估

    • 預估的方法

      • PERT (pp.162-164)

      • 預估任務 (pp.165-167)

        • 德爾菲法

        • 亮手指

        • 規劃撲克

        • 關聯預估

        • 三元預估

      • 大數定律 (p.167)

  • 壓力

    • 應對壓力 (pp.172-173)

      • 不要驚慌失措

      • 溝通

      • 依靠你的紀律原則

      • 尋求幫助

        • Pair programming

  • 協作

    • 程式設計師與人 (pp.177-181)

      • 與雇主

      • 與程式設計師

  • 團隊與專案

    • 有凝聚力的團隊 (p.184)

    • 如何管理有凝聚力的團隊 (p.185)

      • 將專案分配給有凝聚力的團隊

  • 輔導、學徒期與工藝典範

    • 學校能夠傳授電腦程式設計的理論，但是無法傳授你成為程式設計師的原則，實踐，技能

      • 需要建立一個包括學徒期、實習期和長期指引的機制 (p.200)

Code Smell

• 談談壞味道（1）：Duplicated Code

• 談談壞味道（2）：Long Method & Large Class

• 談談壞味道（3）：Long Parameter List & Divergent Change

• 談談壞味道（4）：Shotgun Surgery & Feature Envy

• 談談壞味道（5）：Data Clumps & Primitive Obsession

• 談談壞味道（6）：Switch Statements & Parallel Inheritance Hierarchies

• 談談壞味道（7）：Lazy Class & Speculative Generality

• 談談壞味道（8）：Temporary Field & Message Chains

• 談談壞味道（9）：Middle Man

• 談談壞味道（10）：Inappropriate Intimacy

• 談談壞味道（11）：Alternative Classes with Different Interfaces

• 談談壞味道（12）：Incomplete Library Classes

• 談談壞味道（13）：Data Class

• 談談壞味道（14）：Refused Bequest

• 談談壞味道（15）：Comments

• Code Smell (非常完整的介紹)

• Code Smell (wikipedia)

• Your Code Really Stinks, This is How to Improve It

  • Duplicated Code

  • Large Class

  • Long Method

  • Long Parameter List

  • Divergent Change/Shotgun Surgery

  • Feature Envy

  • Data Clumps

  • Switch Statements

  • Middle Man

  • Comments

• What Makes Code Bad?

  • Unreachable Code

  • Dead Code Including Lazy Classes

  • Large Classes

  • Circular References That Lead to a God Object

  • Speculative Generality

  • Hard-Coding

  • Magic Number

  • Long If(Condition)

  • Sequential Coupling

  • Overuse of Inheritance

  • Not Using Core Programming Language Features

  • Overly Complex Comments

  • Message Chain

  • Data Clumps

  • Poltergeists

• 初次認識 code smells 與分類

  • A Taxonomy for "Bad Code Smells"

    • The Bloaters

    • The Object-Orientation Abusers

    • The Change Preventers

    • The Dispensables

    • The Couplers

• 『珍惜生命，遠離波動拳』 -- 從壞習慣談程式可讀性

• 『波動拳消除了，然後呢？』 -- 談Code Smell 辨識與消除

• 『你儂我儂的程式碼』 -- 談Code Smell 之 Feature Envy

• 10 Programming Code Smells That Affect Your Codebase

• Write Better Code by Knowing What’s Bad

  • Code Duplication

  • Spaghetti Code

  • Contains Copy-Pasted Code

  • Poor Naming Conventions

  • Contains God’s Code

• Higher-Order Code Smells : The N-Dimensional Object

• Why Is It So Easy to Become a Bad Coder?

  • You probably won’t know that your code is terrible until someone tells you.

Implementation Patterns

• Beck, Implementation Patterns (Kent Beck的實作模式)

• 卓越設計的價值觀(Values) (p.38)

  • 溝通 (Communication)

    • 讓讀者容易閱讀

  • 簡單 (Simplicity)

    • 刪除不必要的程式碼

    • 去除不必要的需求

  • 靈活 (Flexibility)

    • 簡單的程式可能更靈活

    • 但靈活的程式也可能會變複雜

• 卓越設計的原則 (Principles) (p.41-46)

  • 局部化影響 (Local Consequences)

    • 減少變化所引起的代價

  • 最小化重複 (Minimize Repetition)

    • 程式碼複製得越多，變化的代價就越高

  • 將邏輯與資料綑綁 (Logic and Data Together)

    • 局部化影響的必然結果

  • 對稱性 (Symmetry)

    • 例如:有add()應該就有remove()

  • 宣告式的表達 (Declarative Expression)

    • 以宣告的方式表達出意圖

//JUnit 4

@RunWith(Suite.class)

@TestClasses({

SimpleTest.class,

ComplicatedTest.class})

class AllTests{

}

• • 變化率 (Rate of Change)

    • 把具有相同變化率的邏輯、資料放在一起，把具有不同變化率的邏輯、資料分開

• 實作模式:牽涉範圍最大只到類別 (Design Patterns是類別間的模式)

  • 類別 (18個模式)

    • Implementation Patterns: Pluggable Selector by Teddy Chen (p.69)

  • 狀態 (19個模式)

    • Implementation Patterns: Variable State by Teddy Chen (p.78)

  • 行為 (14個模式)

    • Implementation Patterns: Guard Clause by Teddy Chen (p.103)

  • 方法 (24個模式)

    • Implementation Patterns: Composed Method by Teddy Chen (p.109)

    • Implementation Patterns: Boolean Setting Method by Teddy Chen (p.125)

  • 集合 (6個模式)

• Implementation Patterns的優缺點

Clean Architecture

• [還少一本書] Clean Architecture

• Clean Architecture（1）：軟體架構的定義與目的

• Clean Architecture（2）：Port and Adapter Architecture

• Clean Architecture（3）：精選參考範例

• Clean Architecture（4）：架構三原則首部曲—分層原則

• Clean Architecture（5）：架構三原則二部曲—相依性原則

• Clean Architecture（6）：架構三原則三部曲—跨層原則

• Clean Architecture讓系統穩定演化